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.

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.

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?

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.

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?

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.

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.

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

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