On Saturday, March 8, 2014 3:35:14 PM UTC-6, Andrew Barnert wrote:
It looks like you're trying to emulate a pocket calculator here. The question is, why are you accepting floats in the first place if that's your goal?
That's fair... if it were me, or you, I wouldn't. In fact, if it were just me, or just you,
I don't think any of us would be talking about this--- I wouldn't even have brought it up.
I am advocating for people--- I am going to say, " if you want just a tad more than double
just to check things out, please use the decimal module and import pdeclib. These folks
are what Guido called newbies, I'll call them naive users, and these folks are using
a calculator (like the TI89) and they will be prone to keying in sqrt(2.345) /
So your goal is that if someone is a TI89 expert but a Python novice, they can easily port a function from their TI89 to Python (or maybe even write a TI89-like desktop calculator program) with your library? That doesn't seem too unreasonable of a goal.
The problem is that you're not quite achieving it. If you want a 16-digit-display calculator, using a mix of float64 values and decimals that expand as needed for intermediates is not equivalent to using 20-digit fixed decimals. So they will not get the same results for many functions that they port. And if they really care about having more than a few digits of precision, they either care about these differences, or really really should care. Hiding them in many but not all cases doesn't seem to be doing them a service.
A simpler solution might be to just only support a fixed precision of, say, 8 digits. Then you can handle float inputs without running into that one-too-few 3's problem you mentioned. But obviously this isn't great either--you'd just end up with users who say "your library is perfect for me, except that I need 10 digits, not 8"...