3.10.2011

New concept

Today I had a lenghty train ride and a lot of time to think and test the best possible ideas and concepts for my operator system. I noticed how inconvient and limiting it can become to not having an implicitely parameterized operator. For example, logic operators! If you take the references A and B, you you'd normally the define the return type as A and for a logic operator as bool. So if you have your class imitating operator behaviour, you'll need to implement a new kind of operator returning a bool or bool-alike value cause the other operator functions always return type A for compatibility. That's just one side effect, but one generating a very, very inconvient to program interface (which's also annoying to use - wouldn't you prefer only two almost equal operators instead of three, or even four different ones?). The second side affect I noticed is that you maybe have division and modulo, which are basically the same operations but you can only get one value back in C/C++, making it impossible to reduce them from one to two operations. You'll never really able to change that except using inline assembler maybe - it's a just an example that may be performance-critical for string numbers, custom data types and others. So using normale operators you need to make two operations out of it or simply writing your own functions. My plan now is to create a set of functions with in, out and in/out reference parameters to always have as many implicitely parameterized ouput variables as possible. I wasn't quite if it's harder for the compiler to optimize then or not, so I did a quick and not that covering comparison of some more and less lenghty terms requiring anonymous or explicitly defined temporary variables. Both assembler outputs are exactly the same, so I really don't need to worry about performance at all (as long as optimizing is turned on of course). It's really basic and simply stuff essentially involving inline functions only, but every function is inside a class you can parameterize but still having the same function call layout. This gives an interesting flexibility in terms of chaining and per-element operations on storage classes (but I think I repeated that often enough the last posts to not again write about... I'm getting tired of it...). It's a bit like using a modular synthesizer: you have your modules, filters, etc. and a variable is a wire or generator. So in order to make stuff happen, you can create programs this way, essentially ending up with some kind of "assembler-like" syntax of, well, "set A to B" or so. Yeah, that sounds really cheap and simple, but it's only the most basic part of it. You still need to provide a full class interface for custom numerical types, operator functions for you storage classes etc... However, stuff's going more and more interesting, so I might create some very special case modules to than operations like you'd chain them with normal mathematical operators. Dunno how to generalize that, but I guess I can do that without any real problems. However, the input/output/io idea is the most final one I think. Theoretically no overhead, more possibilities than by simply using such one-directional C/C++ opertors and as much custom shit as you want.

Yeah, not much to say about that. But I can think of easing implementations for synthesizer formulas, image renderers etc. It's just as cool as the stuff I can come up with it, so nothing is won by just making available as concept. When I've finished everything to make template-generated code as quick as possible to design, I'll go back from where I came - applying it to n-dimensional vectors and then arrays.

No comments: