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

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

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

Another extract from the current packages/misc/rlfi.red:

flag('(!h!a!t !c!h!e!c!k !b!r!e!v!e !a!c!u!t!e !g!r!a!v!e !t!i!l!d!e
        !b!a!r !v!e!c !d!o!t !d!d!o!t hat check breve acute grave tilde
        bar vec dot ddot),'accdef);


I believe that this THINKS it is making "hat" and "HAT" (etc) have the 
accdef (or possibly ACCDEF) property. Well !h!a!t is certainly the word in 
lower case, but onthe next line I get that the author though that hat 
(without the escape characters) really meant HAT because they expected 
"on raise" to be active by default and for it to map lower to upper case. 
These days on PSL *raise will indeed be true but it case folds down, while 
on CSL !*raise will be nil by default, so for slighly different reasons 
what had been coded in around 1995 is very much out of step now and even 
at the time I think it will bave been slighly dubiuous. I have not 
considered whether accepting both HAT and hat makes sense but this 
suggests to me that the package there would rather like somebody who 
wanted to use it (especially if they like mixed case material) to adopt 
it, review it and tidy it up. I bet that on further inspectiaon 
collections of other aspects of the code there have suffered from age 
over the last 30 years...

However I suspect that if it is only used with lower case symbol names 
and the default values of *raise (and *lower) it may still be useful.

So this email is a request for volunteers to adopt this reasonably short 
(832 lines) and fairly self-contained module and bring it into the 21st 
century.

Arthur

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

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

On Wed, 5 Nov 2025, Prof Tony Roberts via Reduce-algebra-developers wrote:
> BTW if someone is tweaking  rlfi ..... if straightforward, could rlfi  take 
> note of the switch  revpri ?  It is a continual pain that all my asymptotic 
> power series are written to LaTeX in the wrong order.
>
> Tony
>
I *JUST* tweaked the *raise issue - I have not looked at rlfi beyond that. 
Again it is plausible that its original author did not consider revpri or 
maybe other flags that impact output formatting. The general policy here 
surely has to be that with Open Source software you can see the sources 
and if things are straightforward you are liable to be able to propose a 
patch that makes things support your needs better. The first couple of 
time you do that you submit your patch to us and we merge it in. On (say) 
the third time we probably grant you direct write access to the code-base.
A good thing about Reduce is that the source code is in the same language 
(more or less) as the user-level, and much of it is in fact pretty 
obvious.
If we take this path it gives at least a chance to grow the base of people 
who feel they can step up and do a bit of maintenance. If a very few of us 
always drop whatever else we are doing to put in (useful and sensible) 
enhancements that are suggested that may have short term benefits but may 
not be as good in the long term when one by one we are forced to drop out!

So please have a look and see if you can understand what is going on. You 
may be able to find help by serching for the word "!*revpri" in the source 
files that do printing not in TeX or it may turn out that in rlfi it will 
be obvious where the terms in a formula are being laid out and hence clear 
how to do so in the other order!

Good luck.

Arthur

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

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

On Wed, 5 Nov 2025, Prof Tony Roberts via Reduce-algebra-developers wrote:
> Hi,
>
> so does that mean  rlfi-package  has an inconsistency in that it turns off/on 
> *raise (which has effects in only psl) but does nothing with *lower (for 
> csl).   Surely it should seek the same effect for both,
>
> Tony
>
If you read my explanation of this you will have seen that when rlfi was 
written the world was often still in upper case, and !*lower did not exist 
or was unknown to the author. So yes there was an inconsistency that is (I 
hope) fixed by the checkin I made earlier this evening. Arthur

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

[Prof T. R. <Pro...@pr...>]

BTW if someone is tweaking  rlfi ..... if straightforward, could 
rlfi  take note of the switch  revpri ?  It is a continual pain that 
all my asymptotic power series are written to LaTeX in the wrong order.

Tony

On 6/11/2025 5:48 am, Prof Tony Roberts via 
Reduce-algebra-developers wrote:
> Hi,
>
> so does that mean  rlfi-package  has an inconsistency in that it turns off/on *raise (which has effects in only psl) but does nothing with *lower (for csl).   Surely it should seek the same effect for both,
>
> Tony
>
> On 5/11/2025 8:11 pm, Rainer Schöpf via Reduce-algebra-developers wrote:
> Hi,
>
> concerning your suggestion about the rlfi package I will commit a correction.
>
> Regarding the raise switch: In CSL Reduce, you need to set "off lower" instead -
> which in my opinion describes better what happens, namely not converting
> uppercase characters to lowercase.
>
> The behaviour of PSL is historical: originally Reduce was all uppercase. "On
> raise" meant to convert lowercase input to uppercase, and "on lower" meant to
> convert to lowercase on output. But at some point in the past PSL changed to
> lowercase internally. To avoid confusion, the switch raise was not renamed, but
> "on raise" means now to convert uppercase input to lowercase.
>
> Maybe we should implement a consistent interface and document it. The Reduce
> manual doesn't mention the raise switch except in the section about rlfi.
>
> Rainer
>
>
> On Wed, 5 Nov 2025 at 07:29 -0000, Prof Tony Roberts via Reduce-algebra-dev...:
>
>> Hi,
>>
>> I have come across two problems with Reduce trying to enable lower- and
>> upper-case together.  These occur with all three versions of Reduce that I
>> have access to, versions spanning releases over the last five years.
>>
>> * First, csl-reduce seems to ignore "off raise"---it has no effect that I can
>> see.  For example,
>>
>>> Reduce (CSL, rev 6657), 10-Dec-2023 ...
>>> 1: off raise;
>>> 2: (x+X)^6;
>>>      6
>>> 64*x
>> Whereas in psl,
>>
>>> Reduce (Free PSL version, revision 6864), build date 27-Aug-2024 ...
>>> 1: off raise;
>>> 2: (x+X)^6;
>>>   6      5         4  2       3  3       2  4        5    6
>>> X  + 6*X *x + 15*X *x  + 20*X *x  + 15*X *x  + 6*X*x  + x
>>
>> * Second, in the LaTeX rlfi package, the source of rlfi.red shows that the
>> latexoff procedure automatically sets "  !*raise:=t;" which turns on the
>> "raise" switch and so ruins any case sensitive algebra in progress.   Surely,
>> this procedure should be changed to restore what a user has set.
>>
>> That is, surely we prefer that procedure latexon stores a users choice of
>> "raise", and then latexoff restores the users choice. By no means fool-proof,
>> but more reasonable.
>>
>>
>> Tony
>>
>> --
>> ---------------------------------------------------------------------
>> Four books and a toolbox:
>>
>> * (2020) Linear Algebra for the 21st Century
>> Oxford University Press. isbn: 978-0-19-885640-5, 978-0-19-885639-9
>> https://global.oup.com/academic/product/linear-algebra-for-the-21st-century-9780198856399
>>
>> * (2015) Model emergent dynamics in complex systems
>> SIAM, Philadelphia. isbn: 9781611973556.
>> https://epubs.siam.org/doi/10.1137/1.9781611973563
>>
>> * (2009) Elementary calculus of financial mathematics
>> SIAM, Philadelphia. isbn: 978-0-898716-67-2.
>> https://epubs.siam.org/doi/10.1137/1.9780898718225
>>
>> * (1994) A one-dimensional introduction to continuum mechanics
>> World Sci. isbn: 978-981-02-1913-0.
>>
>> * (2020) with John Maclean, and J. E. Bunder; Equation-Free
>> function toolbox for Matlab/Octave.
>> http://github.com/uoa1184615/EquationFreeGit
>>
>> Emeritus Professor A.J. Roberts, FAustMS
>> School of Mathematical Sciences, University of Adelaide
>> https://profajroberts.github.io/<https://profajroberts.github.io>
>> mailto:Pro...@pr...
>> http://orcid.org/0000-0001-8930-1552
>>
>>
> Rainer Schöpf
>
> --
> ---------------------------------------------------------------------
> Four books and a toolbox:
>
> * (2020) Linear Algebra for the 21st Century
> Oxford University Press. isbn: 978-0-19-885640-5, 978-0-19-885639-9
> https://global.oup.com/academic/product/linear-algebra-for-the-21st-century-9780198856399
>
> * (2015) Model emergent dynamics in complex systems
> SIAM, Philadelphia. isbn: 9781611973556.
> https://epubs.siam.org/doi/10.1137/1.9781611973563
>
> * (2009) Elementary calculus of financial mathematics
> SIAM, Philadelphia. isbn: 978-0-898716-67-2.
> https://epubs.siam.org/doi/10.1137/1.9780898718225
>
> * (1994) A one-dimensional introduction to continuum mechanics
> World Sci. isbn: 978-981-02-1913-0.
>
> * (2020) with John Maclean, and J. E. Bunder; Equation-Free
> function toolbox for Matlab/Octave.
> http://github.com/uoa1184615/EquationFreeGit
>
> Emeritus Professor A.J. Roberts,  FAustMS
> School of Mathematical Sciences,  University of Adelaide
> https://profajroberts.github.io/
> mailto:Pro...@pr...
> http://orcid.org/0000-0001-8930-1552
>
-- 
---------------------------------------------------------------------
Four books and a toolbox:

