modmap selection

[Ralf Hemmecke]

Hello Waldek,

in the package I have written, I called (wrongly)

precision(e1)

and got the answer 1. That surprised me a bit, since e1 was of type

(171) -> e1

2 3
(171) 1 - q - q + O(q )
Type: QEtaTayloreries(Fraction(Integer))

and for that the function precision was not defined.

I cut the definition down to a simple file (attached).
The interpreter seems to find some way to convert an element of type
QEtaTaylorSeries(QQ) into QEtaTruncatedTaylorSeries(QQ) and that
although there is neither a coerce nor a convert or retract function
available.

The output of

)co foo.spad
)set stream calc 4
QQ ==> Fraction Integer
T ==> QEtaTaylorSeries(QQ)
q := monomial(1,1)$T
s := 2*recip(1-q)::T
)set message bottom on
precision s

surprisingly is

(69) -> s := 2*recip(1-q)::T

2 3 4 5
(69) 2 + 2 q + 2 q + 2 q + 2 q + O(q )
Type: QEtaTaylorSeries(Fraction(Integer))
(70) -> )set message bottom on
(70) -> precision s

Function Selection for precision
Arguments: QETATS(FRAC(INT))
-> no appropriate precision found in
QEtaTaylorSeries(Fraction(Integer))
-> no appropriate precision found in
QEtaTaylorSeries(Fraction(Integer))

Modemaps from Associated Packages
no modemaps

Remaining General Modemaps
[1] PositiveInteger -> PositiveInteger from D
if D has ATARBPR and D has FPS
[2] QEtaTruncatedTaylorSeries(D2) -> NonNegativeInteger
from QEtaTruncatedTaylorSeries(D2) if D2 has RING

[1] signature: QETATTS(QETATS(FRAC(INT))) -> NNI
implemented: slot (NonNegativeInteger) from
QETATTS(QETATS(FRAC(INT)))

[:> , QTTS: prec, 1]
[:> , *prec, 1]
[:> , x, [1]]
[:> , QTTS: prec, 1]

(70) 1
Type: PositiveInteger

What is the interpreter doing here? It somehow called
1$QEtaTaylorSeries(Fraction(Integer)), but why?

Is there a nice explanation that cannot be read from the modemap selection?

Thank you
Ralf

[Waldek Hebisch]

On Sun, Jun 18, 2023 at 05:21:42PM +0200, Ralf Hemmecke wrote:
> Hello Waldek,
>
> in the package I have written, I called (wrongly)
>
> precision(e1)
>
> and got the answer 1. That surprised me a bit, since e1 was of type
>
> (171) -> e1
>
> 2 3
> (171) 1 - q - q + O(q )
> Type: QEtaTayloreries(Fraction(Integer))
>
> and for that the function precision was not defined.
>
> I cut the definition down to a simple file (attached).

The file just invokes ')compile' but I see no .spad file.

> The interpreter seems to find some way to convert an element of type
> QEtaTaylorSeries(QQ) into QEtaTruncatedTaylorSeries(QQ) and that although
> there is neither a coerce nor a convert or retract function available.

Actually there is one more possibility, namely 'map'. 'map' is used
to lift coercions from base domain to derived domains.

Well, modemap selection has many special cases and those print tracing
and debugging info. But if no special case apply, then FriCAS tries
"general modemap selection". Unfortunately, there is almost no
debugging info in general case. And the code has know bugs, for
example it may create invalid types. Before the problem is
solved it is hard to say if you see one of know bugs or a new bug.
Or maybe the case above works as designed due to some unexpected
coincidence.

It seem that Weber paper which was in reference section on the wiki
gives outline of the method.

--
Waldek Hebisch

[Ralf Hemmecke]

On 21.06.23 16:24, Waldek Hebisch wrote:
>> The file just invokes ')compile' but I see no .spad file.

I am sorry. Now the .spad file is attached as well.

Ralf

[Waldek Hebisch]

Well, we have:

(7) -> s::QETATTS(QETATS(FRAC(INT)))

[:> , QTTS: prec, 1]
[:> , *prec, 1]
[:> , x, [1]]

2 3 4 5
(7) [2 + 2 q + 2 q + 2 q + 2 q + O(q )]
Type: QEtaTruncatedTaylorSeries(QEtaTaylorSeries(Fraction(Integer)))


And that is clear: we have coercion form coefficient domain, that
is QEtaTaylorSeries(Fraction(Integer)) to series domain. And
interpreter uses 'precision' from domain above...

So, it looks that FriCAS this time works as designed, but there
are unexpected consequences.

--
Waldek Hebisch