torkell: (Default)
Today's maths fail comes courtesy of the local Tesco's - can you spot it?




Using the drained weight (dr.wt) of 165g, the correct values are:

65p ÷ 165g = 0.394p/g = £3.94/kg

£1.25 ÷ (2 × 165g) = 125p ÷ 330g = 0.379p/g = £3.79/kg
torkell: (Default)
So one of the extra minigames in StreetPass Mii Plaza is StreetPass Battle, wherein you defeat a succession of opposing empires in a best-of-three succession of battles with a rock-paper-scissors-like type system (type disadvantage wipes out half your troops, then largest army wins). There's some skill in that you can choose how your army is split into cavalry/archers/infantry and then pick which group to send into each battle - with care (and careful use of the spy ability) you can defeat much larger opposing armies.

This all falls apart against the final empire which is a straight run of five battles with each side's entire army. The loser of each battle loses half their troops, and whoever's army is biggest at the end wins. I think the AI's play is random here - certainly it's not the same pattern on each attempt, and rock-paper-scissors has limited scope for trying to be smart.

Anyway, the other day I realised that the odds change in steps as my army grows - adding ten soldiers won't change them, but adding enough to put me over 50% of the opposing army size will. So I thought a bit more and started working the various odds out...


Let's start with my current army, which contains 138,121 soldiers. The final empire has I believe a fixed size of 290,143. To win I have to end the five battles with more soldiers than the AI - obviously, if I win all five battles then I win because the AI will be left with 290,143 ÷ 25 = 9066 soldiers (give or take a few depending on how the game rounds the numbers). But how many battles do I actually need to win?

The answer is two. After winning the first the AI has 145,071 soldiers which is still larger than my army, but a second win reduces that to 72,535 which is less than my army. But I then have to maintain that lead, so I must at a minimum tie the remaining three battles. All in all (and if my vague memories of probability math are right), this gives me a chance of winning of (⅓)2 × (⅔)3 = 0.0329 or about 1 in 30ish which is rubbish. Except there's another path to a win - if I win three battles, I can then lose one and still end up on top (with a result of 69,060 against 36,267). That's got a chance of um... 3 wins times 1 any-result times 1 tie-or-win = (⅓)3 × 1 × ⅔ = 0.0247 or 1 in 40. Overall my chance of success is 1 in 17ish which is still rubbish, and tells me that there's really no point challenging the AI until I get a few more soldiers.


Like, oh, another 6951 or so (surprisingly easy as your army grows based on the size of armies that you StreetPass). At that point with my 145,072 soldiers I can achieve a win with any of:

One win and four draws (or better) = ⅓ × (⅔)4 = 0.0658
Two wins, a loss, and two draws = (⅓)2 × 1 × (⅔)2 = 0.0494
Three wins and two losses = (⅓)3 × 12 = 0.0370

Basically I have to win at least one more time than the AI does. Added up this gives me a chance of victory of 0.152 or better than 1 in 7. So, waiting until I get a few more troops will more than double my chance of success. Nice!


For even more fun, if I hold off until my army is larger than the AI's then the AI now has to win more than me, and I get a 6 in 7 chance of splatting it. So I could just wait until that happens. Or thinking about it, could I expect a win with fewer troops? I've not mentioned that there is a penalty to losing in that 10% of your army runs away, so I'd have to rebuild between battles... but if my army is large enough, then I could run battles back-to-back and have a good overall chance of winning one of them. So, if I have 145,072 × 1.16 = 257,003 soldiers (probably a little more - remember, rounding) then I get 7 attempts before dropping below half the enemy size and have a better than 50% chance of seeing one win out of those attempts. Each attempt still only has a 1 in 7 chance of success so my statement earlier about army size and thresholds still applies - in fact, if I'm patient and wait to replenish my army after each loss I can get by with even less troops. If I lose 6 back-to-back battles then overall 111,931 soldiers run away, but if I fight 6 battles at 145,072 and wait to rebuild after each one than I only lose 87,043 troops.

So, I think the most economical way to sensibly see a win is to battle each and every time I reach 145,072 soldiers, and that'll likely take 7 battles and cost me 87,043 soldiers from lost battles. Alternatively there's always the brute force approach - if I ever get to 8,224,097 soldiers then I will win, because the AI can win all five skirmishes and I'll still have more soldiers left... but accumulating that many will take ages and many play coins...
The path to world conquest is not easy, but let us give it our all!
Wentworth, StreetPass Battle
torkell: (Default)
I see [livejournal.com profile] talismancer has just managed to sneak in a post for yesterday. I can't really mock him for that one, seeing as I did the same several times during last year's run (and in fact while last night's post has a timestamp of 11:59:59 it was actually submitted a few seconds later).

Anyway, on to today's post. And today's random topic shall be on why hashing algorithms are not unique identifiers.

Let's take the SHA-1 algorithm. It's a cryptographically secure hashing algorithm that produces a 160-bit output. Now, 2^160 is a stupidly large number: over 1.46×1048. To put that in perspective, if you multiplied that number by 100 the result is more than the number of atoms in the earth (estimated at 1.33×1050). That should be large enough to give a unique output for any input, right?

Wrong.

Let's say that you somehow generate every possible sequence of 20 bytes (all 2^160 of them), and feed each one in turn to SHA-1. You'd get a different 20-byte sequence output for each input - in fact, you'd get 2^160 different outputs (this does assume that SHA-1 can generate a different output for each 20-byte input - it may well not do this, in which case you've already got your collision). Now generate a 21-byte sequence, and hash that. The result will match one of your previous outputs, since there are only 2^160 possible outputs and you've already generated every single one.