* (2020) Linear Algebra for the 21st Century
Oxford University Press. isbn: 978-0-19-885640-5, 978-0-19-885639-9
https://global.oup.com/academic/product/linear-algebra-for-the-21st-century-9780198856399

* (2015) Model emergent dynamics in complex systems
SIAM, Philadelphia. isbn: 9781611973556.
https://epubs.siam.org/doi/10.1137/1.9781611973563

* (2009) Elementary calculus of financial mathematics
SIAM, Philadelphia. isbn: 978-0-898716-67-2.
https://epubs.siam.org/doi/10.1137/1.9780898718225

* (1994) A one-dimensional introduction to continuum mechanics
World Sci. isbn: 978-981-02-1913-0.

* (2020) with John Maclean, and J. E. Bunder; Equation-Free
function toolbox for Matlab/Octave.
http://github.com/uoa1184615/EquationFreeGit

Emeritus Professor A.J. Roberts,  FAustMS
School of Mathematical Sciences,  University of Adelaide
https://profajroberts.github.io/
mailto:Pro...@pr...
http://orcid.org/0000-0001-8930-1552

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

[Prof T. R. <Pro...@pr...>]

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

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

On Wed, 5 Nov 2025, Prof Tony Roberts via Reduce-algebra-developers wrote:
> Hi,
> I have come across two problems with Reduce trying to enable lower- and 
> upper-case together.  These occur with all three versions of Reduce that I 
> have access to, versions spanning releases over the last five years.
>
> * First, csl-reduce seems to ignore "off raise"---it has no effect that I can 
> see.  For example,
>
>> Reduce (CSL, rev 6657), 10-Dec-2023 ...
>> 1: off raise;
>> 2: (x+X)^6;
>>     6
>> 64*x

Let me report on this history and through that explain the current state:
In the beginning only upper case existed. Well when I started the 5-track 
teleprinter paper tape only had upper case, but the 7-track flexowriters 
that were only for use by those more senior to me not only had both cases 
but they could backspace and overtype to get yet more glyphs. So the world 
look4ed as if it was moving towards mixed vase. But then interactive 
servives began and the teletype model 33 took one back to upper case only. 
After a while "glass teletypes" supported both upper and lower case. Other 
places that used punched cards had similar experiences say until well 
through the 1960s with that legacy persisting very much beyond then.
So Lisp obviously started off as an upper case language and McCarthy's 
m-notation was usually expressed in lower case but did not go near a 
computer. So early REDUCE had all internal symbols in upper case. As lower 
case input devices became available it introduced a flag *raise such that 
if that was set all input was case folded into upper case. Output would be 
likely to come back in upper case.

Some years later use of upper case felt ugly and archaic so the PSL lisp 
system (with Reduce on its back) migrated to internal use of lower case 
for all the names of functions. In a way that is maybe odd it kept the 
variable *RAISE (or perhaps *raise??) but now made it fols things to lower 
case. The effect was that while *raise was set things continued to behave 
pretty much as they did. At that time and indeed for many years later the 
various packages making up Reduce sources and contributed from around the 
world were not tidy wrt case sensitivity. Some remained all in upper case.
In other cases the developers knew that case would be folded but for 
source code readability styled some of their identifiers in CamelCase or 
just Capiralized. But they were not 100% consistent in this.
When CSL (and its predecessor Cambridge Lisp) joined the fray it wanted to 
use lower case internally but it hated *raise doing a downcase, so it 
introduced a variable *lower that when set case folds input to lower case. 
That choice was made AGES ago now and perhaps before communication and 
discussion between people was as easy as it can be now - and anyway the 
expectation was that *lower would always be set so eveyrhing would 
continue to work as before.

Originally both *raise and *lower were global, so if some fragment of code
needed to disable case folding for a bit (eg after seeing a "!" while 
reading) it needed some mess like
    begin
      scalar save;
      save := !*raise;  (or !*lower or (!*raise . !*lower)!!!)
      do stuff
      !*rause := save
    end;
and if doing stuff exited with an error the *raise flag would not get 
repaired. So eventially CSL and PSL agreed to make both flags fluid not
global so the code could be
    begin
      scalar !*raise, !*lower;
      do stuff
    end;
and eg on PSL rebinding *fluid was meaningless but harmless. Changes 
through the sources to do things that way may or may not have caught all 
cases! Well your message points out that rlfi did not get reviewed, and I 
expect we will in the coming days!

