No response please. Le sam. 6 déc. 2025, 15:48, Grégory Vanuxem <[email protected]> a écrit :
> 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/CAHnU2dauERn635EZ74wqwg4wz2Y6bzmoKYFgbaWxVYRtpt-CxA%40mail.gmail.com.
