Wikipedia:Reference desk/Archives/Mathematics/2010 July 17

Welcome to the Wikipedia Mathematics Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

July 17

Half pennies on credit cards

Can half pennies be saved on British credit cards? --84.61.131.18 (talk) 13:54, 17 July 2010 (UTC)

Half pennies are no longer legal tender. The miscellaneous reference desk is probably better for this sort of thing. Dmcq (talk) 14:29, 17 July 2010 (UTC)

British banks have never dealt in decimal half pennies (except in pairs), even when they were legal tender. Some credit cards are generous and round up to the nearest penny. Dbfirs 16:59, 17 July 2010 (UTC)

Can farthings be saved on British credit cards? --84.61.131.18 (talk) 10:21, 18 July 2010 (UTC)

As the article Farthing (British coin) notes, they ceased to be legal tender on 31 December 1960. That is, they didn't even make it to decimalisation. The only way you could save them on a (post-decimalisation) credit card would be with sellotape. -- 174.24.196.51 (talk) 15:31, 18 July 2010 (UTC)

Can the old half pennies be saved on british credit cards? --84.61.131.18 (talk) 17:30, 18 July 2010 (UTC)

No. You can't save old Nigerian 1/10 pennies either on them or Euros. Except of course with sellotape or some such analogue as 174.24.196.51 suggested. Dmcq (talk) 18:16, 18 July 2010 (UTC)

What subdivision is the smallest which could be stored on the oldest British credit cards? --84.61.131.18 (talk) 19:16, 18 July 2010 (UTC)

What does it mean to "save" or "store" money on a credit card? You borrow money on credit cards, you don't save it to them... --Tango (talk) 21:28, 18 July 2010 (UTC)

Perhaps there is a misconception that the magnetic stripe on a credit card stores the balance of the card. As far as I know, it stores only the account number, and perhaps some other identifying information. —Bkell (talk) 09:14, 19 July 2010 (UTC)

Even prepaid debit cards are normally just treated by the bank like a normal debit card with a hard limit. There are some cards which are more equivalent to money, for instance cards used for paying fares typically store the actual amount remaining on the card. Dmcq (talk) 10:06, 19 July 2010 (UTC)

For at least the last forty years, banks have not recorded any fractions of a penny (though I remember when they did). If banks don't record fractions then neither do any types of card. Barclays introduced the first credit card in 1966 (American Express and the Bank Americard - later called VISA - were already in the USA), but I think the banks had stopped recording halfpennies by then. Perhaps someone with a better memory than mine can confirm this. I know that cheques here have not allowed half pennies for nearly a century. The smallest amount to be recorded, therefore, is and has been one whole penny, old or new. Dbfirs 08:07, 20 July 2010 (UTC)

Greedy tricolorability

The section called "How to color a knot" in the Tricolorability article seems to imply that a greedy, nonbacktracking algorithm will always succeed in properly tricoloring a knot if the knot is indeed tricolorable. But surely this is not the case—in the fourth step of the "example of a tricolorable knot", if the lower right strand is selected and colored blue (rather than the L-shaped strand on the left) then it is impossible to properly complete the tricoloring. Right? —Bkell (talk) 14:17, 17 July 2010 (UTC)

In the example given, each step is forced except for the initial color choices. So it's not so much greedy as take the only choice available at each step. The article doesn't do into it but I assume there are more complex knots where you have multiple choices available at an intermediate step, and have to use some sort of backtracking. The section is a bit WP:HOWTO for my taste but it seems correct mathematically.--RDBury (talk) 14:34, 17 July 2010 (UTC)

The colors for the top right weren't forced, they could be swapped round. Notice the 'and color it with another color' in box 3. The only available different color for that lower right strand is red. Dmcq (talk) 14:36, 17 July 2010 (UTC)

Sure, the colors are forced if the strands are chosen in the order given. But if I choose to color the lower right strand third rather than fourth, and I choose to color it blue, then I arrive at a conflict that cannot be resolved without backtracking (because I cannot then color the L-shaped strand on the left). —Bkell (talk) 15:26, 17 July 2010 (UTC)

Anyway, my point is that I think the section is subtly flawed. It (imprecisely) describes an algorithm for coloring the strands—a greedy, nonbacktracking algorithm—and implicitly makes the claim that if this algorithm gets stuck then the knot is not tricolorable. I think this claim is false. —Bkell (talk) 15:29, 17 July 2010 (UTC)

Ah, okay, I see what you're saying, RDBury. In these examples the strands are chosen in an order that is carefully prepared so that there is only one possible color in each step, thus making backtracking unnecessary. (That's an important point that is omitted in the "how-to".) However, even this is not exactly the case: the "rules" of tricolorability described in the preceding section allow all of the strands incident upon a crossing to be given the same color, so, for example, the second strand colored in each of these examples could have been red. —Bkell (talk) 15:38, 17 July 2010 (UTC)

If you followed their rules you could have chosen different colors for the top right but the only choice for the bottom right was red. The color chosen according to the rule is another color. It can't be the same color as the other side unless the string over was the same color too. Dmcq (talk) 15:42, 17 July 2010 (UTC)

Yes, I know. I'm talking about the point in time when you have just colored the first strand red and you are pondering what color to use for the second strand. You have two choices here: either color the second strand red, so that it matches the first strand, or green (say), so that it doesn't match. Either is a priori allowable by the rules of tricolorability, even though the description of the algorithm says that a different color must be chosen. —Bkell (talk) 15:45, 17 July 2010 (UTC)

In other words, the entire lower left corner of the first example could properly be colored red. Or the entire upper right corner. (But not both, because the rules require at least two colors be used.) —Bkell (talk) 15:47, 17 July 2010 (UTC)

If your comment was a reply to what I wrote at 15:26, then let me try to explain it again. First operation is the same as the example: coloring the upper left strand red. Second operation is also the same as the example: coloring the J-shaped strand green. Third operation is different from the example: we are going to color the lower right strand now, not the lower left strand. This seems to be a legal choice to make. We choose to color this strand blue. This also seems to be a legal choice to make. It does not conflict with the coloring of the lower left L-shaped strand, because we haven't colored the lower left L-shaped strand yet. However, if we now choose to color the lower left L-shaped strand as our fourth operation, we arrive at a conflict and must backtrack. —Bkell (talk) 15:52, 17 July 2010 (UTC)

I see, instead of following the string across choose a string that was crossed over. That certainly gives problems. It might be the statement of the algorithm is incomplete, but anyway I had a quick look on the web and I couldn't see any reference to an algorithm to three color a knot if it is possible, so on a quick guess I'd have to agree it was made up, or in wiki speech original research. Lets just see if anyone else comes up with a citation within a day since there are nice diagrams, and otherwise just remove that stuff entirely and note its removal and date in the talk page. Dmcq (talk) 16:32, 17 July 2010 (UTC)

I've removed any hint of an algorithm from the article. Dmcq (talk) 12:51, 20 July 2010 (UTC)

Interest calculations

My credit card company has just sent me an offer of zero percent interest for one year, and no transfer fee. I am not at all in debt apart from an interest-only mortgage. How should I calculate the amount of money that I can obtain from the credit card to pay off part of my mortgage? The two conditions are i) there must be zero money outstanding on the credit card when the interest-free year ends, and ii) the combined payments on the credit card and the interest-only mortgage must be no more than they are now. The credit card small-print says I should pay at least 2.25% of the outstanding balance off each month, or £5, whichever is greater. Thanks 92.29.117.202 (talk) 15:54, 17 July 2010 (UTC)

Without thinking about the particulars my first impulse would be to borrow as much as possible and stick 73% into bonds for 11 months and pay back the 2.25% with the remainder. Then walk away with the interest when paying the bank back. I doubt they'd lend you enough to pay any decent part of the mortgage back but you might be able to buy yourself a nice dinner. Dmcq (talk) 16:57, 17 July 2010 (UTC)

The interest rate on the mortgage would be greater than that on bonds. 92.29.117.202 (talk) 18:59, 17 July 2010 (UTC)

The problem with using borrowed capital to pay off a mortgage is that the company will not normally give the money back (increasing the mortgage again) at the end of the year (or at least not without an extra fee). In these circumstances, Dmcq's solution seems optimal, but if you happen to have a very flexible mortgage, then pay it off with 73% of your loan and borrow it back again after 12 months, but be very careful, because the slightest glitch in timing could cost you a lot of money in charges. Personally, I don't think this is worth the risk, but you might make a profit if you get the timing right. Dbfirs 08:49, 18 July 2010 (UTC)

Sorry I have not made my point clear enough. If I used the credit card offer to pay off some of the mortgage, then (assuming it is adjusted immediately) the monthly payment from the mortgage will reduce, but I will have make credit card payments also. What would in theory be the amount I should borrow from the credit card given the two constraints that i) there must be zero money outstanding on the credit card when the interest-free year ends, and ii) the combined payments on the credit card and the interest-only mortgage must be no more than they are now? It has never been my intention to increase the mortgage again after the year is up - the amount borrowed on the credit card must drop down to zero after a year due to its normal monthly repayments.

If I borrowed enough money from the credit card to reduce my mortgage payments by £100 a month, then the maximum I could borrow under the constraints would be 12 x £100 = £1200. Now I think of it, any amount I borrow would reduce my monthly mortgage payments by only a small amount, so the amount I could pay off on the credit card would be even less than that, and which by a circular arguement indicates that the two criteria above cannot be fulfilled for any amount more than zero pounds. Thanks 92.24.178.184 (talk) 10:47, 18 July 2010 (UTC)

By the way I'd have another close look at the terms. Is the zero percent on the transfer or on new purchases? And you'll very likely find that it is at most on credit card purchases and you can't borrow money on it. Dmcq (talk) 12:37, 18 July 2010 (UTC)

Any money trasfered from somewhere else is charged zero interest for one year, and there is no transfer fee. 92.28.244.168 (talk) 19:10, 18 July 2010 (UTC)

When they say "transferred from somewhere else", they usually mean from another credit card, not from a mortgage! Dbfirs 11:17, 19 July 2010 (UTC)

I do have a brain thanks. 92.15.4.196 (talk) 21:28, 19 July 2010 (UTC)

... so if you have no transferable debts, why ask the question? Dbfirs 06:38, 20 July 2010 (UTC)

I'm going to assume this is hypothetical, as it's quite blatently not very real-world (as people have pointed out above). It all depends on the interest rate of the mortgage. If the mortgage is at 6%AER, and you pay £1200 off it, then you must pay an extra £100 a month, but you will save yourself a total of £72 (1200*0.06) in interest over the course of the year. I can't really see a situation where using a credit card like this would be sensible. Much more sensible to get a repayment mortgage, and reduce the debt that way. -- WORMMЯOW  15:43, 20 July 2010 (UTC)

ACT practice test question

This is an extremely elementary geometry question, I'm just asking because there is a surprising amount of disagreement over it. I was taking an ACT practice test, and there is a question, which I've copyied below:

The rectangles ABCD and EFGH shown below are similar. Using the given information, what is the length of side EH, to the nearest tenth of an inch? (Rectangle drawing summary follows: ABCD: AD labelled 3 inches, CD labelled 8 inches, others unlabelled; EFGH: GH labelled 2 inches; AB and CD appear to be the longer sides of ABCD; EH and FG appear to be the longer sides of EFGH) Attempt at ASCII art rendering follows

                       E _______F
   A_____________ B     |       |         
   |             |    ? |       |
 3 |             |      |       |
   |_____________|      |_______|
  D       8      C     H   2 in  G

The answer choices are: A. 0.8
B. 1.3
C. 5.3
D. 7
E. 8

I saw that EH and FG was longer than GH and EF, but the instructions in the ACT said that Figures are not necessarily drawn to scale, so I disregarded this. I reasoned that since ABCD~EFGH then EH and AD must be proportional, as must be GH and CD. Setting up the proportion EH/3=2/8 I got EH=.75 which rounds up to .8 and thus picked A. However in the answers section they claim the correct answer is C. The explanation they provided makes no sense to me. They said that 3/8=2/EH therefore 3(EH)=16 and EH=5.3. Is this a mistake in the book? I thought corresponding segments in similar figures have to be proportional, ie A corresponds to E, B to F, C to G, D to H. Thanks for any help. Sorry about the TLDR. 76.229.159.199 (talk) 17:25, 17 July 2010 (UTC)

Apparently they want you to decide that EFGH is a rotated and scaled version of ABCD (thus still similar). The idea that they're not to scale is meant to prevent you from measuring EH and GH directly on the paper with a ruler to get the length; it seems it is not meant to prevent you from noticing which sides are longer. --Tardis (talk) 17:37, 17 July 2010 (UTC)

I don't get it. If you pick GH is the long side then EH = 0.75 whereas if you pick GH to be the short side then EH = 5.33. Both are included (rounded) in the choices so what was the clue to treat GH as the short side? hydnjo (talk) 19:47, 17 July 2010 (UTC)

GH (in the drawing) appears shorter. 76.229.159.199 (talk) 03:49, 18 July 2010 (UTC)