The above is the long story. The short one is
(1)
   in PSL "off raise/on raise" enable or disable case sensitivity, but
          with "on raise" input gets folded to lower case not upper.
   in CSL "off lower/on lower" does much the same. And in CSL if you
          have "odd" combinations of both *raise and *lower set you may
          get what you deserve!
   with Common Lisp at the Lisp level usually a standard input map folds
          all input to upper case and then printing displays the upper
          case data in lower case again for you. But there are an amazing
          range of options to adjust precise behaviour. I think that the
          fact that in the 1980s the Common Lisp team ended up with that
          sort of excuses the Reduce confusion for having found input &
          output case a muddling issue.

(2) "rlfi" claims to date from 1995. The initial comments in its source 
read:
%*****   Program can be used only on systems supporting lower     ******
%*****   case characters through OFF RAISE.                       ******
%*****   Note that in REDUCE 3.6 one has to input REDUCE commands ******
%*****   in lower case!!!!!                                       ******

so even by then lower case astonished some. And the code in that file was
clearlky written by somebody used to working in an upper case world - eg 
observe "mstyle!*:='!d!i!s!p!l!a!y!m!a!t!h;" where the exclamation marks 
are to preserve the lower caseness of the characters there. I hope I have 
just checked in a small change that (as you suggest) saves *raise and 
*lower at the start and puts them back at the end.
It is plausible that the whole file should be reviewed so that it says eg
"mstyle!*:='displaymath;" and that as a group of developers and 
maintainers we agree that while building the system the default case will 
be lower.

At one time I had tried scanning all the sources to find any places where 
names that were identical apart from case were present. I know I tidied up 
some but am not confident that all are fixed - and if we distributed 
Reduce in a case-sensitive form (just by making the default values of 
*raise and *lower nil) I would expect that to hurt some users. But perhaps 
it would be the right thing to do?????? Thoughts everyone...

Arthur

