Implement Tensor struct

[siliconlad]

No description provided.

[siliconlad]

@CameronMatthew can you have a look and see if this is heading in the right direction.

Very rough around the edges (can you flatten an n-dimensional tensor in your head?), but that can be patched up with refinements to the API and maybe some additional macros.

Also code is a bit of a mess (wth is iters.rs) but gotta start somewhere

[CameronMatthew]

Definitely along the right lines! This is very nice. One or two places you can make your life easier. Would also like to talk about reusing some of this for Static tensors

[Dougal-s]

I'm very impressed by how quickly you managed to put this together!

[siliconlad]

I have restructured the code to have some of the features that we want. NamelyDynamicStorage which abstracts away the memory mapping of the tensor. I have also tweaked some of the interfaces for the methods as mentioned above (e.g. returning Result in various places).

I'm going to press ahead with some further restructurings:

• Create dedicated Vector and Matrix types which support some extra methods
• Create a distinction between int and float Tensors (to hopefully support pow)

I'm ignoring the specific implementations of the methods for now because they work (even if they are over-complicated). I will revisit them at the end and tidy them up as well as implement any of the other missing functionality.

[siliconlad]

Would be good to have another review of the code written so far. I've implemented most of the methods outlined in #1 so far (missing more of the advanced features). Before I add any more, would like to get some feedback on the structure of everything. The way I've done it seems to work, but there's a fair bit of duplication. Perhaps there's a better way.

Largely ignore the code within the methods for now. A lot of it needs to be looked at and refactored (unless you want to suggest a way to refactor it). They do get the job done though so 🤷 (I've never had more tests than I have for this repository I don't think ahaha).

@CameronMatthew @Dougal-s

[CameronMatthew]

I had a quick look and seems fine. I think we should just merge this asap now.

For the following reasons...

• Something "imperfect" is much better than nothing.
• This PR is getting too large to review properly.
• While this remains on a dev branch, the work you do on it is so broadly scoped that it is impossible for others to contribute without risking massive merge conflicts.
• Merging will allow us to create small, self-contained issues that we can all pick up, work on and review easily.

TL;DR Ship it 🚢!

[siliconlad]

Sounds good to me.

[CameronMatthew]

LGTM!