<div class="gmail_quote">On 21 October 2011 10:53, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.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="gmail_quote"><div><div></div><div class="h5">On 21 October 2011 09:00, Don <span dir="ltr"><<a href="mailto:nospam@nospam.com" target="_blank">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>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><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><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></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>
</blockquote></div><br><div>Then again, with regards to 1, the function chosen will depend on the magnitude of the int, perhaps a foreign constant, you might not clearly be able to know which one is called... What if the ambiguous overloads don't actually perform identical functionality with just different precision? .. I don't like the idea of it being uncertain.</div>
<div><br></div><div>And one more thing to ponder, is the return type telling here?</div><div>float x = sqrt(2);</div><div>Obviously this may only work for these pure maths functions where the return type is matched to the args, but maybe it's an element worth considering.</div>
<div>ie, if the function parameter is ambiguous, check for disambiguation via the return type...? Sounds pretty nasty! :)</div>