Here is the program:


import std.stdio;

const long DIM = 1024*1024*1024*1024*4;
void main()
{
writeln(" DIM  is ", DIM);
writeln(" Value ", 1024*1024*1024*1024*4);
writeln(" Max ", long.max);

}

I compiled it:
gdc -frelease -O3 temp.d -o t1 ; ./t1
 DIM  is 0
 Value 0
 Max 9223372036854775807

Can you please tell, why it is taking DIM as zero? If I reduce DIM, it works fine. It is strange.

> const long DIM = 1024*1024*1024*1024*4;

Those are all int (32 bit) literals so it is prolly wrapping around the intermediates before it actually assigns to DIM.

If you used 1024L it should be better, by making the right hand side 64 bit too.

It is similar to

float x = 1 / 2; // x == 0 because the right hand side is done as ints

float x = 1.0 / 2; // now x == 0.5

On 02/14/2013 04:44 PM, Sparsh Mittal wrote:
> Can you please tell, why it is taking DIM as zero? If I reduce DIM, it works
> fine. It is strange.

1024 is an int value.  Write 1024L instead to ensure that the calculation is performed using long.

On Thursday, 14 February 2013 at 15:51:45 UTC, Joseph Rushton Wakeling wrote:
> On 02/14/2013 04:44 PM, Sparsh Mittal wrote:
>> Can you please tell, why it is taking DIM as zero? If I reduce DIM, it works
>> fine. It is strange.
>
> 1024 is an int value.  Write 1024L instead to ensure that the calculation is performed using long.

Thanks a lot for your help.

On Thursday, 14 February 2013 at 15:44:25 UTC, Sparsh Mittal wrote:
> Here is the program:
>
>
> import std.stdio;
>
> const long DIM = 1024*1024*1024*1024*4;
> void main()
> {
> writeln(" DIM  is ", DIM);
> writeln(" Value ", 1024*1024*1024*1024*4);
> writeln(" Max ", long.max);
>
> }
>
> I compiled it:
> gdc -frelease -O3 temp.d -o t1 ; ./t1
>  DIM  is 0
>  Value 0
>  Max 9223372036854775807
>
> Can you please tell, why it is taking DIM as zero? If I reduce DIM, it works fine. It is strange.

It's not because "DIM" is a long, that "1024*1024*1024*1024*4" is a long. Case in point, it is calculated as an int, and becomes 0.

Try it with:
"1UL * 1024*1024*1024*1024*4"
or
"1024UL*1024*1024*1024*4"
or
"cast(ulong)1024*1024*1024*1024*4"
To force the actual calculation into long mode, and you'll get the desired result.

Or, just "2UL^^42", depending on just what you want "DIM" to represent.

Sparsh Mittal:

> const long DIM = 1024*1024*1024*1024*4;

Vote, if you want:
http://d.puremagic.com/issues/show_bug.cgi?id=4835

Go language doesn't have such bugs. Likewise D should not have such bugs.

Bye,
bearophile

On 02/14/2013 04:49 PM, Adam D. Ruppe wrote:
>> const long DIM = 1024*1024*1024*1024*4;
>
> Those are all int (32 bit) literals so it is prolly wrapping around the
> intermediates before it actually assigns to DIM.
>
> If you used 1024L it should be better, by making the right hand side 64 bit too.

Oh, snap. :-P

First time I ran into this kind of issue was when I was calculating a power of 2 in C++ by using:

    size_t p = 1 << m;

m was calculated to ensure that 2 ^^ m was the largest power of 2 that could (i) be multiplied by 2 without integer wraparound and (ii) fell within the range of the uniform random number generator.  And all was fine until I upgraded my system to 64-bit, and suddenly I was getting a nonsense value of p.

It shouldn't have changed, because the RNG used a 32-bit unsigned integer as its internal data type.  After much head-scratching I cottoned on to the fact that as it was, 1 << m was a regular integer that was wrapping around to a negative value before being converted to size_t (which in practice meant: it came out as the maximum of size_t less the negative value).  With 32-bit size_t this was the correct value.  With 64-bit size_t it meant a value of p far larger than it should have been.

Replace the power-of-2 statement with

    size_t p = 1UL << m;

... and everything was cured.