Embedding REDUCE

[kp]

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
       

[Albert Graef]

Hi Kurt,

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

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

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

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

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

Albert

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

[kp]

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

[Albert Graef]

On 09/27/2012 05:57 PM, kp wrote:
> I'm glad to hear that there is some interest for this (it's not without
> selfishness), as I could really benefit from such an option.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[kp]

Am 27.09.2012 22:22, schrieb Albert Graef:

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

Ah, very good news!

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

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

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

Thank you. I ought to have known that :(

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

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

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

Yes, you're right indeed.

Kurt

[kp]

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

[Albert Graef]

On 09/28/2012 03:42 PM, kp wrote:
> I did several examples from the manual, no problems at all. A
> non-trivial one is attached.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Enjoy :)

[Albert Graef]

On 09/29/2012 02:56 AM, Albert Graef wrote:
> Thanks, works fine over here, too. BTW, what is an arbint? I looked it
> up in the ref manual, but couldn't make any sense of the explanation.

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

[John Cowan]

Albert Graef scripsit:

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

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

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

[kp]

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

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

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

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

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

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

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

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

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


It's very exciting.
Kurt



P.S. (

ARBINT OPERATOR

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

EXAMPLES:

____________________________________________________________


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

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

____________________________________________________________

[kp]

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

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

[Albert Graef]

On 09/29/2012 02:56 AM, Albert Graef wrote:

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

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

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

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

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

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

So we got that covered as well.

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

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

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

[Albert Graef]

On 09/29/2012 04:38 AM, kp wrote:
> Reduce has a lot of switches to control formatting and output. I've to
> lookup as I have forgotten most of them (PROC_set_switch).

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

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

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

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

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

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

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

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

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

[kp]

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

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

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

I see, excellent.

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

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

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

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

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

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

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

so do I ):

[kp]

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

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

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

Yes, it's correct. I don't remember why I was puzzled.
I suppose there is a switch to control this behavior.

ah, got it:

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

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

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

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

> We still got all of Unicode. :) How about Greek letters? E.g., the

> arbints might be denoted οΏ½1, οΏ½2, etc., likewise the arbcomplex values as
> οΏ½1, οΏ½2 etc. These are valid identifiers in Pure, so no trouble with that

> (unless you're running on an ancient system which doesn't support Unicode).

good idea.

Kurt

[Albert Graef]

On 09/29/2012 04:41 PM, kp wrote:
> Some packages are autoloaded, some are not, like algint, zeilberg afaik.
> Maybe you want to write and load your own reduce package :)

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

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

Thanks, that does the trick:

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

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

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

> simplify $ 'int 2 x;
2*x

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

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

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

[Albert Graef]

On 09/29/2012 03:58 PM, kp wrote:
> I suspect that "simplify" can operate only on algebraic expressions, so
> we need some stack acrobatics to handle lists (matrices), maybe using
> the "save" space.

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

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

[kp]

The impl code to proc.h is in /trunk/csl/cslbase/csl.c (lines 3280-end).
Maybe you can recognise the mechanisms regarding lists.

Am 29.09.2012 17:53, schrieb Albert Graef:

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

quite probable, I'll try to find it.

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

'intg' would be reasonable.

[kp]

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

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

[John Cowan]

Albert Graef scripsit:

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

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

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

[Albert Graef]

On 09/29/2012 04:41 PM, kp wrote:

>> We still got all of Unicode. :) How about Greek letters? E.g., the

>> > arbints might be denoted α1, α2, etc., likewise the arbcomplex values as
>> > ζ1, ζ2 etc. These are valid identifiers in Pure, so no trouble with that

>> > (unless you're running on an ancient system which doesn't support Unicode).
> good idea.

Committed in rev. 20d8476816f1.

[Albert Graef]

On 09/29/2012 06:03 PM, kp wrote:

> 'intg' would be reasonable.

I already added that in rev. a611358a0898.

[Albert Graef]

On 09/29/2012 06:07 PM, kp wrote:
> very kind, but I think that's not necessary. I can send the examples to
> the list for review, then you may or may not dispatch the stuff.

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

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

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

[Albert Graef]

On 09/29/2012 03:58 PM, kp wrote:

>> Which leaves us with the non-scalar results. Leaving out the call to
>> > PROC_make_printable doesn't help, I tried that already. You still get
>> > the same error from REDUCE:
>> >
>> > ***** solve(log(sin(x + 3)) =8) invalid as scalar
>> >
> I suspect that "simplify" can operate only on algebraic expressions, so
> we need some stack acrobatics to handle lists (matrices), maybe using
> the "save" space.

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

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

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

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

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

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

[kp]

> so maybe you could write up some nice documentation to help aspiring
> Pure-REDUCE users get started? Do you know RST?
>

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

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

[kp]

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

I agree :)
wheras the number of registers can be set in csl.c ;

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

ingenious! that's a real breakthrough.

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

"""

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

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

Kurt

[Albert Graef]

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

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

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

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

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

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

[kp]

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

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

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

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

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

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

well-deserved, I dare to say :)

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

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

"""

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

loc. cit.

[John Cowan]

kp scripsit:

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

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

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

[kp]

Am 30.09.2012 01:40, schrieb John Cowan:
> kp scripsit:
>
>> Yes, that is something I can do, provided somebody will correct the
>> English ;)
>
> As a native speaker and former copy editor (subeditor), I will be glad
> to do so.
>

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

[John Cowan]

kp scripsit:

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

Any format you prefer.

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

[kp]

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

[kp]

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

[kp]

I'm sorry for having polluted the mail-list. I wasn't aware that the
attachments were expanding into the mail body.
Can somebody clear this mess?
I've re-attached the last two src files in a tar.gz ;)
Kurt

