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/[email protected]/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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20201104115836.GA22085%40math.uni.wroc.pl.
