Ralf Hemmecke wrote:
>
> > Thinking loudly. In order to integrate trigonometric
> > functions we need imaginary unit. So, if not present we
> > need to add it, that is extend the original field. Currently
> > this is done by changing base ring from R to Complex(R).
> > OTOH if imaginary unit is present we should use it.
>
> Hmmm... also thinking loudly...
> We cannot and should not have Complex Complex R, but what about a domain
>
> ComplexClosure(R: CommutativeRing): ComplexCategory(R) with ...
> == if R has with imaginary: () -> R then R else Complex R
>
> Would this be the wrapper that you want? To me that looks like an
> elegant solution.
>
> Of course there can be rings R that don't export "imaginary" and still
> have an element x that satisfies x^2+1=0. But I didn't want a condition
> that checks whether x^2+1 can be factored over R.
>
> As a first approximation, ComplexClosure would do what is needed, no?
> Adding conversion between R and ComplexClosure R shouldn't be difficult.
Well, ATM I am thinking of doig this, but witout introducing such
global constructor. But this is just small part of the whole problem.
We need convertions between Expression(R) and Expression(Complex(R))
which while not very hard is more complicated than convertion
between R and Complex(R). In particular imaginary unit may appear
in final result so convertion from Expression(Complex(R)) to
Expression(R) must properly handle imaginary unit (replace %i by
sqrt(-1) if R is real). Extra factor is that convertions are
supposed to be isomorphisms of differential fields so we need
to remember enough information to be able to compute the inverse.
More precisely, we are embedding smaller field in a bigger one
and getting representation in smaller field requires some
effort.
ATM all involved convertions are split between several steps.
There is some possibility to rationalize things, for example
we first convert trigonometric functions to tangents and
later to complex eponentials. It would be more natural
to do this in one step. But limit code needs real functions
(that is tangents) and currently normalization is shared
between integrator and limit code.
We could probably get simpler code by adding imaginary unit
before anything else. OTOH unneeded imaginary unit is an
extra algebraic extention which may increase cost of other
operations. In the past it could lead to other problems,
but now I hope that the only trouble will be loss of
efficiency. But current code makes some effort to introduce
imaginary unit only when needed and it would be nice
to preserve this property.
--
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
