<div class="gmail_quote">On 21 October 2011 09:00, 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 class="im">On 21.10.2011 05:24, Robert Jacques wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 20 Oct 2011 09:11:27 -0400, Don <<a href="mailto:nospam@nospam.com" target="_blank">nospam@nospam.com</a>> wrote:<br>
[snip]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd like to get to the situation where those overloads can be added<br>
without breaking peoples code. The draconian possibility is to disallow<br>
them in all cases: integer types never match floating point function<br>
parameters.<br>
The second possibility is to introduce a tie-breaker rule: when there's<br>
an ambiguity, choose double.<br>
And a third possibility is to only apply that tie-breaker rule to<br>
literals.<br>
And the fourth possibility is to keep the language as it is now, and<br>
allow code to break when overloads get added.<br>
<br>
The one I really, really don't want, is the situation we have now:<br>
#5: whenever an overload gets added, introduce a hack for that<br>
function...<br>
</blockquote>
<br>
I agree that #5 and #4 not acceptable longer term solutions. I do<br>
CUDA/GPU programming, so I live in a world of floats and ints. So<br>
changing the rules does worries me, but mainly because most people don't<br>
use floats on a daily basis, which introduces bias into the discussion.<br>
</blockquote>
<br></div>
Yeah, that's a valuable perspective.<br>
sqrt(2) is "I don't care what the precision is".<br>
What I get from you and Manu is:<br>
if you're working in a float world, you want float to be the tiebreaker.<br>
Otherwise, you want double (or possibly real!) to be the tiebreaker.<br>
<br>
And therefore, the<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thinking it over, here are my suggestions, though I'm not sure if 2a or<br>
2b would be best:<br>
<br>
1) Integer literals and expressions should use range propagation to use<br>
the thinnest loss-less conversion. If no loss-less conversion exists,<br>
then an error is raised. Choosing double as a default is always the<br>
wrong choice for GPUs and most embedded systems.<br>
2a) Lossy variable conversions are disallowed.<br>
2b) Lossy variable conversions undergo bounds checking when asserts are<br>
turned on.<br>
</blockquote>
<br></div>
The spec says: "Integer values cannot be implicitly converted to another type that cannot represent the integer bit pattern after integral promotion."<br>
Now although that was intended to only apply to integers, it reads as if it should apply to floating point as well.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The idea behind 2b) would be:<br>
<br>
int i = 1;<br>
float f = i; // assert(true);<br>
i = int.max;<br>
f = i; // assert(false);<br>
</blockquote>
<br></div>
That would be catastrophically slow.<br>
<br>
I wonder how painful disallowing lossy conversions would be.<br></blockquote><div><br></div><div class="gmail_quote"><div>1: Seems reasonable for literals; "Integer literals and expressions should use range propagation to use</div>
the thinnest loss-less conversion"... but can you clarify what you mean by 'expressions'? I assume we're talking strictly literal expressions?</div><div><br></div><div>2b: Does runtime bounds checking actually addresses the question; which of an ambiguous function to choose?</div>
<div>If I read you correctly, 2b suggests bounds checking the implicit cast for data loss at runtime, but which to choose? float/double/real? We'll still arguing that question even with this proposal taken into consideration... :/</div>
<div>Perhaps I missed something?</div><div><br></div><div>Naturally all this complexity assumes we go with the tie-breaker approach, which I'm becoming more and more convinced is a bad plan...</div></div>