Num2Text not displaying the right number

ID:1377700
 
Sep 15 2013, 1:21 pm
Not a bug
BYOND Version:499
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 23.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 using num2text() in Dream Maker, converting this number '1234567890' to text with significant digits of 10 would return '1234567936 in Dream Seeker.

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
mob/Login()
 world << num2text(1234567890, 10)


Expected Results:
I expected '1234567890' to return as '1234567890' but as text.

Actual Results:

'1234567890' returned as '1234567936'

Does the problem occur:
Every time? Or how often? Every Time.
In other games? Possibly.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur? it always occurs.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

I truly don't know.

Workarounds: None.
Sep 15 2013, 1:30 pm
This isn't a bug. This is due to floating point inaccuracy.

BYOND's numbers are only accurate up to the around the 24th bit, which gives an effective accurate range of : 16777216

Again, as you can see, your number is a fair bit large that the upper threshold for accurate numbers:

0016777216
1234567890

Thus, it will suffer from a slight inaccuracy as it gets larger than that number.

This isn't a bug with BYOND --it's how computers work.
Sep 15 2013, 1:47 pm
clearly, BYOND should uses doubles and ints.
Sep 15 2013, 3:06 pm
i vote for bignums.
Sep 15 2013, 3:36 pm
I second big numbers!! :D
Sep 15 2013, 7:34 pm
Definitely a flaw with floats.

And bigger numbers would be a great feature. Double precision while slower, may also allow for better accuracy. Most systems should be able to handle double precision anyway.
Sep 15 2013, 7:35 pm
I wouldn't want double-precision by default. To be honest, the speed loss is not negligible.
Sep 16 2013, 6:05 am
Who uses num2text()? :|
Sep 16 2013, 6:20 am
Stephen001 resolved issue (Not a bug)
Sep 16 2013, 8:57 am
In response to Albro1
Albro1 wrote:
Who uses num2text()? :|

A few 'DBZ' games out there.
Sep 16 2013, 9:41 am
I used to use num2text in the past. However, I rarely use it these days.
Sep 16 2013, 10:01 am
Upgrading to doubles is probably a doable possibility, though it'd be a project for sure. (Network stuff would still stick with floats.) BYOND's all-purpose Value type is one byte for type, followed by four bytes for data, and the data for a number is a 32-bit floating point number. Jumping up to a 64-bit double would basically entail making all Values bigger, but obviously that would be wasted space for most types, most of which rarely use more than 2 bytes of their data section.

Because of byte alignments, Value is internally an 8-byte struct. If doubles were used for numbers, that would make it a 12-byte struct, so all Value storage would effectively jump up by 50% in memory use. Realistically, most of BYOND's memory usage is not in storing Values, so I expect the memory penalty would not be horrible.

Of course, this would have ramifications for other formats as well, like the .dmb format; the new 4-byte format supported in 500 would make this borderline possible, but currently nums aren't read in a way that would work, so more changes would be needed there. Savefiles would also need to be changed to hold doubles. So this is not a trivial change.
Sep 16 2013, 10:08 am
Speaking of promoting number accuracy, how about non-integer pixel-movement stuff? (step_x, step_y, step_size)

Unlike my deal with how super accurate the collision is along a line (which turned out to be a bug), I'm sure that this is an actual thing. :)

Also, floating point modulo.
Sep 16 2013, 11:05 am
Floating point modulo would disrupt some older games, as much as I'd like it. Scream of the Stickster makes use of the integer rounding.

As for floating-point pixel movement, I don't see that happening. That would require completely revamping how pixel movement works in terms of messaging, etc., as it's currently a 2-byte signed int for both pixel offsets and step offsets; revamping it the first time was hard enough. This isn't the sort of feature most games would ever need anyway.
Sep 16 2013, 11:07 am
In response to Lummox JR
Lummox JR wrote:
Floating point modulo would disrupt some older games, as much as I'd like it. Scream of the Stickster makes use of the integer rounding.

Is BYOND ever going to move away from supporting older games?
Sep 16 2013, 11:09 am
To top it off, it's easily done yourself leveraging the existing assets:

Requires: http://www.byond.com/developer/Ter13/DatumPoint

var
    point/workingpoint = new/point()
proc
    matrixstep(var/atom/movable/O,var/forcedir=null,var/matrix/m,var/step)
        workingpoint.Set(O)
        workingpoint.Add(m.b*step+m.c,m.e*step+m.f)
        var/atom/nl = workingpoint.getLoc()
        if(nl)
            var/d = forcedir
            if(d==null)
                d = get_dir(O,nl)
            . = O.Move(nl,d,workingpoint.getPixelX(),workingpoint.getPixelY())
            if(.)
                O.remainder_x = workingpoint.getRemainderX()
                O.remainder_y = workingpoint.getRemainderY()
            else
                var/mx = workingpoint.x+O.bound_width
                var/my = workingpoint.y+O.bound_height
                if(workingpoint.x<1||workingpoint.y<1||round(mx)>=world.maxx*TILE_HEIGHT||round(my)>=world.maxy*TILE_WIDTH)
                    O.Bump(null)
        else
            O.Bump(null)
            return 0


It takes up next to no CPU to do this too, so I really don't see it being too far outside of the DIY realm.