missing implementation bug (?)

[Ralf Hemmecke]

Hi Kurt, hi Waldek,

I have reworked my program from

https://groups.google.com/d/msg/fricas-devel/tFSAAzvFkp0/sRlfheFGBAAJ
Waldek might want to look here:
https://www.mail-archive.com/fricas...@googlegroups.com/msg13722.html

but put it into a new thread, since I believe it is another issue than
the missing "category default implementation".

I really cannot make sense out of the error in the attached program.
Why would it in some cases work fine and in others not? That is quite
frustrating. Anyone spots an error in my code? Or is it another compiler
bug?

Ralf




(1) -> f1()$Bar(Fraction Integer)
2 3
[:> , px1, 1 + q + q + q ]
Type:
Void
(2) -> f2()$Bar(Fraction Integer)
Internal Error
The function px with signature () -> UnivariateLaurentSeries(
SimpleAlgebraicExtension(Fraction(Integer),
SparseUnivariatePolynomial(Fraction(Integer)),?^2+1),q,0) is
missing from domain Foo
(SimpleAlgebraicExtension (Fraction (Integer))
(SparseUnivariatePolynomial (Fraction (Integer))) ((2 1 . 1) (0 1 . 1)))
(UnivariateLaurentSeries (SimpleAlgebraicExtension (Fraction
(Integer)) (SparseUnivariatePolynomial (Fraction (Integer))) ((2 1 . 1)
(0 1 . 1))) (QUOTE q) 0)


(2) -> C ==> Fraction Integer
Type:
Void
(3) -> minrootpol: SUP C := monomial(1,2)$SUP(C) + 1

2
(3) ? + 1
Type:
SparseUnivariatePolynomial(Fraction(Integer))
(4) -> CX ==> SimpleAlgebraicExtension(C, SUP C, minrootpol)
Type:
Void
(5) -> L1 C ==> UnivariateLaurentSeries(C, 'q, 0);
Type:
Void
(6) -> px2 := px()$Foo(CX, L1 CX)

2 3
(6) 1 + q + q + q
Type:
UnivariateLaurentSeries(SimpleAlgebraicExtension(Fraction(Integer),SparseUnivariatePolynomial(Fraction(Integer)),?^2+1),q,0)
(7) ->

[Waldek Hebisch]

On Tue, Nov 03, 2020 at 11:07:14PM +0100, Ralf Hemmecke wrote:
> Hi Kurt, hi Waldek,
>

> I really cannot make sense out of the error in the attached program.
> Why would it in some cases work fine and in others not? That is quite
> frustrating. Anyone spots an error in my code? Or is it another compiler
> bug?

First guess is that this is due to different handling of constants
in types in various part of FriCAS (this is known bug).
Try consitently keeping parameters as variables and pass actual
values from interpeter only at one place.

--
Waldek Hebisch

[Kurt Pagani]

Strange, indeed. The CATs seem to be ok.
When taking minrootpol and CX out of the body of f2, the it works.


)abbrev package BAR Bar
Bar(C: IntegralDomain): with
f1: () -> Void
f2: () -> Void
== add

minrootpol: SUP C := monomial(1,2)$SUP(C) + 1

CX:=SimpleAlgebraicExtension(C, SUP C, minrootpol)

f1(): Void ==
px1 := px()$Foo(C, L1 C)
dbgPrint("px1", px1)

f2(): Void ==

px2 := px()$Foo(CX, L1 CX)

dbgPrint("px2", px2)

Bar is now explicitly exposed in frame initial
Bar will be automatically loaded when needed from
/Users/kfp/AppData/Local/Temp/BAR.NRLIB/BAR

(3) -> f2()$BAR(FRAC INT)
2 3
[:> , px2, 1 + q + q + q ]
Type: Void
(4) -> f1()$BAR(FRAC INT)

2 3
[:> , px1, 1 + q + q + q ]
Type: Void

(5) ->

[Ralf Hemmecke]

