[Tutor] please return flys in ointment

Dave Angel davea at davea.name
Sun Jul 7 07:52:58 CEST 2013


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 <davea at davea.name> 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



More information about the Tutor mailing list