I rediscovered Minecraft (and all the features I didn't knew of) and played the last two or three days with no real stop. It's fascinating what you can with a set of few mechanics and an almost infite amount of randomyl crushable world map data. So far I emptied a bunch mountains and discovered how useful minecarts can be and how redstone could help me to improve my cave discovering methods. But well, before I knew of that or even started thinking about it, I made my home inside a real mountain that rather high than deep. So in the end I asked my self how get these carts up the ramps... Really hard to do cause I didn't designed with this in mind.

So I'm tempted to restart somewhere in this world and using all useful things I mined out of my mountain. It's rather big place I created and I don't like it very much. I rather want to have a warm place under the earth with short travel ways and no endless stair til I reached my bed to sleep for a while... I feel like someone how created something stunning but then discovered howuseless everywas cause someone did it better, faster and more interesting. I'm a bit pissed off cause I was so stupid to NOT build my home down in a cave or so. I'll start my next home somwhere in the desert I think. Though I don't know where to get wood there.

Also, they should add ingredients to make gunpowder for TNT in peaceful mode. It's annoying to always dig so deep. I hope they add it in the future or so! Also nice would be somekind of redstone to mechanic and mechanic to redstone component. I only want to start my minecraft remotely, that's all!


Maybe a tad of scalability

I'm actually in process of writing this memoization thing (I found a way 'round making something productive yesterday...).And I wasn't sure how to implement this technique flexible without sacrifizing compatibility with later, bigger excursion. Namely other index ranges, huge amounts of data and so on. I think this one could bring some more benefits, so I wasn't happy with just using my custom "Index" typedef that's nothing but an unsigned int. I also have other types with different ranges, but that doesn't matter if I actually want to simply change it on-the-fly. That also came to my mind when implemented several math-related alghorithms that benefit from different types for counter variables (sometimes int is better, sometimes float is - depending on how the formular looks). I used a single template parameter to identify the Index type used there and it worked OK in this case. Since almost all of my classes take template parameters for such "could be useful in this situation" facts, it should harm to add another, I think... Making declarations longer, I'm not where this should end, but I hope it's worthless. I don't like having special solution for every cases. As long as I see one features usefull, I want to apply it where it makes and where it is useful. That's the kind of complementition I like to have in my personal projects. It's the freedom of having a - for me - perfect code without heavy flaws, going nicely along with everything else and forming a definite codeline for further classes and structures. Personally, I adore that kind of freedom to make whatever feature you think is awesome and then combine into on well-written thing. I'm currently not interested in making everything - I just want to make my stuff good and end of discussion. And I'm glad that I currently don't need to worry about making other stuff, term breaks are simply awesome.


Surprise, surprise

Raiding Wikipedia for more information about how to approximite sine and cosine, I discovered that I don't need to do that - modern processors already HAVE sinus and cosinus built-in! That's astounding, seriously! I didn't knew that. And I didn't knew that GCC is able to detect that and insert fast assembler for that. Just amazing, really simply amazing! I didn't knew and I'm glad I don't have to implement a faster approximitation. I simply need to use some special flags and everything's faster, like magic I guess. Wow. Simply wow! And the best is that I can keep using C's standard libraries for that. It's to know that this will work without any problems.

Geez, I already thought I'd need to start making some CORDIC stuff (weird rotation-based thing for calculating all kinds of things) or so. But that's just too much for my head and I'll skip everything related to more complex theory if it isn't already in form of an alghorithm. Anyway, I wanted to start my memoization experiment and what did I do? Read about how to make your sine/cosine functions. Hmpf. I even implemented a pretty decent alghorithm for Pi approximation (BBP if someone's interested), but I really shouldn't use it since it doesn't make much sense to calculate a constant if there's already one defined for me. I should really put more effort into learning all of GCC's command line options, it's worthwhile discovering more interesting things to make your program faster! But since I wanted to make stuff on my own (it feels good to know that there's something NOT depending on special hardware!). So I can port to whatever thing is out there and be happy with it. Plus the concept of my memoization idea is to not worry about one-time calculation, rather about the access of already know values. So it'd only matter later when I want to improve things. And thinking about how I'd need to chain all outputs, it wouldn't make much sense to design all these functions standalone since I want to profit from what's already precalculated. I think it's better to first create the system and then add the maths to it. There are many things I'll need to consider, especially for "open end" functions like factorial or power. But well - I think I can limit these to a specific range. Atleast the factorials. I don't need much precision for what I do, so it'd be cool to have an alghorithm with low powers/factorials and a consistent amount of detail added per iteration. So I can predict how I would need and how large I should make the arrays for such less detaildriven calculations.

Yeah, that might be a good thing to consider. However, now I remember why I wanted to implement my own versions! If I already precalculated parts of, for example, the sine formula, I can reuse them and get quicker calculation. Theoretically, I could buffer everything and only add things here and there to get a complicated formula done. Not sure how this will go, someone wish me luck for that. Could be a fucking awesome tool to have for all things math-related.

But it's really a shame to sacrifice this new knowledge for such a completely different technique... I feel myself getting jealous of somebody not wanting to always discover new technique to make something less sucky. Too bad I live for that.


A recent grumpyness about how few you can generalize without overhead and disadvantages made me think more about my programming language concept. So far, all control about function calls (when, where, inline or not and how), as well as input/output of values is done and now it comes to how I should implement variables, static/dynamic memory and so on. My biggest problem is how to implement static variables. It's easy to handle dynamic memory, as it requires just an adress to work with. But in essence you'll need to know the place where this adress lies and so on. Currently, I don't really make any difference between types and variables. I have a static memory and it's filled with data. Access via byte address, type interpretation via casts in the C-code. Pretty simple idea, but I just don't know how to make work nicely. At first, you'll need to know how many bytes you want for your static memory. Simple: as many bytes as you'd need for the total size of all global variables. And where do you store this information then? I don't want to store it in a special header in the bytecode or so since I'd rather like to keep it clean from anything that would generate overhead during execution. So another idea would be to include a command that allocates as much storage as needed for static variables. No allocation would mean no variables to allocate. This is quite interesting as it enables you to make with only input adresses directly inserted as well as an output address. No temporary variables, not allocation - in essence a perfect inline function, a simple set of commands on a given set of data, just perfect. In the end, I can use this ideal function as a base for all bytecodes I'd want to execute. So it all boiles down to a single command to allocate a set of static memory, keeping the address of it in a single variable required for each bytecode interpreter. But still - how to determine the amount of memory required efficiently? My idea is to introduce a new bracket type that's the compiler step I was talking about before: a pair of {} brackets to signal a pre-compilation calculation. You could still code everything you want with simply using literals - no variable names, just relative addresses. In the way, variables are only bound addresses with a given type and thus size. However, even if I'd had a pair of {} brackets with code in them counting the number of defined variables, it doesn't qualify as something actually useful in this case. If it'd be execute before actual compilation, you couldn't rely on it having variables allready. So you'd need to use numbers - not a problem at all. But even then, is it really the compiler step I want? No. If you compile and execute each {} pair, you'd need to input something, in this case the code itself to look for definitions of variables etc. Kinda cause this would also require some kind of literal aliasing the code itself, enabling reflection for the complete program. I don't know. This kind of goes into a wrong direction I think. Personally, I think it's better to think about something different. Also, what you need to do if you'd want to execute a code? Right, compile it. Thus every {} requires compilation and returning a value. I think it's a too special step somehow. I'll keep it in the concept for things like... I don't know. Maybe config files for execution you can read in using these unnamed programs and generating a different output file. Hm, could be useful one day. No, it may be an interesting features for flexibility purposes, but not for solving the variable problem. Oh and then there's the alias problem. Since it doesn't make sense to use {} all the time, I need a notation for aliases, namespace, scopes etc. Yes, you could do everything by using numbers as addresses. But thats no way to code appropriately, for obvious reasons. So here the design of the language's keywords or symbols kicks in. I need to design them! This will be fun, finally choosing the keywords and designs one would want to use. Even the functions need names, so I can hopefully rely on a simple symbol-based solution... Hm. Not sure if it's wise to use so many symbols. I like to have the freedom to use whatever symbol combinations I want for function and variable names in general. It's useful when, for example, integrating common mathematical notations or so. I can image it beeing more useful than just keeping keywords free... Yeah.

"So what's next, Jimmy?"



I created a handful of tools for bit manipulation (several bitset classes with varying size and performance and some macros). Now that I seem to be complete for starting the first little memoization system test for the system I described before. Too bad I need to change all the bit shifting when I want to port it to a system with another endian mode. Anyway! The bitset (or bitfield, whatever you'd want to call it) is for manipulating bits like you'd manipulate them in an array. I'm aware of the fact that my what I'm planning to create could make a shitload of data (though not a moderate amount compared to what nowadays video games consume). So it is wise (in terms of memory consumption) to not save space-wasting booleans but work with bits instead. Since I can only use power of two bitsizes for my idea, it is not a problem to stick with a single long int variable (atleast 32 bits on most systems). However, I can also use a multiple of 32 bit or 16 bit or 8 or whatever - it only differs in the number of operations to perform. Though 32 entries for a memoization array is really small, I can still rewrite with not much effort in any case thanks to my consistent class design (sometimes I like to fondle my ego).

If everything works correctly, I can use a minimum of memory consumption for each memoization array. Although it'd be faster to not always seperate the bits, check for it's state and thus knowing if the entry has been memoized, I'm more concerned about the memory it would consume, since I do know that I'll never check for anything else than for a single bit beeing set. Let's think about... 32^3 entries in worst case, a T-typed data value and a pointer for detail data as base memory. That's already 256 MB of data for a float array with a lot of details. And you also need 32^3 bytes for the bool variables - 32 MB more! With a single bitset array it'd be only 4 MB you can splitup in an appropriate number of bytes. So really a minimum of space required in this case. But well, I don't think I'd need so many entries in reallife, atleast I hope so. If my concept doesn't work, I can use the memoization mechanic for other purposes (and equal speed). Well, I hope it works. The idea is conceptually too nice to be worthless.



After a while of excessive grumpyness and translation of math alghorithms into useful functions, I discovered that it's possible to take a look at all standard C function defined in gcc's libc. It is good to know how it approximites the sin, exp, cos, etc values. I thought I could find a nice alghorithm I could implement that's a bit quicker than the usual approximations, but that's a total myth. It isn't much faster except with complete precalculation. And that's where the magic kicks in. As I explained in a previous post, a system of memoized values of mathematically complex and CPU-consuming functions could be a good tradeoff between speed from precalculation and flexibility during runtime. Yesterday I created a really interesting concept of a dynamically expanding storage that's able to give and calculate values with more or less resolution. For example, you can could precalculate 360 sine values but maybe would need more for special cases - possible with my solution, it would simply create missing gaps on the fly. It requires some more checks and jumps, though. At the moment, accessing an already calculated value would require one *, one /, some null-checks depending on how you want to dig, some bit operations and finally an array access. The little bit of basic maths you'd need there is also required for normal look-up access, so the overhead is already there. What comes additionally is a series of nul checks and bit operations. And these are really not the slowest ones. Guess it's much faster to use this system than doing it in realtime... Plus you don't need to make HUGE tables for all values you could need during execution (including all the values you simply don't access). Instead, you can make a small resolution first and expand it like you want, if you want. And step by step you notice that you can chain all kinds of operations in a way that you speed up almost every calculation you'd normally do with lookup tables. Yes, it is faster to just lookup tables, but a 1000x1000x1000 cube of formula-based data is a bit too much to calculate or even store. So let's a assume this cube is a three-dimensional, highly detailed wood texture you can use to create dynamic wood surfaces for furnitures, cut trees etc. You don't need ALL elements from the cube, just the ones affecting the polygon areas. So why precalculating it on-the-fly with a low resolution before with a high one if you can randomly create the details you want while accessing them later? That's the idea and I really need to flesh it out a bit more. The basics are there and it should work fine without any problems in reallife. Though I haven't yet tested if the numerical base for accessing is 100% correct and safe. However, this is probably no big problem anymore at all. I'm glad I've discovered this solution and I won't share unless I decide to make all my codes GPL. Of course do I need to test it at first. It's certain that it will work. And I can imagine it looking awesome in a videogame that's only made of polygons and vertex colors. However, it's also something I can use my raytraced roguelike if I ever want to continue developing it further. I can imagine altering the system in a way that can also make the memoization more flexible, getting completely different data than just numbers and it will try to approximate what ever you fed it with. That's highly experimental in the current stage and shouldn't praise to much here. I know stuff can go wrong.


Good music, fresh music

I usually keep track of what's posted on Ektoplazm.com and from time to time a modern goa-alike album comes up. I rather enjoy goa, contemporary, old or inbetween doesn't matter. I'm not such psytrance fan as it tries so hard to sound badass or psychedelic that it totally forgets what good flow and thus psychedelic atmosphere is. That said, I enjoy listening to goa a lot. And today is one these days where it's just another goa album but something that kind of hits my expectations I have of good music. More specific it's an album by Oberon, and it sounds delicious. Two smooth songs with nice cliche chanting in the beginning, the a rather meanish track (I like those) and even two downtempo tracks with exactly the same kind of different I'd like to hear there. Has a good sound quality and does wonders to my ears. You should listen to it if you're a bit into psychedelic electronic music. It's a good quality and tracks 3 and 5 really sound like they would (in spirit) come from Restricted Area's excellent soundtrack. Even better, the album album gives me an excellent show on all sensable layers. The end is very interesting. After pumping tracks and downtempo flowing the musicians turns it creation into echo-distorted mixing of old movie fanfare samples. Indeed a great end for such an album, surprising and more different than other stuff I heard the last time. Did I say I like music that gives you a good, versatile show? Gives me the feeling that music is so much more than a system, rather a monumental collage of sounds and feelings.

Memoization the Second

Since I was able to finish my last exam, I'm free to explore ideas and concepts I didn't have the time for before.
Anyway, my current idea is to how I can reduce the amount of textures, bumpmaps and all kinds of graphical things in general. I explored the idea during my chess viewer assignment and it worked well with certain parameters limitations. But I noticed a) peformance problems with realtime calculation and b) hard-to-setup parameters cause it's was a mostly additive and multiplicative system. To solve problem b, I want to make a system that's a series of editable commands with a flexible set of parameters. The resulting idea shares many elements I can also find in my bytecode/c-code language concepts. So either way it should be possible to combine them with good benefit. And it's a first example of where it's useful to have a flexible bytecode in addition to static code - plus you can mix them with no problems. Problem a on the other side requires a bit more thinking. Originally, I had to precompute everything to compensate it. But since I don't always want to keep values as they are, my idea is to use memoization to store the results of each calculation step. And since the formula system would use sine, cosine etc very often, it's also possible to memoize these, too. In combination it becomes a memoization that's also a set of meomoized data sets etc. So we don't need to store and render them all the time, accessing them on demand and in all possible combinations. I quite like the idea of that. Memoized memoization.

And thinking about it, this system could work well for all kinds of formulas you'd normally change relatively often. Like in a synthesizer where there are many, many ADSR and oscillators you don't want to calculate all the time. I kind of like the idea, though it needs a lot of experimentation to work better than by default. Yay!



I did it. It works. I finally got a version my multidimensional point/color/vector/whatever done and it just works. It's amazingly creepy how implicitely template operators with template arguments simply specified by a passed parameter. I know from methods that you can't just pass it without specifying, but operators with magically like they fell from sky and made love with the most magician on earth. Jokes away, it is also amazing how it me took to bring it to life. C++ is an unforgiving language if comes to such details. It randomly happened that I brought myself to begin coding what I wanted to abandon far away but also wished it more than anything else in the moment. Out of a sudden it worked even better than expected and it just flattened my mind to see it not complaining during compilation. It just worked. And it is probably a mess for the compiler to put into form. Now I can only rely on the compiler to loop unroll and inline it. Fortunately, I found a reference of all GCC optimization flags I can enable on demand and without any problems. So I'll always need to setup these flags to get the performance I want. I didn't notive before that GCC doesn't inline code by default. I just wrote inline infront of it and was happy. Too bad I didn't notice it before, so maybe everything could've been faster without all the very, very long delays between progress. Release! Finally. After a so long time of anger, brainstorming, frustration and knots-in-brain. Pleasing to see it coming well together. I hope I can exploy the operator parameters even more to get on-the-fly type conversion done. Even if this doesn't work - it's awesome to know that the original features set is now 100% safe and functional. Good job boy! You done well. You deserve the sleep you should now get.

I'm tempted to say Amen, but that'd kind of too weird.



A while ago Wikipedia brought a technique called memoization to my ears. Since then I found it always fascinating, but never really had an idea if it'd be useful. Memoization in general is when you have to return result that's always the same depending on the input parameter but have already calculated it. But before you calculate it again you check if you already calculated it. At first I wondered if it's just an "evolutionary not-so far" step from precalculation, hardly seeing any case where it'd be useful. On one hand you can always perform the required calculation again. That doesn't features anything, but depending on the calculations to do, it can be faster than looking into the storage where you've put it in before (usually a sort of hash array). And then on the other is precalculation - depending on what to calculate, this can be very, very slow. You get immediate access to the results, but depending on how many parameters you'd need to feed your storage with, you get a not-to-totally significant amount of memory to allocated and access.

And that's where memoization kicks in, like a mix of both with equally many advantages and disadvantages. At first, you don't need to take the time for precalculation. That's a bonus, each parameter would either blow up the problem and slowdown calculation even more. When calculating normals on demand for example, you may end up with a million of polygons or so and then you'd need all the time to wait, generating annoying delays you could use otherwise. So using memoization we don't need to wait, we calculate on demand and can look them up later to avoid recalculation. Though depending on what storage type you use (hash array, array for each possible value or so), it can be slower in random access since we would also need to calculation the position inside the array. If you don't use a hash array, you can increment the number of already done calculations and decide whether to call the memoizer or directly take in from the array. So if you have to calc n values and the array is full, you don't need to call the memoizer everytime but instead becide before you "brute-force" all calculations inside the block. Further splitting could result in segmented arrays, though you only benefit in special cases where you really only access specific portions of that array. Even more, store the average of how many cells you already precalculated for the last n accesses. If the average doesn't change at all, you can fill all not already precalculated cells to get the array complete and thus further access is faster for the average accesses if the function accessing the memoization array checks for array completition before.

So yeah, it's an interesting technology to reduce precalculation delays and iteratively calculate huge amounts of memory for random access - as long as you choose the correct ways of storaging and accessing. It wouldn't always to determine the right combination, but every bit helps. The more you check before you proceed in form of further "brute force" blocks, the more complex but parallel it becomes. And then effectively faster.

However, another good use of it is getting search results. That's when you search for specific strings of even simple numbers having no efficiently precalculatable range. That'll speed up alot, especially cause strings comparisons are veeery slow compared to simple numbers. I'm trying to implement a versatile system for that, I'm sure this will help for further assignments or even for games! I can image a lot cases where I'd have to make really heavy calculations I don't use all the time, but still beeing slower to calculate in realtime. And well - precalculation isn't always the most useful solution in this case. Even if it's not really for the game itself but for the data management system. There is surely a place for it, I trust in it beeing useful eventually. Plus I'm interested I'm interested in having a simple technology you can explain in or two words to my lecturers. I can remember that this semester was full of explanations cause I don't use standard technology. In the end it was faster and more versatile, otherwise I wouldn't do it!
I need to learn to benefit from what I've already done. The last days I tried to make to most atomic interface for a linked list item structure I already did before. So I used this list item structure to make a typical linked list like I know them Purebasic or so, completely without any iterators (I think these mess up the code quite a bit) but internal selection pointer. Well, after I archieved this kind of list I noticed the substantial lack of not having multiple position to work with. I created a system to memorize whatever I want and even altered to an iterator-like system. Well, then the class was sooo big that I wasn't really able to remember all the pretty different functions I build. There are so many diffirent things that'd be "atomic" for a thing of such an "high level" as a linked list that it is almost impossible to include all of them without using iterators or millions of function names. So I almost got struck by lightning, remembering that my goal to create a more "all-in-one"-alike interface for this item class was simply the same as the item class. The only things it added were the length and pointers to the first/last entries for instant navigation. And these three features aren't usually useful to me. In essence, I simply don't them at all for most moments. And since my item class is designed to work as a self-managed list, I can simply add a little counter variable somewhere without any problems. *sigh*, I just don't get why I'm doing this allover again, everytime when I want to "improve" my existing things. I remember when I told myself to make a more comftable list. It was when I was coding this chess parser like a madman. I coded a special list class which, in essence, was only really necessary to count the added items and to merge two existing lists. But thinking about it, counting all elements was only necessary cause my fellow students didn't knew anything about templates or linked lists - so I had to convert to an array everytime. And merging these would've been - in case - much easierr than by using the start/end thing.

In the end it's everything just a question of how you arrange your alghorithms. I don't like make stuff for every case, it makes software complicated and inefficient. Why do we need more computation power for even the most simple programs? Good question, usually cause the software does things inefficient or with all these "modern" ways to program. Hey, I want to focus on development, not on learning those overly complex systems. Many people said to me that it is easier to use existing things, but I find it more complicated and less satisfying to use them. Plus, they won't work as quick as possible - they are for convenience, which is not my style and not the way I can think.



It's a bit strange I'm blogging about language and the understanding of language. For me, as somebody with more experience in German language than English, it's sometimes (and more often in the past) hard to understand why certain uses of words go so wrong or are interpreted negatively. One example is the use of "he", "she" and "it". I'm used to see them solely as words to describe a gender - he for male, she for female and it for non of these genders (I don't see only to genders and I don't see no genders. For me "it" is just different from male and female). So in theory I find it totally ok to call somebody or something "it" if there's no gender I can name or can apply with my knowledge of words. Today I had a strange moment when I used "it" to express myself as unknowing of someone's gender and it promptly got a negative aura. To be fair, that would have been gone in German. It must a strange anomaly of gender/non-gender equlity I have in my mind and with others understand wrong. Language is a product of past and slowly evolves. I'm glad that in German there's always a gender for object you can name - he, she or it. So as a rather analytic person, I see [he, it, she] as a sequence of states from male to female. If something's not male or female, it is an "it" and at first not an animal, a stone or something unhuman. No, I see entities in the world, not just distinctions male/female humans, animals and objects. That's retarted and utterly unfriendly in spirit. Just look at the manifold lives in our world and then say me: why do you decide between only two genders? There's always a third option, I learned to identify with it. Of course, you may say that's this is also unclear, but atleast I don't it pret something as "subhuman" or something like that. That is putting the humans higher than the ones declared as below and thus every animal or other entity.

So think about these words when you somebody calling you "it" with no evil meaning in mind. Get over the historically evolved stupidity and bring some more polite sense to it!


So as I got another brainstorming session done and I must I quite my current idea how I will step by step, slowly conceptualize the right structure for my own language. At first I thought about how to support only C functions and how well one could integrate it into the idea of step-based, custom compilation and so on. But then I got quite an interesting idea: I like using paranthesis to seperate not only logical blocks and document syntactical specialties using them. So I got the idea of relying on paranthesis in general, similar to how Lisp does it. Of course not in the way that everything is stored in the same format or requires endless amounts of closing brackets after a code. Rather like using all four kinds of brackets: (), [], {} and <> as a fundamental parts of the syntax. That also led to a weird idea: Why don't create a bytecode that can also be exported to C directly and then mixing it with static code? Having a flexible code execution unit INSIDE your static program! And the interesting part of it is that you can access the same memory, creating bytecode via your static code and thus having an effectively self-programming program benefitting from both fast, static code and slower, dynamic code! And on the plus side you can at first focus development on the bytecode and then writing the converter. When they use the same memory, it's probably an equivalent of having a modifyable code. However, the brackets brought to that cause I usually associated () with beeing dynamic, soft and round and [] as fixed and rather static - almost conservative. So why not use this association within the code itself? So maybe you could specify on your own what wll come - [code] for static code and (code) for bytecode. Note that it's sometimes easier to start with an existing set of code, so this is definitely something I may keep in mind. However, this can also be applied to memory. Having [] mark a static variable area and () a set of dynamically allocatable things. I want to have a strong distinction between static and dynamic data, since this you always need static memory to store the adresses you allocated dynamically. In the end, everything ends up in normal memory except when the compiler decides to choose registers as he wishes. And there it also comes to how my memory layout would look like. If I think about it, there's probably a lot of time between converting my code to C and then compiling the C code. I'm not sure whether I want to export it directly so that you can see all your variable names like you wrote them in C code. I still need to access all memory from bytecode. And at the moment my unfinished bytecode design bases heavily on adresses instead of identifiers for variables. And I'm sure it's not really useful to do otherwise - using a simple offset in a big block of memory is easier to export than always letting the bytecode know where what address of which variable is. I could rely on a simple layout and the C compiler would calculate all the static array offsets and we wouldn't need to bother about naming them. Plus it may make compilation easier for the compiler cause he doesn't need to check for existing names and types etc. If there's just a big block you can freely access it without all the things you know from C's harsh compilation errors.

And drop it also completely

And thinkin even MORE about that shit, I'll guess I can drop all that things with template variants of functions and so on. I don't think I get much out of it, as the compiler won't really do work as would let him work. Only thing I can really do there is to reduce the number of parameters, that's it... But one thing I'll do is to create a static array class. So having the size fixed and also template functions for copying or mixing other sizes, it should give the most obvious hint to the compiler to unroll all these loops with literal as min/max values. Yes, that's sounds like some good thing to do. Even if this won't work, I can still use the new comfort I got and make my stuff with it. Anyway, arrays seem to be everywhere where I'm working on. Arrays and lists. Of course, there are also trees and so on, but even they are lists in most cases. So I'm on the right way. That's good know. Whereever this path will lead, it may work atleast with a larger feature set for these two basic elements. I mean colors are arrays, vectors are arrays, images are arrays, maps are arrays, objects in game are lists or arrays, everything is in memory is a list or an array. No matter what it is, you can store as a list or an array. Arrays are as great as squares - they make so elemental components that you can't just get rid of them. I like arrays. They are so fast in access.


Just forget about

I decided to forget about all optimizations on such a level. It makes you feel bad for finding out more precious details about why it doesn't work and so on. I don't like to think about it anymore. But my plans to make my own language come reality will stay. I had a lot of time to think about it today and it makes me more happy than trying to make stuff the language isn't made for. Now I see C++ only as another language that has it's of course natural borders. Noone should force it to something it isn't made for. So I'm having my plan will make use of all things it is made for and not for what it is not made for. That is another place.

Wash it all away

Oh man, I'm so fucking depressed. You meet one person explaining you why all this C++ inlining and reference shit doesn't really work and then you see that everything you tried to archieved will never work that way. GREAT. IT'S FUCKING SICK YOU COMPILER CODERS. *grump*

I don't even know where to start from here! Why do they make so stupid functions if they won't work this way? What's the deal with it, eh? FUCK IT, TOTALLY. I'll screw all that shit and stop working on it, that's it! I'm tired of it. I'll stop the chain of "work towards a nice toolset for your stuff" and will only create things that help to make my own "compiler" that converts my language of choice to C code. I want direct about code creating, the C compiler can make the rest if he wants. If I want an inline function, I really want it inline, not just on occasion. The only way to do this is to insert it as code, directly. And well, yes! If the fucking compiler wants to "optimize" my generated code, just do it then! I don't care as long as I can combine in the way I want.

I'm SO pissed off at the moment. The time has come TO END IT ALL. I don't need pseudo control about it, I want a way to craft code, not leaving it only to the compiler. GRAAAAHHHHHHH

And no, I don't mind about the work do to. I rather do much that has a good effect than doing too much has a bad effect. And trying to get a compiler to tell him that I actually want to insert this code is more annoying that anything else in the world (atleast it's my current point of view). Maaaan, we need better compilers. And by compilers I really mean compilers. Existing languages would provided better control about it if their compilers wouldn't just mash around with your code. My code seems slow to you, little compiler? Well, do you really know what I'm aiming at? Do you UNDERSTAND that I want to have the code like this? No, you don't. You're just a stupid program written by another human, also altered by your previous version. Machines make machines. We all know that this won't work as intended.



I'm a bit uncertain about how inlining in C++ does optimize return values and references. After asking my lecturer he ensured my that reference never really consume any pointer or so and that I can always use it to get a better performance in general. Judging from the fact that I always used before and it was fast enough to make mass data access quick, I'll prefer instead of the return variant. So yeah, I guess this will be my last word for it. Always using references and so on. Hm, I must admit I doubted this for some days. I don't know. Maybe my brain turned into garbage after so many tries to get everything inline. That's weird, really. And now I'm also unsure about this loop unrolling stuff. Though I took a look at this page, knowing that -O does loop unrolling or when I specify it directly, I still ask myself if I can trust it. On the other side, how can I trust empty functions I used for complex, recursive template structures? The degree of possible is equal for both cases, so I can either not trust or be happy about it.

ARGH, sometimes I confuse myself enough with this shit to question everything I never questioned before cause someone told it me right. So it's a false assumption that unrolls later. *sigh* I should set up a definite guideline for my whole toolkit. I'll begin!
  • use only call by reference if possible
  • inline what's worth inlining
  • take loop unrolling serious and offer a large variety of template methods with fixed values to help the compiler determine what to unroll and what no
  • ensure that all unchanged reference are defined as const
  • make it a template class if useful and possible
So that seems like a good guideline. I should print and pin this somewhere for motivational and essential purposes...

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.
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.



Since the array stuff is done, next step is making a class for sequences like C strings - having a set set amount of elements and and limiting character. The point is that every C string is just as big as the memory block you allocated for it. So it's basically just an array with a number of characters used. My problem is that this fact itself doesn't make it necessary to create a class for it. It requires something more... something more special like the ability to combine multiple sequence into one. And that's the point where I'm a bit uncertain. Taking the array class as a base would be kind of the first natural choice - combined with an additional value for it's length (means the number array bytes used til the sequence end value). Only problem is that you'd need to make the array class expandable to make the sequence more useful than just a simply array. So here wo go: that's the basic problem itself. An array has always the same size, no matter what is in it. Especially in C++ you can only really use the new operator to allocte arrays and calling their constructors, so using realloc it no option. Thus it requires allocating a new buffer and transferring existing data to it. In my opinion those functionalities require a new model. There are basically three action: allocate a new memory big enough to fit the old size and the new size (or more generalized: the size of two arrays) and copying the content of array one and then array two. Number one is trivial, done in a single command and and an addition between the two sizes. Step two is something different not really related to the array class itself. Mass-copying content can be effectively seperated and is imho something completely different. So I guess that's the new idea, creating a copier class able to transfer n elements from a to b at position n. Everything using the Array class itself a but more would require such a copy functionality. I think that's the right approach, as you can keep all functionality seperated. So, having a data class itself and a class to modify it, every other more advanced class would benefit from having another class to operate with it's very special properties. I can image having another copier class for the sequence, enabling it to concatenate and alter sequence data. It all depends on what comes to my mind I think. I'm always having trouble to keep my classes not too big and in reality I end up making stuff here and there, just to add the feature I need in the moment. And that'S a problem in general for every programmer thinking a bit beyond per-project featurism (reusing and overhauling code is a key to less work on things you already archieved some time before). I can remember using concept before with a class designed for simplyfying the process of writing software renderers. It had (and still has) a series of classes, some for tracing a specific shape like a polygon or a line, then again others using using these generalized structures to just put pixels shaded pixels whereever the alghorithm defined it. Quite a cool idea! But just too specialized and only usable with an associated class. I want to change that. Keep the base clear and of specific concepts and you're motivated enough to work with this single concept all the time. Maybe that's one of the reason for why people create their own engines or frameworks.

For whimps

I decided to leave this "safe access" thing and only provide a function for checking an index' validity. It's still my toolkit after all and I don't appreciate the implementation of functions I wouldn't use. So all in all I kept it close to what you'd do in C or other lowlevel language. Range check on demand, leaving performance-eating stuff out. If I think about it, I followed another principle with my doubly linked list item class. It made it to have a completely 100% safe self-managing list structure with no seperation between items and list itself. The cool thing is that, while I only check if(!this) return; in the beginning, it gives some interesting aspects when allocating new elements. You can start the allocation an empty element and you get the pointer of newly added back. I think it's not necessary to check for this in every function. I should rework this one day, checking it only where it's really necessary. However, I like the approach and that you can keep it really, really minimal. Though I miss a singly linked variant I'll have to code some day, too. However, I'm pleased with how wonderfully minimal this base is. Oh I'm such fanboy of small code.

Access methods vs. operators

As I start - starting from the very small things is always more pleasing than having all the bulk shit in mind. So I'm doing exactly this, coding an array class that really cover all things I'd never need. For me, concepts with iterators and so on aren't that... efficient. Of course, I could still make them templatey and rather OOP-less, pushing performance to a maximum. But I still see the core elements - arrays, sequences and different kinds of lists. I know I can create every special of memory with them as a base, so there's no reason to create such a complex concepts requiring me to remember more function and write a shitload of code just to access a single element. So I'm brainstorming the most nice way to do this. At first I had a lot of methods in mind doing all kinds of different things with different with and range check, different ways of accessing, etc... But in the end I thought: why so complex? Only thing you need is a reference or pointer, this way you can access everything. And you don't need to write so many methods you need to remember then. So my is to keep the access as simple as in C - [] for unsave element access and () for safe access. I kind of fell in love with designing the "best" interface for a class to suit my needs. But since I know I won't really use the "safe access" methods, I don't think I should tinker with them too much. Only problem using the bracket notation is that you can't really check for errors if they happened. For me, the word "safe" also carries the question whether the action could be carried out or not - impossible with having the return as the value return. Especially if it's a generic array, giving you whatever kind of data as a return value. Well, I could just return return an adress, but this kinda destroys the notation. Hm... it would also give less freedom them. Difficult! But I'll play around with this kind of notation. Recently I developed a strong dislike against using methods for accessing objects keeping n elements. Guess I'll also create a special list class that works with operators. I know, I know - I explained my dislike before. But I thought about a while or and came to the point that it's the best to always choose the most understandable notation. And in case of arrays I prefer the C variant with [] brackets. Therefore, other brackets seem to work better than just using functions (on a second note, array(index) seems more usable than array.getSafe(index)...). I thought about using a static variable that's true when the last operation produced an error, but it's not really a clean solution. Many cases come to my mind where it's simply just BAD to do so. Well, I don't know. But I could some kind of array(index,valref) returning bool on success and storing the value in valref... That's by the way to original way I thought for accessing it. Hmmmmmm, really difficult. However, I could also use my event system for that! It'd be an event static for the whole class. So if an error occured, it will notice it. On the other side, this is like exeception handling, which is even more bad that using methods for all the stuff... Well, then let's get back to methods with minimal interface. Guess that's - again - the most flexible but most inconvenient solution. But I'll include the () notation for convenience. I could also simply create a set of events for all possible things to happen and call it if something happens. Due to the fact that you can also simply leave them untouched, you would really not need to worry about them. This (and almost only this) is what I liked about ActionScript: just hook some event for stuff that could happen. Though I think this a nice solution in theory, I know it's always better to check for errors in code cause you can free all previously allocated memory and let the upper layers catch and react correctly. Simple but efficient, always checking for errors when (could) happen and react properly by deallocating and setting all the stuff that's related to the it - that's the way software will work stable and better to debug. I only had good experiences with it and thus the story continues. So what's the schedule now? Use optionally implemented error callbacks but still return true or false on return.

Oh and during the process of writing this I got the final idea: () returns a pointer, thus it's possible to checkfor zero. That's different but you can check for errors this way. And if you really want a more "if(action) then"-style of access, you can use the access methods. Yeah, I think that's an "O.K." way to do it. Let's see what I think is more convenient. Maybe I'll instead use () as an unsafe address access - having [] for references and () for pointers. Don't know. Since I'd use both notation and usually WITHOUT checking for array bounds all the the time (this is done once before execution), this seems a good solution to me.

Hooray for interface design monologues!


Thoughts about the dimension thing

I'm not quite sure how to proceed from here. I got all kinds of working functions for combining objects of multiple dimensions during compile time, but well - there are four different variants that should be in one single method. Problem is that I still can't just specialize template methods within classes without messy overloading constructs. And no, meta programming didn't really help as intended. It works for compile-time calculations and alghorithms, too, but not for simply calling a different method as this would require replacement of symbols etc. It's just not possible without making it too complicate to work with and thus nullifying the effective. I originally planned it to a) replace n operations for n dimensions with just one line, b) mix 1D, 2D and 3D points without always rewriting the type and c) to keep stuff generalized enough to work with other dimensionized data structures. Well, part of this comes true, but there also things I forgot over time: usability and code size. My current Point3D class is rather massive in functionality since it implements almost all operators you can overload. My new attempt for dimensionality requires to specify them again, but with no content. So I have to copy every function I have - a bit much for my taste - can't it be solved differently? *sigh*, I really don't know how. So maybe it's better to drop the whole shit? Even if I get everything done, I still need to use the current setup for EVERY method I have for my Point classes, so plenty of stuff to rewrite - and that for "just" a bunch of small functions. *doublesigh* Nothing I'll get done with any of the ideas I have. Or perhaps just a the plain, old array access with static indices? That's the only version left I can think of that's possibly easily optimized by the compiler. In the end, every object/structure member access is made by taking it object address and then adding the relative offset. So I guess the compiler can automate this for array access with static arrays, too. It's the last idea I can think of. It sucks to never really now how what is optimized and what not. In the end I still it's best to have pre-compile steps where you can write all "highlevel" optimizations such as loop unrolling, static precalculation etc by yourself. And then you can still let your compiler do whatever it thinks can be pre-calculated. This annoying thing is driving me insane, especially cause only me knows what I believe is the right to optimize. I don't trust compilers in general. They do a lot of stuff and you never know when and why - only thing you can do is to rely on set flags, specifiers in code and the stuff that's in it. I really, really hate it. I'm tempted to completely switch to C for a moment. However, I know how to write everything I code in C - though I dislike how I'd need to use them there. So maybe I should step away from my "special plans" for dimensions, stuff and so on and keep it away from me for while - as long as it will take my to write my own to C converter. Yes, I think this is a nice idea. Basically, I still don't my code as really object-oriented. I plan in such a way, yes, but I never really go beyond using OOP as a set of functions for a specific structures. I know of a bunch people designing their code with concepts in mind that require typeIDs, virtual tables and so on. Personally, I always have my doubts about the "real" use of that. But I'm biased, I learned that only fast and efficient code makes is of use. I'm not a guy for quick coding of half-arsed concepts relying on lazy implementation and so on. If I want to make something with typeIDs, I simply write a special class for it. I see no reason for typeIDs in a system other than, for example, GUIs or projects with just a few elements you don't need to use all the time. It makes programs slower, structures bigger and programmers lazy and unaware of the truth behind what they just types. And NO, don't come with this "we have so fast computers that it doesn't really matter". You know what? Everyone saying this is too stupid to understand that more speed means more possible calculations - those calculations you through away for silly shit that's just not worth having activated all the time. I understand that some of these special OOP concepts ARE useful, but not for most codes. The majority of software todays wastes CPU time and RAM. All the fucking time.

So to end this rage, you see my point and goal clear - making OOP less inefficient but more performance-oriented. My goal is to get a pure C code that's written like you'd not write in like with OOP. That means, structures for objects, functions for changing the data (taking the variable address as first parameter) and so on. I think inheritance can be done by by simply introducing a new structure with the base class as a variable. What constructors/destructors to call can be simply decided during compile time I think. Yeah, that's the most basic approach I guess. Decide it during compile time and then build minimal code with no overhead. Taking this as a base, I got all the stuff I normally use in C++. Templates can be replaced by using my compile step concept. So combining them both should give the possibility to implement OOP concepts on demand - adding stuff as you wrote a new step. Even RTTI is easy using this way. And you could also write your OOP support using such steps. So I only have to make such a system and a converter. Hmmm, didn't I say that before?


Even better

So NOW we are talking about meta programming! This excellent site showed me how easy it can be to make static compile-time decisions. I tweaked their IF construct to support some more things, but I'm really glad I found such a site. They list exactly what I need at the moment, simply nice. And it's fun, too! Amazing how many thing seem much easier than before with such an abstraction.



Yes, you just need to threat enough it with replacement and everything runs as nice as it should. I totally forgot about the order in which the recursively added properties got arranged and how to use my "next object" iteration method. It simply depends on so tiny things, though they make difference between exact realisation and definite fail. However, it has so far limited functionality (more than before of course) that I'll hopefully be able to extend.

