On Thu, 15 Oct 2015, Sven Schreiber wrote:
Am 15.10.2015 um 02:21 schrieb Allin Cottrell:
> On Wed, 14 Oct 2015, Sven Schreiber wrote:
>>> I suspect that your code ends up squaring a very small number and hence
>>> producing a "subnormal" floating-point value (underflow). As noted
in
>>> the post above, different C libraries can respond to this differently:
>>> some will set the variable errno to ERANGE in this case and some will
>>> not.
>>
>> That "diagnosis from afar" seems to be correct: there is one value
>> 4.9033e-310 in the vector which is going to be squared. Chapeau!
>>
>> It's strange though where this number is coming from in the first
>> place...
It seems (not proven yet, just tentatively) the small number is coming
from the cdf() function. And playing around with the cdf() function (on
gretl for Windows) gives:
gretl-Version 1.10.91cvs
Aktuelle Sitzung: 2015-10-15 12:52
? ii = -37.64
? cc = cdf(N, ii)
? printf "%e %e\n", cc, cc^2
2.384211e-310 0.000000e+000
So here it seems to work ok without any underflow problems, I will now
test the same thing on the server / Linux.
The calculation is in fact underflowing here (the square of 2.38e-310
is not zero, it's just a number that is much too small to be
represented as a "double"). It's just that in this context gretl is
not paying attention to the errno value set by the C library, and
so giving you a zero result without complaining.
We have not been very consistent in this regard: only in certain
places in the code (for example gretl_matrix_dot_op) have we
rigorously inspected errno after calculation (though in general we
check for infinities and NaNs).
There's now a modification in git/snapshots: in the contexts where we
examine errno we distinguish between underflow and other problems
(using the C99 functions defined in fenv.h) and we let underflow pass
(with just a warning on stderr). It seems that this is probably what
most people want, most of the time.
Allin