www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecate real

reply 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.
Jun 30
next sibling parent reply 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.
Jun 30
parent reply 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?
Jun 30
parent reply 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.
Jun 30
next sibling parent reply 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?
Jun 30
parent 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.
Jun 30
prev sibling parent 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
Jun 30
prev sibling parent reply 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.
Jun 30
parent 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
Jun 30