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: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] tan compilation problem
Date: Wed, 07 Aug 2002 11:02:54 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

Camm Maguire пишет:
Hi Vadim, and thanks for the report!  A fix is always easier than a
good report!!

I've just committed a fix -- please try it out.  The unoptimized
version of tan simply divided cosine into sin, and did not reference
the tan of libm at all, leading to the undefined symbol when the
optimizer replaced our boxed version with the system tan.

I've implemented a new version, which seems just as good as the old,
but did reveal some oddities in gcl's trig stuff.  For example, (cos
(/ pi 2)) is small but not zero.  The original number_tan protected
the tan call by a check that the cosine was not zero.  I left this in,
but it never seems to kick in as cosine is never exactly zero.  I
don't know off the top of my head how to implement the exact trig
results other than simply enumerating them.  Is this important?
Anyone know the right thing to do?

Take care,


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.

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.


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








reply via email to

[Prev in Thread] Current Thread [Next in Thread]