Math ugliness.
 

Hi,

Do you think -as I do- that the Math object is an ugly artifact ?
Well, here's a nice way of getting rid of it :

Number.prototype.sin= function () { return Math.sin(+this); };
Number.prototype.asin= function () { return Math.asin(+this); };
Number.prototype.pow= function (p) { return Math.pow(+this, p); };
Number.prototype.sqrt= function () { return Math.sqrt(+this); };
Number.prototype.rnd= function () { return this*Math.random(); }

etc..

x= 16;
x.sqrt()
--> 4

x="256";
(+x).pow(2) //be sure to call the right .proto
--> 65536

(1.234).sin().asin()
--> 1.234

1..asin() * 2
-> 3.141592653589793

(2).pow(10)
--> 1024

2..pow(10).sqrt()
--> 32

(100).rnd()
-> 0 <= n < 100
--
Jorge.

Re: Math ugliness.
 

Jorge <jorge@jorgechamorro.com> wrote:
> Hi,
>
> Do you think -as I do- that the Math object is an ugly artifact ?
> Well, here's a nice way of getting rid of it :
>
> Number.prototype.sin= function () { return Math.sin(+this); };
> Number.prototype.asin= function () { return Math.asin(+this); };
> Number.prototype.pow= function (p) { return Math.pow(+this, p); };
> Number.prototype.sqrt= function () { return Math.sqrt(+this); };
> Number.prototype.rnd= function () { return this*Math.random(); }
>
> etc..
>
> x= 16;
> x.sqrt()
> --> 4
>
> x="256";
> (+x).pow(2) //be sure to call the right .proto
> --> 65536
>
> (1.234).sin().asin()
> --> 1.234
>
> 1..asin() * 2
> -> 3.141592653589793
>
> (2).pow(10)
> --> 1024
>
> 2..pow(10).sqrt()
> --> 32
>
> (100).rnd()
> -> 0 <= n < 100
> --
> Jorge.
>
Just out of curiosity, does IE support this? I don't see why it
wouldn't, just making sure

--
--Cody Haines

Re: Math ugliness.
 

On Feb 17, 9:23*am, Jorge <jo...@jorgechamorro.com> wrote:
> Hi,
>
> Do you think -as I do- that the Math object is an ugly artifact ?
> Well, here's a nice way of getting rid of it :
>
> Number.prototype.sin= function () { return Math.sin(+this); };

I'm curious about the use of unary +. Presumably the identifier is
resolved to a number primitive in the first place, otherwise x.sin
wouldn't resolve to Number.prototype.sin.

Or have I missed something?


[...]
> x="256";
> (+x).pow(2) //be sure to call the right .proto
> --> 65536

So if x must be a number in order for the right property to be found,
why must it also be converted inside the function?


--
Rob

Re: Math ugliness.
 

Cody Haines wrote:

> Jorge <jorge@jorgechamorro.com> wrote:
>> Do you think -as I do- that the Math object is an ugly artifact ?
>> Well, here's a nice way of getting rid of it :
>>
>> Number.prototype.sin= function () { return Math.sin(+this); };
>> Number.prototype.asin= function () { return Math.asin(+this); };
>> Number.prototype.pow= function (p) { return Math.pow(+this, p); };
>> Number.prototype.sqrt= function () { return Math.sqrt(+this); };
>> Number.prototype.rnd= function () { return this*Math.random(); }
>>
>> etc..
>>
>> x= 16;
>> x.sqrt()
>> --> 4
>>
>> x="256";
>> (+x).pow(2) //be sure to call the right .proto
>> --> 65536
>>
>> (1.234).sin().asin()
>> --> 1.234
>>
>> 1..asin() * 2
>> -> 3.141592653589793
>>
>> (2).pow(10)
>> --> 1024
>>
>> 2..pow(10).sqrt()
>> --> 32
>>
>> (100).rnd()
>> -> 0 <= n < 100
>> [...]
>
> Just out of curiosity, does IE support this? I don't see why it
> wouldn't, just making sure

JScript 5.6.6626 as of IE 6.0.2800.1106 supports this. It stands to reason
that later versions of JScript and Internet Explorer, therefore other
MSHTML-based browsers, would also support this (I cannot test them here
yet).

In fact, given that, according to Editions 3 and 5 of the ECMAScript
Language Specification, when evaluating the CallExpression's
/MemberExpression/ any primitive value would be converted into an
appropriate value of type Object (ES3/5, 11.2.3, 11.2.1, and 9.9), this
SHOULD work everywhere where `Number.prototype' is supported (which AFAIK
excludes only JavaScript 1.0 as of Netscape 2.x, and JScript 1.0 as of IE
3.0 and IIS 3.0 ).¹ Tests with JavaScript, Apple JSC, Opera ECMAScript,
and KJS confirmed this a while ago; I could also confirm it for Google V8
2.0 as of Chrome 5.0.307.7 by now. (In fact, this idea is anything but
original.)

However, the better question is: Does it make sense to do this?

You could lose the explicit type conversion to begin with (as it is done
implicitly by the algorithms of the built-in methods of `Math'; see ES3/5,
15.8.2).