[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

[Albert Graef]

On 09/29/2012 11:03 PM, kp wrote:

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

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

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

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

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

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

[kp]

Am 01.10.2012 10:08, schrieb Albert Graef:

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

> > simplify $ mateigen {2,5;1,0} οΏ½;
> [[οΏ½^2-2*οΏ½-5,1,{5*οΏ½1/(οΏ½-2);οΏ½1}]]
>

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

[kp]

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

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

[kp]

Hello Albert,

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

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

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

Kurt

#! #########

PROC_clear_stack ;

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

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

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

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

PROC_simplify ;
PROC_dup ;
PROC_save 1 ;
PROC_make_printable;

[Albert Graef]

On 09/30/2012 10:56 PM, kp wrote:
> I'm sorry for having polluted the mail-list. I wasn't aware that the
> attachments were expanding into the mail body.

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

[Albert Graef]

On 09/30/2012 09:08 PM, kp wrote:
> Some further examples using the latest pure-reduce checkout (for test
> purposes).

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

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

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

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

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

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

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

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

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

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

Albert

[Albert Graef]

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

Fixed in rev. 2950b3559e08.

> [...] Pure actually has

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

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

[kp]

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

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

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

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

>
> One convenient solution for the quoting problem is to have a pair of
> bracket symbols which does the same as simplify but automagically quotes
> its argument. I noticed that at least under Ubuntu/Gnome2 using a

> keyboard with an AltGr key, the non-ASCII bracket symbols �� are very

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

> outfix � �;
> def �x� = simplify ('x);
>
> Now you can write, e.g., �df (e^(x^2)) x� instead of simplify ('(df

> (e^(x^2)) x)), and stop worrying about symbols defined in Pure land.
>

As I said, there is no "quoting problem" for me at all, but other users
may see that differently, so that an "outfix" is a good idea (synt.
sugar that makes a clear difference to the eval form). But anyway, I
suppose each user will tailor his/her own commands based on the current
"reduce.pure", depending on what CAS he/her has known before. That
this is possible at all is one of the many great "freedoms" Pure is
providing.

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

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

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

Ah, yes, that is convenient.

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

just.

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

Kurt

[Albert Graef]

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

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

Here's how to use this:

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

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

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

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

Does this do what you want?

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

[Albert Graef]

This is awesome! :) Added under pure/examples/texmacs (with some
commentary) in rev. 8c9c9854493e.

Thanks!
Albert

[Albert Graef]

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

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

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

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

[Albert Graef]

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

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

[kp]

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

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

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

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

Up to now, we need:

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

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

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

cool, nevertheless ;)

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

exactly :)

[kp]

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

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

[kp]

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

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

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

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

reduce::load "excalc" ;

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

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

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

Kurt

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

[Albert Graef]

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

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

[kp]

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

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

[kp]

now it's attached, sorry.

[Albert Graef]

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

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

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

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

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

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

Albert

[Albert Graef]

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

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

[Albert Graef]

On 10/03/2012 10:36 PM, kp wrote:

> I've attached a corrected and slightly extended version of
> examples2.pure.

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

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

***** Zero divisor

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

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

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

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

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

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

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

Last but not least, now that the image path search is in place, I've
also added a call to reduce::start to reduce.pure so that Reduce starts
up automatically when the module is loaded. It's more convenient that
way, and the user can just forget about reduce::start provided that he's
installed the image in the right place. Of course it's still possible to
run reduce::start manually if needed; this automatically nukes a
previous Reduce instance if present.

Albert

[Albert Graef]

On 10/03/2012 01:26 PM, kp wrote:
> I've attached some examples from another package that's working (defint).

Added in rev. 94dc4a1c45da.

[Albert Graef]

I'm not sure what to do with this. Can you elaborate?

On 10/03/2012 01:26 PM, kp wrote:

> 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

[kp]

Am 04.10.2012 02:00, schrieb Albert Graef:
> On 10/03/2012 10:36 PM, kp wrote:
>
> BTW, I just discovered that I even know the guy who wrote the taylor
> package, he's from the University of Mainz. ;-)
>

Many of the packages were written at German universities, so I'm not
surprised :) The other lisp version (PSL) was developed at the
Zuse-Institut Berlin.
BTW I found accidentally the following impressive fgures:
<< In mid-2012, there are about 706,000 lines of RLISP code, 312,000
lines of standard Lisp code, and 1,766,000 lines of C code, in a REDUCE
snapshot. >> @ http://www.math.utah.edu/faq/reduce/

>> I've attached a corrected and slightly extended version of
>> examples2.pure. Please, have a look at "Boolean expressions" near the
>> end of the file. There may be some need for action regarding t,(),infinity.
>
> Mapping infinity<->inf certainly makes sense, but I'm not so sure about
> the boolean values. Are there any situations where Reduce might spit out
> a Lisp nil value which denotes anything else than "false"?
>

Well, you are right, it not necessary at all as it can easily be used by
comparison (if ... == (); ). I used it carlessly on the RHS of a rule
assuming "freeof" would return a Pure boolean.

Kurt

[kp]

Am 04.10.2012 02:53, schrieb Albert Graef:
> On 10/04/2012 02:00 AM, Albert Graef wrote:
>> Mapping infinity<->inf certainly makes sense, but I'm not so sure about
>> the boolean values. Are there any situations where Reduce might spit out
>> a Lisp nil value which denotes anything else than "false"?
>
> These are all implemented now (rev. 64391eece87c), but only in
> `simplify`, not in `lisp`. In the latter case, there's really no way to
> distinguish an empty list from a truth value when interpreting the
> result given back by `lisp`.
>

Ok, you already did it. After re-running examples2, I guess it's more
natural to have returned 0,1 instead of t,() ;)
Kurt

[kp]

Am 04.10.2012 14:29, schrieb Albert Graef:


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