Poorly-set questions like this reflect badly on the intelligence of the author of the book. The question should have said that rectangle ABCD is similar to rectangle FGHE, and it should also have mentioned that answers are rounded to one decimal place. Dbfirs 08:35, 18 July 2010 (UTC)

The question asks for an answer rounded to 0.1 inch. Cuddlyable3 (talk) 23:24, 19 July 2010 (UTC)

I took the ACT in high school and remember that one of the questions definitely had an error, such that one of the answer choices was obviously correct, but because of how the question was worded, one of the other choices was also correct. The developers of the SAT are famously careful about that sort of thing (the questions get a ton of expert review and closed trials before going "live") and the ACT was sloppy by comparison. 67.122.211.208 (talk) 02:42, 19 July 2010 (UTC)

Algorithm to combine trees?

Is there an algorithm to combine two similar trees please? The trees would be broadly similar, except some of the nodes (and their sub-nodes) would be missing in one of the trees, and there would be extra nodes (and their sub-nodes) in one of the trees. The trees start from the same root.

If it makes thing clearer then the two trees-to-be-merged could be TreeA: Food>breakfast,lunch. breakfast>boiledegg,toast,marmalade. lunch>pasta,apple.

TreeB: Food>breakfast,lunch, dinner. breakfast>toast,kipper,marmalade. lunch>sandwich,fruit. fruit>apple,orange,banana. dinner>lentils,rice,strawberries.

TreeCombined: Food>breakfast,lunch,dinner. breakfast>boiledegg,toast,marmalade,kipper. lunch>pasta,apple,sandwich,fruit. fruit>apple,orange,banana. dinner>lentils,rice,strawberries.

Thanks 92.29.117.202 (talk) 18:26, 17 July 2010 (UTC)

The Computing reference desk is probably better for this sort of thing. Dmcq (talk) 18:46, 17 July 2010 (UTC)

By the way I believe this would be called a merge of the trees and you have named nodes. Dmcq (talk) 18:52, 17 July 2010 (UTC)

Here is a sketch:

Represent the trees as a sorted line-numbered file

10000 TreeA
11000 Food
11100 breakfast
11110 boiledegg
11120 toast
11130 marmalade
11200 lunch
11210 pasta
11220 apple
20000 TreeB
21000 Food
21100 breakfast
21110 toast
21120 kipper
21130 marmalade
21200 lunch
21210 sandwich
21220 fruit
21221 apple
21222 orange
21223 banana
21300 dinner
21310 lentils
21320 rice
21330 strawberries

Move the first digit to last position and sort

00001 TreeA
00002 TreeB
10001 Food
10002 Food
11001 breakfast
11002 breakfast
11101 boiledegg
11102 toast
11201 toast
11202 kipper
11301 marmalade
11302 marmalade
12001 lunch
12002 lunch
12101 pasta
12102 sandwich
12201 apple
12202 fruit
12212 apple
12222 orange
12232 banana
13002 dinner
13102 lentils
13202 rice
13302 strawberries

Delete the last digit and clean up extras

0000 TreeA
0000 TreeB
1000 Food
1100 breakfast
1110 boiledegg
1110 toast
1120 kipper
1130 marmalade
1200 lunch
1210 pasta
1210 sandwich
1220 fruit
1221 apple
1222 orange
1223 banana
1300 dinner
1310 lentils
1320 rice
1330 strawberries

Renumbering

000 Food
100 breakfast
110 boiledegg
120 toast
130 kipper
140 marmalade
200 lunch
210 pasta
220 sandwich
230 fruit
231 apple
232 orange
233 banana
300 dinner
310 lentils
320 rice
330 strawberries

Bo Jacoby (talk) 11:53, 18 July 2010 (UTC).

Interesting, but I don't get how you can see what the parents or children of a node are. It may be some node-numbering convention I am not aware of. Thanks. 92.28.244.168 (talk) 19:16, 18 July 2010 (UTC)

1. The parent of 233 'banana' is 230 'fruit', the parent of 230 is 200 'lunch', and the parent of 200 is 000 'Food'. So the parent of a node is obtained by zeroing the least significant (nonzero) digit.
2. The node-numbering convention is published in Bo Jacoby: ORDINAL FRACTIONS - THE ALGEBRA OF DATA, Konferensdokumentation NordDATA 90, vol 3, page 357-367 (Göteborg 11-14 juni 1990). I invented the method in 1980 and have used it ever since. My wikipedia article on ordinal fraction was by my learned fellow editors identified as original research and deleted. (Most of my inventions are reinventions, but apparently not this one). Bo Jacoby (talk) 22:35, 18 July 2010 (UTC).

