Talk:24 game: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎Floating point: Try 3 3 8 8 in Tcl?)
Line 35: Line 35:
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)
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)
::: You mentioned in [[Talk:24_game_Player#Should_we_enumerate_all_solutions.3F]] that it was practicable to identify all 7,860 solutions. That sounds like a pretty small test set. (Or am I misunderstanding your description of the enumeration?) --[[User:Short Circuit|Michael Mol]] 18:49, 8 December 2009 (UTC)
::: You mentioned in [[Talk:24_game_Player#Should_we_enumerate_all_solutions.3F]] that it was practicable to identify all 7,860 solutions. That sounds like a pretty small test set. (Or am I misunderstanding your description of the enumeration?) --[[User:Short Circuit|Michael Mol]] 18:49, 8 December 2009 (UTC)

::: Hi Donal, you might try [[Talk:24_game_Player#Use_3_3_8_8_in_example_runs.3F|3 3 8 8]] in the TCL example. Floating point won't work for this in Python. --[[User:Paddy3118|Paddy3118]] 14:18, 15 February 2011 (UTC)


:One potential problem with floating point, when you get to more than 4 digits, is that in some languages (not Python), division by 0.0 evaluates to infinity (which can be divided by again to get 0), instead of raising an error, so for example, this in Ruby: <code>3.0 * (8.0 + 4.0 / (2.0 / (5.0 - 5.0)))</code> results in 24.0, which you might not want to allow. But I agree that this is not an issue with only 4 digits. --[[User:Spoon!|Spoon!]] 14:16, 8 December 2009 (UTC)
:One potential problem with floating point, when you get to more than 4 digits, is that in some languages (not Python), division by 0.0 evaluates to infinity (which can be divided by again to get 0), instead of raising an error, so for example, this in Ruby: <code>3.0 * (8.0 + 4.0 / (2.0 / (5.0 - 5.0)))</code> results in 24.0, which you might not want to allow. But I agree that this is not an issue with only 4 digits. --[[User:Spoon!|Spoon!]] 14:16, 8 December 2009 (UTC)

Revision as of 14:18, 15 February 2011

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)

You mentioned in Talk:24_game_Player#Should_we_enumerate_all_solutions.3F that it was practicable to identify all 7,860 solutions. That sounds like a pretty small test set. (Or am I misunderstanding your description of the enumeration?) --Michael Mol 18:49, 8 December 2009 (UTC)
Hi Donal, you might try 3 3 8 8 in the TCL example. Floating point won't work for this in Python. --Paddy3118 14:18, 15 February 2011 (UTC)
One potential problem with floating point, when you get to more than 4 digits, is that in some languages (not Python), division by 0.0 evaluates to infinity (which can be divided by again to get 0), instead of raising an error, so for example, this in Ruby: 3.0 * (8.0 + 4.0 / (2.0 / (5.0 - 5.0))) results in 24.0, which you might not want to allow. But I agree that this is not an issue with only 4 digits. --Spoon! 14:16, 8 December 2009 (UTC)
Precisely. That's why it matters that it is a “24-game player”. A solution with computation using rationals would be interesting though. –Donal Fellows 14:57, 8 December 2009 (UTC)

Does the Perl code work?

I have tryed to run the Perl code, and it seems that it doesn't recognise when the correct answer is given. --Blue Prawn 00:42, 26 January 2010 (UTC)

Scala only presenting numbers with solutions

I note that the impressive Scala example seems to only present a set of numbers guaranteed to have a solution. i can't help but think that from playing the game, some of the fun is lost, as we quite enjoyed trying the toughies - not knowing if they actually had a solution or not as most numbers do. I guess they don't have to add much for a solution to 24 game Player. --Paddy3118 06:43, 28 April 2010 (UTC)