gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] tan compilation problem


From: Camm Maguire
Subject: Re: [Gcl-devel] tan compilation problem
Date: 07 Aug 2002 11:37:24 -0400

Greetings!

"Vadim V. Zhytnikov" <address@hidden> writes:

> Camm Maguire ÐÉÛÅÔ:
> > Hi Vadim, and thanks for the report!  A fix is always easier than a
> > good report!!
> > 
> Thanks for quick fix! Now it works fine. Actually this new tan
> definition improved some other related things.  For example
> previosly (tan 1) gave some weird number and now it produces
> something sensible and exactly the same as (tan 1.0) which
> we certainly expect. I only still wonder why the old tan defined
> via sin/cos doesn't work properly.
> 

Hmm.  If you can reproduce and report the errant behavior with an old
build, I'll verify that it has been eliminated, and not still present
somewhere in the functions called by number_tan.  Only if you feel
there is still some possibility of bug here.  Right now, I get the
same answer with (/ (sin 1) (cos 1)).


> As for small nonzero values I'm not numerical calculus expert
> but they seems to be OK.  First of all how can we expect to get
> exact zero (cos (/ pi 2)) if (/ pi 2) is not exactly pi/2 (and
> newer will be)?  So it seems that any value will do unless error
> is too big.
> 

Once (/ pi 2) is represented as a float, you are of course right.  But
if gcl had some type analogous to the rational type with which to
represent this number and those similar, then stuff like (equal (/ 1
(sqrt 2)) (cos (/ pi 4))) would return t, etc.  I'm sure maxima has
some facility for this -- I don't know if it really belongs in a lisp
system, though.

So the question is if the following code is useless:

object
number_tan(object x)
{
        object r, c;
        vs_mark;

        c = number_cos(x);
        vs_push(c);
        if (number_zerop(c) == TRUE)
                FEerror("Cannot compute the tangent of ~S.", 1, x);
        r = number_tan1(x);
        vs_reset;
        return(r);
}


Take care,

> 
> > "Vadim V. Zhytnikov" <address@hidden> writes:
> > 
> > 
> >>Hi!
> >>
> >>I've been trying to figure out why Maxima 5.9.0 (CVS) fails to
> >>build on gcl 2.5.0 if the latter is build with --enable-bfd
> >>and it seems to me that I've managed to localize (but not resolve)
> >>the trouble quite well.
> >>
> >>Let's take very simple file test.lsp which
> >>contains two almost trivial function definitions
> >>------- test.lsp ------------------
> >>
> >>(defun mysin (x)
> >>     (declare (type double-float x))
> >>     (sin x))
> >>
> >>(defun mytan (x)
> >>     (declare (type double-float x))
> >>     (tan x))
> >>
> >>-----------------------------------
> >>
> >>I build two saved_gcl images. First with --disable-bfd
> >>and second with --enable-bfd.  When I make
> >>   (compile-file "tests")
> >>Not surprisingly resulting test.o is absolutely the same
> >>for both saved_gcl versions.  nm test.o lists U tan and
> >>U sin among other symbols.
> >>
> >>The difference reveals when I try to load test.o
> >>   (load "test")
> >>
> >>First saved_gcl (no bfd) successfully loads the file but
> >>issues the warning:
> >>   symbol "tan" is not in base ...
> >>Notice that it complains about tan but not about sin.
> >>In spite of successful load mytan doesn't work since
> >>any attempt to evaluate (mytan ...) results in internal
> >>lisp error ("memory may be damaged..." and so on).
> >>On the contrary mysin works fine.
> >>
> >>Second saved_gcl (with bfd) rejects the file with the
> >>error message:
> >>   tan is undefined
> >>   Error: Cannot get relocated section contents
> >>So bfd-enabled saved_gcl is actually smarter
> >>and reveals the problem immediately.
> >>
> >>I think that it is not necessary to say that
> >>if I remove mytan then test.lsp with mysin
> >>works fine for both saved_gcl images.
> >>
> >>And finally problem disappear if I remove
> >>   (declare (type double-float x))
> >>in both function definitions.
> >>
> >>It seems that there is some problem with
> >>tan in GCL. I wonder why it is so different
> >>from sin?
> >>
> >>Best wishes,
> >>
> >>Vadim
> >>
> >>
> >>
> >>-- 
> >>      Vadim V. Zhytnikov
> >>
> >>       <address@hidden>
> >>      <address@hidden>
> >>      <address@hidden>
> >>     <address@hidden>
> >>
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Gcl-devel mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/gcl-devel
> >>
> >>
> > 
> > 
> 
> 
> 
> -- 
>       Vadim V. Zhytnikov
> 
>        <address@hidden>
>       <address@hidden>
>       <address@hidden>
>      <address@hidden>
> 
> 
> 
> 
> 
> 
> 

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