sqrt(2) must go

[Don]

On 20.10.2011 05:01, Steven Schveighoffer wrote:
> On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques <sandford at jhu.edu>
> wrote:
>
>> On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise <Marco.Leise at gmx.de>
>> wrote:
>>> Am 20.10.2011, 02:46 Uhr, schrieb dsimcha <dsimcha at yahoo.com>:
>>>
>>>> On 10/19/2011 6:25 PM, Alvaro wrote:
>>>>> El 19/10/2011 20:12, dsimcha escribió:
>>>>>> == Quote from Don (nospam at nospam.com)'s article
>>>>>>> The hack must go.
>>>>>>
>>>>>> No. Something as simple as sqrt(2) must work at all costs, period. A
>>>>>> language
>>>>>> that adds a bunch of silly complications to something this simple is
>>>>>> fundamentally
>>>>>> broken. I don't remember your post on implicit preferred conversions,
>>>>>> but IMHO
>>>>>> implicit conversions of integer to double is a no-brainer. Requiring
>>>>>> something
>>>>>> this simple to be explicit is Java/Pascal-like overkill on
>>>>>> explicitness.
>>>>>
>>>>> Completely agree.
>>>>>
>>>>> I call that uncluttered programming. No excessive explicitness
>>>>> should be
>>>>> necessary when what you mean is obvious (under some simple
>>>>> conventions).
>>>>> Leads to clearer code.
>>>>>
>>>>
>>>> Yes, and for the most part uncluttered programming is one of D's
>>>> biggest
>>>> strengths. Let's not ruin it by complicating sqrt(2).
>>>
>>> What is the compiler to do with sqrt(5_000_000_000) ? It doesn't fit
>>> into
>>> an int, but it fits into a double.
>>
>> Simple, is a 5_000_000_000 long, and longs convert to reals. Also,
>> 5_000_000_000 does not fit, exactly inside a double.
>
> It doesn't? I thought double could do 53 bits?
>
> Although I agree, long should map to real, because obviously not all
> longs fit into a double exactly.
>
> -Steve

But ulong.max does NOT fit into an 80-bit real. And long won't fit into 
real on anything other than x86, 68K, and Itanium.

I don't think long and ulong should ever implicitly convert to floating 
point types. Note that you can just do *1.0 or *1.0L if you want to 
convert them.

Currently long implicitly converts even to float. This seems quite bad, 
it loses 60% of its bits!!

Suppose we also banned implicit conversions int->float and uint->float 
(since float only has 24 bits, these are lossy conversions, losing 25% 
of the bits).

Now that we've disallowed lossy integral conversions, it really seems 
that we should disallow these ones as well.

If that was all we did, it would also mean that things like short+short 
wouldn't convert to float either, because C converts everything to int 
whenever it gets an opportunity. But we could use range checking to 
restore this (and to allow small longs to fit into doubles: allow 
conversion to double if it's <= 53 bits, allow conversion to float if <= 
24 bits).