Tried it a bit. First, CyklotomicPolynomialPackage is now removed,
need to replace it by CyklotomicUtilities. Second, it seems that you
are factoring numbers under roots:
(32) ax := xx^2 - 6
2 (32) ? - 6 Type:
SparseUnivariatePolynomial(DynamicAlgebraicNumber) (33) -> r :=
rootsOf(ax) [:> , DACFF rootOf poly, ?^2+2305843009213693919]
(33) [r1 r7, - r1 r7] Type: List(DynamicAlgebraicNumber)
So, code is smart enough to notice that square root of 3 already
appeared, but expressions are more complicated then they would be
otherwise (without reusing previous root this doubles degree of
exention).
I know. However, my main concern was that I wanted to recognise that
sqrt(2)*sqrt(3)-sqrt(6) or sqrt(2)*sqrt(3)+sqrt(6) is 0 (case depending
on internal choice) If the user enters sqrt(6) before sqrt(3) then the
machinery would have to recognise this and change accordingly. I think
Magma does it in the same way.
And when there are four factors we get:
(36) -> ax := xx^2 - 11*13*19*43
...
so there are three extra roots.
Yes, I realized that, too. But as I said, main concern is to be able to
reliably figure out algebraic dependencies. Note that in FriCAS
(5) -> zero?(sqrt(2)*sqrt(3)-sqrt(6))
(5) false
(6) -> zero?(sqrt(2)*sqrt(3)+sqrt(6))
(6) false
That would allow me to divide by this expression. I want an algebraic
closure and no surprises.
(5) -> ax := xx^3 - 1/2305843009213693921
3 1 (5) ? - ------------------- 2305843009213693921
Type: SparseUnivariatePolynomial(DynamicAlgebraicNumber) (6) -> r :=
rootsOf(ax)
Error detected within library code:
IFFTS: inv: cannot invert zero element
Oh, I stopped at some point with this implementation. The fixed prime
should certainly change if it becomes "unlucky". But I have no good
solution for this "changing machinery" yet.
Either way, it seems problematic to store elements of such domains in
files.
Sure. One would also have to store the triangular set with each element.
I actually never thought of storing theys numbers on disk.
And even if we ignore problems above mutable domains cause various
troubles.
Exactly. But what could be a suitable solution for an algebraic closure
with proper zero recognition? I am not at all in much favour of a domain
that has an internal state. Although, if it were computationally not so
costly, it would not be a big problem for
DynamicAlgebraicClosureFiniteField to be different internally in
different sessions.
Borderline case is Kernel: kernels depend on kernel cache
which is separate from Kernel.
Yes, but kernels in cache can have algebraic dependencies and this is
not covered by current code.
Actually, there could be a third option. Elements carry a pointer
to the underlying triangular set of the extension, but then it's
probably not so easy to add elements that have different triangular
sets attached.
As long as you do not need to simplify just append both (or maybe
intelive). Whith some smarts unused variables (generators) should
have little cost.
I don't exactly understand what you mean, but it sounds like current
AlgebraicNumber where dependencies are not detected.
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/699116de-e83b-0498-a69b-45862b586d0c%40hemmecke.org.
