In fact, I have taken you like a newbie, an arrivist. My fault again, I love that. I will respond later.
Just for info I have not knowledge, but I know FRAC(INT) as LocalAlgebra Le ven. 5 déc. 2025, 16:02, Waldek Hebisch <[email protected]> a écrit : > On Thu, Nov 27, 2025 at 08:53:32PM +0100, Grégory Vanuxem wrote: > > Hello Ralf, * > > > > Relatively difficult to explain for a non-English speaker... > > > > Le mar. 25 nov. 2025 à 21:39, 'Ralf Hemmecke' via FriCAS - computer > > algebra system <[email protected]> a écrit : > > > > > > On 11/25/25 18:58, Grégory Vanuxem wrote: > > > > HelloRalf, *, > > > > > > I was a bit lost until I figured out that you refer to > > > https://groups.google.com/g/fricas-devel/c/MZEoqkRMo0Y/m/Dec-ihJGAgAJ > > > > Yes, one my first principal concern is that CL structures are too much > > used. Take FRAC(INT): > > > > (1) -> 1/2 > > > > 1 > > (1) - > > 2 > > (2) -> > > (2) -> % pretend SExpression > > > > (2) (1 . 2) > > (3) -> TYPE_-OF(1/2)$Lisp > > > > (3) CONS > > Do you realize that reprezentation of Fraction is defined in Localize > and it is: > > Rep := Record(num : M, den : R) > > So that is pure Spad definition, having nothing to do with Lisp. > > Spad Record with two fields is represented by Lisp CONS, but that > in principle is changable. If we change this, there may be trouble > in Boot and Lisp code, but Lisp and Boot should use proper accessor > and creation functions (and not raw CONS, CAR and CDR) so the > problem is limited. Of course, we make compromises. To get better > speed several places in algebra use raw Lisp functions. But > in grand picture this is not too bad, in my build tree I see 1062 > uses of 'Lisp', which is 0.5% of total lines, so not too much and > easily identifable. > > > Personally, my "FRAC(INT)" are implemented in C using FLINT (via Julia): > > > > (1) -> QQ(1/2) > > > > 1 > > (1) - > > 2 > > (2) -> % pretend SExpression > > > > (2) #<JLREF 3 #x302000A2C9DD> > > <snip> > > > My principal concern here is that it's tightly related in Spad > > and Boot code to CL. So in some place CL cons take place instead of > > numerator/denominator stuff. I finally managed to modify the boot code > > to take into account NMfraction, but it's an horror to me, I do not > > want to modify the FriCAS internals (NM means Nemo [1] here): > > Well, FriCAS uses generic code so 'FRAC(INT)' may use generic routines > which _assume_ that 'FRAC(INT)' is represented as a Record. Almost > 20 years ago there was proposal to use Lisp rationals as a representation > for 'FRAC(INT)'. That gave significant speedup for calculation with > rational numbers. But _that_ would bake in irregular dependency on > Lisp. Most FriCAS calculations are done on integers and speed of > rational numbers have modest impact on typical computations, so > I decided that a little speedup was not worth complication. > > Your use of Julia rationals is analogus to this "Lisp rationals for > FRAC(INT)" change, but you introduce dependency on Julia (instead of > Lisp dependency). > > <snip> > > > This is my first principal concern. The second one is that SUP is > > almost everywhere in FriCAS (at Category level in fact - ???). I can > > understand its use, it's "universal" in the sense that > > SingletonAsOrderedSet (the "?", the indeterminate) allows you to create > > polynomials without specifying the indeterminate/variable, but again, > > its CL structure is heavily used at Spad and Boot level. > > Again, that is general Spad definition. > > > Moreover I > > have some difficulties, my fault, in creating them. All the POLYs > > stuff is somewhat a big piece > > of code, and for sure well done, but I am not in the head of the > > code's writers. > > Well, there are no free lunch. Our multivariate polynomial code > uses rather simple idea: a multivariate polynomial is a > univariate polynomial in main variable with coefficients > being multivariate polynomials in remaining variables. That > leads to simple recursive implementation of basic operations. > But to get better speed we compromise in few places. And > some operations like gcd or factoring need complex algorithms > to get reasonable speed. > > And some parts want different representation so they reimplement > some basics. > > -- > Waldek Hebisch > > -- > You received this message because you are subscribed to the Google Groups > "FriCAS - computer algebra system" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/fricas-devel/aTLz-jjvI2JOhk8D%40fricas.org > . > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZzB7Pyfuut25bWbPY%3DuzNJb%2BxPL-Q7av%3Dh6MiuLD6FKQ%40mail.gmail.com.
