[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] [Maxima] Out of range floating point number determinatio

From: Camm Maguire
Subject: Re: [Gcl-devel] [Maxima] Out of range floating point number determination
Date: Tue, 21 Aug 2012 16:55:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)


Raymond Toy <address@hidden> writes:

> On Tue, Aug 21, 2012 at 8:34 AM, Camm Maguire <address@hidden> wrote:
>     Raymond Toy <address@hidden> writes:
>     > It would be nice if we could get gcl to signal errors for IEEE errors
>     > like overflow, divide-by-zero, and invalid-operation.  I think most
>     > other lisps have some option to do this.  (I personally don't like float
>     > operations returning NaN since they propagate forever and I never find
>     > NaN being useful at the end of some long computation.)
>     >
>     > Perhaps Camm can give us the magic gcl options to enable these?
>     >
>     Greetings!  I've been looking at this.  I have a local version with some
>     support, but have questions about what is truly useful.
>     1) By default, hardware FPE signals are enabled "oneshot", i.e. after
>     the first occurrence, the enabling command must be reissued to catch the
> I don't think they're oneshot.  Once enabled, they will always generate a 
> trap when the exception occurs, unless your trap handler chooses to
> disable the exceptions.

I was hoping to abstract this at the C (rather than hardware specific
assembler) level.  Specifically the feenableexcept call provided in
fenv.h.  Playing around with this, it does indeed appear to be "oneshot".

>     next.  (This is entirely different from the FPE signal catching
>     mechanism with sigaction, what is meant here is that FPE signals are not
>     even sent by the kernel by default without some enabling command.)  I'm
>     assuming that at the lisp level, one wants a global variable that keeps
>     the desired behavior, and have the C level signal handler reenable the
>     FPE signal as desired when caught automatically.  The alternative is to
>     provide the user with an enabling command that will work once and must
>     be repeated by the user if so desired.
>     2) Modern kernels appear to have the ability to enable only certain
>     types of error, and this level of granularity could be passed to the
>     lisp user, with some complexity.  divide-by-zero, overflow, underflow,
>     inexact, and invalid are all separably trapable.  My guess is that a
>     global enable command is appropriate here.
> I think it's more a function of the chip than the kernel.  Look up the x87 
> FPU control word and the SSE mxcsr register to see what all the options
> are.  For gcl, I guess you might have to know if gcc is using SSE or not so 
> that you can configure either the x87 control word or the sse mxcsr
> register appropriately.

See above.  Do you see any problem sticking with a C interface?

> To be general, I think you'd want the user to be able to set the masks to any 
> desired (valid) value.


> But I think maxima really just needs the overflow, invalid, and 
> divide-by-zero exceptions enabled, and have lisp deliver the exceptions as 
> lisp
> errors so that a lisp handler can do something with them.
>     3) The fault address is typically available.  It could be reported at
>     the lisp level, but my guess is that the typical lisp user would not
>     find that useful, unless a reverse lookup of the function name was
>     performed.
> It probably doesn't hurt to provide the fault address, but maxima probably 
> doesn't need that.  I, however, find it useful if the offending operands
> can be returned.  Maxima probably doesn't need that either, though.

sigaction manpage does not appear to indicate that these are available.
The function name lookup is possible, but tedious in 2.6.8pre.

> If you need more information, I can help with that. 
> What would be really cool is if we could get a small snippet of gcl code 
> (lisp or C) that we can compile today in maxima to enable this.  Then we
> don't have to wait for a new release of gcl or for all the distros to update 
> their copy of gcl.

This is almost possible.  Alas, implementing this has uncovered a
(sigaction) signal resetting bug for FPE in the base code.

Take care,

> Ray

Camm Maguire                                        address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]