Re: [Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

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

Hi,

concerning your suggestion about the rlfi package I will commit a correction.

Regarding the raise switch: In CSL Reduce, you need to set "off lower" instead - 
which in my opinion describes better what happens, namely not converting 
uppercase characters to lowercase.

The behaviour of PSL is historical: originally Reduce was all uppercase. "On 
raise" meant to convert lowercase input to uppercase, and "on lower" meant to 
convert to lowercase on output. But at some point in the past PSL changed to 
lowercase internally. To avoid confusion, the switch raise was not renamed, but 
"on raise" means now to convert uppercase input to lowercase.

Maybe we should implement a consistent interface and document it. The Reduce 
manual doesn't mention the raise switch except in the section about rlfi.

  Rainer


On Wed, 5 Nov 2025 at 07:29 -0000, Prof Tony Roberts via Reduce-algebra-dev...:

 > Hi,
 > 
 > I have come across two problems with Reduce trying to enable lower- and
 > upper-case together.  These occur with all three versions of Reduce that I
 > have access to, versions spanning releases over the last five years.
 > 
 > * First, csl-reduce seems to ignore "off raise"---it has no effect that I can
 > see.  For example,
 > 
 > > Reduce (CSL, rev 6657), 10-Dec-2023 ...
 > > 1: off raise;
 > > 2: (x+X)^6;
 > >     6
 > > 64*x
 > Whereas in psl,
 > 
 > > Reduce (Free PSL version, revision 6864), build date 27-Aug-2024 ...
 > > 1: off raise;
 > > 2: (x+X)^6;
 > >  6      5         4  2       3  3       2  4        5    6
 > > X  + 6*X *x + 15*X *x  + 20*X *x  + 15*X *x  + 6*X*x  + x
 > 
 > 
 > * Second, in the LaTeX rlfi package, the source of rlfi.red shows that the
 > latexoff procedure automatically sets "  !*raise:=t;" which turns on the
 > "raise" switch and so ruins any case sensitive algebra in progress.   Surely,
 > this procedure should be changed to restore what a user has set.
 > 
 > That is, surely we prefer that procedure latexon stores a users choice of
 > "raise", and then latexoff restores the users choice. By no means fool-proof,
 > but more reasonable.
 > 
 > 
 > Tony
 > 
 > -- 
 > ---------------------------------------------------------------------
 > Four books and a toolbox:
 > 
 > * (2020) Linear Algebra for the 21st Century
 > Oxford University Press. isbn: 978-0-19-885640-5, 978-0-19-885639-9
 > https://global.oup.com/academic/product/linear-algebra-for-the-21st-century-9780198856399
 > 
 > * (2015) Model emergent dynamics in complex systems
 > SIAM, Philadelphia. isbn: 9781611973556.
 > https://epubs.siam.org/doi/10.1137/1.9781611973563
 > 
 > * (2009) Elementary calculus of financial mathematics
 > SIAM, Philadelphia. isbn: 978-0-898716-67-2.
 > https://epubs.siam.org/doi/10.1137/1.9780898718225
 > 
 > * (1994) A one-dimensional introduction to continuum mechanics
 > World Sci. isbn: 978-981-02-1913-0.
 > 
 > * (2020) with John Maclean, and J. E. Bunder; Equation-Free
 > function toolbox for Matlab/Octave.
 > http://github.com/uoa1184615/EquationFreeGit
 > 
 > Emeritus Professor A.J. Roberts,  FAustMS
 > School of Mathematical Sciences,  University of Adelaide
 > https://profajroberts.github.io/
 > mailto:Pro...@pr...
 > http://orcid.org/0000-0001-8930-1552
 > 
 > 

   Rainer Schöpf

[Reduce-algebra-developers] Reduce: "off raise" does nothing in csl; and also poor rlfi package assumption

[Prof T. R. <Pro...@pr...>]

Hi,

I have come across two problems with Reduce trying to enable lower- 
and upper-case together.  These occur with all three versions of 
Reduce that I have access to, versions spanning releases over the 
last five years.

* First, csl-reduce seems to ignore "off raise"---it has no effect 
that I can see.  For example,

> Reduce (CSL, rev 6657), 10-Dec-2023 ...
> 1: off raise;
> 2: (x+X)^6;
>     6
> 64*x
Whereas in psl,

> Reduce (Free PSL version, revision 6864), build date 27-Aug-2024 ...
> 1: off raise;
> 2: (x+X)^6;
>  6      5         4  2       3  3       2  4        5    6
> X  + 6*X *x + 15*X *x  + 20*X *x  + 15*X *x  + 6*X*x  + x


* Second, in the LaTeX rlfi package, the source of rlfi.red shows 
that the latexoff procedure automatically sets "  !*raise:=t;" which 
turns on the "raise" switch and so ruins any case sensitive algebra 
in progress.   Surely, this procedure should be changed to restore 
what a user has set.

That is, surely we prefer that procedure latexon stores a users 
choice of "raise", and then latexoff restores the users choice. By 
no means fool-proof, but more reasonable.


Tony

-- 
---------------------------------------------------------------------
Four books and a toolbox:

* (2020) Linear Algebra for the 21st Century
Oxford University Press. isbn: 978-0-19-885640-5, 978-0-19-885639-9
https://global.oup.com/academic/product/linear-algebra-for-the-21st-century-9780198856399

* (2015) Model emergent dynamics in complex systems
SIAM, Philadelphia. isbn: 9781611973556.
https://epubs.siam.org/doi/10.1137/1.9781611973563

* (2009) Elementary calculus of financial mathematics
SIAM, Philadelphia. isbn: 978-0-898716-67-2.
https://epubs.siam.org/doi/10.1137/1.9780898718225

* (1994) A one-dimensional introduction to continuum mechanics
World Sci. isbn: 978-981-02-1913-0.

* (2020) with John Maclean, and J. E. Bunder; Equation-Free
function toolbox for Matlab/Octave.
http://github.com/uoa1184615/EquationFreeGit

Emeritus Professor A.J. Roberts,  FAustMS
School of Mathematical Sciences,  University of Adelaide
https://profajroberts.github.io/
mailto:Pro...@pr...
http://orcid.org/0000-0001-8930-1552

Re: [Reduce-algebra-developers] Removing older snaphots?

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

I've kept the Raspberry Pi snapshot. 

Should we create a new one for the Armv8 architecture instead? 

 Rainer


On Tue, 4 Nov 2025 at 12:46 -0000, Francis Wright wrote:

 > No objections from me, except that it might be worth keeping the Raspberry Pi snapshot, if it is still of any use, since we don't have very many of them. (I don't use Raspberry Pi so I can't judge whether it is still useful.)
 > 
 > Thanks for tidying things up.
 > 
 > Francis
 > 
 > ________________________________
 > From: Rainer Schöpf via Reduce-algebra-developers <red...@li...>
 > Sent: Tuesday, November 04, 2025 7:52 AM
 > To: reduce-algebra-developers <red...@li...>
 > Subject: [Reduce-algebra-developers] Removing older snaphots?
 > 
 > I looked at the list here:
 > 
 >   https://sourceforge.net/p/reduce-algebra/admin/files/large_files
 > 
 > Any objections if I remove all snapshots created before december 2023 ?
 > 
 >     Rainer
 > 
 > 
 > _______________________________________________
 > Reduce-algebra-developers mailing list
 > Red...@li...
 > https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
 > 

   Rainer Schöpf

Re: [Reduce-algebra-developers] Removing older snaphots?

[Francis W. <f.j...@li...>]

No objections from me, except that it might be worth keeping the Raspberry Pi snapshot, if it is still of any use, since we don't have very many of them. (I don't use Raspberry Pi so I can't judge whether it is still useful.)

Thanks for tidying things up.

Francis

________________________________
From: Rainer Schöpf via Reduce-algebra-developers <red...@li...>
Sent: Tuesday, November 04, 2025 7:52 AM
To: reduce-algebra-developers <red...@li...>
Subject: [Reduce-algebra-developers] Removing older snaphots?

I looked at the list here:

  https://sourceforge.net/p/reduce-algebra/admin/files/large_files

Any objections if I remove all snapshots created before december 2023 ?

    Rainer


_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

[Reduce-algebra-developers] Removing older snaphots?

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

I looked at the list here:

  https://sourceforge.net/p/reduce-algebra/admin/files/large_files

Any objections if I remove all snapshots created before december 2023 ?

    Rainer

Re: [Reduce-algebra-developers] A few issues with REDUCE in the current SVN

[Jeff J. <tr...@po...>]

False alarm on the build - I don't know what happened, but I cleaned
up by tree and built from a clean checkout and I was able to build
CSL without any issues.  So there is no issue there.

However, the documentation link for HTML on the site remains.

Sorry to jump the gun with the trouble report.

--
Jeffrey H. Johnson
tr...@po...

[Reduce-algebra-developers] A few issues with REDUCE in the current SVN

[Jeff J. <tr...@po...>]

Greetings,

A few issues to report.  First, on the website, the HTML documentation
link https://reduce-algebra.sourceforge.io/manual/manual.html is
currently broken.  The PDF is fine.

Second, I'm having an error building CSL on Fedora 42.  There are
several missing symbols when linking:

Relinking csl because of csl-arith01.o csl-arith02.o csl-arith03.o csl-arith04.o csl-arith05.o csl-arith06.o csl-arith07.o csl-arith08.o csl-arith09.
o csl-arith10.o csl-arith11.o csl-arith12.o csl-arith13.o csl-arith14.o csl-arith-quad.o csl-isprime.o csl-qsieve.o csl-jit.o csl-forks.o csl-char.o 
csl-cslmpi.o csl-eval1.o csl-eval2.o csl-eval3.o csl-eval4.o csl-fns1.o csl-fns2.o csl-fns3.o csl-inthash.o csl-print.o csl-cslread.o csl-restart.o c
sl-lisphash.o csl-serialize.o csl-sysfwin.o csl-winsupport.o csl-csl.o csl-fasl.o csl-preserve.o csl-bytes1.o csl-showhdr.o csl-float128_t.o csl-newc
slgc.o csl-newallocate.o csl-gc-check.o csl-stubs.o reduce.fonts/cmr10.pfb ../lib/libcrlibm.a ../include/crlibm.h ../lib/libffi.a ../include/ffi.h ..
/lib/libsoftfloat.a ../include/softfloat.h ../lib/libFOX-1.6.a /home/jhj/src/new-reduce/trunk/csl/cslbase/lvector.h
g++ -std=gnu++20  -std=gnu++20 -I/usr/include/freetype2 -I/usr/include/libpng16 -DWITH_GZFILEOP -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/us
r/lib64/glib-2.0/include -I/usr/include/sysprof-6 -pthread  -O3 -Wall  -L../lib  -L/usr/X11R6/lib -Wl,--hash-style=both -L/usr/local/lib -rdynamic -o
 csl csl-arith01.o csl-arith02.o csl-arith03.o csl-arith04.o csl-arith05.o csl-arith06.o csl-arith07.o csl-arith08.o csl-arith09.o csl-arith10.o csl-
arith11.o csl-arith12.o csl-arith13.o csl-arith14.o csl-arith-quad.o csl-isprime.o csl-qsieve.o csl-jit.o csl-forks.o csl-char.o csl-cslmpi.o csl-eva
l1.o csl-eval2.o csl-eval3.o csl-eval4.o csl-fns1.o csl-fns2.o csl-fns3.o csl-inthash.o csl-print.o csl-cslread.o csl-restart.o csl-lisphash.o csl-se
rialize.o csl-sysfwin.o csl-winsupport.o csl-csl.o csl-fasl.o csl-preserve.o csl-bytes1.o csl-showhdr.o csl-float128_t.o csl-newcslgc.o csl-newalloca
te.o csl-gc-check.o   csl-stubs.o -lFOX-1.6 ../lib/libcrlibm.a   ../lib/libffi.a ../lib/libsoftfloat.a  -lXrandr -lXcursor -lXrender -lz -lXext -lX11
 -lfreetype -lXft -lfontconfig -lncurses  /usr/lib/libtinfo.a  -lncurses 
/usr/bin/ld: csl-print.o: in function `internal_prin(long, int)':                                                                                    
print.cpp:(.text+0xd8a0): undefined reference to `f128M_eq'                                                                                          
/usr/bin/ld: csl-arith04.o: in function `uint128_fix(float128_t*)':                                                                                  
arith04.cpp:(.text+0x140e): undefined reference to `f128M_eq'    
/usr/bin/ld: csl-arith04.o: in function `rationalize(long)':                                                                                         
arith04.cpp:(.text+0x1a39): undefined reference to `f128M_eq'                                                                                        
/usr/bin/ld: arith04.cpp:(.text+0x1d13): undefined reference to `f128M_eq'    
/usr/bin/ld: arith04.cpp:(.text+0x1fc2): undefined reference to `f128M_eq' 
/usr/bin/ld: csl-arith04.o:arith04.cpp:(.text+0x2080): more undefined references to `f128M_eq' follow
/usr/bin/ld: ../lib/libcrlibm.a(trigo_fast.o): in function `ComputeTrigWithArgred':        
trigo_fast.c:(.text+0xf92): undefined reference to `scs_set_d'                                                                                       
/usr/bin/ld: trigo_fast.c:(.text+0x12db): undefined reference to `scs_set_d'
/usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o): in function `scs_tan':                                                                            
trigo_accurate.c:(.text+0x17): undefined reference to `scs_set_d'                                                                                    
/usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o): in function `scs_sin_rn':  
trigo_accurate.c:(.text+0xf0): undefined reference to `scs_set_d'
/usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o): in function `scs_sin_rd':                   
trigo_accurate.c:(.text+0x380): undefined reference to `scs_set_d'                                                                                   
/usr/bin/ld: ../lib/libcrlibm.a(trigo_accurate.o):trigo_accurate.c:(.text+0x610): more undefined references to `scs_set_d' follow
/usr/bin/ld: ../lib/libcrlibm.a(addition_scs.o): in function `do_sub':
addition_scs.c:(.text+0xdbb): undefined reference to `scs_zero'                                                                                      
/usr/bin/ld: ../lib/libcrlibm.a(division_scs.o): in function `scs_inv':                                                                              
division_scs.c:(.text+0x173): undefined reference to `scs_set_si'                                                                                    
/usr/bin/ld: division_scs.c:(.text+0x1a1): undefined reference to `scs_set_d'
collect2: error: ld returned 1 exit status                                                                                                           

