View mode: basic / threaded / horizontal-split · Log in · Help
December 26, 2008
Re: Big integrals, opApply autoindex, safer integrals
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.
December 26, 2008
Re: Big integrals, opApply autoindex, safer integrals
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:)
December 27, 2008
Re: Big integrals, opApply autoindex, safer integrals
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..
December 27, 2008
Re: Big integrals, opApply autoindex, safer integrals
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..
> 
>
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home