www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Real implicitly converts to float?

reply Tofu Ninja <joeyemmons yahoo.com> writes:
Is this intended behavior? I can't seem to find it documented 
anywhere, I would think the loss in precision would atleast be a 
warning.

real x = 10;
float y = x; // No error or warning

real to double and double to float also work.
Jun 21 2016
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 22 June 2016 at 05:04:42 UTC, Tofu Ninja wrote:

 Is this intended behavior? I can't seem to find it documented 
 anywhere, I would think the loss in precision would atleast be 
 a warning.

 real x = 10;
 float y = x; // No error or warning

 real to double and double to float also work.


Intended behaviour (in TDPL and all), and same behaviour than C.
I'm not sure of the reason.
Jun 22 2016
parent Tofu Ninja <joeyemmons yahoo.com> writes:
On Wednesday, 22 June 2016 at 08:57:38 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 22 June 2016 at 05:04:42 UTC, Tofu Ninja wrote:

 Is this intended behavior? I can't seem to find it documented 
 anywhere, I would think the loss in precision would atleast be 
 a warning.

 real x = 10;
 float y = x; // No error or warning

 real to double and double to float also work.


 Intended behaviour (in TDPL and all), and same behaviour than C.
 I'm not sure of the reason.


That's a little disconcerting, would be nice if there was a 
compiler flag to give a warning on the precision loss.
Jun 22 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, June 22, 2016 05:04:42 Tofu Ninja via Digitalmars-d-learn wrote:

 Is this intended behavior? I can't seem to find it documented
 anywhere, I would think the loss in precision would atleast be a
 warning.

 real x = 10;
 float y = x; // No error or warning

 real to double and double to float also work.


Well, that particular value should probably work thanks to VRP (value range
propagation), since 10 can fit into float with no loss of precision.
However, what's far more disconcerting is that

real x = real.max;
float y = x;

compiles. real to float is a narrowing conversion, which should be an error
barring the compiler detecting that the value will fit in the target type
even if it's a narrowing conversion (which only happens with VRP). That's
not the sort of thing that I would have expected to be broken such that it
begs the question as to whether it's intentional, but given that narrowing
conversions without a cast are illegal everywhere else, this definitely
seems broken.

- Jonathan M Davis
Jun 22 2016
parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Wednesday, 22 June 2016 at 14:17:42 UTC, Jonathan M Davis 
wrote:

 Well, that particular value should probably work thanks to VRP 
 (value range propagation), since 10 can fit into float with no 
 loss of precision. However, what's far more disconcerting is 
 that

 real x = real.max;
 float y = x;

 compiles. real to float is a narrowing conversion, which should 
 be an error barring the compiler detecting that the value will 
 fit in the target type even if it's a narrowing conversion 
 (which only happens with VRP). That's not the sort of thing 
 that I would have expected to be broken such that it begs the 
 question as to whether it's intentional, but given that 
 narrowing conversions without a cast are illegal everywhere 
 else, this definitely seems broken.

 - Jonathan M Davis


Should I make a bug report? I am not sure it's a bug, seems 
intentional. Maybe a dip for a compiler flag to warn on implicit 
down conversions, but it would be a pretty small dip.
Jun 22 2016
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn wrote:

 On Wednesday, 22 June 2016 at 14:17:42 UTC, Jonathan M Davis

 wrote:

 Well, that particular value should probably work thanks to VRP
 (value range propagation), since 10 can fit into float with no
 loss of precision. However, what's far more disconcerting is
 that

 real x = real.max;
 float y = x;

 compiles. real to float is a narrowing conversion, which should
 be an error barring the compiler detecting that the value will
 fit in the target type even if it's a narrowing conversion
 (which only happens with VRP). That's not the sort of thing
 that I would have expected to be broken such that it begs the
 question as to whether it's intentional, but given that
 narrowing conversions without a cast are illegal everywhere
 else, this definitely seems broken.

 - Jonathan M Davis


 Should I make a bug report? I am not sure it's a bug, seems
 intentional. Maybe a dip for a compiler flag to warn on implicit
 down conversions, but it would be a pretty small dip.


You're original code is almost certainly not a bug thanks to VRP, but I
would think that the example with real.max would be. So, it makes sense to
me to report it. Worst case, it gets closed as invalid. I certainly wouldn't
suggest a DIP for it at this point. If the bug were closed as invalid, then
then a DIP might make sense (though if it were intentional, then I question
that we could get Walter to change it), but I'd treat it as a bug first.

- Jonathan M Davis
Jun 23 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/23/16 5:37 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn wrote:



 Should I make a bug report? I am not sure it's a bug, seems
 intentional. Maybe a dip for a compiler flag to warn on implicit
 down conversions, but it would be a pretty small dip.




It's not a bug. Floating point is in general an approximation, so it's 
not expected to accurately capture the value. It's not the same as a 
narrowing conversion.

For instance:

int x = 1_000_000;
byte b = cast(byte)x;
assert(b == 64);

64 is nowhere near 1 million.

However:

double x = 1_000_000_000_000_000;
float f = x;
assert(f == 999_999_986_991_104);

Now, f and x aren't equal, but they are very close. Much more accurate 
than 64 and 1 million. Whenever you work with floating point, the loss 
of precision must be expected -- a finite type cannot represent an 
infinite precision number.


 You're original code is almost certainly not a bug thanks to VRP


No, VRP only works on the current expression (statement maybe?). The 
compiler does not examine previous lines to see what the range of a 
particular variable should be.

