sqrt(2) must go

[Manu]

Many architectures do not support real, and therefore it should never be
used implicitly by the language.

Precision problems aside, I would personally insist that implicit
conversation from any sized int always be to float, not double, for
performance reasons (the whole point of a compiled language trying
to supersede C/C++).
Amusingly, 5_000_000_000 IS actually precisely representable with a float
;) .. Bet let's take 5_000_000_001, it'll lose a few bits, but that's more
than precise enough for me.

Naturally the majority would make solid arguments against this preference,
and I would agree with them in their argument, therefore should it not just
be a compiler flag/option to explicitly specify the implicit int->float
conversion precision?

Though that leads to a problem with standard library, since it links a
pre-compiled binary... I can't afford to have the standard library messing
around with doubles because that was the flag it was compiled with...
This leads inevitably to my pointlessly rewriting the standard library
functions in my own code, just as in C where the CRT uses doubles, for the
same reasons...


On 20 October 2011 06:01, Steven Schveighoffer <schveiguy at yahoo.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111020/426017df/attachment-0001.html>