On Monday, 30 June 2014 at 16:29:06 UTC, Element 126 wrote:
> On 06/29/2014 11:04 PM, John Colvin wrote:
>> [...]
>>
>> mixin(`alias real` ~ (real.sizeof*8).stringof ~ ` = real;`);
>>
>> is more useful to me.
>
> Be careful : this code is tricky ! real.sizeof is the storage size, ie 16 bytes on x86_64.
>
> The following happily compiles ;-)
>
> import std.conv: to;
>
> mixin(`alias real` ~ to!string(real.sizeof*8) ~ ` = real;`);
>
> static assert(real128.mant_dig == 64);
>
> void main() {
>
> 	real128 x = 1.0;
> }

I knew there'd be something tricky in there. Thanks for spotting it.

Am 30.06.2014 18:30, schrieb dennis luehring:
> Am 30.06.2014 08:21, schrieb Walter Bright:
>>> The only way I know to access x87 is with inline asm.
>>
>> I suggest using "long double" on Linux and look at the compiler output. You
>> don't have to believe me - use gcc or clang.
>
> gcc.godbolt.org clang 3.4.1 -O3

better this

int main(int argc, char** argv)
{
  return argc * 12345.6789L;
}

.LCPI0_0:
        # x86_fp80 12345.6788999999999996
	.quad	-4546745350290602879

	.short	16396
	.zero	6
main:                                   # @main
	movl	%edi, -8(%rsp)
	fldt	.LCPI0_0(%rip)
	fimull	-8(%rsp)
	fnstcw	-10(%rsp)
	movw	-10(%rsp), %ax
	movw	$3199, -10(%rsp)        # imm = 0xC7F
	fldcw	-10(%rsp)
	movw	%ax, -10(%rsp)
	fistpl	-4(%rsp)
	fldcw	-10(%rsp)
	movl	-4(%rsp), %eax
	ret

On 6/30/2014 12:35 AM, ed wrote:
> On Monday, 30 June 2014 at 06:21:49 UTC, Walter Bright wrote:
>
> When precision is an issue we always choose a software solution. This has been
> my experience in both geophysics and medical device development. It is cheaper,
> faster (dev. time), and better tested than anything we would develop within a
> release time frame.
>
> But D "real" is a winner IMO. At my last workplace we ported some geophysics C++
> apps to D for fun. The apps required more precision than double could offer and
> relied on GMP/MPFR. It was a nice surprise when we found the extra bits in D's
> real were enough for some of these apps to be correct without GMP/MPFR and gave
> a real performance boost (pun intended!).
>
> We targeted x86/x86_64 desktops and clusters running linux (windows and MAC on
> desktops as well).

Good to know!


> We did not consider the lack of IBM 360 support to be an issue when porting to D
> :-P

The 360 is almost as auld as I am!

On 6/30/2014 12:20 AM, Don wrote:
> What I think is highly likely is that it will only have legacy support, with
> such awful performance that it never makes sense to use them. For example, the
> speed of 80-bit and 64-bit calculations in x87 used to be identical. But on
> recent Intel CPUs, the 80-bit operations run at half the speed of the 64 bit
> operations. They are already partially microcoded.
>
> 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!!

I did not know this. It certainly adds another layer of nuance - as the higher level of precision will only apply as long as one can keep the value in a register.

On 6/30/2014 4:25 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 29 June 2014 at 22:49:44 UTC, Walter Bright wrote:
>>> I guess we just hope that all future hardware is IEEE754 compliant.
>>
>> I'm not concerned about it. No CPU maker in their right head would do
>> something different.
>
> AFAIK they break compliance all the time.

Examples, please.

On 6/30/2014 4:57 AM, Don wrote:
> Many people seem to have the bizarre idea that floating point is less accurate
> than integer arithmetic. As if storing a value into a double makes it instantly
> "fuzzy", or something.
> In fact, providing that the the precision is large enough, every operation that
> is exact in integers, is exact in floating point as well.
> And if you perform a division using integers, you've silently lost precision.
> So I'm not sure what benefit you'd gain by eschewing floating point.

1. 64 bit longs have more precision than 64 bit doubles.

2. My business accounts have no notion of fractional cents, so there's no reason to confuse the bookkeeping with them.

I understand that for purposes of calculating interest, you'd definitely want the intermediate answers to be in floating point. But when posting to an account, you want cents.

And these days, dealing with trillions of dollars, one is getting awfully close to the max precision of doubles :-)

On Monday, 30 June 2014 at 16:29:08 UTC, H. S. Teoh via Digitalmars-d wrote:
> What's the status of repainting unions in CTFE? Is there a PR for that
> yet, or do we need to implement one?
>
>
> T

What exactly does "repainting a union" mean? I am not familiar with that phrase, google has not helped me either.

On Mon, Jun 30, 2014 at 05:35:34PM +0000, Tofu Ninja via Digitalmars-d wrote:
> On Monday, 30 June 2014 at 16:29:08 UTC, H. S. Teoh via Digitalmars-d wrote:
> >What's the status of repainting unions in CTFE? Is there a PR for that yet, or do we need to implement one?
> >
> >
> >T
> 
> What exactly does "repainting a union" mean? I am not familiar with that phrase, google has not helped me either.

I may have misused the term, perhaps the proper term is "painting"?

Anyway, it means to write data of one type to the union, and read out a different type. E.g., write a double into a union of double and ubyte[double.sizeof], and then read out the latter, in order to get at the bit representation of the double without using pointer casting:

	ubyte[double.sizeof] getRepresentation(double d) {
		union U {
			double d;
			ubyte[double.sizeof] rep;
		}
		U u;
		u.d = d;
		return u.rep;
	}

(This is a silly example, of course, since in assembly it amounts to a function that just returns its argument. Usually you do something non-trivial with u.rep, such as extract the sign bit or mantissa, and so forth.)

Right now, this doesn't work in CTFE (it implicitly type-tags all unions, and raises an error when you try to read out a different type than you wrote in). But this kind of type-punning is needed to implement some of the fundamental floating-point operations.


T

-- 
Question authority. Don't ask why, just do it.

On Monday, 30 June 2014 at 17:49:52 UTC, H. S. Teoh via Digitalmars-d wrote:
> I may have misused the term, perhaps the proper term is "painting"?
>
> Anyway, it means to write data of one type to the union, and read out a
> different type. E.g., write a double into a union of double and
> ubyte[double.sizeof], and then read out the latter, in order to get at
> the bit representation of the double without using pointer casting

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.

On Monday, 30 June 2014 at 17:01:07 UTC, Walter Bright wrote:
>
> 1. 64 bit longs have more precision than 64 bit doubles.
>
> 2. My business accounts have no notion of fractional cents, so there's no reason to confuse the bookkeeping with them.
>
> I understand that for purposes of calculating interest, you'd definitely want the intermediate answers to be in floating point. But when posting to an account, you want cents.

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.  This is how all financial systems I've ever
worked on have operated (hedge fund accounting systems, trading
systems, and enterprise-level accounting systems used by
companies like Goldman Sachs), though every once in a while you
might encounter one that uses the SQL "money" type for certain
types of accounting.

> And these days, dealing with trillions of dollars, one is getting awfully close to the max precision of doubles :-)

To be fair, most accounts don't contain trillions of dollars, or
report on aggregate sums of that magnitude.  That's still well
within the realm of special purpose software.  And for that I'd
likely be using quads and just live with the performance hit.