On Thu, Jul 13, 2023 at 11:31:27PM +0200, Ralf Hemmecke wrote:
> > 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.
Yes, AFAICS this is the whole point of this domain, regardless
of factoring roots or not factoring roots the machinery will
discover dependencies.
> I think
> Magma does it in the same way.
Maybe.
> > 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.
The only surprise is with printing:
(12) -> rl1 := rootsOf(xx^2 - p1*p2)
[:> , DACFF rootOf poly, ?^2+110412165131911888]
[:> , IFFTS extendBy! f, ?^2+110412165131911888]
[:> , IFFTS lvlsz, [5316911983139663348652961669872354241, 2305843009213693921]]
[:> , IFFTS n, 2]
[:> , IFFTS n, -2]
[:> , IFFTS n, 0]
(12) [r1, - r1]
Type: List(DynamicAlgebraicNumber)
(13) -> rl2 := rootsOf(xx^2 - p1)
[:> , DACFF rootOf poly, ?^2+1457092405402532485]
(13) [r2, - r2]
Type: List(DynamicAlgebraicNumber)
(14) -> rl3 := rootsOf(xx^2 - p2)
[:> , DACFF rootOf poly, ?^2+441130959790535368]
(14) [r3, - r3]
Type: List(DynamicAlgebraicNumber)
(15) -> rl1.1 + rl2.1*rl3.1
(15) r2 r3 + r1
Type: DynamicAlgebraicNumber
(16) -> rl1.1 - rl2.1*rl3.1
(16) - r2 r3 + r1
Type: DynamicAlgebraicNumber
(17) -> 1/(rl1.1 - rl2.1*rl3.1)
1
(17) ------------------------------------------- r1
2000000000000000000781800000000000000000702
Type: DynamicAlgebraicNumber
(18) -> 1/(rl1.1 + rl2.1*rl3.1)
>> Error detected within library code:
cannot invert zero element
Instead of factoring you could run zero test before printing, to
print zero as zero.
And of course factoring small numbers and not factoring bigger
ones is somewhat a surprize.
> 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.
True.
> > > 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.
Why? AFAICS appending triangular sets gives you valid triangular
set. And if you use the same prime for both sets, then compatibility
conditions should hold. My understanding is that appending is
equivalent to re-running comands used to generate second set
in session which created first set, but making sure to never
reference the first set (so access via root number must use
usjusted index). Only "mixed" arithmetic or zero test is
supposed to cause interation between polynomials in the two
subsets. Of course, your factoring code breaks the rules, but
as long as it is limited to integer roots this should be
easy to handle.
Concerning using different primes, there is consistency problem
here, different prime could renumber roots so it looks tricky
to ensure that inequality tests decided by finite field give
the same results.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/ZLCAxGXnbpOQ7D5/%40fricas.math.uni.wroc.pl.
