sqrt(2) must go

[Manu]

On 20 October 2011 15:13, Don <nospam at nospam.com> 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.
>
>
>  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.
>

Yeah sorry, I think you're right, the discussion got slightly lost in the
noise here...

Just to clarify, where you advocate eliminating implicit casting, do you
now refer to ALL implicit casting? Or just implicit casting to an ambiguous
target?

Let me reposition myself to suit what it would seem is actually being
discussed... :)

void sqrt(float x);
void sqrt(double x);
void sqrt(real x);

{
  sqrt(2);
}

Surely this produces some error: "Ambiguous call to overloaded function",
and then there is no implicit cast rule to talk about... end of discussion?

But you speak of "eliminating implicit casting" as if this may also refer
to:

void NotOverloaded(float x);

{
  NotOverloaded(2); // not ambiguous... so what's the problem?
}

or:

float x = 10;

Which I can imagine why most would feel this is undesirable...

I'm not clear now where you intend to draw the lines.
If you're advocating banning ALL implicit casting between float/int
outright, I actually feel really good about that idea. I can just imagine
the number of hours saved while optimising where junior/ignorant
programmers cast back and fourth with no real regard to or awareness of
what they're doing.

Or are we only drawing the distinction for literals?
I don't mind a compile error if I incorrectly state the literal a function
expects. That sort of thing becomes second nature in no time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111020/262a2212/attachment.html>