On Tue, Jul 22, 2025 at 03:30:17PM +0200, 'Ralf Hemmecke' via FriCAS - computer
algebra system wrote:
> Dear Waldek,
>
> On 7/19/25 14:32, Waldek Hebisch wrote:
>
> > > %%% (227) -> R ==> MultivariatePolynomial(['a,'b], QQ)
> > > Type: Void
> > > %%% (228) -> C ==> Fraction R
> > > Type: Void
> > > %%% (229) -> U ==> Polynomial C
>
> %%% (232) -> "x"::Symbol :: U
>
> Polynomial(Fraction(MultivariatePolynomial([a,b],Fraction(Integer)))
> ) is not a valid type.
>
> > Look at 'isLegitimateMode' in clammed.boot: it rejects types where
> > inner and outer polynomial variables intersect.
>
> > For me
> >
> > monomial(1$U, "x"::Symbol, 1)$U
> >
> > which avoids ambiguity works.
>
> Hmmmm... that now makes me wonder when the 'isLegitimateMode' actually is
> applied/called. I seem to remember that I could achieve a working situation
> (though I used Polynomial and below some multivariate polynomial type) in
> compiled code.
AFAICS isLegitimateMode' is only used by interpreter.
> Your 'monomial' construction and also a working 1$U seems to suggest that
> not the type itself is problematic, but the (auto-)coercion. Understandble.
>
> Anyway, I have looked at 'isLegitimateMode' and must say, that I am somewhat
> unhappy with it. The reason is that it lists explicitly some types like
> Polynomial, Expression, Complex. I understand that this might have been done
> to prevent users from running into troubles later, however, coding that
> logic in BOOT and not SPAD, but with explicit identifiers from the SPAD
> library, I don't know... If I now go and invent a new polynomial domain. It
> is certainly not covered by this boot logic. Yes, yes, I don't know how to
> do it better, still I feel uneasy about it.
Yes, I feel the same.
> Anyway, if I use a construction like your 'monomial', i.e. create an element
> of a domain like U that has no ambiguity in its creation, can it happen that
> I will ever by bitten later (always assuming that I never use any of the
> function that potenially are ambiguous. i.e. depend on variable
> names/symbols)?
>
> Technically a type like Polynomial(Polynomial(INT)) is not a problem and
>
> %%% (9) -> PPI ==> Polynomial(Polynomial INT)
> %%% (10) -> one := 1$PPI
>
> (10) 1
> Type: Polynomial(Polynomial(Integer))
>
> seems to confirm this. But then why doesn't the following work
>
> %%% (12) -> ppi:PPI := 1$PPI
>
> Polynomial(Polynomial(Integer)) is not a valid type.
>
> Obviously, (12) triggers a call to 'isLegitimateMode' whereas
> (10) does not.
I am not sure how to trigger all places that call 'isLegitimateMode'.
But some are below:
1@PPI
that is check in 'upTARGET'
1::PPI
that is check in 'upCOERCE'
ppi : PPI
that is check in 'upDeclare'
There are 3 uses in i-coerce.boot and 1 use in i-funsel.boot that do not
produce error message (they just refuse to use some signatures).
Of the above they may be related. IIUC implementation of '@' has
restrictions and original authors probably preffered to avoid some
hairy cases. Declaration later works in similar way to '@' (I did
not check if code is shared, but effect is similar). Coercion
may have more problems.
You could try to comment out the checks above and see what happens.
> Suppose, I create a type
>
> Foo(C: Ring): Polynomial C == ...
>
> If I am careful with constructing the element of the return type (like your
> 'monomial' above), would such code compile even if I later instatiate
> Foo(Polynomial(INT))?
>
> I (as a user) are aware of the potential variable overlap, but take care of
> that myself. My question is whether SPAD might prevent me at some point from
> doing this or kick in (via BOOT code) at some unexpected places.
>
> Maybe this question is too hard to answer, but maybe you happen to know and
> have some experience. For now I could live with a restriction of being
> unable to call Foo(Polynomial(INT)), but it would be good to know whether I
> must think of something else if ever I have need to call
> Foo(Polynomial(INT)).
AFAICS Spad compiler is not affected by 'isLegitimateMode'. When
compiling Spad will accept such types with ususal disclaimer, that
is when resolving overloads Spad will you first function that it
finds. But overload resolution happens at compile time. Later
one may be affected by search order, but search order is reasonably
well defined and with sane implementation I would not expect
troubles here. Anyway, the point is that when compiler sees
Polynomial(Polynomial(INT)) and later 'monomial' it will try
'monomial' both from Polynomial(INT) and Polynomial(Polynomial(INT)).
Type rejected by 'isLegitimateMode' are used is several places
in algebra, so I would not expect serious troubles using them
(only some care to ensure correct choice of overloads).
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/aIAwloTedCe2802n%40fricas.org.
