sqrt(2) must go

Manu turkeyman at gmail.com
Thu Oct 20 06:54:48 PDT 2011


On 20 October 2011 16:11, Don <nospam at nospam.com> wrote:

> On 20.10.2011 14:48, Manu wrote:
>
>> On 20 October 2011 15:13, Don <nospam at nospam.com
>>
>> <mailto: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>
>>        <mailto: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?
>> }
>>
>
> Actually there is a problem there, I think. If someone later on adds
> NotOverload(double x), that call will suddenly stop compiling.
>
> That isn't just a theoretical problem.
> Currently log(2) will compile, but only because in std.math there is
> log(real), but not yet log(double) or log(float).
> So once we add those overloads, peoples code will break.
>
> I'd like to get to the situation where those overloads can be added
> without breaking peoples code. The draconian possibility is to disallow
> them in all cases: integer types never match floating point function
> parameters.
> The second possibility is to introduce a tie-breaker rule: when there's an
> ambiguity, choose double.
> And a third possibility is to only apply that tie-breaker rule to literals.
> And the fourth possibility is to keep the language as it is now, and allow
> code to break when overloads get added.
>
> The one I really, really don't want, is the situation we have now:
> #5: whenever an overload gets added, introduce a hack for that function...
>
>
>  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.
>>
>
> I don't know. I think I probably prefer possibility #1 on my list, but
> it'd break existing code. I also like #2 and #3, and I think they'd be more
> generally popular.
> I don't like #4, but anything is better than #5.
>

Hmmm.

I generally like #1, it encourages awareness of the clear distinction
between integer and floating types (something that far too many programmers
lack)
I don't really like #2, it's just arbitrary, and totally subjective. You'll
never have agreement, and perhaps more importantly, it's not instinctively
obvious which it will choose and why... you just have to know, and most
people won't know, they'll just use it blind (see my point about
finding+fixing code by junior/ignorant programmers)
#3 is just a less consistent version of #2... and less easy to catch
the culprit committing the crime, and less obvious to the culprit that they
are committing a crime.
I don't HATE #4, it's not capable of causing any real problem in the code,
it just requires placement of a cast, which anyone can do. But I prefer #1,
solving that problem.
#5 is obviously silly.

In order of preference: 1, 4, 2, 3, 5

I could only support 2 if it chooses 'float', the highest performance
version on all architectures AND actually available on all architectures;
given this is meant to be a systems programming language, and supporting as
many architectures as possible?
If the argument is made to favour precision, then it should surely be real,
not double... the counter argument is obviously that real is not supported
on many architectures, true, but the same is true for double... so I think
it's a hollow argument.
double just seem like a weak compromise; more precise than float, and more
likely to work on more architectures than real (but still not guaranteed),
but it doesn't really satisfy either criteria neatly.
The logic transposed: double is less precise than real, and potentially
slower than float. Is the justification purely that it IS a compromise,
since the choice at the end of the day is totally subjective :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111020/201a2412/attachment.html>


More information about the Digitalmars-d mailing list