ID:2231726
 
Not a bug
BYOND Version:510
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 52.0
Applies to:DM Language
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
When rounding very small decimal fractions, the round function appears to interpret the value incorrectly.
Numbered Steps to Reproduce Problem:
1. Get a small decimal fraction, for example
var/x = cos(270)

round that value
round(x)

be surprised as the result is -1 and not 0

Code Snippet (if applicable) to Reproduce Problem:
var/x = cos(270)
world.log << x
var/y = round(x)
world.log << y


Expected Results:
0 - confirmed this with python3's maths implementation

$ math.cos(math.radians(270))
-1.8369701987210297e-16
$ round(math.cos(math.radians(270)))
0

Actual Results:
-1


I originally thought that it's interpreting the value in scientific notation incorrectly
i.e round(-1.83697e-16) -> -1

whereas the number is actually
-0.0000000000000001836970198 blah blah blah which would round to 0

But perhaps I'm just missing something more obvious about the round function that explains it.

Does the problem occur:
Every time

When does the problem NOT occur?
N/A

Workarounds:
round(x, 1) seems to fix the issue for our use case
actually I suppose this makes sense if byond round defaults to floor unless you give it a second argument of 1 ? In which case feel free to mark this as not a bug
round(num) = floor
round(num,1) = ceil
Nadrew resolved issue (Not a bug)
real_round that acts like round(num, 1) when
I think it's more the fact that round(num) equates to round(num,0) in the end. It's documented.
It is documented and I have read and understood this fact before, it's still suprising to me.

https://en.wikipedia.org/wiki/ Principle_of_least_astonishment
round(num, 1) is "round half up" rounding, not ceil.
round(num) is floor.
-round(-num) is -floor(-num) is ceil.