322 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

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
>> What format do you prefer? ASCII text, RST, ... ?

>> > We can convert it afterwards.

> Any format you prefer.

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

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

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

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

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

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

>

"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

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;

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;

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
> I'm sorry for having polluted the mail-list. I wasn't aware that the

> attachments were expanding into the mail body.

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.

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
> Some further examples using the latest pure-reduce checkout (for test

> purposes).

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

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

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

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

> [...] 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
> Reduce's /, which would allow an exact ratio to be specified as p%q,

> without having to quote it.

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

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

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

> easy to get (AltGr-x and AltGr-y). You can define this as a macro quite

> easily:

>

> outfix � �;
> easily:

>

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

>

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

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

> reasonable compromise.

>

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

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

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

Oct 2, 2012, 6:52:06 AM10/2/12

to pure...@googlegroups.com

commentary) in rev. 8c9c9854493e.

Thanks!

Albert

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

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.

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.

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

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.

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

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.

>

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

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

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

compiling and installing the relevant parts of Reduce easy. Installation

instructions are in the README file.

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

>

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

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
> I'm stuck at two packages (see attach.):

> - SUM, r25-r28: ***** Declare min=>min operator ? (Y or N)

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.

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.

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

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.

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

>

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

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

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.

the boolean values. Are there any situations where Reduce might spit out

a Lisp nil value which denotes anything else than "false"?

Albert

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

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

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

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