Repository navigation
feat: add arb.equal and acb.equal - #444
deftasparagusanaconda wants to merge 1 commit into
Conversation
implement arb_equal and acb_equal which compare ball representations distinct from arb_eq and acb_eq which compare mathematical equality references: https://flintlib.org/doc/arb/predicates.html#arb_equal https://flintlib.org/doc/acb/acb_equal.html see also: https://flintlib.org/doc/arb/predicates.html#arb_eq https://flintlib.org/doc/acb/acb_eq.html#acb_eq
|
|
||
| def equal(self, other): | ||
| other = any_as_arb(other) | ||
| return bool(arb_equal(self.val, (<arb>other).val)) |
There was a problem hiding this comment.
Is there a possibility that the conversion to arb is not exact?
I think maybe this should only compare exact arbs aginst other numeric types exactly.
There was a problem hiding this comment.
arb_equal should have the same behaviour as arb_contains and arb_overlaps because theyre closely related comparison predictes. if we change one, we should change the other two as well.
There was a problem hiding this comment.
I don't know what you mean.
There was a problem hiding this comment.
I think maybe this should only compare exact arbs aginst other numeric types exactly.
arb.contains() and arb.overlaps() use any_as_arb() to convert other to an arb. if these two are allowed to do that, then arb.equal() should also be allowed to do that. or if arb.equal() is not allowed to do that, the other two shouldnt be allowed either. i think this is right, because they are all used to compare the ball representation of two arbs, and they also appear closely together in the FLINT docs. so they should all behave the same.
IMHO none of them should use any_as_arb() since it causes implicit type conversion, which isnt good for something as important as equality!
Is there a possibility that the conversion to arb is not exact?
im not familiar enough with any_as_arb() to say
let me know again if im not clear!
There was a problem hiding this comment.
Is any_as_arb always exact or could it round the input number. I guess we could have an fmpq like 1/3 that cannot be converted to arb without some rounding errorand then we don't know it is contained:
In [1]: from flint import *
In [2]: ctx.prec = 53
In [3]: a = arb(1)/3
In [4]: ctx.prec = 22
In [5]: a.contains(fmpq(1, 3))
Out[5]: FalseThere was a problem hiding this comment.
I think overlaps and equal probably need to special-case some types. There should perhaps be a method that specifically says "other is an arb and is exactly the same as this" as well.
There was a problem hiding this comment.
can you elaborate a little bit?
There was a problem hiding this comment.
There should be a method suitable for use in test code (perhaps there already is) that checks that other is an arb and that it has the exact same representation as self.
Separately I think it should be possible to call e.g. equal or overlaps with something like fmpq it should be able to report the correct answer without any issues due to rounding.
There was a problem hiding this comment.
so if im not mistaken, that means any_as_arb should be changed to raise an error if the arb created is not exact, eliminating any implicit rounding.
if it is so, then it should raise errors based on type, not on value.
in my experience, conversion functions that raise on invalid values will raise runtime errors which are hard to anticipate. its better to raise on types that might potentially be inexact, and be compile-time errors instead. the user would instead convert type manually which is inconvenient but safer and explicit.
There was a problem hiding this comment.
No, I think it just means that any_as_arb should not always be used everywhere.
implement
arb_equalandacb_equalwhich compare ball representationsdistinct from
arb_eqandacb_eqwhich compare mathematical equalitythis is partly in response to #439 (comment)