Reals in SmileBasic
A real value in SB is probably closer to a 32-bit floating precision number. A Java "double" has greater precision than a SB real (64-bit). Thus, you'd do something like:
float mynum = 5.6; //same as VAR MYNUM# = 5.6Also, sorry for late reply. EDIT: a real is a double/float64, my bad
Actually, I'm pretty sure SB uses doubles.Really? I thought SB's variables were all 32-bit?
I don't think so, because reals have a different max value than ints. If reals were 64-bit and ints were 32-bit, it would make logical sense for them to have the same overflow.Sorry persson, you just have to concede here. Coleslaw is completely right: ints are sint32, reals are double. They wouldn't have the same overflow regardless since floats and ints have entirely different encodings. From what I can gather, the 3DS arch has a ARM VFP inside that does double, and the SB spec explicitly states they are double-precision. I haven't seen you provide concrete evidence to your claim. Care to?
Basically all I want is a high precision decimal number..Precision or accuracy? Like do you want a variable which can represent a number with a huge amount of decimal places or a ridiculous range (precision) or do you want a variable which will always be an exact value with no precision errors (accuracy)? If you just need big numbers and don't need high accuracy, use a double or float. Most of the time, double is probably what you want, as most libraries/etc. expect doubles (but it depends). If you want absolute accuracy, check out BigDecimal I know this is stupidly late, but may as well add some information for future viewers.
I haven't seen you provide concrete evidence to your claim. Care to?I don't have concrete evidence because I've never read the documentation XD I just kinda learn from chat, forums, and syntax errors.
A real-type should be more than good for a 3D calculation. You aren't going to need infinite precision, and the accuracy within the precision you need is rather high. Hope this all helped!snipI need a comma number with 32 bits and maybe 5 decimal places ex. 48559.36063 (For a nice and accurate 3D calculation :D) Thx for the java tip, but I just want to know for sb!
I can confirm the integers and reals because that's how many bits are used to store those types of values in DAT files.I believe it's... 32-bit for integers, 64-bit for reals, and 16 bits per character in strings. Is that right?Actually, I'm pretty sure SB uses doubles.Really? I thought SB's variables were all 32-bit?
(let the quoting engage XD) Yep, thanks :)A real-type should be more than good for a 3D calculation. You aren't going to need infinite precision, and the accuracy within the precision you need is rather high. Hope this all helped!snipI need a comma number with 32 bits and maybe 5 decimal places ex. 48559.36063 (For a nice and accurate 3D calculation :D) Thx for the java tip, but I just want to know for sb!
Here is a simple explanation of how floating-point numbers work.
Let's say you're working with some numbers. You have to make lots of calculations, and you HAVE to write down every single result. The rule is: you only have enough space for 10 digits for each number. But there's a problem! Some of your calculations result in numbers as small as 0.00000000001, and other calculations result in numbers as big as 1000000000000000000. 10 digits CANNOT be enough to represent all those different values!
So what you do is this:
let's say you did a calculation, and the result you get is 0.000012341234123412341234.
What you do is you start with the most-significant non-zero digit, and you write as many digits as you can:
1234123412
That's 10 digits.
In another number, you write where the decimal point is - or in other words, how significant is the most significant digit of the number you just wrote.
In this case, it would be 5 digits to the left of the whole number. When this number is read later, everyone knows that this number is equal to:
0.00001234123412
In another calculation, the number you get is 5432154321235456003738.231489662.
This number is HUGE. But again, you only have 10 digits, so you do the same procedure and the number you end up with is:
5432154321000000000000
This is the same scale as the original number, but a lot of the less-significant precision was lost. Still, for many real-world purposes, it's fine.
Floating-point numbers do exactly this, except they do it in binary rather than decimal. Double is the same as float, except it uses more space and therefore allows for much greater accuracy, but it still has a limit.
The main thing to remember is that if you're working with numbers as big as, say, 1000000000000000000000000000, and you try to add or subtract them with numbers like 1, it's probably not going to do anything. But when we're talking about 3D calculations, in a game, the tiny calculation errors that may occur is really meaningless.
Ok, just so this is crystal clear. Real numbers are represented as 64bit, double precision?
I think I'm misunderstanding this, because when I type:
VAR SOMENUM# = &HFFFFFFFF 'this one works, 32 bit VAR SOMEOTHERNUM# = &HFFFFFFFFFFFFFFFF 'this one produces a syntax error, 64 bitEven adding an extra nibble to the first one produces a syntax error, anything beyond the 32 bit boundary. Can someone explain this to me? I'm not expecting the value to be useful, but shouldn't I be able to store something in each bit?
Effectively, &H literal values have 'type' integer.
... I already know what a floating point number is. What's the point of your post?Well, firstly I didn't know that you knew. Secondly, the post wasn't specifically directed at you, someone else may have found value in it. And thirdly, it was very late at night when I typed it up, so there wasn't necessarily ever a point to begin with :P