Problem with retract

[Waldek Hebisch]

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.

--
Waldek Hebisch

[Kurt Pagani]

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?

[Waldek Hebisch]

On Sat, Apr 30, 2022 at 04:15:46PM +0200, Kurt Pagani wrote:
> 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?

ATM 'construct' assume that you give it valid term list, that is
k-coordinates are different. 'construct' will (if needed) sort the
list for you, 'constructOrdered' assumes that list is already
sorted. Both 'construct' and 'constructOrdered' are speed hacks,
for people who know what they are doing.

--
Waldek Hebisch

[Waldek Hebisch]

I have now added back 'retract' to exponents in XDPOLY and XRPOLY.
Also changed 'monom' to 'monomial' so it behaves more similar
to normal polynomials (but there is buch of other things like
'constant').

Old implementation in XRPOLY wrongly handled multiplication
by noncommutaitve scalars, that is fixed now. As result
elements of XRPOLY are now printed differently, with coefficients
before variables (previously coefficients were at the end).

--
Waldek Hebisch