Embedding REDUCE

322 views
Skip to first unread message

kp

unread,
Sep 26, 2012, 8:40:05 PM9/26/12
to pure...@googlegroups.com

After a recent discussion referring to algebraic algorithms in Pure (Buchberger, Risch, ...) I recollected having embedded REDUCE into Python via ctypes (some years ago), what wasn't very useful because Python isn't so symbolic (save sympy) . Reduce is a powerful, general CAS, now providing an improved procedural C interface (in the CSL version), so - to be short - I tried and it works. Implementing the low level interface was a cinch. All is documented in the attached files for reproducing.
I think that enhancing Pure with this algebraic power weapon could be of general interest because Pure is predestined to deal with this kind of objects (Reduce's rlisp language is more or less infix STD-LISP). Of course, there is some (moderate) work to do, especially  for the high level interface, but one has not to reinvent the wheel (about 40 man-years in Reduce :)
Any feedback appreciated.
Kurt

p.s. note the awesome Pure texmacs interface in 0.56 (exported pdf).
- http://www.reduce-algebra.com/
- http://reduce-algebra.svn.sourceforge.net/viewvc/reduce-algebra/trunk/csl/cslbase/
-- see proc.h and driver.c for the proc interface description
- http://reduce-algebra.svn.sourceforge.net/viewvc/reduce-algebra/trunk/csl/new-embedded/
-- this is the new-embedded directory
       
pure_reduce.txt
pure_reduce.pdf

Albert Graef

unread,
Sep 27, 2012, 8:27:38 AM9/27/12
to pure...@googlegroups.com
Hi Kurt,

On 09/27/2012 02:40 AM, kp wrote:
> After a recent discussion referring to algebraic algorithms in Pure
> (Buchberger, Risch, ...) I recollected having embedded REDUCE into
> Python via ctypes (some years ago), what wasn't very useful because
> Python isn't so symbolic (save sympy) . Reduce is a powerful, general
> CAS, now providing an improved procedural C interface (in the CSL
> version), so - to be short - I tried and it works. Implementing the low
> level interface was a cinch. All is documented in the attached files for
> reproducing.

That's very cool! Thanks for the detailed walkthrough, I'll give it a
try asap, so that we can start discussing what high-level interface we want.

We've been tossing around the idea to interface to some CAS on various
occasions in the past. I don't think that we considered the venerable
REDUCE before, though; I wasn't aware that it has a C interface these days.

> I think that enhancing Pure with this algebraic power weapon could be of
> general interest because Pure is predestined to deal with this kind of
> objects (Reduce's rlisp language is more or less infix STD-LISP). Of
> course, there is some (moderate) work to do, especially for the high
> level interface, but one has not to reinvent the wheel (about 40
> man-years in Reduce :)

Exactly. While it would be an interesting project to reimplement some of
these algorithms in Pure, providing all of them simply wouldn't be
feasible. Also, these codes have been written and optimized by real
wizards and tested to death already. It would be silly not to make good
use of them.

Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.G...@t-online.de, a...@muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag

kp

unread,
Sep 27, 2012, 11:57:33 AM9/27/12
to pure...@googlegroups.com
Hello Albert,

I'm glad to hear that there is some interest for this (it's not without
selfishness), as I could really benefit from such an option.

Am 27.09.2012 14:27, schrieb Albert Graef:
> Hi Kurt,
>
> On 09/27/2012 02:40 AM, kp wrote:

> Exactly. While it would be an interesting project to reimplement some of
> these algorithms in Pure, providing all of them simply wouldn't be
> feasible. Also, these codes have been written and optimized by real
> wizards and tested to death already. It would be silly not to make good
> use of them.
>

That's just what I think! There's still a lot one can build upon using
Pure syntax, and maybe some days there exists pure "Pure" algorithms ...

Some remarks:
- my posting is only a crude hack of course, merely to prove that it may
work. As I probably mentioned earlier, my C/C++ knowledge is rather
limited, so the low level proc.h -> proc.pure should be rewritten in a
workmanlike manner (I simply substituted the typedef's and didn't make
any use of the callbacks at all, i.e. I used NULL, meaning
stdin/stdout). I have no clue anyway how to do it, but the callback
aren't really necessary for the RPN interface.

- The "display" function is a straightforward translation of the C code
in the driver.c file and may give a hint how to exchange Pure
expressions back and forth to Reduce via RPN. BTW, is (eval "x") the
standard method to convert strings to symbols? I suppose a robust
coercion function Pure<->RPN should belong to the low level.

- There's a lot of functions and packages in Reduce, so I collected
(some times ago) all the available information into a reference manual
(one function per page, pdf attached), because the official user manuals
are written more in a descriptive way, hence it may be hard to find a
function reference sometimes. (I've grubbed out the tex sources too, so
if somebody is interested ...)

- In principle, Pure may then define it's own naming scheme so that
Reduce isn't visible at all, because all the rlisp functionality is
already inside Pure.

- Another point is the building of the reduce image. The whole reduce
SVN tree is huge, even the "trunk" alone is still very large. I wasn't
able yet to sort out what files/subdirectories are really necessary to
build the library - and the image file (maybe "csl" is enough, but
"cslbase" and "new-embedding" definitively not). Fact is, there's no
need to build the ordinary reduce tree via configure, and it's sure that
there is no need neither of the foxkit nor of the PSL part.
I'll try again

Kurt





redhelp.pdf

Albert Graef

unread,
Sep 27, 2012, 4:22:01 PM9/27/12
to pure...@googlegroups.com
On 09/27/2012 05:57 PM, kp wrote:
> I'm glad to hear that there is some interest for this (it's not without
> selfishness), as I could really benefit from such an option.

Yay, I got it up and running here! :)

One burning question, though: Does this really have to be built as a 32
bit binary? As I'm on a x86_64 Linux system here, I've compiled the dll
as a shared 64 bit ELF library instead; do you know whether this will
cause trouble? It *seems* to work fine, but I only tried it with your
basic example so far.

> - my posting is only a crude hack of course, merely to prove that it may
> work.

That's all right, you took the first big hurdle while everybody else was
talking. :) The rest now is just wrapping it up in a nice package, I can
help with that.

> - The "display" function is a straightforward translation of the C code
> in the driver.c file and may give a hint how to exchange Pure
> expressions back and forth to Reduce via RPN.

This shouldn't be a big deal, I'll have a look at it asap.

> BTW, is (eval "x") the
> standard method to convert strings to symbols?

You probably want to use 'val' instead to prevent evaluation; 'val'
returns a quoted result. However, in the runtime library there are more
low-level (and faster) ways to create a quoted symbol from a string in a
direct fashion:

> extern int pure_sym(void *s);
> extern expr *pure_quoted_symbol(int tag);
> pure_quoted_symbol(pure_sym("x"));
x

I don't recall whether these are already wrapped in the prelude in some
way, I guess not.

> - There's a lot of functions and packages in Reduce, so I collected
> (some times ago) all the available information into a reference manual

Thanks a lot, that will be *very* helpful! Last time I've seen REDUCE in
action was on a Multics system, so there's some learning ahead of me.

> - Another point is the building of the reduce image. The whole reduce
> SVN tree is huge, even the "trunk" alone is still very large.

Let's worry about that later, when we got this thingy working in Pure.
;-) This is just a maintenance problem, it might be awkward but it's
certainly doable. If all else fails, we might just distribute the
Windows and ELF binaries in some way, and we can talk to Ryan and Yuan
about Mac and FreeBSD support.

kp

unread,
Sep 27, 2012, 6:44:54 PM9/27/12
to pure...@googlegroups.com
Am 27.09.2012 22:22, schrieb Albert Graef:

>
> Yay, I got it up and running here! :)
>

Ah, very good news!

> One burning question, though: Does this really have to be built as a 32
> bit binary? As I'm on a x86_64 Linux system here, I've compiled the dll
> as a shared 64 bit ELF library instead; do you know whether this will
> cause trouble? It *seems* to work fine, but I only tried it with your
> basic example so far.

I don't think so. While travelling I have access to Linux via VirtualBox
(32bit) only. The last official Reduce releases (April 2011) are
availabele as 32 and 64 bit versions (even for Windows), so one may
conclude ...

>> BTW, is (eval "x") the
>> standard method to convert strings to symbols?
>
> You probably want to use 'val' instead to prevent evaluation; 'val'
> returns a quoted result.

Thank you. I ought to have known that :(

>> - There's a lot of functions and packages in Reduce, so I collected
>> (some times ago) all the available information into a reference manual
>
> Thanks a lot, that will be *very* helpful! Last time I've seen REDUCE in
> action was on a Multics system, so there's some learning ahead of me.
>

well,well,... Honeywell, as far I can remember, that's amazing :)

>> - Another point is the building of the reduce image. The whole reduce
>> SVN tree is huge, even the "trunk" alone is still very large.
>
> Let's worry about that later, when we got this thingy working in Pure.
> ;-) This is just a maintenance problem, it might be awkward but it's
> certainly doable. If all else fails, we might just distribute the
> Windows and ELF binaries in some way, and we can talk to Ryan and Yuan
> about Mac and FreeBSD support.

Yes, you're right indeed.

Kurt

kp

unread,
Sep 28, 2012, 9:42:10 AM9/28/12
to pure...@googlegroups.com

I did several examples from the manual, no problems at all. A
non-trivial one is attached.

citation: "Non-linear equations are solved using the Groebner basis
package. Users should note that this can be quite a time consuming
process."

that was "once upon a time" ... I noticed no delay.

The interface seems quite intuitive, like as in a interactive session.
The noisy output can be caught by r/w callbacks (error messages are
prefixed with *****).

Kurt





ex_solve.pure
ex_solve.pdf

Albert Graef

unread,
Sep 28, 2012, 8:56:42 PM9/28/12
to pure...@googlegroups.com
On 09/28/2012 03:42 PM, kp wrote:
> I did several examples from the manual, no problems at all. A
> non-trivial one is attached.

