Custom Query (1030 matches)

The sqrt, log and atan functions are failing over significant portions of their domain (particularly for rational or complex rational arguments), even when it is entirely reasonable that a good result should be returned. Some typical examples are:

(sqrt (expt 10 47)) => 3.1622778E+23 ;CCL errors
(sqrt (/ (expt 10 47) 3)) => 1.8257418E+23 ;CCL errors
(sqrt (complex (expt 10 46) (expt 10 47))) => #C(2.3505187E+23 2.12719E+23) ;CCL errors
(sqrt (complex most-positive-short-float most-positive-short-float)) => #C(2.0267142E+19 8.394926E+18) ;CCL errors

(log (expt 10 -66)) => -151.97063 ;CCL errors
(log (- (expt 10 66))) => #C(151.97063 3.1415927) ;CCL returns wrong type (double, not single)
(log (complex (expt 10 65) (expt 10 66))) => #C(151.9756 1.4711276) ;CCL errors
(log (complex (expt 10 -65) (expt 10 -66))) => #C(-149.66307 0.09966865) ;CCL errors
(log 8.0d0 2) => 3.0D0 ;CCL returns wildly inaccurate result
(log #C(0.0 1.0) 0) => #C(0.0 0.0) ;CCL returns wrong type (integer)

(atan (expt 10 46) (expt 10 47)) => 0.09966865 ;CCL errors
(atan (expt 10 -46) (expt 10 -47)) => 1.4711276 ;CCL returns zero

I'm attaching a file that demonstrates how these could all be fixed by making changes to CCL's sqrt, log, log-e and atan functions (but the changes may not be implemented in the most efficient way). Making these fixes would also have a knock-on effect and correct dependent infelicities in both the arg and phase functions (which aren't noted above).

I have a shiny new Linux box running Ubuntu 11.10.

On installing CCL, everything appears OK when I do the rebuild-ccl step. However, in the resulting Lisp image, all math functions (i.e. log and trig functions) are no longer available: all attempts to use such give a "Can't resolve foreign symbol" error.

I've discovered that a 'workaround' is to manually load libm using open-shared-library; the load is remembered through invocations of save-application. However, I'm pretty sure this shouldn't be necessary.

I've found that this behaviour occurs with the latest versions of both CCL 1.6 and 1.7.

I built a hash table with keys that were simple cons cells of the form

(<type> . <item>)

I had a few <type>s, and lots of atomic <item>s (in particular, strings) for each <type>. The performance was very bad.

Investigation showed that ccl::compute-hash-code was returning a hash code that depended only on the <type> but not on the <item>, meaning that hash table look up was degenerating into a linear search.

Example:

(setq h (make-hash-table :test #'equal))

Then

(ccl::compute-hash-code h '(type . "foo") nil)
(ccl::compute-hash-code h '(type . "bar") nil)
(ccl::compute-hash-code h '(type . "baz") nil)
(ccl::compute-hash-code h '(type . pi) nil)
(ccl::compute-hash-code h '(type . nil) nil)

all return exactly the same results.