Math ugliness.
in [JavaScript]
|
From: John G Harris on 20 Feb 2010 13:59 On Sat, 20 Feb 2010 at 14:07:03, in comp.lang.javascript, Lasse Reichstein Nielsen wrote: >Thomas 'PointedEars' Lahn <PointedEars(a)web.de> writes: > >> John G Harris wrote: > >>> It's clear what 2.3 + 1.4 means, but to say that 2.3 'knows' how to >>> add 1.4 to itself is pure nonsense. >> >> Evidence readily proves you wrong, although not in current ECMAScript >> implementations. > >It's clear that other languages have taken the road of having math >operations that work by sending messages to one of the arguments. >In that way, it "makes sense". > >When numbers are objects[1], it makes sense to have operations on that >number as methods of the number. Methods with only one parameter can >use "this" as that parameter. > >However, when you have a method that take two, equally important, >parameters, and that doesn't mutate either (or really: and doesn't >depend on the identity of either), it's not obvious which of them >should carry the method. Alternatively, you could make + an object, a function object. That makes much more sense as you would expect + to know about numbers and how to take two numbers and return another number. No mutation of immutable things here. Whether you can access the + object is a matter of language design. You can in some languages, but they tend to spell it 'add' :-( Incidentally, you seem to have missed out your [1] text. <snip> >>> For a start, 2.3 is not mutable. >> >> It could be, were the language defined differently. > >Then it would not be a 2.3 object, but just a boxed number. >If you did: > var x = 2.3; > var y = 2.3; >and 2.3 was mutable ... would x.mutate() mean that the value of >y changed? Or did the two 2.3's have different identity? Or y = x; even more so. >>> A coherent type system has each type built from 'simpler' types, or from >>> foundation types. The system needs these foundation types to be able to >>> do proofs by induction and to define mathematical properties using >>> recursion. Primitive types are the foundation types. >> >> They are unnecessary. Foundation types can be object types as well. > >Correct. And they were in, e.g., Smalltalk. Every object has a value, which now can only be an object. The result is that you have objects all the way down, for ever. This disaster can only be rescued by having an object that doesn't have a value. That becomes the foundation object. <snip> >>> In contrast, if you insist that every property holds an object and >>> nothing else then you've some complicated specifying to do in order to >>> put numbers and character arrays in there somewhere. >> >> No. > >Agree, that's an implementation problem, not a specification problem, >and it has been shown possible to implement. See above. John -- John Harris
From: Lasse Reichstein Nielsen on 20 Feb 2010 19:20 John G Harris <john(a)nospam.demon.co.uk> writes: > Alternatively, you could make + an object, a function object. That makes > much more sense as you would expect + to know about numbers and how to > take two numbers and return another number. No mutation of immutable > things here. If functions are objects, you won't need an object to store the plus method on, but then you can't really talk about sending messages to objects (unless you send the "invoke" message to the function object). > Incidentally, you seem to have missed out your [1] text. Whoops. I removed it deliberatly, but left the [1] in the text. > Every object has a value, No. Objects *are* values. They have identity, but not necessarily anything else. They *might* also have properties (values) and methods (behavior). The empty object is a perfectly good object. > which now can only be an object. The result is that you have objects > all the way down, for ever. > This disaster can only be rescued by having an object that doesn't have > a value. That becomes the foundation object. There can be many objects with no values, e.g., anything created using "new Object()" in Java. If numbers are objects, there is nothing problematic in that. The object 42 doesn't have a value. It is the value. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: John G Harris on 21 Feb 2010 11:03 On Sun, 21 Feb 2010 at 01:20:03, in comp.lang.javascript, Lasse Reichstein Nielsen wrote: >John G Harris <john(a)nospam.demon.co.uk> writes: > >> Alternatively, you could make + an object, a function object. That makes >> much more sense as you would expect + to know about numbers and how to >> take two numbers and return another number. No mutation of immutable >> things here. > >If functions are objects, you won't need an object to store the plus >method on, but then you can't really talk about sending messages to >objects (unless you send the "invoke" message to the function object). I'm saying the compiler could translate op1 + op2 into +.call(this, op1, op2) where + is a function object that is internal, hidden from our view (and 'this' is ignored). In fact, that's probably pretty close to what it does do at present. >> Incidentally, you seem to have missed out your [1] text. > >Whoops. I removed it deliberatly, but left the [1] in the text. > >> Every object has a value, > >No. Objects *are* values. They have identity, but not necessarily >anything else. They *might* also have properties (values) and methods >(behavior). >The empty object is a perfectly good object. According to ECMA 262 every object has an internal [[Value]] property, which we can't remove. So, no object is truly empty. Every object has a [[Prototype]] property as well. >> which now can only be an object. The result is that you have objects >> all the way down, for ever. >> This disaster can only be rescued by having an object that doesn't have >> a value. That becomes the foundation object. > >There can be many objects with no values, e.g., anything created using >"new Object()" in Java. As above, there are no objects with no values. If everything is an object then following the [[Value]] properties downwards will take forever. Likewise for following the [[Prototype]] property. >If numbers are objects, there is nothing problematic in that. The >object 42 doesn't have a value. It is the value. I don't think you've explained what 'the object 42' means. Does it mean the literal ? Or a new Number(42) object ? If the latter, its [[Value]] is 42. The object contains the value but is more than the value. HTH John -- John Harris
From: Dr J R Stockton on 25 Feb 2010 16:45 In comp.lang.javascript message <55724004-b075-48be-a9f8-bd1d01e2374e(a)z1 9g2000yqk.googlegroups.com>, Tue, 16 Feb 2010 15:23:12, Jorge <jorge(a)jorgechamorro.com> posted: > >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(); } Maybe useful for legibility, which means an aid to coding the desired algorithm. OTOH, is it better than enclosing maths as with (Math) { ... } // ? Expected modest loss in performance, which only matters in those relatively few cases where JavaScript maths is neither inconveniently slow nor unnecessarily fast. For those who want legibility and speed, you could write code to translate "your" maths to/from the standard form. Your eventual examples need to show how to get, for example, the sine of an expression; and to warn that 3.sin() is not the same as 3.0.sin(). Those will not be instantly and certainly obvious to all. How about writing a Reverse Polish Notation interpreter in JavaScript, to suggest that RPN may one day be included in the language proper? My LONGCALC.EXE reads, and uses, RPN. Compare : most methods of the standard Date Object return the date in milliseconds, which is rarely much use. In my DATE2 object, they generally return (a reference to) the object itself, so that one can do D = new DATE2().setXDate(3).setXHours(5) to go to the third of the current month, time [05:00, 06:00). To get the milliseconds, just prepend a unary +. -- (c) John Stockton, Surrey, 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)
From: Jorge on 26 Feb 2010 09:09
On Feb 25, 10:45 pm, Dr J R Stockton <reply1...(a)merlyn.demon.co.uk> wrote: > In comp.lang.javascript message <55724004-b075-48be-a9f8-bd1d01e2374e(a)z1 > 9g2000yqk.googlegroups.com>, Tue, 16 Feb 2010 15:23:12, Jorge > <jo...(a)jorgechamorro.com> posted: > > > > >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(); } > > Maybe useful for legibility, which means an aid to coding the desired > algorithm. OTOH, is it better than enclosing maths as > with (Math) { ... } // ? > > Expected modest loss in performance, which only matters in those > relatively few cases where JavaScript maths is neither inconveniently > slow nor unnecessarily fast. > > For those who want legibility and speed, you could write code to > translate "your" maths to/from the standard form. > > Your eventual examples need to show how to get, for example, the sine of > an expression; and to warn that 3.sin() is not the same as 3.0.sin(). > Those will not be instantly and certainly obvious to all. Yep. I think in general Number literals ought to be enclosed in parens. And some math methods could be getters, but I wonder whether (12345).rnd.floor is any clearer than (12345).rnd().floor(). Some other methods, as e.g. "pow", could not, as they require a parameter. > How about writing a Reverse Polish Notation interpreter in JavaScript, > to suggest that RPN may one day be included in the language proper? My > LONGCALC.EXE reads, and uses, RPN. You'd need a stack for that, and an "enter" operator, and roll down, x<->y etc. stack handling operators. Oh, how far away are the days with my hp65... the 100 steps, the 10 memories, the 5 labels, those magnetic cards, the beautiful led display, DSP.2 :-) > (...) -- Jorge. |