From: Lasse Reichstein Nielsen on
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
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
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
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
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.