Thanks, works fine over here, too. BTW, what is an arbint? I looked it
up in the ref manual, but couldn't make any sense of the explanation.

> citation: "Non-linear equations are solved using the Groebner basis
> package. Users should note that this can be quite a time consuming
> process."
>
> that was "once upon a time" ... I noticed no delay.

I guess that this depends on how big your problems are. ;-) But of
course our PCs are much faster now than the big iron of old.

> The interface seems quite intuitive, like as in a interactive session.

Well, depends on who you ask. :) Anyway, I made a first stab at
providing a more convenient interface, see below.

> The noisy output can be caught by r/w callbacks (error messages are
> prefixed with *****).

The amount of gc noise can also be controlled separately with
PROC_gc_messages (also wrapped in the proposed API).

Ok, attached you can find a beefed-up version of the interface which
provides some automatic marshalling between Pure and REDUCE data to make
things more convenient (see the "high-level interface" at the end of the
script). There's still a lot missing there; watch out for all the
XXXTODO and XXXFIXME labels. But it's a start. Here's how you use this
stuff (see also the attached example):

> using reduce;
> reduce_init "reduce.img" {"-v"};

Codemist Standard Lisp 6.03 for generic:generic: Sep 27 2012
Created: Thu Sep 27 20:37:18 2012

Reduce (Free CSL version), 27-Sep-12 ...
Memory allocation: 12 Mbytes
()
> reduce_verb 0;
0
> simplify (df ((x+1)^2) x);
2*x+2
> simplify (df ((x+5)^3) x);
3*x^2+30*x+75
> simplify (rhs (first (solve (log(sin(x+3))^5 == 8))));
2*arbint 5*pi+asin (e^(2^(3/5)*cos (2*pi/5))/e^(2^(3/5)*sin
(2*pi/5)*i))+-3

The basic data types should all be mapped properly. Function calls are
represented in the standard curried form on the Pure side. Alas, I see
no way to get REDUCE to return bigint and non-scalar results. Also, I'm
having trouble with double values which produce strange results like the
following:

> simplify 1.0;
1
> simplify 1.2;
val ":rd:":"675539944105574":-49
> simplify (1.2*3.0);
val ":rd:":"1013309916158362":-48

Passing doubles from Pure to REDUCE seems to work all right, but there
are these improper lists in the REDUCE output (the val's are supposed to
be symbols, but of course ":rd:" doesn't parse as a Pure symbol). Maybe
PROC_make_printable has trouble with floatnums?

So I'm afraid we're not quite there yet. But maybe you have an idea
what's going on there.

Enjoy :)
reduce.pure
reduce_examp.pure

Albert Graef

unread,
Sep 28, 2012, 9:37:41 PM9/28/12
to pure...@googlegroups.com
On 09/29/2012 02:56 AM, Albert Graef wrote:
> Thanks, works fine over here, too. BTW, what is an arbint? I looked it
> up in the ref manual, but couldn't make any sense of the explanation.

Think I got it now. It's an integer parameter in a solution which can be
chosen arbitrarily, right? Maybe we can invent some prettier
representation for that on the Pure side?

John Cowan

unread,
Sep 28, 2012, 9:53:26 PM9/28/12
to pure...@googlegroups.com
Albert Graef scripsit:

> Think I got it now. It's an integer parameter in a solution which can be
> chosen arbitrarily, right? Maybe we can invent some prettier
> representation for that on the Pure side?

A series of terms in normal form "arbint 1", "arbint 2", etc. would make
sense to me. Reduce generates a new arbint(n) every time it needs one
in order to show that they aren't all equal.

--
One art / There is John Cowan <co...@ccil.org>
No less / No more http://www.ccil.org/~cowan
All things / To do
With sparks / Galore --Douglas Hofstadter

kp

unread,
Sep 28, 2012, 10:38:48 PM9/28/12
to pure...@googlegroups.com

What a pace!
It works, wonderful!! It's a start++.

>
>> The interface seems quite intuitive, like as in a interactive session.
>
> Well, depends on who you ask. :) Anyway, I made a first stab at
> providing a more convenient interface, see below.

... the idea was of course: the command sequence to push onto the stack
is like that in the interactive session :) There is indeed a lower level
in Reduce, the "standard quotient" called *SQ - what you get when
omitting the PROC_make_printable. See chapter 4 in the attachment.

Reduce has a lot of switches to control formatting and output. I've to
lookup as I have forgotten most of them (PROC_set_switch).

I noticed too that only scalars are returned properly, that's why I used
"rhs first" (righthand-side of the first solution) in the "solve"
example. Maybe I have to try out without make_printable if the result is
a list of equations/solutions.

I tried integration
> simplify (int (x^2) x);
x^3/3
> simplify (int (x^2.0) x);
x^3/3
> simplify (int (x^2.09) x);
100*x^(9/100)*x^3/309 ??????
simplify (int (sin x) x);
-cos x
> simplify (int (exp (2*x) ) x);
e^(2*x)/2 :)

I'm sure we find workarounds for all this issues. Moreover there are
still other options to try, like PROC_lisp_eval, PROC_get_raw_value.
Eventually we can contact Arthur Normann , he has been always very helpful.

BTW I found this in proc.h:
<<In due course I may support floating point values
* and big numbers, but release 1 of those code concentrates on the
basics.>>

<< if there is any functionality that you need PLEASE ask
* me to put in a cleaner abstraction to support it.>>


It's very exciting.
Kurt



P.S. (

ARBINT OPERATOR

The operator ARBINT is used to express arbitrary integer parts of an
expression, e.g. in the result of [see SOLVE.] when [*note
ALLBRANCH::.] is on.

EXAMPLES:

____________________________________________________________


solve(log(sin(x+3)),x);

{X=2*ARBINT(1)*PI - ASIN(1) - 3,
X=2*ARBINT(1)*PI + ASIN(1) + PI - 3}

____________________________________________________________




reduce_primer.pdf

kp

unread,
Sep 28, 2012, 10:52:56 PM9/28/12
to pure...@googlegroups.com
Am 29.09.2012 03:53, schrieb John Cowan:
> Albert Graef scripsit:
>
>> Think I got it now. It's an integer parameter in a solution which can be
>> chosen arbitrarily, right? Maybe we can invent some prettier
>> representation for that on the Pure side?
>
> A series of terms in normal form "arbint 1", "arbint 2", etc. would make
> sense to me. Reduce generates a new arbint(n) every time it needs one
> in order to show that they aren't all equal.
>

"arbint n"? ... seems a little bit waste of space to me ... but why not?
What about sacrificing a prefix symbol? Though, there aren't many left,
I know :)
Kurt


Albert Graef

unread,
Sep 29, 2012, 4:05:54 AM9/29/12
to pure...@googlegroups.com
On 09/29/2012 02:56 AM, Albert Graef wrote:
> > simplify 1.2;
> val ":rd:":"675539944105574":-49
> > simplify (1.2*3.0);
> val ":rd:":"1013309916158362":-48

It's actually rather simple, the notation is also described in the
chapter you pointed to in your latest attachment:

> 675539944105574*2^-49;
1.2
> 1013309916158362*2^-48;
3.6

It's easy to add support for that, along with :gi:, :gr:, :rn: etc.

Also, it seems that the C API returns bigints as a simple string:

> simplify ('(30^30));
"205891132094649000000000000000000000000000000"
> pow 30 30;
205891132094649000000000000000000000000000000L

So we got that covered as well.

Which leaves us with the non-scalar results. Leaving out the call to
PROC_make_printable doesn't help, I tried that already. You still get
the same error from REDUCE:

***** solve(log(sin(x + 3)) =8) invalid as scalar

Maybe there's a switch for that? I'll have to go and read the manual now. :)

Albert Graef

unread,
Sep 29, 2012, 4:40:44 AM9/29/12
to pure...@googlegroups.com
On 09/29/2012 04:38 AM, kp wrote:
> Reduce has a lot of switches to control formatting and output. I've to
> lookup as I have forgotten most of them (PROC_set_switch).

Yeah, that should be available in the high-level API as well. What about
PROC_load_package, is that needed in applications, too?

> I tried integration [...]
> 100*x^(9/100)*x^3/309 ??????

Well, considering that REDUCE prefers exact results, that result is
certainly correct, if somewhat convoluted. Maybe REDUCE wants to split
off integer powers of unknowns by default? In any case, it isn't be a
big deal to take apart the standard quotient form and further simplify
it on the Pure side, if desired.

> BTW I found this in proc.h:
> <<In due course I may support floating point values
> * and big numbers, but release 1 of those code concentrates on the
> basics.>>

I read that, too. But we got that sorted out now and it's easy to deal
with this in Pure land, so we don't have to go bug Arthur Normann with
it. :)

> P.S. (
>
> ARBINT OPERATOR
>
> The operator ARBINT is used to express arbitrary integer parts of an
> expression, e.g. in the result of [see SOLVE.] when [*note
> ALLBRANCH::.] is on.

I had read that as well, but at first had no idea what it's talking
about. It might be better to word that as "integer parts of an
expression which can be chosen arbitrarily".

> "arbint n"? ... seems a little bit waste of space to me ... but why not?
> What about sacrificing a prefix symbol? Though, there aren't many left,
> I know

We still got all of Unicode. :) How about Greek letters? E.g., the
arbints might be denoted α1, α2, etc., likewise the arbcomplex values as
ζ1, ζ2 etc. These are valid identifiers in Pure, so no trouble with that
(unless you're running on an ancient system which doesn't support Unicode).

kp

unread,
Sep 29, 2012, 9:58:56 AM9/29/12
to pure...@googlegroups.com
Am 29.09.2012 10:05, schrieb Albert Graef:
> On 09/29/2012 02:56 AM, Albert Graef wrote:
>> > simplify 1.2;
>> val ":rd:":"675539944105574":-49
>> > simplify (1.2*3.0);
>> val ":rd:":"1013309916158362":-48
>
> It's actually rather simple, the notation is also described in the
> chapter you pointed to in your latest attachment:
>
> > 675539944105574*2^-49;
> 1.2
> > 1013309916158362*2^-48;
> 3.6
>
> It's easy to add support for that, along with :gi:, :gr:, :rn: etc.
>
> Also, it seems that the C API returns bigints as a simple string:

Yes, there's a remark in the comment to PROC_push_string:
* big integers can be almost any size and are denoted here by strings.
PROC_push_big_integer("-12345678901234567890");

>
> > simplify ('(30^30));
> "205891132094649000000000000000000000000000000"
> > pow 30 30;
> 205891132094649000000000000000000000000000000L
>
> So we got that covered as well.
>

I see, excellent.

> Which leaves us with the non-scalar results. Leaving out the call to
> PROC_make_printable doesn't help, I tried that already. You still get
> the same error from REDUCE:
>
> ***** solve(log(sin(x + 3)) =8) invalid as scalar
>

I suspect that "simplify" can operate only on algebraic expressions, so
we need some stack acrobatics to handle lists (matrices), maybe using
the "save" space.

In reduce:
-- p:=solve(x^2-1=0,x) => {x=1,x=-1}
-- length p => 2
-- part(p,0) => list
-- part(p,1) => x=1
-- part(p,2) => x=-1

i.e. in stack terms:
PROC_make_function_call "solve" 2 ;
PROC_make_function_call "length" 2; => 2
<OR>
PROC_make_function_call "solve" 2 ;
PROC_push_small_integer 0 ;
PROC_make_function_call "part" 2; => "list"
<BUT>
PROC_make_function_call "solve" 2 ;
PROC_push_small_integer 1 ;
PROC_make_function_call "part" 2; => ***** ... invalid as scalar

one has to take lhs/rhs.
There must be a simple solution, but I have to brush up my reduce knowledge.

p.s. the PROC_lisp_eval doesn't work either, complaining "unset variable x".

> Maybe there's a switch for that? I'll have to go and read the manual now. :)
>
so do I ):




kp

unread,
Sep 29, 2012, 10:41:23 AM9/29/12
to pure...@googlegroups.com
Am 29.09.2012 10:40, schrieb Albert Graef:
> On 09/29/2012 04:38 AM, kp wrote:
>> Reduce has a lot of switches to control formatting and output. I've to
>> lookup as I have forgotten most of them (PROC_set_switch).
>
> Yeah, that should be available in the high-level API as well. What about
> PROC_load_package, is that needed in applications, too?

Some packages are autoloaded, some are not, like algint, zeilberg afaik.
Maybe you want to write and load your own reduce package :)

>
>> I tried integration [...]
>> 100*x^(9/100)*x^3/309 ??????
>
> Well, considering that REDUCE prefers exact results, that result is
> certainly correct, if somewhat convoluted. Maybe REDUCE wants to split
> off integer powers of unknowns by default? In any case, it isn't be a
> big deal to take apart the standard quotient form and further simplify
> it on the Pure side, if desired.
>
Yes, it's correct. I don't remember why I was puzzled.
I suppose there is a switch to control this behavior.

ah, got it:

ROUNDED _ _ _ _ _ _ _ _ _ _ _ _ switch

When rounded is on, floating-point arithmetic is enabled, with precision
initially at a system default value, which is usually 12 digits. The
precise number can be found by the command precision(0).

** Most switches are listed in chapter 12 of the ref manual.

If "off rounded" (default) then float -> rat automatically.

> We still got all of Unicode. :) How about Greek letters? E.g., the
> arbints might be denoted οΏ½1, οΏ½2, etc., likewise the arbcomplex values as
> οΏ½1, οΏ½2 etc. These are valid identifiers in Pure, so no trouble with that
> (unless you're running on an ancient system which doesn't support Unicode).

good idea.

Kurt

Albert Graef

unread,
Sep 29, 2012, 11:53:53 AM9/29/12
to pure...@googlegroups.com
On 09/29/2012 04:41 PM, kp wrote:
> Some packages are autoloaded, some are not, like algint, zeilberg afaik.
> Maybe you want to write and load your own reduce package :)

Ok, I already added this to the high-level API now.

> ah, got it:
>
> ROUNDED _ _ _ _ _ _ _ _ _ _ _ _ switch

Thanks, that does the trick:

> reduce::switch "rounded" 1;
0
> simplify $ int (x^2.0) x;
0.333333333333333*x^3
> simplify $ int (x^2.09) x;
0.323624595469256*x^0.09*x^3

Still, REDUCE seemingly wants to split off integer powers, maybe there's
another switch for that? :)

BTW, 'int' is actually a function in Pure, which means that you need to
use the quote to prevent premature evaluation if you want to integrate a
numeric constant:

> simplify $ 'int 2 x;
2*x

To work around that, I'd like to suggest that we designate a special
symbol on the Pure side for integration (int would still continue to
work, of course, subject to the caveat above). How about 'intg'?

> ** Most switches are listed in chapter 12 of the ref manual.

Thanks for the pointer, I'll have a look at that.

Albert Graef

unread,
Sep 29, 2012, 11:59:15 AM9/29/12
to pure...@googlegroups.com
On 09/29/2012 03:58 PM, kp wrote:
> I suspect that "simplify" can operate only on algebraic expressions, so
> we need some stack acrobatics to handle lists (matrices), maybe using
> the "save" space.

Ok, I see, I'll have a look at that asap. I've committed what I have
into the hg repo now (rev. 95eea55c44b3), to facilitate access for
everybody and so that we can keep track of changes. See here:
http://code.google.com/p/pure-lang/source/browse/#hg/pure-reduce.
Bigints and other special coefficients (:rd: et al) should now be
handled properly.

Kurt, if you want I can give you commit access so that you can work on
the pure-reduce sources yourself (you need a gmail account for that). In
particular, we need more examples in reduce_examp.pure, especially
examples which don't work properly yet so that we can fix the interface.
;-) Also, there are the XXXTODO items in the reduce.pure module,
especially the lists of Reduce function symbols which need remapping on
the Pure side.

kp

unread,
Sep 29, 2012, 12:03:34 PM9/29/12
to pure...@googlegroups.com
The impl code to proc.h is in /trunk/csl/cslbase/csl.c (lines 3280-end).
Maybe you can recognise the mechanisms regarding lists.


Am 29.09.2012 17:53, schrieb Albert Graef:

>
> Still, REDUCE seemingly wants to split off integer powers, maybe there's
> another switch for that? :)

quite probable, I'll try to find it.

>
> BTW, 'int' is actually a function in Pure, which means that you need to
> use the quote to prevent premature evaluation if you want to integrate a
> numeric constant:
>
> > simplify $ 'int 2 x;
> 2*x
>
> To work around that, I'd like to suggest that we designate a special
> symbol on the Pure side for integration (int would still continue to
> work, of course, subject to the caveat above). How about 'intg'?
>
'intg' would be reasonable.

kp

unread,
Sep 29, 2012, 12:07:18 PM9/29/12
to pure...@googlegroups.com
Am 29.09.2012 17:59, schrieb Albert Graef:
> On 09/29/2012 03:58 PM, kp wrote:
>> I suspect that "simplify" can operate only on algebraic expressions, so
>> we need some stack acrobatics to handle lists (matrices), maybe using
>> the "save" space.
>
> Ok, I see, I'll have a look at that asap. I've committed what I have
> into the hg repo now (rev. 95eea55c44b3), to facilitate access for
> everybody and so that we can keep track of changes. See here:
> http://code.google.com/p/pure-lang/source/browse/#hg/pure-reduce.
> Bigints and other special coefficients (:rd: et al) should now be
> handled properly.
>
> Kurt, if you want I can give you commit access so that you can work on
> the pure-reduce sources yourself (you need a gmail account for that). In
> particular, we need more examples in reduce_examp.pure, especially
> examples which don't work properly yet so that we can fix the interface.
> ;-) Also, there are the XXXTODO items in the reduce.pure module,
> especially the lists of Reduce function symbols which need remapping on
> the Pure side.
>
> Albert
>

very kind, but I think that's not necessary. I can send the examples to
the list for review, then you may or may not dispatch the stuff.
Morevoer I'm still a "pure" noob :)
Kurt

John Cowan

unread,
Sep 29, 2012, 1:12:01 PM9/29/12
to pure...@googlegroups.com
Albert Graef scripsit:

> Kurt, if you want I can give you commit access so that you can work on
> the pure-reduce sources yourself (you need a gmail account for that).

Actually, you can get a Google account based on any email address, not just
a Gmail one, by going to <https://accounts.google.com/SignUp>. You don't
have to tell the truth in any of the other fields. :-)

--
We are lost, lost. No name, no business, no Precious, nothing. Only empty.
Only hungry: yes, we are hungry. A few little fishes, nassty bony little
fishes, for a poor creature, and they say death. So wise they are; so just,
so very just. --Gollum co...@ccil.org http://ccil.org/~cowan

Albert Graef

unread,
Sep 29, 2012, 1:13:10 PM9/29/12
to pure...@googlegroups.com
On 09/29/2012 04:41 PM, kp wrote:
>> We still got all of Unicode. :) How about Greek letters? E.g., the
>> > arbints might be denoted α1, α2, etc., likewise the arbcomplex values as
>> > ζ1, ζ2 etc. These are valid identifiers in Pure, so no trouble with that
>> > (unless you're running on an ancient system which doesn't support Unicode).
> good idea.

Committed in rev. 20d8476816f1.

Albert Graef

unread,
Sep 29, 2012, 1:21:31 PM9/29/12
to pure...@googlegroups.com
On 09/29/2012 06:03 PM, kp wrote:
> 'intg' would be reasonable.

I already added that in rev. a611358a0898.

Albert Graef

unread,
Sep 29, 2012, 1:30:41 PM9/29/12
to pure...@googlegroups.com
On 09/29/2012 06:07 PM, kp wrote:
> very kind, but I think that's not necessary. I can send the examples to
> the list for review, then you may or may not dispatch the stuff.

