SC2Mapster

So from what I see, the editor only has a rounding function for reals that rounds it to 0 decimal places. I tried making a custom function to round Reals to ONE decimal place, by taking the number multiplying it by 10.0, rounding to 0 decimal places (using the native funct), then divide by 10.0, but that sometimes results in something like 2.0999999, and whenever I try to change "10.0" to "10.0000000", it auto-corrects it back to "10.0". So... how can I round to only ONE decimal place?

Something like this also should work (Use Modulo (real) function):

real mod;
mod = n modulo 0.1;
if (mod<0.05){
	n = n-mod;
}else {
	n = n-mod+0.1;
}

Quote from DeltaV: Go

Something like this also should work (Use Modulo (real) trigger):

real mod;
mod = n modulo 0.1;
if (mod<0.05){
	n = n-mod;
}else {
	n = n-mod+0.1;
}

That's how I would do it in normal, text-based code, but I never could figure out how to use % in the editor. How do I access it??

@PerAnimus: Go

The "Modulo (real)" function.

Alright guys, I've tried everything I can think of and I'm extremely frustrated by this point. The problem is that EVERY TIME, the number ends up showing as 2.8999 or 4.0001 or whatever but I really just can't figure out how to get this to work :/ Tried Modulo, manually adding/subtracting like above, multiplying by 10, dropping off the decimal, and dividing by 10, converting to string and back, etc etc etc

Convert to string > convert back to real.

Melee Initialization
    Events
        Game - Map initialization
    Local Variables
        real = 0.0 <Real>
        string = "" <String>
    Conditions
    Actions
        Variable - Set real = 1.2569
        Variable - Set string = (String(real) with 2 decimal places)
        Variable - Set real = (Real(string))
        UI - Display (Text(real) with Any Precision decimal places) for (All players) to Chat area

Quote from DogmaiSEA: Go

Convert to string > convert back to real.

Melee Initialization
    Events
        Game - Map initialization
    Local Variables
        real = 0.0 <Real>
        string = "" <String>
    Conditions
    Actions
        Variable - Set real = 1.2569
        Variable - Set string = (String(real) with 2 decimal places)
        Variable - Set real = (Real(string))
        UI - Display (Text(real) with Any Precision decimal places) for (All players) to Chat area

I already tried this :/ But nonetheless, copied yours EXACTLY and it doesn't work. Using the numbers:

A) 2.9876

B) 2.92

C) 2.8744

D) 2.2123

E) 2.4236

The results were:

A) 2.99 instead of 3.0

B) 2.9199 instead of 2.9

C) 2.8701 instead of 2.9

D) 2.1201 instead of 2.2

E) 2.4199 instead of 2.4

Multiply it by 10.

Convert it to an integer.

Convert it back to a real.

Divide it by 10.

It was meant to be used in conjunction with the previous mod system.

EDIT>

@ Tya's solution, this is the way to do it if you don't want to use a modulo system.

Quote from TyaStarcraft: Go

Multiply it by 10.

Convert it to an integer.

Convert it back to a real.

Divide it by 10.

@TyaStarcraft: Go

If you do that 2.89 would be rounded to 2.8 instead of 2.9 (Would be fine if he wanted to always round down)

@PerAnimus: Go

I'm pretty sure it's showing as slightly off because the reals are stored as base 16, and as such cannot be represented with perfect decimal precision. (Actually 12 bit decimal part, see Jademus' post)

So your problem is not your rounding methods, but how the reals are being represented.
For example, if you set a real value to 2.9 and then without doing anything to it, display it with ANY precision, it will show as 2.8999.

So when you convert reals to text in game you should just set the precision to 2 decimal places if you want to show the approximate decimal value.
E.g. instead of
UI - Display (Text(real) with Any Precision decimal places)
use:
UI - Display (Text(real) with 2 decimal places)

Always aim for constant computational complexity, whenever possible.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

//** Round value f to nearest increment.
fixed RoundIncrement (fixed f, fixed increment) {
    return Round(f/increment)*increment;
}

//** Round value f to specific place value.
//      +place value for whole places
//      -place value for fractional places
fixed RoundPlace (fixed f, int place) {
    return RoundIncrement(f,Pow(10,place));
}

//** Round value f to nearest tenths.
fixed RoundTenths (fixed f) {
    return RoundIncrement(f,0.1);
}

As for misinformation about the fixed-point Real, learn the bit widths.

Quote from DeltaV: Go

@TyaStarcraft: Go

@TyaStarcraft: Go

If you do that 2.89 would be rounded to 2.8 instead of 2.9 (Would be fine if he wanted to always round down)

Good catch, I didn't notice that.

Quote from JademusSreg: Go

As for misinformation about the fixed-point Real, learn the bit widths.

Thanks for that.

@DeltaV: Go

Is that so? That sounds more like a bug in StarCraft then, because that is some terrible maths.

Edit: Just tested it and it's true. 4.26 becomes 4.2. What curious design.

Fixed-point represents arbitrary real numbers rather poorly, but can represent multiples of 1/4096 with 12 decimal digits precision, and can alternately be thought of as a 32-bit integer divided by 4096. Fixed-point arithmetic produces less unintuitive results when the input values are 1/4096 multiples instead of arbitrary real numbers, so one should input such multiples when coding.

4.26 / (1 / 4096) = 17448.96; 17448 / 4096 = 4.259765625;
2.718281828459 / (1 / 4096) = 11134.082369368064; 11134 / 4096 = 2.71826171875

@PerAnimus: Go

More about......Rounding decimal places

William