[Python-Dev] calculator module

Gareth McCaughan gmccaughan at synaptics-uk.com
Wed Mar 10 05:16:33 EST 2004


On Wednesday 2004-03-10 at 07:26, Raymond Hettinger wrote:

> I was thinking that if a student's calculator can do something, then
> Python ought to handle most of the same tasks right out of the box.
..
> My thought is to create a pure python module with "pretty good"
> implementations of things found on low to mid-range calculators like my
> personal favorite, the hp32sII student scientific calculator.  It offers
> a reasonably small but useful set of functions without any attempt to
> comprehensively cover a given category.  For instance, there is a
> single, simple solver -- and if it can't handle your function, then you
> go to MatLab or somesuch.

Sounds good to me, but
  - would you propose a single "calculator" module, or distributing
    these things among different modules, or what?
  - I don't think I agree with your suggestion that, e.g., a
    9-place approximation is sufficient for special functions
    like gamma. It would be a shame to set a precedent for putting
    known sloppy code into the Python standard library, and users
    may not appreciate that the results are very inaccurate. (In
    comparison with the precision theoretically available with
    Python's floats, that is.)

> Here are a few that may be worthy of a module:
> * Combinations, permutations, and factorial (with a full gamma function)
> * Two variable linear regression
> * Hyperbolic trig

Yes to all these. (Factorials should be exact for integer
inputs, using Python longs for the result where appropriate.)

> * % and %chg

Is there any way of spelling these that's actually shorter
and easier to remember than writing the calculation out
explicitly?

> * A simple integrator (adaptive trapezoidal method I think)
> * A simple solver, given f(x)==c and hi/low bounds, solve for x if
>   possible.  (works like Goal Seek in Excel)

If we have that then there should be a minimizer and maximizer too.
In the interests of ease of use, that should be a "minimize"
function and a "maximize" function, not a single "optimize" that
takes a flag. Of course they could share their implementation
behind the scenes.

Perhaps we also a function for calculating derivatives?

> * Polar/Rectangular coordinate conversions
> * A handfull of metric/English conversions (these could be skipped)

And should be :-). It might be neat, though, to have a "units"
module that understands quantities with units attached and has
a big list of unit values. Like the "units" program on Unix,
only (of course) better.

> * Simple fraction implementation with a choice a maximum denominator or
>   some multiple of a fixed denominator.

Why not one with unlimited denominator? We could add a
function that converts any number to a rational with a
set maximum denominator, which could also be used to
round a rational to have a smaller denominator. This
doesn't look to me as if it belongs in the same module
as the other things here.

> Another variant of the calculator also offers:
> * simple matrix functions up to 3x3 (addition, multiplication, inverse,
>   determinant)
> * cross-product and dot product for 3 element vectors (x,y,z
>   coordinates).

These would be handy to have, though presumably we would
have them for arbitrary-length vectors. But then, my opinion
is that Numeric should be made a part of Python. :-)

> To these, the HP12C financial calculator adds:
> * solve for missing variable in (n i% pv pmt fv)
> * internal rate of return and net present value for a stream of cash
>   flows

I suspect things like this belong in a special finance module,
which should have a lot of other stuff in it too. (I don't
know what other stuff.)

> Though not present on the calculator, I could also see the inclusion of
> probability distributions to capture what students normally have to look
> up in tables and then can't find when they need it.  That is likely why
> MS Excel includes these functions but excludes so many others.

I'd be in favour of this.

> By "pretty good" implementation, I mean that the implementations should
> remain as straight-forward as possible and neither promise, nor get in a
> snit about being accurate to the last place (i.e. a 9 place
> approximation of gamma would be considered fine).

Straightforward, yes. Gratuitously inaccurate, no. If this is
replacing a pocket calculator, then I think the right tradeoff
is with speed rather than accuracy.

-- 
g





More information about the Python-Dev mailing list