Ok, I'll take care of that, but be warned that I probably won't be able
to keep up that pace; there's also some other stuff on my TODO list. :)

> Morevoer I'm still a "pure" noob :)

But you know your ways around REDUCE much better than anyone else here,
so maybe you could write up some nice documentation to help aspiring
Pure-REDUCE users get started? Do you know RST?

Albert Graef

unread,
Sep 29, 2012, 4:22:36 PM9/29/12
to pure...@googlegroups.com
On 09/29/2012 03:58 PM, kp wrote:
>> Which leaves us with the non-scalar results. Leaving out the call to
>> > PROC_make_printable doesn't help, I tried that already. You still get
>> > the same error from REDUCE:
>> >
>> > ***** solve(log(sin(x + 3)) =8) invalid as scalar
>> >
> I suspect that "simplify" can operate only on algebraic expressions, so
> we need some stack acrobatics to handle lists (matrices), maybe using
> the "save" space.

Ugh, that would be a rather awful kludge. What to do if we're running
out of registers (they're only 100 of them)?

Fortunately, by trial and error I found a solution now. Funnily enough,
non-scalar results seem to go through just fine if the input expression
is wrapped in an extra 'list' call. I've implemented this workaround
now. In fact I added full bidirectional marshalling of list values
between Pure and Reduce in the latest revision. So you can also solve
systems of equations in a straightforward way. Example (see the latest
revision of reduce_examp.pure for more):

> simplify $ solve [3*x + 5*y == -4, 2*x + y == -10] [x, y];
[[x==(-46)/7,y==22/7]]

I'm still trying to figure out how to convert matrix values. This is how
far I got:

> reduce::load "matrix";
> simplify $ 2*mat [1,2] [3,4];
mat (__sq ([(list:1):2]:1) t 2 4) (__sq ([(list:1):2]:1) t 6 8)

This looks about right, but I still need to fix up those embedded *SQ
forms. Apparently PROC_make_printable doesn't like matrix values, so it
refuses to recurse into them. ;-)

kp

unread,
Sep 29, 2012, 5:02:01 PM9/29/12
to pure...@googlegroups.com
> so maybe you could write up some nice documentation to help aspiring
> Pure-REDUCE users get started? Do you know RST?
>

Yes, that is something I can do, provided somebody will correct the
English ;)
Kurt

p.s.
Maybe, there are some other "poets" around?
Any help is welcome.

kp

unread,
Sep 29, 2012, 5:03:13 PM9/29/12
to pure...@googlegroups.com
Am 29.09.2012 22:22, schrieb Albert Graef:
> On 09/29/2012 03:58 PM, kp wrote:
>>> Which leaves us with the non-scalar results. Leaving out the call to
>>>> PROC_make_printable doesn't help, I tried that already. You still get
>>>> the same error from REDUCE:
>>>>
>>>> ***** solve(log(sin(x + 3)) =8) invalid as scalar
>>>>
>> I suspect that "simplify" can operate only on algebraic expressions, so
>> we need some stack acrobatics to handle lists (matrices), maybe using
>> the "save" space.
>
> Ugh, that would be a rather awful kludge. What to do if we're running
> out of registers (they're only 100 of them)?

I agree :)
wheras the number of registers can be set in csl.c ;
>
> Fortunately, by trial and error I found a solution now. Funnily enough,
> non-scalar results seem to go through just fine if the input expression
> is wrapped in an extra 'list' call. I've implemented this workaround
> now. In fact I added full bidirectional marshalling of list values
> between Pure and Reduce in the latest revision. So you can also solve
> systems of equations in a straightforward way. Example (see the latest
> revision of reduce_examp.pure for more):
>
> > simplify $ solve [3*x + 5*y == -4, 2*x + y == -10] [x, y];
> [[x==(-46)/7,y==22/7]]
>

ingenious! that's a real breakthrough.

Now I conceive the statement in the manual:
"""
From the symbolic mode standpoint it may appear a bit curious that one
has to insert the symbol LIST into a list in order to make it a correct
algebraic object, but this is necessary in the prefi x algebraic context
"""

> I'm still trying to figure out how to convert matrix values. This is how
> far I got:
>
> > reduce::load "matrix";
> > simplify $ 2*mat [1,2] [3,4];
> mat (__sq ([(list:1):2]:1) t 2 4) (__sq ([(list:1):2]:1) t 6 8)
>
> This looks about right, but I still need to fix up those embedded *SQ
> forms. Apparently PROC_make_printable doesn't like matrix values, so it
> refuses to recurse into them. ;-)
>
> Albert
>

Well, "prepsq/simp" convert between algebraic- and SQ form, but this
seems not very helpful here. On the other hand (from a lisp point of
view) the difference is only (MAT ....) vs. (LIST ...), so as a last
resort one could try to replace the ident via "lisp". Let's hope you
will find in this case a resonable solution too :)

Kurt




Albert Graef

unread,
Sep 29, 2012, 6:20:42 PM9/29/12
to pure...@googlegroups.com
On 09/29/2012 11:03 PM, kp wrote:
> Now I conceive the statement in the manual:
> """
>>From the symbolic mode standpoint it may appear a bit curious that one
> has to insert the symbol LIST into a list in order to make it a correct
> algebraic object, but this is necessary in the prefi x algebraic context
> """

I should have known this a bit earlier. ;-) Where did you find that gem?

Another funny thing I discovered is that apparently with the extra
'list' call the toplevel gets expanded to the "printable" format even
without PROC_make_printable. The stuff inside 'mat' still remains
unexpanded, alas.

> Well, "prepsq/simp" convert between algebraic- and SQ form, but this
> seems not very helpful here.

No, there seems no way to call it via simplify (at least I couldn't find
one), and I don't want to start fiddling with executing Lisp code from
Pure. ;-) I wrote my own SQ form expander now (not a big deal in Pure),
it's almost finished, but I guess I call it a day for now.

One thing that still throws me off is that '__sq ([(list:1):1]:1) t'
term (in Pure syntax) at the front of each row of the matrix. I just
don't understand what that's good for. Do you have an idea? Must be some
internal bookkeeping, I guess. It seems to adjust to the kernels in the
matrix elements, but so far I can't find a use for it. Oh well, if you
can dig out some documentation on Reduce's internal matrix format, that
might be helpful. :)

kp

unread,
Sep 29, 2012, 6:59:15 PM9/29/12
to pure...@googlegroups.com
Am 30.09.2012 00:20, schrieb Albert Graef:
> On 09/29/2012 11:03 PM, kp wrote:
>> Now I conceive the statement in the manual:
>> """
>> >From the symbolic mode standpoint it may appear a bit curious that one
>> has to insert the symbol LIST into a list in order to make it a correct
>> algebraic object, but this is necessary in the prefi x algebraic context
>> """
>
> I should have known this a bit earlier. ;-) Where did you find that gem?
>

Ah, sorry, I forget to give the ref; it's all in the "primer" I sent on
29-09-2012:04:38

- description of *SQ, section 3.2, page 16
- lists, section 3.3.1 (*gem)
- matrices, section 3.3.2
- SF,SQ comprehensive, chapter 4 ff.


> Another funny thing I discovered is that apparently with the extra
> 'list' call the toplevel gets expanded to the "printable" format even
> without PROC_make_printable. The stuff inside 'mat' still remains
> unexpanded, alas.
>

I suppose "list" calls internally "symbolic prepsq" (as "list ..." is
also a Reduce command), this might be an explanation for this phenomenon.

>> Well, "prepsq/simp" convert between algebraic- and SQ form, but this
>> seems not very helpful here.
>
> No, there seems no way to call it via simplify (at least I couldn't find
> one), and I don't want to start fiddling with executing Lisp code from
> Pure. ;-) I wrote my own SQ form expander now (not a big deal in Pure),
> it's almost finished, but I guess I call it a day for now.
>

well-deserved, I dare to say :)

> One thing that still throws me off is that '__sq ([(list:1):1]:1) t'
> term (in Pure syntax) at the front of each row of the matrix. I just
> don't understand what that's good for. Do you have an idea? Must be some

cit. 3.3.2
"""
A matrix too is represented internally by a prefi x form with operator
MAT followed by the rows; each row is a list containing the elements as
algebraic forms. The elements can be accessed easily using the access
function nth.
Example: the matrix mat((1; 2); (3; 4)) is encoded as (MAT (1 2) (3 4)).
"""

> internal bookkeeping, I guess. It seems to adjust to the kernels in the
> matrix elements, but so far I can't find a use for it. Oh well, if you
> can dig out some documentation on Reduce's internal matrix format, that

loc. cit.

John Cowan

unread,
Sep 29, 2012, 7:40:45 PM9/29/12
to pure...@googlegroups.com
kp scripsit:

> Yes, that is something I can do, provided somebody will correct the
> English ;)

As a native speaker and former copy editor (subeditor), I will be glad
to do so.

--
You let them out again, Old Man Willow! John Cowan
What you be a-thinking of? You should not be waking! co...@ccil.org
Eat earth! Dig deep! Drink water! Go to sleep!
Bombadil is talking. http://ccil.org/~cowan

kp

unread,
Sep 29, 2012, 8:58:23 PM9/29/12
to pure...@googlegroups.com
Am 30.09.2012 01:40, schrieb John Cowan:
> kp scripsit:
>
>> Yes, that is something I can do, provided somebody will correct the
>> English ;)
>
> As a native speaker and former copy editor (subeditor), I will be glad
> to do so.
>

Hi John,
that is very kind, thank you.
What format do you prefer? ASCII text, RST, ... ?
We can convert it afterwards.
Kurt


John Cowan

unread,
Sep 29, 2012, 9:22:03 PM9/29/12
to pure...@googlegroups.com
kp scripsit:

> What format do you prefer? ASCII text, RST, ... ?
> We can convert it afterwards.

Any format you prefer.

