On 6/30/2014 11:10 AM, Sean Kelly wrote:
> If your liquid assets are represented in dollars, yes.  But this
> is really just a display issue.  The amounts could easily be
> stored in a floating point representation and rounded when
> reporting is done.

But if you round only for display purposes (and for sending statements to a customer), the customer can easily wind up with accounts that don't balance to the penny.

On 6/30/2014 11:06 AM, Tofu Ninja wrote:
> Oh, ok that make sense. I have never heard that called any form of painting
> before. I never realized that had a name at all really, just thought it was a
> thing you did with unions. Thank for the clarification.

The notion is to "paint" a type onto data.

And my opinion is that real should be deprecated and removed in the future.
Double is enough.
If your application depends on float-point accuracy you have problems.

On Monday, 30 June 2014 at 17:01:07 UTC, Walter Bright wrote:
> 2. My business accounts have no notion of fractional cents, so there's no reason to confuse the bookkeeping with them.
.00001 BTC

On Monday, 30 June 2014 at 19:15:44 UTC, Walter Bright wrote:
> On 6/30/2014 11:10 AM, Sean Kelly wrote:
>> If your liquid assets are represented in dollars, yes.  But this
>> is really just a display issue.  The amounts could easily be
>> stored in a floating point representation and rounded when
>> reporting is done.
>
> But if you round only for display purposes (and for sending statements to a customer), the customer can easily wind up with accounts that don't balance to the penny.

And in those cases, rounding occurs at the proper points to
ensure that things match whatever on-paper accounting you might
have done.  "Reporting" in this instance may actually mean
writing data to a ledger somewhere.  My point was that
effectively all of the math that's done in these systems is
floating-point.  The fixed-point conversions occur at
serialization points.

On Monday, 30 June 2014 at 19:42:34 UTC, Temtaime wrote:
> And my opinion is that real should be deprecated and removed in the future.
> Double is enough.
> If your application depends on float-point accuracy you have problems.

I think that real should be deprecated and removed in favor of a library quadruple (binary128) and/or library "real" type. Plus I think having some form of decimal64 and decimal128 types (despite being non-native and slower) would be highly appreciated as well. I'm siding with Walter that precision is important and we should make it easy to get more precision at the cost of speed (of course, fast float/double ops should be fully supported as well). Obviously better algorithms that require less precision is the ideal approach, but we shouldn't assume that users will want to spend time on better algorithms. Offering easy-to-accomplish accuracy is a good feature as long as the difficult-to-accomplish better accuracy with higher performance is also possible.

I think having even more precise types you can count on for different situations is better. I dunno if that will actually change, but maybe we could implement the library versions and see if Walter ends up liking that approach better.

On 6/30/2014 12:42 PM, Temtaime wrote:
> And my opinion is that real should be deprecated and removed in the future.
> Double is enough.

D would no longer be compatible with C if that were done.

On Monday, 30 June 2014 at 16:54:55 UTC, Walter Bright wrote:
> On 6/30/2014 4:25 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>
>> AFAIK they break compliance all the time.
>
> Examples, please.

Cell:

http://publib.boulder.ibm.com/infocenter/cellcomp/v101v121/index.jsp?topic=/com.ibm.xlcpp101.cell.doc/proguide/spu_sp_diffs.html

Intel:

http://www.velocityreviews.com/threads/intel-fp-h-w-non-compliance-to-ieee754.746517/

ARM Neon vs VPF…

etc.

On 6/30/14, 2:20 AM, Don wrote:
> For me, a stronger argument is that you can get *higher* precision using
> doubles, in many cases. The reason is that FMA gives you an intermediate
> value with 128 bits of precision; it's available in SIMD but not on x87.
>
> So, if we want to use the highest precision supported by the hardware,
> that does *not* mean we should always use 80 bits.
>
> I've experienced this in CTFE, where the calculations are currently done
> in 80 bits, I've seen cases where the 64-bit runtime results were more
> accurate, because of those 128 bit FMA temporaries. 80 bits are not
> enough!!

Interesting. Maybe we should follow a simple principle - define overloads and intrinsic operations such that real is only used if (a) requested explicitly (b) it brings about an actual advantage.

I.e. most of the time not using real in user code means it's never real throughout.


Andrei

On Mon, Jun 30, 2014 at 05:18:43PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/30/14, 2:20 AM, Don wrote:
> >For me, a stronger argument is that you can get *higher* precision using doubles, in many cases. The reason is that FMA gives you an intermediate value with 128 bits of precision; it's available in SIMD but not on x87.
> >
> >So, if we want to use the highest precision supported by the hardware, that does *not* mean we should always use 80 bits.
> >
> >I've experienced this in CTFE, where the calculations are currently done in 80 bits, I've seen cases where the 64-bit runtime results were more accurate, because of those 128 bit FMA temporaries. 80 bits are not enough!!
> 
> Interesting. Maybe we should follow a simple principle - define
> overloads and intrinsic operations such that real is only used if (a)
> requested explicitly (b) it brings about an actual advantage.
> 
> I.e. most of the time not using real in user code means it's never real throughout.
[...]

Iain's PR to provide overloads of std.math functions for float/double has already been merged, so all that remains is for float literals to default to double unless suffixed with L, or contain too many digits to accurately represent in double.


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.