factorization patches
John Cremona
a few functions for the Factorization class (division, gcd and lcm).
These are orthogonal to the problems discussed at #2460, but I may
have a go at resolving those issues as well.
There are some more silly things I discovered: (1) you can multiply
two factorizations even if they are from totally different rings. (2)
you can add and subtract factorizations, but the result is not
factored so this seems rather redundant. (e.g. factor(-6)+factor(81)
returns 75).
John
John Cremona
Looking at factorization.py I was all ready to fix all the problems I
could see -- using Sequence to get a common universe for the bases on
construction, cache this base_ring, only allow operations between
factorizations with the same base_ring, and so on.
But then I saw what appeared to be a totally weird example:
sage: F = Factorization([(ZZ^3, 2), (ZZ^2, 5)], cr=True); F
(Ambient free module of rank 2 over the principal ideal
domain Integer Ring)^5 *
(Ambient free module of rank 3 over the principal ideal
domain Integer Ring)^2
This bears no relation at all to what I thought the Factorization
class was for. Doing a search_src showed that this is designed in to
support splitting of modular symbols spaces (and similar).
This leaves a question almost certainly for William: is it really
sensible to have one class serve both as the structure to hold "prime
factorizations" for UFDs and other rings, as well as to hold lists of
subspaces with multiplicities?
If so, perhaps we need to refactor this to have a base class which
just handles the basics, with (at least) 2 derived classes, one for
rings factorizations and one for additive decompositions?
John
# I have added this posting to trac#2460 too.
2008/8/22 John Cremona <john.c...@gmail.com>:
William Stein
>
> Forgive the self-reply.
>
> Looking at factorization.py I was all ready to fix all the problems I
> could see -- using Sequence to get a common universe for the bases on
> construction, cache this base_ring, only allow operations between
> factorizations with the same base_ring, and so on.
>
> But then I saw what appeared to be a totally weird example:
>
> sage: F = Factorization([(ZZ^3, 2), (ZZ^2, 5)], cr=True); F
> (Ambient free module of rank 2 over the principal ideal
> domain Integer Ring)^5 *
> (Ambient free module of rank 3 over the principal ideal
> domain Integer Ring)^2
>
> This bears no relation at all to what I thought the Factorization
> class was for. Doing a search_src showed that this is designed in to
> support splitting of modular symbols spaces (and similar).
>
> This leaves a question almost certainly for William: is it really
> sensible to have one class serve both as the structure to hold "prime
> factorizations" for UFDs and other rings, as well as to hold lists of
> subspaces with multiplicities?
I use one word for both: "factorization" :-)
> If so, perhaps we need to refactor this to have a base class which
> just handles the basics, with (at least) 2 derived classes, one for
> rings factorizations and one for additive decompositions?
Sure, go for it. As long as I don't have to do the work, it sounds
good to me.
-- William
John Cremona
>> This leaves a question almost certainly for William: is it really
>> sensible to have one class serve both as the structure to hold "prime
>> factorizations" for UFDs and other rings, as well as to hold lists of
>> subspaces with multiplicities?
>
> I use one word for both: "factorization" :-)
The issue to me is that while a Factorization as currently implemented
can hold such a thing, some of the Factorization methods don't make
sense and/or don't work. For example if you set
F = ModularSymbols(11,4).factorization()
(and why not), then F.value() crashes.
That's why I thought it would be sensible to separate out a structure
for holding an abstract list of objects with multiplicities (e.g. the
above F) and a richer one for things like factor(x^20-1) or
factor(1000).
For the moment I am taking a compromise approach so that the
"optional" methods just return None if they cause an exception.
John