Here is a new patch. Please test
\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{\$SPAD/src/input lode.input}
\author{The Axiom Team}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{License}
<>=
--Copyright The Numerical Algorithms Group Limi
Martin Rubey <[EMAIL PROTECTED]> writes:
| Waldek Hebisch <[EMAIL PROTECTED]> writes:
|
| > Martin, first I _really_ prefer to get exceptions in normal code.
| > Ignoring exceptions is a great way to do not see bugs. Also, things
| > like infinities and (particularly nasty) "not a number" break
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin, first I _really_ prefer to get exceptions in normal code.
> Ignoring exceptions is a great way to do not see bugs. Also, things
> like infinities and (particularly nasty) "not a number" break normal
> mathematical reasoning.
Don't worry, I se
Martin Rubey wrote:
>
> I finally have a patch that works at least on sbcl, and should not modify gcl
> behaviour too much.
>
> I do not think it's optimal, but I do think it's better than the current
> situation, where plots fail out of the blue on sbcl, and the workarounds are
> relatively ugl
I finally have a patch that works at least on sbcl, and should not modify gcl
behaviour too much.
I do not think it's optimal, but I do think it's better than the current
situation, where plots fail out of the blue on sbcl, and the workarounds are
relatively ugly. (manual clipping with max and mi
Martin Rubey <[EMAIL PROTECTED]> writes:
> In sbcl, we can actually do the same using
>
> )lisp (sb-ext::set-floating-point-modes :traps nil)
>
> we get
>
> - #.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
>
> which behaves as in gcl.
Unfortunately, it doesn't *quite*. In gcl, one can operate on
Martin Rubey <[EMAIL PROTECTED]> writes:
> > So, I affraid it is a bit more work to properly fix draw...
>
> I'm not so sure about that: with gcl, everything's fine when plotting
> sin(1/x)*exp(-1/x). At some point,
> TwoDimensionalPlotClipping.clipWithRanges,32 is called, and the range is
> re
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> Martin, ATM I would prefer to eliminate overflow form plotting.
> Overflow means that we are not getting correct result -- ignoring
> overflow means that we silently tolerate wrong values.
>
> Now, I do not consider x +-> 10^300 (or even x +-> 10^154)
Martin Rubey wrote:
>
> Dear all,
>
> sorry about the noise. I have to stop now, here is what I got so far. The
> patch below shows how that we need to explicitely trap errors outside the
> calculation of the function, these are mostly calculations of length.
>
> However, sin(1/x)*exp(-1/x) w
Dear all,
sorry about the noise. I have to stop now, here is what I got so far. The
patch below shows how that we need to explicitely trap errors outside the
calculation of the function, these are mostly calculations of length.
However, sin(1/x)*exp(-1/x) will not be drawn nicely with this pat
possibly another bug:
g: DFLOAT -> DFLOAT := x +-> 10^300
draw(g, x=-1..1)
seems to take forever.
Unfortunately, it seems that I need to rebuild the whole system to make changes
in CLIP and DRAW take effect. Since this is several hours everytime, I cannot
really continue. Below is a patch fo
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I wrote:
> >
> > Exceptions are expected -- we have error handler which is supposed
> > to catch them. We have to find what is wrong with error handling.
> >
>
> Look at DRAWCFUN.spad, in particular myTrap1 -- it is supposed to
> catch all numeric
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I wrote:
> >
> > Exceptions are expected -- we have error handler which is supposed
> > to catch them. We have to find what is wrong with error handling.
> >
>
> Look at DRAWCFUN.spad, in particular myTrap1 -- it is supposed to
> catch all numeric
I wrote:
>
> Exceptions are expected -- we have error handler which is supposed
> to catch them. We have to find what is wrong with error handling.
>
Look at DRAWCFUN.spad, in particular myTrap1 -- it is supposed to
catch all numeric errors.
--
Waldek Hebisch
[E
Martin Rubey wrote:
>
> Martin Rubey <[EMAIL PROTECTED]> writes:
>
> > Oh, I found it:
> >
> > )lisp (sb-ext::set-floating-point-modes :traps nil)
> >
> > this should go into
> >
> > (defun set-initial-parameters()
> > (setf *read-default-float-format* 'double-float))
> >
> > shouldn't i
Martin Rubey <[EMAIL PROTECTED]> writes:
> Oh, I found it:
>
> )lisp (sb-ext::set-floating-point-modes :traps nil)
>
> this should go into
>
> (defun set-initial-parameters()
> (setf *read-default-float-format* 'double-float))
>
> shouldn't it?
no, I just saw that set-initial-parameters
Martin Rubey <[EMAIL PROTECTED]> writes:
> I just checked ecl:
>
> g(x:DFLOAT):DFLOAT == 10^155
> draw(g, -1..1)
>
> fails, while 10^154 seems to work.
The failing routine is norm in CLIP, being called by iClipParametric. I find
the following behaviour:
gcl:
(2) -> f := max()$DFLOAT
(2)
Martin Rubey <[EMAIL PROTECTED]> writes:
> I get the following under sbcl:
>
> (3) -> draw(sin(1/x)*exp(-1/x), x=-10..10, clip==true)
>Compiling function %D with type DoubleFloat -> DoubleFloat
>
>>> System error:
>arithmetic error FLOATING-POINT-OVERFLOW signalled
>
> I guess so
18 matches
Mail list logo