Still, with regard to memory efficiency your stack would be one level
higher than without it, and with regard to runtime efficiency you would be
paying for one call more than without it. Stack space being a scarce
resource, and calls being rather expensive, this approach does not appear
to make much sense.


PointedEars
___________
¹ To be sure of that, I have debugged the algorithms of ECMAScript Ed. 5,
and compared with Ed. 3; I can post more detailed results of my
research if anyone is interested.
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

Re: Math ugliness.
 

kangax wrote:

> RobG wrote:
>> Jorge wrote:
>>> Do you think -as I do- that the Math object is an ugly artifact ?
>>> Well, here's a nice way of getting rid of it :
>>>
>>> Number.prototype.sin= function () { return Math.sin(+this); };
>>
>> I'm curious about the use of unary +. Presumably the identifier is
>> resolved to a number primitive in the first place, otherwise x.sin
>> wouldn't resolve to Number.prototype.sin.
>
> I was curious about this too.
>
> I'm guessing ToNumber conversion is there to make method intentionally
> generic, similar to, say, `String.prototype.trim` from ES5, which passes
> its this value through ToString before trimming a value.

It is still superfluous as the methods of `Math' already call ToNumber() on
each of their arguments.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Re: Math ugliness.
 

On Feb 17, 4:10*am, RobG <rg...@iinet.net.au> wrote:
> On Feb 17, 9:23*am, Jorge <jo...@jorgechamorro.com> wrote:
>
> > Hi,
>
> > Do you think -as I do- that the Math object is an ugly artifact ?
> > Well, here's a nice way of getting rid of it :
>
> > Number.prototype.sin= function () { return Math.sin(+this); };
>
> I'm curious about the use of unary +. Presumably the identifier is
> resolved to a number primitive in the first place, otherwise x.sin
> wouldn't resolve to Number.prototype.sin.
>
> Or have I missed something?

I believe it gets -automatically- wrapped in an object just before -in
order to do- the property lookup... ¿?

> [...]
>
> > x="256";
> > (+x).pow(2) //be sure to call the right .proto
> > --> 65536
>
> So if x must be a number in order for the right property to be found,
> why must it also be converted inside the function?

I did that because I recall that new Number(3) !== new Number(3): IOW,
because "this" is -supposedly- an object.

This idea occurred to me yesterday late at night while watching
Crockford on JS video #2, and I just posted it here on the fly without
much/any further ado/testing.
--
Jorge.

Re: Math ugliness.
 

On Feb 17, 6:14*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>
> (...) In fact, this idea is anything but original. (...)

And then came Pointy, decided to spoil the fun... :-)

I've never seen it before.. who, where, when ? Have you got any urls,
plz ?
--
Jorge.

Re: Math ugliness.
 

On Feb 17, 2:23*am, Jorge <jo...@jorgechamorro.com> wrote:
> Hi,
>
> Do you think -as I do- that the Math object is an ugly artifact ?
> Well, here's a nice way of getting rid of it :
>

Artifact of not - that's questionable, because some methods fit to
numbers (e.g. .round(), other), some by semantic - for mathematical
actions and could be placed in separate Math'ematical module.

Other question is style of code. I always don't like to repeat some
chunks of code, I always try to decrease such repetitions. That's why
I really don't like new approach in ES5 for methods to work with
objects which are placed not in `Object.prototype' letting to work in
OOP-style, but in `Object' constructor itself. I know the reasons why
it was done so (such a "protection" if simple object will have own
such property), but that seems to my ugly too (just an abstract
example):

var o = Object.freeze(
Object.seel(
Object.defineProperties(
Object.create(proto),
properties
)
)
);

This repetition of Object.-Object.-Object. is really `heavy'. The
first thing which also can be done in ES5 (to make it more comfortable
in some viewpoint) - is definition of the same methods in
`Object.prototype' (with [[Enumerable]] = false), allowing elegant
chains, decreasing of the repeated chunks of code such as `Object.':

var o = Object.create(proto)
.defineProperties(properties)
.seel()
.freeze();

By the way, e.g. in Ruby, many of this methods (and for numbers and
for objects) are instance methods:

1.5.round()
{'a' => 10}.freeze()

and so on.

/ds

Re: Math ugliness.
 

On Feb 17, 10:15*am, "Dmitry A. Soshnikov"
<dmitry.soshni...@gmail.com> wrote:
>
> By the way, e.g. in Ruby, many of this methods (and for numbers and
> for objects) are instance methods:
>
> 1.5.round()
> {'a' => 10}.freeze()
>
> and so on.

That's the way it ought to be, imo, and JS is powerful enough that
allows for sculpting it at your liking.
--
Jorge.

Re: Math ugliness.
 

On Feb 17, 10:33*am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
>
> - implies two numeric primitive to Number object type-conversations

One sometimes has to wonder what's really going on inside one's
browser... "primitive" "conversations" ? LOL.
--
Jorge.