Zut. I vas responded about it's week-end. It's not... Le sam. 6 déc. 2025, 15:45, Grégory Vanuxem <[email protected]> a écrit :
> 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/CAHnU2dZz7mwDjEd2ybVpchDK78FPAc_2ptJFoE80h%3D0U1PJciA%40mail.gmail.com.
