[Openmcl-devel] Infinity and NaN

[Liam Healy]

On Mon, Jul 19, 2010 at 3:02 PM, R. Matthew Emerson <rme at clozure.com> wrote:
>
> On Jul 19, 2010, at 12:35 PM, Liam Healy wrote:
>
>> I'm having trouble defining variables that create infinities and NaNs.
>> I am using GSL
>> http://www.gnu.org/software/gsl/manual/html_node/Infinities-and-Not_002da_002dnumber.html
>> to do this; here for example is my definition
>>
>> (defconstant +nan+
>>  (ignore-errors
>>    (cffi:foreign-funcall "gsl_nan" :double)))
>>
>> If I put this form into the listener, it loads fine, and
>>
>> +nan+
>> 1D+-0 #| not-a-number |#
>>
>> However, if I put this definition into a file to compile it,
>>
>> ASDF could not load gsll because FLOATING-POINT-INVALID-OPERATION detected
>> performing LOG on (1.0).
>>> Error: FLOATING-POINT-INVALID-OPERATION detected
>>>       performing LOG on (1.0)
>>> While executing: CCL::%FP-ERROR-FROM-STATUS, in process listener(1).
>>> Type :POP to abort, :R for a list of available restarts.
>>> Type :? for other options.
>>
>> I'm not sure where this is coming from, nor why taking the log
>> of 1.0 should be a problem.
>
> I recently changed how ccl deals with floating-point exceptions in foreign code (on x86-64), so I may have introduced or exposed a bug here.
>
> At the risk of boring everyone, I will explain the change.
>
> We used to unconditionally mask (disable) all floating point exceptions when calling a foreign function.  It's not free to save/restore the MXCSR (the register that contains fp status and control bits) around every foreign function call, so we now leave fp exceptions enabled (as configured by ccl:set-fpu-mode).  The runtime will notice when an fp exception takes place in foreign code, mask all fp exceptions, and try the call again.  When we return from the foreign function call, we check to see if the runtime handled an fp exception: if it did, we save the fp exception state and restore lisp's MXCSR (again, as set by ccl:set-fpu-mode).
>
> leo2007 on #ccl pasted a backtrace of this problem: http://paste.pocoo.org/show/239363

... who as a matter fact was the one who reported the problem in GSLL
to the gsll-devel
mailing list.

>
> Anyway, we're looking at it.

OK, no problem, for now I've #-ccl conditionalized away these definitions
so that all of GSLL loads.  Fortunately nothing relies on it.

>
> I guess that what happened in this case is that some operation somewhere has set the exception flags and left them behind;  later, when LOG checks them, a spurious error is signaled.
>
> By the way, there are constants ccl::double-float-{positive,negative}-infinity, and ccl::double-float-nan. I wonder if we should be exporting those.

These look identical to what I get from the foreign code,
even down to the error I get when I try to describe them:

(describe ccl::double-float-nan)
Float: 1D+-0 #| not-a-number |#
> Error: FLOATING-POINT-INVALID-OPERATION detected
> While executing: CCL::FIXNUM-DFLOAT-COMPARE, in process listener(1).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.

Is this the same problem you describe with the foreign code?

>
>> (lisp-implementation-version)
>> "Version 1.6-dev-r13980M-trunk  (LinuxX8664)"
>