Dear FriCAS group,
@Waldek: As it turns out 95% of the issues I was generally facing were
caused by missing import's. So thank you for that and further insight.
I am currently writing functions that require series expansions, conversion
from Complex(Fraction(Integer)) to Complex(Float) (CF) and back to
Complex(Fraction(Integer)) (CFI) to approximate longer exact expressions in
the CFI domain, possibly integration, and pattern matching.
I have started the package with domains
R : Join(GcdDomain, Comparable, RetractableTo Integer, _
LinearlyExplicitOver Integer)
FE : Join(AlgebraicallyClosedField, TranscendentalFunctionCategory, _
FunctionSpace R)
So if my function operates on FE, I can do series expansions
In practice I start with (call the function with) expressions in the domain
Expression(Complex(Fraction(Integer))), which are fed to the FE functions.
The reason I have to use FE Is because the use of 'approximate' from series
expansions requires additional operations that are implied by these type
constraints:
if Coef has coerce : Symbol -> Coef then
if Coef has "^": (Coef,RN) -> Coef then
Is there a way to just have a function in the concrete domain
Expression(Complex(Fraction(Integer))) and demand that it further satisfied
these constraints? Or is this not something that makes sense?
Moving on I further wanted to have some debug prints, so I had to add
"ConvertibleTo InputForm" to FE. To have the most general
integration routine working I added "PrimitiveFunctionCategory,
AlgebraicallyClosedFunctionSpace R" to FE and "CharacteristicZero,
PolynomialFactorizationExplicit" to R.
I also want to use pattern matching on FE expressions, so I added
"PatternMatchable Integer" to R.
Now I am facing the problem that I want to approximate some expressions in
FE
(I concretely call the FE function with an
Expression(Complex(Fraction(Integer))) argument)) using
rationalFunction$Float. So I added
CoercibleTo Expression(Complex(Float)), _
CoercibleTo Expression(Complex(Fraction(Integer))), _
to FE. This allows me to convert some FE expressions to
Expression(Complex(Float)) and I was hoping that in an additional step I
could coerce back to FE. So
Step1: coerce FE to ECF
Step2: coerce ECF to Expression(Complex(Fraction(Integer))) and hopefully
back to FE
As it turns JUST adding these additional type constraints was not a good
idea, and I get a runtime crash even with an empty function: Function:
smaller? : (%, %) -> Boolean is missing from domain:
Vector(Complex(Fraction(Integer)))
(Obviously this makes sense that there is no 'smaller?').
It looks to me like I'm lost in type constraints. Maybe all of this can be
solved if I can start with a domain Expression(Complex(Fraction(Integer)))
and specify additional constraints that allow me to use approximate, etc.,
whatever isn't implied.
I am not sure if I can expect a concrete answer to these issues, but I
would be happy for some suggestions. Maybe I am missing something
fundamental that would resolve such issues immediately.
Another question: Is the ")translate" option for ")compile" still
supported? The manual implies that this can be used to translate SPAD code
into Aldor code.
Thank you,
Tobias
--
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/56615957-67bc-4751-87bf-c75ded560ec1n%40googlegroups.com.