I haven't had any time yet to actually debug it, but I thought I'd report it.

This is on Linux, Fedora 42.  I'll look into it a bit more later.

--
Jeffrey H. Johnson
tr...@po...

Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

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

Thanks and glad you can now make work progress. Gc issues can be very slippery to the extent that exact file paths (which of course consume mrmory) can make them appear and vanish, do if ANYONE can get this issue robustly repeatable on Linux i would be grateful. Arthur

Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: martin gregory <a.m...@ic...>
Sent: Thursday, August 28, 2025 9:58:27 PM
To: Arthur Charles Norman <ac...@ca...>; reduce-algebra-developers <red...@li...>
Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

Thanks for taking the time to answer.

Good news is that with -k2.5g the for loop below completed without crashing:

Time: 1190190 ms  plus GC time: 1408 ms

Memory usage peaked at 1.02GB.

As I mentioned earlier, no urgency, so no need to reply now.

Regards,
Martin

On 28. Aug 2025, at 01:24, Arthur Charles Norman <ac...@ca...<mailto:ac...@ca...>> wrote:

Thank you.i am indeed on a trip and not in a position to investigate until I greet back home, but an immediate hack that may help is that a command line option such as -k6g would instruct csl to start with 6g of memory not its default,and doing thatbaturallymoves garbage collection around somay. Sidestep by trying various numbers where I showed 6. For when I return getting a solidly reproducible version will be good. Specifically I will be configuring and building reduce with --enable-debug and that can change memory layout a little, and debugging on thee mac is horrid for me, do what I would most like would be a crash on a debug mode csl on linux! Apologies. Arthur

Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: martin gregory via Reduce-algebra-developers <red...@li...<mailto:red...@li...>>
Sent: Thursday, August 28, 2025 1:42:40 AM
To: reduce-algebra-developers <red...@li...<mailto:red...@li...>>
Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code:

for k:=25:40 do <<
   kp:=10^k-1;
   kpf:=factorize(kp);
   write "k: ", k, " kp: ", kp, "  ", kpf ;
>>;

This aborts reproducibly after k = 37.

I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all.

Regards,
Martin

On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote:

Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot.
 Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible?

Eberhard

On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote:
I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866  results in”.

Apologies,
Martin

On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote:

Dear reduce-algebra-developers,

running the procedure

procedure lastprime (n) ;
   begin scalar k, kfact ;
      k:=n+1 ;
      repeat
      << k:=k-1 ;
 kfact:=factorize(k)
      >> until length(kfact) = 1 and second(first(kfact))=1;
      return first(first(kfact))
   end ;

with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message

!!! Aborting: newcslgc.cpp:266 page type not recognised

and the last number tested before the abort is 10^25-112.

On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.

The log files for the both CSL and PSL 6866 runs are attached.

In case it's relevant, here are the machine specs:

Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024;
root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz

Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux

Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.

Kind regards,
Martin






_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...<mailto:Red...@li...>
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers





_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...<mailto:Red...@li...>
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers



_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...<mailto:Red...@li...>
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

[martin g. <a.m...@ic...>]

Thanks for taking the time to answer. 

Good news is that with -k2.5g the for loop below completed without crashing:

Time: 1190190 ms  plus GC time: 1408 ms

Memory usage peaked at 1.02GB.

As I mentioned earlier, no urgency, so no need to reply now.

Regards,
Martin

