Number.toFixed() not rounding per specification #1611
Replies: 18 comments
-
Posted at 2019-08-20 by Robin Tue 2019.08.20 This might be of some use to rule out a floating point issue, or cross check a 'C' snippet, by observing the actual mantissa value used at the point of desired rounding:
Adapted from snippet above for the Espruino tests
Value under test:
Still a bit of work to do with the actual manipulation of the mantissa. Also may be used for and related to post: References: > nice pictorial on bit layout in F.P. register > https://en.wikipedia.org/wiki/IEEE_754-1985 > https://en.wikipedia.org/wiki/Floating-point_arithmetic |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-22 by Robin Wed 2019.08.21 Using the IEEE 754 specification link in #2 above, and using those primitive tools, a pencil and paper, made an attempt at viewing the bits that are used to create the floating point representation of our discovered value that appears to be problematic. GOAL: Make a determination if the issue is with the functions that are performing the conversion, or isolate if the underlying floating point math is problematic. Using our initial value, we split into the fractional and the integer parts. Using the integer value, convert that to base 2 using a calculator, and also the hex equivalent for reference. The fractional part uses a iterative process of simple multiplication, and records the carry value, either a one or zero.
I only manually calculated 16 places as we really don't know how many bits will be required and quite frankly, is a tedious process.
We mentally save ten, the base 2 power and record both to use in subsequent calculations. Looking back at the @valderman Feb 2012 stackoverflow.com Step C Now we may start to assemble our F.P. register value. Bit 31 is the sign. B23-B30 is the exponent. Bit0-B22 holds the mantissa
Assemble the base 2 fractional part. Using the manual calculations from step 2
Step D Convert the stream of bits into the base we understand in hex notation
Now off to hand calculate the reverse process and build a simple snippet to check our work. Back in a bit (a long while) |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Robin Sat 2019.08.24
Attempting to uncover the source of this rounding error reminds of a book I read thirty years ago that had an impact on my career, if not more awareness to the world of computing. I was buried in electronics at the time, barely post tube era. (I hear the laughter now) oops, sorry proper web etiquette ROTF LOL Even remember the author, Clifford Stoll. Anyone with me? The Cuckoos Egg A true story that Cliff unravels tracking down $0.75 accumulated rounding error that leads him down the path tracking the crime in progress. And across a 1200 baud modem! Remember those days? Mesmerised over the step-by-step process to find the computer anomaly. Can't immediately put my hand on the hard copy I picked up later in the nineties, but did find a link. Isn't the web a marvelous place!! Grab a copy - worth the read Back to our Cuckoos Egg that is plaguing this discovered rounding issue. While cranking out routines to assist in building some data to analyze, I uncovered a slick online tool to create Floating Point values. I used this to cross check my manual register byte creation. Still need some looping functions to solve this anomaly though. From the following we can visually verify that the @valderman Feb 2012 snippet does in fact return consistent accurate results. Output from Chrome browser
Note the number of digits the browser presents to the right of the D.P. To determine if there might be any issues while adding, (remember we use the PC to perform the addition, which is using the same questionable Floating Point to perform that calculation) I added the summation intermediate step.
Note that the browser output renders up to 19 base ten numerals to the right of the D.P. and will default to 'E' notation when significantly small a value. ``` document.write( sum.toString(10) ); // it appears that the toString() function has no effect on the formatting in this case
Findings: Chrome output no format specifier, but 16 numerals past the D.P. and up to 19 used during rendering to get to this final value Espruino output no format specifier, but truncates (up to) 11 numerals 0.50499999523
// Espruino output [ 2^- 1 ] D:123456789012345678900.5 [ 2^- 8 ] D:123456789012345678900.50390625 [ 2^-10 ] D:123456789012345678900.5048828125 [ 2^-14 ] D:123456789012345678900.50494384765 [ 2^-15 ] D:123456789012345678900.50497436523 [ 2^-16 ] D:123456789012345678900.50498962402 [ 2^-17 ] D:123456789012345678900.50499725341 [ 2^-19 ] D:123456789012345678900.50499916076 [ 2^-21 ] D:123456789012345678900.50499963760 [ 2^-22 ] D:123456789012345678900.50499987602 [ 2^-23 ] D:123456789012345678900.50499999523 toFixed(2) // Espruino output
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Robin Sat 2019.08.24 Although I have spent a great deal of time in an attempt to resolve this rounding issue, I am currently behind on the skills and don't have the tools needed to perform a correction. I'm also waaaaaaay short on time to face the learning curve involved. In case I enter one of my sadistic moments to venture down a path of creating compilations, I've scanned
and it appears one could perform this task on a Windows10 PC. If I'm understanding this, I need a virtual PC to run a Linux OS image. Ubuntu is used to compile the files that are written in 'C'. Ubuntu runs Python scripts that perform the compilation. So far, am I on the right track? Then what is not clear, what tools are needed to perform debugging? My background from a decade ago was VStudio pre community edition, building web services in C/C++/C#. Any other intuitive assistance to get a good overview would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Wilberforce If you are on 64 bit Windows the best bet is to install WSL. Windows subsystem for Linux. It's in the Windows shop app. This gives you an Ubuntu shell window without needing to install Linux in a virtual machine. Once you are in the shell - do the In your ide, you can then connect to |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Robin
Yes, have that. Thank you @wilberforce, that helps in clearing that up. I'm sure others reading along will appreciate that info also. By "In your ide" does this imply a browser of my choice, or is this an IDE that will be available once Ubuntu shell is installed? Is a debugger available, or do we use the Chrome debugger? The biggest obstacle I see is attempting to traverse the 'C' logic in performing the rounding. I've uncovered these links: TO BE ADDED SHORTLY - EDIT see post #10 for functions and entry points BTW: This will be more of a winter project for me, as I really don't want to start meddling with the underlying source. Will also need to re-build my Linux skills along with telnet commands, quite an undertaking. However, as implied by post #4, this has been a tremendous learning experience in the understanding of how complex, just a simple addition instruction truly is under the covers. Most probably don't give a rat's expletive but it has clued me in to the complexity of what you guy's actually do. Thank's for that effort!! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by AkosLukacs Use WSL as @wilberforce already recommended. Or of course you can use an Ubuntu VM. You can use VS Code with the remote WSL extensions, makes modifying files much easier... Just install WSL, VSCode, "Remote - WSL" extension
One rookie mistake I did: don't try to use WSL in your regular windows file system (by default you are at something like As for debugging: AFAIK you won't be able to single step debug the Espruino code as easily as you could do from VS. There |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Robin Sun 2019.08.25 Thank you @AkosLukacs for the additional tidy summary.
Found this ten minute overview of GDB, which supplies the basics, and there is VSCode, Git and Bash to learn on top of it all. With only a basic introduction with RedHat over a decade ago, this process will feel like starting from scratch in an entirely new environment. Planning on chunking, maybe an hour a week, until I'm up to speed. With three Espruino projects in the works, will even have to delay that thought. A winter starter perhaps. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Robin Sun 2019.08.25 Links to areas of source that appear to be the entry points that will need a looksy: Definition GitHub source file for
JS_NUMBER_BUFFER_SIZE is suspect, but I'm not able to locate where that constant is defined ftoa_bounded_extra
> https://github.com/espruino/Espruino/blob/master
> https://github.com/espruino/Espruino/blob/master/src/jsutils.c
> https://github.com/espruino/Espruino/blob/master/src/jsutils.c#L614
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-25 by Robin Sun 2019.08.25 And just when one thinks every stone is over turned, more web searching digs up that others have found that
A link there over turns this relatively recent 'fix' - "Revision 1383484 of Math.round()" "Rounding 1.005 should have an expected result of 1.01, but it returns 1." So, what do we know so far for function toFixed()? by definition:
EXCEPT when it doesn't, then one must apply a patch that is only discovered when locating the recommended fix as suggested in revision 1383484. Pardon me while I go scream!! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-26 by Robin Mon 2019.08.26 I'm so hoarse, can't be heard, so decided to create that patch 'fix' as suggested. Used the standard rounding function which is recognized by most:
Interactive fiddle Demo > http://jsfiddle.net/jfriend00/kvpgE/ Tried it out in Chrome browser
Now we are on the right track, or are we??? Test using Espruino WebIDE
And, *SURPRISE*!! that failed. Is it the toFixed() or the actual Math.round() this time???
Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-26 by Robin Mon 2019.08.26 Now running on sheer insanity, and a will and determination to find an acceptable answer, found a jsFiddle solution that MDN recommends. A Closure that wraps the Math.round() function. Interactive Tried that out in the Chrome browser with it's own with embedded revealed steps
So we can confirm the confirmed MDN rounding of 1.005 now works in the browser. Now we have to be on the right track track this time, Right? Test using Espruino WebIDE
This time it appears to be the combination of the toString() function and toFixed() So there ya' have it. Even the MDN recommended closure that * IS * the Javascript solution to this (lack of) rounding anomaly, also fails. Don't shoot the messenger here. Remember, a month ago all I wanted was a reliable way to shift one bit left. Sheer persistence and digging got us this far. Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-27 by Robin Tue 2019.08.27 Anyone with a running 'C' compiler and debugger able to cross check these values please? Or any ideas to provide other helpful means that will assist in pin pointing what is going on? It is puzzling that Espruino and the Chrome browser produce near identical numerals to the right of the D.P. when hand calculated, or using the output value from the @valderman Feb 2012 snippet. Value Espruino - Single precision 32 bit: The online calculator produces a slightly greater value: Single precision 32 bit: I originally thought this might be that double precision was more accurate, as there are an additional 32 bits that when summed, would cause a higher value. But it can be seen that is not the case using the online calculator. surprisingly, the value is smaller |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-27 by @gfwilliams Hi, thanks for looking into this. I just had a look at the code involved and I believe I just fixed it: espruino/Espruino@3c700f9 If you try with the latest builds hopefully you'll have some luck. Floating point is a bit of a nightmare as any error could be:
If this comes up in future one solution might be to compare |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-28 by Robin Tue 2019.08.27 Thank you for the response @gfwilliams and Welcome Back! Hope it was fun and relaxing. Me, summer break is over and back to the salt mine this week, so limited available time now. I'll gather some more data that fails, in order to prove out the update when I get around to flash. I'll also create some cross check code after looking into the compare suggestion from #15 using Float64Array(). Then, I'll update the firmware and test, test, test. Also want to re-visit the other two posts involving rounding. From the line that was modified, seems to confirm my hunch that it wasn't in the underlying mechanism that creates the floating point equivalent, which was what I initially thought it appeared to be, two weeks ago. Was it a number typo (then) or was there a particular reason that value was chosen? Seems a possible typo. Still puzzled though, how that online calculator provides a slightly different higher mantissa value that does either the near matching Browser or Espruino tests. To confirm, to debug this would require the steps Wilberforce and AkosLukacs #6 #7 #8 #9 point out? Maybe will have time to push through that this winter. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-28 by @gfwilliams
Correct, yes.
I believe at the time it was a badly thought out attempt to ensure that digits further down the number didn't cause rounding - for example
https://www.exploringbinary.com/floating-point-converter/ says:
I'm not entirely sure on what it means there but on Espruino the The converter could quite happily store the integer and fractional parts as two arbitrarily long integers and then combine them at the end, and that would probably provide a more accurate number in a lot of cases.
It's worth playing with WSL anyway - it's really simple to compile Espruino in it, and you could then change the Espruino source to output the binary values of the number at each stage of the arithmetic. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-04-26 by user142686 It seems like Math.round() is a better solution, but it is not! In some cases it will NOT round correctly. Also, toFixed() will NOT round correctly in some cases. To correct the rounding problem with the previous Math.round() and toFixed(), you can define a custom JavaScript round function that performs a "nearly equal" test to determine whether a fractional value is sufficiently close to a midpoint value to be subject to midpoint rounding. The following function return the value of the given number rounded to the nearest integer accurately.
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-04-27 by andrewg_oz I realise this is a 3-year-old thread that has been dredged up, but since I find floating-point numbers interesting (as a professional programmer), I thought I'd leave this link to a website I find useful: https://www.h-schmidt.net/FloatConverter/IEEE754.html It demonstrates that in general floating-point numbers can almost never represent fractions exactly (see 'Value actually stored in float'). As a result, you will always be able to find edge cases where rounding is apparently being performed incorrectly. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-08-11 by Robin
Sun 2019.08.11
toFixed()
Does not round as does at the MDN siteThis rounds correctly in the try it window at Mozilla link above
From MDN Correct string representation and rounding
EDIT: @AkosLukacs documented two other samples in #4 #8
Had a thought, could this anomaly be related to the recent discovery of floating point number of digits to right of zero not matching different browsers and node.js output? hmmmm. . . .
EDIT: Tue 2019.08.20 Unable to verify with
toPrecision()
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toPrecisionVerified not a member of Number
Beta Was this translation helpful? Give feedback.
All reactions