[Top][All Lists]
[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
Re: [Gcl-devel] tan compilation problem, Camm Maguire, 2002/08/06