Spec proposal

[Lars T Hansen]

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.)

--lars

>
>  Michael
>
>
>
>
>  Lars T Hansen wrote:
>  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:
>
> 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"
>
>  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.
>
> --lars
>
>
>