Big integrals, opApply autoindex, safer integrals

[Weed]

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:)