sqrt(2) must go

[Alex Rønne Petersen]

On 20-10-2011 14:13, Don wrote:
> 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.

+1.

>
>> 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.