Lars T. Kyllingstad wrote:
Don wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like
that opPow made it in, and also the changes to std.math look very
useful.
I have one question regarding the latter: What exactly is supposed
to happen when I run the example in the FloatingPointControl
documentation? Is the program supposed to crash with some
informative error message, or do I have to do something to catch the
exception? Currently, nothing out of the ordinary happens when I run
it on my computer -- y just becomes NaN when x is NaN.
Aargh, the example's wrong. DMD optimizes the assignment into a blit.
Try setting y = x*2.
I take that back. The example is correct. This code...
-----
import std.math;
void main()
{
real x;
FloatingPointControl fpctrl;
fpctrl.enableExceptions(FloatingPointControl.severeExceptions);
double y = x*3.0;
}
----
results in:
object.Error: Invalid Floating Point Operation
However, it seems that the compiler is no longer creating variables of
type double and float as signalling NaNs. That's a bug.
OK, thanks for explaining. :)
-Lars
I had a further look at this. The compiler *is* creating doubles and
floats as signalling NaNs. Turns out, that there are slight differences
between processors in the way they treat signalling NaNs, especially
between Intel vs AMD. Intel Core2 triggers SNANs when loading floats &
doubles, but *doesn't* trigger for 80-bit SNANs. The Pentium M that I
did most of my testing on, didn't trigger for any of them. AMD's docs
say that it triggers for all of them.
Won't be too hard to fix.
