221–225 of 225 posts
Let's do a full circle. It all began with replacing frequent occurrence of 2π in calls of sin and cos functions with τ. This post suggests an optimisation by getting rid of τ by getting rid of radians. That way one can get rid of frequent and adjacent radians to degrees conversions and back. I say, let's get rid of sin and cos itself ! Of course I am being over the top here. However, if you represent angle not as a s…
Earlier quoted context omitted.
Writing full articles takes time and effort. But the effort is cumulative, so these stub articles are really just the start. Some of the comment you made here would definitely improve the article. You are always welcome to edit and improve Wikipedia. I mean this literally and sincerely, it is one of the few places on the internet where you might benefit from posting.
it is quite telling that wikipedia has pages upon pages documenting pokemon, but relatively limited context about maths or science, beyond what's in textbooks.
That can be seen as a feature: cos(angRad) will never return zero, avoiding edge cases, and same with sin(angRad) if argument is not zero.
Earlier quoted context omitted.
> I miss strict, deterministic unsigned addition overflow. In many modern languages, all kinds of verbose hoops are required to get this behavior and there's a chance it will generate terrible machine code. Most modern (post-2000) languages actually handle this perfectly fine. They have both signed and unsigned types, with exact bit widths and fully specified semantics, which generally match what the hardware is nati…
Go read K&R 1ed, squirt.
Earlier quoted context omitted.
Please look at the link where context is clear here. Floating point has limited precision and the complete inability to exactly represent some numbers . Example, this equality check is false: 0.1 + 0.2 == 0.3 Because the last bits of a floating point number, after any practical chain of operations, is practically random, do to errors from limited precision. Yes you can always know what the result will exactly be for…
Your problem only occurs when you try to naively transport equality of real numbers into equality of floating point numbers. https://www.netlib.org/fp/dtoa.c is how eg CPython parses literals like 0.3 into floating point numbers and how it converts floating point numbers back to strings. Lo and behold: these algorithm compare floating point numbers for equality, and would break catastrophically, if the compiler were…
This is not a naivety problem, it's as I said, that floating point numbers cannot represent some numbers. In practical use, we see this as a precision problem, thus requiring tolerances.
Yes, that discussion is precisely what I'm talking about. That tolerance is required because the bits below the tolerance are not stable. They will practically be, after some practical operations, random which is why you need to ignore them. As I said, yes you will know what those meaningless lower bits will be, at any point in time, if you know the algs, which is why I said "considered to be" and "practical".
And yes, old code will produce the same numbers as new code, if the same hardware/libraries/implementations are used. But, since even the order of operation will change the lower bits, due to precision limits. This will usually NOT be true across libraries. If you're using hardware sin/cos, then it will not be true even if the same library is used, since different platforms can use different implementations/approximations of hardware sin/cos. This is all fine, because if you're actually doing this type of work, the fact that floating point numbers have limited precision, therefore requiring a tolerance for comparison, is well understood (see your discussion link).
Cheers!