On Mon, Feb 01, 2021 at 11:57:10AM -0800, Tobias Neumann wrote:
> 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 Expression(Complex(Fraction(Integer)))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?
By design FriCAS type constraints are in terms of domains and
not in term of elements. So either conditions are satisfied
when you use Expression(Complex(Fraction(Integer))) or not.
If conditions are satisfied you can just use it instead of FE.
Using FE means that your package is more general (because
potentialy other domains satisfy your contraints) and
hopefuly more clear (because contraints are explicit).
However if you cram a lot of different things into single
package, then it is no longer clear which constraint is
relevant for specific aspect, so hardcoding FE to
Expression(Complex(Fraction(Integer))) may be better.
Concerning elements: usual pattern is use of 'retractIfCan'
to test if your element logically belongs to smaller
domain (which may satisfy stronger constrants). Another
aspect is domain inheritance: contrants may be related
to availability of some functions. If you can provide
reasonable implementation of needed functions, then
you can create new domain which is essentially like
old one but adds new function.
To put is differently: types serve as compile-time assertions
about all values of given type. If your value satisfies
stronger condition, then you can create new type (new
stronger assertion) and convert value to the new type.
Note thar 'convert' here may be as trivial as using
'pretend' (if your new type uses the same representation
as on old one) or may involve substantial computation
(like convertion between Expression(Integer) and
Expression(Fraction(Integer))).
Another pattern is conditional definiton: if you want
your package to be general you can condtionally define
functions based on propertied of types. 'approximate'
above is an example of this pattern: other operations
are more general, but 'approximate' need ability to
coerce variable name (a symbol) to element of coefficnt
domain. To support Puiseux series 'approximate' needs
ability to compute fractional powers.
BTW: Logically Expression(Complex(Fraction(Integer)))
is the same as Expression(Complex(Integer)), but the
second is usually more efficient. So I wonder why
you use Expression(Complex(Fraction(Integer))).
> 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?').
Lack of 'smaller?' was a bug. Apparently you are doing things
differently than other folks, so you were first to notice
the problem. Thanks for info: I now commited fix to the trunk.
BTW: 'smaller?' is supposed to implement axiom of choice, that
is linear order that may have no special connection to mathematical
properties of domain. There are deep problems with current
implementation for 'Expression', but implementation for 'Vector'
do not present any difficulty.
> 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.
AFAICS Expression(Complex(Fraction(Integer))) should satisfy your
constraints without need to add anything.
In slightly different tone: if you feel that some domain/package
should have some operation and type constraints prevent using it,
then ask here. Usually there is good reason why type constraints
are there, in such case other domain/package may be more appropriate.
But there are also cases where constraints are not needed, then
we can improve FriCAS by removing spurious limitations.
> 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.
No. This part never worked well and was removed long ago. I now
removed the remaining traces.
--
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/20210202002124.GA4275%40math.uni.wroc.pl.
