disallow non exact fields for the 'field' backend

[vdelecroix]

The 'field' backend does not properly support non exact fields

sage: omega = 2*RR.pi() / 5
sage: verts = [((i*omega).sin(), (i*omega).cos()) for i in range(5)]
sage: verts
sage: Polyhedron(vertices=verts, base_ring=RR)
Traceback (most recent call last):
...
AssertionError: 

or

sage: Q = polytopes.icosahedron()
sage: Q = polytopes.icosahedron(); Q
A 3-dimensional polyhedron in (Number Field in sqrt5 with defining polynomial x^2 - 5)^3 defined as the convex hull of 12 vertices
sage: Q_RR = Polyhedron(vertices = [n(v.vector(),digits=10) for v in Q.vertices()])
sage: Q_RR
A 3-dimensional polyhedron in (Real Field with 37 bits of precision)^3 defined as the convex hull of 7 vertices
sage: Q_RR = Polyhedron(vertices = [n(v.vector(),digits=30) for v in Q.vertices()])
sage: Q_RR
A 3-dimensional polyhedron in (Real Field with 103 bits of precision)^3 defined as the convex hull of 1 vertex and 3 rays

We simply raise an error if somebody want to try this.

[mkoeppe]

Another bug for RDF polyhedra: #21270

[vdelecroix]

New commits:

​c28fcf0

18220: raise an error for non exact fields

[jipilab]

The tests pass on my machine with 7.6.beta6. The documentation looks fine as well. No idea what the quasar bot is up to.

The I believe it is a good idea to raise an error for such a behaviour.

Matthias, any thoughts? Does that look good for you?

[mkoeppe]

I agree with disabling it for floating point, but I'm not sure about disabling it for the SR as well. Maybe there are some people who want to work with polytopes with transcendental coordinates?

[vdelecroix]

I would like to make computations with trascendental coordinates. However, the symbolic ring is not the proper way to do it. I am very much against special casing SR anywhere. SR has its own logic that does not fit at all with the Sage logic of parents and coercion. Moreover, comparison is completely broken

sage: bool(pi == 245850922/78256779)
True

[jipilab]

Then, let's restrict the usage of the symbolic ring with polyhedron.

If it ever happens that there is a use case of the symbolic ring, we may consider adapting it properly then.

[novoselt]

WAIT!!! Are you proposing to drop support for RR/RDF and other floating points?! With all the bugs it is still useful to be able to operate with them, if you think it is too dangerous, how about throwing a warning?

[vdelecroix]

As mentioned in the title description, it only concerns the "field" backend that is very much broken for non exact fields. Other backends still support RDF as it used to be.

[novoselt]

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

[jipilab]

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

No worries!

It is true that the name 'field' is confusing...

[vdelecroix]

Replying to jipilab:

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

No worries!

It is true that the name 'field' is confusing...

What about changing it to 'generic'?

[vdelecroix]

Replying to vdelecroix:

Replying to jipilab:

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

No worries!

It is true that the name 'field' is confusing...

What about changing it to 'generic'?

or 'generic_exact', or 'sage_toy', or ...

[jipilab]

Replying to vdelecroix:

Replying to vdelecroix:

Replying to jipilab:

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

No worries!

It is true that the name 'field' is confusing...

What about changing it to 'generic'?

or 'generic_exact', or 'sage_toy', or ...

In this setup I would not call the backend generic, because it does not provide the principal reason to use it: irrational exact values.

What about irrational_exact ?

[vdelecroix]

Replying to jipilab:

Replying to vdelecroix:

Replying to vdelecroix:

Replying to jipilab:

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

No worries!

It is true that the name 'field' is confusing...

What about changing it to 'generic'?

or 'generic_exact', or 'sage_toy', or ...

In this setup I would not call the backend generic, because it does not provide the principal reason to use it: irrational exact values.

What about irrational_exact ?

It is even more confusing since this backend can deal with rationals... generic_exact?

[jipilab]

Replying to vdelecroix:

Replying to jipilab:

Replying to vdelecroix:

Replying to vdelecroix:

Replying to jipilab:

OK, sorry for the false alarm (it was an end of a tough day yesterday ;-)). I guess I got confused by the strange name for a backend as well...

No worries!

It is true that the name 'field' is confusing...

What about changing it to 'generic'?

or 'generic_exact', or 'sage_toy', or ...

In this setup I would not call the backend generic, because it does not provide the principal reason to use it: irrational exact values.

What about irrational_exact ?

It is even more confusing since this backend can deal with rationals... generic_exact?

Right... hmm.

+1 for generic_exact.

;-)

[jipilab]

I just saw that in the documentation of version 7.6.rc0, the doc file of the backend field is called "the python backend".

Maybe we should create a ticket about renaming the backend.