Opened 5 years ago

Closed 5 years ago

## #24219 closed defect (wontfix)

# critical bug in comparison between RealField and QQ

Reported by: | Paul Zimmermann | Owned by: | |
---|---|---|---|

Priority: | critical | Milestone: | sage-duplicate/invalid/wontfix |

Component: | coercion | Keywords: | |

Cc: | Jeroen Demeyer | Merged in: | |

Authors: | Reviewers: | ||

Report Upstream: | N/A | Work issues: | |

Branch: | Commit: | ||

Dependencies: | Stopgaps: |

### Description (last modified by )

sage: RealField(2)(1) >= 5/4 True

This is clearly wrong.

The reason is that `5/4`

is first converted to a 2-bit
floating-point number, which is `1`

in mode to nearest, then the comparison is made.

### Change History (13)

### comment:2 Changed 5 years ago by

I did not ask `t >= RealField(2)(5/4)`

, but `t >= 5/4`

.
Does the following convince you? Note that 6*t is exactly representable in 2-bit precision.

sage: t = RealField(2)(1) sage: t >= 7/6 True sage: 6*t >= 7 False

### comment:3 Changed 5 years ago by

Well, comparison happens after coercion, and coercion can only lose precision. If you want comparison that makes sense, you should avoid using such a small precision.

### comment:4 Changed 5 years ago by

where is it documented that comparison happens after coercion? Is the user warned about that? And why is the coercion done in the direction QQ to RealField? and not the converse, which would not lose any information?

### comment:5 Changed 5 years ago by

Coercion is supposed to be exact (mathematically), so it can not guess anything from an approximate real number. Going from R to QQ is a conversion.

sage: R = RealField(2) sage: R.coerce_map_from(QQ) Generic map: From: Rational Field To: Real Field with 2 bits of precision sage: QQ.coerce_map_from(R)

### comment:6 Changed 5 years ago by

### comment:8 Changed 5 years ago by

Component: | basic arithmetic → coercion |
---|---|

Description: | modified (diff) |

The behaviour that you see is by design, so by definition it's a feature and not a bug.

Note also that what you see is consistent with subtraction, which is a good thing:

sage: RealField(2)(1) - 5/4 0.00

I don't see a simple fix here... it would require substantial changes to the coercion model.

### comment:9 follow-up: 10 Changed 5 years ago by

I don't see a simple fix here...

why no simply forbid comparison involving floating-point numbers, if it can result in mathematically wrong results? Then the user would have to do:

sage: RealField(2)(7).exact_rational() == 10 False

### comment:10 Changed 5 years ago by

Replying to zimmerma:

I don't see a simple fix here...

why no simply forbid comparison involving floating-point numbers

I don't think that's realistic. I'm pretty sure that a lot of stuff in Sage would break if we did that.

### comment:11 follow-up: 12 Changed 5 years ago by

I don't quite see it as a mathematically wrong result as it is correct up to the estimate bounds. If we did that, then I feel this would have to return `False`

by the same argument:

sage: bool(pi.n() == pi) True

since `pi.n()`

is an inexact floating point number. Also, we have this doctest in `exact_rational`

:

sage: RR(3^60).exact_rational() - 3^60 6125652559

### comment:12 Changed 5 years ago by

Replying to tscrim:

I don't quite see it as a mathematically wrong result as it is correct up to the estimate bounds. If we did that, then I feel this would have to return

`False`

by the same argument:sage: bool(pi.n() == pi) Truesince

`pi.n()`

is an inexact floating point number.

it would indeed be correct to return False, since `pi.n()`

is a well-defined rational number, namely `884279719003555/2^48`

, and it is well known that `pi`

is not rational, thus we cannot get equality.

Anyway, since I'm alone to consider this as a bug, I will simply use `exact_rational`

whenever I want correct comparisons with floating-point numbers.

### comment:13 Changed 5 years ago by

Milestone: | sage-8.1 → sage-duplicate/invalid/wontfix |
---|---|

Resolution: | → wontfix |

Status: | new → closed |

**Note:**See TracTickets for help on using tickets.

So this is not really a bug