--
I now introduce Professor Smullyan, John Cowan
who will prove to you that either co...@ccil.org
he doesn't exist or you don't exist, http://www.ccil.org/~cowan
but you won't know which. --Melvin Fitting

kp

unread,
Sep 30, 2012, 3:08:36 PM9/30/12
to pure...@googlegroups.com
Some further examples using the latest pure-reduce checkout (for test
purposes).

-- The first part in cats1.pure is borrowed from the "Computer Algebra
Test Suite" (CATS), to find at the Axiom website
http://axiom.axiom-developer.org/axiom-website/CATS/index.html.
The list variable "Dx" should contain only zeroes after running the script.

-- the second part (r1-r54) are examples from the Reduce manual (with
some new operators, mainly for multivariate polynomials). Below is a
printout of "R" (the script gives no output) in order to see the very
few issues (_sq in lists).

-- The use of Pure's "e" and "i" as variables should be used with care
(use quote) as they evaluate to "Euler" and complex "i".

bottom line:
- there were no (math) errors in the output
- the interface is already very stable (even the error messages are
reasonable) and all fits well into Pure's syntax :)
- next are matrices, switches and packages to test. It's not yet clear
to me how to declare properties of operators (symmetric, odd, factor,
depend, ...).
Kurt


> using system;
let R = [val ("r"+str i) | i=1..54];
map puts $ map str $ map eval R;
> > 1002230017L
[__sq (2:((x:1):1):2) t,__sq (-2:((x:1):1):1) t,__sq
(2:((x:2):1):((x:1):2):1) t]
[x==2*val "\0x256c\(0x2592)5"*pi+asin (e^(2^(3/5)*cos
(2*pi/5))/e^(2^(3/5)*sin (2*pi/5)*i))+-3,x==2*val
"\0x256c\(0x2592)5"*pi+-asin (e^(2^(3/5)*cos (2*pi/5))/e^(2^(3/5)*sin
(2*pi/5)*i))+pi+-3,x==2*val "\0x256c\(0x2592)4"*pi+asin
(1/e^(2^(3/5)*cos (pi/5)+2^(3/5)*sin (pi/5)*i))+-3,x==2*val
"\0x256c\(0x2592)4"*pi+-asin (1/e^(2^(3/5)*cos (pi/5)+2^(3/5)*sin
(pi/5)*i))+pi+-3,x==2*val "\0x256c\(0x2592)3"*pi+asin (e^(2^(3/5)*sin
(pi/5)*i)/e^(2^(3/5)*cos (pi/5)))+-3,x==2*val
"\0x256c\(0x2592)3"*pi+-asin (e^(2^(3/5)*sin (pi/5)*i)/e^(2^(3/5)*cos
(pi/5)))+pi+-3,x==2*val "\0x256c\(0x2592)2"*pi+asin (e^(2^(3/5)*cos
(2*pi/5)+2^(3/5)*sin (2*pi/5)*i))+-3,x==2*val
"\0x256c\(0x2592)2"*pi+-asin (e^(2^(3/5)*cos (2*pi/5)+2^(3/5)*sin
(2*pi/5)*i))+pi+-3,x==2*val "\0x256c\(0x2592)1"*pi+asin
(e^2^(3/5))+-3,x==2*val "\0x256c\(0x2592)1"*pi+-asin (e^2^(3/5))+pi+-3]
[__sq ([(z:2):1]:1) t,0,__sq ([(z:1):3]:1) t,0,3,0,__sq (1 ((z:1):1)) t]
1/z
b
a
(+)
[[__sq
((((x:48):1):((x:47):1):((x:46):1):((x:43):-1):((x:42):-1):((x:41):-2):((x:40):-1):((x:39):-1):((x:36):1):((x:35):1):((x:34):1):((x:33):1):((x:32):1):((x:31):1):((x:28):-1):((x:26):-1):((x:24):-1):((x:22):-1):((x:20):-1):((x:17):1):((x:16):1):((x:15):1):((x:14):1):((x:13):1):((x:12):1):((x:9):-1):((x:8):-1):((x:7):-2):((x:6):-1):((x:5):-1):((x:2):1):((x:1):1):1):1)
t,1],[__sq
((((x:24):1):((x:23):-1):((x:19):1):((x:18):-1):((x:17):1):((x:16):-1):((x:14):1):((x:13):-1):((x:12):1):((x:11):-1):((x:10):1):((x:8):-1):((x:7):1):((x:6):-1):((x:5):1):((x:1):-1):1):1)
t,1],[__sq
((((x:12):1):((x:11):-1):((x:9):1):((x:8):-1):((x:6):1):((x:4):-1):((x:3):1):((x:1):-1):1):1)
t,1],[__sq
((((x:8):1):((x:7):-1):((x:5):1):((x:4):-1):((x:3):1):((x:1):-1):1):1)
t,1],[__sq
((((x:6):1):((x:5):1):((x:4):1):((x:3):1):((x:2):1):((x:1):1):1):1)
t,1],[__sq ((((x:4):1):((x:3):1):((x:2):1):((x:1):1):1):1) t,1],[__sq
((((x:2):1):((x:1):1):1):1) t,1],[__sq ((((x:1):1):-1):1) t,1]]
[[2,2],[3,1],[__sq ((((x:1):1):1):1) t,1],[__sq ((((x:1):1):-1):1) t,1]]
x+1
2*x+2*y
1
x^3+4*x^2+5*x+2
4*x^3+4*x^2*y+-4*x*y____2+-4*y*y____2
2*y^2
y
-y^2
[__sq ((((u:2):1):((u:1):35):234):1) t,u==v^2+10*v,v==x^2+-22*x]
[__sq ((((w:2):1):1):1) t,w==u+v]
2
13
y^2
c^2+4*c*d+4*d^2
4*a+4*b
a*c+2*a*d+b*c+2*b*d
a
d^2
1
a*c^2+4*a*c*d+4*a*d^2
4*a*d^2+4*b*d^2
a*c+2*a*d+b*c+2*b*d
a
0
x
50
3*a+2*b
b*c+2*b*d
a*c+b*c
0
a^2+2*a*y+2*y^2+2*y+1
mat (__sq ([(list:1):1]:1) t [a,b,c] [d,e,f] [g,h,i])
(2*A*X^2*Y^2+4*A*X^2*Y+X*Y^2+X*Z)/(2*A)
(2*A*X^2*Y^2+4*A*X^2*Y+X*Y^2+X*Z)/(2*A)
x^m*b+x^n*a+c
x^m*b+x^n*a+c
(x^m*b*m+x^n*a*n)/x
(x^m*b*n*x+x^m*b*x+x^n*a*m*x+x^n*a*x+c*m*n*x+c*m*x+c*n*x+c*x)/(m*n+m+n+1)
a*b*x1^2*x2*x3^3
12*a*b*x3
x3^J*x2^M*x1^N
(x3^J*x2^M*x1^N*J*M^2*N^2+-x3^J*x2^M*x1^N*J*M^2*N+-x3^J*x2^M*x1^N*J*M*N^2+x3^J*x2^M*x1^N*J*M*N)/(x1^2*x2^2*x3)
(x3^J*x2^M*x1^N*J*M^2*N^2+-x3^J*x2^M*x1^N*J*M^2*N+-x3^J*x2^M*x1^N*J*M*N^2+x3^J*x2^M*x1^N*J*M*N)/(x1^2*x2^2*x3)
0
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
>
cats1.pure
cats1.pure.pdf

kp

unread,
Sep 30, 2012, 3:34:10 PM9/30/12
to pure...@googlegroups.com

before it's lost: a template (latex.pure) for Texmacs output.
Usage see tm_pure.pdf. It should be tailored (intention, taste) at any
rate; it's only an example.
Kurt

tm_pure.pdf
latex.pure

kp

unread,
Sep 30, 2012, 4:56:04 PM9/30/12
to pure...@googlegroups.com
I'm sorry for having polluted the mail-list. I wasn't aware that the
attachments were expanding into the mail body.
Can somebody clear this mess?
I've re-attached the last two src files in a tar.gz ;)
Kurt


files.tar.gz

Albert Graef

unread,
Oct 1, 2012, 3:41:15 AM10/1/12
to pure...@googlegroups.com
On 09/30/2012 03:22 AM, John Cowan wrote:
>> What format do you prefer? ASCII text, RST, ... ?
>> > We can convert it afterwards.
> Any format you prefer.

The preferred documentation format for the Pure project is RST (with
Sphinx extensions). Of course any format is fine, as long as its
ASCII-convertible. :) But then someone else will have to do the RST
conversion. So it's really helpful if stuff gets written in RST format
right away.

We also have syntax highlighting for Pure and a Pure domain for function
docs etc. Please just have a look at how the existing doc sources look
like
(http://code.google.com/p/pure-lang/source/browse?repo=docs#hg%2F_sources)
and ask.

RST is really rather straightforward, looks almost like ASCII text. :)
In fact, most of the docs are simply the README files of the various
packages, and the entire online documentation gets generated
automatically from that.

Albert

Albert Graef

unread,
Oct 1, 2012, 4:08:12 AM10/1/12
to pure...@googlegroups.com
On 09/29/2012 11:03 PM, kp wrote:
> Well, "prepsq/simp" convert between algebraic- and SQ form, but this
> seems not very helpful here. On the other hand (from a lisp point of
> view) the difference is only (MAT ....) vs. (LIST ...), so as a last
> resort one could try to replace the ident via "lisp". Let's hope you
> will find in this case a resonable solution too :)

Matrices work now, including symbolic matrices. Well, at least I got
some simple examples working, see reduce_examp.pure, so any feedback is
appreciated.

This was a bit tricky. The only way I found to construct a matrix was to
use (mat (list 'x11 'x12 ...) ...), evaluating the embedded list terms
in the Lisp interpreter first. But it seems to work fine now:

> using math, reduce;
> reduce::init "reduce.img" {"-v"};

Codemist Standard Lisp 6.03 for generic:generic: Sep 27 2012
Created: Thu Sep 27 20:37:18 2012

