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

You can subscribe to this list here.

 2009 2010 2011 2012 2013 2014 2015 2016 2017 Jan (2) Feb (5) Mar Apr May (2) Jun (8) Jul (4) Aug Sep Oct (2) Nov (6) Dec Jan (1) Feb (1) Mar (3) Apr (2) May (2) Jun (2) Jul (18) Aug (13) Sep (7) Oct Nov Dec (2) Jan Feb (11) Mar Apr (4) May Jun (1) Jul (18) Aug (16) Sep (12) Oct (12) Nov (19) Dec (42) Jan (16) Feb (3) Mar (8) Apr (14) May (30) Jun (5) Jul (7) Aug (3) Sep (10) Oct (4) Nov (10) Dec (1) Jan (14) Feb (8) Mar (5) Apr (3) May (9) Jun (19) Jul Aug (27) Sep (5) Oct (18) Nov (12) Dec (8) Jan (5) Feb (8) Mar (20) Apr (22) May (28) Jun (9) Jul (6) Aug (46) Sep (40) Oct (15) Nov (8) Dec (34) Jan (20) Feb (15) Mar (18) Apr (20) May (3) Jun (13) Jul (10) Aug (19) Sep (8) Oct (31) Nov (26) Dec (13) Jan (13) Feb (4) Mar (14) Apr (28) May (19) Jun (7) Jul (1) Aug Sep (19) Oct (5) Nov (4) Dec (9) Jan (4) Feb (30) Mar Apr (5) May Jun Jul Aug Sep Oct Nov Dec
S M T W T F S

1

2
(2)
3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19
(1)
20
(5)
21
(1)
22

23
(1)
24

25

26

27
(2)
28

29

30

31

Showing 12 results of 12

 [Reduce-algebra-developers] reduce at Mac OSX From: Zhongbo Kang - 2011-10-27 14:25:09 ```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 From: Raffaele Vitolo - 2011-10-27 14:02:33 ```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 From: Rainer Schöpf - 2011-10-23 19:42:54 ```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 From: Rainer Schöpf - 2011-10-21 16:38:58 ```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 From: Arthur Norman - 2011-10-20 21:15:43 ```> 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! > 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. I can only see 3 places in the sources where oldnam is inspected: in math/mprint.red, rprint/rprint.red and utf8/utf8.red so putting an explicit test in each of those for the mapped version of "nil" might be ugly but is not a huge risk maybe. Is at least protecting nil and t this way worth it? I suspect so... > > 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. > 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 This is because in CSL "t" is marked as a fluid variable and then the rlisp parser sees that as a type and moans. It appears that PSL treats "t" as so special that although it has a global (fixed) meaning it is neither fluid nor global, hence Reduce does not know to complain. Now whether being the name of a global or fluid variable should cause a refusal to allow something as a function name is another thought. The code that provoked the error will prevent names of matrices etc being used as procedure names. And back in the days when some Lisps had values and functions in the same cell one wanted this check. > (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. > > 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 > For "t" we possibly want special treatment for nil and t in symbolic mode, but I suspect I vote for internal renaming that means they become "not at all special" in algebraic mode... > Rainer > ```
 Re: [Reduce-algebra-developers] Use of t and nil in Reduce From: Rainer Schöpf - 2011-10-20 20:43:19 ```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 From: Arthur Norman - 2011-10-20 18:43:17 ```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@... Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Reduce-algebra-developers mailing list > Reduce-algebra-developers@... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >```
 Re: [Reduce-algebra-developers] Use of t and nil in Reduce From: Rainer Schöpf - 2011-10-20 17:30:39 ```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 From: Rainer Schöpf - 2011-10-20 17:27:30 ```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... From: Arthur Norman - 2011-10-19 10:37:17 ```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 From: Arthur Norman - 2011-10-02 19:29:50 Attachments: text/plain text/plain ```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@...=../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 From: Aditya Narayan - 2011-10-02 06:43:27 Attachments: Message as HTML ```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@...=../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 ```

Showing 12 results of 12