gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] solve test on allegro CL maxima


From: Richard Fateman
Subject: [Gcl-devel] solve test on allegro CL maxima
Date: Thu, 21 Mar 2002 10:30:36 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1

(C23)  W:SOLVE([4*X^2-Y^2 = 12,X*Y-X = 2],[X,Y])
;

Error: STORE failed -- can't find array for #<macro AFIXN @ #x203d5f12>

The backtrace in Allegro says...

(ERROR "STORE failed -- can't find array for ~S" #<macro AFIXN @ #x203d5f12>)
 ->(STORE-INTERNAL-2D #<macro AFIXN @ #x203d5f12> 1 ...)
   (CPTOMF 5 (#:X1374 3 1 ...) ...)
   (CPBQ1 (#:X1374 3 1 ...) 3)
   (CPBER1 (#:X1374 4 1 ...))
   (CHOOZP (#:X1374 4 4 ...))
   (FACT5 (#:X1374 4 4 ...))
   (FACTOR72 (#:X1374 4 4 ...))
   (FACTOR1972 (#:X1374 4 4 ...))

So it is actually in the polynomial factoring program.
I think this may be trying factoring over Gaussian integers.

This may or may not be related to GCL problems.
For what it is worth, the commercial macsyma gives the
following (better, in my view) answer:
[[x = 2, y = 2], [x = root_of(4 * x^3 + 8 * x^2 + 3 * x + 2), y = ((x + 2)/x)]]

RJF

Camm Maguire wrote:

Greetings!


"Vadim V. Zhytnikov" <address@hidden> writes:


Some more facts about the problem I was able
to get lately:

1) The problem is not due to recent solve changes.
It exists with older solve as well. I'm not surprised but
I verified it explicitly.

2) The problem is not due to recent GCL updates.
It shows up both with GCL 2.5.0 (latest CVS) and
old GCL 2.3.8.

3) When I start tracing some functions (using lisp's trace)
in which error occurs the problem magically disappears!
This is very bad and makes detection of  the problem's
origin rather hard. Something really nasty is
happening to variables binding.



Yes, please see my other post about similar mysterious behavior which
I feel arises from the same malady.  to this list, I might also add
again the note that certain catastrophic problems on m68k Linux were
due to missing casts in the function call pointer routines.

This is making me conclude that we are ready for a straightforward but
tedious task for reworking all of the C files to compile with no
warnings under -Wall.  A useful tool for this is protoize, for those
who might not be aware.  at the same time, we ought to modernize the
varargs paramters specifications, and use ansi C function
declarations.  We probably will also have to make minor modifications
to the lisp compiler to get the generated C code it produces into the
same form.
Any suggestions as to how to organize this task is appreciated.  I
feel very comfortable with plodding along in this direction, but as by
now is obvious, my time is limited, and it will take a considerable
amount of time.  I hope to be able to clear a day for gcl by sometime
next week.

Take care,


Vadim



Camm Maguire wrote:


Greetings!

"Vadim V. Zhytnikov" <address@hidden> writes:


This is a multi-part message in MIME format.
--------------DCA8AA4BB1B26CA471011469
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit

Greetings!

Finally I located the problem with solve test
on GCL Maxima build with new build system.

Does this error disappear with the old build system?


If you load("test.lisp"); the following file
-------- tests.lisp ---------
(sloop for v in '("rtest.mac")
 do
 (test-batch v)
)
-----------------------------
with
------- rtest.mac ----------
W:SOLVE([4*X^2-Y^2 = 12,X*Y-X = 2],[X,Y]);
[[X = 2,Y = 2],
[X = 0.5202594388652008*%I-0.1331240357358706,
 Y = 0.07678378523787777-3.608003221870287*%I],
[X = -0.5202594388652008*%I-0.1331240357358706,
 Y = 3.608003221870287*%I+0.07678378523787777],
[X = -1.733751846381093,Y = -0.1535675710019696]];
-----------------------------
in GCL Maxima you will get an error.
But it is enough to change sloop variable v
to something different to get correct answer!
On Clisp everything works fine independently
on sloop variable name.


Well, unfortunately, I suspect gcl here.  Which version?  What about
different input functions?  Can you go through the lisp debugger and
isolate the lisp error?  I'd really appreciate it if you could get
this into a form where a simple (as possible) input file into gcl
shows the mistake.  Otherwise, we can of course build the gcl with -g
and step through the stack in gdb, but I'm sure its quite huge.


I'm perfectly sure that the problem has nothing to do
with recent solve changes. It is not clear yet
which part is to be blamed for the problem -
new build system or GCL. The case require
more thorough testing.

Thanks again for your work here, Vadim!


Vadim



--

[ Vadim V. Zhytnikov  <address@hidden>  <address@hidden> ]


--------------DCA8AA4BB1B26CA471011469
Content-Type: application/x-gzip;
name="solve.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="solve.tar.gz"

H4sIAM/8eTwAA+3UXWvCMBQG4N6uvyIIY62z5SQnX052uYvBYBeDrUUUnG5M0Cna+fsXKzgG
buKF+4D3uUjT9JDTkJxUT8sqn4yX8+h4SBJZrSMKnDWfnmtSUUROs2WnNXOIl45lJOiI/7T1
tqwGCyGi1WA0nn4Tt+/7P5UsJ7PZXDzPFmIlxq/iLGksqvWZmA6GjTQ+EaNZaJL1UPY4qIYv
YpXGafyl314PHGa72UfMsa/+tVWb+leGnLR1/UuF+v8JDxd3tzf3V0lXN4u+ysq+EpdCqlbR
LLMidFWv1S1aZS/txN1uPdAqN8OxqN8pN4qUaWv23oYu+ebpdUa5ZJZKExvHxjuyIV6UdXzY
e+fZeaNC44KMc0ueiJWSIVR5F6bYJsgOzbBrtvMdaT8yyNwxOyO9tuwltble4zqFYWOdceEA
y7Zt216vgxsOAAAAAAAAAAAAAAAAAAAA/ph3Wq1t4QAoAAA=
--------------DCA8AA4BB1B26CA471011469--





--
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

_______________________________________________
Gcl-devel mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gcl-devel

--
[
[    Vadim V. Zhytnikov
[
[     <address@hidden>
[   <address@hidden>
[    <address@hidden>
[












reply via email to

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