>> I really cannot make sense out of the error in the attached program.
>> Why would it in some cases work fine and in others not? That is quite
>> frustrating. Anyone spots an error in my code? Or is it another compiler
>> bug?
>
> First guess is that this is due to different handling of constants
> in types in various part of FriCAS (this is known bug).
> Try consitently keeping parameters as variables and pass actual
> values from interpeter only at one place.

I assume that you answer to the problem in this thread and not to

https://www.mail-archive.com/fricas...@googlegroups.com/msg13722.html
(which more looks like an issue with category default
implementations---but maybe you say it's the same issue).

Anyway. in

===========

Bar(C: IntegralDomain): with
f1: () -> Void
f2: () -> Void
== add

f1(): Void ==
px1 := px()$Foo(C, L1 C)
dbgPrint("px1", px1)
f2(): Void ==

minrootpol: SUP C := monomial(1,2)$SUP(C) + 1

CX ==> SimpleAlgebraicExtension(C, SUP C, minrootpol)

px2 := px()$Foo(CX, L1 CX)

dbgPrint("px2", px2)
===========

minrootpol IS a variable and f2 leads to a problem (as seen in my
previous mail).

In my original program I want something like minrootpol to be computed
from other data that eventually come from a user input.
So your suggestion does not really help me to get around this problem.

If it were Aldor, I would probably write something like this:

f3aux(minrootpol: SUP(C)): Void ==

CX ==> SimpleAlgebraicExtension(C, SUP C, minrootpol)

px3 := px()$Foo(CX, L1 CX)
dbgPrint("px3", px3)
f3(): Void ==

minrootpol: SUP C := monomial(1,2)$SUP(C) + 1

f3aux(minrootpol)
f4(): Void == f3aux(monomial(1,2)$SUP(C) + 1)

because arguments of functions are supposed to be constants (as far as I
remember). However in FriCAS that does not help.

The question is, how would I have to program f2 so that it will work as
expected? This problem is a real blocker for me. :-(

Ralf

[Ralf Hemmecke]

On 11/4/20 12:05 AM, Kurt Pagani wrote:
> Strange, indeed. The CATs seem to be ok.
> When taking minrootpol and CX out of the body of f2, the it works.

OK, good to know, but I don't think it will help me since in fact, I
want to get minrootpol from

cyclotomic(n)$CyclotomicPolynomialPackage

and the n is computed from some other data at runtime.
So moving it out of the function is not of big help, since I want to
create this SimpleAlgebraicExtension at runtime.

FriCAS should be able to do this.

Ralf

[Waldek Hebisch]

On Wed, Nov 04, 2020 at 09:32:45AM +0100, Ralf Hemmecke wrote:
> >> I really cannot make sense out of the error in the attached program.
> >> Why would it in some cases work fine and in others not? That is quite
> >> frustrating. Anyone spots an error in my code? Or is it another compiler
> >> bug?
> >
> > First guess is that this is due to different handling of constants
> > in types in various part of FriCAS (this is known bug).
> > Try consitently keeping parameters as variables and pass actual
> > values from interpeter only at one place.
>
> I assume that you answer to the problem in this thread

Yes.

> and not to
>
> https://www.mail-archive.com/fricas...@googlegroups.com/msg13722.html
> (which more looks like an issue with category default
> implementations---but maybe you say it's the same issue).

I think they are closely related.

> Anyway. in
>
> ===========
> Bar(C: IntegralDomain): with
> f1: () -> Void
> f2: () -> Void
> == add
> f1(): Void ==
> px1 := px()$Foo(C, L1 C)
> dbgPrint("px1", px1)
> f2(): Void ==
> minrootpol: SUP C := monomial(1,2)$SUP(C) + 1
> CX ==> SimpleAlgebraicExtension(C, SUP C, minrootpol)
> px2 := px()$Foo(CX, L1 CX)
> dbgPrint("px2", px2)
> ===========
>
> minrootpol IS a variable and f2 leads to a problem (as seen in my
> previous mail).

Sorry, I see some potential troubles above:
- Spad compiler can see what value is assigned to 'minrootpol'
and almost surely uses this value
- you still have expressions in parameters, in particular
you call freshly constructed type

Spad compiler normally uses unevaluated expressions (parse
trees). At runtime parameters must be evaluated, so
runtime support routines normally handle values. But
there is lazy evaluation and databases which store
unevaluated expressions, so runtime support have
to evaluate expressions when needed and in general
handle both forms. Interpreter adds extra complication
to the mix: it uses different representation and
evaluates much more eagely than compiler. In ideal
world at any given place in code it would be
clear which representation is in use and there
would be convertions in right places. Reality
is messy...

I am not sure if I can shortly explain coding rules that I use.
Basically, I am trying to control when evaluation happen
and to make sure that type-correctness does not depend
on exact values.

You may look at PartialDifferentialOperator, TwoFactorize
and maybe FS2UPS. In particular PartialDifferentialOperatorHelper
exists only to help Spad compiler. In TwoFactorize
function 'doExtension' perform type choice at runtime. Doing
the same with less indirection would led to slow code or
fail. In FS2UPS code written like you tried either would
not compile or fail at runtime. Current arrangement with
split into FS2UPS and FS2UPS2 works...
--
Waldek Hebisch

[Kurt Pagani]

On 04.11.2020 11:47, Ralf Hemmecke wrote:
> On 11/4/20 12:05 AM, Kurt Pagani wrote:
>> Strange, indeed. The CATs seem to be ok.
>> When taking minrootpol and CX out of the body of f2, the it works.
>
> OK, good to know, but I don't think it will help me since in fact, I
> want to get minrootpol from
>
> cyclotomic(n)$CyclotomicPolynomialPackage
>
> and the n is computed from some other data at runtime.
> So moving it out of the function is not of big help, since I want to
> create this SimpleAlgebraicExtension at runtime.

Seemingly it also works by using macros, so this may be a work-around?
Not nice perhaps, but ...

Bar(C: IntegralDomain): with
f1: () -> Void
f2: () -> Void
== add

--minrootpol: SUP C := monomial(1,2)$SUP(C) + 1
--CX ==> SimpleAlgebraicExtension(C, SUP C, minrootpol)

minrootpol(X) ==> monomial(1,2)$SUP(X) + 1
CX(Y) ==> SimpleAlgebraicExtension(Y, SUP Y, minrootpol Y)

f1(): Void ==
px1 := px()$Foo(C, L1 C)
dbgPrint("px1", px1)

f2(): Void ==

px2 := px()$Foo(CX(C), L1 CX(C))
dbgPrint("px2", px2)

[Ralf Hemmecke]

> Seemingly it also works by using macros, so this may be a work-around?
> Not nice perhaps, but ...

Great. Thank you for this suggestion. Unfortunately, it only helps in my
cut-down example for the demonstration of the problem, but my actual
code is more complicated and there it's not so easy to use macros. It
would lead to re-evaluation of functions that I only want to compute
once. Also introducing a new function and passing the respective
function values as parameters did not work. But maybe I was not careful
enough.

I'll try to figure out what Waldek's suggestion might mean for my code.
It is unfortunate anyway that this restriction and its possible
workaround is not documented. :-(

Ralf

[Kurt Pagani]

The strange thing is, that *now* there's no need to get the macros out of the
body ;) Hence, I guess the problem is related to type coercion. If you could
rewrite the macros to local functions (w. types), e.g. minrootpol(X:Type):?,
then ... maybe.


f2(): Void ==

minrootpol(X) ==> monomial(1,2)$SUP(X) + 1
CX(Y) ==> SimpleAlgebraicExtension(Y, SUP Y, minrootpol Y)

px2 := px()$Foo(CX(C), L1 CX(C))
dbgPrint("px2", px2)