Riccardo GUIDA wrote:
>
> I've done some elementary tests to try to understand how FriCAS looks at
> n-rooths and log, but now I am even more confused.
>
> * (1) puzzles me: from your previous answer I have understood that
> (...)^(1/n) with n>1 was "mostly" seen by FriCAS as a multivalued and
> possibly complex algebraic number. Is (1) an exception?
In a sense.
>
> * (3) seems to suggest that for positive integer n and positive x x^(1/n) =
> e^(log(x)/n), but this is violated by (7)
>
> * (6) and (8) are consistent, but how is defined x^a with a irrational and
> positive x?
>
>
> (1) -> (1 = (1)^(1/2))::Boolean
>
> (1) true
> Type:
> Boolean
> (2) -> (1 = e^(1/2*log(1)))::Boolean
>
> (2) true
> Type:
> Boolean
> (3) -> (sqrt(1) = e^(1/2*log(1)))::Boolean
>
> (3) true
> Type:
> Boolean
> (4) -> (1 = (1)^(sqrt(3)))::Boolean
>
> (4) false
> Type:
> Boolean
> (5) -> (1 = e^(sqrt(3)*log(1)))::Boolean
>
> (5) true
> Type:
> Boolean
> (6) -> ((1)^(sqrt(3)) = e^(sqrt(3)*log(1)))::Boolean
>
> (6) false
> Type:
> Boolean
> (7) -> (sqrt(2) = e^(1/2*log(2)))::Boolean
>
> (7) false
> Type:
> Boolean
> (8) -> (2^sqrt(2) = e^(sqrt(2)*log(2)))::Boolean
>
> (8) false
> Type:
> Boolean
>
>
> I guess that the present status of the code is, as usual, "quite intricated",
> but, if not already done, would it be possible for you to take the time (on
> the medium term) to write a short note or some rule of thumbs to explain to
> new users how FriCAS behaves in view of irrational powers, log, inverse
> functions, which relations are expected to hold, and how integrate and
> complex integrate behave in view of explicitly trascendental numbers,
> integration variable and external parameters, like a or a^b or log(a)?
1) Basic concept is "kernel". "Normal" operation either creates new
kernel or reuses an existing one. Transcendental kernels behave
in algebraic operations behave as variables, algebraic kernels
are simplified using defining relation. For example, 'sqrt(3)^2'
is replaced by 3.
2) Before "normal" case functions like 'sqrt' try to perform some
"always valid" simplifications. Unfortunately, "always valid"
is fuzzy and ill-defined term and the result is more or less
ad-hoc. In particular, there are popular conventions when dealing
with real functions which are invalid as transformations
of complex functions. Original authors adapted convention that
Expression(Integer) is supposed to represent real functions
so implemented conventions from real analysis. OTOH
for Expression(Complex(Integer)) some of those transformations
are disabled.
3) To limit redundacy FriCAS tries to put some functions in
"normal form". In particular, 'sin(-x)' will give you
'-sin(x)'.
4) In Expression(Integer) arithmetic operations only use defining
relation for simplifications. If for example you somewhat
manage to create 'sqrt(1)' (in the past it was possible to create
it due to a bug) it will stay different from '1'. 'sqrt(2)' and
'(2^(1/4))^2' will stay different.
5) 'integrate' needs a differential field and can not directly handle
trigonometric functions. So it has to perform rather drastic
transformations.
> Furthermore, your view on what should be the ideal target behavior to nicely
> resolve these ambiguities and have a homogeneous interface would surely be a
> relief ...
Well, the problem is unsolvable. First, users expectations are
inconsistent. Second, vocal group says that computer algebra
should use the same conventions as numerical computation (use
principal branch). But variation of Richardson proof shows
that with such conventions problem of testing functions for
equality is uncomputable.
The best we could do is to keep context for each expression
and treat transformations as rewrite rules which are applied
when information from context proves that rule is valid.
In particular context would encapsulate user expectations
and in this way limit problems due to inconsistent
expectations. Rewrite rule point of view allows us
to do _some_ computations even if general problem is
uncomputable.
Note that in Axiom era it was claimed that types would solve
problems above. But this is not so for few reasons:
1) context can differ in subtle ways and it is hard to
to decide if given contextual information is relevant
or not. Keeping all information in types leads to
huge number of different types which causes
practical difficulties.
2) algebraic structure that we get has very bad properties,
it contains partial functions and basic operations are
not even associative. So is fits badly into existing
FriCAS type hierarchy.
3) operations are not well defined in sense that they should
be done on best-effort base. With better algorithms we
will be able to compute more and results will change.
4) Validity of operations depends on subltle and specialised
proofs. Our type machinery can handle simple proofs
but is not fit to the task.
Let me also add that in a sense solving problems due to
multivalued functions is less important than one would
first think. Namely, if kernels are indepenent, that
is no simplifications are possible except for algebraic
simplifications due to defining relations of algebraic
kernels, then current Expression(Integer) will give
correct results for algebraic operations. 'integrate'
can be changed to avoid generating depenent kernels,
so depenent kernels will never appear, except when
explicitely present in user input. There are tricks
to preserve ambiguity if user input contains dependent
kernels. In other words problem of simplification
is indepenent from integration.
I wrote above "can be changed", so what happens? To
avoid algebraic dependencies we need to know that
defining polynomials are irreducible, which means that
we need good factorization routines. It would be good
to improve efficiency of our current factorizer, but
now it works much better than in the past. We need to
call factorizer at appropriate places -- this is slow
process as it involves restructuring sizeable piece of
code. We need changes to 'normalize' and need to
call equivalent of 'normalize' during postprocessing
of the integral.
> Best regards
> Riccardo
>
> PS Speaking of oddities, to me (11) and (12) should behave in the same way:
> as elements of R->R or or as complex multivalued.
>
> (9) -> sin(0)
>
> (9) 0
> Type:
> Expression(Integer)
> (10) -> sinh(0)
>
> (10) 0
> Type:
> Expression(Integer)
> (11) -> asin(0)
>
> (11) 0
> Type:
> Expression(Integer)
> (12) -> asinh(0)
>
> (12) asinh(0)
Well, according to original rules the results should be opposite:
'sinh' is single-valued on real line, so 'asinh(0)' should be 0.
OTOH 'sin' is multivalued on real line so 'asin(0)' should
remain unevaluated. I can guess that current behaviour is
so that FriCAS produces textbook anwers when calling 'solve'
on trigonometric equalities (and original authors probably
did not think that 'asinh' needs the same attention).
--
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.
