# sqrt(2) must go

Martin Nowak dawg at dawgfoto.de
Thu Oct 20 04:05:59 PDT 2011

```On Thu, 20 Oct 2011 09:55:51 +0200, Don <nospam at nospam.com> wrote:

> 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).
>>>>>>
>>>>>
>>>>> 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).
I'd really like to see, that all conversion were based on value range
propagation
instead of the strange C rules.

Thankfully this discussion reminded reminded me of an ugly header file bug
http://d.puremagic.com/issues/show_bug.cgi?id=6833.

martin
```