17 replies to this topic

[infogulch]

Round(-0.001, 2) returns -0.00. How can i get 0.00?

SubStr(Round(-0.001, 2) + 0, 1, -4)

Whoa whoa whoa -- use Abs()

[infogulch]

I am rounding numbers to 2 decimal places. I want 0.00, not 0 or 0.000000.

Then use Abs before you use round.

Round(Abs(-0.001), 2)

MOD: This has gone a bit too far off topic imo, split to help?

[Lexikos]

Either of the following should do the job:

MsgBox % Round(Round(-0.001, 2), 2)
MsgBox % (n := Round(-0.001, 2)) = 0 ? "0.00" : n

The difference in behaviour is due to the use of ceil() from the C runtime instead of qmathCeil(), which iirc isn't 64-bit compatible. The following (C++) code returns -0.000000 when value is -0.001:

aResultToken.value_double = (value >= 0.0 ? qmathFloor(value * multiplier + 0.5)
	: qmathCeil(value * multiplier - 0.5)) / multiplier;

(qmathCeil and qmathFloor are now just macros which point at ceil and floor.)

Round(..., 2) uses _stprintf to format the number. Apparently the -0.00 result is intentional:

Note that the change is not a change to the double representation, but a change to printf (and other floating point output functions). They previously ignored negative zeros, but now they do not. This brings us into line with the relevant standards, in response to customer requests.
Source: Negative zero valid?

[Lexikos]

By the way, how does that comform to the IEEE standard?

I'm not familiar with the IEEE standard. Feel free to look it up if you're curious. (Edit: I was curious. I was unable to find a copy of the IEEE standard, but I did find something suggesting the return value of standard ceil() always has the same sign as its input.)

If negative zero is the standard, would it be logical then to expect that also Round(-0.1) returns -0.

When N is 0 or omitted, Round returns a pure integer, not a formatted floating-point numeric string. Integers have no way to represent negative zero.

Note that the expression (0.0 * -1.0) produces negative zero.

Is it intentional that comparison operations like equal cause this same effect.

What are you talking about?

[jaco0646]

[OffTopic]
The talk of negative zero reminded me that SetTimer treats 0 and -0 as equivalent, when the negative sign is supposed to indicate Run only once.
[/OffTopic]

[Lexikos]

Please provide an example.

x := Round(-0.001, 2)
MsgBox % x ; -0.00
if (x = 0)
    MsgBox zero
MsgBox % x ; -0.00

[Solar]

Sorry, I did remember wrong. It was -0.000000 and when using a function. Without comparison the function gives -0.00.

To be clear, this has nothing to do with -0.0 or the round function. The following example will give the same effect:

MsgBox % func()

func() {
    x := 1.0
    if (x) {
    }
    return x
}

Why? Well, based on the next example of a workaround, it seems to be a bug in the way return handles expressions:

MsgBox % func()

func() {
    x := 1.0
    if (x) {
    }
    return [color=red]([/color]x[color=red])[/color]
}

[Lexikos]

I see.

Well, based on the next example of a workaround, it seems to be a bug in the way return handles expressions

Return handles expressions just fine, but return x and return %x% (which are equivalent in v1) are not expressions.

Note that y := (x + 0) will have the same effect as if (x = 0): when the variable x is converted to a number, the result is stored in x's binary number cache. This "read-caching" is done in AutoHotkey Basic and AutoHotkey_L v1, but not v2. Similarly, if x contains only a pure number, an expression like (x . "") causes a string to be stored in x alongside the number. This is done in AutoHotkey Basic, AutoHotkey_L v1 and v2. So in v1, it's impossible to distinguish between x, y and z at the end of the following script:

;     NUM  STR  V1 | V2  NUM  STR
y := "1.000000" ; y    0    1      |      0    1
z := 1.000000+0 ; z    1    0      |      1    0
x := 1.000000   ; x    1    1      |      1    0
_ := y [color=red]+ 0[/color]      ; y    [color=red]1[/color]    1      |      0    1
_ := z [color=red]. ""[/color]     ; z    1    [color=red]1[/color]      |      1    [color=red]1[/color]

In AutoHotkey Basic, all return values from user-defined functions are strings, so your numeric string retains its format.

In AutoHotkey_L v1, the expression evaluator returns all variables as strings, so return (x) works in this case. However, if the return value (which is a string) is passed to something which requires a number (such as a particular COM object method), it will fail. On the other hand, return x bypasses the expression evaluator and uses the attributes of the variable to determine which type of value to return. If it contains a number, only the number is returned. This enables certain COM object methods to work correctly, but causes any special formatting of the numeric string to be lost. The behaviour of return (x) is correct from a backward-compatibility standpoint, but was actually unintentional. Conversely, the behaviour of return x was (perhaps misguidedly) intentional, but it breaks compatibility.

In v2, there is no number "cache". A variable can only have the "numeric" flag if it was originally assigned a number. If x contains a number, both return (x) and return x return only a pure number. Since Round(...,2) returns a string, x contains a string; both return (x) and return x return the original string. A numeric variable can also have a string component, but since SetFormat has been eliminated, the string component can be discarded and regenerated at any time.

Side note: passing the variable through SubStr prevents binary number caching from occurring.

func()
{
    x := Round(-0.001, 2)
    if (SubStr(x,1) = 0) {
    }
    return x ; -0.00
}

Additionally, if you use a quoted literal string, the comparison is always done alphabetically in v1 since v1 considers all quoted literal strings non-numeric. This prevents the expression from caching a number in x.

MsgBox, % Round2(-0.001)

Round2(x) {
    x := Round(x, 2)
    if (x = "-0.00")
        x := "0.00"
    return x
}