sqrt(2) must go

[Don]

On 20.10.2011 13:12, Manu wrote:
> On 20 October 2011 11:02, Don <nospam at nospam.com
> <mailto:nospam at nospam.com>> wrote:
>
>     On 20.10.2011 09:47, Manu wrote:
>
>         Many architectures do not support real, and therefore it should
>         never be
>         used implicitly by the language.
>
>         Precision problems aside, I would personally insist that implicit
>         conversation from any sized int always be to float, not double, for
>         performance reasons (the whole point of a compiled language trying
>         to supersede C/C++).
>
>
>     On almost all platforms, float and double are the same speed.
>
>
> This isn't true. Consider ARM, hard to say this isn't a vitally
> important architecture these days, and there are plenty of embedded
> architectures that don't support doubles at all, I would say it's a
> really bad idea to invent a systems programming language that excludes
> many architectures by its design... Atmel AVR is another important
> architecture.

It doesn't exclude anything. What we're talking about as desirable 
behaviour, is exactly what C does. If you care about performance on ARM, 
you'll type sqrt(2.0f).

Personally, I'd rather completely eliminate implicit conversions between 
integers and floating point types. But that's just me.

> I maintain that implicit conversion of integers of any length should
> always target the same precision float, and that should be a compiler
> flag to specify the desired precision throughout the app (possibly
> defaulting to double).

I can't believe that you'd ever write an app without that being an 
upfront decision. Casually flipping it with a compiler flag??
Remember that it affects very few things (as discussed below).

> If you choose 'float' you may lose some precision obviously, but you
> expected that when you chose the options, and did the cast...

Explicit casts are not affected in any way.

>     Note that what we're discussing here is parameter passing of single
>     values; if it's part of an aggregate (array or struct), the issue
>     doesn't arise.
>
>
> Are we? I thought we were discussing implicit conversion of ints to
> floats? This may be parameter passing, but also assignment I expect?

There's no problem with assignment, it's never ambiguous.

There seems to be some confusion about what the issue is.
To reiterate:

void foo(float x) {}
void foo(double x) {}

void bar(float x) {}

void baz(double x) {}

void main()
{
    bar(2); // OK -- 2 becomes 2.0f
    baz(2); // OK -- 2 becomes 2.0
    foo(2); // fails -- ambiguous.
}

My proposal was effectively: if it's ambiguous, choose double. That's all.