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: Scott Sauyet on 23 Jun 2010 08:50 Dr J R Stockton wrote: > In comp.lang.javascript message <703e1d78-8204-4c60-b73f-eac7de238028(a)j4 > g2000yqh.googlegroups.com>, Mon, 21 Jun 2010 12:51:53, Scott Sauyet > <scott.sau...(a)gmail.com> posted: > >> Does the latest version fix the UI versions you mention? > >> <http://scott.sauyet.com/Javascript/Test/2010-06-21a/> > > Yes. But you set the width to 800px. That was detritus left over from the earlier layout. I've removed it from the most recent two versions. > Where you have more than one function from a person, I suggest that the > first be numbered "1". Good idea. I updated the most recent one to do so. <http://scott.sauyet.com/Javascript/Test/2010-06-21b/> > My ExactPF us now called BetterPF for two > reasons, one being that it is not invariably exact. If and when I make a new version, I will try to remember to change that. -- Scott
From: Scott Sauyet on 23 Jun 2010 09:33 Dr J R Stockton wrote: > In comp.lang.javascript message <7550eef3-42f2-4d97-9459-dea2356aa84b(a)z8 > g2000yqz.googlegroups.com>, Mon, 21 Jun 2010 13:50:01, Scott Sauyet > <scott.sau...(a)gmail.com> posted: > >> I saw the exponent code, and am not quite sure how that should play >> with bases higher than 14 (it gets tricky when you consider that >> "1.0e3", base 10, should convert to 1000 but "1.0e3", base 16, should >> convert to 1.055419921875. The question is what does "e" represent? > > In a browser, a full function parseFloat(String, radix) should accept > the exponent format which, in that browser, toString(radix) gives for > sufficiently large and small Numbers. But it should accept that format > for all finite values, and with the radical point not in the same > position. That probably stakes out the only practical position, assuming that all browsers when they report in exponent form always use "+" or "-". But it leaves the strange ambiguity of things like "6.02214179e23", which is understood by parseFloat as 6.02214179e+23, but our new version using base 16 could not understand 7.f8618974d08a8e13 as the same value, since the final three digits would have to be treated as digits and not as representing multiplication by the 13th power of our 16. It's not that this is wrong; it seems the only way to resolve the potential ambiguity. But it is decidedly odd. -- Scott
From: Dr J R Stockton on 24 Jun 2010 14:46 In comp.lang.javascript message <4ff2b606-26e5-4649-8136-a99411861ea5(a)w3 1g2000yqb.googlegroups.com>, Wed, 23 Jun 2010 06:33:48, Scott Sauyet <scott.sauyet(a)gmail.com> posted: >Dr J R Stockton wrote: >> In comp.lang.javascript message <7550eef3-42f2-4d97-9459-dea2356aa84b(a)z8 >> g2000yqz.googlegroups.com>, Mon, 21 Jun 2010 13:50:01, Scott Sauyet >> <scott.sau...(a)gmail.com> posted: >> >>> I saw the exponent code, and am not quite sure how that should play >>> with bases higher than 14 (it gets tricky when you consider that >>> "1.0e3", base 10, should convert to 1000 but "1.0e3", base 16, should >>> convert to 1.055419921875. �The question is what does "e" represent? >> >> In a browser, a full function parseFloat(String, radix) should accept >> the exponent format which, in that browser, toString(radix) gives for >> sufficiently large and small Numbers. �But it should accept that format >> for all finite values, and with the radical point not in the same >> position. > >That probably stakes out the only practical position, assuming that >all browsers when they report in exponent form always use "+" or "-". >But it leaves the strange ambiguity of things like "6.02214179e23", >which is understood by parseFloat as 6.02214179e+23, but our new >version using base 16 could not understand 7.f8618974d08a8e13 as the >same value, since the final three digits would have to be treated as >digits and not as representing multiplication by the 13th power of our >16. > >It's not that this is wrong; it seems the only way to resolve the >potential ambiguity. But it is decidedly odd. One needs to test all browsers, or at least several, before making such comment. There may be error, but I see no ambiguity. Browser :- 1e50.toString(35) :- MS IE 8 3.v3ty6r1g4a8(e+32) Ff 3.0.19 3v3ty6r1g49vrxtsu3y8yqlp7gi2e9jfa Opera 10.10 3v3ty6r1g48bx586912esj60h8rsjawka Safari 4.0.5 3v3ty6r1g48bx586912esj60h8rsjawka Chrome 5.0 3v3ty6r1g48bx586912esj60h8rsjawka Browser :- 1e-50.toString(35) :- MS IE 8 9.002luc6eeb5(e-33) Ff 3.0.19 0.000000000000000000000000000000009002luc6eef Opera 10.10 1e-50 Safari 4.0.5 0 Chrome 5.0 0.000000000000000000000000000000009002luc6ee ... IE8's exponents appear to be decimal powers of radix, but that needs checking. So the ideal must be to read fixed point AND IR's exponents. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (RFCs 5536/7) Do not Mail News to me. Before a reply, quote with ">" or "> " (RFCs 5536/7)
From: Scott Sauyet on 24 Jun 2010 20:35 Dr J R Stockton wrote: > In comp.lang.javascript message <4ff2b606-26e5-4649-8136-a99411861ea5(a)w3 > 1g2000yqb.googlegroups.com>, Wed, 23 Jun 2010 06:33:48, Scott Sauyet > <scott.sau...(a)gmail.com> posted: >>Dr J R Stockton wrote: > >>> In a browser, a full function parseFloat(String, radix) should accept >>> the exponent format which, in that browser, toString(radix) gives for >>> sufficiently large and small Numbers. But it should accept that format >>> for all finite values, and with the radical point not in the same >>> position. > >> That probably stakes out the only practical position, assuming that >> all browsers when they report in exponent form always use "+" or "-". >> But it leaves the strange ambiguity of things like "6.02214179e23", >> which is understood by parseFloat as 6.02214179e+23, but our new >> version using base 16 could not understand 7.f8618974d08a8e13 as the >> same value, since the final three digits would have to be treated as >> digits and not as representing multiplication by the 13th power of our >> 16. > >> It's not that this is wrong; it seems the only way to resolve the >> potential ambiguity. But it is decidedly odd. > > One needs to test all browsers, or at least several, before making such > comment. There may be error, but I see no ambiguity. > > Browser :- 1e50.toString(35) :- > MS IE 8 3.v3ty6r1g4a8(e+32) > Ff 3.0.19 3v3ty6r1g49vrxtsu3y8yqlp7gi2e9jfa > Opera 10.10 3v3ty6r1g48bx586912esj60h8rsjawka > Safari 4.0.5 3v3ty6r1g48bx586912esj60h8rsjawka > Chrome 5.0 3v3ty6r1g48bx586912esj60h8rsjawka > > Browser :- 1e-50.toString(35) :- > MS IE 8 9.002luc6eeb5(e-33) > Ff 3.0.19 0.000000000000000000000000000000009002luc6eef > Opera 10.10 1e-50 > Safari 4.0.5 0 > Chrome 5.0 0.000000000000000000000000000000009002luc6ee ... > > IE8's exponents appear to be decimal powers of radix, but that needs > checking. > > So the ideal must be to read fixed point AND IR's exponents. I understand that the output of toString() might always be susceptible to this method, although I haven't checked it thoroughly. But I wanted to consider Strings that reasonably represent base-n floating numbers, things like 7.f8618974d08a8e20 The question, perhaps is whether we want our function to recognize "6.02214179e23" with radix 10 as an approximation to Avogadro's Number, which is approximately 6.02214179 multiplied by the 23rd power of 10. It would make sense to do so. The built-in parseFloat does so in each of the implementations I've tried. But then what would we get for "7.f8618974d08a8e20", which could be interpreted as 7.f8618974d08a8 (base 16) time the 20th power of 16, or as 7.970238295573418 as all the currently published versions in my test page do. That's the ambiguity I see. Do we just assume that all inputs using exponential notation will use "e+" or "e-"? Or do we cover the base 10 version as a special case? Or is there some other option? -- Scott
From: Dr J R Stockton on 26 Jun 2010 13:45
In comp.lang.javascript message <872a82c8-5cdf-4c9e-ab3b-0e5f70f37962(a)j4 g2000yqh.googlegroups.com>, Thu, 24 Jun 2010 17:35:01, Scott Sauyet <scott.sauyet(a)gmail.com> posted: >I understand that the output of toString() might always be susceptible >to this method, although I haven't checked it thoroughly. But I >wanted to consider Strings that reasonably represent base-n floating >numbers, things like > > 7.f8618974d08a8e20 > >The question, perhaps is whether we want our function to recognize >"6.02214179e23" with radix 10 as an approximation to Avogadro's >Number, which is approximately 6.02214179 multiplied by the 23rd power >of 10. It would make sense to do so. The built-in parseFloat does so >in each of the implementations I've tried. ISTM that ECMA 262 9.3.1 requires it to do so. >But then what would we get for "7.f8618974d08a8e20", which could be >interpreted as 7.f8618974d08a8 (base 16) time the 20th power of 16, or >as 7.970238295573418 as all the currently published versions in my >test page do. >That's the ambiguity I see. Do we just assume that all inputs using >exponential notation will use "e+" or "e-"? Or do we cover the base >10 version as a special case? Or is there some other option? Base 10 should be handled as a general case. It's easier to develop and test, since our instincts mostly work in Base 10. If there is no base- 10-specific code, base-10 debugging will debug all bases except for base-specific errors. Those people who want greater speed for base 10 or other special cases such as 2^N can add a neat wrapper to deal with those. Those who have other code, including parseFloat, for such bases can use it to check the general code. Those people who want the greatest speed can sacrifice neatness by merging the wrapper. Perhaps the best way overall of handling exponent notation for general bases is to use a specific punctuation character to do for all bases what e does for base 10. For that, ^ or @ will serve. There should also be a way of indicating the radix as part of the number string, as shown by -123.456^78#9 or otherwise. There also needs to be a clear indication as to whether the exponent is to be base radix or base 10. How about 0x12.34^0x56 ? -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk BP7, Delphi 3 & 2006. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links; <URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ; NOT <URL:http://support.codegear.com/newsgroups/>: news:borland.* Guidelines |