sqrt(2) must go

[Manu]

On 20 October 2011 10:55, 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).
>>>>>> 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).
>

You're making a bunch of references to loss of bits, but I think this is
misleading... you need to consider that loss of bits does NOT translate
linearly to loss of precision.
Losing 25% of 32bits results in a loss of 0.00001% precision, something I'm
perfectly happy to accept in virtually any floating point maths I've ever
written.

When I cast an int to a float, I don't expect it to retain perfect
precision, thus is the nature of floating point maths.
Floating point arithmetic will accumulate error all on its own, so why be
so concerned if the cast is perfect?

Remember, even float32 is perfectly capable of representing the magnitude
of ints of ANY size, and this will still result in solid results when
passing to functions like sqrt(), etc...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111020/db8ae9be/attachment.html>