Waldek:
Unfortunately no. You have equalty when additionaly real parts of
z1 and z2 are nonnegative. But in whole D things are "interesting".
<snip>
Your claim (1) shows that principal branch creates traps that
normal users do not see. So "familiar" should be taken with
grain of salt.
Upss ... that *was* familiar some time ago... SHAME ON ME!!
DLMF [10] says that it should be correct to replace
"if z1*z2 in D" in (1)
by
"if pi< arg(z1)+arg(z2) <= pi"
Well, whatever, the point was to use (correct) identities by default
in PrincipalBranchExpression.
Waldek:
Actually, you have the some trouble with (2) as with (1).
More nonsense of mine?
I thought that (2) was OK in polar coordinates z~(r,phi)
for the "log -manifold" and with
log z(r,phi) := log r + i phi
z1*z2 := ( z1.r * z2.r, z1.phi + z2.phi )
... but maybe you mean if we work on complex patches homemorphic to C-cut.
Waldek:
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.
sounds elegant, but is that doable in a CAS?
Waldek:
Well, how you define 'x^a'? I am aware of only one FriCAS domain
which defines 'x^a' for irrational 'a' differently than via 'exp'.
The exception is SmallOrdinal and you could argue that ordinals
are in some sense "rational".
OK, so for irrational 'a' FriCAS defines
x^a := e^{a log(x)}
but does this definition hold (in FriCAS) also for rational 'a' and in
particular 'a = 1/n'?
I mean, I'm confused by my tests below
(1) -> (2^sqrt(3) = e^(sqrt(3)*log(2)))::Boolean
(1) false
Type: Boolean
(2) -> (2^(1/3) = e^(1/3*log(2)))::Boolean
(2) false
Type: Boolean
(3) -> (2^(5/3) = e^(5/3*log(2)))::Boolean
(3) false
Type: Boolean
(4) -> (1^sqrt(3) = e^(sqrt(3)*log(1)))::Boolean
(4) false
Type: Boolean
(5) -> (1^(5/3) = e^(5/3*log(1)))::Boolean
(5) true
Type: Boolean
(6) -> (1^(1/3) = e^(1/3*log(1)))::Boolean
(6) true
Type: Boolean
--- below dependent kernels on purpose,
--- why they are not simplified unsing definition of '^'?
----
(7) -> integrate(2^sqrt(3)-e^(sqrt(3)*log(2)),x)
┌─┐ ┌─┐
log(2)\│3 log(e) log(2)\│3
(7) - x %e + x %e
Type: Union(Expression(Integer),...)
(8) -> integrate(2^(5/3)-e^((5/3)*log(2)),x)
5 log(2)log(e)
──────────────
3 3┌─┐2
(8) - x %e + 2 x \│2
Type: Union(Expression(Integer),...)
(9) -> integrate(2^(1/3)-e^((1/3)*log(2)),x)
log(2)log(e)
────────────
3 3┌─┐
(9) - x %e + x\│2
Type: Union(Expression(Integer),...)
Waldek:
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.
Well, you over-evaluate my understanding of FriCAS global design:
I understand that one would simplify only if some conditions are met,
and that many equalities would be undecidable =
larger expressions with hidden identities
but I do not quite see why one could not recycle most of code from the current
Expression Integer, and why a "full tree representation of expressions"
would be mandatory instead of the usual rational function of kernels
representation.
Waldek:
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).
"M* on FriCAS" ... the best of the two worlds in a single (open source) CAS...
appealing indeed.
Thanks for your time
riccardo
[10] https://dlmf.nist.gov/4.8.E2
--
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.
