On 07/07/2013 01:30 AM, Dave Angel wrote:
On 07/06/2013 10:40 PM, Jim Mooney wrote:
On 6 July 2013 19:09, Dave Angel <[email protected]> wrote:
<SNIP>
If you'd like, I'll post my full version, changed as little as
possible from
That would be helpful. The corrections are already four times the size
of the program, and at least three pots of coffee ;')
I hope this is useful. There are lots more places where I might clean
things up, but I wanted to make it as close to yours as possible, so you
could reasonably diff the two.
Sorry to do this in two parts, but there are a few things I know I added
to that code since the last discussion online. (There are undoubtedly
others, which is why I suggest you do a diff with your own code, and
study the reasons for each difference)
As Steve suggested, I added a function int_name() which does what Steven
suggested. It encapsulates your entire algorithm, without confusing
with input or output schemes. It also has the same interface as the
int2word() function I found elsewhere.
Main thing is that I found another implementation which I can compare
yours to. I didn't copy that code here, because I don't want to
contaminate yours with scraps of his. And I didn't read it either,
except enough to tell that he has a single useful function that takes an
int (long) and returns a string representing the word version of the number.
If you look at compare_em(), you'll see that I had to distort both your
function and the the int2word() function to make them mostly match up.
The other author does not use hyphens or commas in the words. He ends
each string with a blank. And he neglected to handle zero.
He also is buggy beyond a nonillion-1. So I used this to test your code
within those parameters. It won't catch a problem with a very high
number, nor one with misplaced or extra commas or dashes. But
otherwise, it looks like you two have come very close.
I suspect with a little more searching, I could find a different
implementation that's closer to yours.
BTW, this approach of having two implementations and comparing them is
very useful, even if there isn't one out on the net somewhere. When I
was microcoding add, subtract, multiply, ... trig, log, ... I also
wrote a very crude high precision math package. The slow one was done
in a high level language, and very brute force. Then I systematically
pitted the two sets of functions against each other, looking for edge
cases and bugs. Some things, like the trig functions, I couldn't expect
to be precisely the same. (I used things like taylor series for the
brute force ones, but with intermediate results carried out to many more
places than the accuracy I was actually comparing.) That was in about 1975.
--
DaveA
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