Rather useless find

I found out that the Boost library also features metaprogramming, but I don't see how it would help me efficiently. I know I will almost only use MY template classes for everything I'm doing and I don't want to waste so much time with setting it up or even reading all the stuff they're talking over there. I took a look at what features it gives and I feel I'd only use a few of them, even with some more open considerations. No, I don't think I'd have a real advantage there. My goal is to push generic programming so far that I can work with it comfortably. At the moment, I can wait til I have enough time for reading stuff about more interesting languages or writing my own one. Agh! That's killing me. I think I should also limit myself to keeping the focus on:
  1. simple syntax (brackets, numbers, identifiers with possibly all kinds of non-whitespaces)
  2. generic programming (random number of pre-compilation steps)
  3. compatibility to C code/functions (tricky with the "all symbols as identifiers" thing)
  4. minimal core, extension using the language itself (like, for example, OOP functionality)
Yeah, I think these are the basic points. I'm heavily impressed and influenced by how Lisp did alter itself over time, extending with really ALL kinds of features that weren't parts of the language before. The cool thing is that if I get a different interpretation of the C syntax done (with all essential elements necessary for supporting libraries etc) and implement the multi-step compilation/code generation, I can for example write a piece of compile step code that filters the incoming file for all notation with an "." oder other patterns in it and produce appropriate member access code. I could take C's structure syntax and produce structures and virtual tables for all things having class definitions in it and so. I think that's quite a cool thing and worth trying. At last, I'll have a more user-friendly syntax that's not so hard to decipher for people already used to C/C++. It may also be possible to create completely different syntactical styles, as the compile-steps would (depending on how I implement them) allow all kinds of input data. Not sure how integrate this one! However, It would make a good base for an extending system of natively executed programs, profiting from the target compiler's optimization and from the fact that every compile step will also be executed natively with no annoying delay or so. A finished generic library could simply get compiled once and you won't have any problems with template instanciation and so on. Kind of a "next generalization level" for C, maybe the first real ever? I have no idea. And I'm just a silly boy sitting here and complaining stuff nobody really complains about.

