I suppose its too much to ask that floats work in 2021 +/- however many years lost.

>>> math.cos(math.pi)
-1.0
>>> math.sin(math.pi)
1.2246467991473532e-16

what I don't get is this would work on a calculator.

Calculators have tables.

@c3r38r170 I've always wondered how that worked. Do they just average values somehow when they get a small digit ? and what does math.sin do then ? use some approximation function one would find in calc 2 who's name i can't remember ? LOL

so then the question is why don't we have tables :P

I wonder if cheech and chong are dead now, along with walken, they were ancient in 2020.

if they'd stop stealing my things i wouldn't fall victim to what they did to me.

@c3r38r170: Symbolic stuff is also often used.

Check out CORDIC. And yes, tables with better approximations than just "averaging" - you would probably use a truncated polynomial series or a difference method or something.

Also calulators do rounding... That number is to e-16. Might as well be 0

@AvatarOfKaine Floats have always worked exactly the way they're supposed to. They give you precision up to N places after the most significant digit, and it's your job as a developer to keep that in mind and decide how to handle it for your particular use case. What you have to understand is that you're looking at the exact value as stored in memory, while calculators (and all decent applications) display numbers using a mechanism like "printf", which rounds the number AFTER converting it to target numeric system, and provides less precision than the actual value stored in the memory (so that numer would still be displayed as 0).

If you need exact precision, there are mechanisms to do it, but they come at significant memory and performance cost, so they're only ever used where that's absolutely necessary, e.g. in finance where even huge numbers must be precise to a cent, and in physics where "chaos effect" is expected to be a problem.

@hitko yes yes i know. its still a cause for complaint when a value that should be 0 ends up being a positive value as above to the order 10^-16

@Hazarth do they really ? hmm

@Hazarth only thing about that is because often trig is used for angular things, one could say the smallest order would disrupt a calculation on a long enough leg length

This is a feature, not a bug. math.pi isn't exact, the value you get is the real sin value of math.pi rounded to the nearest float.

You can actually test this. sin has the property that, for a value y, which is pi/2<y<pi*3/2 && y!=pi, x will be closer to pi than y when applying this formula: x=y+sin(y)

Use a calculator with a better precision or do it digit by digit, add the value of math.pi and the result you get from math.sin(math.pi). The result is closer to pi than math.pi, the resulting value is accurate to about 32 digits, while math.pi is only accurate to about 16 digits.

@happygimp0 however sin(pi) is a hard point. a calculator returns the right result, thats my point.
but yeah I could see that given pi is a repeating decimal calculation that is approximated, however it doesnt make sense then that cos(pi) gives the right result and sin(pi) gives me a tiny, but not SOOO tiny positive result.

@happygimp0 propagation of mathematical error can make that tiny error really large where considering things like distance. even if you're considering distance on a very very small scale in relation to other distances in the same very very small scale.

@AvatarOfKaine I guess that a float can't represent math.cos(math.pi) any better than with -1.

@AvatarOfKaine It would be an error to return anything different than it does now.

Which value do you think would be better?

@happygimp0 sorry got those mixed up.

I meant the math.sin value. which approaches 0 but is not 0.

@happygimp0 1x10-16 is pretty small, but a calculator would return 0.

.... are you sure you didn't misread rather than me mistype.... ...

@AvatarOfKaine math.pi is exactly 0x3.243F6A8885A3 . sin(0x3.243F6A8885A3) is not 0 but approximately 0x0.00000000000008D313198A2E03707344A4093821B7176CFEB or 1.2246467991473531772260659322749979970e-16. The nearest possible float is 1.2246467991473532e-16, therefore 1.2246467991473532e-16 is the correct result of math.sin(math.pi)

@happygimp0 where did the code you posted go ? how are you deriving that value ?

on the unit circle pi = 180 degrees, its x value is 1, its y value is 0

so sin(pi) = 0
cos(pi) = 1

so i the case of floating point error, which is built in error if it ends up being some awful positive value, that is wrong is my point.

hey want a fun exercise.

type numpy.linspace(0,100,20) and see if you agree with the results.

its shit like this which I find insensible.