From @zoffixznet

This report is for records only. The fix is already a part of my upcoming rework of `is-approx` code.

Problem​: both the specification, the documentation, and even the [partially] the old implementation of `is_approx` treat the positional tolerance argument as absolute tolerance, yet `is-approx`'s current algorithm treats it as relative tolerance.

From @smls

Isn't the relative tolerance more useful though?

Maybe it was intentionally changed from absolute to relative as an improvement, and the spec/doc have simply not been updated yet. Maybe searching the IRC logs or git history could illuminate the reasoning behind the current implementation?

The RT System itself - Status changed from 'new' to 'open'

From @zoffixznet

Isn't the relative tolerance more useful though?

Absolute is much easier to understand, use, and predict the lower/upper bounds to. I'd use 1-e15 by default, since that's what ≅ uses, but that's not what was specced/documented.

Both tolerance variants are available via named args anyway.

Maybe searching the IRC logs or git history could illuminate

All I see is a commit from a year ago with a link to a Python library's 13-page documentation as justification. Then throughout the year, I see multiple people complaining about the subroutine being broken, so I doubt whatever exquisite behavour that 13-page document describes is in high demand.

This morning, I posted in dev my proposal for a rewrite that fixes all the issues and defines/clarifies the extra behaviour currently implemented but unspecced/undocumented. So far, only PerlJam ++ed it. No one else commented.

https://github.com/zoffixznet/debug/blob/master/mu/approx-rework.md

From @zoffixznet

Proposed PR to fix this​: rakudo/rakudo#783

From @zoffixznet

Resolved by this commit​: rakudo/rakudo@bb165a5

@zoffixznet - Status changed from 'open' to 'resolved'