> On 28. Aug 2025, at 01:24, Arthur Charles Norman <ac...@ca...> wrote:
> 
> Thank you.i am indeed on a trip and not in a position to investigate until I greet back home, but an immediate hack that may help is that a command line option such as -k6g would instruct csl to start with 6g of memory not its default,and doing thatbaturallymoves garbage collection around somay. Sidestep by trying various numbers where I showed 6. For when I return getting a solidly reproducible version will be good. Specifically I will be configuring and building reduce with --enable-debug and that can change memory layout a little, and debugging on thee mac is horrid for me, do what I would most like would be a crash on a debug mode csl on linux! Apologies. Arthur
> 
> Sent from Outlook for Android <https://aka.ms/AAb9ysg>
> From: martin gregory via Reduce-algebra-developers <red...@li...>
> Sent: Thursday, August 28, 2025 1:42:40 AM
> To: reduce-algebra-developers <red...@li...>
> Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866
>  
> Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code:
> 
> for k:=25:40 do <<
>    kp:=10^k-1;
>    kpf:=factorize(kp);
>    write "k: ", k, " kp: ", kp, "  ", kpf ;
> >>;
> 
> This aborts reproducibly after k = 37.
> 
> I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all.
> 
> Regards, 
> Martin
> 
>> On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li... <mailto:red...@li...>> wrote:
>> 
>> Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot.
>>  Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? 
>> 
>> Eberhard
>> 
>> On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote:
>>> I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866  results in”. 
>>> 
>>> Apologies,
>>> Martin
>>> 
>>>> On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li... <mailto:red...@li...>> wrote:
>>>> 
>>>> Dear reduce-algebra-developers,
>>>> 
>>>> running the procedure
>>>> 
>>>> procedure lastprime (n) ;
>>>>    begin scalar k, kfact ;
>>>>       k:=n+1 ;
>>>>       repeat
>>>>       << k:=k-1 ;
>>>>  kfact:=factorize(k) 
>>>>       >> until length(kfact) = 1 and second(first(kfact))=1;
>>>>       return first(first(kfact))
>>>>    end ;
>>>> 
>>>> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message
>>>> 
>>>> !!! Aborting: newcslgc.cpp:266 page type not recognised
>>>> 
>>>> and the last number tested before the abort is 10^25-112.
>>>> 
>>>> On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.
>>>> 
>>>> The log files for the both CSL and PSL 6866 runs are attached.
>>>> 
>>>> In case it's relevant, here are the machine specs:
>>>> 
>>>> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; 
>>>> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
>>>> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz
>>>> 
>>>> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
>>>> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux
>>>> 
>>>> Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.
>>>> 
>>>> Kind regards, 
>>>> Martin
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Reduce-algebra-developers mailing list
>>>> Red...@li... <mailto:Red...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers>
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Reduce-algebra-developers mailing list
>>> Red...@li... <mailto:Red...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers>
>> 
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li... <mailto:Red...@li...>
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
> 

Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

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

Thank you.i am indeed on a trip and not in a position to investigate until I greet back home, but an immediate hack that may help is that a command line option such as -k6g would instruct csl to start with 6g of memory not its default,and doing thatbaturallymoves garbage collection around somay. Sidestep by trying various numbers where I showed 6. For when I return getting a solidly reproducible version will be good. Specifically I will be configuring and building reduce with --enable-debug and that can change memory layout a little, and debugging on thee mac is horrid for me, do what I would most like would be a crash on a debug mode csl on linux! Apologies. Arthur

Sent from Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: martin gregory via Reduce-algebra-developers <red...@li...>
Sent: Thursday, August 28, 2025 1:42:40 AM
To: reduce-algebra-developers <red...@li...>
Subject: Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code:

for k:=25:40 do <<
   kp:=10^k-1;
   kpf:=factorize(kp);
   write "k: ", k, " kp: ", kp, "  ", kpf ;
>>;

This aborts reproducibly after k = 37.

I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all.

Regards,
Martin

On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote:

Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot.
 Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible?

Eberhard

On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote:
I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866  results in”.

Apologies,
Martin

On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li...<mailto:red...@li...>> wrote:

Dear reduce-algebra-developers,

running the procedure

procedure lastprime (n) ;
   begin scalar k, kfact ;
      k:=n+1 ;
      repeat
      << k:=k-1 ;
 kfact:=factorize(k)
      >> until length(kfact) = 1 and second(first(kfact))=1;
      return first(first(kfact))
   end ;

with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message

!!! Aborting: newcslgc.cpp:266 page type not recognised

and the last number tested before the abort is 10^25-112.

On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.

The log files for the both CSL and PSL 6866 runs are attached.

In case it's relevant, here are the machine specs:

Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024;
root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz

Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux

Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.

Kind regards,
Martin






_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...<mailto:Red...@li...>
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers





_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...<mailto:Red...@li...>
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers



_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...<mailto:Red...@li...>
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

[martin g. <a.m...@ic...>]

Yes, it’s reproducible on my 2017 MacBook Air Intel which doesn’t run any MacOS later than Monterey. I can also reproduce it using this simpler code:

for k:=25:40 do <<
   kp:=10^k-1;
   kpf:=factorize(kp);
   write "k: ", k, " kp: ", kp, "  ", kpf ;
>>;

This aborts reproducibly after k = 37.

I have modified my R code to trap and handle this gracefully and I will mention the issue in the documentation. I have just completed coding (on Linux) and only discovered this running the test suite on the Mac after it completed successfully on Linux. I still have to finish the documentation and am unlikely to publish before mid October. So no urgency at all.

Regards, 
Martin

> On 27. Aug 2025, at 15:52, Eberhard Schruefer via Reduce-algebra-developers <red...@li...> wrote:
> 
> Thank you very much for your report. The right person to comment on this would be Arthur Norman, however he is on vacation until late September. There were several changes to the new, conservative, garbage collector of CSL after that snapshot. Publishing a new snapshot from our side is overdue, but our old snapshot build-system is not available anymore and setting up a new one takes time. So, please bear with us until some time in October if you want to use a snapshot.
>  Is the error which you saw with snapshot 6866 on a Mac-Intel machine reproducible? 
> 
> Eberhard
> 
> On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote:
>> I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866  results in”.
>> 
>> Apologies,
>> Martin
>> 
>>> On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li... <mailto:red...@li...>> wrote:
>>> 
>>> Dear reduce-algebra-developers,
>>> 
>>> running the procedure
>>> 
>>> procedure lastprime (n) ;
>>>    begin scalar k, kfact ;
>>>       k:=n+1 ;
>>>       repeat
>>>       << k:=k-1 ;
>>> 	 kfact:=factorize(k) 
>>>       >> until length(kfact) = 1 and second(first(kfact))=1;
>>>       return first(first(kfact))
>>>    end ;
>>> 
>>> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message
>>> 
>>> !!! Aborting: newcslgc.cpp:266 page type not recognised
>>> 
>>> and the last number tested before the abort is 10^25-112.
>>> 
>>> On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.
>>> 
>>> The log files for the both CSL and PSL 6866 runs are attached.
>>> 
>>> In case it's relevant, here are the machine specs:
>>> 
>>> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; 
>>> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
>>> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz
>>> 
>>> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
>>> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux
>>> 
>>> Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.
>>> 
>>> Kind regards, 
>>> Martin
>> 
>> 
>> 
>> 
>>> 
>>> 
>>> _______________________________________________
>>> Reduce-algebra-developers mailing list
>>> Red...@li... <mailto:Red...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li... <mailto:Red...@li...>
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers>
> 
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

