Hi,
Thanks for your reply.
> > What is the correct way to factor polynomials in spad code?
> >
>
> ATM this is a mess. Normally you need to determine correct
> factorizer.
Hmm, yes. I hoped that giving some generic details about
the base ring would be enough. Then Fricas would figure
which domain/package exactly is needed.
> If you want something automatic, then
> you may try GeneralizedMultivariateFactorize, but it works
> on best effort basis: it may fail to produce factorization
> if it can not find good factorizer. If base ring is
> Integer, then MultivariateFactorize contains apropriate
> 'factor'.
Ok. So I was on the right track more or less. But it
was a long way with very little documentation.
Still difficult to use this domain.
I got a small test case working.
Not sure it is correct at all.
----------------------------------------------------------
)abbrev package FACIT FactorIt
++ Toy Model
FactorIt(R) : Exports == Implementation where
R : Join(EuclideanDomain, CharacteristicZero)
P ==> Polynomial(R)
-- Hmm ... This is not correct, is it?
-- I'd expect SparseUnivariatePolynomial(R) with R the coefficient ring
UP ==> SparseUnivariatePolynomial(P)
S ==> Symbol
MVF ==> MultivariateFactorize(S, IndexedExponents S, R, P)
Exports ==> with
factorIt : UP -> List(UP)
++ Toy implementation doing like "factorList"
Implementation ==> add
factorIt(p:UP) : List(UP) ==
fp := factor(p)$MVF
[fac.factor for fac in factors fp]
----------------------------------------------------------
> > Assume I have some ring R (maybe Z):
> >
> > R : UniqueFactorizationDomain
> >
>
> That is not enough: there fields F such that factorization
> in SparseUnivariatePolynomial(F) is not computable.
Oh, ok. Didn't know that.
> So we need more properties from R to be able to factor
> polynomials. This is at core of current mess. There
> was proposal to introduce additional property which
> allows propagating polynomial factorization trough
> type hierarchy (google for PolynomialFactorizationExplicit).
No need to google it anymore. I got many compilation errors
due to this thing, not understanding why and how to fix them.
Reading the docstring in the category definition explains
at least the idea.
> However, as I explaned in recent posts there is problem
> with implementing it (both speed and correctness are
> problematic).
Your mail from June, 30th, right. I think that this
code should be fixed and properly be part of Fricas.
Maybe one can include it in such a way that it is
only slow when necessary and not affecting "general case"?
(Anyway better slow and complete than wrong.)
BTW: In case you are curious what I wanted to build:
https://github.com/raoulb/fricas_code/blob/master/dis/dispersion.spad
https://github.com/raoulb/fricas_code/blob/master/dis/dispersion_test.input
It is a small package for computing dispersion of polynomials.
(Aldor has that feature, but takes a different approach I think.)
BTW2: @Ralf: I very much appreciate your documentation effort.
These pages were of great help finding and browsing domain information.
--
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 http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
