-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: all: quaternions #19813
Comments
CL https://golang.org/cl/39217 mentions this issue. |
CL https://golang.org/cl/39218 mentions this issue. |
CL https://golang.org/cl/39221 mentions this issue. |
CL https://golang.org/cl/39222 mentions this issue. |
CL https://golang.org/cl/39219 mentions this issue. |
CL https://golang.org/cl/39215 mentions this issue. |
CL https://golang.org/cl/39214 mentions this issue. |
CL https://golang.org/cl/39216 mentions this issue. |
CL https://golang.org/cl/39220 mentions this issue. |
CL https://golang.org/cl/39213 mentions this issue. |
For those interested, the language spec change is: https://go-review.googlesource.com/c/39213/ |
Thanks for taking the time work out the implementation consequences. I know this is blocking a team at Google, but I do wonder if maybe we should leave this for Go 2, for consistency with the handling of other recent language change proposals. Is it possible we can patch this into Google's toolchain for now, and wait for Go 2? |
I think so. I see two significant technical disadvantages to that approach though:
|
Want to pick up the torch on int128, int256, and up? Think how impressive it would be to have added an infinite number of built-in types to the language. Plus a built-in type for crypto keys! |
Best Buganizer link ever. |
@dorian That's a good point. Perhaps we should instead add direct support for Cayley-Dickson construction. For example, if we extend the grammar for type literals to allow call-like syntax:
then we can add a new predeclared
(We can't simply add a new |
@mdempsky If octonions are introduced, since octonions are non-associative, multiplications of more than two octonions, e.g. |
It seems if Go wants to add quaternions, it would be best to solve the more general "problem" of basic numeric types. Real numbers are the most commonly implemented, followed by complex numbers, which are both already in Go. After that though, quaternions are useful for geometric rotation, but there are more numeric types, such as dual numbers (and hyper-dual numbers) which are useful for automatic differentiation, and so come up in optimization and machine learning. Quaternions can be implemented at the package level, albeit with less nice syntax. This is the cost of no operator overloading. |
Note that |
@mdempsky: I do not think the Cayley-Dickinson construction is general enough. In my opinion, what would be really useful is to add versors and multiversors and have full support for geometric algebra in the language. Then, not only we won't need quaternions, but neither complex numbers, and we will be able to easily represent vectors, areas and volumes in a natural way too, and even higher-dimensional entities. So, I propose that we define a new kind of versor types float64.N (and float32.N), where N is a binary number that indicates the basis, such that the active bits of X correspond to the product of basis vectors. For example, for a 3D space:
The product of two versors gives a new one following the geometric product rules, such that if V and W are basis vectors (ie. they only have one active bit), then:
Notice that this product is not commutative. The product of other versors follows from this definition. For example, to calculate the product of the bivector float64.11(1) by itself:
Two or more versors can be combined in a multiversor, such that for example float64.X.Y has two values, that can be extracted with .X and .Y, float64.X.Y.Z would contain three values, and so on. To work in 2D and 3D spaces we could do:
Products of multiversors are also resolved following the geometric product, ie. assuming that a multiversor is a sum of versors and applying the distributive property. eg:
A smart enough compiler could optimize quite well how to store and multiply different kinds of multiversors. Later, this could be extended with a general multiversor type float64.* and adding support for other kind of basis for which |
April 1 is over. |
You got me. |
Italian mathematician here. Adding support to builtin quaternions (i mean something like Consider it seriously, it is not a joke. |
@fibo Why do you think they need to be builtin? Almost everything about this proposal can be done without any dedicated language or standard library support. |
For example I am following Golang before it went 1.0, then recently I started using it to implement the Apollonian Gasket geometry and generate fractal images. Other than the power of calculations (read concurrency), I was attracted by the sintax like Having something similar for quaternions, instead of a third party package, I mean, enter the playground and start doing quaternion calculations out of the box, could attract many people studyng robotics and physics. Also note that, since Smale (in my opinion the greatest USA mathematician) classified all manifolds for dimension >= 5, and dimension = 4 is still an open field of research, as well as other beasts like the 120-cell, and the Legendre theorem among others, having builtin quaternion support is something really exciting. It is true there are few quaternion golang packages on github, I think that builtin syntax and support would be a real boost for the adoption of Golang in many science fields that use quaternion, i.e. math, physics and robotics for sure. As a mathematician I appreciated also a lot that there are many complex functions available in
implementing quaternion, the name is in honour of Sir Hamilton of course |
This proposal extends the Go programming language to include quaternions, a hypercomplex noncommutative division algebra that generalizes the complex numbers to four dimensions. They're particularly useful for representing spatial rotations, such as in 3D graphics.
Quaternions are generally represented in the form a + bi + cj + dk, where a, b, c, and d are real numbers, and i, j, and k are the fundamental imaginary units satisfying i2 = j2 = k2 = ijk = -1.
Concretely, this proposal changes the language as follows:
j
andk
suffixes.quaternion128
andquaternion256
(and predeclares them).+
and-
operators and the binary*
operator to apply to quaternions.quaternion
built-in function to construct quaternions from four real numbers.real
andimag
built-in functions to also return the real and i-imaginary parts of quaternions.jmag
andkmag
built-in functions to return the j- and k-imaginary parts of quaternions.Also, it implies corresponding support and extensions to standard library packages.
The text was updated successfully, but these errors were encountered: