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 28 Jun 2010 10:34 Dr J R Stockton wrote: > 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.sau...(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. Yes, but that does not have to constrain our function. >> 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. I'm not sure what you mean by "Base 10 should be handled as a general case." Obviously, we're talking here about generalizing *from* the base-10 case. My function followed Thomas' lead and defaulted to the existing (base-10) parseFloat function if the radix is not supplied or if the radix is 10. This of course does treat base-10 as a special case. There is some obvious justification for that, but there are clear counter-arguments as well to having any such special cases. > 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. I'm afraid I don't follow this. > 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. Uggh! This seems to be veering sharply away from the original idea of pairing a version of parseFloat with the existing Number.toString() so that we can reasonably switch representations, which I understood as at least part of the goal of your original suggestion that "ECMA 6 should specify a Method whereby for ANY Number X the result of X.toString(B) can be converted to the original X ." This suggestion also has the ugly feature that experience with other languages could easily make one expect "1.23^45" to represent the forty-fifth power of 1.23 rather than 1.23 * the forty-fifth power of ten. > 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 ? Can you think of a good justification for mixing and matching a base-10 exponent with a mantissa expressed in a different base? I can't come up with one. I would suggest that the base be used for all digits in the String format. -- Scott
From: Garrett Smith on 28 Jun 2010 15:07 On 2010-05-29 04:07 AM, Lasse Reichstein Nielsen wrote: > VK<schools_ring(a)yahoo.com> writes: > >> On May 29, 1:26 pm, Lasse Reichstein Nielsen<lrn.unr...(a)gmail.com> >> wrote: [...] > [1] Don't get me started on properties on the RegExp object. I'd like to read that. Garrett
From: Dr J R Stockton on 29 Jun 2010 18:44 In comp.lang.javascript message <4ba0b1f4-f63e-4c44-b87a-20a24b4953a4(a)q1 2g2000yqj.googlegroups.com>, Mon, 28 Jun 2010 07:34:06, Scott Sauyet <scott.sauyet(a)gmail.com> posted: >Dr J R Stockton wrote: >> 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.sau...(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. > >Yes, but that does not have to constrain our function. Actually, ECMA 262 is wrong. Name "parseFloat" should mean that the action "parse" is applied to a "Float" - and 123.456e78 is in floating- point notation but 1234.5678 is in fixed=point notation. The fact that the result is a floating-point type is grammatically irrelevant. A better name would be "parseToFloat". Routines not using exponents such as we have been considering should be called not "parseFloat" but "parseFixed". Given a parseFixed, one can make a parseFloat by wrapping it to hdle the mantissa in with code to handle the exponent (which might also use parseFixed or part thereof). The "F" in my routine "BetterPF" has just changed its meaning. >> 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. > >I'm not sure what you mean by "Base 10 should be handled as a general >case." Obviously, we're talking here about generalizing *from* the >base-10 case. According to <http://scott.sauyet.com/Javascript/Test/2010-06-16a/>, the aurally-malformed one has chosen to use var origPF = parseFloat; if (!iBase || iBase == 10) { return origPF(s); } His main routine, as supplied, is therefore entirely useless for testing native parseFloat. There, it (presumably) performs a conversion-speed optimisation which diminishes utility as a source of reliable conversions. >My function followed Thomas' lead and defaulted to the existing >(base-10) parseFloat function if the radix is not supplied or if the >radix is 10. This of course does treat base-10 as a special case. >There is some obvious justification for that, but there are clear >counter-arguments as well to having any such special cases. Indeed. FIRST one should obtain a 100% accurate converter, using only basic operations such as exact arithmetic (no rounding by use of the "+" operator, for example), string splitting, character-to-number - all of which operations will be well-tested in released ECMAscript. SECOND, one can use that to check the quality of faster code to do the same thing. >> 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. > >I'm afraid I don't follow this. Write a good, slow, routine such as mine - call it PF(S, R). Wrap it as function FPF(S, R) { return R == 10 ? parseFloat(S) : PF(S, R) } in which the common case is faster; or merge by putting if (R == 10) return parseFloat(S) within function PF. Those are simplified examples, ignoring the case of R absent. >> 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. > >Uggh! > >This seems to be veering sharply away from the original idea of >pairing a version of parseFloat with the existing Number.toString() so >that we can reasonably switch representations, which I understood as >at least part of the goal of your original suggestion that "ECMA 6 >should specify a Method whereby for ANY >Number X the result of X.toString(B) can be converted to the original >X ." I did not want to imply disallowing the use of an exponent letter in a base-10 float. >This suggestion also has the ugly feature that experience with other >languages could easily make one expect "1.23^45" to represent the >forty-fifth power of 1.23 rather than 1.23 * the forty-fifth power of >ten. That's why I included @ in the suggestion. >> 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 ? > >Can you think of a good justification for mixing and matching a >base-10 exponent with a mantissa expressed in a different base? I >can't come up with one. I would suggest that the base be used for all >digits in the String format. It all depends whether you are specifying formats that you would like to output and read back, or planning to read in formats what you would NOT like to output. Compare date formats : I "always" prefer to output Gregorian dates as yyyy-mm-dd or yyyy mm dd or yyyymmdd, but I am sometimes obliged to read other forms such as 14 July 1789, and I sometimes provide a choice of output forms such as dd.mm.yyyy. My Web <URL:http://www.merlyn.demon.co.uk/js-maths.htm#BEA> now contains and tests function refParseFixed(IN, Rdx, Obj) { // Obj is an optional Object I fairly strongly believe that for bases 2 to 36 it always gets the sign and mantissa of the returned Number correct, and less strongly that it always gets the exponent correct. There, Obj, if present, must be an Object; it is given a string property Bnry which is the mantissa of the result before rounding. It may not remain. It needs more testing. Query : can a function, during execution, write a property to itself, and if so how? function F() { myself.now = new Date() } later: alert(F.now) // see time of call -- (c) John Stockton, near London. *@merlyn.demon.co.uk/?.?.Stockton(a)physics.org Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Correct <= 4-line sig. separator as above, a line precisely "-- " (RFC5536/7) Do not Mail News to me. Before a reply, quote with ">" or "> " (RFC5536/7)
From: Scott Sauyet on 29 Jun 2010 23:12 Dr J R Stockton wrote: > In comp.lang.javascript message <4ba0b1f4-f63e-4c44-b87a-20a24b4953a4(a)q1 > 2g2000yqj.googlegroups.com>, Mon, 28 Jun 2010 07:34:06, Scott Sauyet > <scott.sau...(a)gmail.com> posted: >> Dr J R Stockton wrote: >>> 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.sau...(a)gmail.com> posted: > >>>> 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. > >> Yes, but that does not have to constrain our function. > > Actually, ECMA 262 is wrong. Name "parseFloat" should mean that the > action "parse" is applied to a "Float" - and 123.456e78 is in floating- > point notation but 1234.5678 is in fixed=point notation. The fact that > the result is a floating-point type is grammatically irrelevant. A > better name would be "parseToFloat". While I appreciate the distinction, I for one have never been surprised by the semantics of a parseNoun() function. They always take a String and return an item of type Noun. Perhaps it's because I spent a fair bit of time in strongly typed languages, where the fact that the parameter was a String and the result was of type Noun can be noted at a glance. > Routines not using exponents such as we have been considering should be > called not "parseFloat" but "parseFixed". Perhaps, but again I don't find this to be of major importance. > Given a parseFixed, one can make a parseFloat by wrapping it to hdle the > mantissa in with code to handle the exponent (which might also use > parseFixed or part thereof). > > The "F" in my routine "BetterPF" has just changed its meaning. I think it's relatively simple to change the regexes and the related code in many of the existing implementation to handle the formats "e +exp" or "E-exp" if we settle the question of the base of the exponent. I would prefer to use the radix, but can (almost) understand an argument for base-10. >>> 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. > >> I'm not sure what you mean by "Base 10 should be handled as a general >> case." Obviously, we're talking here about generalizing *from* the >> base-10 case. > > According to <http://scott.sauyet.com/Javascript/Test/2010-06-16a/>, the > aurally-malformed one has chosen to use ^^^^^^^^^^^^^^^^^^^^^ :-) "Malformed"?! I'm not sure that a bias in favor of blunt auditory configurations should be promulgated here. > var origPF = parseFloat; > > if (!iBase || iBase == 10) > { > return origPF(s); > } > > His main routine, as supplied, is therefore entirely useless for testing > native parseFloat. There, it (presumably) performs a conversion-speed > optimisation which diminishes utility as a source of reliable > conversions. You seem to be on a different path than I'm following. I understand that you're looking for a reliable-even-if-inefficient converter of string representations of base-n numbers to floating point numbers. I'm less interested in that than in a practical-even-if-less-provably- correct version. >> My function followed Thomas' lead and defaulted to the existing >> (base-10) parseFloat function if the radix is not supplied or if the >> radix is 10. This of course does treat base-10 as a special case. >> There is some obvious justification for that, but there are clear >> counter-arguments as well to having any such special cases. > > Indeed. FIRST one should obtain a 100% accurate converter, using only > basic operations such as exact arithmetic (no rounding by use of the "+" > operator, for example), string splitting, character-to-number - all of > which operations will be well-tested in released ECMAscript. > > SECOND, one can use that to check the quality of faster code to do the > same thing. But what is your basis for demonstrating the quality of a converter? If a String is in the proper format to represent a base-n number and that number is representable as an IEEE-754 floating point number, should our algorithm choose the closest IEEE-754 value, subject to the standard rounding rules? If so, how does one go about demonstrating the accuracy? If not, what is the standard? >>> 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. > >> I'm afraid I don't follow this. > > Write a good, slow, routine such as mine - call it PF(S, R). > > Wrap it as > > function FPF(S, R) { > return R == 10 ? parseFloat(S) : PF(S, R) } > > in which the common case is faster; or merge by putting > if (R == 10) return parseFloat(S) > within function PF. Those are simplified examples, ignoring the case of > R absent. Yes, but you're assuming that we can in some straightforward way show that an unwrapped function or some other parseFloat is as accurate as possible. I don't know if this can be done, and if you think it can, I would love to see your evidence. >>> 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. > >> Uggh! > >> This seems to be veering sharply away from the original idea of >> pairing a version of parseFloat with the existing Number.toString() so >> that we can reasonably switch representations, which I understood as >> at least part of the goal of your original suggestion that "ECMA 6 >> should specify a Method whereby for ANY >> Number X the result of X.toString(B) can be converted to the original >> X ." > > I did not want to imply disallowing the use of an exponent letter in a > base-10 float. An alternative to that, though, is to require the exponent sign. That would entirely disambiguate the possibilities. That is, unless we made a (quite possibly reasonable) exception for base-10, we would not allow "6.02214179e23", only "6.02214179e+23". >> This suggestion also has the ugly feature that experience with other >> languages could easily make one expect "1.23^45" to represent the >> forty-fifth power of 1.23 rather than 1.23 * the forty-fifth power of >> ten. > > That's why I included @ in the suggestion. I think e+, e-, E+, E- would be clearer and would not be overly restrictive. >>> 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 ? > >> Can you think of a good justification for mixing and matching a >> base-10 exponent with a mantissa expressed in a different base? I >> can't come up with one. I would suggest that the base be used for all >> digits in the String format. > > It all depends whether you are specifying formats that you would like to > output and read back, or planning to read in formats what you would NOT > like to output. I understand Postel's law, but the only extension of the possible output of toString(radix) I would like to cover is additional digits. > [ ... ] > > My Web <URL:http://www.merlyn.demon.co.uk/js-maths.htm#BEA> now contains > and tests > function refParseFixed(IN, Rdx, Obj) { // Obj is an optional Object > I fairly strongly believe that for bases 2 to 36 it always gets the sign > and mantissa of the returned Number correct, and less strongly that it > always gets the exponent correct. Although its goal is somewhat different from the other functions on the page, I did include it on my latest test page: <http://scott.sauyet.com/Javascript/Test/2010-06-29a/> <http://scott.sauyet.com/Javascript/Test/2010-06-29a/index.phps> > [ ... ] > > It needs more testing. > > Query : can a function, during execution, write a property to itself, > and if so how? > function F() { > myself.now = new Date() } > later: > alert(F.now) // see time of call Yes, it's very easy for functions defined like that. Simply F.now = new Date(); -- Scott
From: Dr J R Stockton on 1 Jul 2010 18:38
In comp.lang.javascript message <07c28fab-b585-4a49-8f70-50f5c8f30425(a)i3 1g2000yqm.googlegroups.com>, Tue, 29 Jun 2010 20:12:53, Scott Sauyet <scott.sauyet(a)gmail.com> posted: >Dr J R Stockton wrote: >> His main routine, as supplied, is therefore entirely useless for testing >> native parseFloat. �There, it (presumably) performs a conversion-speed >> optimisation which diminishes utility as a source of reliable >> conversions. > >You seem to be on a different path than I'm following. Not really; I'm just ahead of you, and perhaps past where you were intending to stop. I've written my comparatively fast and imperfectly accurate routines, now parsFlotA parsFlotB parsFlotC parsFlotD. > I understand >that you're looking for a reliable-even-if-inefficient converter of >string representations of base-n numbers to floating point numbers. >I'm less interested in that than in a practical-even-if-less-provably- >correct version. There are, evidently, many ways of getting an approximate answer, especially if ECMA string to/from number routines are used. If you look at what I've found about some of the major-browser implementations, you will see while anything using their conversion routines cannot reasonably be trusted cross-browser, unless it is compared cross-browser with a known-good routine. Finding a digit 2 in a binary number string is like hearing the 13th stroke of a church clock. >But what is your basis for demonstrating the quality of a converter? >If a String is in the proper format to represent a base-n number and >that number is representable as an IEEE-754 floating point number, >should our algorithm choose the closest IEEE-754 value, subject to the >standard rounding rules? It is that others can examine my code and see that it must give the right answer. At present, that's fairly easy for the sign and mantissa. It's a bit harder for the exponent; but big errors are not deceptive, even though they may be annoying. Any reasonable rounding rule can be applied without difficulty. >Yes, but you're assuming that we can in some straightforward way show >that an unwrapped function or some other parseFloat is as accurate as >possible. I don't know if this can be done, and if you think it can, >I would love to see your evidence. It is <URL:http://www.merlyn.demon.co.uk/js-maths.htm#BEA>, once seen to have been debugged and once the comment is adjusted so that a sufficient number of people can understand the code. It uses the method that one would use with pencil and paper. It is easy to get parseFloat(S, R) fully accurate. Take the part before the point and keep halving it in base-R arithmetic, pushing the remainders until there is nothing left, and reverse them. Take the part after the point and keep doubling it in base-R arithmetic, pushing the remainders until one has 54 (sic) bits, of which the first will be a 1. The 54th alone is sufficient to tell whether 1 has to be added to the 53rd. One now has the bits needed for the mantissa of an IEEE Double. Start with zero and keep doubling and adding in to get what will be the value after scaling in the exponent. Then consider whether there are any special cases : "0.0" is such (since the code suggested so far will fill the memory with zero bits while hoping to find a 1 bit); just test the string for it and if found return a correctly-signed zero. Exponent notation, once parsed for pattern, is easy if the exponent is to the same radix; for approximate results, parseInt the exponent and multiply/divide it in enough times (or trust Math.pow(Rdx, Expo)), and for my method just shift the point in the string at the beginning. >I think e+, e-, E+, E- would be clearer and would not be overly >restrictive. One could, for radix not 10, use lower case for the digits and upper- case E for the separator. >> My Web <URL:http://www.merlyn.demon.co.uk/js-maths.htm#BEA> now contains >> and tests >> � � �function refParseFixed(IN, Rdx, Obj) { // Obj is an optional Object >> I fairly strongly believe that for bases 2 to 36 it always gets the sign >> and mantissa of the returned Number correct, and less strongly that it >> always gets the exponent correct. > >Although its goal is somewhat different from the other functions on >the page, I did include it on my latest test page: > > <http://scott.sauyet.com/Javascript/Test/2010-06-29a/> > <http://scott.sauyet.com/Javascript/Test/2010-06-29a/index.phps> It's not really ready for that, unless you have reviewed and tested it comprehensively. Today's version is different. Tomorrow's will be different again. Give your users a textarea into which they can paste code for test. Also, if you examine the first of those of your pages, you find in "John Stockton 3" a visible and invalid line for (K=0, Cy=0 ; K= 0) Scale /= 2 but in my real code there are a few other lines between the second K and the following =. Your innerHTML needs to be processed by something like function SafeHTML(S) { return S.split("&").join("&").split("<").join("<"). split(">").join(">") } // IAS if it may contain '<' '>' or '&' ('<' '>' do not always *need* to be replaced; but they always can be). >> Query : can a function, during execution, write a property to itself, >Yes, it's very easy for functions defined like that. Simply > > F.now = new Date(); function Fn() { alert(Fn.now) ; Fn.now = new Date() ; alert(1) } Fn() alert(Fn.now) Fn() works. I must have done something else wrong when trying to do something like that. Thanks. <http://www.bbc.co.uk/radio7/programmes/schedules> links to John Major on Cricket. -- (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) |