[Top][All Lists]

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

[Axiom-developer] Issue 338

From: Waldek Hebisch
Subject: [Axiom-developer] Issue 338
Date: Tue, 20 Mar 2007 15:34:14 +0100 (CET)

I looked at the issue 338.  It seems that we have extra porblem here.
Axiom allows operators of arity 0, and it looks that for such operators
we would have exactly the same problem of ordering.  I am not sure
if Axiom typechecker allows 0 arity functions here, but assuming
that such functions are allowed we have problem.

It seems taht both problem can be avoided if we disable early exit
from smprep:

diff -u /home/s/test/tt/axiom2/wh-sandbox2/src/algebra/fspace.spad.pamphlet 
--- /home/s/test/tt/axiom2/wh-sandbox2/src/algebra/fspace.spad.pamphlet 
2007-02-07 14:59:29.000000000 +0100
+++ wh-sandbox2/src/algebra/fspace.spad.pamphlet        2007-03-20 
15:21:17.000000000 +0100
@@ -634,7 +634,8 @@
       -- op(arg)**m ==> func(arg)**(m quo n) * op(arg)**(m rem n)
       smprep(lop, lexp, lfunc, p) ==
         (v := mainVariable p) case "failed" => p::%
-        symbolIfCan(k := v::K) case SY => p::%
+        -- symbolIfCan(k := v::K) case SY => p::%
+        k := v::K
         g := (op := operator k)
            (arg := [eval(a,lop,lexp,lfunc) for a in argument k]$List(%))
         q := map(eval(#1::%, lop, lexp, lfunc),

I am still investigating if this is a right fix.  Also smprep looks
inefficient and this change would make it even less efficient than
it is now.

                              Waldek Hebisch

reply via email to

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