Rounding values after zeros
joshb
I have a length converter which converts mm, cm, m, km, ft, yd, in and
mi. If I convert 5mm to miles, I get 0.00000031068559649... miles. I'm
looking to convert all my values to two decimal spots, but if it comes
up zeros, I would like to round to two spots after the last zero. I've
looked through google and haven't found anything I could use yet, so I
was wondering if you guys had any scripts or any leads I could use to
make it.
Thanks in advance,
Josh.
Danny@Kendal
news:1122044728.6...@g43g2000cwa.googlegroups.com...
Try adding "significant digits" or "precision" to your searches.
I had a quick look around and I think
yournumber.toPrecision(2)
might do it.
eg: 0.00000031068559649
should become 3.1e-7
Nathan
how far the digits go out. I don't see any way to accomplish this
without the use of a RegEx.
mi = "0.00000031068559649";
mi_formatted = mi.match(/.+?\.0+.{2}/); // returns 0.00000031
I don't know how reliable this RegEx for your project, but its should
be a good start.
joshb
into 0.000044.
Thanks for the tip Nathan, I have something to work with now.
Dr John Stockton
, dated Fri, 22 Jul 2005 08:05:28, seen in news:comp.lang.javascript,
joshb <jbr...@gmail.com> posted :
In English, that would be rounding to two *significant figures*; if you
search for jargon terms, you'll only find jargoneers.
A search for "Rounding to N Significant Figures" and "Round to N
Significant Figures" should have found at least one of
<URL:http://www.merlyn.demon.co.uk/js-round.htm>
<URL:http://www.merlyn.demon.co.uk/js-demos.htm>
the latter now being better.
You should want a method which converts
0.0000006666 -> 0.00000067
0.0000006987 -> 0.00000070 with trailing zero.
<URL:http://www.merlyn.demon.co.uk/js-demos.htm#TF>, with 5/25.4/36/1760
in the input window, gives /inter alia/ :-
StrSigFigFxd +0.0000031
StrSigFigExp +3.1e-06
ShowSigned +0.00000310685596118667
FixedPoint +0.0000031
where the long number is not quite what you quoted. Since the
difference is not 2 ppm, it's hard to explain.
Read and test the code before using it; it's rather new.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
RobG
Either your conversion factor is wrong (or JavaScript maths functions
are not good enough for what you are after). To convert feet to
metres you multiply by exactly 0.3048.
1 mile = 5,280'
= 1,609.344 m
Using 20 significant digits and MS Excel:
0.005m/1,609.344m = 0.00000310685596118667 (miles)
^^^^^^
JS in Safari gave: 0.0000031068559611866696
Firefox gave: 0.0000031068559611866696
IE (Mac) gave: 0.000003106855961186667
All of which vary from the result you provided above, though not until
after 9 significant digits - which is within your tolerance of 2. I
think 3 is the norm in engineering.
--
Rob
Dr John Stockton
01.iinet.net.au>, dated Sat, 23 Jul 2005 15:25:35, seen in
news:comp.lang.javascript, RobG <rg...@iinet.net.auau> posted :
>
>Using 20 significant digits and MS Excel:
>
> 0.005m/1,609.344m = 0.00000310685596118667 (miles)
> ^^^^^^
I call that 20 decimal places and 15 significant figures.
My Windows 98 calculator gives 3.10685596118666984808717092181659e-6 ;
I sometimes wonder how it does arithmetic, and whether all functions are
as accurate as they purport to be.
The decimal mantissa of the true answer is, I think,
+3.1 068559611866698480871709218165911079296906
where the portion after the space repeats indefinitely.
Javascript specifies 64-bit IEEE Doubles, and standards suggest that
routine Double arithmetic should give the same 64 bits in any system,
unless some calculated value is really near half-way between two 64-bit
numbers. Therefore it is a little disconcerting to see non-identical
decimal results in your browsers and in mine.
I don't recall that the resolution of the conversion is stipulated; but
ISTM that there should be consensus on it.
The OP may be American : maybe the meter is not quite the same as the
metre?
cwdj...@yahoo.com
Dr John Stockton wrote:
> JRS: In article <42e1d4cf$0$21392$5a62ac22@per-qv1-newsreader-
> 01.iinet.net.au>, dated Sat, 23 Jul 2005 15:25:35, seen in
> news:comp.lang.javascript, RobG <rg...@iinet.net.auau> posted :
> >
> >Using 20 significant digits and MS Excel:
> >
> > 0.005m/1,609.344m = 0.00000310685596118667 (miles)
> > ^^^^^^
>
> I call that 20 decimal places and 15 significant figures.
>
> My Windows 98 calculator gives 3.10685596118666984808717092181659e-6 ;
> I sometimes wonder how it does arithmetic, and whether all functions are
> as accurate as they purport to be.
>
> The decimal mantissa of the true answer is, I think,
> +3.1 068559611866698480871709218165911079296906
> where the portion after the space repeats indefinitely.
>
>
>
> Javascript specifies 64-bit IEEE Doubles, and standards suggest that
> routine Double arithmetic should give the same 64 bits in any system,
> unless some calculated value is really near half-way between two 64-bit
> numbers. Therefore it is a little disconcerting to see non-identical
> decimal results in your browsers and in mine.
>
> I don't recall that the resolution of the conversion is stipulated; but
> ISTM that there should be consensus on it.
>
> The OP may be American : maybe the meter is not quite the same as the
> metre?
I wonder why you thought that the meter and metre might be different
other than in spelling. The modernized metric system known as Systeme
International d'Unites is of course the same in the US as in other
countries. The US signed the Meter Convention in Paris in 1875 along
with 16 other countries, and this support remains until present.
Non-metric units, such as miles, are defined in terms of the SI units.
Scientific work and publications are all in modern metric units. Some
engineers were taught in English units. Wine and spirits are now sold
in metric units in the US, but many other food items are still sold by
the pound or US quarts, for example.
The mile has been used in many countries and defined in different ways
for a very long time. Plese see
http://www.absoluteastronomy.com/encyclopedia/m/mi/mile.htm for some of
the history of the mile. One source of confusion can be between the
usual statute(international mile) and the survey mile used in the US,
because the conversion factor from one to the other is 0.999998
exactly. The details are in the reference I quoted.
______________________________________________________
http://www.cwdjr.net/calendar/perpetual_calendar3.html
______________________________________________________
RobG
[...]
>>The OP may be American : maybe the meter is not quite the same as the
>>metre?
>
> I wonder why you thought that the meter and metre might be different
> other than in spelling.
In the words of Foghorn Leghorn: "Heh, heh, that's a joke son".
> The modernized metric system known as Systeme
> International d'Unites is of course the same in the US as in other
> countries. The US signed the Meter Convention in Paris in 1875 along
That would be the Convention du Mètre.
[...]
> the history of the mile. One source of confusion can be between the
> usual statute(international mile) and the survey mile used in the US,
> because the conversion factor from one to the other is 0.999998
> exactly. The details are in the reference I quoted.
But that does not account for the difference noted. The bottom line
appears to be that JavaScript mathematical functions are implemented
slightly differently in different browsers on different platforms.
--
Rob
cwdj...@yahoo.com
RobG wrote:
> cwdj...@yahoo.com wrote:
> [...]
> > the history of the mile. One source of confusion can be between the
> > usual statute(international mile) and the survey mile used in the US,
> > because the conversion factor from one to the other is 0.999998
> > exactly. The details are in the reference I quoted.
>
> But that does not account for the difference noted. The bottom line
> appears to be that JavaScript mathematical functions are implemented
> slightly differently in different browsers on different platforms.
I did not say that the difference between the US survey mile and the
statute mile had anything to do with JavaScript math functions.
It would in fact be expected that javascript would give somewhat
different math results on different platforms when one considers the
last few significant figures. This is just what happens on large
computers. It is why different constants are given for different
computers in series calculations that wish to push the computer to the
limits. This has been done for many years. To know exactly what is
going on, one needs to know the details of how a computer is making
calculations at a machine level, and this information is not provided
completely by a higher level language such as C++ or Fortran or a lower
level language such as javascript. It is of course possible that some
version of a language, or some routine therein, may have errors in the
code that introduce error in addition to that imposed by the way the
computer works.
_____________________________________________________________
http://www.cwdjr.net/geometric/tile_layer4.html
_____________________________________________________________
cwdj...@yahoo.com
cwdj...@yahoo.com wrote:
> It would in fact be expected that javascript would give somewhat
> different math results on different platforms when one considers the
> last few significant figures. ---
Go to the test page at http://www.bugnet.com/alerts/bugalert9298.html
for an interesting test for 3 calculations. This page is ancient, being
last updated in 1998. However nothing appears to have changed
concerning math calculation accuracy using javascript since then. I
tested the page on 7 of the most recent computer browsers and the old
NN4. All give the same errors as one got back in 1998. However the
simulator for the old MSNTV 2.8 set top box gave exact values for 2 of
the 3 test cases. However you find it gives only 12 digits after the
decimal point, while the computer browsers all gave 13 places. When you
round off the computer browser results to 12 places, they are in
agreement with the MSNTV results. The reference points out that the
results are exact in Perl calculations. At the time, the browser makers
contacted claimed that the javascript math calculations were doing
exactly what they were supposed to do according to floating point
standards. If you round off properly, you will of course not have this
problem unless you are dealing with extremely large or small numbers in
some special cases. In the old days, most scientific calculations on
the IBM 370 were done in floating point in Fortran, while business
people used the Cobol program that was designed for business
calculations and did not alarm bean counters with things such as
$1.999999999999.