[Eberhard S. <esc...@ca...>]

Thank you very much for your report. The right person to comment on this 
would be Arthur Norman, however he is on vacation until late September. 
There were several changes to the new, conservative, garbage collector 
of CSL after that snapshot. Publishing a new snapshot from our side is 
overdue, but our old snapshot build-system is not available anymore and 
setting up a new one takes time. So, please bear with us until some time 
in October if you want to use a snapshot.
  Is the error which you saw with snapshot 6866 on a Mac-Intel machine 
reproducible?

Eberhard

On 27.08.25 15:03, martin gregory via Reduce-algebra-developers wrote:
> I just noticed that “snapshot 6866 or higher results in” should read 
> “snapshot 6866  results in”.
>
> Apologies,
> Martin
>
>> On 27. Aug 2025, at 14:01, martin gregory via 
>> Reduce-algebra-developers 
>> <red...@li...> wrote:
>>
>> Dear reduce-algebra-developers,
>>
>> running the procedure
>>
>> procedure lastprime (n) ;
>>    begin scalar k, kfact ;
>>       k:=n+1 ;
>>       repeat
>>       << k:=k-1 ;
>>  kfact:=factorize(k)
>>       >> until length(kfact) = 1 and second(first(kfact))=1;
>>       return first(first(kfact))
>>    end ;
>>
>> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher 
>> results in the following message
>>
>>     !!! Aborting: newcslgc.cpp:266 page type not recognised
>>
>>
>> and the last number tested before the abort is 10^25-112.
>>
>> On the same macbook with the same call PSL snapshot 6866 and both PSL 
>> and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 
>> CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all 
>> complete without issues. The result in all cases is 10^25-123. 
>> Repeating up to 10^40 on these versions causes no problems.
>>
>> The log files for the both CSL and PSL 6866 runs are attached.
>>
>> In case it's relevant, here are the machine specs:
>>
>> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024;
>> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
>> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz
>>
>> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
>> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux
>>
>> Finally the context in case it helps: the R to REDUCE interface I'm 
>> building can notify at user-defined intervals that a calculation is 
>> still running and can also interrupt a calculation after a 
>> user-defined timeout. I'm using the above procedure to test these 
>> features by executing it for a series of integers to determine how 
>> long it takes to run on an arbitrary test system and then use this 
>> to calculate appropriate notification interval and timeout so that 
>> these will be triggered.
>>
>> Kind regards,
>> Martin
>
>
>>
>>
>> _______________________________________________
>> Reduce-algebra-developers mailing list
>> Red...@li...
>> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers
>
>
>
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

[martin g. <a.m...@ic...>]

I just noticed that “snapshot 6866 or higher results in” should read “snapshot 6866  results in”.

Apologies,
Martin

> On 27. Aug 2025, at 14:01, martin gregory via Reduce-algebra-developers <red...@li...> wrote:
> 
> Dear reduce-algebra-developers,
> 
> running the procedure
> 
> procedure lastprime (n) ;
>    begin scalar k, kfact ;
>       k:=n+1 ;
>       repeat
>       << k:=k-1 ;
> 	 kfact:=factorize(k) 
>       >> until length(kfact) = 1 and second(first(kfact))=1;
>       return first(first(kfact))
>    end ;
> 
> with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message
> 
> !!! Aborting: newcslgc.cpp:266 page type not recognised
> 
> and the last number tested before the abort is 10^25-112.
> 
> On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.
> 
> The log files for the both CSL and PSL 6866 runs are attached.
> 
> In case it's relevant, here are the machine specs:
> 
> Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; 
> root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
> Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz
> 
> Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
> Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux
> 
> Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.
> 
> Kind regards, 
> Martin
> 
> 
> 
> 
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

[Reduce-algebra-developers] Aborting newcslgc.cpp on MacOS Intel/12.7.6 CSL snapshot 6866

[martin g. <a.m...@ic...>]

Dear reduce-algebra-developers,

running the procedure

procedure lastprime (n) ;
   begin scalar k, kfact ;
      k:=n+1 ;
      repeat
      << k:=k-1 ;
	 kfact:=factorize(k) 
      >> until length(kfact) = 1 and second(first(kfact))=1;
      return first(first(kfact))
   end ;

with n=10^25 on MacOS Intel/12.7.6 CSL snapshot 6866 or higher results in the following message

!!! Aborting: newcslgc.cpp:266 page type not recognised

and the last number tested before the abort is 10^25-112.

On the same macbook with the same call PSL snapshot 6866 and both PSL and CSL snapshot 6658 all complete without issues. On Linux 5.15.187 CSL and PSL snapshots 7131, 6860 and 6658 (compiled locally) all complete without issues. The result in all cases is 10^25-123. Repeating up to 10^40 on these versions causes no problems.

The log files for the both CSL and PSL 6866 runs are attached.

In case it's relevant, here are the machine specs:

Darwin Kernel Version 21.6.0: Mon Jun 24 00:56:10 PDT 2024; 
root:xnu-8020.240.18.709.2~1/RELEASE_X86_64 x86_64
Processor: Intel(R) Core(TM) i5-5350U CPU @ 1.80GHz

Linux 5.15.187 #1 SMP PREEMPT Thu Jul 10 19:03:37 CDT 2025 x86_64
Processor: Intel(R) Core(TM) i5-4440 CPU @ 3.10GHz GenuineIntel GNU/Linux

Finally the context in case it helps: the R to REDUCE interface I'm building can notify at user-defined intervals that a calculation is still running and can also interrupt a calculation after a user-defined timeout. I'm using the above procedure to test these features by executing it for a series of integers to determine how long it takes to run on an arbitrary test system and then use this to calculate appropriate notification interval and timeout so that these will be triggered.

Kind regards, 
Martin

Re: [Reduce-algebra-developers] odesolve example 18 from zimmer.tst produces no solution

[Francis W. <f.j...@li...>]

I think the problem is that odesolve calls a procedure in the solve package when it generates a new root of unity or a new plus or minus. (To be precise, it calls symbolic procedure mkrootsoftag() defined in "solve/solve1.red".) But this procedure is not loaded by default. If odesolve has already called solve then everything is fine; otherwise it isn't!

A quick fix is to do

load_package solve;

before using odesolve. Please let me know if that doesn't solve the problem, or if anyone spots any other issues.

I will add some code to odesolve so that this is not necessary in future.

Francis

________________________________
From: martin gregory via Reduce-algebra-developers <red...@li...>
Sent: Thursday, June 05, 2025 1:47 PM
To: reduce-algebra-developers <red...@li...>
Subject: [Reduce-algebra-developers] odesolve example 18 from zimmer.tst produces no solution

Dear reduce-algebra-developers,

first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst:

