Decimal Save Bug

ID:65769
 
Apr 23 2009, 4:08 pm
This issue has been marked as a duplicate of id:71751
BYOND Version:440
Operating System:Windows Vista Home Premium
Web Browser:Firefox 3.0.9
Status: Duplicate
This issue has been marked as a duplicate of id:71751
Descriptive Problem Summary:
When saving large amounts of data, decimals do not properly save. I tried to setup a direct demo of this bug, but it appears you need to save large amounts of data and/or various types. Simply saving a decimal alone, or saving it with a few other variables won't cause the problem.

Code Snippet (if applicable) to Reproduce Problem:
var/savefile/F = new("Players/[copytext(ckey(src.key),1,2)]/[ckey(src.key)][src.SaveSlot].sav")
F["SaveVersion"]<<GameVersion
//Many other variables here


Expected Results:
Decimal saves properly
SaveVersion = 8.2

Actual Results:
Decimal saves as a long non-exact amount
SaveVersion = 8.1999998092651367

Workarounds:
Save it as text and convert it back to a number after loading it.
Apr 24 2009, 10:36 pm
This is due to the way numbers are stored in memory. There is a limit to how precisely a number can be represented. This is also the reason why numbers are usually limited to 6 digits before you start seeing scientific notation. 1,000,000 is often shown as 1.0e+006 because it is longer than 6 digits. The function num2text(8.2) may return "8.2" due to rounding, but num2text(8.2, 19) may return something like "8.199999..." because you're telling it to show more than it can accurately display. The key is to try to keep numbers from going beyond 6 or 7 digits in length.
Apr 25 2009, 5:19 am (Edited on Apr 25 2009, 5:28 am)
Yota wrote:
This is due to the way numbers are stored in memory. There is a limit to how precisely a number can be represented. This is also the reason why numbers are usually limited to 6 digits before you start seeing scientific notation. 1,000,000 is often shown as 1.0e+006 because it is longer than 6 digits. The function num2text(8.2) may return "8.2" due to rounding, but num2text(8.2, 19) may return something like "8.199999..." because you're telling it to show more than it can accurately display. The key is to try to keep numbers from going beyond 6 or 7 digits in length.

I'm not using num2text to turn it into text, simply putting "[variable]". And the number I have is 8.2, its not 8.199... and rounding; its doing the opposite. Its also displaying past 6 digits in the decimal when loaded (into a text file).
Apr 25 2009, 6:39 am
If you get a long decimal, can't you just use round()? >_>
Apr 25 2009, 6:43 am
Super Saiyan X wrote:
If you get a long decimal, can't you just use round()? >_>

Or I could just save it as text and convert it to a number after loading like I said in the original post. Yay for workarounds? Granted 90% of using BYOND is finding workarounds for their half-functional systems, but that doesn't make this any less of a bug.
Apr 25 2009, 11:58 am
We would need a working demo to properly investigate this. However, I can tell you right now that it is almost certainly not an issue with BYOND but rather the way floating points are stored internally (the actual float stored will vary with the savefile, due to the storage format). More info: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.16