Indeed, I ought to have it considered :(

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

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

anyway.

>

> 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 regenerates the log after
> changes to tests.pure.
>

I was also concerned regarding this point as I'm used to "unit" testing
in Python. So this is a good idea.

> Last but not least, now that the image path search is in place, I've
> also added a call to reduce::start to reduce.pure so that Reduce starts
> up automatically when the module is loaded. It's more convenient that
> way,

I quite agree.

Kurt

[kp]

Am 04.10.2012 14:55, schrieb Albert Graef:
> I'm not sure what to do with this. Can you elaborate?
>

I'll submit some more elaborate examples asap. The core statement is
that many packages have a declare/defintion part to construct an object
like tensors, pforms, arrays ... which doesn't work with "simplify". In
the example below

let r4 = simplify $ pform [u==k] [v==4] [f==0] [w==dim-1] ;

should declare four p-forms u,v,w,f of dimensions k,4,0,dim-1
respectively. Only the lisp form "lisp ('pform ...." works; the same
holds e.g. for "simplify $ spacedim 4". But the "methods" wedge,
exdegree ... are working fine with simplify.

Kurt

[kp]

Am 04.10.2012 15:35, schrieb kp:
> Am 04.10.2012 14:55, schrieb Albert Graef:
>> I'm not sure what to do with this. Can you elaborate?
>>

One may wonder whether to care about the special packages at all? The
current interface covers most of the basics now, so that the special
packages could be handled in a similar way in Pure (e.g. using
reduce::excalc and so on). Maybe it's possible to pack several into one
pure file if there is some similarity.
For the basics then we'd need only something like

declare operator f => (operator (list 'f))
declare depend f x => (depend (list (list 'f 'x)))
declare f <property> => (flag (list 'f) 'symmetric)

what do you think?
Kurt

[Albert Graef]

On 10/04/2012 03:57 PM, kp wrote:
> One may wonder whether to care about the special packages at all? The
> current interface covers most of the basics now, so that the special
> packages could be handled in a similar way in Pure (e.g. using
> reduce::excalc and so on). Maybe it's possible to pack several into one
> pure file if there is some similarity.

Great idea. Gotta love procrastination. :) No, seriously, let's start
worrying about this when people pick it up and actually need this stuff
(and maybe contribute the required addons themselves).

> For the basics then we'd need only something like
>
> declare operator f => (operator (list 'f))
> declare depend f x => (depend (list (list 'f 'x)))
> declare f <property> => (flag (list 'f) 'symmetric)
>
> what do you think?

D'accord. Committed in rev. 3d241a6d38f9 (with some cosmetic changes).
Examples for all supported declarations can be found at the end of
reduce_examp.pure. The properties currently supported are even, odd,
linear, symmetric; if you want anything to be added to this list, please
let me know.

Albert

[Albert Graef]

Preliminary documentation is now online at:
http://docs.pure-lang.googlecode.com/hg/pure-reduce.html

Kurt, I'm counting on you to beef this up a little bit. ;-) (And on
John, of course, who kindly offered to do the proofreading!)

Ok, so we got a Gnumeric plugin now and interfaces to Octave, Reduce,
GLPK and GSL. What else do we need? A better plotting interface maybe?
The Gnuplot module, while functional, is somewhat incomplete at present.
Can anyone suggest a good 2D/3D plotting library with a nice C interface
which we might want to wrap in Pure?

[kp]

Am 05.10.2012 01:28, schrieb Albert Graef:
> On 10/04/2012 03:57 PM, kp wrote:
>> One may wonder whether to care about the special packages at all? The
>> current interface covers most of the basics now, so that the special
>> packages could be handled in a similar way in Pure (e.g. using
>> reduce::excalc and so on). Maybe it's possible to pack several into one
>> pure file if there is some similarity.
>
> Great idea. Gotta love procrastination. :) No, seriously, let's start
> worrying about this when people pick it up and actually need this stuff
> (and maybe contribute the required addons themselves).

A wise decision, I dare to say :)

>
>> For the basics then we'd need only something like
>>
>> declare operator f => (operator (list 'f))
>> declare depend f x => (depend (list (list 'f 'x)))
>> declare f <property> => (flag (list 'f) 'symmetric)
>>
>> what do you think?
>
> D'accord. Committed in rev. 3d241a6d38f9 (with some cosmetic changes).
> Examples for all supported declarations can be found at the end of
> reduce_examp.pure. The properties currently supported are even, odd,
> linear, symmetric; if you want anything to be added to this list, please
> let me know.

There are two, three others props. I'll collect them asap.


>
> Albert
>

[kp]

Am 05.10.2012 02:28, schrieb Albert Graef:
> Preliminary documentation is now online at:
> http://docs.pure-lang.googlecode.com/hg/pure-reduce.html
>
> Kurt, I'm counting on you to beef this up a little bit. ;-) (And on
> John, of course, who kindly offered to do the proofreading!)
>

Excellent.
Your pace is overwhelming, but nobody is complaining :)

If you want me to convert the examples (sectioned by topic) to rst, let
me know.
Reduce has a very sophisticated TeX package (TRI) in which I'm very
interested in view of the Texmacs interface. Unfortunately I have no
clue how to get the tex output into a string (yet). Though I found a
very inconvenient method via the internal stack, I'm convinced there
must be a simple solution.

> Ok, so we got a Gnumeric plugin now and interfaces to Octave, Reduce,
> GLPK and GSL. What else do we need? A better plotting interface maybe?
> The Gnuplot module, while functional, is somewhat incomplete at present.
> Can anyone suggest a good 2D/3D plotting library with a nice C interface
> which we might want to wrap in Pure?

springing to mind are:

Paraview, http://www.paraview.org/
GLE, http://glx.sourceforge.net/
matplotlib, http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/
GRI, github.com/dankelley/gri.git (looked at, but never used).


Thank you Albert, a great job indeed.
Kurt

[Albert Graef]

On 10/05/2012 03:49 AM, kp wrote:
> Your pace is overwhelming, but nobody is complaining :)

Well, I've just been processing the stuff you keep throwing at me. ;-)

> If you want me to convert the examples (sectioned by topic) to rst, let
> me know.

Yes, please. I think that it would be nice to have a little guided tour
of Reduce's basic features and how they're used from Pure.

> Reduce has a very sophisticated TeX package (TRI) in which I'm very
> interested in view of the Texmacs interface. Unfortunately I have no
> clue how to get the tex output into a string (yet). Though I found a
> very inconvenient method via the internal stack, I'm convinced there
> must be a simple solution.

Let me know if you figure it out, it should be nice to add this to our
module.

Also, is it important for a pure-reduce user to know how to load his own
Reduce packages? Then we should have a basic example showing how to do
this via reduce::load. I have no idea where Reduce looks for package
files which aren't in the image; the redhelp entry on load_package
doesn't say anything about this.

> Paraview, http://www.paraview.org/
> GLE, http://glx.sourceforge.net/
> matplotlib, http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/
> GRI, github.com/dankelley/gri.git (looked at, but never used).

Thanks for these links. These all look nice and capable but none of them
seems to expose a C API; at least I couldn't find anything in the online
docs. I'm specifically looking for a plotting library with a decent C
interface. I found these (I haven't used any of these, though, so
comments are appreciated):

http://mathgl.sf.net/ (C++, but seems to have C bindings)
http://plplot.sf.net/ (C/C++/D and a bunch of other languages)

> Thank you Albert, a great job indeed.

Thank *you* for getting this started. :) I would never have imagined
that it would be that easy to get a full-blown CAS integrated in Pure.
This is really one of the things we sorely missed, and was asked for a
couple of times already.

[Albert Graef]

On 10/02/2012 03:42 PM, kp wrote:
> 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

I've added most of these now, except as noted below. I've also added all
the operator symbol attributes I could find in the redhelp which were
still missing. Note that some stuff like `order` and `factor` seems
rather useless right now because it only affects the print
representation, and these flags don't seem to be honored by the PROC
interface at all.

infix: Do we really need this? I mean, this doesn't really affect the
prefix form which simplify returns, does it? So you'll never know the
difference, unless you're writing actual Reduce code and then you might
just do these declarations in the Reduce code instead.

precision, real, scalar, scientific_notation, share, tr, untr, varname:
Those might be useful on occasion, but do we really need to wrap them?

- AFAICT, the integer, real and scalar declarations only declare local
variables in a begin ... end block, but they don't seem to have any
other effect on simplify that I can see.

- scientific_notation only affects the print representation according to
the redhelp.

- share, tr, untr, varname seem to be confined to expert use, and then
you might just use `lisp` directly to execute these.

- precision seems useful for average use, but then again it's not so
difficult to just write something like `lisp (precision 20)` and be done
with it.

So I'd suggest that we just leave these unwrapped and let the programmer
invoke them through `lisp` if he really needs them. Ok?

[kp]

Am 05.10.2012 14:29, schrieb Albert Graef:
> On 10/02/2012 03:42 PM, kp wrote:
>> Up to now, we need:

that was bit rash ...

>>
>> 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
>
> I've added most of these now, except as noted below. I've also added all
> the operator symbol attributes I could find in the redhelp which were
> still missing. Note that some stuff like `order` and `factor` seems
> rather useless right now because it only affects the print
> representation, and these flags don't seem to be honored by the PROC
> interface at all.
>

It's all there. I only missed antisymmetric and nonzero.
The "noncom" declaration evaluates to "(noncom (list 'g)", so it should
be in reduce::kdec_syms instead of reduce::prop_syms?

>
> So I'd suggest that we just leave these unwrapped and let the programmer
> invoke them through `lisp` if he really needs them. Ok?
>

Yes, these are rarely needed outside the special packages in which the
"lisp" function can't be avoided anyway.

Kurt

[kp]

> Thanks for these links. These all look nice and capable but none of them
> seems to expose a C API; at least I couldn't find anything in the online
> docs. I'm specifically looking for a plotting library with a decent C
> interface. I found these (I haven't used any of these, though, so
> comments are appreciated):

Well, I know there is no explicit C API, so one had to write a wrapper
or build the library itself (in some of the listed apps there is not
much C++ code except the .cc suffix). I admit that this would be
tiresome and questionable anyway, as a simple "pipe" would suffice to
obtain the same result.
I forgot to mention http://asymptote.sourceforge.net/ , another high
quality tool (I'm afraid it's also C++).

The easiest way - don't laugh - would be to embed the Python interpeter
(more or less a three liner :) then one has access to a bunch of
plotting libs, especially pylab/matplotlib.

http://docs.python.org/extending/embedding.html
void exec_pycode(const char* code)
{
Py_Initialize();
PyRun_SimpleString(code);
Py_Finalize();
}

AFAIK there was a C API to ROOT (http://root.cern.ch/), which has very
nice graphics, but I suppose it would be out of date anyway, even CINT
will be replaced by CLING/CLANG (LLVM).

>
> http://mathgl.sf.net/ (C++, but seems to have C bindings)
> http://plplot.sf.net/ (C/C++/D and a bunch of other languages)
>

plplot looks promising!

here some forks of old GRX C API.
http://www.fgrim.com/mgrx/
http://grx.gnu.de/grx249um.html

Kurt

[kp]

>> Ok, so we got a Gnumeric plugin now and interfaces to Octave, Reduce,
>> GLPK and GSL. What else do we need?

The IUP toolkit is very handy and has a cool C API (I embedded it in
CLIPS, though without the main event loop; it has a MIT lic). It has a
lot of predefined dialogs which are working without setting up the whole
cb machinery.
website: http://www.tecgraf.puc-rio.br/iup/

BTW: I forgot to mention the famous DISLIN
(http://www.mps.mpg.de/dislin/), it's free, but still for non-commercial
use only.

Kurt

[Albert Graef]

On 10/05/2012 03:54 PM, kp wrote:
> The "noncom" declaration evaluates to "(noncom (list 'g)", so it should
> be in reduce::kdec_syms instead of reduce::prop_syms?

Oops. Fix in rev. 7ad26dc88a36.

[Albert Graef]

On 10/05/2012 05:35 PM, kp wrote:
> The easiest way - don't laugh - would be to embed the Python interpeter
> (more or less a three liner :) then one has access to a bunch of
> plotting libs, especially pylab/matplotlib.

I'm not laughing, I'm just afraid that shuffling around copious amounts
of program-generated data as strings or temporary files isn't going to
cut it. So it's necessary to go deeper into Python's C API. It's not
difficult, I know, but not the kind of stuff I'd like to do for fun on
weekends, so I'd rather leave that to someone who's worked with the API
before. ;-)

> plplot looks promising!

I agree. I'm going to take a look at it some time, if nobody else beats
me to it.

> here some forks of old GRX C API.
> http://www.fgrim.com/mgrx/

djgpp? DJGPP?? You must be kidding me. ;-)

Thanks for those links, some of those libraries look really nice, and
while I have already come across some of them, some others I didn't
know. In any case it's interesting to hear what everybody else is using.

> The IUP toolkit is very handy and has a cool C API (I embedded it in
> CLIPS, though without the main event loop; it has a MIT lic). It has a
> lot of predefined dialogs which are working without setting up the whole
> cb machinery.
> website: http://www.tecgraf.puc-rio.br/iup/

This looks *really* cool, I didn't know that! A pity, though, that it
doesn't support OSX/Aqua natively (although there seems to be some work
underway to fix that). And no GUI builder, apparently. But a clean and
*simple* C API, that's quite a feat in this day and age.

I should really run pure-gen over the IUP header files and play around
with it. This might be a nice cross-platform GUI solution for Pure, with
basic plotting capabilities already included. GTK+ can be a bitch to get
going on Windows, Qt is a veritable nightmare to wrap (even with
SmokeQt), Tcl/Tk starts looking really old nowadays, Tcl/Gnocl doesn't
work all that well on Windows, wxWidgets is C++, ... It looks like we
should be able to make some good use of IUP in Pure, even if the Unicode
and Mac support is somewhat limited.

[Albert Graef]

On 10/05/2012 02:29 PM, Albert Graef wrote:
> - precision seems useful for average use, but then again it's not so
> difficult to just write something like `lisp (precision 20)` and be done
> with it.

On second thought, this seems so important that there should be a
dedicated function for it. So I added one now. Not very surprisingly,
it's just:

> precision 20;
12

The previously set precision is returned.

In the future we might want to add support for Pure's mpfr module, so
that the full precision becomes available in Pure land as well. But
right now this isn't implemented yet, so the given precision value is
only used internally on the Reduce side. (I'm already tracking this as
issue #97.)

[Albert Graef]

On 10/05/2012 02:28 AM, Albert Graef wrote:
> Ok, so we got a Gnumeric plugin now and interfaces to Octave, Reduce,
> GLPK and GSL. What else do we need? A better plotting interface maybe?

Well, of course Reduce has its own plotting capabilities (via gnuplot),
and this seems to work pretty well. Examples included in
reduce_examp.pure in the latest revision.

[kp]

Am 06.10.2012 04:00, schrieb Albert Graef:
> On 10/05/2012 02:28 AM, Albert Graef wrote:
>> Ok, so we got a Gnumeric plugin now and interfaces to Octave, Reduce,
>> GLPK and GSL. What else do we need? A better plotting interface maybe?
>
> Well, of course Reduce has its own plotting capabilities (via gnuplot),
> and this seems to work pretty well. Examples included in
> reduce_examp.pure in the latest revision.
>

That's striking. I haven't used gnuplot for a long time, so I'm quite
surprised how much it has been pepped up. There are even precompiled
versions for Windows.
I wouldn't have dreamt of trying it in reduce at all :)
Kurt

[kp]

Am 06.10.2012 02:14, schrieb Albert Graef:
> On 10/05/2012 02:29 PM, Albert Graef wrote:
>> - precision seems useful for average use, but then again it's not so
>> difficult to just write something like `lisp (precision 20)` and be done
>> with it.
>
> On second thought, this seems so important that there should be a
> dedicated function for it. So I added one now. Not very surprisingly,
> it's just:
>
> > precision 20;
> 12
>

I didn't notice that at all, in fact I never cared much about numerics
in reduce. I looked it up now and it's admittedly useful. There is an
interesting switch "adjprec":

"While on, adjprec will automatically increase the precision, when
necessary, to match that of any integer or real input, and a message
printed to inform the user of the precision increase."

[Albert Graef]

On 10/06/2012 02:57 PM, kp wrote:
> I wouldn't have dreamt of trying it in reduce at all :)

It's fun. :) Well, it has some quirks and limitations, but it's
certainly usable. In any case, it's more capable than pure-gplot (which
only supports a few basic options and no 3D plotting at all IIRC).

[kp]

Am 05.10.2012 13:08, schrieb Albert Graef:
>> Reduce has a very sophisticated TeX package (TRI) in which I'm very
>> interested in view of the Texmacs interface. Unfortunately I have no
>> clue how to get the tex output into a string (yet). Though I found a
>> very inconvenient method via the internal stack, I'm convinced there
>> must be a simple solution.
>
> Let me know if you figure it out, it should be nice to add this to our
> module.
>
> Also, is it important for a pure-reduce user to know how to load his own
> Reduce packages? Then we should have a basic example showing how to do
> this via reduce::load. I have no idea where Reduce looks for package
> files which aren't in the image; the redhelp entry on load_package
> doesn't say anything about this.
>

At last I found a solution to get the TeX output into a string. This
also provides an example how to load your own reduce code (should be
terminated by ";end;" as a rule in reduce):

- lisp ('in ["path/filename.red"]);

The code can be "compiled" with
- faslout <filename>; ... faslend ;
and loaded with "load/load_package", but this makes hardly sense for
small files.

String handling in CSL is a nightmare, so the TeX string returned by
"tex" has to be postprocessed. Since I popped the TeX output off the
stack by a "dirty" trick, I suspect it's not finished yet (it slightly
differs from the actual stdout output), so that it's not suitable for
the gallery for now.
Kurt

[kp]

>> If you want me to convert the examples (sectioned by topic) to rst, let
>> me know.
>
> Yes, please. I think that it would be nice to have a little guided tour
> of Reduce's basic features and how they're used from Pure.
>

Before I proceed in the wrong direction find a sample attached. I'm not
sure if it fits into your documentation scheme (my sphinx doesn't work
for the moment after a docutil update, but "restview" doesn't complain).
Kurt

[Albert Graef]

On 10/06/2012 11:14 PM, kp wrote:
> At last I found a solution to get the TeX output into a string. This
> also provides an example how to load your own reduce code (should be
> terminated by ";end;" as a rule in reduce):
>
> - lisp ('in ["path/filename.red"]);

Ah I see, thanks. We could provide that as an additional function in the
high-level API, like reduce::in. But this operation is really *awfully*
verbose; is there a way to keep it from blurting out the whole shebang?
In Reduce I can (mostly) silence it with a `$`. I have no idea how to do
that in Pure (safe from temporarily redirecting stdout). I tried
`reduce::switch "echo" 0` but that doesn't seem to help. :(

[Albert Graef]

On 10/07/2012 03:10 AM, kp wrote:
> Before I proceed in the wrong direction find a sample attached. I'm not
> sure if it fits into your documentation scheme (my sphinx doesn't work
> for the moment after a docutil update, but "restview" doesn't complain).

Very nice! Note that the code blocks should be formatted with `..
code-block:: pure` (or just `::`), but other than that the formatting
looks fine as well.

[Albert Graef]

Attached is a sample of what it looks like when formatted in the context
of the Pure documentation.

On 10/07/2012 11:32 AM, Albert Graef wrote:
> On 10/07/2012 03:10 AM, kp wrote:
>> Before I proceed in the wrong direction find a sample attached. I'm not
>> sure if it fits into your documentation scheme (my sphinx doesn't work
>> for the moment after a docutil update, but "restview" doesn't complain).
>
> Very nice! Note that the code blocks should be formatted with `..
> code-block:: pure` (or just `::`), but other than that the formatting
> looks fine as well.

[kp]

Am 07.10.2012 11:37, schrieb Albert Graef:
> Attached is a sample of what it looks like when formatted in the context
> of the Pure documentation.
>

Attached is a draft of the "examples" in the same style. Please, feel
free to change whatever.

@John: although there is not much "prose" in it, you might skim it over?

[kp]

Am 07.10.2012 11:13, schrieb Albert Graef:
> On 10/06/2012 11:14 PM, kp wrote:
>> At last I found a solution to get the TeX output into a string. This
>> also provides an example how to load your own reduce code (should be
>> terminated by ";end;" as a rule in reduce):
>>
>> - lisp ('in ["path/filename.red"]);
>
> Ah I see, thanks. We could provide that as an additional function in the
> high-level API, like reduce::in. But this operation is really *awfully*
> verbose; is there a way to keep it from blurting out the whole shebang?
> In Reduce I can (mostly) silence it with a `$`. I have no idea how to do
> that in Pure (safe from temporarily redirecting stdout). I tried
> `reduce::switch "echo" 0` but that doesn't seem to help. :(
>
> Albert
>

A (possibly final) version of the reduce tex-to-string procedure. Now,
it returns the same string as it is printed by the switch "on tex". I
noticed that the returned string is cut-off at 255 in the Pure console,
but not in reduce (?).

Regarding verbosity when loading a file: the recommended way is - as you
already remarked - "in <filename>$". I have no clue how to emulate the
"$" in the lisp call, but writing "off echo;" at the begin of the source
file helps (and using "$'s" instead of ";").

Maybe mid-term you'll find the leisure to think about the callback's to
catch the output :) There are, that's to say, some other packages
providing (more modern) latex and texmacs output, unfortunately also via
"prin2" (no typo) only.

Kurt

[Albert Graef]

On 10/09/2012 01:03 AM, kp wrote:
> A (possibly final) version of the reduce tex-to-string procedure. Now,
> it returns the same string as it is printed by the switch "on tex".

Thanks, seems to work great! In the meantime, I've also fixed up Pure's
texmacs mode and latex.pure, so that they get along better with modules
like reduce which heavily rely on str, and are thus easily broken when
__show__ is redefined in an intrusive manner. See
http://code.google.com/p/pure-lang/source/detail?r=bd5f33098ea9.

Example attached. Your reduce tex-to-string procedure should benefit
from that, too, if you try to use it in texmacs. Note that you need to
define __texmacs__ instead of __show__ now; this only applies in texmacs
mode and only in the REPL; str is unaffected, so the reduce module will
work fine with it.

> I noticed that the returned string is cut-off at 255 in the Pure console,
> but not in reduce (?).

Static buffer in reduce-algebra/csl/cslbase/csl.c, line 4098. Boo hiss!!

It's easy enough to fix this. Getting this accepted upstream is another
matter, though. Are you still in touch with the Reduce developers? For
the time being I can add my own replacement of PROC_string_data to the
library, that shouldn't be a big deal either.

> Regarding verbosity when loading a file: the recommended way is - as you
> already remarked - "in <filename>$". I have no clue how to emulate the
> "$" in the lisp call, but writing "off echo;" at the begin of the source
> file helps (and using "$'s" instead of ";").

Yes, it's indeed much better now. :)

> Maybe mid-term you'll find the leisure to think about the callback's to
> catch the output :)

Yeah, not a big deal either. But just so that I don't forget about all
this, could you file bugs please?

[kp]

>
> Maybe mid-term you'll find the leisure to think about the callback's to
> catch the output :) There are, that's to say, some other packages
> providing (more modern) latex and texmacs output, unfortunately also via
> "prin2" (no typo) only.
>
> Kurt
>
>

Well, I'm sometimes quite stupid. Forget the paragraph above. The
callbacks are of course entirely useless as it will be nothing more to
catch as we already see with the NULL's :(

What really could be promising is the following observation:

> reduce::execute_lisp_function "oem-supervisor" NULL NULL ;
(load!-package 'tri)
% TeX-REDUCE-Interface 0.70
% set greek asserted
% set lowercase asserted
% set Greek asserted
% set Uppercase asserted
% \tolerance 10
% \hsize=150mm
nil
0
> reduce::execute_lisp_function "oem-supervisor" NULL NULL ;
(aeval 'a)
(!*sq ((((a . 1) . 1)) . 1) t)
0
> reduce::execute_lisp_function "oem-supervisor" NULL NULL ;
(texpri 'hello nil 'only)
$$
hello
$$
nil
0

Kurt

[kp]

Am 09.10.2012 02:25, schrieb Albert Graef:
> On 10/09/2012 01:03 AM, kp wrote:
>> A (possibly final) version of the reduce tex-to-string procedure. Now,
>> it returns the same string as it is printed by the switch "on tex".
>
> Thanks, seems to work great! In the meantime, I've also fixed up Pure's
> texmacs mode and latex.pure, so that they get along better with modules
> like reduce which heavily rely on str, and are thus easily broken when
> __show__ is redefined in an intrusive manner. See
> http://code.google.com/p/pure-lang/source/detail?r=bd5f33098ea9.
>

That's great. I was aware that redefining __show__ X may be problematic,
especially when avoiding any partition of X by types.

> Example attached. Your reduce tex-to-string procedure should benefit
> from that, too, if you try to use it in texmacs. Note that you need to
> define __texmacs__ instead of __show__ now; this only applies in texmacs
> mode and only in the REPL; str is unaffected, so the reduce module will
> work fine with it.
>

This oils the wheels :)
There has been a lot of work-power invested in the reduce packages tri,
rlfi, tmprint and fmprint. It would be a pity not to use it.

>> I noticed that the returned string is cut-off at 255 in the Pure console,
>> but not in reduce (?).
>
> Static buffer in reduce-algebra/csl/cslbase/csl.c, line 4098. Boo hiss!!

Well, I didn't expect this as the whole string appeared in the reduce
console. Maybe it concerns only the proc interface?

>
> It's easy enough to fix this. Getting this accepted upstream is another
> matter, though. Are you still in touch with the Reduce developers? For
> the time being I can add my own replacement of PROC_string_data to the
> library, that shouldn't be a big deal either.
>

My last contact was several years ago. Now and then reading in dev list,
I believe they are rather open-minded.
It's not urgent anyway, as I'm still seeking after a better solution.

>> Regarding verbosity when loading a file: the recommended way is - as you
>> already remarked - "in <filename>$". I have no clue how to emulate the
>> "$" in the lisp call, but writing "off echo;" at the begin of the source
>> file helps (and using "$'s" instead of ";").
>
> Yes, it's indeed much better now. :)
>

The package header even prints with the 'dollar'.

[Albert Graef]

On 10/08/2012 04:40 PM, kp wrote:
> Attached is a draft of the "examples" in the same style. Please, feel
> free to change whatever.

Wow, that was quick. :) What a nice and comprehensive selection of
examples, thanks! Committed in rev. 3497a0b8d77d. I already found and
fixed a few trivial formatting glitches and typos, but didn't do any
thorough proofreading. You can have a look at the results in html format
here:
http://docs.pure-lang.googlecode.com/hg/pure-reduce.html#examples-by-topic

Note: The references don't show in the pdf at
http://docs.pure-lang.googlecode.com/hg/puredoc.pdf, although they work
fine in the html doc. I'm not sure why, I will have to look into it.
Maybe I need to update my Sphinx/docutils.

John, if you have any corrections then please throw them at me and I'll
commit them asap. Thanks!

BTW, Kurt, are you running under Windows? I don't quite understand why
you got those garbled `val "\0x256c\(0x2593)5"` terms in the first
`solve` example. This correctly gives β5 (\beta 5) over here. Maybe the
encoding of your reduce.pure file got messed up? Anyway, I already fixed
that in the committed docs.

Albert

[Albert Graef]

On 10/09/2012 03:39 AM, kp wrote:
>> Static buffer in reduce-algebra/csl/cslbase/csl.c, line 4098. Boo hiss!!
> Well, I didn't expect this as the whole string appeared in the reduce
> console. Maybe it concerns only the proc interface?

Yep, that code belongs to the proc interface.

[Albert Graef]

On 10/09/2012 02:26 AM, kp wrote:
> Well, I'm sometimes quite stupid. Forget the paragraph above. The
> callbacks are of course entirely useless as it will be nothing more to
> catch as we already see with the NULL's :(

Well, it might still be useful to just get rid of the remaining output.

This is all fixed in rev. fd7bc71c78bf. There are new functions
reduce::capture, reduce::output and reduce::in (the latter automatically
captures the output). So you can now just do:

> using reduce;
Reduce (Free CSL version), 09-Oct-12 ...
> reduce::in "pure_tex.red";
[]
> let r1 = simplify $ tex (df (x^n) x); r1;
"$$\\frac{x^{n}\\cdot n}{x}$$"

If you need to see the output produced by reduce::in:

> reduce::output;
"off echo $\n% TeX-REDUCE-Interface 0.70\n% set greek asserted\n% set
lowercase asserted\n% set Greek asserted\n% set Uppercase asserted\n%
\\tolerance 10\n% \\hsize=150mm\n"

*Hint Hint* This might be worth a section in the Examples by Topics?

While I was at it, I also fixed the truncated string buffer issue. So
big return strings from your `tex` function shouldn't be an issue any more.

Note that all this requires some fixups and extensions to the PROC
interface which are in proc-add.c now. A recompile is needed (drop
reduce-algebra into pure-reduce and run `make && sudo make install`).

Eventually we should probably give that whole PROC interface a serious
facelift to fix its most annoying quirks, such as the crashes on invalid
Lisp code.

> What really could be promising is the following observation:
>
>> reduce::execute_lisp_function "oem-supervisor" NULL NULL ;

That oem-supervisor thingy seems pretty useful. ;-) Is it documented
somewhere?

I've added support for that as well, so you can now just run
oem-supervisor like this (as a bonus, you'll also get the Lisp result as
a Pure value):

> lisp (lispsym "oem-supervisor");

(aeval 'a)
(!*sq ((((a . 1) . 1)) . 1) t)

[_sq,[(a:1):1]:1,t]

I also found this gem buried in the "Examples by Topics":

> > simplify $ pf f x;
> [2/(x+2),(-2)/(x+1),2/(((x:1):1):1)^2] // (x+1)^2 ???

This is rather interesting since there's a kernel in a standard form
here which is itself a standard form. The Reduce docs aren't really
clear on whether that kind of recursion is intended, so I thought it was
forbidden. But it's fixed in rev. 3c8a4193b1bd:

> reduce::switch "exp" 0;
0
> let f = 2/((x+1)^2*(x+2));
> simplify $ pf f x;
[2/(x+2),(-2)/(x+1),2/(x+1)^2]

I hope that this doesn't break anything -- the tests all pass, though,
so we should be fine (FLW). :)

[kp]

Am 09.10.2012 03:45, schrieb Albert Graef:

> BTW, Kurt, are you running under Windows? I don't quite understand why
> you got those garbled `val "\0x256c\(0x2593)5"` terms in the first

> `solve` example. This correctly gives οΏ½5 (\beta 5) over here. Maybe the

> encoding of your reduce.pure file got messed up? Anyway, I already fixed
> that in the committed docs.
>
> Albert
>

Yes, sometimes I have to use it ;)
Windows and Unicode, that's a perpetual struggle. If I do a "type
reduce.pure" in the console the greek letters are displayed, so the file
is certainly ok. I've no clue for the moment how to get unicode output
work in the win console, although the settings are as recommended (chcp
65001, utf capable font, cmd/u, ...).

[John Cowan]

kp scripsit:

> Windows and Unicode, that's a perpetual struggle.

The key is "_setmode(_fileno(stdout), _O_U16TEXT);". See
<http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx>
for details. (Michael Kaplan is authoritative about Windows and
Unicode issues.)

--
John Cowan co...@ccil.org http://ccil.org/~cowan
If I have seen farther than others, it is because I am surrounded by dwarves.
--Murray Gell-Mann

[kp]

Am 09.10.2012 14:53, schrieb Albert Graef:
> On 10/09/2012 02:26 AM, kp wrote:
>> Well, I'm sometimes quite stupid. Forget the paragraph above. The
>> callbacks are of course entirely useless as it will be nothing more to
>> catch as we already see with the NULL's :(
>
> Well, it might still be useful to just get rid of the remaining output.

At any rate.

>
> This is all fixed in rev. fd7bc71c78bf. There are new functions
> reduce::capture, reduce::output and reduce::in (the latter automatically
> captures the output). So you can now just do:
>
> > using reduce;
> Reduce (Free CSL version), 09-Oct-12 ...
> > reduce::in "pure_tex.red";
> []
> > let r1 = simplify $ tex (df (x^n) x); r1;
> "$$\\frac{x^{n}\\cdot n}{x}$$"
>
> If you need to see the output produced by reduce::in:
>
> > reduce::output;
> "off echo $\n% TeX-REDUCE-Interface 0.70\n% set greek asserted\n% set
> lowercase asserted\n% set Greek asserted\n% set Uppercase asserted\n%
> \\tolerance 10\n% \\hsize=150mm\n"

That's far more convenient, indeed, so one has not to care with "$'s"
and "echoes" in the source files.

>
> *Hint Hint* This might be worth a section in the Examples by Topics?
>

Of course, there are also some others I have on the agenda.

> While I was at it, I also fixed the truncated string buffer issue. So
> big return strings from your `tex` function shouldn't be an issue any more.
>
> Note that all this requires some fixups and extensions to the PROC
> interface which are in proc-add.c now. A recompile is needed (drop
> reduce-algebra into pure-reduce and run `make && sudo make install`).
>

The build process is very clean! Ubuntu was no problem, only
Windows/MinGW complained (see attached make.log.gz). Image and Exe were
built, only the DLL part stuck.

> Eventually we should probably give that whole PROC interface a serious
> facelift to fix its most annoying quirks, such as the crashes on invalid
> Lisp code.

Well, I don't object :)

>
>> What really could be promising is the following observation:
>>
>>> reduce::execute_lisp_function "oem-supervisor" NULL NULL ;
>
> That oem-supervisor thingy seems pretty useful. ;-) Is it documented
> somewhere?