Of course, doing such is completely impractical. That doesn't mean that hash collisions won't happen - they're still possible, since for every possible output there are an infinite number of inputs that will give that output. I'll grant that actually finding a collision is extremely improbable, but "extremely improbable" is not the same as "impossible" and does not mean "cannot happen tomorrow". The more inputs you try the higher the chance of a collision is as well, due to the birthday paradox - if one were able to generate 2^80 inputs (still completely impractical, but less impractical than 2^160 inputs), then the chance of a collision is 50%.

And that's why things like Mercurial and git make me slightly nervous, since that uses SHA-1 as a unique identifier and just assumes that a hash collision won't ever happen.
torkell: (Default)

Oh dear, there's been more riots in London. My views on the protests haven't changed, and the quote from my previous post still stands. This time round the police came out in force, leading to this gem of a comment that the BBC quoted:

From twitter: Why don't they stop sending a ridiculous amount of police out for small scale protests instead of cutting education spending?

Well, the last protest was "small scale" and look what happened there.


Anyway, while all this was going on Nick Clegg did make a good point: "Examine our proposals before taking to the streets. Listen and look before you march and shout." And indeed there are some significant points in the proposals:

Point 1: you do not pay any tuition fees up front.

Point 2: you do not have to start repaying fees until you earn more than £21k (and then it's 9% of what you earn above the threshold).

Point 3: your student loan is written off (without, I believe, affecting your credit rating) 30 years after graduating.

I do wonder just how much of the loan the average person will pay back. Hmm... let's assume an annual loan of £10k, this works out as £3k or so cost of living and £6k or so fees. Interest rates will be 0% for people on incomes of £21k, rising to 3 points above inflation for people on incomes of £41k. Let's assume a linear increase and 2% inflation, so at £31k you pay 2.5% interest.

So, after your three years of university you'll end up with a £30k loan (£10k × 3 years at 0% interest). This is actually slightly better than the current system, in that currently you do pay interest (pegged at inflation) from day 1, although your loan before interest under the old system would only be £18k or so.

Let's say you go into work bang on the £21k threshold, and each year at work you get a 3% rise. That's probably a highly unrealistic scenario, but it'll do for some rough numbers. I vaguely remember there being nice equations to do with applying interest, but I can't remember what they were so I'm going to do this the old fashioned way with mad Excel skillz.

YearLoanSalaryInterest rateInterestRepaymentResult
130000.0021000.000.00% 0.00 0.0030000.00
230000.0021630.000.16% 47.25 56.7029990.55
329990.5522278.900.32% 95.89 115.1029971.34
429971.3422947.270.49% 145.91 175.2529941.99
529941.9923635.690.66% 197.29 237.2129902.07
629902.0724344.760.84% 250.04 301.0329851.08
729851.0825075.101.02% 304.12 366.7629788.44
829788.4425827.351.21% 359.50 434.4629713.47
929713.4726602.171.40% 416.15 504.2029625.43
1029625.4327400.241.60% 474.02 576.0229523.43
1129523.4328222.241.81% 533.06 650.0029406.49
1229406.4929068.912.02% 593.20 726.2029273.49
1329273.4929940.982.24% 654.33 804.6929123.13
1429123.1330839.212.46% 716.37 885.5328953.97
1528953.9731764.382.69% 779.18 968.7928764.36
1628764.3632717.322.93% 842.601054.5628552.40
1728552.4033698.843.17% 906.461142.9028315.96
1828315.9634709.803.43% 970.521233.8828052.60
1928052.6035751.093.69%1034.521327.6027759.52
2027759.5236823.633.96%1098.141424.1327433.53
2127433.5337928.344.23%1161.011523.5527070.99
2227070.9939066.194.52%1222.671625.9626667.71
2326667.7140238.174.81%1282.591731.4426218.87
2426218.8741445.325.00%1310.941840.0825689.73
2525689.7342688.685.00%1284.491951.9825022.24
2625022.2443969.345.00%1251.112067.2424206.11
2724206.1145288.425.00%1210.312185.9623230.46
2823230.4646647.075.00%1161.522308.2422083.74
2922083.7448046.485.00%1104.192434.1820753.75
3020753.7549487.885.00%1037.692563.9119227.52

That's... not what I expected. The politicians weren't lying when they said that most people won't repay the full amount. Or were they? Just how much do you pay over the 30 year period?

I'll leave working that out as an exercise for the reader, though I'll give you a hint: they're still lying.

torkell: (Default)
Minish Cap has a sort of gambling mini-game for collecting figurines - each try at a figurine costs a certain number of mysterious shells, and the more shells you spend the greater the odds of getting a new figurine are. Each extra shell you gamble increases your chances of success by 1% (i.e. if one figurine gives you a 50% chance, two will give you a 51% chance and three will give you 52%). The first figurine is a guaranteed success, as at that point all possible figurines are new and so only costs 1 shell. The second then costs 1 shell for a 100% chance, or 2 shells for a 99% chance, and so on up to final (130th at this point in the game) figurine which is one shell for a 1% chance or a hundred shells for a guaranteed success.

Anyway, while trying to get all of them I wondered just how long it'd take...
Mad maths )

