In an attempt to generate a random number between 0.050 and 1.000 (variables only take 3 decimal places, right?) that was a multiple of 0.050, I came up with the code
Code:

---

volume1 = (int(1 + random(20))) / 20;	// num between 0.05 and 1

---

Looks pretty basic right? Make a number between 1 and 20 and divide by 20. Thing is, as soon as I fired up the engine and generated this variable, I started getting numbers like 0.149 and 0.799, and occasionally a nice round one like 0.650. I remembered the manual saying 3DGS wasn't too good with very small numbers, and multiplying by a big number was better than dividing by a small, but regardless I tried changing it to:
Code:

---

volume1 = 0.050 * int(1 + random(20));	// num between 0.05 and 1

---

However that was even worse - I started getting things like 0.297 that were out by as much as 0.003. Thing is, it's a simple calculation and should work, so I went and made a thread over here in the Scripting forum. After some discussion I tried a kind of test program (see post #5) to see what 3DGS came up with when you divided 7 by 20, to a different number of decimal places. I came up with the numbers:

0 - 0
1 - 0.3
2 - 0.35
3 - 0.350
6 - 0.349609
9 - 0.349609375

That's right, apparently 7/20 isn't what you thought it was, and 3DGS seems to generate numbers to 9 decimal places. It just so happened that 7/20 rounded to 0.350 (3 decimal places), but add any more and it doesn't become 0.350000, it becomes 0.349609. A few other people have come up with the same numbers, so I assume it's nothing to do with my computer, and the only thing left we have in common is 3DGS, which leads me to believe it's a bug/limitation in the engine.

Does anyone know why this might be, and if there's any way to do what I'm trying to do without taking every variable and rounding it in a separate function?

1 + random(20) won't get you numbers between 1 and 20. It will get you numbers between 1 and 20.999.

If you want something between 0.05 and 1, just use

0.05 + random(1-0.05);

That's right.

But what about:
Code:

---

var x;

x=7/20;  //0.35!!
....

---

I dont get 0.35 exactly when I use more then 3 decimal places:
->
0 - 0
1 - 0.3
2 - 0.35
3 - 0.350
6 - 0.349609
9 - 0.349609375


Is this a CPU problem (dont think so) a engine bug or a wrong/bad convertion from long (long, isnt it?) to var or something else?


nipx

Your first assumption was correct: it's a CPU problem.

A CPU stores numbers in binary representation. Converting binary to decimal, or vice versa, causes rounding errors depending on the precision the number is stored in. In case of var it's only 10 bits after the decimal.

http://en.wikipedia.org/wiki/Binary_numeral_system

http://manual.conitec.net/aarray.htm

The idea was it got me a number between 1 and 20.999, of which I took the integer with the int(). That integer was then divided by 20. I don't know much at all about Lite-C, but I've seen it's got different types of variables, like long, short and int - would these do that calculation properly?

As for 0.05 + random(1-0.05); that would give me any number between 0.05 and 1 right? I was looking to get a multiple of 0.05 between 0.05 and 1.

The problem is that there is no binary representation of 0.05, so you'll always get slight differences in the 3rd digit after the decimal.

For what reason do you need exact multiples of 0.05? If you want exact values you normally use integers.

You can use float and double in lite-C, which will be more precise than var, but you still won't get exact multiples of 0.05. The only language that I know of that supports unlimited precision is LISP.