Im wondering why, whenever my real number gets to 140.52 it adds a 1.. so its, 140.521.... And when you get higher, 141.521 it becomes 141.522 any way to stop this, or change it somehow?
Im wondering why, whenever my real number gets to 140.52 it adds a 1.. so its, 140.521.... And when you get higher, 141.521 it becomes 141.522 any way to stop this, or change it somehow?
It could help to see your trigger, because it looks like a numeric problem.
The thing is, that for example a number such as 0.2 does not exist as a floating point number. It will convert to something like 0.19999998807907104 which is quite close to 0.2, but not exactly. That is because 0.2 is periodic in the binary system and the internal represenation of this number is finite and may be rounded. So it is always wise to use power of two numbers (if possible) like 0.0625, 0.125, 0.25, 0.5, 1, 2, 4, 8, 16, .... to avoid these problems.
@RileyStarcraft: Do you know if Starcraft 2 uses the IEEE 754 standard?
Imprecision generally comes from rounding. Computers don't work with our decimal system, so they don't exactly know 141.52, but they have to calculate it. These calculations can lead to rounding errors where the number slightly differs.
I have been using alot of reals and I have never had this problem.
how are you coming up with your value anyways.... are you doing multiplication/ division/ subtraction / or addition.
Reals are just what they are ... they are Numbers with decimals. You shouldnt see the number change on its own.
If you do 1.111111 + 1.111111
you should end up with 2.222222 It wont change on its own unless you tell it to round it or your doing some kind of division
Generally when you getting a value of a real and storing it as a real it asks you what precision you want to use. I generally set it to a precision of "2" this means that the number will always have two decimals..... It may round the 3rd or the 1000th's position and change the 100th's though.
PS: This precision thing when you're converting a real into a text/string only cuts off anything after x amount of decimal places.
So a precision of 1 doesn't make the calculation more imprecise, but only doesn't show you a part of it.
@s3rius:
Hi
I've got the same problem in my map, except my reals don't use any decimals.
I've got a trigger that makes a dialog fade away.
So it 's basically this :
-If Dialog's transparency <= 100.0
- Action : set dialog transparency = dialog transparency + 5.0
- Repeat
I've tested it out with text detecting the transparency, it never reached 100 but something like 9x,xxxx
And all I used was reals without decimals !
So I fixed it by using a "transparency <= 99" but I thought I'd let you know.
You could use an integer variable and convert it to a real when setting the transparency. If your using reals, there is something you should absolutely not do: compare if two of them are equal, because that might not happen. Always use a tolerance. In your case I would recommend something like:
fixed is a 32-bit fixed (as opposed to floating point) number where 19 bits are available in the integer portion, 12 bits are available in the fractional portion and 1 bit is giving the sign. In the Galaxy Editor GUI fixed is referred to as a real.
(231 - 1) / 4096 = 524287.999755859375 is the greatest fixed number.
-(231 - 1) / 4096 = -524287.999755859375 is the least fixed number.
2-12 = 1 / 4096 = 0.000244140625, is the smallest non-zero fixed number.
Reverting back to my second answer... Never compare if two Reals are equal.
Maybe there is another way to achieve your goal. What exactly are you trying to do and what goes wrong?
When and where does it change to .521? Does it happen in your label? If yes, then set the precision lower.
Or does it really create math problems in your script?
That's because Sc2 even "calculates" those numbers. The editor only knows multiples of 1/4096th. So if you enter 0.5 then the system will remember it as (2048/4096), but if you enter 0.51 then there might not be a multiple that is exactly this number, so it looks for one nearby.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Im wondering why, whenever my real number gets to 140.52 it adds a 1.. so its, 140.521.... And when you get higher, 141.521 it becomes 141.522 any way to stop this, or change it somehow?
@Pshyched:
http://en.wikipedia.org/wiki/Floating_point
@RileyStarcraft: Go
So you are saying, if i add another Decimal Point, no number will appear past the 140.52...?
Edit It dosent not work, it takes it straight back to 0.0
It could help to see your trigger, because it looks like a numeric problem.
The thing is, that for example a number such as 0.2 does not exist as a floating point number. It will convert to something like 0.19999998807907104 which is quite close to 0.2, but not exactly. That is because 0.2 is periodic in the binary system and the internal represenation of this number is finite and may be rounded. So it is always wise to use power of two numbers (if possible) like 0.0625, 0.125, 0.25, 0.5, 1, 2, 4, 8, 16, .... to avoid these problems.
@RileyStarcraft: Do you know if Starcraft 2 uses the IEEE 754 standard?
Starcraft's using Fixed points?
Imprecision generally comes from rounding. Computers don't work with our decimal system, so they don't exactly know 141.52, but they have to calculate it. These calculations can lead to rounding errors where the number slightly differs.
I have been using alot of reals and I have never had this problem.
how are you coming up with your value anyways.... are you doing multiplication/ division/ subtraction / or addition.
Reals are just what they are ... they are Numbers with decimals. You shouldnt see the number change on its own.
If you do 1.111111 + 1.111111
you should end up with 2.222222 It wont change on its own unless you tell it to round it or your doing some kind of division
Generally when you getting a value of a real and storing it as a real it asks you what precision you want to use. I generally set it to a precision of "2" this means that the number will always have two decimals..... It may round the 3rd or the 1000th's position and change the 100th's though.
@SouLCarveRR: Go
Actually 1.11111 + 1.11111 = 2.22217
Try it out :P
That's the rounding imprecision I was talking about.
well i dunno if 6 decimals is more then it can handle but..
1.11 + 1.11 should come out at 2.22 if your adding them together correctly
Think I might test this out later tonight but I woulda figured I woulda come across this sooner if it always behaves in this manner.
1.11 + 1.11 = 2.22021 :)
1.1 + 1.1 = 2.2002
1.0 + 1.0 = 2.0 w00t!
PS: This precision thing when you're converting a real into a text/string only cuts off anything after x amount of decimal places.
So a precision of 1 doesn't make the calculation more imprecise, but only doesn't show you a part of it.
You could use an integer variable and convert it to a real when setting the transparency. If your using reals, there is something you should absolutely not do: compare if two of them are equal, because that might not happen. Always use a tolerance. In your case I would recommend something like:
Where tolerance should be 0.1 or 0.01 or something like that.
or even better:
Take a look at this one then.... http://starcraftmapping.de/gui.php?id=51
Reals in galaxy are fixed: http://www.sc2mapster.com/api-docs/types/fixed/
They are just int divided by 4096 :)
Reverting back to my first question... how can i stop it from changing to a third number...
http://starcraftmapping.de/gui.php?id=51
Reverting back to my second answer... Never compare if two Reals are equal. Maybe there is another way to achieve your goal. What exactly are you trying to do and what goes wrong?
@Pshyched: Go
Is it only a visual problem? Then set the precision of the text in the labels to 2.
One way or another, Pfaeff is right. Try not to check if 2 reals are equal. Change it from == to <= or <.
No, the comparasin works fine, i compared em and they worked fine, but im trying to stop it from changing into 141.521...
@Pshyched: Go
When and where does it change to .521? Does it happen in your label? If yes, then set the precision lower. Or does it really create math problems in your script?
I don't think any math operations are required to lose precision. Sometimes entering real values into the data editor, I lose precision automatically.
@Ultimaswc3: Go
That's because Sc2 even "calculates" those numbers. The editor only knows multiples of 1/4096th. So if you enter 0.5 then the system will remember it as (2048/4096), but if you enter 0.51 then there might not be a multiple that is exactly this number, so it looks for one nearby.