I found it in csl/cslbase/extras.red (line 68). It's just a simple REP.

--------
% The following small function is just used for testing the CSL OEM
% interface code...

symbolic procedure oem!-supervisor();
print eval read();

--------

>
> I've added support for that as well, so you can now just run
> oem-supervisor like this (as a bonus, you'll also get the Lisp result as
> a Pure value):
>
> > lisp (lispsym "oem-supervisor");
> (aeval 'a)
> (!*sq ((((a . 1) . 1)) . 1) t)
> [_sq,[(a:1):1]:1,t]
>

Great.

> I also found this gem buried in the "Examples by Topics":
>
>> > simplify $ pf f x;
>> [2/(x+2),(-2)/(x+1),2/(((x:1):1):1)^2] // (x+1)^2 ???
>
> This is rather interesting since there's a kernel in a standard form
> here which is itself a standard form. The Reduce docs aren't really
> clear on whether that kind of recursion is intended, so I thought it was
> forbidden. But it's fixed in rev. 3c8a4193b1bd:
>
> > reduce::switch "exp" 0;
> 0
> > let f = 2/((x+1)^2*(x+2));
> > simplify $ pf f x;
> [2/(x+2),(-2)/(x+1),2/(x+1)^2]
>
> I hope that this doesn't break anything -- the tests all pass, though,
> so we should be fine (FLW). :)
>
> Albert
>