Reduce (Free CSL version), 27-Sep-12 ...
Memory allocation: 12 Mbytes
()
> simplify $ det (x*{1,2;3,4});
-2*x^2
> simplify $ mateigen {2,5;1,0} λ;
[[λ^2-2*λ-5,1,{5*ζ1/(λ-2);ζ1}]]

kp

unread,
Oct 1, 2012, 8:42:03 AM10/1/12
to pure...@googlegroups.com
Am 01.10.2012 10:08, schrieb Albert Graef:

> Matrices work now, including symbolic matrices. Well, at least I got
> some simple examples working, see reduce_examp.pure, so any feedback is
> appreciated.
>
> This was a bit tricky. The only way I found to construct a matrix was to
> use (mat (list 'x11 'x12 ...) ...), evaluating the embedded list terms
> in the Lisp interpreter first. But it seems to work fine now:
>
> > using math, reduce;
> > reduce::init "reduce.img" {"-v"};
>
> Codemist Standard Lisp 6.03 for generic:generic: Sep 27 2012
> Created: Thu Sep 27 20:37:18 2012
>
> Reduce (Free CSL version), 27-Sep-12 ...
> Memory allocation: 12 Mbytes
> ()
> > simplify $ det (x*{1,2;3,4});
> -2*x^2
> > simplify $ mateigen {2,5;1,0} οΏ½;
> [[οΏ½^2-2*οΏ½-5,1,{5*οΏ½1/(οΏ½-2);οΏ½1}]]
>

Marvelous! That's a further milestone.
I'm going to try the ODE package which makes heaviliy use of matrices.
Kurt

kp

unread,
Oct 1, 2012, 8:58:43 AM10/1/12
to pure...@googlegroups.com
Am 01.10.2012 09:41, schrieb Albert Graef:
> On 09/30/2012 03:22 AM, John Cowan wrote:
>>> What format do you prefer? ASCII text, RST, ... ?
>>>> We can convert it afterwards.
>> Any format you prefer.
>
> The preferred documentation format for the Pure project is RST (with
> Sphinx extensions). Of course any format is fine, as long as its
> ASCII-convertible. :) But then someone else will have to do the RST
> conversion. So it's really helpful if stuff gets written in RST format
> right away.
>
> We also have syntax highlighting for Pure and a Pure domain for function
> docs etc. Please just have a look at how the existing doc sources look
> like
> (http://code.google.com/p/pure-lang/source/browse?repo=docs#hg%2F_sources)
> and ask.
>
> RST is really rather straightforward, looks almost like ASCII text. :)
> In fact, most of the docs are simply the README files of the various
> packages, and the entire online documentation gets generated
> automatically from that.
>
> Albert
>

Yes, thanks. I know rst/sphinx from Python. John offered to correct my
"horrible" English, so I asked him which format he would prefer, as ReST
isn't as comfortable as pure text for that purpose. Since he has no
preference regarding the format, there's no fence to write it in rst
from beginning.
But there are some points we should discuss before starting the doc,
especially how to build the library and regarding the portability of the
reduce image.
Kurt

kp

unread,
Oct 1, 2012, 9:25:06 AM10/1/12
to pure...@googlegroups.com
Hello Albert,

below is a solution for the declararion functions "operator" and "flag"
(there are some few others), which do not work with PROC_simplify and
has to be evaluated with PROC_lisp_eval. Since they are essential for
most core operators as well as the packages (tylor, argint, ode, ...) we
need an additional function in Pure (similar to simplify), which is able
to perform a sequence as in the code below. Any idea?

The backgroud is as follows: reduce has an algebraic and a symbolic (aka
lisp) mode. PROC_simplify is for the algebraic mode only, refusing to
evaluate the commands: operator, even, linear, antisymmetric and so on.
In fact, those commands are only aliases to some core commands in the
symbolic mode which have to be evaluated with lisp_eval. If one sets the
switch "on defn" in interactive reduce, one may see the internal
structure (in lisp notation). I have recognized the following:

