Dick Moores wrote:
> I'm baaaack!
>
> I kept getting ideas for what I (and some of you) thought was a
> finished yen-USD.py. And some of the good advice I got was to move on
> to other things. I did for a while, but I kept thinking up new
> revisions. The script has more than doubled in length. I'd previously
> posted v4 at < http://www.rcblue.com/Python/yen-USD-v3.txt>.
>
> Here's v10: < http://www.rcblue.com/Python/yen-USD-v10.txt>
>
> New functions:
> again()
> divide2StringDecimals()
> multiply2StringDecimals()
> roundNumber() -- replaced setPrecision()
> printVariablesNotChanging()
> formatNumber()
> removeCommasFromNumbers()
>
> rather radically revised function:
> again() -- offers several more choices
>
> The most important change is that because I realized I wanted the
> program to be a general solution and give accurate answers for even
> very large amounts of Yen or USD, I decided to operate with (number)
> strings only, except when necessary in getRate() and getAmount() to
> error check user inputs. Those floats are not used in the
> calculations of Yen or USD.
>
> The most difficult function for me to write was roundNumber(), which
> of course couldn't rely on the use of the built-in round() or the
> formatting of strings (see the line "format = "%." + str(precision) +
> 'f'" in setPrecision() in v3). Lack of experience with the slicing
> of lists caused many headaches. I didn't succeed in debugging until I
> put in print statements wherever a value changes, and trying many
> different integer strings and places (the arguments of
> roundNumber()). A good lesson, I think.
>
>
A few notes:
1. in your roundNumber function, you define a function incrementDigit.
I'm pretty sure that this function is destroyed and recreated every time
you call the function roundNumber.
This applies to divide2stringdecimals and other functions as well.
Is this what you want?
I don't understand. What's another way? And what's the downside of the way I've done it? How do you keep from causing all that destruction and recreation? And what's bad about it?
2. in your remove commas from numbers function, you could simplify it:
#from
a = n.split(',')
n = ''.join(a)
return n
#to
return ''.join(a.split(','))
personally I like this more.
Yes, I do too.
> I hope some of the Tutors will take a look at the new functions,
> especially roundNumber().
> Did I just reinvent the wheel?
>
I'm pretty sure you could set up a Context in the decimal module that
will round and keep the precision where you specify.
So if this is true, I guess you did reinvent the wheel.
Yes, I jut got the knew Python for Dummies, and see that I could have greatly shortened roundNumber() if I'd used the decimal module more. I had thought I KNEW that you couldn't multiply or divide decimal numbers directly! I also didn't realize that I could use it for rounding. I'll rewrite roundNumber(), divide2StringDecimals, and multiply2StringDecimals. But I'm still shaky with the decimal module. Don't really understand what you wrote below about a custom context. But that's OK. I'll get it, I think, by just experimenting.
> Should it be broken up into more sub-functions (there's only one now)?
> It works, but is it Pythonic? Etc.
>
I think you need to settle on a naming convention so your code's more
readable.
Your variables are sometimes named aRandomVariable, with the start of
each new word capitalized,
then in other places (like the variable 'slen' in numberCommas ->
intCommas) they're not.
Also, it's easier to differentiate between functions and variables if
they're named a different way.
Like a_variable_name = someFunction()
That's just my opinion, of course, and you can do whatever you want :)
No, I'll take your advice. But I hate to type underscores, so is there another style I could use for functions that would be different from the aRandomVariable style I like for variables? And intCommas() with its "slen"--I've had that around a long time. Should be more critical of my old stuff. I suppose I'll rename slen to lenS.
But since writing the above I remembered that Python For Dummies references PEP 8, "Style Guide for Python Code" (< http://www.python.org/dev/peps/pep-0008/>), in which I find
Function Names Function names should be lowercase, with words separated by underscores as necessary to improve readability.
mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.So I guess I should start learning to type underscores accurately.
Also, I've seen that you call the variable you store the split value in
'splt'
Ugly, isn't it. Thanks.
Now while this approach may have its uses, it makes it more difficult to
understand
what's going on in your code (for me).
If I were writing this software I might misread (or mistype!) split
instead of splt, and not be able to figure out
what the problem was while I was debugging, whereas if the variable were
named 'num_str' or something,
there's a smaller chance of confusion.
Thanks. Point well-taken.
And lastly :)
props on the commenting. They were helpful and informative.
Thanks for that feedback. I worked at the commenting.
> I'm also curious about multiply2StringDecimals() and divide2StringDecimals().
> Again, am I reinventing the wheel with these?
> Is there a simpler way to multiply and divide big decimals with precision?
>
Well, the decimal module implements division and multiplication of
decimal data type variables...
Eg.
#code:
context = decimal.Context() #replace this line with your customized
context...
decimal.setcontext(context)
d= decimal.Decimal('6')
e = decimal.Decimal('3')
print d/e
#output:
2
Again, for the precision and such that you'll want for this,
look into making a custom context.
Thanks very much, Luke.
Dick
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
