Back to thinking n-dimensional

So n-dimensionality turns out to be totally possible (within the range of acceptable performance) with some arrays and a loop unrolling compiler. I think GCC does so - atleast I hope. Well, since I was finally able to jump over my own shadow and understood that I just need to define some static values for the end and start points of the loop, I'm - again - thinking about how to them to work nicely. There is still this annoying issue that you will need some kind of for-loop do to all these things. I tried to a way to exploy my classes I used for generic array filling, but since nested classes can't access the upper object propery (logically, where the fuck would they know the addresses from), it's getting quite difficult for me to come up with some even more comftable ways to create new functions. However, I shouldn't complain. The current solution is far better than anything else I ever create for making n-dimensional objects. Hm, maybe I should write seperate n-dimensional classes for standard operator overloading, so that I only need to write the rather generic one values/many values functions for +,-,*,/ etc? Hm... hope that is possible... Let's see. I have just too many structures I want to create operators for, I don't to always repeat myself and type the same thing one million times. Why do I even this when it's possible to do so. It's marginally less work for just taking three dimensions and listing all commands individually. Well played, weaker self.

Besides this, I forget about ',' operator use. This maybe interesting for defining coordinate pairs n-dimensionally. Don't how effecient this could become, but it's definitely a cooler notation to just write p=x,y,z instead of p.set(x,y,z) or so. I'm kind of set of writing function names for stuff I use so often.

No comments: