2.10.2011

I got an idea during my interface designs related to number classes in general. Some time ago I wrote a number class giving you the possibility to to things like number::max(), number.abs(), number.sin() etc on single number object will type-specific commands and so on. It's pretty much just a fully compatible wrapper for standard datatypes in C++. I always wanted one - using C's constants for number lengths and functions in general in a bit ugly cause I'm a lazy bum always the function before the object. However, I noticed a bit of inconsistency: I have, for example, three abs function: one for applying it to the number. one for returning the abs value and the last for storing it inside another number you specified via call by reference. So I started to think about how to replace the three of them with just one all-purpose function. One note here: I always inline such small operations. So there is no real difference between returning a value or taking a reference and then setting it. In the end we always need a second variable to store the result. At first I though it'd be better to store the resulting value inside the number from which we called it. But then again - why apply a command to store it if we maybe need the value later? All in all, we need to make a copy before, so we have two unnecessary things we'd do then. I must admit that kind of hit me. Cause there is always a temporary value and we can't change it. Return value or reference or something different - we can't avoid it. Even if you manage to find a way so, it'd be useless cause most operations can't be done without storing avalue somewhere else. Think about it: you want to calculate the sinus of x and simultanously storing it in x without having a temporary variable? That won't work, cause everything you change x, you'd alter the result of the formula. Not to mention the steps between, a few variables (depending on the function's complexity) will always stay. So I'm sure it's totally useless to make something different than just returning the new value, our temporary variable (except you have something that'S bigger than a reference or pointer - then you better take a references as parameter to store it there). One may say that is normal and obvious. But well, it's not: Do you know how many temporary variables your resulting code has in reality? If you have some experience in Assembler or a similar language, then you'll know that it's extremely necessary to create temporary variables. But I'm kind of intrigued by the idea of using just a few available variables to do all operations. That's what I'm currently into and I begin to unfold some parts of the system I work and program with everyday. And it's for me to know what creates more temporary variables and what not. At the moment, I prefer making rather atomic operations to a) have more control about when there will be new temporary variables and b) to get a better understanding of how formulas work in essence and how microoptimize as soon as possible (without having to worry about it later). Got some doubts some minutes ago, but since I can only control how many operations I do and how to indirectly avoid temporary variables, this is a good approach for keeping it stupid and simple. So inline here we go - full throttle function return. This makes my live much easier as I can stick with one function instead of a million.

It's good to keep this in mind from time to time. I did so much memory work, I never really payed attention to the details. But it's good to I was able to take the time. This way I keep up arguing with those annoying lecturers thinking they know everything better - even if their code is running slower than mine.

Also, I hate people who insist on floating point accuracy. Due an assignment I was so annoyed by this one guy who wanted to do massively heavy operations with floating point numbers. I used integers instead and the result showed quite well. With his double floating point approach it wouldn't be faster, never ever. Due to that I did some research in fixed point numbers. My experience tells my that's it's in most cases more usefull to have integers or integer-base operation than with floating points. For example, in graphics programming I really don't need the super high dynamic range of floating points. I only need integers (even for HDR), so that stuck in my head. Though I wonder if I should really go that direction. In my case, I've always used floating point numbers for color operations. You don't need to rewrite much and it's simply to turn everything in multiplication by default. With Integers I'd need to make the range bigger, with more depth to work with. However, it's unintuitive for me to describe colors this way and I know it's quicker using floating points for shaders since hardware in graphics cards is made for that kind of thing. But, however, I don't see any reason to change an alghorithm that works perfectly with integers. There are no reasons for that, 'Nuff said.

No comments: