Monday, June 1. 2009When casinos go brokenWhat's wrong with this picture? I've taken the liberty of enlarging the relevant text (or you can click to view the full original screenshot).
Balance £3. Which means I have insufficient funds to place a £2 bet. Let me try to take a stab at explaining what kind of logic is needed to come to this absurd conclusion. Three Card Poker requires you to place an additional bet equal to your ante if you want to play the hand. You can fold and forfeit the ante - but if giving up without a chance is only option you wouldn't start the hand in the first place. So in fact this £2 bet (including a £1 "pair plus" prop bet) actually needs me to have £3 in my balance to play it. Which, it appears, I do. [Side note: This is different to blackjack, where the game will never stop you from dealing a hand if you don't have enough money to double down or split a pair. You are at least able to complete the hand and stand a chance of winning something without using these options.] However we already know that Gala suffers from fraction-of-a-penny rounding errors. It's not too much of a stretch to imagine that their bodgeroonie of a cashier system actually thinks my balance is very slightly below £3, but close enough to it that it is rounded up when displayed. It'll be some number like £2.999999995673, so that when asked "does he have at least £3?" then answer will be "ooooooh not quite". I see this kind of rounding error fairly often when working with decimal numbers. It's because computers suck at fractions. Everything has to be stored internally as some representation of a power of 2, so only fractions with a denominator of 2, 4, 8, 16, etc can be stored exactly. When working in hundredths, that's just 4% of all numbers: those ending in .00, .25, .50 or .75; everything else is going to be converted to a (fairly long) decimal approximation; close, but not precise. However, if you know that it happens, it's not that hard to deal with. Notably in the poker and casino operator APIs I've worked with, you don't need to worry about this. They have always stored and returned the player balance numbers as a whole number of pence or cents. It makes it pretty easy to accidentally conjure money out of thin air - you just have to forget to divide by 100 one time - but it means that there are never any fractions of a penny floating around the system to go wrong. In fact, some poker networks even store and return your player points balance as a whole number of hundredths of a point. I guess they really don't want to give much away! My assumption is that Gala's cashier system stores the casino balances as pounds and pence - a design decision that has side effects they either don't know about or don't care about. For a system that handles real money transactions this is, frankly, a bit poo. And if anyone from Gala actually reads this: yes, I could do (and have done) better. Let's talk. Anyway, there's more. I really can't begin to explain what the hell is going on this time. The dealer's cards were dealt, briefly flashing face up - but too quickly for me to remember what it showed. They flipped over as soon as they were dealt, and then the game announced the apparent straight flush for the dealer you (don't) see here. Like I'm just meant to believe that?
"NaN" means "not a number". Or, in English, "something fucked up". Isn't it great to know that when the game software has a glitch, the default behaviour is to give the dealer the very best hand possible? Comments
Display comments as
(Linear | Threaded)
Use Dec(imal), not Float in MySQL, for storing currency / definite numbers, which I learned the hard way last month. Floats are an approximation, decimals are not.
Comments (3)
Decimal types are good, but there are still rounding issues to be aware of, e.g. if you calculate VAT on an odd number and pump the result directly into a decimal(N,2) it will get truncated, whereas if you use sprintf("%.2f", $number) in PHP it will get rounded. Easy to lose pennies that way.
Even using sprintf everywhere, I think the rounding is peculiar; IIRC odd numbers before the rounding point go up and even numbers point 5 go down (e.g. 3.215 - 3.22; 3.225 -> 3.22). The most pecular stuff I've come across in PHP is when serialize()ing an array of numbers when what appeared to be a fixed point decimal then becomes a very very long approximation: < ? php $numbers = array(1.25, 2.5, 3.7); $ser = serialize($numbers); print $ser; ? > Result: a:3:{i:0;d:1.25;i:1;d:2.5;i:2;d:3.70000000000000017763568394002504646778106689453125;} Only numbers with denominators that are powers of 2 are preserved. Comment (1)
Oh yes, but if you always round($val,2) after dividing a number, you should be ok. I think
 Comments (3)
Add Comment
|
Calendar
QuicksearchArchivesCategories
Syndicate This BlogBlog AdministrationPowered byCopyright |
|||||||||||||||||||||||||||||||||||||||||||||||||
I don't use Moneybookers very often, but I have an account there for the odd times I need to receive money that way. This was one of those times. I was sent a sum of money, originally in British Pounds but it got converted to US Dollars as that's t Comment (1)
Tracked: Jul 11, 17:17