Big integrals, opApply autoindex, safer integrals

Weed resume755 at mail.ru
Fri Dec 26 22:34:18 PST 2008


Yigal Chripun пишет:
> Weed wrote:
>> Yigal Chripun пишет:
>>> Weed wrote:
>>>> bearophile пишет:
>>>>> Weed:
>>>>>> where else can I use that thing?
>>>>> I was talking about a built-in syntax for multi-precision integral
>>>>> numbers. I presume you can use it only when you want to use
>>>>> multi-precision integral number :-)
>>>>> Do you feel the need to use it in other situations too?
>>>> I thought proposes a more advanced method for operators overloading :)
>>>>
>>>> It seems to me, all operators working with values should correspond to
>>>> processor instructions. Instruction like "Sum int [80] with int [30]"
>>>> does not exist and it is not necessary to do for it the built-in-like
>>>> syntax.
>>> I disagree. Programing languages are for programmers, i.e Humans, not
>>> CPUs. if you want to work with a programming language that corressponds
>>> to a CPU, go learn Assemby language.
>>>
>>> It makes perferct sense to use operators that do not corespond to cpu
>>> instructions, for example:
>>> auto m1 = new Matrix(10, 30);
>>> auto m2 = new Matrix(30, 20);
>>> ... fill m1, m2 with data...
>>> auto res = m1 * m2;
>>>
>>
>> Ohhh! Matrices! Mmmm... :)
>>
>>> The point of programming languages is to provide abstarctions to the
>>> underlying machine,
>>
>> without the overhead!
>>
>>> so that we humans can express complex problems to
>>> the CPU more easily.
>>
>> Yes. But language without the overhead costs almost get what I said.
>>
>>> also, another reason for allowing: "Sum int [80] with int [30]" is due
>>> to vectorization. modern CPUs can perform operations on vectors so
>>> instead of doing:
>>> for (int i = 0; i<  80; ++i) { sum[i] = a[i] + b[i] }
>>> the CPU can process those in chunks of 4 ints at a time or something
>>> like that. This is already implemented in DMD.
>>
>> int[80] there is not an array of type int, it very big 80 bit int value
>>
>>
>> So initialization of mathematical types at compile time would be more
>> interesting:)
> 
> sorry, I don't understand your english.

You are in the majority:)

> int[80] is an array. see:

No! int [80] is not an array here!
It 80bit int value:
01010010010101001001010100100101010010010101001001010100100101010010010101001001

I just accidentally used the D syntax to describe it. Sorry.

> auto a = int[80];
> personally I'm against your idea of using static data as this is thread
> unsafe.

What is my idea?

> D2 will have shared to deal with multi-threading issues like that.
> still, I'd say that static should be limited to invariant data.
> it makes sense to do:
> static invariant m = IdentityMatrix(3,5);
> for instance, but what's the benefits of doing the same for mutable
> data? I don't see it..
> 
> 




More information about the Digitalmars-d mailing list