I get an error message "g improperly defined in terms of itself", even
when the expression is preceded by the command "linelength 10000$"
What is going on here?
It is most improbable that linelength has any part of this since that is
only involved in influencing the format of output. Perhaps the statement
you include in your report is used in the context of some previous
computations one of which sets one of x1 to x9 to be an expression that
depends on g.. along the lines of
1: q := (r+1)^3;
3 2
q := r + 3r + 3r + 1
2: r := (q+1)^2;
* r improperly defined in terms of itself
When I put JUST the input you provide into a freshly started Reduce it
does not show trouble.
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps the statement
you include in your report is used in the context of some previous
computations one of which sets one of x1 to x9 to be an expression that
depends on g..
Unfortunately the problem still occurs in a fresh reduce session. The reduce accept the input but when I type g I get the error.
Update
What's unusual is that when I press the up arrow key reduce only recalls the first part of the expression
Unfortunately the problem still occurs in a fresh reduce session. The
reduce accept the input but when I type g I get the error.
Equally unfortunately when I transcribe your original "g := ..." statement
and put it into a fresh reduce that is accepted and duly echoed for me,
and when I then type just "g;" as my next input that again behaves.
So just to confirm - do you have a .reducerc file that does something
before you begin? Which platform are you on and exactly which version of
Reduce did you try. The one I have just used is the version I build
locally that I am developing on - so when it starts it says
redcsl -w
Reduce (CSL, rev 6406), 26-Oct-2022 ...
and I happen to be running this on Windows. I can not at present imagine a
reason why platform might matter and an certainly not aware of recent
changes that could have mended a glitch like that which existed earlier
so at present it is a bit of a mystery to me.
If instead of using an 8-line input you work through cases that include
the first N terms of the expression to see if eg merely "g := 2x1*2;"
causes you trouble and so on... and you might also try with the fresh
reduce just inputting "x1; x2; x3; ..." to reassure yourself that nothing
odd has happened.
I suppose I can note that if you have a "funny" reduce.img in the
directory you are in which was created using preserve() that could have
non-original stuff in it.
Also you might try bootstrapreduce which is expected to do just the same
things as Reduce but slower ... and if that behaves differently we will
not know why but we have an extra data point!
So I am still confused but this is listing all the thoughts for diagnosing
that I can think of.
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can confirm that I get the error message using Reduce CSL rev 6339 on Ubuntu, installed from the .deb package downloaded from Sourceforge. Only with the GUI version, in the command line it works. The error message is printed not when entering the expression, but when entering g; on a new command line.
If I "build up" g, i.e., I enter the first line of the expression into g, then add the remaining lines to it, as g := g + (next line stuff); then there is no error.
Last edit: arpi 2022-10-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I logged on to say this. (GUI version of reduce csl on Ubuntu
downloaded from Sourceforge.)
Thank you.
Eberhard and I have another hypothesis to try out on you.
Your input is all one line and you put it into Reduce using a PASTE
operation. Because it is over 512 (about) chars long the end gets lost,
and what goes into Reduce is only part of it - in particular not including
the final ";". So nothing very visible has happened!
But you then by hand type in "g;" to look to see if its is there - and
that forms the final part of the expression which now reads
g := LOADS OF STUFF g;
and you get a "defined in terms of itself" diagnostic.
If this is what is going on you would see a different behaviour if you
arranged that the long expression is presented as several lines rather
more as if it had been typed by a human and in particular such that each
line us under 600 chars long.
Does this now feel like an explanation? It is clearly not good that the
GUI limits input line lengths for people who PASTE in book-length formulae
without newlines. In the subversion repository I have checked in a change
that increases the limit from around 500 to around 2000 chars - fully
aware that this just moves the problem up a bit. But I could do that
rapidly and doing so let me check that it did let YOUR example formula
get entered. At some time I will need to look into the code more carefully
either to remove the limit or to make the system reject very long lines in
a properly visible way, but this week I am busy elsewhere and working
round by just presenting pre-split lines will often be easy.
Have we got this sorted?
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another possible solution might be to use my Run-REDUCE graphical user interface (GUI) instead of the CSL GUI. I just checked this using Ubuntu 20.04.5 LTS with Run-REDUCE running CSL REDUCE. I copied and pasted the assignment at the start of this thread into Run-REDUCE and it displayed it without any drama. I also copied and pasted the assignment into the CSL REDUCE GUI, which didn't display anything until I input a semicolon by hand and then displayed a clearly different assignment to g.
You can download and install Run-REDUCE on Ubuntu much as you would REDUCE itself (see the link above) and it should automatically pick up your REDUCE installation. The first time you run it, you could click on the REDUCE menu, select Auto-run REDUCE... and then select CSL REDUCE. After that, Run-REDUCE should behave much like the CSL REDUCE GUI. Probably the most obvious difference is that Run-REDUCE uses a separate input window, which you can hide if you want to maximise the area available to view REDUCE output. Run-REDUCE provides the same interface to CSL REDUCE, PSL REDUCE or (in principle) any other command-line implementation of REDUCE. Because Run-REDUCE is independent of CSL REDUCE it has its own independent set of bugs, so there is a reasonable chance that if one doesn't work properly the other one will!
Francis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I input a lengthy expression into reduce, e.g. below
g := 2*x1**2 - x1*x3 - 2*x1 + 2*x2**2 - x2*x4 + 2*x3**2 - x3 + 2*x4**2 - 4 + 2*x3**2 - x3*x5 - 5*x3 + 2*x4**2 - x4*x6 + 2*x5**2 - 4*x5 + 2*x6**2 + 2 + 2*x1**2 - x1*x3 - x1*x7 - 2*x1*x9 + 2*x10**2 - 2*x10*x2 - x10*x4 - x10*x8 + 2*x2**2 - x2*x4 - x2*x8 + 2*x3**2 - 2*x3*x7 - x3*x9 + 2*x4**2 - 2*x4*x8 + 2*x7**2 - x7*x9 + 2*x8**2 + 2*x9**2 - 6 + 2*x10**2 - x10*x12 - x10*x4 - 2*x10*x6 + 2*x11**2 - 2*x11*x3 - x11*x5 - x11*x9 + 2*x12**2 - 2*x12*x4 - x12*x6 + 2*x3**2 - x3*x5 - x3*x9 + 2*x4**2 - x4*x6 + 2*x5**2 - 2*x5*x9 + 2*x6**2 + 2*x9**2 - 6;I get an error message "g improperly defined in terms of itself", even when the expression is preceded by the command "linelength 10000$"
What is going on here?
On Wed, 26 Oct 2022, videohead wrote:
It is most improbable that linelength has any part of this since that is
only involved in influencing the format of output. Perhaps the statement
you include in your report is used in the context of some previous
computations one of which sets one of x1 to x9 to be an expression that
depends on g.. along the lines of
1: q := (r+1)^3;
q := r + 3r + 3r + 1
2: r := (q+1)^2;
* r improperly defined in terms of itself
When I put JUST the input you provide into a freshly started Reduce it
does not show trouble.
Arthur
Unfortunately the problem still occurs in a fresh reduce session. The reduce accept the input but when I type
gI get the error.Update
What's unusual is that when I press the up arrow key reduce only recalls the first part of the expression
g := 2*x1**2 - x1*x3 - 2*x1 + 2*x2**2 - x2*x4 + 2*x3**2 - x3 + 2*x4**2 - 4 + 2*x3**2 - x3*x5 - 5*x3 + 2*x4**2 - x4*x6 + 2*x5**2 - 4*x5 + 2*x6**2 + 2 + 2*x1**2 - x1*x3 - x1*x7 - 2*x1*x9 + 2*x10**2 - 2*x10*x2 - x10*x4 - x10*x8 + 2*x2**2 - x2*x4 - x2*x8 + 2*x3**2 - 2*x3*x7 - x3*x9 + 2*x4**2 - 2*x4*x8 + 2*x7**2 - x7*x9 + 2*x8**2 + 2*x9**2 - 6 + 2*x10**2 - x10*x12 - x10*x4 - 2*x10*x6 + 2*x11**2 - 2*x11*x3 - x11*x5 - x11*x9 + 2*x12**2 - 2*x12*x4 - x12*x6 + 2*x3**2 - x3*x5 - x3*x9 + 2*x4**2 - x4*x6 + 2*x5**2which it is able to accept. Could it be a restriction on the input expression?
BTW, I'm running the csl version of reduce.
Last edit: videohead 2022-10-26
So just to confirm - do you have a .reducerc file that does something
before you begin? Which platform are you on and exactly which version of
Reduce did you try. The one I have just used is the version I build
locally that I am developing on - so when it starts it says
redcsl -w
Reduce (CSL, rev 6406), 26-Oct-2022 ...
1: g := 2x12 - x1x3 - 2x1 + 2x22 - x2x4 + 2x32 - x3 + 2x4*2
...
and I happen to be running this on Windows. I can not at present imagine a
reason why platform might matter and an certainly not aware of recent
changes that could have mended a glitch like that which existed earlier
so at present it is a bit of a mystery to me.
If instead of using an 8-line input you work through cases that include
the first N terms of the expression to see if eg merely "g := 2x1*2;"
causes you trouble and so on... and you might also try with the fresh
reduce just inputting "x1; x2; x3; ..." to reassure yourself that nothing
odd has happened.
I suppose I can note that if you have a "funny" reduce.img in the
directory you are in which was created using preserve() that could have
non-original stuff in it.
Also you might try bootstrapreduce which is expected to do just the same
things as Reduce but slower ... and if that behaves differently we will
not know why but we have an extra data point!
So I am still confused but this is listing all the thoughts for diagnosing
that I can think of.
Arthur
I can confirm that I get the error message using Reduce CSL rev 6339 on Ubuntu, installed from the .deb package downloaded from Sourceforge. Only with the GUI version, in the command line it works. The error message is printed not when entering the expression, but when entering g; on a new command line.
If I "build up" g, i.e., I enter the first line of the expression into g, then add the remaining lines to it, as g := g + (next line stuff); then there is no error.
Last edit: arpi 2022-10-27
I logged on to say this. (GUI version of reduce csl on Ubuntu downloaded from Sourceforge.)
Thank you.
On Thu, 27 Oct 2022, videohead wrote:
Eberhard and I have another hypothesis to try out on you.
Your input is all one line and you put it into Reduce using a PASTE
operation. Because it is over 512 (about) chars long the end gets lost,
and what goes into Reduce is only part of it - in particular not including
the final ";". So nothing very visible has happened!
But you then by hand type in "g;" to look to see if its is there - and
that forms the final part of the expression which now reads
g := LOADS OF STUFF g;
and you get a "defined in terms of itself" diagnostic.
If this is what is going on you would see a different behaviour if you
arranged that the long expression is presented as several lines rather
more as if it had been typed by a human and in particular such that each
line us under 600 chars long.
Does this now feel like an explanation? It is clearly not good that the
GUI limits input line lengths for people who PASTE in book-length formulae
without newlines. In the subversion repository I have checked in a change
that increases the limit from around 500 to around 2000 chars - fully
aware that this just moves the problem up a bit. But I could do that
rapidly and doing so let me check that it did let YOUR example formula
get entered. At some time I will need to look into the code more carefully
either to remove the limit or to make the system reject very long lines in
a properly visible way, but this week I am busy elsewhere and working
round by just presenting pre-split lines will often be easy.
Have we got this sorted?
Arthur
Another possible solution might be to use my Run-REDUCE graphical user interface (GUI) instead of the CSL GUI. I just checked this using Ubuntu 20.04.5 LTS with Run-REDUCE running CSL REDUCE. I copied and pasted the assignment at the start of this thread into Run-REDUCE and it displayed it without any drama. I also copied and pasted the assignment into the CSL REDUCE GUI, which didn't display anything until I input a semicolon by hand and then displayed a clearly different assignment to g.
You can download and install Run-REDUCE on Ubuntu much as you would REDUCE itself (see the link above) and it should automatically pick up your REDUCE installation. The first time you run it, you could click on the REDUCE menu, select Auto-run REDUCE... and then select CSL REDUCE. After that, Run-REDUCE should behave much like the CSL REDUCE GUI. Probably the most obvious difference is that Run-REDUCE uses a separate input window, which you can hide if you want to maximise the area available to view REDUCE output. Run-REDUCE provides the same interface to CSL REDUCE, PSL REDUCE or (in principle) any other command-line implementation of REDUCE. Because Run-REDUCE is independent of CSL REDUCE it has its own independent set of bugs, so there is a reasonable chance that if one doesn't work properly the other one will!
Francis