rubys at intertwingly.net
Wed Sep 17 18:24:34 PDT 2008
On Wed, Sep 17, 2008 at 8:05 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Sep 17, 2008, at 4:48 PM, Sam Ruby wrote:
>> Maciej Stachowiak wrote:
>>> On Sep 17, 2008, at 2:34 PM, Douglas Crockford wrote:
>>>> Sam Ruby wrote:
>>>>> To the extent that I understand Doug's proposal, it essentially
>>>>> is an
>>>>> opt-in that would remove a feature (binary64 floating points); and
>>>>> therefore would likely be about as successful as an opt-in that
>>>>> removed another feature that Doug dislikes, such as "with". Am I
>>>>> missing something?
>>>> It would replace a feature that many consider to be broken with a
>>>> feature that
>>>> we hope will work better.
>>> While decimal floating point may be better than binary floating
>>> point for some applications, such as currency calculations, it
>>> would be unsuitable for other applications such as graphics. Doing
>>> popular application. For example, see Processing.JS, Algorithmic
>>> Ink, Mozilla's recent image filtering demo, and any of a number of
>>> charting and graphic applications.
>>> Using decimal floating point is unacceptable for these kinds of
>>> applications - the performance would not be acceptable. So we
>>> should not go down a path based on the assumption that binary
>>> floating point can be removed.
>> If we agree that binary64 isn't a "bug" that needs to be removed,
>> wouldn't the simplest solution that could possibly work be separate
>> number and decimal data types that can be freely convertible between
>> each other, and the absolutely most a "use decimal" could possibly
>> mean is that the interpretation of numeric literals is as decimal
>> floating point as opposed to binary floating point?
> That approach sounds much better to me than Doug's proposal.
Let's take that a step further. If other languages are any guide,
then complex, rational, and big integer are common requirements. For
the moment, let's assume that unlimited precision integer arithmetic
is the most likely next "number-like" requirement for ES. In Python
such constants end with an "L", so I will use that to illustrate the
next question. But first some background.
9007199254740993 is the smallest positive integer that can't be
exactly represented as a ES number. 9007199254740993L and
9007199254740992m, however can be represented exactly as hypothetical
big integer and 128 bit decimal values.
Given that as background, what should typeof(9007199254740993L) return?
>>> I agree with you and Brendan that these issues are better resolved
>>> in Harmony.
>> At the minimum, I would hope that we should be able to agree on what
>> the issues are. If they can't be worked in time, so be it.
>> Doug has put forward the proposal that Harmony seek to "wholly
>> replace the binary representation with the decimal representation".
>> Is that the consensus of the group?
> I certainly do not agree with his proposal. Other embers of the group
> may speak for themselves, but it was not my understanding previously
> that anyone wanted to go down such a road.
Doug's previous proposal where "use decimal" merely determined whether
a constant like "1.1" would be interpreted as binary64 or decimal128
still may be worth exploring. Presumably with the ability to have a
suffix (like d) to explicitly indicate that a given quantity is double
But given the past history of this language, and the wide deployment
is has enjoyed, I don't think that "use decimal" should ever mean much
more than that.
> - Maciej
- Sam Ruby
More information about the Es-discuss