Edit detail for #102 solve(sinh(z)=cosh(z), z) revision 1 of 9

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

From kratt6 Fri Jun 17 08:13:06 -0500 2005
From: kratt6
Date: Fri, 17 Jun 2005 08:13:06 -0500
Subject: Fix
Message-ID: <20050617081306-0500@page.axiom-developer.org>

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?


From kratt6 Fri Jun 17 08:14:03 -0500 2005
From: kratt6
Date: Fri, 17 Jun 2005 08:14:03 -0500
Subject: property change
Message-ID: <20050617081403-0500@page.axiom-developer.org>

Status: open => fix proposed 


From BillPage Mon Oct 17 13:34:27 -0500 2005
From: Bill Page
Date: Mon, 17 Oct 2005 13:34:27 -0500
Subject: Why is "append" written with quotation marks?
Message-ID: <20051017133427-0500@www.axiom-developer.org>

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]

From kratt6 Tue Oct 18 03:53:32 -0500 2005
From: kratt6
Date: Tue, 18 Oct 2005 03:53:32 -0500
Subject: 
Message-ID: <20051018035332-0500@page.axiom-developer.org>

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

From BillPage Tue Oct 18 17:50:00 -0500 2005
From: Bill Page
Date: Tue, 18 Oct 2005 17:50:00 -0500
Subject: "foo"/list is a BOOT construction
Message-ID: <20051018175000-0500@page.axiom-developer.org>

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?

From kratt6 Wed Oct 19 03:20:04 -0500 2005
From: kratt6
Date: Wed, 19 Oct 2005 03:20:04 -0500
Subject: 
Message-ID: <20051019032004-0500@page.axiom-developer.org>

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

From kratt6 Fri Oct 27 06:46:08 -0500 2006
From: kratt6
Date: Fri, 27 Oct 2006 06:46:08 -0500
Subject: fixed in patch 46
Message-ID: <20061027064608-0500@wiki.axiom-developer.org>

Status: fix proposed => closed 

     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, [])

  "append"/[solve1Sys(plist, lvar) for plist in trianglist]

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

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

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