Riccardo GUIDA wrote:
>
> Below you'll find some thoughts/questions you might want to comment/answer.
Just a few quick comments.
> These thoughts concern the user interface for the inverse functions, which is
> a topic that periodically returns in the list.
>
> In the past you repeatedly spoke of users with inconsistent wishes, so,
> to be more "precise", let me start by setting up some "notation",
> reviewing some facts I learned from the list.
>
> I will restrict to log and sqrt for shortness and expose the various ways
> such functions might be defined.
>
> All the definitions below (apart maybe SetValuedExpression, I do not know)
> should respect the property that
> these functions are right-inverses under composition, ie
> (sqrt(x))^2 =x exp(log(x))=x for every x in their domain D.
>
> --- PrincipalBranchExpression ---
>
> Let the PrincipalBranchExpression be a domain of analytic, complex valued
> functions each defined by its respective ``principal branch'',
> ie defined in a cut complex plane,
> the cuts being arbitrarily but conventionally agreed to be as detailed
> eg by Olver et al. in [2]:
>
> sqrt, log: D -> C where D:=C -[0,-oo] (I neglect boundaries for simplicity).
>
> For every z1,z2 in D such that z1*z2 in D we have the nice relations
> sqrt(z1)*sqrt(z2)=sqrt(z1*z2) and log(z1)+log(z2)=log(z1*z2) (1)
Unfortunately no. You have equalty when additionaly real parts of
z1 and z2 are nonnegative. But in whole D things are "interesting".
> In my knowledge this domain and (1) is well-defined mathematically
> but has not a nice algebraic properties adapted to "Risch... algorithm"
> and no algorithms to decide if A=0 in full generality. Too Bad.
>
> On the other hand,
> a heuristic & arbitrary "simplify" is possible,
> based on pattern-matching transformations, eg
> implementing a bunch of transformation rules (including (1)) and choosing
> the best/shortest result based on some arbitrary expression length function.
>
> This is the domain in which happily & daily work thousand of researchers out
> there,
> using Maxima, Sympy and other CAS I do not master or afford.
>
> I guess that (1) is applied automatically by these CAS whenever its hypotheses
> may be proven to be satisfied, hence the following replacements are
> likely to be exploited.
> sqrt(2)*sqrt(3)<~>sqrt(6) and sqrt(1-i)sqrt(1+i)<~>sqrt(2)
>
> --- RealExpression ---
>
> One may define a domain RealExpression of
> regular functions on a real subset,
> sqrt, log: D -> R where D:=(0,oo) (I neglect boundaries for simplicity).
>
> At the price of banning some incompatible "highschool relation"
> (like (-1)^(1/3)=-1)
> I guess that one can consider the functions in RealExpression as appropriate
> restriction of functions in PrincipalBranchExpression,
> up to optimizations that exploit reality to improve the speed.
> So I do not consider any more this domain.
>
> --- AnyBranchExpression ---
>
> Let AnyBranchExpression be the domain of analytic complex valued
> functions, each well-defined on some arbitrary cut complex plane,
> not necessary the ``principal branch''.
>
> In this case a to a function with a single branch point
> correspond in general a non countable
> infinity of functions, think for instance
> sqrt, log: D -> C where D:=C-[0,oo]*e^{i theta}
> with theta in R
> and also to the fact that the cut need not to be a straight line.
>
> Now I give some possible approaches to "multi-valued" functions:
>
> --- RiemannSurfaceExpression ---
>
> Let RiemannSurfaceExpression be the domain of meromorphic functions
> defined on Riemann surface.
Well, Riemann surface is a nicer variant of arbitrarily cut
plane. Instead of saying that you are not allowed to cross
the cut we essentially say that crossing cut puts you on
different sheet of the surface.
> sqrt, log: D -> R where D "is" {(r,phi): r in R_+ and phi in R }
>
> for every z1,z2 in D
> sqrt(z1)*sqrt(z2)=sqrt(z1*z2) and log(z1)+log(z2)=log(z1*z2) (2)
Actually, you have the some trouble with (2) as with (1).
> --- SetValuedExpression ---
>
> Let SetValuedExpression be a domain of set-valued functions:
>
> sqrt: C-{0} -> Parts(C),
> x|-> { princbranchsqrt(x), -princbranchsqrt(x)}.
>
> log: C-{0} -> Parts(C),
> x|-> {princbranchlog(x)+2pi i k, with k in Z}.
>
> I see that there are attempts to construct a mathematical theory of these
> set valued functions [3]
>
> IIUC the product in this space is defined by direct product:
> f(x)*g(y) = { zf*zg with zf in f(x) and zg in g(y)}.
IMO this is misguided. Set valued approach gives approximation
to reality, but this approximation is rather crude.
> --- DifferentialField ---
>
> (The following domain is quite new to me and I have much to learn,
> so forgive my sloppiness)
>
> Let DifferentialField be some *abstract* field endowed with an additive
> derivative
> satisfying Leibniz rule and extending the rational fild Q(x).
>
> This is the natural framework for implementing the "Risch... algorithm"
> for finding antiderivatives.
>
> (I do not really know how should define the algebraic "functions" here.
> See below.)
>
> In this field one defines
>
> log(x) by D(log(x))=1/x
>
> Actually this does define log(x) "up to a constant", so I do not know if this
> log(x) has something to do with the other log(x) defined in the other domains.
>
> As an aside:
> Are the elements of DifferentialField naturally isomorphic to
> *concrete, numerical* functions?
> I had a really fast-and-furious look at Siedenberg's embedding theorem [4]
> "Finitely generated differential field in characteristic zero
> is isomorphic to a subfield of field of meromorphic functions
> in a domain"
> but I have not yet really understood in which domain these meromorphic
> function are defined nor if the construction is unique.
The embedding is highly non-unique. For example Q(z, exp(\pi z))
and Q(z, exp(e z)) are isomorphic as differential fields, but
quite different from point of view of number theorists.
> So I cannot really say what is the numerical value of S(log)(2)
> where S is the Siedenberg isomorphism.
>
> I wonder if the abstract functions DifferentialField in are related
> (up to constants) to the ones in RiemannSurfaceExpression defined above.
>
> --- Discussion ---
>
> As far as I understand, FriCAS user interface is currently heavily biased by
> its implementation of the "Risch... algorithm".
> In this sense, Expression R when R = Integer / Complex Integer tries to model
> a DifferentialField. This results in default simplification rules that are too
> weak as compared to the PrincipalBranchExpression.
> Eg sqrt(2)*sqrt(3)-sqrt(6) is not zero.
>
> Now the thoughts/questions.
>
> 0)
> As shown above there are a *lot* of possible meanings for sqrt, log ...
>
> A general problem is that the different semantics have the same Input and
> Output form
> and it is not always clear in which mathematical semantics one is exposed.
>
> Of course one reads Type: Expression Integer or Expression Complex on the
> right
> but this is not a guarantee that the relations proper to
> PrincipalBranchExpression or RealExpression are applied.
>
> For instance one writes sqrt(2), one sees the usual graphical sqrt V2 but
> this has
> not the meaning that a lot of people would think, ie +1.4142...
>
> Too bad and confusing.
>
> 1)
> The "Risch... algorithm" and differential algebras are new to me
> and I find them beautiful & elegant.
> But.. how many people really needs to work by default fall-back
> in a differential algebra?
> (Apart developers and maybe few mathematicians working exactly on that
> subject.)
>
> I mean:
> I understand that simplification and integration are in principle
> unrelated problems, so, why FriCAS exposes as user catchall-type
> a domain modeled to be a differential algebra useful for "Risch algorithm"
> and not a familiar PrincipalBranchExpression like the other CAS?
Your claim (1) shows that principal branch creates traps that
normal users do not see. So "familiar" should be taken with
grain of salt.
>
> Thousands of potential FriCAS users (me included)
> would like to have the possibility to live
> in a more familiar context where everything is compatible
> with PrincipalBranchExpression and, more than that,
> to have aggressive & automatic simplifications
> that 100% comply with the rules of this world.
Frankly, I doubt that many users need it. Principal branch
is of some use for numerical analysts, because it is close
to what popular numerical libraries are doing. But there
is enough differences that honest numerical analyst must
do independent reasoning anyway (in particular check that
rounding error will not put him on wrong side of branch
cut).
Users are brainwashed to accept principal branches, but
in most applications we deal with continous functions.
That is, correct branch is one leading to continous
function. So, much of complexity (unsolvability!)
introduced by principal branches really is useless
and does not correspond to real world. Part of
branch cut complications is due to using wrong
model, that is pretending that we are working
on euclidean space when we should work with manifolds.
> Nobody wants to spend half an hour to find out
> what operation one has to invoke
> to force sqrt(2)*sqrt(3)=sqrt(6)
> which is quite trivial in a PrincipalBranchExpression context.
Sure.
> This is the reason of the recurrent non-bugs raised in the lists:
> semantics of Expression R is not evident to users and, worse,
> does not fully satisfy the PrincipalBranchExpression-community
> expectations.
>
> Why naot, for instance, having the analog of a
> PrincipalBranchExpression domain + its simplifications
> as user fall back top domain, with RealExpression called on option
> and DifferentialField/Expression R below and available on demand?
You should understand that domain that you propose is quite
unlike domains already present in FriCAS. Main point is
that there are almost no absolute equalities, most things
are conditional.
I have some sympathy towards such domain. But implementing
it is no small task. First, it should be correct. It should
cooperate somewhat with other domains (which is tricky
because it so different from other parts of FriCAS).
And it should be reasonably efficient (naive tree-rewriting
in many cases gives exponential blowup).
> If I understand correctly,
> having PrincipalBranchExpression domain by default
> could help eliminating dependent kernels in integration:
> Eg when invoked from PrincipalBranchExpression, an
> expression like
> integrate( 1/(1+x+(sqrt(2)*sqrt(3)-sqrt(6))*x^100000000000), x)
> might be automatically & rigorously pre-simplified with
> symplify$PrincipalBranchExpression,
> thus eliminating ((sqrt(2)*sqrt(3)-sqrt(6))*x^100000000000)
> then the expression (with no more dependent kernels)
> may be lifted to the DifferentialField domain which gets back
> an expression in terms of abstract functions log ....
> and then each abstract function maight be
> projected back to the PrincipalBranchExpression world
> because the target context is clear.
>
> The advantages of having a PrincipalBranchExpression
> domain would then be:
> i)
> make the users of other CAS be more interested to FriCAS
> because a familiar framework is offered
> = increased chance of long term survival of the project
> ii)
> separate the Risch code which is hard to understand from other code that
> can
> be improved by developers not at ease with Risch
> (hoping not to hurt other people in the list,
> I have the *impression* that only you fully understand
> risch-related domains: code simplifications should be welcome.)
> iii)
> the full independence from user expectations might allow
> for a no-compromises and cleaner Risch framework
> (Eg I've read that some branch cut choices for algebraic numbers
> are done in some -- unspecified -- situations.).
>
> 2)
> I anticipate your possible disagreemnt:
> if the PrincipalBranchExpression proposal is not suitable for your plans
> what FriCAS may offer to the PrincipalBranchExpression-people?
>
> I mean are you willing
> to facilitate the life of these (huge) group of potential users?
>
> How?
>
> 3)
> Algebraic numbers aside.
>
> How do you rigorously define sqrt n-th power as implemented in FriCAS?
>
> Currently sqrt(a) means something like
> "a generic complex x such that x^2=a".
>
> The only rigorous meaning I found for multivalued function is that
> sketched in MultivaluedExpression,
> but the natural product there is the direct product of sets
> so it is no more true that sqrt(a)*sqrt(a) = {a},
> becausethe direct product combines
> all elements on the left set with all the elements on the right set.
>
> In simple words, what bothers me is that if I define
> sqrt(a)* sqrt(b)
> := product of a generic complex x such that x^2=a
> and a generic complex y such that y^2 =b
> then specializing to a=b it is no more true that
> sqrt(a)*sqrt(a) = a,
> which is currently a structural identity of FriCAS.
Well, that is one example of users expecting too much. It is
well known that specialization can lead to troubles. It
will work if some appropriate conditions are satisfied, but
not in general.
> 4)
> Somewhere you said that you find unsatisfactory to work only with
> one branch.
>
> But if you want all branches together,
> how do you deal with the fact that in general,
> as argued in AnyBranchExpression,
> there is an infinity of such branches?
>
> Maybe you want to limit only to a subset of all possible branches
> with cuts fixed on negative axis or so...
>
> 5)
> Is it concievable/practical to solve multivalueness problems introducing
> a RiemannSurfaceExpression domain?
>
> For log-riemann surface one should model a point with polar coordinates
> (r, phi), r i R_+ and phi in R.
>
> But I do not know how meromorphic functions on different Riemann surfaces
> might interact together.
This could be useful domain. However, it looks heavy:
- complex code to implement it
- probably slow due to complexity
- users have to specify extra information
--
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.