Yeah, it would appear that the example worked only because TreeA was missing dinner, not lunch. So, if TreeA and TreeB each have a node with the same value (or name) then are those nodes guaranteed to be at the same depth? If so, it would seem easy to do simultaneous tree traversals, either adding missing items to one tree or creating a third tree with the merged content of both. -- 110.49.193.95 (talk) 20:30, 18 July 2010 (UTC)

Sorry, they are not guaranteed to be the same depth. They probably will not be. Thanks 92.15.26.94 (talk) 21:58, 18 July 2010 (UTC)

It seems to me that the simplest method is to pick one tree to be the "new" tree. For each node in the other tree, insert the node in the new tree. As you attempt to insert the node, the standard insert algorithm will look where to insert it. If it finds the node, just don't insert it. Once finished, you may want to balance the new tree using a standard balancing algorithm. -- kainaw™ 22:03, 18 July 2010 (UTC)

Thanks. I'm thinking of how to copy two similar computer directory trees to make a combined tree where nothing is lost. In that situation you would start at the top of the trees and have no knowledge of what was lower down. I think its easiest to copy one tree and then add the other to it. The procedure at each directory is not too difficult, but as a non-mathematician and non-programmer its the traversing of the source tree that I find difficult. 92.28.240.114 (talk) 09:28, 19 July 2010 (UTC)

Traversing the trees is easy, but have you really thought of what you want to do at each level? What do you do if the same directory (as identified by name and level) in each tree each has a file of the same name, but the files differ in content, or if one is a file and the other is a subdirectory? In a directory tree a subdirectory may have the same name as its parent (or earlier ancestor), and you said earlier that matching nodes (directories, or possibly files as well?) may not be at the same depth in each tree, so how do you know if you really have a match or not? If you are not concerned about such special cases, then a merge is trivial. -- 110.49.193.24 (talk) 11:24, 19 July 2010 (UTC)

"Traversing trees is easy" - tell me how then please? I have already thought of the various choices you mention. Thanks 92.15.4.196 (talk) 21:22, 19 July 2010 (UTC)

Tree traversals#Sample implementations shows how simple it is to recursively step through a binary tree -- with a directory tree you just loop on all elements at each level, and following two trees in parallel adds complexity only if you are trying to match things up at different levels, something that you apparently want to do but have not explicitly defined. Without this complication a simple cp or tar command can traverse directories automatically and possibly do what you want depending on how you want to handle mismatches. find is a dedicated directory traversal command, and with a bit of shell scripting can take action and handle mismatches however you wish. For anything beyond what cp or tar can do you could write a quick perl script. Have you searched for directory merging utilities. One early result is this (rather verbose) perl script which could be a starting point for whatever it is you want to do. -- 110.49.193.194 (talk) 23:47, 19 July 2010 (UTC)

They are not binary trees though - a directory could easily have 100 or more sub-directories. Thanks for the link to the Perl script. 92.15.7.17 (talk) 11:07, 20 July 2010 (UTC)

Mathematical game

Player B chooses a positive integer 1 < n < 20. Then, player A writes down any n consecutive positive integers. Starting with A, players alternate crossing off numbers until there are two left. If the two numbers are relatively prime, A wins; otherwise, B wins. Can one player guarantee victory? --138.110.206.102 (talk) 21:17, 17 July 2010 (UTC)

Yes, according to zermelo's theorem (game theory) and the fact that a draw is not possible. I have no idea which one it would be though. ––Alphador (talk) 06:41, 18 July 2010 (UTC)

By the way, I assume you meant 2 < n < 20.--Alphador (talk) 06:42, 18 July 2010 (UTC)

Why assume that? Allowing n=2 just gives B a chance to lose very quickly. Algebraist 09:51, 18 July 2010 (UTC)

Well the game is trivial with n = 2 and there is a very simple winning strategy up to n=7 for A if he has a free choice of where to start his integers. A can still win for n=8 to 11, but has to be careful where to start. My intuition says that A always has a winning strategy, but intuition is sometimes wrong and, even if it is correct, I'm not sure how to prove it other than by trial and error. Has anyone the time to do a full analysis? For some values of n, A can be generous and allow B to go first in crossing off. Dbfirs 07:07, 18 July 2010 (UTC)

