-
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:
by @valderman Feb 2012
https://stackoverflow.com/questions/9383593/extracting-the-exponent-and-mantissa-of-a-javascript-numberAdapted from snippet above for the Espruino tests
function getNumberParts(x) { var float = new Float64Array(1), bytes = new Uint8Array(float.buffer); float[0] = x; var sign = bytes[7] >> 7, exponent = ((bytes[7] & 0x7f) << 4 | bytes[6] >> 4) - 0x3ff; bytes[7] = 0x3f; bytes[6] |= 0xf0; return { sign: sign, exponent: exponent, mantissa: float[0], } } tests.forEach(function(x) { var parts = getNumberParts(x), value = Math.pow(-1, parts.sign) * Math.pow(2, parts.exponent) * parts.mantissa; console.log( "sign= " + parts.sign + " exp= " + parts.exponent + " man= " + parts.mantissa ); console.log( "Testing: arg= " + x + " calc= " + value ); });Value under test:
var tests = [1234.505]; sign= 0 exp= 10 man= 1.20557128906 Testing: arg= 1234.505 calc= 1234.505 =undefined >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 -
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.
Step A
Convert the Integer part to it's equivalent in base 2var kwh = 1234.505; Convert to F.P. Step A Integral part 1234 base 10 = 0100 1101 0010 base 2 == 0x04D2 Fractional Part 0.505 0.505 x 2 = 1.01 1 0.01 x 2 = 0.02 0 0.02 x 2 = 0.04 0 0.04 x 2 = 0.08 0 0.08 x 2 = 0.16 0 0.16 x 2 = 0.32 0 0.32 x 2 = 0.64 0 0.64 x 2 = 1.28 1 0.28 x 2 = 0.56 0 0.56 x 2 = 1.12 1 0.12 x 2 = 0.24 0 0.24 x 2 = 0.48 0 0.48 x 2 = 0.96 0 0.96 x 2 = 1.92 1 0.92 x 2 = 1.84 1 0.84 x 2 = 1.68 1I only manually calculated 16 places as we really don't know how many bits will be required and quite frankly, is a tedious process.
Step B
Normalize that integer part (move the D.P. in this case left) so we have a value of one multiplied by it's base 2 power equivalent. We are after the resultant power which is used as an index.0100 1101 0010 Step B Normalize - move D.P. left 10 places // we drop the leading zero in the initial value 1.00 1101 0010 base2 x 2 ^10 We moved the D.P. ten places left which is the equivalent of multiplying one and the fractional part by 2 ^ 10We mentally save ten, the base 2 power and record both to use in subsequent calculations. Looking back at the @valderman Feb 2012 stackoverflow.com
getNumberParts(x)function from #2 above, we now can validate that the power 10 does match.
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 mantissa1 bit sign 8 bit exponent 23 bit mantissa reg 0 00000000 0000000000.....bit0 31 30 22 0 msb lsb msb lsbAssemble the base 2 fractional part. Using the manual calculations from step 2
mantissa is formed using the original adjusted exponent 00 1101 0010 followed by 1000 0001 0100 0111 23 bits mantissa reg 0 10001001 0011010010.....bit0 31 30 22 0 msb lsbmsb lsb
Step D
Convert the stream of bits into the base we understand in hex notationF.P. 0 1000 1001 0011 0100 1010 0000 0101 000 Separating by four bits, 0xF we now have 0100 0100 1001 1010 0101 0000 0010 1000 we can easily see the hex equivalent of 0x449A 5028 // this is our Floating Point equivalent value in hex for // our base 10 value of 1234.505 // that is the value used in the register performing F.P. calculations // make sure not to confuse with the human readable // hex equivalent 0x04d2 or 1234 which when converted to human readable form is 0x449A 5028 base 16 equiv - as a floating point value not the original number 1234.505 1150963752 base 10
Now off to hand calculate the reverse process and build a simple snippet to check our work.Back in a bit (a long while)
-
Sat 2019.08.24
Took a bit longer than I anticipated
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
significand= 001101001010000001010001111010111000010100 significand= 01234567890123456789012345678901 // array element index reference only // we have a sign bit, eight exponent bits, followed by the significand, // the string of bits we are after starting at element 10 2^0 = 1 add leading implicit 1 // we would use the above for our decimal representation str = [ 10000001010001111010111 ] [ 2^ -1 ] 0.5 [ 2^ -8 ] 0.00390625 [ 2^-10 ] 0.0009765625 [ 2^-14 ] 0.00006103515625 [ 2^-15 ] 0.000030517578125 [ 2^-16 ] 0.0000152587890625 [ 2^-17 ] 0.00000762939453125 [ 2^-19 ] 0.0000019073486328125 [ 2^-21 ] 4.76837158203125e-7 [ 2^-22 ] 2.384185791015625e-7 [ 2^-23 ] 1.1920928955078125e-7 sum = 0.5049999952316284
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.
I've added the element location beneath the addend to ease locating elements ref D:0123456
// Chrome browser 2^0 = 1 add leading implicit 1 str = [ 10000001010001111010111 ] [ 2^-1 ] 0.5 - - - - - - - - - - - - - - - - - - - - 0.5 [ 2^-8 ] 0.00390625 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.50390625 [ 2^-10 ] 0.0009765625 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.5048828125 [ 2^-14 ] 0.00006103515625 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.50494384765625 [ 2^-15 ] 0.000030517578125 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.504974365234375 [ 2^-16 ] 0.0000152587890625 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.5049896240234375 [ 2^-17 ] 0.00000762939453125 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.5049972534179688 [ 2^-19 ] 0.0000019073486328125 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.5049991607666016 [ 2^-21 ] 4.76837158203125e-7 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.5049996376037598 [ 2^-22 ] 2.384185791015625e-7 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - 0.5049998760223389 [ 2^-23 ] 1.1920928955078125e-7 D:12345678901234567890 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - D:12345678901234567890 0.5049999952316284 toFixed(2) 0.50 // Chrome browser
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 document.write( sum );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 0.5049999952316284 Espruino output no format specifier, but truncates (up to) 11 numerals 0.50499999523
Now let's compare to the Espruino output
// Espruino output 2^0 = 1 add leading implicit 1 [ 2^- 1 ] 0.5 D:12345678901234567890 ------------------------- 0.5 [ 2^- 8 ] 0.00390625 D:12345678901234567890 ------------------------- 0.50390625 [ 2^-10 ] 0.0009765625 D:12345678901234567890 ------------------------- 0.5048828125 [ 2^-14 ] 0.00006103515 D:12345678901234567890 ------------------------- 0.50494384765 [ 2^-15 ] 0.00003051757 D:12345678901234567890 ------------------------- 0.50497436523 [ 2^-16 ] 0.00001525878 D:12345678901234567890 ------------------------- 0.50498962402 [ 2^-17 ] 0.00000762939 D:12345678901234567890 ------------------------- 0.50499725341 [ 2^-19 ] 0.00000190734 D:12345678901234567890 ------------------------- 0.50499916076 [ 2^-21 ] 0.00000047683 D:12345678901234567890 ------------------------- 0.50499963760 [ 2^-22 ] 0.00000023841 D:12345678901234567890 ------------------------- 0.50499987602 [ 2^-23 ] 0.00000011920 D:12345678901234567890 ------------------------- 0.50499999523 toFixed(2) 0.50 // Espruino output
Using our online floating point generator, we can see that our input of1234.505using either precision presents a number that should round to the hundredths place. The value1234.5050048828125contains enough bits to the right of our last thousandths numeral '5' to allow for a round up. During the conversion back to decimal, several bits beyond2^-23are lost, leaving us with a value that is just shy of our original '5' thousandths place.1234.50499999As I have hand coded two examples and we have the @valderman stackoverflow snippet as an additional cross check, I'm
0.9987654321 x 10^2 %certain that the Floating Point mechanism works near flawlessly, as one would expect, making the assumption that proven underlying 'C' Math libraries are accurate and used.
But, still a bit puzzling is that Espruino and the Chrome browser produce near identical numerals to the right of the D.P.
Espruino - Single precision 32 bit:0.50499999523
Chrome - Single precision 32 bit:0.5049999952316284The online calculator produces a slightly greater value:
Single precision 32 bit:
1234.505004882812
Double precision 64 bit:1234.5050000000001091393642127513885498046875
As the conversion to and from F.P. introduces a slight bit of error, It would be nice if we had a right of the D.P. adder that works using integers only. This could assist in resolving if there is additional slop during the summation of the equivalent right of D.P. bits. Anyone up for the task to create that little wonder, while I battle cleaning up these snippets to allow posting here?
The Html code file presents the conversion to a floating point value and uses color hinting to show the concatenation of bits to form the register value used in math calculations. It was a quick hack to compare summation output against Espruino output. Nothing fancy. Needs a bit of refactoring and renders more of a what's going on under the hood. Can be used to check conversions back to decimal along with toFixed() checks.
1 Attachment
-
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
https://github.com/espruino/Espruino
https://github.com/espruino/Espruino/blob/master/README_BuildProcess.mdand 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.
-
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
apt-getto install the build tools as per the Linux instructions. Then you can just amakeand build the Linux version of espruino, which you can then run with./esprunio --telnetIn your ide, you can then connect to
localhost:2323to connect to this install running in Linux on top of Windows. -
'64 bit Windows'
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!!
-
• #8
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
- Start a new VSCode & launch WSL
- open the terminal in VSCode
cd ~(if you are not there by default)git clone https://github.com/espruino/Espruino.git- Press the "Open Folder" button
- and follow the Linux instructions :)
One rookie mistake I did: don't try to use WSL in your regular windows file system (by default you are at something like
/mnt/c/something==c:\something). Clone the Espruino repo into a WSL directory, otherwise bash scripts just went crazy.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
gdb, but that itself has a steep learning curve afaik. - Start a new VSCode & launch WSL
-
Sun 2019.08.25
Thank you @AkosLukacs for the additional tidy summary.
'There gdb, but that itself has a steep learning curve afaik.'
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.
-
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
toFixed()https://github.com/espruino/Espruino/blob/master/src/jswrap_number.c#L120
JsVar *jswrap_number_toFixed(JsVar *parent, int decimals) { if (decimals<0) decimals=0; if (decimals>20) decimals=20; char buf[JS_NUMBER_BUFFER_SIZE]; ftoa_bounded_extra(jsvGetFloat(parent), buf, sizeof(buf), 10, decimals); return jsvNewFromString(buf); }
JS_NUMBER_BUFFER_SIZE is suspect, but I'm not able to locate where that constant is defined
ftoa_bounded_extrahttps://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#L614void ftoa_bounded_extra(JsVarFloat val,char *str, size_t len, int radix, int fractionalDigits) { // possible areas that end of array may be encounteredjsvGetFloathttps://github.com/espruino/Espruino/blob/master
https://github.com/espruino/Espruino/blob/master/src/jsvar.c#L1867JsVarFloat jsvGetFloat(const JsVar *v) { // too many lines and entry points to list here -
Sun 2019.08.25
And just when one thinks every stone is over turned, more web searching digs up that others have found that
toFixed(2);is problematic between different browsers and have concluded the safest method is to use your own rounding function, 'just to be sure!'https://stackoverflow.com/questions/10015027/javascript-tofixed-not-rounding
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:
'The number is rounded if necessary, and the fractional part is padded with zeros if necessary so that it has the specified length'
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed
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!!
-
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:
var roundedNum = ( Math.round( num * 100 ) / 100 ).toFixed( place );
Interactive fiddle DemoTried it out in Chrome browser
num= 1.005 place=2 roundedNum= 1.00 num= 1234.505 place=2 roundedNum= 1234.51
Now we are on the right track, or are we???Test using Espruino WebIDE
num= 1.005 place=2 roundedNum= 1.00 num= 1234.505 place=2 roundedNum= 1234.50
And, SURPRISE!! that failed. Is it thetoFixed()or the actualMath.round()this time???
2 Attachments
-
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
1.005 p2 inside Math.round10(value, exp); val=1.005 exp=-2 inside decimalAdjust() type=round val=1.005 exp=-2 inside decimalAdjust() shift val=1.005 inside decimalAdjust() shift val=101 inside decimalAdjust() shift back val=101 inside decimalAdjust() shift back ret=1.01 inside Math.round10(value, exp); decimalAdjust() ret=1.01 Math.round10(1.005, -2); = 1.01 1234.505 p2 inside Math.round10(value, exp); val=1234.505 exp=-2 inside decimalAdjust() type=round val=1234.505 exp=-2 inside decimalAdjust() shift val=1234.505 inside decimalAdjust() shift val=123451 inside decimalAdjust() shift back val=123451 inside decimalAdjust() shift back ret=1234.51 inside Math.round10(value, exp); decimalAdjust() ret=1234.51 Math.round10(1234.505, -2); = 1234.51
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
1.005 p2 inside Math.round10(value, exp); val=1.005 exp=-2 inside decimalAdjust() type=round val=1.005 exp=-2 inside decimalAdjust() shift val=1.005 inside decimalAdjust() shift val=100 inside decimalAdjust() shift back val=100 inside decimalAdjust() shift back ret=1 inside Math.round10(value, exp); decimalAdjust() ret=1 Math.round10(1.005, -2); = 1 1234.505 p2 inside Math.round10(value, exp); val=1234.505 exp=-2 inside decimalAdjust() type=round val=1234.505 exp=-2 inside decimalAdjust() shift val=1234.505 inside decimalAdjust() shift val=123450 inside decimalAdjust() shift back val=123450 inside decimalAdjust() shift back ret=1234.5 inside Math.round10(value, exp); decimalAdjust() ret=1234.5 Math.round10(1234.505, -2); = 1234.5
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.
2 Attachments
-
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
1234.505Espruino - Single precision 32 bit:
0.50499999523
Chrome - Single precision 32 bit:0.5049999952316284The online calculator produces a slightly greater value:
Single precision 32 bit:
1234.505004882812
Double precision 64 bit:1234.5050000000001091393642127513885498046875I 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
-
Hi, thanks for looking into this. I just had a look at the code involved and I believe I just fixed it: https://github.com/espruino/Espruino/commit/3c700f9d92e73d08dc28a60abd29915a8abd9499
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:
- conversion of a text string to floating point
- the actual floating point maths
- conversion of floating point to text
If this comes up in future one solution might be to compare
(new Float64Array([1234.50])).bufferwhich gives you the dependable, non-fuzzy binary representation of the underlying floating point number. - conversion of a text string to floating point
-
Tue 2019.08.27
Thank you for the response @Gordon 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.
-
it wasn't in the underlying mechanism that creates the floating point equivalent
Correct, yes.
Was it a number typo (then) or was there a particular reason that value was chosen?
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
0.5549 -> 0.56. Of course because it works in at least 90% of cases it wasn't immediately apparent that there was an issue.how that online calculator provides a slightly different higher mantissa value that does either the near matching Browser or Espruino tests.
https://www.exploringbinary.com/floating-point-converter/ says:
It is implemented with arbitrary-precision arithmetic, so its conversions are correctly rounded
I'm not entirely sure on what it means there but on Espruino the
stringToFloatWithRadixfunction uses repeated multiply and add with floats to convert the number, and multiply/divide by 10 is a particularly bad thing to do for accuracy.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.
To confirm, to debug this would require the steps Wilberforce and AkosLukacs #6 #7 #8 #9 point out?
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.
-
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.
Number.prototype.roundTo = function(decimal) { return +(Math.round(this + "e+" + decimal) + "e-" + decimal); } var num = 9.7654; console.log( num.roundTo(2)); //output 9.77 -
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.
Wilberforce
AkosLukacs
Gordon
user142686
andrewg_oz-
Post a reply
About
Number.toFixed() not rounding per specification
Posted 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()Verified not a member of Number