With ecl 16.1.3, I noticed that least-positive-double-float and least-positive-normalized-double-float are exactly equal. This is allowed, but ecl can work with denormals since (/ least-positive-normalized-double-float 10) is printed correctly.
Maybe these two values should be different?
Or maybe ecl really meant to turn on flush-to-zero so that no denormals can occur?
Hey,
With ecl 16.1.3, I noticed that least-positive-double-float and least-positive-normalized-double-float are exactly equal. This is allowed, but ecl can work with denormals since (/ least-positive-normalized-double-float 10) is printed correctly.
The reason they are the same is because portable C gives us DBL_MIN at our disposal (and its counterparts for other floats).
Maybe these two values should be different?
Maybe we could hardcode other value when ieee-floating-point is in featuers (fwiw it is an optional build flag). I'm not sure what would be the right thing here.
Or maybe ecl really meant to turn on flush-to-zero so that no denormals can occur?
ECL signals a floating-point-overflow/underflow conditions unless disabled by an internal function si:trap-fpe.
Regards, Daniel
Sorry for the delay....
On Tue, Jan 29, 2019 at 11:08 PM Daniel Kochmański daniel@turtleware.eu wrote:
Hey,
With ecl 16.1.3, I noticed that least-positive-double-float and least-positive-normalized-double-float are exactly equal. This is allowed, but ecl can work with denormals since (/ least-positive-normalized-double-float 10) is printed correctly.
The reason they are the same is because portable C gives us DBL_MIN at our disposal (and its counterparts for other floats).
Seems reasonable for portability.
Maybe these two values should be different?
Maybe we could hardcode other value when ieee-floating-point is in featuers (fwiw it is an optional build flag). I'm not sure what would be the right thing here.
I don't know either, but it is a bit weird if you can create and print values that are less than least-positive-double-float. :-)
Or maybe ecl really meant to turn on flush-to-zero so that no denormals can occur?
ECL signals a floating-point-overflow/underflow conditions unless disabled by an internal function si:trap-fpe.
You trap on underflow by default? That seems unusual and kind of annoying.
Regards, Daniel
Hey,
the issue has now been fixed in the develop branch, we use the {FLT,DBL,LDBL}_TRUE_MIN constants from the C11 standard where available.
Am 06.02.19 um 06:39 schrieb Raymond Toy:
> > Or maybe ecl really meant to turn on flush-to-zero so that no > denormals can > occur? > ECL signals a floating-point-overflow/underflow conditions unless disabled by an internal function si:trap-fpe.You trap on underflow by default? That seems unusual and kind of annoying.
No, that's not correct. By default, we only trap on overflow, division by zero and invalid operations.
Best regards, Marius Gerbershagen
-
Daniel Kochmański -
Marius Gerbershagen -
Raymond Toy