Math.PI.toString(16) -> 3.243f6a8885a3 and back
in [JavaScript]
|
Prev: Firefox cache issue
Next: FAQ Topic - How do I format a Number as a String with exactly 2 decimal places? (2010-05-27)
From: Ry Nohryb on 28 May 2010 10:21 On May 28, 3:53 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Ry Nohryb wrote: > > Thomas 'PointedEars' Lahn wrote: > >> Ry Nohryb wrote: > >> > parseFloat(Math.PI.toString(33), 33) > >> > --> NaN > > >> I cannot confirm this. Where have you tested it? > > > Safari / Mac: > > navigator.userAgent > > --> "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us) > > AppleWebKit/534.1+ (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7" > > Thanks, I am seeing this in Google Chrome 5.0.375.55 beta for Linux (V8 > 2.1), too. > > The reason of this is apparently that the fractional part of > "3.4m6dn4ow9qwe210nr3u0cdqkcnrbmwlh7kmfeapn9fijt38kie44jvdqh2vfrd6ogbvu > rnjq2bqkbr01f97av5k7uaffclrl3hmt2glugpaqe422qgfn81ca8pa73pmt51ewqo9234c > km2twg1qgwmahsv1pdti9bug3bjc9w0sn9ul421p5aanjnfuab9rq3bm5lchsu5aq6000no > i5wcf9c5p5idkgclha9j05bcupqqcb9h08dc3i2v2qcqjks96pgpkmangnavpt7tk6kvrfo > s0qq63iqrgv5nu2i8goh8tjmifwbwf9t3bvcd4r61tbqa05ca16ql0icacmucfcl1h3ceb1 > hrdmhhmsp8ri842wn3nj97v7r5i9mdv135qo5jd9bn9chun8n1h11qlgt35mqksnn8ef4p6 > kdade1d2t1bfigevwtjnjufm5sc9vhgq7qusio03g1ctrgmukjj5frghkmw1f1dhl4hvr7c > 8slmplk66fb34twd9dwkvb16dfi8lbq8nvftmvwo2o4aukf0d252v3go1gtbgfbj8qoqtsf > 8hpkkdfw9w686je30nmk6ojecalbc9ifs533e4gucpivw3327b1rc8a7qvqplce4o5agc9s > 9h64lia1bker9hhbj7tq6saw68e7c6nqo37v97nbgl8bcgniv3g7ebvrwufnuqsqhlk6fee > 7nsj348jwe0nstlnrjcet17sdksk7fo81rwtn6tknpo7lmcmskd4t5lebji6h6riabtauul > s2d49kgak0cu02fbwfklvn6jdlchkn7uwfa7qvncrfrw2umrhpja4hkwgrm261o8cf67c0a > lckiq428lpcvnjub55qkp15l90pbd47w9tupnf87iwjt8stpccka0scrqi7o6v8vmn1b73c > 9f4r4g3m11ofcdw5rq7rv89s69mnoumfpark413hsogn5lb4qawo789t7oet5kfolb9ltn9 > wm4iqlhi1glc5e2nd9q6jc6dghqcr5epkf2fde1rpd3ii2ouj7bq0pn16n4l28b85thc8ob > 3bi7debdwogfnhfaif0v6h4k2i9k39fkrvmlc", which is the 33-ary representation > of Math.PI there, is parsed (because of its length) into `Infinity', while > in JavaScript 1.8.2 the representation is rounded to "3.4m6dn4ow9r" and > therefore the fractional part is not parsed into `Infinity'. > > Therefore, it appears to be prudent to truncate the fractional part so that > it is not parsed into `Infinity'. A simple solution is to restrict the > number of characters matched by the regular expression, like: > > ... new RegExp("\\.([" + chars + "]{1,10})", "i") ... > > A more sophisticated solution would be an adaptive algorithm that uses only > as many characters as possible so that the result would not be `Infinity' > given the numeric base. An implementation of that might be available > through the Mozilla sources. No. A "more sophisticated solution" is to fix your broken algorithm: you're parsing an amount which is less than 1 as an (probably) enormous integer and then dividing it by another (probably) enormous integer. That's the problem, not Chrome, your algorithm is the culprit. You're, as usual, heavily disoriented. > BTW, in case you have not noticed yet, like Safari, Chrome has a Developer > menu (in the first main menu, below the Encoding menu item), which provides > access to the Developer tools, including a script console and a debugger > (which helped me to track this down). That makes using Firebug Lite in > Chrome unnecessary. You're telling me ? See: http://groups.google.com/group/comp.lang.javascript/msg/8e76deb9e1bc4441 -- Jorge.
From: Ry Nohryb on 28 May 2010 10:22 On May 28, 3:25 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > > Personally, I consider his suggestions interesting and enlightening. > I wouldn't use them in production code destined to be maintained by > cheap labour, but then, this newsgroup is hardly entirely about writing > Web applications in an industrial environment, is it now ? (If it is, > where can I find discussions about the computer language javascript ?) Thanks, :-) -- Jorge.
From: Ry Nohryb on 28 May 2010 10:41 On May 28, 3:25 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > (...) > where can I find discussions about the computer language javascript ? Yeah, comp.lang.javascript definitely sounds alike, very much suspiciously alike. -- Jorge.
From: Thomas 'PointedEars' Lahn on 28 May 2010 10:59 Ry Nohryb wrote: > Thomas 'PointedEars' Lahn wrote: >> Ry Nohryb wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> Ry Nohryb wrote: >> >> > parseFloat(Math.PI.toString(33), 33) >> >> > --> NaN >> >> >> >> I cannot confirm this. Where have you tested it? >> >> > Safari / Mac: >> > navigator.userAgent >> > --> "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us) >> > AppleWebKit/534.1+ (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7" >> >> Thanks, I am seeing this in Google Chrome 5.0.375.55 beta for Linux (V8 >> 2.1), too. >> >> The reason of this is apparently that the fractional part of >> "3.4m6dn4ow9qwe210nr3u0cdqkcnrbmwlh7kmfeapn9fijt38kie44jvdqh2vfrd[...]", >> which is the 33-aryrepresentation of Math.PI there, is parsed (because of >> its length) into `Infinity', while in JavaScript 1.8.2 the representation >> is rounded to "3.4m6dn4ow9r" and therefore the fractional part is not >> parsed into `Infinity'. >> >> Therefore, it appears to be prudent to truncate the fractional part so >> that it is not parsed into `Infinity'. A simple solution is to restrict >> the number of characters matched by the regular expression, like: >> >> ... new RegExp("\\.([" + chars + "]{1,10})", "i") ... >> >> A more sophisticated solution would be an adaptive algorithm that uses >> only as many characters as possible so that the result would not be >> `Infinity' given the numeric base. An implementation of that might be >> available through the Mozilla sources. > > No. A "more sophisticated solution" is to fix your broken algorithm: > you're parsing an amount which is less than 1 as an (probably) > enormous integer Less than 1? You don't know what you are talking about. > and then dividing it by another (probably) enormous integer. That's the > problem, not Chrome, your algorithm is the culprit. As usual you fail to recognize the relevant cause-and-effect relationship. The problem here is produced by the different implementations of Number.prototype.toString(), although JavaScriptCore's/V8's behavior cannot be considered a bug in the ECMAScript implementation, as I have already indicated in my response to John Stockton. By comparison you are splitting before you need to (parseInt() can take care of the point), you are calling the callback futilely at least 886 times in V8 because precision does not suffice to represent the factor, you fail to handle the sign properly, and you lose precision every time you call the callback and increment `r'. > You're, as usual, heavily disoriented. Yeah, maybe that is why your code also fails to solve this problem: ,-<news:52ceaeda-f3e2-4aaa-ad6f-42a640125d91(a)j9g2000vbp.googlegroups.com> | | (-Math.PI).toString(33).toFP(33) | --> NaN >> BTW, in case you have not noticed yet, like Safari, Chrome has a >> Developer menu (in the first main menu, below the Encoding menu item), >> which provides access to the Developer tools, including a script console >> and a debugger (which helped me to track this down). That makes using >> Firebug Lite in Chrome unnecessary. > > You're telling me ? Don't be so vain. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Ry Nohryb on 28 May 2010 11:16
On May 28, 4:59 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Ry Nohryb wrote: > > > No. A "more sophisticated solution" is to fix your broken algorithm: > > you're parsing an amount which is less than 1 as an (probably) > > enormous integer > > Less than 1? You don't know what you are talking about. Yes, less than one : [0..1) -- Jorge. |