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: Lasse Reichstein Nielsen on 29 May 2010 07:07 VK <schools_ring(a)yahoo.com> writes: > 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. And that's not what I said. I dislike the implicit "arguments" object way of exposing extra arguments, but I admit that it serves a purpose. There are different approaches and some would probably have been better for performance and ease of use. What I don't see any reasonable use for, and a lot of problems with, is reading the arguments object off the function object: function foo() { bar(); } function bar() { alert(foo.arguments[0]); } foo("Can't keep me secret"); If it wasn't for that feature, calling a function that doesn't use the arguments object with more arguments than it actually needs, could just be done by dropping the extra arguments. Instead, the extra arguments need to be stored, and the function call needs to adapt them to match the code of the function, which is optimized for the common case of getting the parameters that it expects. > 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 The arguments object doesn't need to be created unless it is actually used. An optimizing compiler can keep the arguments on the stack and work on them directly from there, without creating any arguments object. That is, unless someone actually uses the arguments object. In that case, you need to alias the arguments and the arguments object, and all accesses go through an extra layer of indirection (or more). The design is most likely derived from an early implementation that did just this, but that's why more efficient implementations have such a hard time with this language: The specification derives from a specific implementation strategy, with unnecessary features that just happened to be easily implemented using that strategy. [1] > Respectively I would expect arguments usage to be (fractionally) > quicker than formal argument names usage. That's because actual implementations are doing the opposite of what you expect. /L [1] Don't get me started on properties on the RegExp object. -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Ry Nohryb on 29 May 2010 07:50 On May 28, 4:59 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > (...) you are calling the callback futilely at least 886 times in > V8 because precision does not suffice to represent the factor (...) [*] FIXED: String.prototype.toFP= function (base, d, w, n, r, s, pw) { if (/[^0-9a-z\.+-]/i.test(this)) return NaN; d= "0123456789abcdefghijklmnopqrstuvwxyz"; s= (r= parseInt((n= this.split('.'))[w= 0], base)) < 0 ? -1 : 1; n= n[1].toLowerCase().split(''); while(n.length && (pw=Math.pow(base,--w))) r +=s*d.indexOf(n.shift())*pw; return r; }; for (var base=2; base <37; base++) console.log([base, Math.PI.toString(base).toFP(base)]) --> [2, 3.141592653589793] [3, 3.141592653589794] [4, 3.141592653589793] [5, 3.1415926535897936] [6, 3.141592653589793] [7, 3.141592653589794] [8, 3.141592653589793] [9, 3.141592653589794] [10, 3.141592653589793] [11, 3.141592653589793] [12, 3.141592653589793] [13, 3.141592653589793] [14, 3.141592653589793] [15, 3.1415926535897936] [16, 3.141592653589793] [17, 3.141592653589793] [18, 3.141592653589794] [19, 3.1415926535897922] [20, 3.141592653589793] [21, 3.1415926535897936] [22, 3.1415926535897927] [23, 3.141592653589793] [24, 3.141592653589793] [25, 3.1415926535897936] [26, 3.141592653589793] [27, 3.1415926535897927] [28, 3.141592653589794] [29, 3.141592653589793] [30, 3.141592653589793] [31, 3.141592653589793] [32, 3.141592653589793] [33, 3.141592653589793] [34, 3.141592653589793] [35, 3.141592653589793] [36, 3.141592653589793] -- Jorge.
From: Evertjan. on 29 May 2010 12:02 Dr J R Stockton wrote on 28 mei 2010 in comp.lang.javascript: > 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? Perhaps, John, we missed YOUR point. However we were [or at least I was] just contemplating a general function for conversion of any root[1..36] floating point string to number value. Such functions are much safer explicit than embedded, if speed is not the essense, as any bug can more easily be delt with, as you, as king of the embedded bug detectives, should know. ;-) btw: in root 1 only the zero value can be expressed. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
From: Ry Nohryb on 29 May 2010 13:10 On May 29, 1:50 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: > > String.prototype.toFP= function (base, d, w, n, r, s, pw) { > if (/[^0-9a-z\.+-]/i.test(this)) return NaN; > d= "0123456789abcdefghijklmnopqrstuvwxyz"; > s= (r= parseInt((n= this.split('.'))[w= 0], base)) < 0 ? -1 : 1; > n= n[1].toLowerCase().split(''); > while(n.length && (pw=Math.pow(base,--w))) r > +=s*d.indexOf(n.shift())*pw; > return r; > > }; > > (...) Take 3: this one uses the same algorithm of my first post, but, if the divisor (Math.pow(base, fractionalPartStr.length) is too big (Infinity) it trims fractionalPartStr down until isFinite(divisor): /* Tested in Safari, Chrome, Opera & FF */ String.prototype.toFP= function (base, n, r, w, div) { if (/[^0-9a-z\.+-]/i.test(this)) return NaN; n= this.split('.'); if (isFinite(r= parseInt(n[0], base))) { if (w= (n= n[1]).length) { /*trim until it's finite*/ while (!isFinite(div= Math.pow(base, w))) w--; r+= (r<0 ? -1:1)* parseInt(n.substr(0, w), base)/ div; } } return r; }; for (var base=2; base <37; base++) console.log([base, Math.PI.toString(base).toFP(base)]) --> [2, 3.141592653589793] [3, 3.141592653589793] [4, 3.141592653589793] [5, 3.141592653589793] [6, 3.141592653589793] [7, 3.141592653589793] [8, 3.141592653589793] [9, 3.141592653589793] [10, 3.141592653589793] [11, 3.141592653589793] [12, 3.141592653589793] [13, 3.141592653589793] [14, 3.141592653589793] [15, 3.141592653589793] [16, 3.141592653589793] [17, 3.141592653589793] [18, 3.141592653589793] [19, 3.141592653589793] [20, 3.141592653589793] [21, 3.141592653589793] [22, 3.141592653589793] [23, 3.141592653589793] [24, 3.141592653589793] [25, 3.141592653589793] [26, 3.141592653589793] [27, 3.141592653589793] [28, 3.141592653589793] [29, 3.141592653589793] [30, 3.141592653589793] [31, 3.141592653589793] [32, 3.141592653589793] [33, 3.141592653589793] [34, 3.141592653589793] [35, 3.141592653589793] [36, 3.141592653589793] (-Math.PI).toString(33).toFP(33) --> -3.141592653589793 -- Jorge.
From: Dr J R Stockton on 29 May 2010 16:13
In comp.lang.javascript message <4430313.MhkbZ0Pkbq(a)PointedEars.de>, Fri, 28 May 2010 14:34:28, Thomas 'PointedEars' Lahn <PointedEars(a)web.de> posted: >Yes, good catch; we need to consider the sign with addition, e.g.: > > var s = (-Math.PI).toString(16); > var i = parseInt(s, 16); > var f = (s.match(/\.([\da-f]+)/i) || [, "0"])[1]; > var n = i + (i < 0 ? -1 : 1) * parseInt(f, 16) / Math.pow(16, f.length); You need to consider it more effectively, and to test adequately. That indeed gives -3.141592653589793; but use instead Math.PI/10 and it gives 0.3141592653589793. Whenever parseInt(s, 16) gives a zero, your code will give a positive result. Search the archives covering the 200x decade, and you will see that the relevant facts are known. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Grandson-Of-RFC1036 is released. RFC 5536 Netnews Article Format is a subset of Internet Message Format which is described in RFC 5532. The RFCs are read together to determine standard Netnews article format. |