sqrt(2) must go

[Jonathan M Davis]

On Thursday, October 20, 2011 21:52:32 Manu wrote:
> On 20 October 2011 17:28, Simen Kjaeraas <simen.kjaras at gmail.com> wrote:
> > On Thu, 20 Oct 2011 15:54:48 +0200, Manu <turkeyman at gmail.com> wrote:
> >  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?
> > 
> > D specifically supports double (as a 64-bit float), regardless of the
> > actual hardware. Also, the D way is to make the correct way simple, the
> > fast way possible. This is clearly in favor of not using float, which
> > *would* lead to precision loss.
> 
> Correct, on all architectures I'm aware of that don't have hardware double
> support, double is emulated, and that is EXTREMELY slow.
> I can't imagine any case where causing implicit (hidden) emulation of
> unsupported hardware should be considered 'correct', and therefore made
> easy.

Correctness has _nothing_ to do with efficiency. It has to do with the result 
that you get. Losing precision means that your code is less correct.

> The reason I'm so concerned about this, is not for what I may or may not do
> in my code, I'm likely to be careful, but imagine some cool library that I
> want to make use of... some programmer has gone and written 'x = sqrt(2)'
> in this library somewhere; they don't require double precision, but it was
> implicitly used regardless of their intent. Now I can't use that library in
> my project.
> Any library that wasn't written with the intent of use in embedded systems
> in mind, that happens to omit all of 2 characters from their float literal,
> can no longer be used in my project. This makes me sad.
> 
> I'd also like you to ask yourself realistically, of all the integers you've
> EVER cast to/from a float, how many have ever been a big/huge number? And
> if/when that occurred, what did you do with it? Was the precision
> important? Was it important enough to you to explicitly state the cast?
> The moment you use it in a mathematical operation you are likely throwing
> away a bunch of precision anyway, especially for the complex functions like
> sqrt/log/etc in question.

When dealing with math functions like this, it doesn't really matter whether 
the number being passed in is a large one or not. It matters what you want for 
the return type. And the higher the precision, the more correct the result, so 
there are a lot of people who would want the result to be real, rather than 
float or double. It's when your concern is efficiency that you start worrying 
about whether a float would be better. And yes, efficiency matters, but if 
efficiency matters, then you can always tell it 2.0f instead of 2. Don's 
suggestion results in the code being more correct in the general case and yet 
still lets you easily make it more efficient if you want. That's very much the D 
way of doing things.

Personally, I'm very leery of making an int literal implicitly convert to a 
double when there's ambiguity (e.g. if the function could also take a float), 
because then the compiler is resolving ambiguity for you rather than letting 
you do it. It risks function hijacking (at least in the sense that you don't 
necessarily end up calling the function that you mean to; it's not an issue 
for sqrt, but it could matter a lot for a function that has different behavior 
for float and double). And that sort of thing is very much _not_ the D way.

So, I'm all for integers implicitly converting to double so long as there's no 
ambiguity. But in any case where there's ambiguity or a narrowing conversion, 
a cast should be required.

- Jonathan M Davis