Small hiccup in ABS

[FellippeHeitor]

We're settled then ❤️

[Cobalt]

I would like to reiterate the points made above:
 - ABS's return type is the same as its argument, so you can't expect to get back a value that can't be represented in that width
 - The QB4.5 interpreter correctly gives an overflow error

And also note:
 - If you compile the program with Q4.5 and run the resulting binary you'll get the same behaviour experienced here (printing the most negative value), since compiled binaries don't have overflow checking.

With that all in mind I'm deeming this slightly surprising but not buggy behaviour.

so why does it not show the same behavior with integer64? the negative sign is removed in that case?

[Cobalt]

We're settled then ❤️

not really, cause if that is expected behavior then ABS with INTEGER64 is broken.

[FellippeHeitor]

I stand with Luke on that technicality.

[Cobalt]

So be it.

The wiki has been updated to NOTE this limitation of ABS to save future users the headache.

You may double check my wording to make sure I have it correct.

[FellippeHeitor]

Thanks for the wiki edit, it seems proper.

[SMcNeill]

Since we're bugward compatible, an easy user-function for this is:

FUNCTION Absolute## (x AS _FLOAT)
  Absolute## = SGN(x) * x
END FUNCTION

[Qwerkey]

Thanks everybody for clearing that up.

To the inveterate idiots of the community, it would not have occurred that ABS(-128) would ever be anything except 128, but now that you've explained that ABS() retains the variable type, we see that for a byte 128 -> -128.

You really shouldn't let technology loose on the unthinking!