[Ecls-list] Error: Cannot print object #<single-float quiet NaN> readably.

[Waldek Hebisch]

Juan Jose Garcia-Ripoll wrote:
> 
> On Mon, Dec 19, 2011 at 7:00 PM, Waldek Hebisch <hebisch at math.uni.wroc.pl>w=
> rote:
> 
> > Put the the following line in a file:
> >
> > (DEFUN |nangenericcomplex| () (PROG () (RETURN (/ 1.0 (COMPLEX 0.0)))))
> >
> > And then try to compile-file it:
> >
> > > (compile-file "sfsfun.clisp")
> >
> > ;;; Loading #P"/var/tmp/hebisch/usr/lib/ecl-11.1.1/cmp.fas"
> > ;;;
> > ;;; Compiling sfsfun.clisp.
> > ;;; OPTIMIZE levels: Safety=3D2, Space=3D0, Speed=3D3, Debug=3D0
> > ;;;
> > ;;; Compiling (DEFUN |nangenericcomplex| ...).
> > ;;; End of Pass 1.
> > ;;; Emitting code for |nangenericcomplex|.
> > ;;; Internal error:
> > ;;;   ** Cannot print object #<single-float quiet NaN> readably.
> > NIL
> > NIL
> > NIL
> >
> > FriCAS uses such a function to raise floating point errors
> > when appropriate.  In principle I could divide by "runtime"
> > zero (I have one at hand as just before call to |nangenericcomplex|
> > I have test which checks that number to be used as divisor is zero).
> > But having separate function seems clearer.  And some day compiler
> > may be smart enough to realize that "runtime" zero is a zero and
> > try to constant fold it...
> 
> 
> Actually this is the time in which ECL is already clever enough to
> constant-fold the #'/ and detect that the output of that function can not
> be saved. Changing the function to
> 
> (DEFUN foo () (PROG () (locally (declare (notinline /)) (RETURN (/ 1.0
> (COMPLEX 0.0))))))
> 
> fixes the problem, because ECL no longer tries to precompute the quotient.

This workaround is unattravtive to me as the failng code is
mechanically generatated.  I have a different workaroud.
Namely, the code was called as follows:

    (if (zerop res)
        (progn ;;; Write error message
              (|nangenericcomplex|)))

I have changed it to:

    (if (zerop res)
        (progn ;;; Write error message
              (/ 1.0 res)))

However, in the second version smart compiler can note that 'res'
is zero and try to constant fold it...

> I am unsure about how to fix this, or even whether this needs to be fixed..=
> .

AFAICS the code is legal and works as intended in conforming
implementations.  As compiler writer I would be tempted to
disallow it, but experience with different languages shows
that such codes appear in real life with low but non-negligable
frequency -- how can you print your own error message (customized
to concrete use) but still raise normal division by zero error?
I guess I could try to assemble proper condition object, but
just performing division by zero is simpler and insures that
condition is exactly the same as other division by zero errors.

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl