On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:
> On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:
> >More to the point, *if* typeinfo isn't meant to match == for whatever reason, then why is it being used as the standard of comparison for AA keys?
> >
> 
> I guess we need NaN == NaN to be true for AA keys, no ?

Not according to: http://d.puremagic.com/issues/show_bug.cgi?id=7836

So, should NaN == NaN for AA keys, or not?


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote:
> On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:
>> On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:
>> >More to the point, *if* typeinfo isn't meant to match == for whatever
>> >reason, then why is it being used as the standard of comparison for
>> >AA keys?
>> >
>> 
>> I guess we need NaN == NaN to be true for AA keys, no ?
>
> Not according to: http://d.puremagic.com/issues/show_bug.cgi?id=7836
>
> So, should NaN == NaN for AA keys, or not?
>
>
> T

I think it was not decided yet. From language coherency point of view NaN != NaN like in general case, from usefulness perspective you don't need several nans in AA array.

On Tuesday, July 09, 2013 18:04:29 Maxim Fomin wrote:
> On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote:
> > On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:
> >> On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:
> >> >More to the point, *if* typeinfo isn't meant to match == for
> >> >whatever
> >> >reason, then why is it being used as the standard of
> >> >comparison for
> >> >AA keys?
> >> 
> >> I guess we need NaN == NaN to be true for AA keys, no ?
> > 
> > Not according to: http://d.puremagic.com/issues/show_bug.cgi?id=7836
> > 
> > So, should NaN == NaN for AA keys, or not?
> > 
> > 
> > T
> 
> I think it was not decided yet. From language coherency point of view NaN != NaN like in general case, from usefulness perspective you don't need several nans in AA array.

I'd think that having NaN != NaN would cause serious problems with retrieving any elements inserted with NaN as a key, but given how floating point values work, using them as the key for an AA is arguably completely broken to begin with as comparing floating point values for equality is generally just plain wrong. That being the case, I'd argue in favor of language consistency and just point out to anyone that runs into problems that using a floating point type as the key type of an AA is a stupid thing to do to begin with.

- Jonathan M Davis

Jonathan M Davis:

> That being the case, I'd argue in favor of language consistency

Here I'd like D AAs act as Python dicts. This means breaking "consistency".

Bye,
bearophile

On Tuesday, July 09, 2013 19:19:18 bearophile wrote:
> Jonathan M Davis:
> > That being the case, I'd argue in favor of language consistency
> 
> Here I'd like D AAs act as Python dicts. This means breaking "consistency".

I'm afraid that you'll have to be more specific in terms of what you mean.

But as far as I can tell, using floating point values as keys in an AA is fundamentally broken, because using == with floating point values is fundamentally broken. As such, I see no reason why it should matter that NaN is effectively unusable as an AA key.

- Jonathan M Davis

Jonathan M Davis:

> I'm afraid that you'll have to be more specific in terms of what you mean.

Please ignore what I have said...


> As such, I see no reason why it should matter that NaN
> is effectively unusable as an AA key.

OK.

Bye,
bearophile

On Tuesday, 9 July 2013 at 21:12:15 UTC, Jonathan M Davis wrote:
> On Tuesday, July 09, 2013 19:19:18 bearophile wrote:
>> Jonathan M Davis:
>> > That being the case, I'd argue in favor of language consistency
>> 
>> Here I'd like D AAs act as Python dicts. This means breaking
>> "consistency".
>
> I'm afraid that you'll have to be more specific in terms of what you mean.
>
> But as far as I can tell, using floating point values as keys in an AA is
> fundamentally broken, because using == with floating point values is
> fundamentally broken. As such, I see no reason why it should matter that NaN
> is effectively unusable as an AA key.
>
> - Jonathan M Davis

Using floating point as keys can make sense in an ordered container actually. Just thought I'd point it out.

Basically, instead of looking for specific keys, you try to position yourself between two entries.

But since our AA's are hashed sets, then no, it doesn't make sense for us."

On Tuesday, 9 July 2013 at 17:04:47 UTC, Jonathan M Davis wrote:
> On Tuesday, July 09, 2013 18:04:29 Maxim Fomin wrote:
>> On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote:
>> > On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote:
>> >> On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote:
>> >> >More to the point, *if* typeinfo isn't meant to match == for
>> >> >whatever
>> >> >reason, then why is it being used as the standard of
>> >> >comparison for
>> >> >AA keys?
>> >> 
>> >> I guess we need NaN == NaN to be true for AA keys, no ?
>> > 
>> > Not according to:
>> > http://d.puremagic.com/issues/show_bug.cgi?id=7836
>> > 
>> > So, should NaN == NaN for AA keys, or not?
>> > 
>> > 
>> > T
>> 
>> I think it was not decided yet. From language coherency point of
>> view NaN != NaN like in general case, from usefulness perspective
>> you don't need several nans in AA array.
>
> I'd think that having NaN != NaN would cause serious problems with retrieving
> any elements inserted with NaN as a key, but given how floating point values
> work, using them as the key for an AA is arguably completely broken to begin
> with as comparing floating point values for equality is generally just plain
> wrong. That being the case, I'd argue in favor of language consistency and
> just point out to anyone that runs into problems that using a floating point
> type as the key type of an AA is a stupid thing to do to begin with.
>
> - Jonathan M Davis

That what I meant, and you explained it much better.