Implement printing guidelines for multivariate ideals

[joschmitt]

Implement the printing guidelines for MPolyIdeal and InvRing.
For the ideals, I followed the example in #2166, with the exception that so far all generators are printed in detailed mode. I can adjust this, but I wasn't sure what the outcome of this general discussion was (the analogous question was discussed e.g. in #2878).

Note: the printing of MPolyLocalizedIdeal should be adjusted consistently (once there is an agreement for MPolyIdeal).

[fingolfin]

Overall I agree with the direction, but I wonder if we can't do something to help those cases were IMHO the new printed output is strictly worse than the old. Of course that's just about my subjective opinion -- I am not strictly opposed, and if others feel this is the way to go, I am happy enough (also, we can always improve again later).

That said it'd be great if others could chime in, to see if we can get a (partial) consensus

[fingolfin]

In places like this, we loose information while now printing redundant information. Don't get me wrong, at the same time there are good reasons for the change in this PR (overall I like it!).

But I wonder if that means we perhaps need another printing mode, or just some special cases where we don't just recurse but do something specific when recording?

Like here, perhaps the complement function should print a list of generators of the ideal? If the printing here was any of these, I think it would be better (but perhaps not in general?)

Complement of
  prime ideal
    of multivariate polynomial ring in 3 variables over QQ
  generated by
    x

or

Complement of
  prime ideal generated by
    x
in multivariate polynomial ring in 3 variables over QQ

Of course in this specific case some people might also like

Complement of
  prime ideal P
in R

or

Complement of
  prime ideal generated by [ x ]
  in QQ[x, y, z]

but both also have downsides, IMHO...

Perhaps @simonbrandhorst or @fieker or @thofma or others have something to say...

[fingolfin]

Another situation where the old printing seems strictly more useful than the new printing :-/.

Of course that might change if there are 50 ideal generators, each spanning three lines...

BTW, there seems to be a Lowercase() missing in the show method for Affine algebraic set

[joschmitt]

I agree that for a few, small generators the old printing is better. In the end this gets us back at the discussion, whether objects should print all their generators or not or just some.
Here, I followed the example in #2166 by @simonbrandhorst , but we could of course also print something like

Ideal generated by x1, x2, ..., xn in multivariate polynomial ring

in one-line mode. If one generator is just huge this will of course explode again.

[fingolfin]

Oh, and I'd like to be very clear: I am very grateful for @joschmitt to have made this PR! I don't have a better idea than what is in here :-)

[joschmitt]

I changed the one-line mode now, so that the generators are printed if they need not more than 20 characters. See this example from the doc tests:

(Ideal with 5 generators in multivariate polynomial ring, Ideal (17, d, c, b, a) in multivariate polynomial ring)

We can change the 20 to something else and we can also change the (x, y, z) to something else. (Angular brackets are probably forbidden in non-unicode land?)

[codecov]

Codecov Report

Merging #3250 (e7b1500) into master (cc01f7b) will decrease coverage by 0.02%.
Report is 2 commits behind head on master.
The diff coverage is 66.66%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3250      +/-   ##
==========================================
- Coverage   81.63%   81.62%   -0.02%     
==========================================
  Files         546      546              
  Lines       73162    73204      +42     
==========================================
+ Hits        59729    59754      +25     
- Misses      13433    13450      +17     

Files	Coverage Δ
...ntal/FTheoryTools/src/FamilyOfSpaces/attributes.jl	100.00% <ø> (ø)
...rimental/FTheoryTools/src/TateModels/attributes.jl	93.84% <ø> (ø)
.../MatroidRealizationSpaces/src/realization_space.jl	85.42% <ø> (ø)
experimental/Schemes/BlowupMorphism.jl	90.55% <ø> (ø)
experimental/Schemes/CartierDivisor.jl	65.75% <ø> (ø)
experimental/Schemes/IdealSheaves.jl	88.73% <ø> (ø)
experimental/Schemes/SpaceGerms.jl	68.43% <ø> (ø)
experimental/Schemes/ToricBlowups/constructors.jl	88.23% <ø> (ø)
...rimental/Schemes/ToricIdealSheaves/constructors.jl	44.94% <ø> (ø)
experimental/Schemes/duValSing.jl	100.00% <ø> (ø)
... and 59 more

