Hi,
This is an uneducated guess, but won't get any information lost if i
is too large for even transforming it into a real(32)?
An int(32) will need these 32 Bit completely for the integer part but
a real(32) needs them for both the integer/exponent and the fraction
parts.
Let's say that i is 1073741824 which is 2^30 so it will need the 31st
bit which is zero to show that it's a positive number. The 30th bit is
one while the remaining 29 bit are zero (where the least significant
bit is counted as No. 0).
If we anyway put this value of i into a float(32) which has the same
amount of bits, won't we get a wrong value?
At the moment I have no opportunity to test this in Chapel but in C++
I tried the following:
#include <stdio.h> // I stay with a C-function for console output in
this example :)
// 32-bit-float
float foo(float x)
{
return x+0.123;
}
int main()
{
int32_t bla = 1073741824; // 2^30
printf("%f\n",foo(bla));
return 0;
}
The output is 1073741824.000000
If the same will happen in Chapel, there should be at least a compiler
warning.
bye
Zitat von Brad Chamberlain <[email protected]>:
> Hi Chapel Users --
>
> We wanted to highlight a question that came up recently on a sibling
> thread in hopes of getting feedback from the community. Perhaps most
> simply, given the following code:
>
> var i: int(32) = 42;
>
> foo(i); // call requires coercion from int to real
>
> proc foo(x: real(32)) { writeln("In 32-bit version"); }
>
> proc foo(x: real(64)) { writeln("In 64-bit version"); }
>
> Which of the two calls would you want/expect foo() to dispatch to (if
> either one)?
>
>
> While this example is fairly arbitrary, note that this has implications
> for things like which math operators are invoked in cases where there is
> no precisely matching signature for the two argument types, such as:
>
> ...i * 2.5...
>
>
> We'd appreciate hearing any heartfelt opinions on this topic. Opinions
> with supporting rationale are particularly appreciated.
>
> Thanks,
> -Brad
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Chapel-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-users
------------------------------------------------------------------------------
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
