Talk:Count the coins

Python vs D

The previous claim of Python/psycho being faster than D was a little curious. Could it be because the D code uses bigint throughout, while python will only switch to bigint when the values exceed 64 bits? If so, that's another reason to not make speed comparisons. --Ledrug 07:22, 30 October 2011 (UTC)

why not? the only reason not to make such comparisons it to avoid getting into a debate about it.

otherwise if one version is faster than another it is useful to know. even better would be though to also understand why. can the D version be rewritten easily to not use bignum for smaller values? if not then that is an important point to understand when comparing languages. people claim that C is faster, (i don't know about D) but they forget to explain that in order to get the faster speed you also have to know how to take advantage of that. so if the comparison shows that python is faster for naive code then i think that is something useful.--eMBee 09:25, 30 October 2011 (UTC)

that said, the python speed comparison involves psyco which is not a standard part of using python, the same comment could be made about many examples. therefore i am not sure if such comments are adding any value unless the task involves solving a problem efficiently.--eMBee 09:38, 30 October 2011 (UTC)

> why not? the only reason not to make such comparisons it to avoid getting into a debate about it.

Well, now you are in a debate about it.

One definitely can write D code where bignum is only used when necessary, though obviously it won't be as convenient as in languages which can manage that by itself as in Python. But you don't see people making claims like "coding in language A is about 2.7 times easier than in language B", only the speed comparisons, which is misleading by not telling the whole story. Also, unless you are confident both examples are well written within the bounds of reasonable effort, such comment doesn't really tell much. --Ledrug 14:24, 30 October 2011 (UTC)

Python vs C

The second Python version gives: 99341140660285639188927260001

For: make_change(1000000, [1,2,5,10,20,50,100,200])

While the C version gives: 8.033207543e+24

That means: 8033207542650321391101281

Turns out I forgot to add the high 8 bytes for the 128-bit addition. Surprising how it didn't bork until the very last one. --Ledrug 02:31, 31 October 2011 (UTC)