[fricas-devel] aldor build fails

2023-11-29 Thread Ralf Hemmecke
Commit 92d33b9bf046eb33c00d6614cbd3bc822732714c failed with the build of libaldor.al. The problem seems to be the function name Pi in MathematicalSymbols. When I change for debugging in src/interp/ax.boot to axOpTran(name) == FORMAT(true,'"axOpTran [~S]~%", name) ATOM name => name

Re: [fricas-devel] FriCAS on Android with SBCL (on termux)

2023-11-29 Thread Andrey G. Grozin
On Wed, 29 Nov 2023, Qian Yun wrote: You can run with "fricas -nosman" so that /tmp is not required. Yes! Thank you very much. fricas -nosman works fine. And this is all what's needed in command-line termux (I never tried to run X programs in termux, it is possible, but requires some work;

Re: [fricas-devel] aldor build fails

2023-11-29 Thread Ralf Hemmecke
Well, there is certainly a reason why |Pi| gives these extra parentheses, but I do not know what to do here. This is a name clash: Pi is a type and for that reasons gets parentheses around. Oh, uh, so my suggestion with staying with the convention was not so bad, after all. Interpreter

Re: [fricas-devel] ==> or == with Exports or Implementation

2023-11-29 Thread Waldek Hebisch
On Wed, Nov 29, 2023 at 02:51:52PM +0100, Grégory Vanuxem wrote: > Hello, > > In Spad, with Exports or Implementation the macro or function > definition operators can be used. What I mean is that: > > Exports == with > Implementation == add > > seems to be identically treated with: > >

Re: [fricas-devel] aldor build fails

2023-11-29 Thread Waldek Hebisch
On Wed, Nov 29, 2023 at 10:05:41AM +0100, Ralf Hemmecke wrote: > Commit 92d33b9bf046eb33c00d6614cbd3bc822732714c failed with the build of > libaldor.al. The problem seems to be the function name Pi in > MathematicalSymbols. > > then > > )lisp (|makeAxExportForm| "UnusedArgument" (list

Re: [fricas-devel] better integration result -- avoid complicated roots

2023-11-29 Thread Waldek Hebisch
On Tue, Nov 28, 2023 at 07:02:16PM +0800, Qian Yun wrote: > I have examined integrals where rootSum is over degree 4, from a > subset of Nasser's test. There are also examples of degree 3. When there is 1 real root solver is doing reasonable job and real roots can be recognized, like

Re: [fricas-devel] Unicode vs ASCII

2023-11-29 Thread Waldek Hebisch
On Wed, Nov 29, 2023 at 02:01:29PM +0100, Grégory Vanuxem wrote: > > Le dim. 26 nov. 2023 à 18:00, Waldek Hebisch a écrit : > > > > On Sun, Nov 26, 2023 at 05:20:11PM +0100, Grégory Vanuxem wrote: > > > > > so, as you see Unicode is supported. > > Thanks for making me remember greek letter

[fricas-devel] ==> or == with Exports or Implementation

2023-11-29 Thread Grégory Vanuxem
Hello, In Spad, with Exports or Implementation the macro or function definition operators can be used. What I mean is that: Exports == with Implementation == add seems to be identically treated with: Exports ==> with Implementation ==> add The two seem to compile identically (I have

Re: [fricas-devel] ==> or == with Exports or Implementation

2023-11-29 Thread Ralf Hemmecke
Remark: FriCAS book say that '==' is "delayed assignment". This meaning should be considered obsolete now. Oh! Since you know best what == actually is, can you update the book in the respective sections? How does the meaning of == differ between FriCAS and Aldor? Ralf -- You received this

Re: [fricas-devel] Unicode vs ASCII

2023-11-29 Thread Grégory Vanuxem
Hello, Sorry for being so late. Le dim. 26 nov. 2023 à 18:00, Waldek Hebisch a écrit : > > On Sun, Nov 26, 2023 at 05:20:11PM +0100, Grégory Vanuxem wrote: > > Hi here, > > > > I have read some discussions about using Unicode. Frankly speaking, > > that reminds me of the past, when Debian