gcl-devel
[Top][All Lists]
Advanced

[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)

Greetings!

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.
>

OK

> 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]