[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] util.ht
From: |
root |
Subject: |
[Axiom-developer] util.ht |
Date: |
Sun, 20 Jul 2003 15:13:26 -0400 |
The i-output.boot.pamphlet file has been modified to change the test slightly.
We add a simple fudge-factor as a temporary measure until log10 computes
correct values. The code was:
u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
and is now:
u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR ((LOG10 u) + 0.0000001)
The attached diff:
===========================================================================
--- i-output.boot.pamphlet Sun Jul 20 15:10:37 2003
+++ i-output.boot.pamphlet.tpd Sun Jul 20 15:12:16 2003
@@ -9,6 +9,26 @@
\eject
\tableofcontents
\eject
+\section{GCL_log10_bug}
+In some versions of GCL the LOG10 function returns improperly rounded values.
+The symptom is:
+\begin{verbatim}
+(24) -> [1000]
+ (24) [100]
+\end{verbatim}
+The common lisp failure can be shown with:
+\begin{verbatim}
+(25) -> )lisp (log10 1000)
+Value = 2.9999999999999996
+\end{verbatim}
+This previous boot code was:
+\begin{verbatim}
+ u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
+\end{verbatim}
+and should be restored when the GCL bug is fixed.
+<<GCL_log10_bug>>=
+ u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR ((LOG10 u) + 0.0000001)
+@
<<*>>=
-- See LICENSE.AXIOM for Copyright
@@ -840,7 +860,7 @@
negative := 0
-- Try and be fairly exact for smallish integers:
u = 0 => 1
- u < MOST_-POSITIVE_-LONG_-FLOAT => 1+negative+FLOOR LOG10 u
+<<GCL_log10_bug>>
-- Rough guess: integer-length returns log2 rounded up, so divide it by
-- roughly log2(10). This should return an over-estimate, but for objects
-- this big does it matter?