201–210 of 225 posts
Earlier quoted context omitted.
> For graphics rendering Euler equation doesnt matter. Huh?? "Euler angles" are one of the most popular representations in computer graphics! The only other good alternative is quaternions, where as you say this also matters!
Euler angles have nothing to do with e^ix = cos x + i sin x. They are a completely different concept.
Earlier quoted context omitted.
It’s good to know you don’t want your house powered by AC power anymore. It’s a weird take, but you do you.
As I have already said, and I am an electronics engineer, the design of any electrical or electronic system, including anything that uses AC power, can be done faster and with less numerical errors, if instead of using complex exponentials one uses 2 other exponential functions: "2^x" and "1^x", with arguments and value domains as I have written above. Unfortunately, this requires the use of a custom library of trans…
Earlier quoted context omitted.
Why not e^{2 pi i x} = cos x + i sin x then? We already handle e^{2 pi/360 i x} = cos x + i sin x for x in degrees just fine. It's not that euler no longer holds, it's that you just have to be clear about what units[0] you use when comparing the explicitly angular/geometric cos and sin with the numeric exponential, and then deciding on a default numeric cos and sin/a default "unit" for angles. If we want to get real…
The problem is that angles in the complex plane are related to multiplication, which is related to exponentiation. When you multiply two complex numbers z1 and z2, their angles add: Arg(z1 z2) = Arg(z1) + Arg(z2). That carries into exponentiation: Arg(z^2) = 2 Arg(z). The exponent 2 has an interpretation as doubling the angle. In other words, e^2πix has an interpretation as working with angles. When you have that 2π…
> But on your right side, you have turns: the expression cos x + i sin x is literally saying that the point whose angle is x on the unit circle in the complex plane is the complex number .
I totally agree here, and that's purely geometric, regardless of what we express x in. We can talk in terms of abstract points without specific coordinates/embeddings in R.
> When you have that 2π in there, but not in the sin and cos expressions, you're using different angles for multiplication/exponentiation and for sin/cos.
This part I'm not following. When we talk about a scale, any purely universal identity like Arg(z^2) = 2 Arg(z) is going to hold regardless of the scale. I agree that the Arg stuff nicely motivates interpreting it as an angle, but don't see how it says anything at all about the scale in question. Like, we get an interpretation of e^2πix as working in angles from the Arg reasoning, but we don't get a scale for those angles from it, do we? We'd only get Arg if we impose a scale on Arg itself, right?
So if we take e^2πix at x=1/2 turn=1/2, we get e^πi=-1, which gets us Arg(-1)=1/2 turn=pi rads=180 degrees, and we can work from there, but I still don't see how it imposes a unique scale that we can say is still radians and thus incompatible with the RHS's scale of turns.
Earlier quoted context omitted.
It would sure be better if it had some concrete explanations and examples why vincenty is preferred. It's also barely any more computational load on modern computers so very little reason not to use it. Haversine is strongly deprecated in even short distance applications like planning a 35 km point to point licensed band radio microwave link, because you risk having both slightly the wrong distance and the azimuth fi…
I've actually implemented Haversine in a SQL query to find what can be summed up as "which of these moving things is closest to this thing right now". It's not the tidiest, and I had to ask someone better at SQL than I am to make it entirely work, but it looks like it is easier than doing Vincenty. I should try it, right? Edit: I also wonder what's to be gained by being accurate to nanometres over the surface of a fa…
The math is definitely not fine with turns, because your Euler formula e^ix = cos x + i sin x no longer holds. We can use a base other than e , namely B = e^2pi which around 535.4916. This doesn't have the nice e properties like d/dx e^x = e^x. The elegant fact that the base of the natural logarithm, which produces an exponential function that is its own derivative, also shows up as the basis for the above Euler's fo…
That formula as such has no importance at all, it is just a correspondence between different notations. What you really mean is that there are certain mathematical problems where the complex exponential function is useful and for the complex exponential it is more convenient to measure the real part in nepers and the imaginary part in radians (in order to have a simple formula for computing its derivative and its pri…
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…
My friend,
it's called a complex number. A unit complex number, to be specific.
>Recall rotation is a linear transformation with a matrix whose entries are in terms of sin and cosine.
That's what multiplication of complex numbers is.
Can't wait till people here rediscover that a 3D rotation matrix has an axis-angle representation whose composition is given by quaternion multiplication.
At that, children, is why learning mathematics is important.
Earlier quoted context omitted.
That formula as such has no importance at all, it is just a correspondence between different notations. What you really mean is that there are certain mathematical problems where the complex exponential function is useful and for the complex exponential it is more convenient to measure the real part in nepers and the imaginary part in radians (in order to have a simple formula for computing its derivative and its pri…
1^x = 1 for any complex x. So that library can be very simple and fast!
1^x is multi-valued, and like with all other multi-valued complex functions it is possible to select a branch of the function that is a proper function.
Defined correctly, the value of 1^x for any rational x is the corresponding smallest root of unity, and for irrational arguments it is defined by continuity.
Therefore 1^x rotates on the unit circle for increasing x.
The standard complex exponential and complex logarithm functions are defined exactly in the same way, because they are also multi-valued, so the same kind of equalities like yours would also be true for them.
With the correct definition, 1^x = 1 only for integer x, not for any x. As I have written above, the useful 1^x is defined only for real arguments, not for complex arguments. Only its values are complex numbers of unit modulus.
The math is definitely not fine with turns, because your Euler formula e^ix = cos x + i sin x no longer holds. We can use a base other than e , namely B = e^2pi which around 535.4916. This doesn't have the nice e properties like d/dx e^x = e^x. The elegant fact that the base of the natural logarithm, which produces an exponential function that is its own derivative, also shows up as the basis for the above Euler's fo…
Your argument is correct and I'm sure you're really smart and all that. However, Proportion of code where radians are used to represent rotation in 2D (i.e. turns): 99.9999% Proportion of code where radians are used to perform higher degree derivatives, symbolic computation, etc: 00.0001%
The use of the trigonometric functions with arguments in radians, which are unfortunately standard in most programming languages, wastes time and introduces unnecessary rounding errors at each function evaluation.
The functions with arguments in cycles perform exact argument reduction instead of approximate argument reduction, and which is also faster (omitting a multiplication with an approximate value).
Earlier quoted context omitted.
Oh yeah, in the era of ¼ circle trig tables (cos and maybe tan; inverse (arc) versions as needed) in ROM or Taylor/Maclaurin approximation (with fast integer division) when FPUs were rare. Such tables and tricks mostly fell by the wayside when the 80486DX, 68040, and N64 (VR4300) arrived and SIMD/MIMD systems followed. I miss strict, deterministic unsigned addition overflow. In many modern languages, all kinds of ver…
> 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…