----------------------------------------------------------------------
% (18) Bernoulli 1
odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);
----------------------------------------------------------------------

If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only:

----------------------------------------------------------------------
4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);
This is a nonlinear ODE of order 1.
It is of Bernoulli type.

5:
----------------------------------------------------------------------

i.e. not even the {} one gets when there is no solution.

Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs.

If I don't use the explicit option I do get the correct solution, but in a different form.

Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible.

Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical.

odesolve is very impressive software!

Kind regards,
Martin

[1] The R Project for Statistical Computing: https://www.r-project.org/





_______________________________________________
Reduce-algebra-developers mailing list
Red...@li...
https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers

Re: [Reduce-algebra-developers] odesolve example 18 from zimmer.tst produces no solution

[martin g. <a.m...@ic...>]

Thanks for the quick response. I will disable that test until there is a fix. I still have quite some work to do on my  code before publishing it.

Kind regards, 
Martin

> On 5. Jun 2025, at 17:39, Francis Wright <f.j...@li...> wrote:
> 
> Thanks for your detailed work on this problem and your comments about odesolve. What you have discovered is a bug that I will endeavour to fix ASAP, but I'm away from home for a couple of days. I'll try to take a look at this next week.
> 
> Best wishes, Francis
> 
> On 5 Jun 2025 1:47 pm, martin gregory via Reduce-algebra-developers <red...@li...> wrote:
> Dear reduce-algebra-developers,
> 
> first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst:
> 
> ----------------------------------------------------------------------
> % (18) Bernoulli 1
> odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);
> ----------------------------------------------------------------------
> 
> If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only:
> 
> ----------------------------------------------------------------------
> 4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);
> This is a nonlinear ODE of order 1.
> It is of Bernoulli type.
> 
> 5:
> ----------------------------------------------------------------------
> 
> i.e. not even the {} one gets when there is no solution.
> 
> Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs.
> 
> If I don't use the explicit option I do get the correct solution, but in a different form.
> 
> Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible.
> 
> Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical.
> 
> odesolve is very impressive software!
> 
> Kind regards,
> Martin
> 
> [1] The R Project for Statistical Computing: https://www.r-project.org/ <https://www.r-project.org/>
> 
> 
> 
> 
>  
> _______________________________________________
> Reduce-algebra-developers mailing list
> Red...@li...
> https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers <https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers>
> 

Re: [Reduce-algebra-developers] odesolve example 18 from zimmer.tst produces no solution

[Francis W. <f.j...@li...>]

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="auto">Thanks for your detailed work on this problem and your comments about odesolve. What you have discovered is a bug that I will endeavour to fix ASAP, but I'm away from home for a couple of days. I'll try to take a look at this next week.<div dir="auto"><br></div><div dir="auto">Best wishes, Francis</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 Jun 2025 1:47 pm, martin gregory via Reduce-algebra-developers	 &lt;red...@li...&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><font size="2"><span style="font-size:11pt">
<div>Dear reduce-algebra-developers,<br>
<br>
first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for
 odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst:<br>
<br>
----------------------------------------------------------------------<br>
% (18) Bernoulli 1<br>
odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);<br>
----------------------------------------------------------------------<br>
<br>
If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only:<br>
<br>
----------------------------------------------------------------------<br>
4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);<br>
This is a nonlinear ODE of order 1.<br>
It is of Bernoulli type.<br>
<br>
5:<br>
----------------------------------------------------------------------<br>
<br>
i.e. not even the {} one gets when there is no solution.<br>
<br>
Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output
 I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work.
 Searching further, however, I found that it is turned on any time odesolve runs.<br>
<br>
If I don't use the explicit option I do get the correct solution, but in a different form.<br>
<br>
Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible.<br>
<br>
Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical.<br>
<br>
odesolve is very impressive software!<br>
<br>
Kind regards,<br>
Martin<br>
<br>
[1] The R Project for Statistical Computing: <a href="https://www.r-project.org/">
https://www.r-project.org/</a><br>
<br>
<br>
</div>
</span></font></div>
<div><font size="2"><span style="font-size:11pt">
<div><br>
<br>
</div>
</span></font></div>
<div><font size="2"><span style="font-size:11pt">
<div>&nbsp;</div>
</span></font></div>
<div><font size="2"><span style="font-size:11pt">
<div>_______________________________________________<br>
Reduce-algebra-developers mailing list<br>
Red...@li...<br>
<a href="https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers">https://lists.sourceforge.net/lists/listinfo/reduce-algebra-developers</a><br>
</div>
</span></font></div>
</div>
</blockquote></div><br></div>

[Reduce-algebra-developers] odesolve example 18 from zimmer.tst produces no solution

[martin g. <a.m...@ic...>]

Dear reduce-algebra-developers,

first some context: I am building an R[1] package to execute REDUCE code and transform the output to appropriate R objects. An important aspect of testing is to ensure the transformation of the output is accurate. While looking for non-trivial examples for odesolve solutions including plus_or_minus() I found example 18 of odesolve/zimmer.tst:

----------------------------------------------------------------------
% (18) Bernoulli 1
odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);
----------------------------------------------------------------------

If I execute zimmer.tst it works perfectly. If I execute this call in a fresh REDUCE session, setting TRODE, DIV and INTSTR to on and ALLFAC to off as in zimmer.tst, I get only:

----------------------------------------------------------------------
4: odesolve(df(y,x) + y = y^3*sin x, y, x, explicit);
This is a nonlinear ODE of order 1.
It is of Bernoulli type.

5:
----------------------------------------------------------------------

i.e. not even the {} one gets when there is no solution.

Trying to understand what was going on I assumed that one or more of the preceding 17 examples was influencing the call so I generated a program for each 17 to execute, in a new session, the switch settings, the example and then example 18. Searching the output I found that examples 3, 8, 11, 12, 13, 15 each cause 18 to work correctly. I then checked the state of all switches before and after executing these programs and found that ALLOWDFINT is turned on. Setting it on in a clean session did not cause 18 to work. Searching further, however, I found that it is turned on any time odesolve runs.

If I don't use the explicit option I do get the correct solution, but in a different form.

Is there a switch or option to get example 18 to work with explicit and without running one of the other examples first? If there is no such way, I can add a warning to my documentation that such behaviour is possible.

Attached is odesolve-zimmer18.red with CSL (.clg) log demonstrating the behaviour. PSL behaviour is identical.

odesolve is very impressive software!

Kind regards,
Martin

[1] The R Project for Statistical Computing: https://www.r-project.org/

[Reduce-algebra-developers] Thomas Wolf

[Eberhard S. <esc...@ca...>]

Dear all,

I would like to share with you Brock University's obituary for our 
friend and colleague Thomas Wolf.

https://brocku.ca/brock-news/2025/06/professor-thomas-wolf-remembered-for-sharing-his-love-of-math/

Rest in peace.

Eberhard