First real complain about GCC

Yes, this is a rant, a complain, a thing I usually don't do about GCC. So far, I got the nicest things which would work, for example, in VC++, but not using GCC's g++. I talk about specializing template methods inside a template class. This is a really annoying thing, as you also can't specify it outside. The only solution I found so far was an ugly, ugly one with overloaded methods and a type only there to identify specific sets of template parameters. Really ugly stuff I don't to have in my code. But well - the idea multidimensionality is the core concepts of almost all of my more useful classes. Multidimensional arrays, sequences, lists, trees etc. It's the base class for EVERYTHING that's useful to me. To most important thing EVER in my whole toolkit. But what's happening to it? Nothing. More specific, my hopes to solve this clean in C++ fall apart. Well, it seems I then have to start learning Lisp instead. I still don't have time for doing so (this will change in two weeks). Writing my own language to then convert to C is also a bit stupid since I'd want to use my toolkit for coding it, which then again gets an infinite loop cause I'd need my own language for it. *sigh* It's a never-ending circle of death. But in case everything's going too annoying, I'll simply limit myself to not doing anything too interesting in C++ anymore. It simply becomes annoying to see that every idea you get, beeing totally possible, fails due to the languages horribly complicated syntax with very limited overall cleanliness. So here's my plan: Make your toolkit, create ony multidimensionality for the things you really need use multidimensional (points etc - arrays are basically always multidimensional from a certain point of view) and freeze it there. As long as I get the basic stuff done, I can do more complicated things with my own language later. The plan continues in the way that I'll try to collect all elements I think are core parts of a language but can be combined to every kind of thing I can imagine at the moment. This will of course include a way to generate a program in multiple steps, so that you can generate code of this language which in order can also generate code. A multi-step compilation process of user-defined length, making it possible to recompile the generators only if changed some of their previous steps. I hate g++' compilation system for that, but I can't change it myself, as g++ is a creep-sized project I'm too unexperienced for. So I'll choose to export everything to C, where I can be sure that all the complex can be left to my personal observation. I'll just make a big list of things and expand on demand. No forced features, just the stuff I'd really need in reallife. And the syntax will be as minimal as possible to keep compilation time down (remember: we still need to compile it to C than). Possibly a bit like Lisp, but with more common notation elements you can in C, C++ and so on. It's really time to move on and do something against this horrible motivation stopper. It's getting annoying, seriously annoying.