[Edu-sig] The fate of raw_input() in Python 3000

[kirby urner]

On 9/9/06, kirby urner <kirby.urner at gmail.com> wrote:
> On 9/9/06, Arthur <ajsiegel at optonline.net> wrote:
>
> >  >import math
> >  >math.cos( 90 * math.degrees)
> >
> > It doesn't belong to you, it doesn't belong to Fuller, it ain't "gnu
> > math" because there ain't no such thing. Except to you and six guys in
> > some Mecca called Portland.

Doesn't belong in Python either.

What I *should* have written is:

import math
math.cos( math.radians (90) )

Maybe that's what you were objecting to (i.e. math.degrees is a
*function* -- plus it's radians I really wanted).

>>> from math import cos, radians
>>> target = cos ( radians( 90 ) )
>>> target
6.1230317691118863e-017

Almost 0 then (but not, because of floating point limitations).

Using a generator won't be more accurate unless we do the work to make
radians(90) more accurate as well, and that requires some humongous
pi.  We could use Ramanujan's Engine for that.

I'm thinking I need a trig module wherein everything is geared to work
in a high precision context, i.e. Decimals throughout.

I could set the context and have everything adjust accordingly.

There wouldn't have to be a "main()" to tie it all together.  You'd
have partial sum generators for sine, cosine, tangent.

This would help my precalculus students understand about precision and
the notion of limits, also about the limitations of floating point and
possible workarounds.

We'd also have that discussion about not pretending to more precision
than the problem allows,

e.g. if you're crunching empirical data and your measures are
plus/minus 1%, then all this high precision stuff is likely overkill
and shouldn't usually be used because misleading and/or wasteful of
time/energy.

Precision is relative to the application.

Kirby