Re: Real implicitly converts to float?
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... :-/
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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.
Re: Real implicitly converts to float?
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.
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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.
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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.
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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.
Re: Real implicitly converts to float?
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
Re: Real implicitly converts to float?
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.
Re: Real implicitly converts to float?
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.
Real implicitly converts to float?
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.
