>> 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?

Status: open => fix proposed

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

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...

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.

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