[Openmcl-devel] Maxima + Clozure on Windows

Mon Mar 30 01:42:30 PDT 2009

One thing I found in  Maxima (a few months back) as a problem is the  
following (maybe it also is a problem here):

The code generated by the Fortran to CL translator is not generally  
portable CL code. It includes a few assumptions that are only true in  
the Lisp the translator was running in. Namely types. One simply can't  
translate the code once and use it in any Common Lisp. The code really  
needs to be translated by the Lisp Maxima is supposed to be running  
in. One needs to make sure for CCL that the Fortran to CL translator  
translates all code in CCL before testing/using it.

The source of this problem is that the translator includes type  
declarations into the CL source. It does generate these type  
declarations based on information that is valid in the current Lisp it  
is running in. Unfortunately type declarations have different ranges,  
have different effects in different CL and different meanings. FIXNUM  
for example may have different ranges. Floats are slightly different.  
If typed CL code is compiled by another Lisp compiler than the Lisp  
compiler might have a different interpretation for these types. It  
would help to let the compiler generate type declaration code that is  
valid across different implementations, but currently that is not the  
case. At least last I looked a few month back. For example in the  
Maxima source I was using the following header was included:

;;; Compiled by f2cl version 2.0 beta Date: 2007/05/04 17:29:50
;;; Using Lisp CMU Common Lisp Snapshot 2007-05 (19D)
;;;
;;; Options: ((:prune-labels nil) (:auto-save t) (:relaxed-array-decls  
t)
;;;           (:coerce-assigns :as-needed) (:array-type ':simple-array)
;;;           (:array-slicing nil) (:declare-common nil)
;;;           (:float-format double-float))

So the translator was running in CMUCL and I found several  
assumptions, that were not right for the Lisp I was using.

Not sure if that is also the case here, but I found the translator to  
be something that the Maxima folks should look into.

Regards,

Rainer Joswig

Am 30.03.2009 um 06:37 schrieb Gary Byers:

> Barton (and anyone else who might know):
>
> 1) is doing
>
> bessel_j(3,2.0);
>
> in Maxima equivalanet to doing
>
> (maxima::bessel-j 3 2.0)
>
> in lisp ?
>
> 2) is the correct answer approximately 0.129 ?  (That's what I get
> in an x86-64 CCL.)
>
> If so, then we may have a reproducible test case that demonstrates
> at least one problem; the bad news is that the problem is likely
> in the Maxima function SLATEC::DBESJ. which seems to have been
> automatically translated from Fortran and is rather large (about 17KB
> of source, about 32KB of object code.)  It might be necessary to
> sort of whack at that from both ends in order to expose the bug.
>
> (So yes, simple reproducible test cases are ideal, but not always
> possible.  When they are possible they're much appreciated and
> when they aren't, any steps that can be taken to simplify things
> will likely be helpful.  In this case - where it looks like the
> problem's in SLATEC::DBESJ - it may not be easy to simplify the
> function much, but it'd be helpful to know if we're looking in
> the right place.)
>
>
> On Sat, 28 Mar 2009, R. Matthew Emerson wrote:
>
>> If bugs in CCL are causing Maxima to fail some tests, I'm interested
>> in fixing those bugs.
>>
>> Test cases (in lisp) that demonstrate those bugs would help me do  
>> that.
>>
>> Unfortunately, I'm not familiar enough with Maxima or its build/test
>> infrastructure in order to track down any bugs from the problems you
>> mention in your message.
>>
>>
>> On Mar 26, 2009, at 5:46 PM, Barton Willis wrote:
>>
>>>
>>> I'm a developer for the Maxima computer algebra system. Today I  
>>> tried
>>> compiling and running Maxima using Clozure CL + Windows XP (32bit):
>>>
>>> The tests rtest14, rtest15, and rtest_gamma abort; the rest of the
>>> tests pass. Deleting these three tests, the run times are: (SBCL on
>>> Windows is experimental.)
>>>
>>> SBCL 1.0.22 109.9 seconds,  6.105 seconds GC   9 850 167 496 bytes
>>> consed
>>> Clozure CL  162.0 seconds, 28.063 seconds GC   3 745 442 024 bytes
>>> allocated
>>>
>>> Using Clozure CL, the share_testsuite reports some errors, but it
>>> finishes:
>>>
>>> Errors found in rtest_numericalio.mac, problems: (50 52 57)
>>> Errors found in testprintf.mac, problems: (27 54)
>>> Error found in test_abs_integrate.mac, problem: (75)
>>> Error found test_pochhammer.mac, problem: (29)
>>>
>>> I used a 2.13 GHz, 2 GB RAM, Core 2 CPU. One bug that I know is
>>>
>>> (%i1) bessel_j(3,2.0);
>>>
>>> (%o1)                                 0.0
>>> (%i2) build_info();
>>>
>>> This bug shows up in the Maxima regression tests.
>>>
>>> Maxima version: 5.17post
>>> Maxima build date: 13:56 3/26/2009
>>> host type: @host@
>>> lisp-implementation-type: Clozure Common Lisp
>>> lisp-implementation-version: Version 1.3-dev-r11537M-trunk
>>> (WindowsX8632)
>>>
>>> Let me know if you have questions; thanks for making Clozure CL run
>>> under
>>> XP.
>>>
>>> Barton Willis
>>> Professor of Mathematics
>>> University of Nebraska at Kearney
>>>
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

Rainer Joswig, Hamburg, Germany
http://lispm.dyndns.org/
mailto:joswig at lisp.de