> Remember, because π is irrational, we cannot actually call sin or cos on > any rational multiple of π. We can only operate on multiples of pi, > which is *close to* but not the same as π. That's why it is okay that > tan(pi/2) returns a huge number instead of infinity or NAN. That's > because the input is every so slightly smaller than π/2. That's exactly > the behaviour you want when x is ever so slightly smaller than π/2.
This would basically be the reason for a PiMultiple class - you can special case it. You'd know sin(PiMultiple(0.5)) == 0. You'd know cos(PiMultiple(0.5)) == -1 and tan(PiMultiple(0.5)) == nan. This could let you remember as much angles as possible into multiples of pi, and as long as you're in multiples of pi, you're exact. PiMultiple(Fraction(1, 6)) would be exact and could give the right sin() and cos() behaviour. And because it'd be a numeric type, you could still use it with all other numeric types and add/multiply etc it. When you add and subtract it with another numeric type, it'd lose the special status, but even with multiples and divisions you can preserve it's specialness. And if it gets weird values, you can always fall back on converting it to a float, therefore never giving worse results. It also gives a reason -against- degrees. if you have PiMultiple or TauMultiple, it's rather easy to give common angles, and students can learn to properly learn radians for angles as they should.(because, lets be honest, they're objectively better measures of angles than degrees, or even *shiver* grads. ) We SHOULD make it easy to code exact and the right way, and I think a PiMultiple class could help that a lot. That said, it does need a better name. _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
