Anonymous user
Talk:24 game: Difference between revisions
→Floating point: Floats seem to be Good Enough™
Underscore (talk | contribs) (→Floating point: I'm not sure.) |
(→Floating point: Floats seem to be Good Enough™) |
||
Line 30:
: It isn't rigorous, (I'm an engineer, not a theoretical mathematician captain), but with the restricted range of single digit numbers, the given operators, and the precision of most FP implementations on a PC; I don't think it will matter. --[[User:Paddy3118|Paddy3118]] 07:12, 8 December 2009 (UTC)
: Certainly rationals are a better choice than floating point for this type of task, but I think you should be able to use floating point safely so long as you say something like <code>if abs(ans - 24) < 1e-6</code> instead of <code>if ans == 24</code>. It's considered good practice, in general, to never test a floating-point variable for exact equality. That said, I'm at a loss for an input that the Python program would wrongly reject, so maybe floating point is better than I think it is. —[[User:Underscore|Underscore]] ([[User talk:Underscore|Talk]]) 12:49, 8 December 2009 (UTC)
:: If someone can exhibit a solution that a floating-point version won't find, that's when action becomes necessary. However, when I try out likely problems then I find I still cannot trigger any issues. For example:
::<lang tcl>$ tclsh8.5
% expr {(((1.0/3.0)*9.0)*8.0) - 24.0}
0.0</lang>Despite a definitely non-representable intermediate (I know the implementation) the answer is exact. I just can't trigger the problem for anything that might be a solution. (Non-solutions… who cares about them?) Rationals might be theoretically better, but IEEE double seems good enough here. –[[User:Dkf|Donal Fellows]] 13:32, 8 December 2009 (UTC)
| |||