I don't think A needs to be careful where he starts at all. Whatever n integers he picks, he can use a simple strategy to ensure the last two are consecutive (and hence coprime). Algebraist 10:00, 18 July 2010 (UTC)

I must be missing something as I see a winning strategy for B choosing n=18 (giving B the last move, with both A and B crossing off 8 numbers each). Of A's 18 consecutive positive integers, there will be 9 even numbers and 3 odd multiples of three. In order for A to win, 8 of the 9 and 2 of the 3 must be crossed off, something that A cannot accomplish alone. B's winning strategy is to avoid crossing off multiples of 2 or 3 until all other numbers have been crossed off. With only 6 numbers not multiples of 2 or 3, B will have succeeded in crossing them off with at least two more moves to go. Thus, B's final move will be to cross off one of three numbers which are all either multiples of 2 or 3, and can ensure that the final two numbers belong to one group or the other. -- 117.47.248.208 (talk) 12:21, 18 July 2010 (UTC)A similar strategy should work for all even n≥12.-- 117.47.248.208 (talk) 13:29, 18 July 2010 (UTC)

I must also be missing something, because I'm pretty sure A is incapable of ensuring that the numbers are consecutive in the case of n=3. Sure, he can ensure that they are coprime, but they may have to be odd n, n+2.

Can you be more explicit about your simple strategy, Algebraist? --173.174.22.246 (talk) 12:27, 18 July 2010 (UTC)

Remember that A goes first, so it is easy for A to ensure two consecutive numbers in the case of n=3. It seems clear that B can ensure that there are not two consecutive numbers when making the last move (even n>2), but I don't know about odd n. -- 117.47.248.208 (talk) 12:42, 18 July 2010 (UTC)

Sorry, I meant n=4. Dunno how I made that mistake. --173.174.22.246 (talk) 15:43, 18 July 2010 (UTC)

I miscalculated, sorry. My scheme works only for n odd. It would work for all n if B had to remove first. Algebraist 18:45, 18 July 2010 (UTC)

What is your scheme and is there a simply proof that it always works? It seems to me that for n odd, A choosing to cross off the smallest integer that is not part of an isolated pair, when possible, will result in a consecutive pair, but I've not though of a proof yet. -- 117.47.213.137 (talk) 08:29, 19 July 2010 (UTC)

I think Algebraist's scheme is simpler than that. For their first move A removes either the lowest number if that is odd, or the highest number if the lowest number is even. This leaves an even number of numbers starting at an even number. Thereafter, if B removes an even number k then A removes k+1, and if B removes an odd number k then A removes k-1. This ensures that after A's last move the final two remaining numbers are consecutive and hence coprime. Gandalf61 (talk) 08:51, 19 July 2010 (UTC)

So it remains to check whether A always has a winning choice for n = 12, 14, 16 and 18 -- unless Algebraist and Gandalf61 can come up with another clever strategy. Dbfirs 11:10, 19 July 2010 (UTC)

I must be missing something too just reading this. As far as I can see the argument by 117.47.248.208 above could be applied to n=10 rather than 18 so A ends up either with 3 even numbers and an odd number or two even numbers and two odd numbers divisible by 3. And yet someone above said the start number can be chosen so A wins with n=10. Dmcq (talk) 11:22, 19 July 2010 (UTC)

With n=10 each player gets to cross off 4, so A should choose the numbers {4, 5, 6, 7, 8, 9, 10, 11, 12, 13} and cross off {6, 8, 10, 12}. (Starting at 4 and crossing off evens larger than 2 is A's winning strategy for even n ≤ 10.) The strategy I described above for B to win does not work for n = 10 because there will be only 5 evens and as few as 1 odd multiple of three, leaving as many as 4 numbers divisible by neither 2 nor 3, so B cannot guarantee them crossed off prior to B's final move. This strategy requires an even n ≥ 12 = 6 * 2, giving at least 2 odd multiples of three and thus at most n/2 - 2 numbers divisible by neither 2 nor 3 compared with n/2 -1 moves for B. -- 110.49.193.24 (talk) 11:46, 19 July 2010 (UTC)

Sorry yes I miscounted, but it should work for 12 or more so that's the problem done and dusted. Dmcq (talk) 11:55, 19 July 2010 (UTC)

Just to summarise the answer to the OP's question: A has a winning strategy for all n except 12, 14, 16 and 18, and if B choses one of these then he should be "generous" and allow B to go first. Dbfirs 12:17, 19 July 2010 (UTC)