• ixid (3/3) Jun 30 2017 Are there any reasons not to put real on the path to removal? The
• Nicholas Wilson (4/7) Jun 30 2017 Don't forget that real is only fp80 on x86. On AArch64(?) it
• ixid (3/10) Jun 30 2017 Isn't it an objective of D to move away from such confusing types
• Stefan Koch (5/16) Jun 30 2017 D does have well defined floating point types.
• ixid (3/20) Jun 30 2017 In that case should it not be defined to be something other than
• Patrick Schluter (6/29) Jun 30 2017 The real type is defined as the highest precision a platform
• Steven Schveighoffer (5/24) Jun 30 2017 Not agreeing with the OP, but annoyingly you are forced to deal with it
• jmh530 (9/12) Jun 30 2017 I've never found real confusing.
• Walter Bright (2/10) Jun 30 2017 https://github.com/dlang/druntime/pull/1621

ixid <adamsibson gmail.com> writes:

Are there any reasons not to put real on the path to removal? The 
hardware is deprecated by both Intel and AMD and it seems like an 
unnecessary source of confusion.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to removal? 
 The hardware is deprecated by both Intel and AMD and it seems 
 like an unnecessary source of confusion.

Don't forget that real is only fp80 on x86. On AArch64(?) it 
is/should be fp128 which _is_ supported, there is also PowerPC 
double double.

ixid <adamsibson gmail.com> writes:

On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:
 On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to removal? 
 The hardware is deprecated by both Intel and AMD and it seems 
 like an unnecessary source of confusion.

 Don't forget that real is only fp80 on x86. On AArch64(?) it 
 is/should be fp128 which _is_ supported, there is also PowerPC 
 double double.

Isn't it an objective of D to move away from such confusing types 
and have defined widths?

Stefan Koch <uplink.coder googlemail.com> writes:

On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:
 On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:
 On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to removal? 
 The hardware is deprecated by both Intel and AMD and it seems 
 like an unnecessary source of confusion.

 Don't forget that real is only fp80 on x86. On AArch64(?) it 
 is/should be fp128 which _is_ supported, there is also PowerPC 
 double double.

 Isn't it an objective of D to move away from such confusing 
 types and have defined widths?

D does have well defined floating point types.
float and double.

real is a special type for people who know what they are dong.
And not to be removed.

ixid <adamsibson gmail.com> writes:

On Friday, 30 June 2017 at 10:49:19 UTC, Stefan Koch wrote:
 On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:
 On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:
 On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to 
 removal? The hardware is deprecated by both Intel and AMD 
 and it seems like an unnecessary source of confusion.

 Don't forget that real is only fp80 on x86. On AArch64(?) it 
 is/should be fp128 which _is_ supported, there is also 
 PowerPC double double.

 Isn't it an objective of D to move away from such confusing 
 types and have defined widths?

 D does have well defined floating point types.
 float and double.

 real is a special type for people who know what they are dong.
 And not to be removed.

In that case should it not be defined to be something other than 
80 bit doubles on x86?

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Friday, 30 June 2017 at 10:58:50 UTC, ixid wrote:
 On Friday, 30 June 2017 at 10:49:19 UTC, Stefan Koch wrote:
 On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:
 On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson 
 wrote:
 On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to 
 removal? The hardware is deprecated by both Intel and AMD 
 and it seems like an unnecessary source of confusion.

 Don't forget that real is only fp80 on x86. On AArch64(?) it 
 is/should be fp128 which _is_ supported, there is also 
 PowerPC double double.

 Isn't it an objective of D to move away from such confusing 
 types and have defined widths?

 D does have well defined floating point types.
 float and double.

 real is a special type for people who know what they are dong.
 And not to be removed.

 In that case should it not be defined to be something other 
 than 80 bit doubles on x86?

The real type is defined as the highest precision a platform 
gives.
This is the legacy x87 format on x86 platform. If ever AMD or 
Intel introduced a 128bit SSEx format, real would be changed to 
use this hypothetical new format.

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 6/30/17 6:49 AM, Stefan Koch wrote:
 On Friday, 30 June 2017 at 10:44:41 UTC, ixid wrote:
 On Friday, 30 June 2017 at 10:26:03 UTC, Nicholas Wilson wrote:
 On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to removal? The 
 hardware is deprecated by both Intel and AMD and it seems like an 
 unnecessary source of confusion.

 Don't forget that real is only fp80 on x86. On AArch64(?) it 
 is/should be fp128 which _is_ supported, there is also PowerPC double 
 double.

 Isn't it an objective of D to move away from such confusing types and 
 have defined widths?

 
 D does have well defined floating point types.
 float and double.
 
 real is a special type for people who know what they are dong.
 And not to be removed.

Not agreeing with the OP, but annoyingly you are forced to deal with it 
even if you don't know, as all FP operations are promoted to real, even 
double + double. It's a constant source of confusion.

-Steve

jmh530 <john.michael.hall gmail.com> writes:

On Friday, 30 June 2017 at 10:07:44 UTC, ixid wrote:
 Are there any reasons not to put real on the path to removal? 
 The hardware is deprecated by both Intel and AMD and it seems 
 like an unnecessary source of confusion.

I've never found real confusing.

However, I do see some people confused by the fact that floating 
point operations may do intermediate steps at higher precision. 
Walter has provided the reasoning before and I think I agree with 
it. However, I think a case could be made for having an option to 
disable it and force intermediate calculations to be done at the 
precision of the type. I would consider it to be something of low 
importance, but other people might value it more.

Walter Bright <newshound2 digitalmars.com> writes:

On 6/30/2017 5:20 AM, jmh530 wrote:
 I've never found real confusing.
 
 However, I do see some people confused by the fact that floating point 
 operations may do intermediate steps at higher precision. Walter has provided 
 the reasoning before and I think I agree with it. However, I think a case
could 
 be made for having an option to disable it and force intermediate calculations 
 to be done at the precision of the type. I would consider it to be something
of 
 low importance, but other people might value it more.

https://github.com/dlang/druntime/pull/1621