For example, this is an error:

int x = 10;
byte b = x; // error

This isn't:

int x;
byte b = x = 10;

-Steve
Jun 23 2016
next sibling parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer 
wrote:

 Whenever you work with floating point, the loss of precision 
 must be expected -- a finite type cannot represent an infinite 
 precision number.


The loss in precision should still be a warning. If I am using 
reals then I obviously needed a certain level of precision, I 
don't want to accidentally lose that precision somewhere because 
the compiler decided it was not important enough to warn me about 
it.
Jun 23 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/23/16 11:16 AM, Tofu Ninja wrote:

 On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer wrote:

 Whenever you work with floating point, the loss of precision must be
 expected -- a finite type cannot represent an infinite precision number.


 The loss in precision should still be a warning. If I am using reals
 then I obviously needed a certain level of precision, I don't want to
 accidentally lose that precision somewhere because the compiler decided
 it was not important enough to warn me about it.


I disagree. I've used languages where converting floating point types is 
not implicit, and it's painful. Most of the time, the loss in precision 
isn't important.

-Steve
Jun 23 2016
next sibling parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer 
wrote:

 I disagree. I've used languages where converting floating point 
 types is not implicit, and it's painful. Most of the time, the 
 loss in precision isn't important.

 -Steve


Which is why a flag would be nice, for some applications the 
precision matters, for some it doesn't.
Jun 23 2016
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/23/16 11:41 AM, Tofu Ninja wrote:

 On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer wrote:

 I disagree. I've used languages where converting floating point types
 is not implicit, and it's painful. Most of the time, the loss in
 precision isn't important.


 Which is why a flag would be nice, for some applications the precision
 matters, for some it doesn't.


You can attempt to make a wrapper that prevents the conversion, probably 
the best that can be had.

-Steve
Jun 23 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer 
wrote:

 On 6/23/16 11:16 AM, Tofu Ninja wrote:

 On Thursday, 23 June 2016 at 13:57:57 UTC, Steven 
 Schveighoffer wrote:

 Whenever you work with floating point, the loss of precision 
 must be
 expected -- a finite type cannot represent an infinite 
 precision number.


 The loss in precision should still be a warning. If I am using 
 reals
 then I obviously needed a certain level of precision, I don't 
 want to
 accidentally lose that precision somewhere because the 
 compiler decided
 it was not important enough to warn me about it.


 I disagree. I've used languages where converting floating point 
 types is not implicit, and it's painful. Most of the time, the 
 loss in precision isn't important.


This is so wrong. _especially_ when you have parameter 
overloading/templates. It means that you accidentally can trash a 
computation by getting the wrong function. That is not type-safe 
in my book.

Jonathan's max-value example is a good one. The distinction 
between infinity and a large actual value is an important one.
Jun 24 2016
parent reply Tofu Ninja <joeyemmons yahoo.com> writes:
On Friday, 24 June 2016 at 08:52:48 UTC, Ola Fosheim Grøstad 
wrote:

 This is so wrong. _especially_ when you have parameter 
 overloading/templates. It means that you accidentally can trash 
 a computation by getting the wrong function. That is not 
 type-safe in my book.

 Jonathan's max-value example is a good one. The distinction 
 between infinity and a large actual value is an important one.


I am glad I was not the only one who thought that sounded a 
little crazy... I thought D was supposed to be type safe. I think 
I will make a bug report and see where that goes.
Jun 24 2016
next sibling parent Tofu Ninja <joeyemmons yahoo.com> writes:
On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote:

 I am glad I was not the only one who thought that sounded a 
 little crazy... I thought D was supposed to be type safe. I 
 think I will make a bug report and see where that goes.


https://issues.dlang.org/show_bug.cgi?id=16202
Jun 24 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 24 June 2016 at 20:10:16 UTC, Tofu Ninja wrote:

 I am glad I was not the only one who thought that sounded a 
 little crazy... I thought D was supposed to be type safe. I 
 think I will make a bug report and see where that goes.


It is one of those cases where it made sense in C because it puts 
the burden on the programmer and the C-convention is to have the 
type in the name so it is "somewhat explicit" in C. C++ compilers 
solve this by having warning-options for float->double and also 
double->float conversions.

The conversion becomes rather problematic if you use Infinity to 
mean an open-ended interval. It means that a closed interval can 
implicitly be converted into an open-ended interval... :-/
Jun 24 2016
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 06/23/2016 06:57 AM, Steven Schveighoffer wrote:

 On 6/23/16 5:37 AM, Jonathan M Davis via Digitalmars-d-learn wrote:

 On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn
 wrote:



 Should I make a bug report? I am not sure it's a bug, seems
 intentional. Maybe a dip for a compiler flag to warn on implicit
 down conversions, but it would be a pretty small dip.




 It's not a bug. Floating point is in general an approximation, so it's
 not expected to accurately capture the value. It's not the same as a
 narrowing conversion.

 For instance:

 int x = 1_000_000;
 byte b = cast(byte)x;
 assert(b == 64);

 64 is nowhere near 1 million.

 However:

 double x = 1_000_000_000_000_000;
 float f = x;
 assert(f == 999_999_986_991_104);


But there is also the representable value range. The difference between 
the maximum values are worse in the case of floating point types.

void main() {
     pragma(msg, long.max / byte.max);
     pragma(msg, real.max / float.max);
}

72624976668147841L
3.49631e+4893L

So it's more nowhere near for floating point types from that point of 
view: :)

Ali
Jun 23 2016