On 9/9/06, kirby urner <[EMAIL PROTECTED]> wrote: > On 9/9/06, Arthur <[EMAIL PROTECTED]> 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 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig