[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) |
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
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/21
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination,
Camm Maguire <=
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/22
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/23
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/23
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/24
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/27
- Message not available
- Re: [Gcl-devel] [Maxima] Out of range floating point number determination, Camm Maguire, 2012/08/28