<div class="gmail_quote">On 20 October 2011 10:55, Don <span dir="ltr"><<a href="mailto:nospam@nospam.com">nospam@nospam.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On 20.10.2011 05:01, Steven Schveighoffer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques <<a href="mailto:sandford@jhu.edu" target="_blank">sandford@jhu.edu</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise <<a href="mailto:Marco.Leise@gmx.de" target="_blank">Marco.Leise@gmx.de</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am 20.10.2011, 02:46 Uhr, schrieb dsimcha <<a href="mailto:dsimcha@yahoo.com" target="_blank">dsimcha@yahoo.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/19/2011 6:25 PM, Alvaro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
El 19/10/2011 20:12, dsimcha escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
== Quote from Don (<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a>)'s article<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The hack must go.<br>
</blockquote>
<br>
No. Something as simple as sqrt(2) must work at all costs, period. A<br>
language<br>
that adds a bunch of silly complications to something this simple is<br>
fundamentally<br>
broken. I don't remember your post on implicit preferred conversions,<br>
but IMHO<br>
implicit conversions of integer to double is a no-brainer. Requiring<br>
something<br>
this simple to be explicit is Java/Pascal-like overkill on<br>
explicitness.<br>
</blockquote>
<br>
Completely agree.<br>
<br>
I call that uncluttered programming. No excessive explicitness<br>
should be<br>
necessary when what you mean is obvious (under some simple<br>
conventions).<br>
Leads to clearer code.<br>
<br>
</blockquote>
<br>
Yes, and for the most part uncluttered programming is one of D's<br>
biggest<br>
strengths. Let's not ruin it by complicating sqrt(2).<br>
</blockquote>
<br>
What is the compiler to do with sqrt(5_000_000_000) ? It doesn't fit<br>
into<br>
an int, but it fits into a double.<br>
</blockquote>
<br>
Simple, is a 5_000_000_000 long, and longs convert to reals. Also,<br>
5_000_000_000 does not fit, exactly inside a double.<br>
</blockquote>
<br>
It doesn't? I thought double could do 53 bits?<br>
<br>
Although I agree, long should map to real, because obviously not all<br>
longs fit into a double exactly.<br>
<br>
-Steve<br>
</blockquote>
<br></div></div>
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.<br>
<br>
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.<br>
<br>
Currently long implicitly converts even to float. This seems quite bad, it loses 60% of its bits!!<br>
<br>
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).<br>
<br>
Now that we've disallowed lossy integral conversions, it really seems that we should disallow these ones as well.<br>
<br>
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).<br>

</blockquote></div><br><div>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.</div><div>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.</div>
<div><br></div><div>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.</div><div>Floating point arithmetic will accumulate error all on its own, so why be so concerned if the cast is perfect?</div>
<div><br></div><div><div>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...</div></div>