340 views

Skip to first unread message

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

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

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.

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 :)

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

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

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.

>

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

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! :)
> 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.

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.

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.

> BTW, is (eval "x") the

> standard method to convert strings to symbols?

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

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.

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

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

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

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

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

Kurt

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

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
> I did several examples from the manual, no problems at all. A

> non-trivial one is attached.

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.

course our PCs are much faster now than the big iron of old.

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

providing a more convenient interface, see below.

> The noisy output can be caught by r/w callbacks (error messages are

> prefixed 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 :)

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

chosen arbitrarily, right? Maybe we can invent some prettier

representation for that on the Pure side?

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

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

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

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.

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}

____________________________________________________________

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

>

What about sacrificing a prefix symbol? Though, there aren't many left,

I know :)

Kurt

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
> val ":rd:":"675539944105574":-49

> > simplify (1.2*3.0);

> val ":rd:":"1013309916158362":-48

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

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

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

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.

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

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

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

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

>

> 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

>

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

>

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

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.

>

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

> οΏ½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

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.
> Some packages are autoloaded, some are not, like algint, zeilberg afaik.

> Maybe you want to write and load your own reduce package :)

> ah, got it:

>

> ROUNDED _ _ _ _ _ _ _ _ _ _ _ _ switch

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

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

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.

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.

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

>

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

>

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

>

the list for review, then you may or may not dispatch the stuff.

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

Kurt

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

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

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

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

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.

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

to keep up that pace; there's also some other stuff on my TODO list. :)

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

so maybe you could write up some nice documentation to help aspiring

Pure-REDUCE users get started? Do you know RST?

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

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

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
> Pure-REDUCE users get started? Do you know RST?

>

English ;)

Kurt

p.s.

Maybe, there are some other "poets" around?

Any help is welcome.

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

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

>

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

>

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

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 prefix algebraic context

> """

I should have known this a bit earlier. ;-) Where did you find that gem?
> 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 prefix algebraic context

> """

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.

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

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 prefix 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
> 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 prefix algebraic context

>> """

>

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

>

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.

>

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.

>

> 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

"""

A matrix too is represented internally by a prefix 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.
> 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

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

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

> English ;)

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

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

>

that is very kind, thank you.

What format do you prefer? ASCII text, RST, ... ?

We can convert it afterwards.

Kurt

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

> What format do you prefer? ASCII text, RST, ... ?

> We can convert it afterwards.

--

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

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]

>

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]

>

Oct 1, 2012, 3:41:15 AM10/1/12