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;

The point of programming languages is to provide abstarctions to the underlying machine, so that we humans can express complex problems to the CPU more easily.

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.

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

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.
int[80] is an array. see:
auto a = int[80];
personally I'm against your idea of using static data as this is thread unsafe.
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..

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..
> 
>