On 29 June 2014 10:11, deadalnix via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
> On Saturday, 28 June 2014 at 09:07:17 UTC, John Colvin wrote:
>>
>> On Saturday, 28 June 2014 at 06:16:51 UTC, Walter Bright wrote:
>>>
>>> On 6/27/2014 10:18 PM, Walter Bright wrote:
>>>>
>>>> On 6/27/2014 4:10 AM, John Colvin wrote:
>>>>>
>>>>> *The number of algorithms that are both numerically stable/correct and
>>>>> benefit
>>>>> significantly from > 64bit doubles is very small.
>>>>
>>>>
>>>> To be blunt, baloney. I ran into these problems ALL THE TIME when doing
>>>> professional numerical work.
>>>>
>>>
>>> Sorry for being so abrupt. FP is important to me - it's not just about
>>> performance, it's also about accuracy.
>>
>>
>> I still maintain that the need for the precision of 80bit reals is a niche
>> demand. Its a very important niche, but it doesn't justify having its
>> relatively extreme requirements be the default. Someone writing a matrix
>> inversion has only themselves to blame if they don't know plenty of
>> numerical analysis and look very carefully at the specifications of all
>> operations they are using.
>>
>> Paying the cost of moving to/from the fpu, missing out on increasingly
>> large SIMD units, these make everyone pay the price.
>>
>> inclusion of the 'real' type in D was a great idea, but std.math should be
>> overloaded for float/double/real so people have the choice where they stand
>> on the performance/precision front.
>
>
> Would thar make sense to have std.mast and std.fastmath, or something along
> these lines ?

I've thought this too.
std.math and std.numeric maybe?

To me, 'fastmath' suggests comfort with approximations/estimates or
other techniques in favour of speed, and I don't think the non-'real'
version should presume that.
It's not that we have a 'normal' one and a 'fast' one. What we have is
a 'slow' one, and the other is merely normal; ie, "std.math".

Reply via email to