Thank you for the detailed explanations. I see the problems and would agree that keeping retraction to coefficients has priority. In user code one may easily get along with the current state. In the meantime I've been trying to rewrite some functions avoiding XDP, i.e. just using Free-Monoid/Module. In the course of this I found the following peculiarity when using listOfTerms/construct:
R:=EXPR INT FMR:=FreeModule(R,Symbol) [a,b,c]:=[s::FMR for s in [a,b,c]] T:=a+b+c lT:=listOfTerms T clT:=concat(lT,lT) c1:=construct(clT)$FMR c2:=constructOrdered(clT)$FMR c1+c2 c1-c2 c1-c1 c1+c1 --- better! d1:=reduce(_+,[construct([s])$FMR for s in clT]) d1-d1 d1+d1 Apparently it's favourable to construct each term as the single member of a list, otherwise the collection/simpl procedure seems to be puzzled (like me). Is this intentional? On 30.04.2022 01:03, Waldek Hebisch wrote: > I am looking at problem reported by Kurt Pagani. Direct reason > for trouble is that up to 1.3.6 FreeModuleCategory exported > retraction to base set. This retraction is no longer present > in 1.3.7. FreeModule still has such retraction, but > XPolynomialRing which inherits implementation from FreeModule > among other is of category FreeModuleCategory and no longer > exports this retraction. XDistributedPolynomial which officially > exorts 'retract' used to inherit implementation from XPolynomialRing, > but in 1.3.7 XPolynomialRing has no 'retract' so also > XDistributedPolynomial has no implemetation of 'retract'. > > At first glance this may look easy to fix. But there is deeper > trouble. Trying to export 'retract' from FreeModuleCategory > leads to trouble with polynomials. Reason is easy to see: > various retractions are distinguished only by target type. > If we have several retractions with the same target type, > then overloading does not work (retractions have quite > different effects, but our overloading machinery gives no way > to choose right one). In particular, for univariate polynomials > NNI is type of exponents, but also legal type for coefficients. > Worse, NNI is subtype of Integer and our retraction machinery > assumes that it can use retraction to Integer even when NNI is > requested. > > Anyway, in general having retraction both to T1 and T2 is unsafe > unless we are sure that T1 is different than T2. In case of > commutative polynomials currently we have retraction to variables > and retraction to coefficients. AFAICS this is unsafe, as we can > form SparseMultivariatePolynomial(Integer, Integer), that > is Integer may serve both as coefficients and as variables. > More generally, any ordered commutatitve semiring may serve > such dual purpose. > > In case of XDistributedPolynomial ATM there is only one exported > retraction, that is retraction to exponents. However, is would be > natural to have retraction to coefficients (such retraction makes > sense for any algebra with unit). For XDistributedPolynomial > this still is safe, as coefficients are required to be a ring > and exponents are FreeMonoid which is not a ring. But > in case of XPolynomialRing in principle coefficients may be > the same as exponents (both can be a ring), so having two > retractions is unsafe. > > I admit that ATM I am not sure what to do. Inside algebra > probably most sensible solution is to keep retraction from > polynomials to coefficients (which is very fundamental) and > avoid use of other retractions. It is less clear if we > should keep exporting extra retractions for use in user > code or ban them as potentially unsafe. > -- 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 fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/77ce72c1-7348-c875-2660-8462a32c37b3%40gmail.com.
