Closed gingerBill closed 5 years ago
Hell yes. A couple questions though:
It seems these would be compile-time types, analogous to multi-dimensional arrays. How would this relate to slices, then? Would there be a runtime equivalent?
Why is it necessary to specify the rank explicitly, when it could be inferred from the number of dimension arguments provided?
Is there a specific reason to use the tensor
keyword rather than just extending arrays to multiple dimensions when there is more than one comma-delineated dimension argument?
This is an excellent proposal, and I'm pretty excited given that I'm too shit at math to implement a tensor library myself.
Do we need to have kronecker_delta, levi_civita, christoffel, weyl
as built-in procedures, or couldn't we have them in a core:tensor
library? The less built-ins the better afterall.
@ThisDrunkDane I think the idea is that the tensors would be implemented as array equivalents - i.e. compile-time sized - therefore you would want these procedures to work at compile-time. If there is a runtime equivalent as per my first question, something like a "tensor slice", then I would expect those functions to also be implemented in the core:tensor
library.
April Fool's Day has now ended. This proposal was a joke.
Noooooo
This proposal extends the Odin programming language to include tensors, a geometric object that maps in a multi-linear manner vectors, scalar, and other tensors to a resulting tensors. They would be very useful in many areas that require linear algebra, such as physics, engineering, and mathematics.
A common form of tensors are rank-2 tensors, also known as matrices.
Concretely, this proposal changes the language as follows:
+
and-
operators and the binary*
operator to apply to tensorstensor
kronecker_delta
,levi_civita
,christoffel
,weyl
.Also, it implies corresponding support and extension to support library packages.
Example syntax:
This is a partial proposal, conforming to The Proposal Process step 2.