Spec proposal
On Dec 13, 2007 5:07 PM, Michael O'Brien <mob at mbedthis.com> wrote:
I understand that the cut off for proposals is long past. But I believe this is an important issue that will force non-standard implementations .... bad.
Proposal:
Running ECMAScript on embedded devices is more and more common. It is being used in mobile phone widget engines, mobile browsers and it a wide variety of embedded infrastructure hardware. However many such devices do not have floating point and this has forced non-standard language extensions to allow other default numeric types. For example: most feature phones (> 500M devices) do not have floating point and have very modest CPU resources. Furthermore, the proposed ES4 decimal standard is currently implemented in software as there is no common hardware support for it (yet). Consequently, it is fairly large and slow and will certainly put a strain on feature phones!
We should allow the default number type to be an integer or 64 bit integer. Many of embedded devices have very good 64bit integer support that is quite fast. 64 bit integer support is important if floating point or decimal is not available to provide a wider scale of numeric values.
To do this, I'd like to propose that:
We change the "use decimal" pragma to "use number NUMBER_TYPE". This would allow for other number types. E.g.
use number decimal use number int
We add support for int as the default number
We add "long" and ulong types that are by definition 64 bit. Also support "use number long"
I have a couple of comments.
First, the "use decimal" pragma has been changed radically from older proposals and no longer allows the program to select "decimal everywhere" semantics. (What it does allow is a little bit in flux. At a minimum it allows controlling rounding and precision.)
Second, several good implementations of ES3 fall back on double arithmetic sparingly in practice by using clever representations; for example, "1" is represented as an int, "1 + 2" uses int arithmetic only (with an overflow check). The same trick could be used if the default were decimal. An implementation could extend this principle up to 53 bits of precision, after which it would have to go to floating point or become very clever. "53 bits ought to be enough for anyone." (Making all its values decimal would give the program in excess of 100 bits of integer precision ;-)
My beef with ECMAScript at this point is that it has no integer divide operator and no easy way to signal to the implementation that that's what desired. In practice, "/" forces us into floating point.
On Thu, 2007-12-13 at 08:07 -0800, Michael O'Brien wrote:
I believe this is an important issue that will force non-standard implementations...
On the same topic, it seems that Adobe are planning on introducing the decimal type into the Flash Player before the ES4 spec. is finalised. They're asking Flash developers at the moment what their requirements are for "decimal math".
Is the spec. at the point where implementers can start preempting it?
Cheers,
-- Nathan de Vries
On Dec 13, 2007, at 3:09 PM, Nathan de Vries wrote:
On Thu, 2007-12-13 at 08:07 -0800, Michael O'Brien wrote:
I believe this is an important issue that will force non-standard implementations...
On the same topic, it seems that Adobe are planning on introducing the decimal type into the Flash Player before the ES4 spec. is finalised. They're asking Flash developers at the moment what their requirements are for "decimal math".
Is the spec. at the point where implementers can start preempting it?
Not quite, but no one is going to preempt -- the early implementors
will have to shift if they want to claim conformance to the final
spec. We've done this in the past in Mozilla and it has been tolerable.
Michael's point seemed to me to be more about divergent long/ulong
semantics and no spec, not early implementations trumped by the one
true spec.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20071213/17d5ac3d/attachment-0002
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20071213/cb7d1e12/attachment-0002
On Dec 14, 2007 5:54 AM, Michael O'Brien <mob at mbedthis.com> wrote:
Lars,
I'm not sure quite what you are saying here.
Are you saying that ES4 should automatically scale numerics up seamlessly from integer to decimal by detecting overflow much as Ruby does? ie. the default number type is not decimal, but rather the numeric type will expand as required up to 128 bit decimal numbers. Is this what you are saying?
I'm saying that current ES3 implementations do this (int/uint representations overflow to double as needed in order to use the integer hardware and avoid using (software) fp) and that ES4 implementations will do the same.
Decimal is really not part of that discussion.
If so, then can an implementation be compliant if it:
Has no floating point h/w or s/w
If it has no floating point at all it can't be compliant with ES3.
Has no decimal ie. could an implementation be compliant if it does not support floating point arithmetic and can only scale up to 32 or 64 bit integers?
This is what many embedded devices need. I think the spec should accommodate these devices without breaking the spec.
My opinion is that subset implementations will exist in any case -- for example, ActionScript has no "eval" and no "Function" constructor -- and that the spec should not address these needs because the complexity cost in the spec is too great. If an implementation wants to do away with IEEE double numbers and use 64-bit ints instead, and do all the work with retrofitting libraries and so on and choose whether to support trig functions or not, then I think it's better if this cost is borne by the implementor or by a derivative standard, not by the ES4 spec, which is plenty complicated already.
(Also note that TG1 rejected the previous proposal on "use decimal" (meaning "pretend all numbers are decimal") because we did not think it could be made to work reliably. The same argument would go for any other number type IMO.)
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20071214/9942d65e/attachment-0002
On 2007-12-13, at 15:50 EST, Lars T Hansen wrote:
My beef with ECMAScript at this point is that it has no integer divide operator and no easy way to signal to the implementation that that's what desired. In practice, "/" forces us into floating point.
Couldn't this be fixed upward-compatibly by adding an optional second
argument to floor, ceiling, round, and truncate the way Lisp and
Dylan do?
Surely:
var int x = int(y) / int(z);
also signals that an integer divide is desired (although the desired
rounding mode is is unclear).
I understand that the cut off for proposals is long past. But I believe this is an important issue that will force non-standard implementations .... bad.
Proposal:
Running ECMAScript on embedded devices is more and more common. It is being used in mobile phone widget engines, mobile browsers and it a wide variety of embedded infrastructure hardware. However many such devices do not have floating point and this has forced non-standard language extensions to allow other default numeric types. For example: most feature phones (> 500M devices) do not have floating point and have very
modest CPU resources. Furthermore, the proposed ES4 decimal standard is currently implemented in software as there is no common hardware support for it (yet). Consequently, it is fairly large and slow and will certainly put a strain on feature phones!
We should allow the default number type to be an integer or 64 bit integer. Many of embedded devices have very good 64bit integer support that is quite fast. 64 bit integer support is important if floating point or decimal is not available to provide a wider scale of numeric values.
To do this, I'd like to propose that:
We change the "use decimal" pragma to "use number NUMBER_TYPE". This would allow for other number types. E.g.
use number decimal use number int
We add support for int as the default number
We add "long" and ulong types that are by definition 64 bit. Also support "use number long"
Michael O'Brien
I understand that the cut off for proposals is long past. But I believe this is an important issue that will force non-standard implementations .... bad. Proposal: Running ECMAScript on embedded devices is more and more common. It is being used in mobile phone widget engines, mobile browsers and it a wide variety of embedded infrastructure hardware. However many such devices do not have floating point and this has forced non-standard language extensions to allow other default numeric types. For example: most feature phones (> 500M devices) do not have floating point and have very modest CPU resources. Furthermore, the proposed ES4 decimal standard is currently implemented in software as there is no common hardware support for it (yet). Consequently, it is fairly large and slow and will certainly put a strain on feature phones! We should allow the default number type to be an integer or 64 bit integer. Many of embedded devices have very good 64bit integer support that is quite fast. 64 bit integer support is important if floating point or decimal is not available to provide a wider scale of numeric values. To do this, I'd like to propose that: 1. We change the "use decimal" pragma to "use number NUMBER_TYPE". This would allow for other number types. E.g. use number decimal use number int 2. We add support for int as the default number 3. We add "long" and ulong types that are by definition 64 bit. Also support "use number long" Michael O'Brien