On Thursday, 19 September 2019 at 11:16:12 UTC, Simen Kjærås
wrote:
Might I ask what specifically you're working on?
Of course. It's about issue 15881 (and 15763), namely approxEqual
not always doing, what people think it should do. (As a side
note: I stumbled over this, when I wanted to file a bug report,
because I thought it's not doing, what it should do. In my case I
was comparing the distance of geographic items in a town.
approxEqual decided, that two items which where at opposite ends
of the town, are at the same place. Seen from a global
perspective, this might indeed be true, but here it was not, what
I was looking for.)
Well, some people (including me) think, that approxEqual should
be a replacement for == for floatingpoint numbers, to accept
small errors, that inevitantly creep in. But approxEqual accepts
rather large errors with it's default values. (Probably because
it's first use was to write some unittests for other functions in
phobos, where this is sufficent to make the unittests pass, but
not optimal, as errors might stay undetected). As it's not easy
to define "small", I searched in the internet, if others have
investigated on this and came up with [1], which, in my eyes, is
a very good summary.
Now I'm working on a replacement for approxEqual with the
constraints given in [1]. My first try (PR #7173) was a little
bit too fast and would have caused quite some trouble, so I
closed it and replaced it with two new PRs (#7180 and #7187) as
suggested by n8sh.
[1] https://www.python.org/dev/peps/pep-0485/
