[Bug 45] Bug in conversion of floating point literals

[Thomas Kuehne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

d-bugmail at puremagic.com schrieb am 2006-03-15:
>> Strictly speaking the code above behaves correctly.
>> 
>> http://www.digitalmars.com/d/float.html
>> # For floating point operations and expression intermediate values, a
>> # greater precision can be used than the type of the expression. Only the
>> # minimum precision is set by the types of the operands, not the maximum. 
>> 
>> The documentation doesn't require an expression to always use the same
>> "excessive" precision.
>
> That doesn't apply in this case. There's no intermediate value here.
>
> 3.40483L is not the same as 3.40483. It's a different number.
>
> You provide the compiler with input values of a given precision, and it returns
> output values of a different precision. It's free to use any higher precision
> during the intermediate calculations, but it is NOT free to change the
> precision of the inputs (if it were, the L prefix would be entirely
> meaningless). It's just a bug (and I suspect it's a regression introduced
> during the improvements to constant folding that occurred around DMD 0.138).

I'm deffinatly on the "literal defines precision" side, but have a look
at:
http://d.puremagic.com/bugzilla/show_bug.cgi?id=21

Thomas



-----BEGIN PGP SIGNATURE-----

iD8DBQFEGIMR3w+/yD4P9tIRAkJqAKCHk1V4EB/gmrpgUQnXKp86YQMlWQCgl0SD
fdSYAXNs3CxYxIcsIeze+yo=
=mefP
-----END PGP SIGNATURE-----