- operator 'myop -> corresponds to "operator myop" in algebraic mode
- flag 'myop 'prop -> corresponds to "prop myop", e.g. linear myop.
- prop 'plus -> no correspondence, gives property list of an operator,
- put, get -> setting properties (actually, we don't need them, don't we?

Kurt

#! #########

PROC_clear_stack ;

/////////////////////////////////////
// (operator (list 'myOp))
// (flag (list 'f) 'odd)
/////////////////////////////////////

PROC_push_symbol "myOp" ;
PROC_make_function_call "quote" 1;
PROC_make_function_call "list" 1;
PROC_make_function_call "operator" 1;
PROC_lisp_eval;

PROC_push_symbol "myOp" ;
PROC_make_function_call "quote" 1;
PROC_make_function_call "list" 1;
PROC_push_symbol "odd" ;
PROC_make_function_call "quote" 1;
PROC_make_function_call "flag" 2;
PROC_lisp_eval;

PROC_push_symbol "x" ;
PROC_make_function_call "minus" 1;
PROC_make_function_call "myOp" 1;

PROC_simplify ;
PROC_dup ;
PROC_save 1 ;
PROC_make_printable;

Albert Graef

unread,
Oct 1, 2012, 4:48:29 PM10/1/12
to pure...@googlegroups.com
On 09/30/2012 10:56 PM, kp wrote:
> I'm sorry for having polluted the mail-list. I wasn't aware that the
> attachments were expanding into the mail body.

No need to worry. It depends on the mail client. Google Groups won't
display the contents of the attachments until you click on them.
Thunderbird displays ASCII attachments, but I actually find this pretty
convenient since I can look at the code without having to save the
attachments.

Albert Graef

unread,
Oct 1, 2012, 7:03:48 PM10/1/12
to pure...@googlegroups.com
On 09/30/2012 09:08 PM, kp wrote:
> Some further examples using the latest pure-reduce checkout (for test
> purposes).

Thanks, that will be very useful as a test suite indeed! I've committed
it (with some minor changes) as pure-reduce/tests.pure in rev.
ee61503724fd. The results look good to me, but you might want to have
another look yourself (see pure-reduce/tests.log).

> -- the second part (r1-r54) are examples from the Reduce manual (with
> some new operators, mainly for multivariate polynomials). Below is a
> printout of "R" (the script gives no output) in order to see the very
> few issues (_sq in lists).

The unexpanded SQ forms were fixed already. There's still an issue with
bigints not being recognized (that's also why simplify $ num (100/6)
gives an exception), but I'll take care of that asap.

> -- The use of Pure's "e" and "i" as variables should be used with care
> (use quote) as they evaluate to "Euler" and complex "i".

Yes, but that also applies to any variable, constant or function that
might already be defined in a Pure script. As usual, you'd just quote
the entire argument to simplify if you want it to be treated as a
literal. We might make this the default behaviour, but I think that it's
actually more convenient as it is, since you can easily simplify
computed expressions as well. Pure's own reduce macro also works that way.

One convenient solution for the quoting problem is to have a pair of
bracket symbols which does the same as simplify but automagically quotes
its argument. I noticed that at least under Ubuntu/Gnome2 using a
keyboard with an AltGr key, the non-ASCII bracket symbols �� are very
easy to get (AltGr-x and AltGr-y). You can define this as a macro quite
easily:

outfix � �;
def �x� = simplify ('x);

Now you can write, e.g., �df (e^(x^2)) x� instead of simplify ('(df
(e^(x^2)) x)), and stop worrying about symbols defined in Pure land.

Concerning (/), I've chosen that for the division operator since that's
what Reduce uses. So this means that if you have a ratio of two numbers
then you need to quote it if you want to pass it to Reduce unchanged.
(Of course you can also write something like (quotient 100 6) which
isn't defined in Pure, but that's less convenient.) Pure actually has
its own exact division operator %, so we should probably map this to
Reduce's /, which would allow an exact ratio to be specified as p%q,
without having to quote it.

Concerning Reduce's assignment operator, I've added an operator symbol
:= for that now. It has the same precedence as Pure's hash rocket =>,
which allows it to be used unparenthesized as an operand to $ or inside
a list (so that you can, e.g., use do simplify [x:=expr1, y:=expr2, ...]
to process an entire batch of Reduce assignments). I think that this is
convenient, but of course I'm open to suggestions concerning the
precedence of the := operator. One might give it a very low precedence
(such as Pure's --> which is at precedence level 0), but then one always
has to parenthesize it when used in any larger context; or one might
give it the precedence of the relational operators, but that doesn't
work very well if used in conjunction with the logical operators (which
bind weaker than the relational operators in Pure, like in C). So I
think that putting it at the same precedence level as Pure's => is a
reasonable compromise.

Albert

Albert Graef

unread,
Oct 1, 2012, 7:52:50 PM10/1/12
to pure...@googlegroups.com
On 10/02/2012 01:03 AM, Albert Graef wrote:
> The unexpanded SQ forms were fixed already. There's still an issue with
> bigints not being recognized (that's also why simplify $ num (100/6)
> gives an exception), but I'll take care of that asap.

Fixed in rev. 2950b3559e08.

> [...] Pure actually has
> its own exact division operator %, so we should probably map this to
> Reduce's /, which would allow an exact ratio to be specified as p%q,
> without having to quote it.

Fixed in rev. 3b6173e23cef. Pure complex number notation in rectangular
(x+:y) and polar notation (x<:y) are now converted to the appropriate
Reduce terms as well. That is, they'll expand to (x+i*y) and
(x*e^(i*y)), respectively. Kurt, if you know better ways to get complex
numbers in Reduce, please let me know.

kp

unread,
Oct 1, 2012, 11:39:18 PM10/1/12
to pure...@googlegroups.com
Am 02.10.2012 01:03, schrieb Albert Graef:
> On 09/30/2012 09:08 PM, kp wrote:
>> Some further examples using the latest pure-reduce checkout (for test
>> purposes).
>
> Thanks, that will be very useful as a test suite indeed! I've committed
> it (with some minor changes) as pure-reduce/tests.pure in rev.
> ee61503724fd. The results look good to me, but you might want to have
> another look yourself (see pure-reduce/tests.log).
>

I pulled it down, no errors :)
I'll do some more asap (matrix, ode, taylor, limits, tensors, ...).


>> -- The use of Pure's "e" and "i" as variables should be used with care
>> (use quote) as they evaluate to "Euler" and complex "i".
>
> Yes, but that also applies to any variable, constant or function that
> might already be defined in a Pure script. As usual, you'd just quote
> the entire argument to simplify if you want it to be treated as a
> literal. We might make this the default behaviour, but I think that it's
> actually more convenient as it is, since you can easily simplify
> computed expressions as well. Pure's own reduce macro also works that way.

Well, my remark was merely intended to draw attention to the "quote" in
the expression and by no means to blame the evaluation behavior. On the
contrary, I find this quite natural as I conceive "reduce" as part of
Pure. If we have an expression, say "let P = X^2+1", then I ought to
know what "X" is (if it evaluates to "foo", it's my fault :) but when
differentiating, say "let P1 = simpl $ df P X", then I expect that "P"
evaluates and P1 is the derivative of P (in Pure).
I'd have never chosen the variables "e,i" in the test script myself,
they came in by copy/paste from the manual.

>
> One convenient solution for the quoting problem is to have a pair of
> bracket symbols which does the same as simplify but automagically quotes
> its argument. I noticed that at least under Ubuntu/Gnome2 using a
> keyboard with an AltGr key, the non-ASCII bracket symbols �� are very
> easy to get (AltGr-x and AltGr-y). You can define this as a macro quite
> easily:
>
> outfix � �;
> def �x� = simplify ('x);
>
> Now you can write, e.g., �df (e^(x^2)) x� instead of simplify ('(df
> (e^(x^2)) x)), and stop worrying about symbols defined in Pure land.
>
As I said, there is no "quoting problem" for me at all, but other users
may see that differently, so that an "outfix" is a good idea (synt.
sugar that makes a clear difference to the eval form). But anyway, I
suppose each user will tailor his/her own commands based on the current
"reduce.pure", depending on what CAS he/her has known before. That
this is possible at all is one of the many great "freedoms" Pure is
providing.


> Concerning (/), I've chosen that for the division operator since that's
> what Reduce uses. So this means that if you have a ratio of two numbers
> then you need to quote it if you want to pass it to Reduce unchanged.
> (Of course you can also write something like (quotient 100 6) which
> isn't defined in Pure, but that's less convenient.) Pure actually has
> its own exact division operator %, so we should probably map this to
> Reduce's /, which would allow an exact ratio to be specified as p%q,
> without having to quote it.
>

Yes, so the user has the choice between 2%3, 2/3 or (quote 2/3).

> Concerning Reduce's assignment operator, I've added an operator symbol
> := for that now. It has the same precedence as Pure's hash rocket =>,
> which allows it to be used unparenthesized as an operand to $ or inside
> a list (so that you can, e.g., use do simplify [x:=expr1, y:=expr2, ...]

Ah, yes, that is convenient.


> think that putting it at the same precedence level as Pure's => is a
> reasonable compromise.
>
just.

I find the current "reduce.pure" very plain and proper. I guess it's
easy to learn, however, it's also clear to me that Pure offers a lot of
possibilities to wrap it up.

Kurt



Albert Graef

unread,
Oct 2, 2012, 5:12:40 AM10/2/12
to pure...@googlegroups.com
On 10/01/2012 03:25 PM, kp wrote:
> below is a solution for the declararion functions "operator" and "flag"
> (there are some few others), which do not work with PROC_simplify and
> has to be evaluated with PROC_lisp_eval. Since they are essential for
> most core operators as well as the packages (tylor, argint, ode, ...) we
> need an additional function in Pure (similar to simplify), which is able
> to perform a sequence as in the code below. Any idea?

Ok, in rev. 7dccede3067c I've added a new function `lisp` which works
like `simplify` but executes arbitrary Lisp code. I feel a bit uneasy
about this since PROC_lisp_eval just crashes if you try to execute a
non-existing Lisp function. But if it's needed to do some things then so
be it. Use with care. :)

Here's how to use this:

> lisp ('list a b c d e);
[a,b,c,d,e]
> lisp ('cdr [a,b,[c,d],e]);
[b,[c,d],e]

As you can see, Pure lists are converted to Lisp lists and a resulting
Lisp list is converted back to a Pure list. I guess that it's most
convenient that way, but I'm open to suggestions there.

Here's how you can do the operator declaration stuff:

> lisp ('operator [myop]);
[]
> lisp ('flag [myop] odd);
[]
> lisp ('prop myop);
[odd:t,simpfn:simpiden]
> simplify (myop (-x));
-myop x

Does this do what you want?

BTW, in rev. 918e18a740f5 I also renamed reduce::init to reduce::start
to prevent a name collision with the standard library function init
which was inconvenient when 'using namespace reduce'.

Albert Graef

unread,
Oct 2, 2012, 6:52:06 AM10/2/12
to pure...@googlegroups.com
This is awesome! :) Added under pure/examples/texmacs (with some
commentary) in rev. 8c9c9854493e.

Thanks!
Albert

Albert Graef

unread,
Oct 2, 2012, 7:05:12 AM10/2/12
to pure...@googlegroups.com
On 10/01/2012 02:58 PM, kp wrote:
> Yes, thanks. I know rst/sphinx from Python. John offered to correct my
> "horrible" English, so I asked him which format he would prefer, as ReST
> isn't as comfortable as pure text for that purpose. Since he has no
> preference regarding the format, there's no fence to write it in rst
> from beginning.

Ok, I understand. I just wanted to point out that RST would be good,
since then your doc integrates nicely with the rest of the Pure
documentation.

> But there are some points we should discuss before starting the doc,
> especially how to build the library and regarding the portability of the
> reduce image.

I'm thinking about adding a Makefile which would allow you to just drop
the Reduce sources in the pure-reduce source directory and then run the
usual `make && sudo make install`. I'll also add something like a Pure
library path search for the image file to reduce::start so that
`reduce::start "reduce.img" {}` just works after a `make install`. We
might even add that statement to the reduce.pure module so that no extra
initialization would be required, just `using reduce;` would suffice.

Albert Graef

unread,
Oct 2, 2012, 7:28:09 AM10/2/12
to pure...@googlegroups.com
On 10/02/2012 05:39 AM, kp wrote:
> I find the current "reduce.pure" very plain and proper. I guess it's
> easy to learn, however, it's also clear to me that Pure offers a lot of
> possibilities to wrap it up.

Yeah, that's the idea. We keep reduce.pure rather minimalistic so that
you just have a few Pure functions to learn to get going. Then the user
can build his own abstractions on top of that as desired.

kp

unread,
Oct 2, 2012, 9:42:13 AM10/2/12
to pure...@googlegroups.com
Am 02.10.2012 11:12, schrieb Albert Graef:
> On 10/01/2012 03:25 PM, kp wrote:
>> below is a solution for the declararion functions "operator" and "flag"
>> (there are some few others), which do not work with PROC_simplify and
>> has to be evaluated with PROC_lisp_eval. Since they are essential for
>> most core operators as well as the packages (tylor, argint, ode, ...) we
>> need an additional function in Pure (similar to simplify), which is able
>> to perform a sequence as in the code below. Any idea?
>
> Ok, in rev. 7dccede3067c I've added a new function `lisp` which works
> like `simplify` but executes arbitrary Lisp code. I feel a bit uneasy

so do I :)
but it's very convenient, to be honest. Maybe it should go to the low
level for the adepts. For the moment let's use it for the testing:

> lisp ('depend [y,x]);
[]
> simplify $ odesolve [df y x == x^2+(quote e)^x] [y] x;
[y==(3*arbconst 1+3*e^x+x^3)/3]

I suggest that I'm going to collect some examples then perhaps you will
recognize a pattern for a safe "declare" like function.

Up to now, we need:

operator f,g --> (operator (list 'f 'g)
odd|linear|symmetric,... f,g,h --> (flag (list 'f 'g 'h) 'symmetric
[no]depend f,x,y,z --> (depend (list 'f 'x 'y 'z)
factor|remfac f,g,h --> (factor (list 'f 'g 'h)
infix f,g,h --> (mkop 'f)(mkop 'g)(mkop 'h)
(infix (list 'f 'g 'h)

... korder, noncom, nonzero, order, precedence, precision, real, scalar,
scientific_notation, share, tr, untr, varname


> about this since PROC_lisp_eval just crashes if you try to execute a
> non-existing Lisp function. But if it's needed to do some things then so
> be it. Use with care. :)
>
> Here's how to use this:
>
> > lisp ('list a b c d e);
> [a,b,c,d,e]
> > lisp ('cdr [a,b,[c,d],e]);
> [b,[c,d],e]
>
> As you can see, Pure lists are converted to Lisp lists and a resulting
> Lisp list is converted back to a Pure list. I guess that it's most
> convenient that way, but I'm open to suggestions there.

cool, nevertheless ;)

>
> Here's how you can do the operator declaration stuff:
>
> > lisp ('operator [myop]);
> []
> > lisp ('flag [myop] odd);
> []
> > lisp ('prop myop);
> [odd:t,simpfn:simpiden]
> > simplify (myop (-x));
> -myop x
>
> Does this do what you want?

exactly :)



kp

unread,
Oct 2, 2012, 3:51:16 PM10/2/12
to pure...@googlegroups.com

It's incredible how much works properly on first try.
I'm stuck at two packages (see attach.):
- SUM, r25-r28: ***** Declare min=>min operator ? (Y or N)
- TAYLOR r29,r30: there, I can't interpret the output.

I haven't found yet many packages which need properties or flags (except
ODESOLVE, where "depend" is mandatory). Moreover, most packages do
"autoload", so "reduce::load" isn't necessary very often. But there are
still a lot of others (each has its own documentation
http://www.reduce-algebra.com/documentation.htm), so I'll keep on trying.

Kurt



examples2.pure

Albert Graef

unread,
Oct 3, 2012, 2:46:29 AM10/3/12
to pure...@googlegroups.com
On 10/02/2012 01:05 PM, Albert Graef wrote:
> On 10/01/2012 02:58 PM, kp wrote:
>> But there are some points we should discuss before starting the doc,
>> especially how to build the library and regarding the portability of the
>> reduce image.
>
> I'm thinking about adding a Makefile which would allow you to just drop
> the Reduce sources in the pure-reduce source directory and then run the
> usual `make && sudo make install`. I'll also add something like a Pure
> library path search for the image file to reduce::start so that
> `reduce::start "reduce.img" {}` just works after a `make install`. We
> might even add that statement to the reduce.pure module so that no extra
> initialization would be required, just `using reduce;` would suffice.

The path search is implemented now and I've added a Makefile to make
compiling and installing the relevant parts of Reduce easy. Installation
instructions are in the README file.

kp

unread,
Oct 3, 2012, 7:26:14 AM10/3/12
to pure...@googlegroups.com
Am 03.10.2012 08:46, schrieb Albert Graef:
> On 10/02/2012 01:05 PM, Albert Graef wrote:
>> On 10/01/2012 02:58 PM, kp wrote:
>>> But there are some points we should discuss before starting the doc,
>>> especially how to build the library and regarding the portability of the
>>> reduce image.
>>
>> I'm thinking about adding a Makefile which would allow you to just drop
>> the Reduce sources in the pure-reduce source directory and then run the
>> usual `make && sudo make install`. I'll also add something like a Pure
>> library path search for the image file to reduce::start so that
>> `reduce::start "reduce.img" {}` just works after a `make install`. We
>> might even add that statement to the reduce.pure module so that no extra
>> initialization would be required, just `using reduce;` would suffice.
>
> The path search is implemented now and I've added a Makefile to make
> compiling and installing the relevant parts of Reduce easy. Installation
> instructions are in the README file.
>

That will make life definitively easier. I'll try it asap (especially on
MinGW/Win).

I've attached some examples from another package that's working (defint).

There are still some problems with the more specialized packages like
atensor, cali, excalc, ... they all are using symbolic constructors,
which can only be called via your "lisp" function for the moment. In
most cases, however, the non-definition part is usually algebraic, for
example:

reduce::load "excalc" ;

// define a p-form:
//
//let r4 = simplify $ pform [u==k] [v==4] [f==0] [w==dim-1] ; !not alg
let r4 = lisp ('pform
(list
(list equal u k)
(list equal v 4)
(list equal f 0)
(list equal w (list difference dim 1)))) ;

let r5 = simplify $ (u^v);
let r6 = simplify $ exdegree (u); // -> k
let r7 = simplify $ exdegree (v); // -> 4
let r8 = simplify $ exdegree (f); // -> 0
let r9 = simplify $ exdegree (w); // -> dim-1

//let r10 = simplify $ spacedim 4; // -> not algebraic

Kurt


defint.pure

Albert Graef

unread,
Oct 3, 2012, 10:17:37 AM10/3/12
to pure...@googlegroups.com
On 10/02/2012 09:51 PM, kp wrote:
> I'm stuck at two packages (see attach.):
> - SUM, r25-r28: ***** Declare min=>min operator ? (Y or N)

Typo (the parens around n^3 in r25 are missing). This strange message
seems to happen quite often if you mistype an expression. I don't think
that it's related to the Pure frontend, but I'll look into that.

> - TAYLOR r29,r30: there, I can't interpret the output.

It's explained in redhelp.pdf p. 588. The taylor function yields a
special form which can be converted to standard form with
taylortostandard. I could insert calls to taylortostandard at the
appropriate places in the Pure frontend to have this handled automatically.

Albert Graef

unread,
Oct 3, 2012, 11:11:16 AM10/3/12
to pure...@googlegroups.com
On 10/03/2012 04:17 PM, Albert Graef wrote:
> Typo (the parens around n^3 in r25 are missing). This strange message
> seems to happen quite often if you mistype an expression. I don't think
> that it's related to the Pure frontend, but I'll look into that.

Well, it was in the frontend after all. This weird bug would rear its
ugly head whenever, due to a mistyped expression, a funcall ended up
with a (small) integer in the head. *facepalm* But it's fixed now as of
rev. d2c38b7601b3.

kp

unread,
Oct 3, 2012, 4:36:31 PM10/3/12
to pure...@googlegroups.com
Am 03.10.2012 16:17, schrieb Albert Graef:
> On 10/02/2012 09:51 PM, kp wrote:
>> I'm stuck at two packages (see attach.):
>> - SUM, r25-r28: ***** Declare min=>min operator ? (Y or N)
>
> Typo (the parens around n^3 in r25 are missing). This strange message
> seems to happen quite often if you mistype an expression. I don't think
> that it's related to the Pure frontend, but I'll look into that.
>
>> - TAYLOR r29,r30: there, I can't interpret the output.
>
> It's explained in redhelp.pdf p. 588. The taylor function yields a
> special form which can be converted to standard form with
> taylortostandard. I could insert calls to taylortostandard at the
> appropriate places in the Pure frontend to have this handled automatically.
>

I didn't know that, thanks. Now it works, at least the simplified form
is displayed.
I've attached a corrected and slightly extended version of
examples2.pure. Please, have a look at "Boolean expressions" near the
end of the file. There may be some need for action regarding t,(),infinity.
Kurt

kp

unread,
Oct 3, 2012, 4:37:44 PM10/3/12
to pure...@googlegroups.com
now it's attached, sorry.
examples2.pure

Albert Graef

unread,
Oct 3, 2012, 8:00:57 PM10/3/12
to pure...@googlegroups.com
On 10/03/2012 10:36 PM, kp wrote:
> Am 03.10.2012 16:17, schrieb Albert Graef:
>> It's explained in redhelp.pdf p. 588. The taylor function yields a
>> special form which can be converted to standard form with
>> taylortostandard. I could insert calls to taylortostandard at the
>> appropriate places in the Pure frontend to have this handled automatically.
>
> I didn't know that, thanks. Now it works, at least the simplified form
> is displayed.

The latest revision now inserts the calls to taylortostandard at the
appropriate places in an automatic fashion. Of course this looses the
O(...) residual terms, but these should be obvious in most cases.

In case this gets in the way, you can still disable this with the `#!
--disable taylorsf` pragma, so that you get the unexpanded terms and do
with them as you please.

BTW, I just discovered that I even know the guy who wrote the taylor
package, he's from the University of Mainz. ;-)

> I've attached a corrected and slightly extended version of
> examples2.pure. Please, have a look at "Boolean expressions" near the
> end of the file. There may be some need for action regarding t,(),infinity.

Mapping infinity<->inf certainly makes sense, but I'm not so sure about
the boolean values. Are there any situations where Reduce might spit out
a Lisp nil value which denotes anything else than "false"?

Albert

Albert Graef

unread,
Oct 3, 2012, 8:53:36 PM10/3/12
to pure...@googlegroups.com
On 10/04/2012 02:00 AM, Albert Graef wrote:
> Mapping infinity<->inf certainly makes sense, but I'm not so sure about
> the boolean values. Are there any situations where Reduce might spit out
> a Lisp nil value which denotes anything else than "false"?

These are all implemented now (rev. 64391eece87c), but only in
`simplify`, not in `lisp`. In the latter case, there's really no way to
distinguish an empty list from a truth value when interpreting the
result given back by `lisp`.

Albert Graef

unread,
Oct 4, 2012, 8:29:59 AM10/4/12
to pure...@googlegroups.com
On 10/03/2012 10:36 PM, kp wrote:
> I've attached a corrected and slightly extended version of
> examples2.pure.

Thanks! These have been added to tests.pure (rev. 2a0780d0bf4f). AFAICT,
as of rev. 2a0780d0bf4f there still were issues with the following tests
in the second batch, which I've fixed now as indicated (rev. e37f87f7c6f4):

> let r28 = simplify $ prod (k/(k-2)) k 1 N ; r28;

***** Zero divisor

Given that k-2 becomes zero when k=2 this error message is in fact
correct. :) I'm changing this to (k/(k+2)) so that the test computes
something meaningful.

> let r31 = simplify $ implicit_taylor (x^2+y^2-1) x y 0 1 5 ; r31;
(6*sub (y==1) (df (sub (x==0) (df y x 3)) y)*x^5-7*sub (y==1) (df (sub
(x==0) (df y x 2)) y)*sub (y==1) (df (sub (x==0) (df y x)) y)*x^5+15*sub
(y==1) (df (sub (x==0) (df y x 2)) y)*x^4-3*sub (y==1) (df (sub (x==0)
(df y x)) y 2)*x^5+sub (y==1) (df (sub (x==0) (df y x)) y)^3*x^5-5*sub
(y==1) (df (sub (x==0) (df y x)) y)^2*x^4+7*sub (y==1) (df (sub (x==0)
(df y x)) y)*x^5+20*sub (y==1) (df (sub (x==0) (df y x))
y)*x^3-15*x^4-60*x^2+120)/120

This seems to be due to the earlier declaration (in the odesolve
example) that y depends on x. Getting rid of that declaration with a
call to `nodepedends` solves the problem.

> let r39 = lisp (numberp x) ; r39;
0

This used to crash, but works ok now as of rev. 844497443f5c.

Four eyes see more than two, so it might be good if you checked the
results of the second batch in the latest revision of tests.log to see
whether you can still spot anything wrong.

Note that I also did some cosmetic surgery to tests.pure so that it's
easier to run the tests interactively. It would be nice if we could
stick to that format in the future, this makes my life a lot easier. :)
For convenience, there's also a Makefile target 'make check' now which
runs the tests in an automatic fashion and compares them against
tests.log, and a 'make logs' target which r