From: Cheng Che Chen
Subject: Lisp floating-point underflow
Date: 
Message-ID: <2go0qa$sdt@nntp2.Stanford.EDU>
Dear people:

I don't know a lot of Lips, but recently I needed to run someone else's Lisp
program.  Our school's workstations have Lucid Lisp.  The interpreter seems to
be very unforgiving about underflow, refusing to continue and giving me the
message:

>>Error: A condition of type FLOATING-POINT-UNDERFLOW occurred.

*:
:C  0: Try loading "small.lisp" again
:A  1: Abort to Lisp Top Level


Could someone familiar with this Lisp implementation instruct me about how to
disable this trap-on-underflow feature?

Thanks.

From: Barry Margolin
Subject: Re: Lisp floating-point underflow
Date: 
Message-ID: <2gq4igINN81q@early-bird.think.com>
In article <··········@nntp2.Stanford.EDU> ·····@leland.Stanford.EDU (Cheng Che Chen) writes:
>>>Error: A condition of type FLOATING-POINT-UNDERFLOW occurred.
>
>*:
>:C  0: Try loading "small.lisp" again
>:A  1: Abort to Lisp Top Level

When I get a floating point underflow in Lucid CL, the proceed options are:

:C  0: Use de-normalized (or zero) result
:A  1: Abort to Lisp Top Level

I'm not sure why you're not getting the first option.

>Could someone familiar with this Lisp implementation instruct me about how to
>disable this trap-on-underflow feature?

You can use the WITH-FLOATING-POINT-TRAPS macro to specify which traps
should be enabled and disabled.  See the documentation for details.  Note
that this is not portable.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

······@think.com          {uunet,harvard}!think!barmar
From: ······@ma2s2.mathematik.uni-karlsruhe.de
Subject: Re: Lisp floating-point underflow
Date: 
Message-ID: <2gqb5a$52o@nz12.rz.uni-karlsruhe.de>
Rodrigo Vanegas <··@cs.brown.edu> writes:

> A floating point undeflow
> error is of the same serious nature as a division by zero.  There is
> no floating point representation for the only value which would make
> any sense as the result of this floating point operation.

Not at all. Floating point *overflow* and division by zero are nearly
the same: evaluation of a mathematical function near or at a singularity,
i.e. a point where no finite limit exists.
But floating point *underflow* is harmless from a mathematical point of
view. It is only the floating point representation that is too limited
there. In fixed point arithmetic, there is no underflow. 0.0 ought to be
returned.


                    Bruno Haible
                    ······@ma2s2.mathematik.uni-karlsruhe.de
From: eric dedieu (these mazer 95)
Subject: Re: Lisp floating-point underflow
Date: 
Message-ID: <1994Jan10.135249.17506@imag.fr>
In article <···············@monaco.cs.brown.edu> ··@cs.brown.edu (rodrigo vanegas) writes:
>
>So you see, disabling the error doesn't quite solve your problem.
>Whatever caused this overflow will be expecting a value and since the
>multiplication/division was unable to produce a value and no value
>exists which can be used in its place, the program is stuck.  (C would
>just use 0 -- but is that what you want?)
>

I have often handled underflow traps by disabling the error, and it
automatically gives 0 - what I want. Very useful when using exponentials.

(defmacro without-underflow-traps (&body body)
  `(with-floating-point-traps (nil '(floating-point-underflow))
     ,.body))

(defun enable-underflow-traps (x)       ; argument nil or t
  (setf (enabled-floating-point-traps)
	(if x (adjoin 'floating-point-underflow (enabled-floating-point-traps))
	  (remove 'floating-point-underflow (enabled-floating-point-traps)))))
-- 
Eric Dedieu  (···········@imag.fr)
LIFIA - 46 av. Felix Viallet, 38031 Grenoble Cedex, France
Tel: 76 57 46 11  - Fax: 76 57 46 02  - Dom: 76 07 28 77