login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit

Submitted by : (unknown) at: 2007-11-17T21:51:30-08:00 (9 years ago)
Name :
Axiom Version :
Category : Severity : Status :
Optional subject :  
Optional comment :

>> Error detected within library code: No identity element for reduce of empty list using operation append

This one and bug #137 can be resolved by using the three-argument form of reduce in SOLVETRA, for example:
     solveList(lexpr:L RE, lvar:L S):L L EQ RE ==
        ans1 := solveRetract(lexpr, lvar)
        not(ans1 case "failed") => ans1 :: L L EQ RE
        lfrac:L Fraction Polynomial RE :=
           [makeFracPoly(expr, lvar) for expr in lexpr]
        trianglist := triangularSystems(lfrac, lvar)
        -- "append"/[solve1Sys(plist, lvar) for plist in trianglist]
        l: L L L EQ RE := [solve1Sys(plist, lvar) for plist in trianglist]
        reduce(append, l, [])

and similarly in all places, where "append"/ is used. Maybe there is an alternative fix, "append"/ does not call reduce, does it?

property change --kratt6, Fri, 17 Jun 2005 08:14:03 -0500 reply
Status: open => fix proposed

Why is "append" written with quotation marks? --Bill Page, Mon, 17 Oct 2005 13:34:27 -0500 reply
Martin, can you explain to me what this function call in the original code is supposed to do:
  "append"/[solve1Sys(plist, lvar) for plist in trianglist]

What it does is easily explained: "foo"/l maps the function foo over the list l. However, it appears that it doesn't use reduce but rather some lisp primitive. It is hard to trace, since it doesn't work in the interpreter. I suppose that it is some leftover of the elder days of spad. In any case, when you grep the algebra directory, there doesn't appear to be a three argument form of this construct, so I propose to (gradually) replace it by reduce everywhere.

Martin

"foo"/list is a BOOT construction --Bill Page, Tue, 18 Oct 2005 17:50:00 -0500 reply
This construct occurs frequently in the BOOT code in src/interp so I guess that this is actually a carry-over from the BOOT language.

In http://wiki.axiom-developer.org/axiom--test--1/src/algebra/Aggcat2Spad reduce is defined as either:

      reduce(fn, v, ident) ==
        val := ident
        for i in minIndex v .. maxIndex v repeat
          val := fn(qelt(v, i), val)
        val

for array-like structures or recursively (for lists):

      reduce(fn, l, ident) ==
        empty? l => ident
        reduce(fn, rest l, fn(first l, ident))

It seems doubtful to me that either of these would be optimized by SPAD to a simple lisp primitive (but I could be wrong). Anyway I agree that it makes more sense to use reduce in the algebra code especially since there is no "/" operation defined in the domain List, although this might introduce more circularity (mutual recursion) in the algebra code.

I wonder if it would work to define the operation:

  "/":((S, R) -> R, A, R) -> R

as a synonym for reduce in List and then recompile most of the algebra code or would SPAD die of embarrassment?

It should work, given that the compiler does not stumble over some bug. However, I don't think it is the right direction to take anyway:

  • The bugs mentioned here won't go away, since you would have to provide the third argument, and
  • I think that reduce is easier to understand for the casual reader.

Concerning the optimization: in an ideal world, reduce would be optimized away. We are not in an ideal world, and we will never be, but we should strive to make it better...

fixed in patch 46 --kratt6, Fri, 27 Oct 2006 06:46:08 -0500 reply
Status: fix proposed => closed

Status: closed => open

This patch was made to Axiom on 10/30/2005. In the current version of Axiom the patch exists. However, the error still occurs.

Fixed in revision 51 of FriCAS --greg, Thu, 20 Dec 2007 08:27:44 -0800 reply
See http://groups.google.com/group/fricas-commit/browse_thread/thread/f5eb34760d0f3721

Do not know exactly what is THETA and more generally what is going here so can not help more.

(this fix affects the compiler, so the LISP code generated)

Category: Axiom Interpreter => Axiom Compiler Status: open => fix proposed

Fixed in OpenAxiom

Status: fix proposed => closed




  Subject:   Be Bold !!
  ( 12 subscribers )  
Please rate this page: