Talk:24 game: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎Floating point: I'm not sure.)
(→‎Floating point: Floats seem to be Good Enough™)
Line 30: 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)
: 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)
: 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)

Revision as of 13:32, 8 December 2009

Purpose

What's the theoretical or practical interest in this task? I'd be interested in a program that enumerated all the 4-tuples that have solutions or determined whether a given 4-tuple had a solution, but we've already got tasks for getting input from the user, parsing arithmetic expressions, and so on. —Underscore 19:22, 31 October 2009 (UTC)

Umm,
  1. Playing the game.
  2. We have a gazillion sorts for example, (some are very impractical); so we can stand some repetition.
  3. We don't have many games, (of any description). Some site grazers might be attracted just by the word 'game'.
  4. The input checking is novel.
  5. The task is more than the some of its parts! (We have tasks covering most statement types, and it would not make sense to use that as a reason for not doing any composite task).
  6. Prelude to possibly another task to solve the game.
(I don't like to write a task until I have a solution and so can better gauge its suitability, and so write a better task description). --Paddy3118 20:57, 31 October 2009 (UTC)
Without any official guidelines as to what's an appropriate Rosetta task and what isn't, I suppose it's all completely subjective, so I can't very well argue with you. Adding more games isn't such a bad idea; RCRPG is interesting from an implementation point of view but sorely lacking in the fun department. I wonder how hard it is to write a minimal Pong clone. —Underscore 22:24, 31 October 2009 (UTC)
Very easy, with modern hardware and programming languages.
FWIW, this task does strike me as being a somewhat useful one. I used to have a similar time waster game when I was a teen where you got 4 numbers and a goal, the end. (Except for the variable goal, identical to this task.) -- Eriksiers 02:23, 1 November 2009 (UTC)
Since there really is no body of multiple individuals to give any sort of official policy, any concept of "official" falls to whatever I say by fiat. Which sucks, because I'm nowhere near as knowledgeable on programming as many of RC's contributors are, regular or not. All I really know is that I have a good mental picture of the kinds of roles I want to the site to fill. Beyond that, I don't pretend to have expertise; Many of my early ideas and attempts at trying to come up with task descriptions were too specific, enforcing my own limited view of programming on the examples, so I've learned to stand back. I step in from time to time if I see discussion heading in a direction counter to where I'd like the site to go, but that's about it.
As for "redundant" tasks, it doesn't bother me. In fact, I can think of ways to take advantage of it, such as category tagging individual examples with techniques, features or principles they may illustrate, to offer another way to browse and search the site, and to be more illustrative of alternate approaches. --Michael Mol 17:12, 1 November 2009 (UTC)
Methinks you're turning into a Python-esque BDFL ;-)
--Paddy3118 18:49, 1 November 2009 (UTC)
It's also practical; I've got one paid 50hr/wk job coding, one 30+hr/wk job taking care of an elderly family member, and one 50hr/wk job sleeping. Not much time left to micromanage RC, as well as have any [other] hobbies. :) --Michael Mol 23:13, 1 November 2009 (UTC)

A game player was not too difficult so I created it as a separate (but linked), task. --Paddy3118 04:52, 1 November 2009 (UTC)

Autohotkey and Untested

Does untested mean that it has not been shown to run? If so, could we restrict ourselves to examples that have at least been run? (Or do you mean: "insufficiently tested but has at least been run")? --Paddy3118 05:37, 11 November 2009 (UTC)

Floating point

Is recommending floating point wise? Precision and rounding errors would seem to defeat the purpose of preserving remainders. --Michael Mol 03:58, 8 December 2009 (UTC)

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. --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 if abs(ans - 24) < 1e-6 instead of if ans == 24. 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. —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. –Donal Fellows 13:32, 8 December 2009 (UTC)