bug in "intersect"

[David Eisenbud]

intersect ({}}
the intersection of the empty list of ideals, returns an error; it
should
return the unit ideal.

In version 1.2 this caused surprising errors in the radical command,
but that seem to have been fixed.

Examples:

S=ZZ/101[x]
intersect decompose ideal(1_S)
intersect{}

David
--
David Eisenbud
Professor of Mathematics,
University of California, Berkeley
www.msri.org/~de

[Daniel R. Grayson]

On Nov 13, 2009, at 5:47 PM, David Eisenbud wrote:

> intersect ({}}
> the intersection of the empty list of ideals, returns an error; it
> should
> return the unit ideal.

It's hard to say whether {} represents an empty list of ideals. ( In
which ring? ) Or whether it's an empty list of sets. Or an empty
list of integers. (So it is not a bug.)

What we need is a cogent design for an enhanced system of types, where
it makes sense to say that we have an empty list of ideals of S. To
get the code below to work, one would then arrange for 'decompose' to
always return not just a list, but a list of ideals of S.

[David Eisenbud]

You are right, Dan, as usual...

David
--
David Eisenbud
Professor of Mathematics,
University of California, Berkeley
www.msri.org/~de

[Bjarke Hammersholt Roune]

In the mean time, I suggest having an overload that takes a list and a
ring. If the list is empty, then the ring is used to still generate an
answer. This avoids having to have a special case for empty lists all
over. This is also an issue for e.g. the monomialIdeal function when
given an empty list of generators.

[Dan Grayson]

One might prefer something that conveys the idea that an *ideal* is to
be produced, more than the code

intersect(R,{})

would. And this wouldn't address the original problem, which
concerned applying "intersect" immediately to the output returned by
"decompose".


On Nov 14, 5:40 am, Bjarke Hammersholt Roune <bjarke.ro...@gmail.com>
wrote:

[Daniel R. Grayson]

Here's a simple attempt at a framework for fixing the original problem
by enhancing the system of types in Macaulay2:

Macaulay2, version 1.3.1
with packages: ConwayPolynomials, Elimination, IntegralClosure,
LLLBases, PrimaryDecomposition, ReesAlgebra, SchurRings, TangentCone

i1 : input "/tmp/foo.m2"

ii2 : TypedList = new Type of List;

ii3 : intersect TypedList := x -> (
if #x === 0 and null =!= lookup(class,class x)
then ideal lookup(ring,lookup(class,class x))
else intersect toSequence x);

ii4 : TypedListType = new Type of Type

oo4 = TypedListType

oo4 : Type

ii5 : net TypedListType := X -> "List of " | net lookup(class,X);

ii6 : RingedIdealType = new Type of Type

oo6 = RingedIdealType

oo6 : Type

ii7 : net RingedIdealType := X -> "Ideal of " | net lookup(ring,X);

ii8 : listOfIdealOf = (cacheValue listOfIdealOf) (
R -> new TypedListType of TypedList from hashTable {
class => new RingedIdealType of Ideal from hashTable { ring =>
R }
}
);

ii9 : oldmethod := lookup(decompose, Ideal);

ii10 : decompose Ideal := I -> new listOfIdealOf ring I from
oldmethod I;

ii11 : R = QQ[x,y,z];

ii12 : decompose ideal (x*y)

oo12 = {ideal(y), ideal(x)}

oo12 : List of Ideal of R

ii13 : intersect oo

oo13 = ideal(x*y)

oo13 : Ideal of R

ii14 : decompose ideal 1_R

oo14 = {}

oo14 : List of Ideal of R

ii15 : intersect oo

oo15 = ideal ()

oo15 : Ideal of R

ii16 :

[Bjarke Hammersholt Roune]

>  And this wouldn't address the original problem, which
> concerned applying "intersect" immediately to the output returned by
> "decompose".
>

That is true. However, it would make it work if you change

intersect decompose ideal(1_S)

to

intersect(decompose ideal(1_S), S)

I agree that a good type system is the right solution, so if you plan
to release something like that in short order, then there is no point
to something like this. If a type system is years off, then I think it
does make sense. In any case I think it would be good if the error
message explained enough that you don't see threads like this.

Cheers
Bjarke