... and 1 file with indirect coverage changes

[simonbrandhorst]

My impression is also that it looks worse than before. The one line print mode is useless if we just print the number of generators.
ideal(x,y, z) seems like the perfect way to print it in one line mode. No need to print the parent.
Edit: In some ways ideals are more like elements and there we do not hide information / and do not print the parent as well.

[joschmitt]

I'm not sure I understand. Do you just propose

1. to not print the parent (in one-line mode or maybe at all) or
2. to always print all generators in one-line mode?

(Or both.)
Point 2 would contradict my understanding of "one-line mode".
Don't get me wrong: I'm all in favour of printing all generators in detailed mode because in my opinion the detailed mode should show enough information to define the object (and I voiced this opinion before regarding the question whether groups should print all their generators). But the one-line mode is for example used in a quotient ring (I think?) where I wouldn't want the screen to "explode" because the modulus has a thousand generators. (And if I want to see them, I can do modulus(R) to see the detailed mode.)

Here is a new proposal:

Detailed mode:

Ideal generated by
  first generator
  second generator
  and so on

One-line mode:

Ideal (comma separated list of generators)

... assuming this fits a fixed number of characters (80 or 100 or 120 or whatever a "line"is) and

Ideal with n generators

... if the list of generators would be too long.

Supercompact:

Ideal

And just to say: I feel like the examples we see in the documentation might be misleading since they almost always show ideals with very few and small generators.

[simonbrandhorst]

Thanks at lot for the new proposal. I think it is close to optimal!
Something to think about: Do we want a) Ideal(...) or b) Ideal (...) ?
I would prefer version a) since it is reminiscent of a function f(x) not f (x) .

[joschmitt]

My thought was that Ideal (x, y, z) should be read as "the ideal $\langle x, y, z\rangle$" (maybe we could/should even print angular brackets if the user allows unicode). I considered printing Ideal generated by x, y, z but this seems unnecessarily long and considering Murphy's law, there will probably be a situation where something prints as ... Ideal generated by x, y, z and f ... where the brackets would be important.
I must say that I always found it very weird that MPolyIdeal is the only type that "prints like you would type it". I don't think this principle is followed anywhere else in OSCAR. Sure, polynomials print as polynomials, but one(R) prints as 1 for almost any ring R and if you type 1 you don't even get an OSCAR RingElem.
So, basically, this question of space or no space seems to me to be a question about whether we print mathematical information or computer/programming information. I have never heard anybody talk about ideals as "a mapping from the polynomial ring to the set of ideals", so I wouldn't print it like that.

[fingolfin]

I agree with @joschmitt . How about just using plain ASCII < and >, so e.g. Ideal <x, y, z>?

[simonbrandhorst]

Plain asci <x, y, z> just looks horrible. But in unicode we can use the $\langle \rangle$ if available.

[simonbrandhorst]

Oh and i would agree that ideal generated by (...) is too much and should be avoided.
Note that in commutative algebra it is not uncommon to denote the ideal generated by x,y by (x, y) ... thus lets please stick to round braces. Maybe even in unicode for consistency?

[joschmitt]

I implemented now what I believe is the consensus. I also adjusted the printing of MPolyLocalizedIdeal accordingly.

[simonbrandhorst]

Is long output in one line mode now truncated .. at how many characters? I could not find an example in the diff.

[joschmitt]

@simonbrandhorst here is an example where the generator(s) are not printed in one-line mode. I put the limit at 100 characters.

[simonbrandhorst]

This is certainly an improvement. Thank you @joschmitt