Infinity

Nov. 8th, 2008 11:05 pm
torkell: (Default)

The link I posted earlier today was inspired by an old school TV program I once saw, about infinity. Throughout the program they kept on showing segments where someone would say:

"'Twas a dark and stormy night, and the storyteller said to his friends, "Gather round and I'll tell you a tale." So the listeners gathered round, and the storyteller said:"

At this point the speaker walked off to one side, revealing another person behind him who repeated the same phrase. Given enough people you could continue this for hours.

Infinity is a strange concept, when you think about it. Many of you will have at some point heard the tale of explaining infinity by picking larger numbers. You think of the largest number you can come up with ("one thousand"), but the other person will always be able to pick a larger number ("one thousand plus one"). This can continue forever, as there's always a larger number ("two thousand! three thousand! one million! one million plus 1! one squillion! one squillion plus 1! ..."). There's a similar trick that can be done with prime numbers, to prove that there is no such thing as an absolute largest prime: multiply all the primes you know, and add 1. Now, if you then divide that number by any of your primes there will always be a remainder of one. Therefore, either this number is itself prime, or you missed out a smaller one. And, of course, this can be applied to the new number as well.

Once you get close to infinity, other stuff becomes strange as well. Here's another example from that TV program:

Start by imagining an infinitely long straight line. That's reasonably easy to come up with, and to comprehend. Let's look at a bit in the middle of it, say a yard long (no particular reason). Now imagine a circle just above the line, with a diameter of a yard. It's clearly a circle: you can easily see the curvature of it.

Now make that circle bigger, but still concentrating only on a section of it about a yard across. Twice as big? Still a circle. Ten times as big: well, it's less curved than it was but it's definitely circular.

As the circle gets larger and larger the small bit you're looking at becomes flatter and flatter. At some point, the small section you're imagining will be so flat and straight that it looks just like the infinitely long straight line we came up with earlier.

Now, do you have two infinitely long straight lines, two infinitely large circles, or one of each? Do both even exist as separate things?

4, 82, …

Nov. 4th, 2008 11:40 pm
torkell: (Default)

Shortly after signing in to #jj2, I saw this snippet go past:

[17:59] <n0m> TakeOne: 4, 48, 1198, 2394, 8794...
[18:00] <n0m> 4, 82*, 1198, 2394, 8794...

[18:08] <n0m> Basically, I randomly said 4, and Takeone randomly said 82, and I tried to find a sequence.

[18:07] <n0m> My logic in this is something like 2, 4, 6, 8, 10 -> 2, 5, 11, 17, 29 -> 2, 7, 29, 47, 109, -> 2, 13, 109, 211, 599, -> 2, 41, 599, 1297, 4397, -> 4, 82, 1198, 2394, 8794

[18:12] <n0m> … positive even numbers, -> nth prime number -> nth prime number, -> nth prime number, -> nth prime number, -> doubled
[18:13] <n0m> But because 1 isn't considered prime, it would be more like (n+1)th prime number.

So, with nothing else to do, I dusted off my graphical calculator and started playing with numbers. The first sequence I came up with was

ai = 4 × i4.357

This gives the sequence (starting with i=1)

(4, 82, 479.81, 1681, 4444.86, …)

This isn't as nice as n0m's attempt, but it's a start. I actually found the sequence by plugging the first two numbers in to the calculator and telling it to find a power formula that matched. Anyway, next I decided to go for multiplication. 82 ÷ 4 = 20.5, so my next formula and sequence was:

b1 = 4
bi = 20.5 × bi - 1
(4, 82, 1681, 34460.5, …)

Note how a4 = b3 = 1681, and also if you continue the first sequence then a8 = b4 = 34460.5. There must be some relationship between the numbers 20.5 and 4.357. The latter sequence looked exponentialish, so to get it into a form that didn't depend on previous values I again ran it through the calculator, this time telling it to find an exponential formula. There is an exact formula for it (at least for the first 5 datapoints):

ci = 0.195 × e3.020 × i

It's worth mentioning that I've been rounding these numbers: the exact value went off the end of the calculator display. I'm sure that there must be some nice relationship between all of them, but at that point I left it to sort out some other stuff. Any ideas?

[18:28] <Torkell> … why those numbers?
[18:28] <n0m> Magic.

January 2026

S M T W T F S
     123
45678910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 9th, 2026 03:00 pm
Powered by Dreamwidth Studios