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: Dr J R Stockton on 28 May 2010 15:35 In comp.lang.javascript message <Xns9D85CE4464FCFeejj99(a)194.109.133.242> , Thu, 27 May 2010 18:16:34, Evertjan. <exjxw.hannivoort(a)interxnl.net> posted: >Ry Nohryb wrote on 27 mei 2010 in comp.lang.javascript: You have both missed the point. I wrote : > Is there in fact an >easy built-in way of converting non-integer Hex strings to Number? to which the proper answers must be along the lines of "I cannot see one" or "ECMA 262 #.##.# indicates that <brief> does it". I can readily enough code that myself in various ways, the most obvious being to use parseint(S, 16) for the integer part, split off the fractional part, use parseInt(S, 16) on that, divide by Math.pow(16, length) then add or subtract. ISTM that parseInt("-0", 16) does indeed return -0. S = "-45.6" A = parseInt(S, 16) if (S = S.split(".")[1]) A += (2*(1/A>0)-1) * parseInt(S, 16) / Math.pow(16, S.length) // -> -69.375 That is undertested. A number string should always have a digit before its basal separator if any. Have no non-digit terminator. But that is, although easy, not built-in. Built-on means something like using unary + rather than valueOf or getTime on a Date Object would be if those two methods did not exist - an inconspicuous but useful fearure of the language as specified, generally missing from non-normative descriptions of the language. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 7. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Command-prompt MiniTrue is useful for viewing/searching/altering files. Free, DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.
From: Ry Nohryb on 28 May 2010 20:04 On May 28, 5:29 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > Ry Nohryb <jo...(a)jorgechamorro.com> writes: > > String.prototype.toFP= function (base, digits, w, n, r) { > > One argument against using unused parameters as local variable > declarations, that hasn't been mentioned yet, is that it might slow > down calling the function. > > Simple test: > > (function() { > function foo1(a,b,c,d,e) { > e=a;d=e;c=d;b=c;return b; > } > function foo2(a) { > var b,c,d,e; > e=a;d=e;c=d;b=c;return b; > } > var x = 42; > foo1(x);foo2(x); // Make sure they are compiled. > var t0 = Date.now(); > for (var i = 0; i < 10000000; i++) { > x = foo1(x); > } > var t1 = Date.now(); > for (var i = 0; i < 10000000; i++) { > x = foo2(x); > } > var t2 = Date.now(); > alert([t1-t0,t2-t1]); > > })() > > Safari: 300, 179 > Opera 10.54: 132, 116 (maybe not significant). > Chrome dev: 145, 90 > Firefox and IE: no noticable difference. > (I also ran the tests with the two loops swapped, to see if going > first made a difference. It did a little in Firefox). That's very interesting. Any clues as to why ? In any case, first of all, thanks for sharing. Although imo such a small difference only makes a difference in the rare cases when you're calling (ultra-short and fassst) functions at a rate of tens of millions per second, which is hardly a usual thing. After all, we're talking about differences of +/-5ns per call, here: 5e-9 seconds, you've got to do quite a lot of calls in order to notice that, or not ? > It also prevents the compiler from knowing the initial values > of the variables (but that should be irrelevant if they are > initialized before use on all paths anyway). Ack. -- Jorge.
From: Ry Nohryb on 28 May 2010 20:06 On May 28, 9:35 pm, Dr J R Stockton <reply1...(a)merlyn.demon.co.uk> wrote: > In comp.lang.javascript message <Xns9D85CE4464FCFeej...(a)194.109.133.242> > , Thu, 27 May 2010 18:16:34, Evertjan. <exjxw.hannivo...(a)interxnl.net> > posted: > > >Ry Nohryb wrote on 27 mei 2010 in comp.lang.javascript: > > You have both missed the point. I wrote : > > > Is there in fact an > >easy built-in way of converting non-integer Hex strings to Number? > > to which the proper answers must be along the lines of "I cannot see > one" or "ECMA 262 #.##.# indicates that <brief> does it". Ok. There seems to be an easy way but it's not built-in. > I can readily enough code that myself in various ways, the most obvious > being to use parseint(S, 16) for the integer part, split off the > fractional part, use parseInt(S, 16) on that, divide by Math.pow(16, > length) then add or subtract. > > ISTM that parseInt("-0", 16) does indeed return -0. > > S = "-45.6" > A = parseInt(S, 16) > if (S = S.split(".")[1]) > A += (2*(1/A>0)-1) * parseInt(S, 16) / Math.pow(16, S.length) > // -> -69.375 > > That is undertested. A number string should always have a digit before > its basal separator if any. Have no non-digit terminator. function stocktonParseFloat (S, base) { var A = parseInt(S, base); if (S = S.split(".")[1]) A += (2*(1/A>0)-1) * parseInt(S, base) / Math.pow(base, S.length); return A; } for (base= 2; base < 37; base++) console.log([base, stocktonParseFloat(Math.PI.toString(base), base)]); [2, 3.141592653589793] [3, 3.141592653589793] [4, 3.141592653589793] [5, NaN] [6, 3.141592653589793] [7, 3.141592653589793] [8, 3.141592653589793] [9, 3.141592653589793] [10, 3.141592653589793] [11, NaN] [12, 3.141592653589793] [13, 3.141592653589793] [14, 3.141592653589793] [15, NaN] [16, 3.141592653589793] [17, NaN] [18, 3.141592653589793] [19, 3.141592653589793] [20, 3.141592653589793] [21, NaN] [22, 3.141592653589793] [23, 3.141592653589793] [24, 3.141592653589793] [25, NaN] [26, 3.141592653589793] [27, NaN] [28, 3.141592653589793] [29, NaN] [30, 3.141592653589793] [31, 3.141592653589793] [32, 3.141592653589793] [33, NaN] [34, 3.141592653589793] [35, NaN] [36, 3.141592653589793] That algorithm has problems, as you can see. > But that is, although easy, not built-in. Built-on means something like > using unary + rather than valueOf or getTime on a Date Object would be > if those two methods did not exist - an inconspicuous but useful fearure > of the language as specified, generally missing from non-normative > descriptions of the language. Ok. -- Jorge.
From: Lasse Reichstein Nielsen on 29 May 2010 05:26 Ry Nohryb <jorge(a)jorgechamorro.com> writes: > On May 28, 5:29�pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> > wrote: >> One argument against using unused parameters as local variable >> declarations, that hasn't been mentioned yet, is that it might slow >> down calling the function. .... > That's very interesting. Any clues as to why ? Best guess is that the extra or missing arguments makes it harder to just pass the arguments on the stack to the function. You need to either introduce extra undefined values or change where the function looks for its arguments. Also, implementations are likely to optimize for the "common case", which they assume is to call a function with the number of arguments that it expects. Anything else triggers special code with extra overhead. And possibly, local variables can be optimized better, since it's certain that noone outside the function can see them. Most implementations still support the (incrdibly stupid) func.arguments feature where you can access the arguments of the current call to a function on the function object itself. That alone breaks some possible optimizations. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: VK on 29 May 2010 05:48
On May 29, 1:26 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > And possibly, local variables can be optimized better, since it's > certain that noone outside the function can see them. Most > implementations still support the (incrdibly stupid) func.arguments > feature where you can access the arguments of the current call to a > function on the function object itself. That alone breaks some > possible optimizations. I do not agree that the possibility to send any amount of arguments to a function without being bothered with formal argument IDs is a stupid feature. IMHO it is very handy. Also you seem reversing the production mechanics: arguments object is created and filled on function call in either case, with formal argument names provided or not. *Then* formal argument names are used to init them with arguments members from arguments[0] to arguments.length-1 Respectively I would expect arguments usage to be (fractionally) quicker than formal argument names usage. |