bug: ContinuedFraction is no longer working

[Ralf Hemmecke]

I just compiled FriCAS f82c476a3dd3e1e1a0311da3271de5715514997d.

Then I get

%%% (13) -> (2/3)::ContinuedFraction(Integer)

Cannot convert the value from type Fraction(Integer) to
ContinuedFraction(Fraction(Integer)) .

%%% (13) -> (2/3)::ContinuedFraction(Integer)

Cannot convert the value from type Fraction(Integer) to
ContinuedFraction(Integer) .

%%% (14) -> 2/(3::ContinuedFraction(Integer))

1 | 1 |
(14) +---+ + +---+
| 1 | 2
Type:
ContinuedFraction(Integer)

And I cannot see why this should happen. Was there a change to
ContinuedFraction that I missed?

FriCAS 1.3.13 still works fine.

Ralf

[Waldek Hebisch]

AFAICS ContinuedFraction itself is fine, for example

2::ContinuedFraction(Integer)/3::ContinuedFraction(Integer)

works. The trouble is in the interpreter:

(2) -> coerce((2/3))$ContinuedFraction(Integer)
There are 78 exposed and 131 unexposed library operations named
coerce having 1 argument(s) but none was determined to be
applicable. Use HyperDoc Browse, or issue
)display op coerce
to learn more about the available operations. Perhaps
package-calling the operation or using coercions on the arguments
will allow you to apply the operation.

Cannot find a definition or applicable library operation named
coerce with argument type(s)
Fraction(Integer)

Perhaps you should use "@" to indicate the required return type,
or "$" to specify which version of the function you need.

So, interpreter can no longer find 'coerce'. Looking at list of
operations is see that 'coerce' is there and I expect that calling
it from Spad would work.

Change is due to commit 8093a181ad571732d134ebcbeb711f3c200d237c,

Export Algebra(Fraction(Integer)) only in characteristic 0

We still have:

(2) -> ContinuedFraction(Integer) has Algebra(Fraction(Integer))

(2) true

so the commit is doing nothing wrong. I suspect that trouble is
because operation list has different order. Unfortunatly, there is
an old interpreter bug in search for operations. Due to this bug
interpreter may sometimes miss operations, depending on their
position in operation list.

Fixing this will take some time

--
Waldek Hebisch

[Ralf Hemmecke]

> So, interpreter can no longer find 'coerce'. Looking at list of
> operations is see that 'coerce' is there and I expect that calling
> it from Spad would work.

OK. I was thinking about a way I can (out of the many coerce functions
that ContinuedFraction exports) specify exactly which one I want, i.e.
help the interpreter what to choose, but I cannot come up with a right
combination of $ and @ to make this work. On the other hand it
recognizes that the argument is Fraction(Integer), and
)show also shows that coerce: Fraction(Integer) -> % is there, so it
should know which function to choose. Obviously, the interpreter thinks,
this particular coerce function is not available. Does it use another
search than ")show"?

Ralf

[Waldek Hebisch]

Actually, for some reason 'coerce' is considerd conditional,
that is valid only when CharacteristicZero holds. And we
have

ContinuedFraction(Integer) has CharacteristicZero

(1) false
Type: Boolean

So there are two problems. First, ContinuedFraction(Integer) should
be of characteristic 0. This looks like missing propagation of
information in algebra. Second, when parameter is Integer we
should have unconditional signature. Fixing any of the above
should fix your original problem.

--
Waldek Hebisch

[Waldek Hebisch]

On Wed, Jun 24, 2026 at 06:25:07PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:

> I just compiled FriCAS f82c476a3dd3e1e1a0311da3271de5715514997d.
>
> Then I get
>
> %%% (13) -> (2/3)::ContinuedFraction(Integer)
>
> Cannot convert the value from type Fraction(Integer) to
> ContinuedFraction(Fraction(Integer)) .

The attached patch should fix the problem. However, with the patch
I see errors in few examples in FriCAS book, I will investigate them.

--
Waldek Hebisch

[Waldek Hebisch]

)show and Hyperdoc use different routine, they do not need search
and just use list of operations. OTOH interpreter may need search
and possibly complicated matching of parameters of domains. The
search code is doing quite a few things which are not needed
when domain providing operation is known.

--
Waldek Hebisch