|
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>
[Prev in Thread] | Current Thread | [Next in Thread] |