Hi,

I have a problem with JavaScript function parseFloat.

when i am trying to convert a string which contains 15 digits and 2 decimal points("123456789012345.09") to number type using parseFloat function, it returns value wrongly like 123456789012345.1

eg:
var V1 = parseFloat("123456789012345.09");
here V1 value will be 123456789012345.1

like above parseFloat("123456789012345.99") will return 123456789012345.98
      parseFloat("123456789012345.96") will return 123456789012345.95

parseFloat function works wrongly if the number exceeds 14 digits with 2 decimal points, else it works fine.

i am facing this problem for some Scenarios, not for all conversions.

Need your help to solve this issue.

That's probably a combination of the accuracy of the numeric functions and also some values are not expressible exactly in binary. My approach would be to multiply the initial string by 100, this will try to cast the string as a number. If the result is NaN then it wasn't valid. What you do next depends on what you actually do with the number.

--

Joe (Microsoft MVP - XML)

Hi joefawcett,

In my application(ASP.net), the user will be entering the numeric values(like 123456789012345.09) in textbox, in some events(like onblur of textbox, onClick event on button) i will be capturing the textbox value which will be in string format and will convert to numeric type using parseFloat function to do some calculation.

i will be dealing with maximum of 8 decimal points.

also parseFloat("123456789012345.229") will return 123456789012345.23
     parseFloat("123456789012345.203") will return 123456789012345.2

as per your suggestion, how we can multiply the string with 100 or other in javascript?

Need your help to solve this issue.

I slightly misunderstood but I think you are simply running up against the limitations of JavaScript's arithmetic precision. See http://www.jibbering.com/faq/#FAQ4_7. There's probably a workaround, what do these figures represent? Can you move the logic to the server where a language such as C# will probably be more accurate?

--

Joe (Microsoft MVP - XML)