On 6/28/2014 5:43 AM, Element 126 wrote:
> +1 for float32 & cie. These names are much more explicit than the current ones.

I don't see any relevance to this discussion with whether 32 bit floats are named 'float' or 'float32'.

On 6/28/2014 6:49 AM, Andrei Alexandrescu wrote:
> The only problem is/would be when the language forces one choice over the other.
> Both options of maximum performance and maximum precision should be handily
> accessible to D users.


That's a much more reasonable position than "we should abandon 80 bit reals".

I think this thread is getting out of hand. The main point was to
get float and double overloads for std.math.

This whole discussion about numeric stability, the naming of
double and float, the state of real.... all of it is a little bit
ridiculous.

Numerical stability is not really related to getting faster
overloads other than the obvious fact that it is a trade off.
Float and double do not need a name change. Real also does not
need a change.

I think this thread needs to refocus on the main point, getting
math overloads for float and double and how to mitigate any
problems that might arise from that.

On 06/29/2014 02:40 AM, Walter Bright wrote:
> On 6/28/2014 3:33 AM, Russel Winder via Digitalmars-d wrote:
>> ...
>> So D should perhaps make a breaking change and have types int32, int64,
>> float32, float64, float80, and get away from the vagaries of bizarre
>> type relationships with hardware?
>
> D's spec says that the 'real' type is the max size supported by the FP
> hardware. How is this wrong?
>

It is hardware-dependent.

On 06/29/2014 02:42 AM, Walter Bright wrote:
> On 6/28/2014 6:49 AM, Andrei Alexandrescu wrote:
>> The only problem is/would be when the language forces one choice over
>> the other.
>> Both options of maximum performance and maximum precision should be
>> handily
>> accessible to D users.
>
>
> That's a much more reasonable position than "we should abandon 80 bit
> reals".

If that is what you were arguing against, I don't think this was actually suggested.

On 6/28/2014 6:14 PM, Timon Gehr wrote:
> On 06/29/2014 02:40 AM, Walter Bright wrote:
>> On 6/28/2014 3:33 AM, Russel Winder via Digitalmars-d wrote:
>>> ...
>>> So D should perhaps make a breaking change and have types int32, int64,
>>> float32, float64, float80, and get away from the vagaries of bizarre
>>> type relationships with hardware?
>>
>> D's spec says that the 'real' type is the max size supported by the FP
>> hardware. How is this wrong?
>>
>
> It is hardware-dependent.

D does not require real to be 80 bits if the hardware does not support it.

Keep in mind that D is a systems programming language, and that implies you get access to the hardware types.

On 6/28/14, 5:33 PM, Walter Bright wrote:
> On 6/28/2014 7:01 AM, Andrei Alexandrescu wrote:
>> On 6/28/14, 3:42 AM, Walter Bright wrote:
>>> Inverting matrices is commonplace for solving N equations with N
>>> unknowns.
>>
>> Actually nobody does that.
>
> I did that at Boeing when doing analysis of the movement of the control
> linkages. The traditional way it had been done before was using paper
> and pencil with drafting tools - I showed how it could be done with
> matrix math.

Pen on paper is a low baseline. The classic way to solve linear equations with computers is to use Gaussian elimination methods adjusted to cancel imprecision. (There are a number of more specialized methods.)

For really large equations with sparse matrices one uses the method of relaxations.

>> I have an alarm go off when someone proffers a very strong conviction.
>> Very
>> strong convictions means there is no listening to any argument right
>> off the
>> bat, which locks out any reasonable discussion before it even begins.
>
> So far, everyone here has dismissed my experienced out of hand. You too,
> with "nobody does that". I don't know how anyone here can make such a
> statement. How many of us have worked in non-programming engineering
> shops, besides me?

My thesis - http://erdani.com/research/dissertation_color.pdf - and some of my work at Facebook, which has been patented - http://www.faqs.org/patents/app/20140046959 - use large matrix algebra intensively.

>> For better or worse modern computing units have focused on 32- and
>> 64-bit float,
>> leaving 80-bit floats neglected.
>
> Yep, for the game/graphics industry. Modern computing has also produced
> crappy trig functions with popular C compilers, because nobody using C
> cares about accurate answers (or they just assume what they're getting
> is correct - even worse).
>
>
>> I think it's time to accept that simple fact
>> and act on it, instead of claiming we're the best in the world at FP
>> math while
>> everybody else speeds by.
>
> Leaving us with a market opportunity for precision FP.
>
> I note that even the title of this thread says nothing about accuracy,
> nor did the benchmark attempt to assess if there was a difference in
> results.

All I'm saying is that our convictions should be informed by, and commensurate with, our expertise.


Andrei

On 6/28/14, 5:42 PM, Walter Bright wrote:
> On 6/28/2014 6:49 AM, Andrei Alexandrescu wrote:
>> The only problem is/would be when the language forces one choice over
>> the other.
>> Both options of maximum performance and maximum precision should be
>> handily
>> accessible to D users.
>
>
> That's a much more reasonable position than "we should abandon 80 bit
> reals".

Awesome! -- Andrei

On 6/28/14, 6:02 PM, Tofu Ninja wrote:
> I think this thread is getting out of hand. The main point was to
> get float and double overloads for std.math.
>
> This whole discussion about numeric stability, the naming of
> double and float, the state of real.... all of it is a little bit
> ridiculous.
>
> Numerical stability is not really related to getting faster
> overloads other than the obvious fact that it is a trade off.
> Float and double do not need a name change. Real also does not
> need a change.
>
> I think this thread needs to refocus on the main point, getting
> math overloads for float and double and how to mitigate any
> problems that might arise from that.

Yes please. -- Andrei

On Sat, Jun 28, 2014 at 05:16:53PM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/28/2014 3:57 AM, Russel Winder via Digitalmars-d wrote:
[...]
> >Or indeed when calculating anything to do with money.
> 
> You're better off using 64 bit longs counting cents to represent money than using floating point. But yeah, counting money has its own special problems.

For counting money, I heard that the recommendation is to use fixed-point arithmetic (i.e. integer values in cents).


T

-- 
The best compiler is between your ears. -- Michael Abrash