Talk:Approximate equality: Difference between revisions

From Rosetta Code
Content added Content deleted
Line 1: Line 1:


==Can of worms==
==Can of worms==
uh-oh, you've opened a can of words here. I can remember in the far distant past, being lectured to about floating point/equality/closeness and I resolved to run and hide if I could in the future :-)<br>
uh-oh, you've opened a can of worms here. I can remember in the far distant past, being lectured to about floating point/equality/closeness and I resolved to run and hide if I could in the future :-)<br>
Firstly, you can't leave people to find out how Python does it, if you want them to use a specific method then you need to add the description to the task.<br>
Firstly, you can't leave people to find out how Python does it, if you want them to use a specific method then you need to add the description to the task.<br>
Second. Approximation depends on circumstances. If the compared vary exponentially ar non-linearly, or ... then one may end up with different, but more usable definitions of approximately equal.<br>
Second. Approximation depends on circumstances. If the compared vary exponentially ar non-linearly, or ... then one may end up with different, but more usable definitions of approximately equal.<br>

Revision as of 14:03, 3 September 2019

Can of worms

uh-oh, you've opened a can of worms here. I can remember in the far distant past, being lectured to about floating point/equality/closeness and I resolved to run and hide if I could in the future :-)
Firstly, you can't leave people to find out how Python does it, if you want them to use a specific method then you need to add the description to the task.
Second. Approximation depends on circumstances. If the compared vary exponentially ar non-linearly, or ... then one may end up with different, but more usable definitions of approximately equal.
--Paddy3118 (talk) 12:08, 2 September 2019 (UTC)

Agreed. You need to be very precise about your imprecision. Admittedly my gut instinct was that 100.01 and 100.011 are not approximately equal, like you said, but in fact they are better than 99.999% approximately equal and less than 0.001% different! I just wrote down "what I usually do" and on reflection that is not really likely to meet any task requirements very well. Perhaps explicitly specifying the accuracy (as a fraction, percentage, number of significant digits, decimal places, or whatever) with all the explicitly required answers for each of the various precision settings might help. Also, the test cases should probably be numbered rather than bullet pointed, if you're going to refer to them by number. --Pete Lomax (talk) 01:25, 3 September 2019 (UTC)
I've just done the update to the task's preamble (as far as numbers instead of bullets).   However, some programming language entries have added some of their (or other's) pairs of numbers to be compared, so their   outputs   don't match the examples given in the task's preamble.     -- Gerard Schildberger (talk) 01:41, 3 September 2019 (UTC)

The desired task use case is to have a method that allows tests on floating point calculations to be tested against a non-integer decimal constant, to verify correctness of the calculation, even when code changes change the floating point result in its non-significant portion.

Beyond that, the "can of worms" probably surrounds a) whether there should be an absolute difference that matters, versus just a relative difference, and b) whether 0.0 is different from all other floating point, because only 1/0.0 is NaN. Those "wormy" issues should not matter here.--Wherrera (talk) 02:25, 3 September 2019 (UTC)