reduce-algebra-developers — Discussion of development, administration and support for Reduce

[Reduce-algebra-developers] reduce at Mac OSX

[Zhongbo K. <ka...@gm...>]

Dear all,

I am not sure if any of you encounter the following problem:

I have installed REDUCE at my Mac (build from the source). However, every time when I update my Mac OSX system (automatically by Mac Software update), then my reduce will NOT work any more. When I run reduce, it will return the error message telling that there is no build version of reduce. So I have to rebuild every time when I update Mac OSX, it gets really annoying.

Any ideas?

Best,
Kang

[Reduce-algebra-developers] Number of nested substitutions

[Raffaele V. <raf...@un...>]

Dear All,

I should solve a system of equations where a set of variables are 
substituted by expressions which, in turn, can contain variables from 
the same set to be substituted. This does not lead me to 'circular' 
substitutions or to new conditions because of some theoretical 
principles under which the system is built. Substitutions are 
implemented as a sequence of `let a=b' rules.

However, it seems to me that the number of these substitutions slows 
down the computation too much. So, my question is if there exists a way 
(like an internal parameter) to measure the number of nested 
substitutions and/or a faster way to do substitutions than `let' rules, 
such as a way to get rid of nested substitutions before using 
substitutions in computations.

Best regards, Raffaele.

--
Raffaele Vitolo, Dipartimento di Matematica 'E. De Giorgi'
Universita' del Salento, via per Arnesano 73100 Lecce ITALY
tel.: +39 0832 297425 (office) fax.: +39 0832 297594
home page: http://poincare.unisalento.it/vitolo

Re: [Reduce-algebra-developers] Use of t and nil in Reduce

[Rainer S. <rai...@gm...>]

It turns out that mapping external to internal identifiers isn't so simple. A 
fair number of the user contributed packages need to be changed to work with it, 
because they define their own statement parsing or because they do clever things 
with identifiers like explode/compress or mkid.

So, I checked in a workaround for the original bug with t as a free variable in 
rules and a regression test for various valid or invalid uses of t and nil.

  Rainer

Re: [Reduce-algebra-developers] Use of t and nil in Reduce

[Rainer S. <rai...@gm...>]

On Thu, 20 Oct 2011 at 22:15 +0100, Arthur Norman wrote:

 > > Agreed, though redefining algid isn't enough: it is not applied to
 > > procedure
 > > parameters, local variables or free variables in rules. Ie. formblock,
 > > formproc
 > > and forall need to be changed as well.
 > > 
 > Indeed - but we could do it!

Yes - though a closer inspection shows that more functions in form.red need to 
be changed, formsetq among them.  In particular, nil is more work than t (or 
anything else).  For example, an empty statement

 ;

is parsed in the same way as

 nil;

(giving both no output in algebraic mode), and simply mapping nil to some 
internal identifier means that both statements will always print

nil

irregardless of the current mode.

As a first step, I corrected the bug reported in the SourceForge forum and added 
a couple of error checks for cases like using nil as a free variable in rules or 
trying to share t between algebraic and symbolic mode.

 > > Should we also allow t and nil as procedure and operator names?
 > If we map them (in algebraic mode only) onto internal names that do not clash
 > with Lisp then there should be no problem. And I can imagine people using "t"
 > as a function name.

Yes.  t as algebraic operator seems to work already.

 > > (BTW: The window version of CSL prints parentheses around "fluid t", the
 > > command
 > > line version does not.)
 > That is interesting. I will put in 90% of the way down my pile of things that
 > I might check one day.

Yes, that seems the right place for it ;-)

  Rainer

Re: [Reduce-algebra-developers] Use of t and nil in Reduce

[Rainer S. <rai...@gm...>]

On Thu, 20 Oct 2011 at 19:43 +0100, Arthur Norman wrote:

 > If you switch "on comp" so that CSL compiles things I believe you will see
 > diagnostics (albeit not very nice ones) from your first two cases.
 > At the Lisp level it can not make sense to refuse to allow "e", "i" etc to be
 > local variables, or else
 >   for i := 1:n do ...
 > would be rejected and MANY people would be upset.

Yes, I didn't think of that.  

 > The symbols "nil" and "t" have special historical meanings at the level of
 > symbolic (lisp level) code and maybe for them "form" and friends could rename
 > them to something anodyne if seen in algebraic-level code so that for
 > ordinary algebraic users they would not be reserved any more. That MAY be as
 > easy as addint to the algid procedure in rlisp/form.red
 >   if u = nil then 'algebraic!:nil
 >   else if u = t then 'algebraic!:t
 >   else whatever it had before
 > and in a matching way arranging that printing new to map the internal names
 > back to what they were on input.

Agreed, though redefining algid isn't enough: it is not applied to procedure 
parameters, local variables or free variables in rules. Ie. formblock, formproc 
and forall need to be changed as well.

Printing t is easy, just add

 put('algebraic!-t,'oldnam,'t);

but this doesn't work for nil, as after

 put('algebraic!-nil,'oldnam,'nil);

get('algebraic!-nil,'oldnam) 

still returns nil.

Should we also allow t and nil as procedure and operator names?  At the moment 
nil doesn't work at all, and t cannot be a procedure in CSL:

procedure t(x);x;

***** fluid t invalid as procedure

(BTW: The window version of CSL prints parentheses around "fluid t", the command 
line version does not.)

No problem with disallowing both, but CSL and PSL should behave in the same way, 
with a slightly better error message like

***** reserved identifier t invalid as procedure

  Rainer

Re: [Reduce-algebra-developers] Use of t and nil in Reduce

[Arthur N. <ac...@ca...>]

If you switch "on comp" so that CSL compiles things I believe you will see 
diagnostics (albeit not very nice ones) from your first two cases.
At the Lisp level it can not make sense to refuse to allow "e", "i" etc to 
be local variables, or else
   for i := 1:n do ...
would be rejected and MANY people would be upset.

The symbols "nil" and "t" have special historical meanings at the level of 
symbolic (lisp level) code and maybe for them "form" and friends could 
rename them to something anodyne if seen in algebraic-level code so that 
for ordinary algebraic users they would not be reserved any more. That MAY 
be as easy as addint to the algid procedure in rlisp/form.red
   if u = nil then 'algebraic!:nil
   else if u = t then 'algebraic!:t
   else whatever it had before
and in a matching way arranging that printing new to map the internal 
names back to what they were on input.

For e, i, pi and possibly MANY others the most I feel one could do would 
be to consider a warning message. But the "for i := 1:n" example is close 
to enough to persuade me that even that will hurt at least as many people 
as it helps.

Arthur


On Thu, 20 Oct 2011, Rainer Schöpf wrote:

> The recent bug report
>
>  https://sourceforge.net/tracker/?func=detail&atid=1126256&aid=3426364&group_id=248416
>
> made me test how t and nil behave in algebraic mode. Try the following:
>
> algebraic procedure x(t); t;
> algebraic procedure y(nil); nil;
> algebraic procedure z(e);e;
> x(1);
> y(1);
> z(1);
>
> CSL returns 1 in all cases, PSL replies with
>
> ***** T and NIL cannot be rebound
>
> in the first two.
>
> I think the use of reserved identifiers as formal parameters or free variables
> in a rule should lead to an error.
>
>    Rainer
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>

Re: [Reduce-algebra-developers] Use of t and nil in Reduce

[Rainer S. <rai...@gm...>]

Addendum: For real fun, try

operator fun;
for all nil let fun(nil)=nil;

 Rainer

[Reduce-algebra-developers] Use of t and nil in Reduce

[Rainer S. <rai...@gm...>]

The recent bug report

  https://sourceforge.net/tracker/?func=detail&atid=1126256&aid=3426364&group_id=248416

made me test how t and nil behave in algebraic mode. Try the following:

algebraic procedure x(t); t;
algebraic procedure y(nil); nil;
algebraic procedure z(e);e;
x(1);
y(1);
z(1);

CSL returns 1 in all cases, PSL replies with

***** T and NIL cannot be rebound

in the first two.

I think the use of reserved identifiers as formal parameters or free variables 
in a rule should lead to an error.

    Rainer

[Reduce-algebra-developers] wxWidgets...

[Arthur N. <ac...@ca...>]

I have put a *PATCHED* set of wxWidgets sources in 
trunk/csl/support-patches and so feel I should record what I have done and 
why. The changes are to provide what I hope is a nicer interface for 
registering application specific fonts, and to make those available with 
wxGraphicsContext under Windows. This does not apply to the default built 
of CSL-reduce - just to what happens if you go ./configure --with-csl 
--with-wx to get my experimental unfinished development version. I have 
tried submitting my changes to wxWidgets so I hope that at some stage they 
will adopt them or provide their own better solution.

Now compiling wxWidgets takes a reasonable age - especially on Windows 
using cygwin's i686-w64-mingw32-g++. Thus I try to avoid it getting 
compiled at all often since I hope and expect it to remain stable. But to 
get the new snapshot this is what you need to do
    cd ..../trunk
    rm -rf csl/wxWidgets
    ./configure --with-csl --with-wxWidgets

The configure step will spot that the unpacked directory of wxWidgets 
sources is not in the csl directory so will find a .tar.bz2 file in 
csl/support-packages and unpack it and configure it. One thing to note is 
that the survive with my patch on a Windows machine you *MUST* arrange to 
have gdiplus headers where your C compiler can find them. The 
i686-w64-mingw32 set of headers at the time of sending this message seem 
not to so I needed to copy some in from elsewhere. If you do not pay 
attention to this then wxWidgets will configure without support for 
wxGraphicsContext and the stuff I am now developing will not even build.

              Arthur

Re: [Reduce-algebra-developers] problem building reduce.img

[Arthur N. <ac...@ca...>]

On Sun, 2 Oct 2011, Aditya Narayan wrote:
> I tried to build the reduce.img for the embedded reduce using the following:

> cd csl/embedded
> ./reduce -w -z -Dno_init_file ../cslbase/buildreduce.lsp -D@srcdir=../cslbase
> \ -o reduce.img
> The result is that it builds a file that's only 278k big. And exactly the
> same happens on both MacOS X and Linux:


Apologies. So there are two parts to my answer.

Firstly the embedded sub-directory contains a snapshot of all the files 
from cslbase, so does not automatically get updated as csl does. I needed 
to update fns2.c to add an nreverse2 function... but after a while I had 
made a new-embedded directory that tries a little harder to be robust. In 
fact it was not and I had to fix something there too. I hope I have 
checked in a new version....

OK first re new-embedded. The main system used GNU autoconf (ie a 
"configure" script) to adapt to the machine being used. That has 
advantages but is messy and complicated and slow. The "embedded" directory 
sidesteps this two ways. First it tries to use only conservative C code. 
Secondly it provides a hand-crafted "config.h" file. I had added a 
BUILTFOR predefined to the main config.h that lets one report something 
about the current system. I had not put that in the hand-crafted config.h. 
I have now! In general the "embedded" and "new-embedded" are for people 
who will be looking hard at the C code so they can extend it or use it ion 
an odd way - they may then wish to look at config.h from time to to time 
to adapt it to the platform that natters most to them. And then MAYBE look 
at "#ifndef EMBEDDED" line in the main csl/cslbase sources if they wish to 
re-activate something I disabled in the name of simple portability...

OK now back to embedded and why it was so delicate that I invented 
new-embedded. The CSL Reduce compiles some stuff from Reduce/Lisp into C 
to make files u01.c, u01.lsp etc. Actually embedded sort of expected that 
you made a full Reduce image using an up to date non-embedded system, then 
copied cslbuild/generated-c/u*.c to csl/embedded and then build the reduce 
executable there. As building the "full" system changes things the u*.c 
and u*.lsp files RAPIDLY get out of step. So to mend the build I went
    cd .../trunk
    cp cslbuild/generated-c/u*.c csl/embedded
(after I had build a "real" Reduce so that the files in generated-c has 
been updated properly).  The bad news is that if you try to build a 
reduce.img using the embedded version of reduce as per your attempt it 
used u*.c from csl/embedded and u*.lsp from cslbuild/generated-c and when 
they are not in step (ha ha) the compilation failes. You may see traces of 
that if you review a log of trying to build reduce.img that way.

Now more about embedded vs. new-embedded. To reduce delicacy, I have made 
the new-embedded version not use anything compiled into C. I have also 
provided samples there showing how to make a "mini" image as well as a 
"full" one, since people using Reduce embedded in any sense are liable to 
want to customise stuff. This makes new-embedded a bit slower. So that is 
maybe enough cause for me not to delete the old embedded. But I am *NOT* 
doing heavy maitenance on the files in "embedded". If you use it then 
please compare all C sources files with the ones in csl/cslbase in case 
there are updates that newer version of the Reduce sources rely on.... it 
is for "experts"!!!!

Hope this lengthy explanation gives enough elaboration that you can move 
forwards happily.
             Arthur

[Reduce-algebra-developers] problem building reduce.img

[Aditya N. <adi...@gm...>]

I tried to build the reduce.img for the embedded reduce using the following:


cd csl/embedded

./reduce -w -z -Dno_init_file ../cslbase/buildreduce.lsp -D@srcdir=../cslbase
\ -o reduce.img

The result is that it builds a file that's only 278k big. And exactly the
same happens on both MacOS X and Linux:

Any ideas will be appreciated. Thanks!

-- Message --


"**** **** REDUCE FULLY REBUILD **** ****";

% At this stage I have a complete workable REDUCE. If built using a
% basic CSL (I call it "bootstrapreduce" here)  nothing has been compiled
into C
% (everything is bytecoded), and it is big because it has retained all
% Lisp source code in the image file. If however I built using a version
% of CSL ("reduce") that did have things compiled into C then these will
% be exploited and the original Lisp source will be omitted from the
% image, leaving a production version.

bye;

+++ error: 99 "End-of-file read"
Leaving REDUCE ...

nil