sqrt(2) must go

[Robert Jacques]

On Fri, 21 Oct 2011 09:00:48 -0400, Manu <turkeyman at gmail.com> wrote:
> On 21 October 2011 10:53, Manu <turkeyman at gmail.com> wrote:
>> On 21 October 2011 09:00, Don <nospam at nospam.com> wrote:
[snip]
>> 1: Seems reasonable for literals; "Integer literals and expressions should
>> use range propagation to use
>> the thinnest loss-less conversion"... but can you clarify what you mean by
>> 'expressions'? I assume we're talking strictly literal expressions?

Consider sqrt(i % 10). No matter what i is, the range of i % 10 is 0-9.

I was more thinking of whether plain old assignment would be allowed:

float f = myshort;

Of course, if we deny implicit conversion, shouldn't the following fail to compile?

float position = index * resolution;

>> 2b: Does runtime bounds checking actually addresses the question; which of
>> an ambiguous function to choose?
>> 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... :/
>> Perhaps I missed something?

Yes, nut only because I didn't include it. I was thinking of

float f = i;

as opposed to

func(i)

for some reason. Bounds checking would only make sense if func(float) was the only overload.

>> Naturally all this complexity assumes we go with the tie-breaker approach,
>> which I'm becoming more and more convinced is a bad plan...
>>
>
> 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? ..

Then whoever wrote the library was Evil(tm). Given that these rules wouldn't interfere with function hijacking, I'm not sure of the practicality of this concern. Do you have an example?

> I don't like the idea of it being uncertain.
>
> And one more thing to ponder, is the return type telling here?
> float x = sqrt(2);
> 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.
> ie, if the function parameter is ambiguous, check for disambiguation via
> the return type...? Sounds pretty nasty! :)