so:

> I have an unrelated question, this is not a criticism but an honest one. Why don't you write these 3 lines like:
> 
> >     auto r = to!real  ("0x1.0076fc5cc7933866p+40L");
> >     auto d = to!double("0x1.0076fc5cc7933866p+40L");
> >     auto f = to!float ("0x1.0076fc5cc7933866p+40L");

I have a certain stylistic rule regarding how function calls are written in my code, and that rule is more important than such alignment. Adding spaces where I don't expect them to be slows down my visual parsing of the code. Generally in my code I've found that such kind of alignment is a waste of my time, if I change something I may need to waste time realigning things.

Bye,
bearophile

On Monday, November 29, 2010 12:36:00 bearophile wrote:
> so:
> > I have an unrelated question, this is not a criticism but an honest one.
> > 
> > Why don't you write these 3 lines like:
> > >     auto r = to!real  ("0x1.0076fc5cc7933866p+40L");
> > >     auto d = to!double("0x1.0076fc5cc7933866p+40L");
> > >     auto f = to!float ("0x1.0076fc5cc7933866p+40L");
> 
> I have a certain stylistic rule regarding how function calls are written in my code, and that rule is more important than such alignment. Adding spaces where I don't expect them to be slows down my visual parsing of the code. Generally in my code I've found that such kind of alignment is a waste of my time, if I change something I may need to waste time realigning things.

LOL. I couldn't figure out what was different about those lines (the extra space apparently; the fact that the text isn't monospaced makes it harder to see though). But no one's over going to get people to agree on spacing any more than they'll get them to agree on braces. Personally, I generally don't have extraneous spaces but will periodically line up variable declarations with regards to names (which would require no work here because they're all auto and line up anyway). Other folks I know insist on always putting extra spaces after keywords like if and/or putting extra spaces before or after parens. Trying to convince anyone about spacing is a waste of time, and I'd say that suggesting that spacing be altered in code is generally a waste of time unless there's something abnormally bad about it (like 10 spaces after every paren or something ridiculous like that).

- Jonathan M Davis

Walter Bright Wrote:

> > Really? I think, the answer is neither correct nor wrong. It's approximate.
> 
> The rules for rounding the mathematical value to the representation are precise, and so there is such a thing as the correctly rounded result and the wrong result.

Well, maybe, but the result fits well in machine precision (which is equal to the last bit). And if this precision is not enough for the algorithm, then the algorithm is incorrect on any x87 FPU, and its output is garbage.

Kagamin wrote:
> Walter Bright Wrote:
> 
>>> Really? I think, the answer is neither correct nor wrong. It's
>>> approximate.
>> The rules for rounding the mathematical value to the representation are
>> precise, and so there is such a thing as the correctly rounded result and
>> the wrong result.
> 
> Well, maybe, but the result fits well in machine precision (which is equal to
> the last bit). And if this precision is not enough for the algorithm, then
> the algorithm is incorrect on any x87 FPU, and its output is garbage.

How do you decide how many bits should be enough for any algorithm?

The thing is, the FPU has 53 bits of precision and so ought to be correct to the last bit.

> LOL. I couldn't figure out what was different about those lines (the extra space
> apparently; the fact that the text isn't monospaced makes it harder to see
> though). But no one's over going to get people to agree on spacing any more than
> they'll get them to agree on braces. Personally, I generally don't have
> extraneous spaces but will periodically line up variable declarations with
> regards to names (which would require no work here because they're all auto and
> line up anyway). Other folks I know insist on always putting extra spaces after
> keywords like if and/or putting extra spaces before or after parens. Trying to
> convince anyone about spacing is a waste of time, and I'd say that suggesting
> that spacing be altered in code is generally a waste of time unless there's
> something abnormally bad about it (like 10 spaces after every paren or something
> ridiculous like that).
>
> - Jonathan M Davis

IMHO this is a good example why inconsistencies are sometimes necessary.
I don't put spaces into random places either but this example is crying for attention :)

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Monday 29 November 2010 21:30:31 so@so.do wrote:
> > LOL. I couldn't figure out what was different about those lines (the
> > extra space
> > apparently; the fact that the text isn't monospaced makes it harder to
> > see
> > though). But no one's over going to get people to agree on spacing any
> > more than
> > they'll get them to agree on braces. Personally, I generally don't have
> > extraneous spaces but will periodically line up variable declarations
> > with
> > regards to names (which would require no work here because they're all
> > auto and
> > line up anyway). Other folks I know insist on always putting extra
> > spaces after
> > keywords like if and/or putting extra spaces before or after parens.
> > Trying to
> > convince anyone about spacing is a waste of time, and I'd say that
> > suggesting
> > that spacing be altered in code is generally a waste of time unless
> > there's
> > something abnormally bad about it (like 10 spaces after every paren or
> > something
> > ridiculous like that).
> > 
> > - Jonathan M Davis
> 
> IMHO this is a good example why inconsistencies are sometimes necessary. I don't put spaces into random places either but this example is crying for attention :)

If you say so. I don't see any problem with it. I can see why you'd want to add the extra spaces (at least, once I put it in an editor with a monospaced font), but I wouldn't have thought that it would be worth calling someone on it. It just seems nitpicky, honestly.

- Jonathan M Davis

> but I wouldn't have thought that it would be worth calling someone on it. It
> just seems nitpicky, honestly.
>
> - Jonathan M Davis

I am sorry if it seems that way, wasn't my intention.

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Walter Bright Wrote:

> How do you decide how many bits should be enough for any algorithm?
> 
> The thing is, the FPU has 53 bits of precision and so ought to be correct to the last bit.

It's not me, it's the programmer. He was disgusted that his algorithm produced garbage, which means, the error was unacceptable. Mat be it was 1%, may be 80%, I don't, that was his decision, that the result was unacceptable. The bug description assumes the problem was in the last bit, which means, he wanted precision higher than the machine precision.

On Tue, Nov 30, 2010 at 1:43 PM, Kagamin <spam@here.lot> wrote:

> Walter Bright Wrote:
>
> > How do you decide how many bits should be enough for any algorithm?
> >
> > The thing is, the FPU has 53 bits of precision and so ought to be correct
> to the
> > last bit.
>
> It's not me, it's the programmer. He was disgusted that his algorithm produced garbage, which means, the error was unacceptable. Mat be it was 1%, may be 80%, I don't, that was his decision, that the result was unacceptable. The bug description assumes the problem was in the last bit, which means, he wanted precision higher than the machine precision.
>

What programmer? What algorithm? As far as I can tell, this was found when testing a library explicitly for accuracy, not in an application, so your argument doesn't apply.

Kagamin wrote:

> It's not me, it's the programmer. He was disgusted that his
> algorithm produced garbage, which means, the error was
> unacceptable. Mat be it was 1%, may be 80%, I don't, that was
> his decision, that the result was unacceptable. The bug
> description assumes the problem was in the last bit, which
> means, he wanted precision higher than the machine precision.

This thread is about a bug in a CPU's floating point implementation. Regardless of which bit of the floating point representation is affected, it's a bug.

Ali