All tests passed on my side too.
I'll try the win version as soon as it works again.
Kurt

[Albert Graef]

On 10/09/2012 02:53 PM, Albert Graef wrote:
> This is all fixed in rev. fd7bc71c78bf. There are new functions
> reduce::capture, reduce::output and reduce::in (the latter automatically
> captures the output). So you can now just do:

Feeding input to Reduce is now also supported, as of rev. dafae5303265.
Example:

> using reduce;
Reduce (Free CSL version), 09-Oct-12 ...

> lispeval s::string = res when
> reduce::feed s;
> res = lisp (lispsym "oem-supervisor");
> end;
> lispeval "(print '(a b c d))";
(a b c d)
(a b c d)
[a,b,c,d]
> lispeval "(aeval 'a)";

(!*sq ((((a . 1) . 1)) . 1) t)
[_sq,[(a:1):1]:1,t]

> reduce::capture 1;
0
> lispeval "(aeval 'a)";

[_sq,[(a:1):1]:1,t]

[kp]

Am 09.10.2012 20:06, schrieb John Cowan:
> kp scripsit:
>
>> Windows and Unicode, that's a perpetual struggle.
>
> The key is "_setmode(_fileno(stdout), _O_U16TEXT);". See
> <http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx>
> for details. (Michael Kaplan is authoritative about Windows and
> Unicode issues.)
>

@John
Thank you for the link, though I didn't grasp it yet.
I suppose the "key" goes to the main program? I tried it as inline C

stdin0.a03228:1:19: error: a parameter list without types is only
allowed in a
function definition
_setmode(_fileno(stdout), _O_U16TEXT);

[John Cowan]

kp scripsit:

> Thank you for the link, though I didn't grasp it yet.
> I suppose the "key" goes to the main program?

Yes, it needs to be done before any output is sent to stdout, so in the
C main program is the right place. Conditionalized with an #ifdef WIN32,
of course.

--
Real FORTRAN programmers can program FORTRAN John Cowan
in any language. --Ed Post co...@ccil.org