quote:Original post by irbrian
Regarding my original proposal though, is everyone clear on the concept that number variables would be composed of an Integer AND a Float, not one or the other? There's no direct conversion involved here -- it's simply a matter of whether or not the engine USES the floating portion (i.e. whether the number is equally divisible by the real number 1.0). The challenge would be in finding the most efficient way to determine whether to use the FP.

One option would be to permit only a certain amount of precision for your "floating-point" decimal fraction, encoded in a more stable form such as BCD, and use regular 2's-complement storage for the whole number portion. Here's a prototype in C++:

struct Number {  long whole_part;  long decimal_part; // BCD};  

BCD requires 4-bits per digit (business-grade decimal representation uses 8-bits per digit, but that's another topic), so you'd get 8 digits of precision in a 32-bit value. Your whole part would have the same range as a 32-bit integer in C, about ±2 billion.

[edited by - Oluseyi on April 29, 2004 7:46:06 PM]

Hmm... You''re right, but looking at it from a game programmer''s perspective, wouldn''t it add a lot of complexity that we don''t need? For example, if the player''s coordinates are stored in doubles, and then encoded in BCD when a script wants to access them, it would still have the same errors. Are you saying that BCD-encoded values should be used for the whole game?? Imagine manipulating matrices and stuff like that using these values. I think that it would create more problems than it solves =/

Still, having an epsilon range seems to me like it''s a bit innaccurate. Any more solutions? I''m totally lost on this one. But I''ve seen lots of games with scripting languages that don''t seem to worry about this problem. You tell it that something is 1.0, and it stores just that...

quote:Original post by Jotaf
Are you saying that BCD-encoded values should be used for the whole game?

I''m thinking about a scripting language as an isolated solution. The question of integrating the language with other languages is separate; many high-level languages have native types that lower-level languages (C, C++) do not possess, and a common solution is to support them as aggregates (structs) or other compound ADTs. Python has a native complex type, extracted to C as a two-field struct. This language could extract numbers as a (whole, fract) pair.

quote:But I''ve seen lots of games with scripting languages that don''t seem to worry about this problem. You tell it that something is 1.0, and it stores just that...

Are you sure? Have you tested the values for numerical stability?

You need both int and float type. I originally tried it with just doubles, all the problems mentioned are real, and also conversion from double to int does not round and something like

0.999999 -> 0 as an int, not 1, and that type of result happens kind of frequently even with simple arithmetic becuase like they said FP is not very precise. Something like 2 / 4 might or might not be 2 when converted to an int it might be 1.999999 and when you truncate to int you get 1! That''s a bad example but I noticed problems like that that doubles do not always store a value that translates to integers well unless you use SSE2 intstructions to do the conversion (I think they round properly).

I''m just trying to save you time I already tried a universal number scheme and it didn''t work well. I like the Basic style with a lexical dingy informing the type of the expression like a$ for string, a# for int, a% for double. I don''t think that is very hard for newbies to understand at all.

Of course you might be smarter than me and figure out how to get it work :-) I gave up it was too much of pain and I didn''t think using a lexical syntax to differentiate on the symbol was very hard to understand.

Well... I have limited experience with scripting languages in games, but they all always seemed pretty stable (by limited I mean that I only tested a few, but the ones I did, you can say that I used them "extensively"). The ones I can remember right now are Graal (www.graalonline.com, it''s free ) and Warcraft III. I remember using floats to store flags (that could be either 1 or 0), and I would do exact comparisons and everything would behave as expected. I also never had any problem with arithmetic operations and stuff that could be affected by some imprecision. And I remember that they called them "floats" I''m not saying that these problems don''t exist, I mean that there must be some really obvious way to handle them.

And I think that the question of integrating the language is one of the most important matters, since it''s supposed to be part of a game

Peter, I know it''s a matter of personal preference, but I always considered those symbols kinda ugly, and unnecessary. If you define a variable with a specific type, you don''t need to put it everywhere in the code you just go look it up in the definition whenever you need. But that''s just me

heehee yeah, I had worked it out so you could use them or not, dynamic or static cast variables. It's awkward to explain but my last toy I could have variables containing multiple values at the same time.

As for the floats, well exact comparisons will work if you set it to 1 or 0. My example was bad. In a more complicated expression sometimes the conversion to an int did not turn out what was expected. I can't remember exactly what now but the result would not be a perfect integer. The problem is if you are using it to index an array or some data type then you get unexpected problems. So it was better to have an int and float type as seperate not to mention it is alot faster as there is no type casting to do anymore. The less stuff you have to do the faster it will run :-)

Now I have started yet another toy to correct all the mistakes I made in my previous toy designs hehe. Actually I think I am close to being a master of toy virtual machine design now this new one runs about 1-40x slower than native C code in general. It is about 2.5x+ faster than Python in almost every way. The nicest part is I managed to integrate it directly to C, my standard library is imported directly from MSVCRT.DLL :-) Of course, it is horribly unsafe and would be a disaster to use it as a script language for a commercial game but it is very fast.


[edited by - PeterTarkus on May 5, 2004 5:50:07 PM]