From: Kostas O. <k.o...@at...> - 2014-12-21 17:27:12
|
Does anyone else have these problems? Kostas Reduce (Free CSL version), 21-Dec-14 ... 1: set(mkid(a,4), "junk"); ***** String junk invalid as identifier 2: set(mkid(a,4), mat(0,1,2,3)); Memory access violation detected % Should be syntax error? 3: clear a4; 4: set(mkid(a,4), mat((0,1,2,3))); ***** [0 1 2 3] invalid as scalar 5: x := 1; x := 1 6: if x = 1 then rederr {"Can't be:", x}; ***** list Can't be: 1 % Where does "list" come from? 7: |
From: Rainer S. <rai...@gm...> - 2014-12-21 19:27:07
|
On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote: > Does anyone else have these problems? Don't worry, I see the same behaviour (in PSL). > 1: set(mkid(a,4), "junk"); > > ***** String junk invalid as identifier The "set" operator is implemented separately and differently from an assignment. This is surprising and should be changed. > 2: set(mkid(a,4), mat(0,1,2,3)); > > Memory access violation detected This has nothing to do with set. mat(0,1,2,3); alone exhibits the same behaviour. It should be a syntax error, but there is some interaction with autoloading the matrix package - which is why it works the second time. I have just committed a correction. > 5: x := 1; > > x := 1 > > 6: if x = 1 then rederr {"Can't be:", x}; > > ***** list Can't be: 1 > > % Where does "list" come from? It's the internal representaion of {"Can't be:", x} which is (list "Can't be:" x) Rainer |
From: Eberhard S. <esc...@ca...> - 2014-12-21 22:01:51
|
On 12/21/2014 08:26 PM, Rainer Schöpf wrote: > On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote: > > > Does anyone else have these problems? > > Don't worry, I see the same behaviour (in PSL). > > > 1: set(mkid(a,4), "junk"); > > > > ***** String junk invalid as identifier > > The "set" operator is implemented separately and differently from an assignment. > This is surprising and should be changed. Semantically they are different things. It is similar to setq and set on the Lisp level. The restriction that the second argument in the algebraic set command must be a scalar expression, however, would be worth a generalization (I don't have the time at the moment for that though). Eberhard > > > 2: set(mkid(a,4), mat(0,1,2,3)); > > > > Memory access violation detected > > This has nothing to do with set. > > mat(0,1,2,3); > > alone exhibits the same behaviour. It should be a syntax error, but there is > some interaction with autoloading the matrix package - which is why it works the > second time. I have just committed a correction. > > > 5: x := 1; > > > > x := 1 > > > > 6: if x = 1 then rederr {"Can't be:", x}; > > > > ***** list Can't be: 1 > > > > % Where does "list" come from? > > It's the internal representaion of {"Can't be:", x} which is > > (list "Can't be:" x) > > Rainer > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: Arthur N. <ac...@ca...> - 2014-12-21 20:59:25
|
Firstly I observe that on version sof Reduce from some while back mat(0,1,2,3); crashes on both CSL and PSL. As explained in the manual if you wanted a single row matrix you would have needed to write mat((0,1,2,3)) with an extra pair of parens. If you yse bootstrapreduce rather than redcsl or redpsl then all car/cdr accesses are checked and you can get a slighly clearer diagnostic. $ bin/bootstrapreduce -w Reduce (Free CSL version), 20-Nov-14 ... 1: on backtrace; 2: mat(0,1,2,3); +++ Error attempt to take car of an atom: 0 Inside: formlis Arg1: 0 Arg2: nil Arg3: algebraic Inside: formmat Arg1: (mat 0 1 2 3) Arg2: nil Arg3: algebraic Arg1: (mat 0 1 2 3) Arg2: nil Arg3: algebraic apply: formmat Inside: form1 Arg1: (mat 0 1 2 3) Inside: command and perhaps as a result of your example we will check that the syntax is correct rather than assuming that people do the right thing! The issue of trying to set something to a string is related to the fact that the code that imlements SET works using let0 ... simp!* ... and the creation there of a form (!*sq ...) manually using mk!*sq means that the RHS has to be something that can be a genuine algebraic expression. And strings can not. It MIGHT be possible to change let0 list(list('equal,x,mk!*sq(u := simp!* cadr u))); return u into a call something along the lines of setk(x, u := aeval cadr u); return simp!* u but I am really not comfortable enough that I understand all potential ramifications and consequences to drop everything now and consider such a change. Even though use of SET may be really uncommon I would not wish to break some other use of it by trying to mend this case. Strings are mostly there in Reduce just to be directly printed! So in short, I believe that the behaviour you report is long standing and not a trivial glitch to slap an easy band-aid on. Arthur On Sun, 21 Dec 2014, Kostas Oikonomou wrote: > Does anyone else have these problems? > > Kostas > > > Reduce (Free CSL version), 21-Dec-14 ... > > 1: set(mkid(a,4), "junk"); > > ***** String junk invalid as identifier > > 2: set(mkid(a,4), mat(0,1,2,3)); > > Memory access violation detected > > % Should be syntax error? > > 3: clear a4; > > 4: set(mkid(a,4), mat((0,1,2,3))); > > ***** > > [0 1 2 3] > > invalid as scalar > > 5: x := 1; > > x := 1 > > 6: if x = 1 then rederr {"Can't be:", x}; > > ***** list Can't be: 1 > > % Where does "list" come from? > > 7: > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
From: Kostas O. <ko...@re...> - 2014-12-21 22:41:48
|
The set(mkid()) is not a critical problem/bug for me, but I did want to report it. However, the rederr behavior didn't use to occur in earlier versions of Reduce, and it is a problem. Agreed? 8: x := 123; x := 123 9: rederr {"My value is", x}; ***** list My value is 123 (By the way, I changed my subscription address because Arthur was experiencing email bounces.) Kostas On 12/21/2014 17:01, Eberhard Schruefer wrote: > On 12/21/2014 08:26 PM, Rainer Schöpf wrote: >> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote: >> >> > Does anyone else have these problems? >> >> Don't worry, I see the same behaviour (in PSL). >> >> > 1: set(mkid(a,4), "junk"); >> > >> > ***** String junk invalid as identifier >> >> The "set" operator is implemented separately and differently from an assignment. >> This is surprising and should be changed. > Semantically they are different things. It is similar to setq and set on > the Lisp level. > The restriction that the second argument in the algebraic set command > must be a scalar expression, however, > would be worth a generalization (I don't have the time at the moment for > that though). > > Eberhard > >> > 2: set(mkid(a,4), mat(0,1,2,3)); >> > >> > Memory access violation detected >> >> This has nothing to do with set. >> >> mat(0,1,2,3); >> >> alone exhibits the same behaviour. It should be a syntax error, but there is >> some interaction with autoloading the matrix package - which is why it works the >> second time. I have just committed a correction. >> >> > 5: x := 1; >> > >> > x := 1 >> > >> > 6: if x = 1 then rederr {"Can't be:", x}; >> > >> > ***** list Can't be: 1 >> > >> > % Where does "list" come from? >> >> It's the internal representaion of {"Can't be:", x} which is >> >> (list "Can't be:" x) >> >> Rainer >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: Eberhard S. <esc...@ca...> - 2014-12-21 23:12:25
|
On 12/21/2014 11:41 PM, Kostas Oikonomou wrote: > The set(mkid()) is not a critical problem/bug for me, but I did want to > report it. > > However, the rederr behavior didn't use to occur in earlier versions of > Reduce, and it is a problem. > Agreed? Are you sure or did you call rederr in symbolic mode before? > > 8: x := 123; > > x := 123 > > 9: rederr {"My value is", x}; > > ***** list My value is 123 > > > (By the way, I changed my subscription address because Arthur was > experiencing email bounces.) > > Kostas > > > On 12/21/2014 17:01, Eberhard Schruefer wrote: >> On 12/21/2014 08:26 PM, Rainer Schöpf wrote: >>> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote: >>> >>> > Does anyone else have these problems? >>> >>> Don't worry, I see the same behaviour (in PSL). >>> >>> > 1: set(mkid(a,4), "junk"); >>> > >>> > ***** String junk invalid as identifier >>> >>> The "set" operator is implemented separately and differently from an assignment. >>> This is surprising and should be changed. >> Semantically they are different things. It is similar to setq and set on >> the Lisp level. >> The restriction that the second argument in the algebraic set command >> must be a scalar expression, however, >> would be worth a generalization (I don't have the time at the moment for >> that though). >> >> Eberhard >> >>> > 2: set(mkid(a,4), mat(0,1,2,3)); >>> > >>> > Memory access violation detected >>> >>> This has nothing to do with set. >>> >>> mat(0,1,2,3); >>> >>> alone exhibits the same behaviour. It should be a syntax error, but there is >>> some interaction with autoloading the matrix package - which is why it works the >>> second time. I have just committed a correction. >>> >>> > 5: x := 1; >>> > >>> > x := 1 >>> > >>> > 6: if x = 1 then rederr {"Can't be:", x}; >>> > >>> > ***** list Can't be: 1 >>> > >>> > % Where does "list" come from? >>> >>> It's the internal representaion of {"Can't be:", x} which is >>> >>> (list "Can't be:" x) >>> >>> Rainer >>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Reduce-algebra-developers mailing list >>> Red...@li... >>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers |
From: Kostas O. <ko...@re...> - 2014-12-21 23:20:43
|
10: eval_mode; algebraic 11: x := 123; x := 123 12: rederr {"My value is", x}; ***** list My value is 123 13: On 12/21/2014 18:12, Eberhard Schruefer wrote: > On 12/21/2014 11:41 PM, Kostas Oikonomou wrote: >> The set(mkid()) is not a critical problem/bug for me, but I did want to >> report it. >> >> However, the rederr behavior didn't use to occur in earlier versions of >> Reduce, and it is a problem. >> Agreed? > Are you sure or did you call rederr in symbolic mode before? > >> |
From: Arthur N. <ac...@ca...> - 2014-12-21 23:21:08
|
On Sun, 21 Dec 2014, Kostas Oikonomou wrote: > The set(mkid()) is not a critical problem/bug for me, but I did want to > report it. Yes by all means report things. > However, the rederr behavior didn't use to occur in earlier versions of > Reduce, and it is a problem. > Agreed? No I do not agree. I just dug out a binary using revision 2120 dates 2013-07-09 and see the same behaviour. If you look in the manual you will see that what it says about rederr there takes a string so you are going beyond that there. However I see a number of places in the Reduce source code that go rederr {blah, blah, blah}; that you have presumably spotted and are copying. But what you will (I rather believe) find is different is that they are all in symblic mode code where actually I would never write "{" and "}" but would go rederr list(blah, blah, blah) so I knew just what I was saying. By using rederr in algebraic mode you are getting its argument treated in algebraic mode but rederr does not have any clever processing to handle that - it just takes the actual argument you are passing as a bit of Lisp style data and displays it in a fairly naive manner. If it is a Lisp style list it displays eack item in it in turn. Now the algebraic mode list you create by using { blah, blah } in algebraic mode code has the keyword "list" on the front so that the reduce algebra engine can know what it is. The rederr function is displaying this. You will see similar oddities if you try rederr ((x+6)^10); where you will see a sequence ot items each being consecutive items in the data structure representing the expression. So you see "plus" then (expt x 10) and so on down to eventually 60466176. Now if you think that the example you give "worked in a previous version" by the magic of subversion you can go svn -r NNNN update to take your locally checked out version down to revision NNNN. Then rebuild and test. When I need to do this I tend then to do binary search to narrow down the exact revision where something changed, and that lets me see who changed something when to alter behaviour. That lets me see what they were doing at the time and allows me to explore why the effect I see has happened! > > 8: x := 123; > > x := 123 > > 9: rederr {"My value is", x}; > > ***** list My value is 123 > The following shows both that rederr is not designed to display algebraic chunks in a message and how you can call it so that the value of an algebraic mode variable is retrieved and converted to a prefix representation for you... Reduce (Free CSL version), 18-Dec-14 ... 1: a := 22/7; 22 a := ---- 7 2: rederr {"my value is", a}; ***** list my value is (quotient 22 7) 3: lisp rederr {"my value is", prepsq simp aeval 'a}; ***** my value is (quotient 22 7) > > (By the way, I changed my subscription address because Arthur was > experiencing email bounces.) Thank you very much for that. > > Kostas > > > On 12/21/2014 17:01, Eberhard Schruefer wrote: >> On 12/21/2014 08:26 PM, Rainer Schöpf wrote: >>> On Sun, 21 Dec 2014 at 12:27 -0500, Kostas Oikonomou wrote: >>> >>> > Does anyone else have these problems? >>> >>> Don't worry, I see the same behaviour (in PSL). >>> >>> > 1: set(mkid(a,4), "junk"); >>> > >>> > ***** String junk invalid as identifier >>> >>> The "set" operator is implemented separately and differently from an assignment. >>> This is surprising and should be changed. >> Semantically they are different things. It is similar to setq and set on >> the Lisp level. >> The restriction that the second argument in the algebraic set command >> must be a scalar expression, however, >> would be worth a generalization (I don't have the time at the moment for >> that though). >> >> Eberhard >> >>> > 2: set(mkid(a,4), mat(0,1,2,3)); >>> > >>> > Memory access violation detected >>> >>> This has nothing to do with set. >>> >>> mat(0,1,2,3); >>> >>> alone exhibits the same behaviour. It should be a syntax error, but there is >>> some interaction with autoloading the matrix package - which is why it works the >>> second time. I have just committed a correction. >>> >>> > 5: x := 1; >>> > >>> > x := 1 >>> > >>> > 6: if x = 1 then rederr {"Can't be:", x}; >>> > >>> > ***** list Can't be: 1 >>> > >>> > % Where does "list" come from? >>> >>> It's the internal representaion of {"Can't be:", x} which is >>> >>> (list "Can't be:" x) >>> >>> Rainer >>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Reduce-algebra-developers mailing list >>> Red...@li... >>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Reduce-algebra-developers mailing list >> Red...@li... >> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Reduce-algebra-developers mailing list > Red...@li... > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers > |
From: Kostas O. <ko...@re...> - 2014-12-21 23:33:27
|
On 12/21/2014 18:21, Arthur Norman wrote: > >> However, the rederr behavior didn't use to occur in earlier versions of >> Reduce, and it is a problem. >> Agreed? > > No I do not agree. I just dug out a binary using revision 2120 dates > 2013-07-09 and see the same behaviour. > > If you look in the manual you will see that what it says about rederr > there takes a string so you are going beyond that there. Yes, the manual says that. The Melenk "Primer" in sec. 6.1 has the usage I'm talking about. But I now see it is referring to usage in symbolic mode. I have used rederr {...} before, but I guess all of the usages were in symbolic mode, and it's not a version issue. I got mixed up. But the now the question is, how can I issue the same kind of error message in algebraic mode? All I can think of is write "my value is", x; rederr ""; But that's awkward. Kostas |
From: Arthur N. <ac...@ca...> - 2014-12-22 09:37:28
|
>> If you look in the manual you will see that what it says about rederr >> there takes a string so you are going beyond that there. > > Yes, the manual says that. The Melenk "Primer" in sec. 6.1 has the > usage I'm talking about. But I now see it is referring to > usage in symbolic mode. I have used rederr {...} before, but I guess > all of the usages were in symbolic mode, and it's not a version issue. > I got mixed up. > > But the now the question is, how can I issue the same kind of error > message in algebraic mode? > All I can think of is > > write "my value is", x; > rederr ""; > > But that's awkward. > > Kostas I observe that I can generate a diagnostic as follows 1: deg (sin x/cos y, x); sin(x) ***** -------- invalid as polynomial cos(y) so you can track through and see the (symbolic mode) code for the function typerr that arranges to be able to embed an algebraic expression within a message that gets sent back to the user. Raising a diagnostic with simple things in it is not too hard and MANY places in Reduce arrange that the message that gets issued is little more than a string. Doing more complicated things is more complicated!!!! Futhermore you raising this causes me to look further and the code for typerr in alg/intro.red, while messy. is still not good enough becuse the test on outputhandler!* leads to it displaying ugly output when "on fancy" is active. I am not going to view improving that as a high priority, but I do present it to you as an indication that while you may believe that what you think you want to do is obvious and simple it is not as trifling as you might have hoped. [with "on fancy" the above example says ***** (quotient (sin x) (cos x)) invalid as a polynomial rather than displaying the expression with infix operators and raised exponents...] So unless you want to delve fully deeply into the Reduce sources and see all the things that could interact with mathematical display your easiest solution is to arrange that the diagnostic you issue is merely a simple message without any embedded expressions. I have not looked at (and am not about to either) other places where other authors have called rederr to see how disciplined they have been or to work out exactly what the boundaries are of what can be coped with - that looks like a longer job than I have time for just now! Arthur |
From: Kostas O. <ko...@re...> - 2014-12-22 16:38:21
|
On 12/22/2014 04:37, Arthur Norman wrote: >> > > I observe that I can generate a diagnostic as follows > > 1: deg (sin x/cos y, x); > > sin(x) > ***** -------- invalid as polynomial > cos(y) > > so you can track through and see the (symbolic mode) code for the > function typerr that arranges to be able to embed an algebraic > expression within a message that gets sent back to the user. > > Raising a diagnostic with simple things in it is not too hard and MANY > places in Reduce arrange that the message that gets issued is little > more than a string. Doing more complicated things is more complicated!!!! > Futhermore you raising this causes me to look further and the code for > typerr in alg/intro.red, while messy. is still not good enough becuse > the test on outputhandler!* leads to it displaying ugly output when > "on fancy" is active. I am not going to view improving that as a high > priority, but I do present it to you as an indication that while you > may believe that what you think you want to do is obvious and simple > it is not as trifling as you might have hoped. No doubt. But we do have a conflict here between what a user regards as "simple" or "trifling", and the intricacies of the system's implementation. And I say this with some experience in developing software of my own, and hearing comments from people that have tried using it. What I regard as subtleties others regard as nuisances. > > [with "on fancy" the above example says > ***** (quotient (sin x) (cos x)) invalid as a polynomial > rather than displaying the expression with infix operators and raised > exponents...] > > So unless you want to delve fully deeply into the Reduce sources and > see all the things that could interact with mathematical display your > easiest solution is to arrange that the diagnostic you issue is merely > a simple message without any embedded expressions. I am all for simplicity, but useability is an important factor. Here is my ugly solution for the time being: symbolic(rederr {<string>, x, <string>}); This, coupled with a 'share' declaration for x, works in all the (algebraic) cases I've tried it. > I have not looked at (and am not about to either) other places where > other authors have called rederr to see how disciplined they have been > or to work out exactly what the boundaries are of what can be coped > with - that looks like a longer job than I have time for just now! > > Arthur > |