On 7/4/24 21:30, Waldek Hebisch wrote:
> So, basically you want 'normalize' to work with algebraic
> expression.
Yes, that would be nice, but more urgent for me is to have that just for
algebraic numbers, i.e. no variables involved. So there might be even
some properties that can be used. For example, I've realized that
sometimes there appears a sqrt(-1) factor while applying rootFactor.
(The following is with the current trunk code.)
%%% (3) -> rootFactor((sqrt(sqrt(2)-3*sqrt(3))))
+-------------+
+---+ | +-+ +-+
(3) \|- 1 \|3 \|3 - \|2
%%% (4) -> rootFactor((sqrt(5*sqrt(2)-sqrt(3))))
+-------------+
+---+ | +-+ +-+
(4) \|- 1 \|\|3 - 5 \|2
That looks OK for the first case, but definitely not for the second.
Also
%%% (57) -> a := sqrt((3*sqrt(2)-sqrt(3)::E)*(7*sqrt(5)-sqrt(7)::E))
+----------------------------------------------+
| +-+ +-+ +-+ +-+ +-+ +-+
(57) \|(\|3 - 3 \|2 )\|7 + (- 7 \|3 + 21 \|2 )\|5
%%% (58) -> [a::Complex(Float), rootFactor(a)::Complex(Float)]
(58) [5.7144160659_439266652, - 5.7144160659_439266652]
does not seem to be desirable even though it matches the current
specification of rootFactor.
At least for AlgebraicNumber, I would like to see an implementation that
does not change the value of the algebraic number if the value under the
root is positive. Yes, that is a bit more work, but if rootFactor
changes the sign somewhere in a nested root expression (that is in fact
positive at all places) that can change the floating point value of that
number in a pretty unpredictable way and thus becomes useless.
I somehow think of checking positiveness of the expression and their
factors with
algnum::Complex(DoubleFloat)::Float.
Similarly, one could have a rootCombine that doesn't chang the value.
I guess all that should live in AlgebraicNumber directly and fall under
the name "normalize" (or is even silently applied)/
ad ((your suggested code))
> What is the difference? Main is that eval is done _before_
> splitting, that allows cancellation between numerator and
> denominator.
OK, that makes sense.
> And little differences like using 'cons' to _prepend_ to a list.
> Compared to concat this avoids quadratic behaviour.
I actually knew about that quadratic issue and wanted to do it with
cons, but wasn't completely sure whether eval wants its arguments in a
specific sorting order.
> I added rootFactor, there were various improvements, especially by
> Qian. But the approach looks limited, I do not see how to extend it
> to do things which and be done using different approach. And to that
> matter, unstated assumption is that user can do desired
> transformation by sequence of simpler transformations. Currently I
> think that _single_ say 'transform' function with many options would
> be better. The point is that multiple options are simpler both for
> user and implementation than multiple functions. And interactions
> of options can produce results that would be hard to do as sequence
> of transformations.
I stayed away from expression transformation since long. I feel, it's a
hard problem and I began to love AXIOM, because it worked with canonical
representations in most places.
Introducing a 'transform' function with options is probably a good idea.
Honestly, I would have liked that such a function already existed in
FriCAS. Programming it myself, is currently not my main interest. I go
for simple improvements that help me with what I currently need.
Ralf
--
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/b75fc4e0-3073-46f2-ac07-d9efdf178fb1%40hemmecke.org.
