digitalmars.D.learn - writeln double precision
- Arun Chandrasekaran (10/10) Oct 23 2017 I've written a simple tool [1] to find the DET and CMC
- Arun Chandrasekaran (13/23) Oct 23 2017 ```
- =?UTF-8?Q?Ali_=c3=87ehreli?= (19/28) Oct 23 2017 Yes, it can but we don't want that. Otherwise, the code would be too
- Arun Chandrasekaran (5/8) Oct 24 2017 Thanks Ali. Is this for backward compatibility with C? Because,
- H. S. Teoh (9/17) Oct 24 2017 [...]
- jmh530 (2/8) Oct 24 2017 Haven't used Python 3+?
- H. S. Teoh (5/17) Oct 24 2017 Haha, I guess I'm behind the times!
- Arun Chandrasekaran (7/24) Oct 24 2017 I'm not denying that all the programming languages does it this
- =?UTF-8?Q?Ali_=c3=87ehreli?= (25/30) Oct 24 2017 I'm not a language designer so I can't be sure but I think it has the
- Jonathan M Davis (22/51) Oct 25 2017 Part of it is compatibility. In general, valid C code should either be v...
I've written a simple tool [1] to find the DET and CMC specifically for biometrics performance measurement. When I generate the report, I expected to see high precision floating point numbers, but I see that writefln trims the precision to the last 6 digits after decimal point. Am I doing the right thing here? Should I use a different format specifier? [1] https://bitbucket.org/carun/biometrics-reports/src Cheers, Arun
Oct 23 2017
On Monday, 23 October 2017 at 14:07:06 UTC, Arun Chandrasekaran wrote:I've written a simple tool [1] to find the DET and CMC specifically for biometrics performance measurement. When I generate the report, I expected to see high precision floating point numbers, but I see that writefln trims the precision to the last 6 digits after decimal point. Am I doing the right thing here? Should I use a different format specifier? [1] https://bitbucket.org/carun/biometrics-reports/src Cheers, Arun``` void main() { double a = 22/7.0; import std.stdio: writeln, writefln; writefln("%.51f", a); } ``` and it prints all the decimals. So I'm happy that I have not lost the precision. But why does the compiler bring the C baggage for the integer division? Why do I need to `cast (double)` ? Can't the compiler figure it out?
Oct 23 2017
On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:void main() { double a = 22/7.0; import std.stdio: writeln, writefln; writefln("%.51f", a); }But why does the compiler bring the C baggage for the integer division? Why do I need to `cast (double)` ?I think you mean having to write 7.0 to bring a double into the expression.Can't the compiler figure it out?Yes, it can but we don't want that. Otherwise, the code would be too slippery to keep under control. For example, introducing the following temporary variable would change the semantics: // Before: foo(22/7); // After double temp = 22/7; foo(temp); // Is this the same call with the same value? Writing the above made me aware that function overloading would be too cumbersome as the compiler would find too many potential matches for the expressions. For example, should it convert 22/7 to float or double or long, etc. The rule is that every expression has a type and 22/7 is int. The rules are carried from C and can be tricky. Both "Integer Promotions" and "Usual Arithmetic Conversion" are interesting here: https://dlang.org/spec/type.html#integer-promotions Ali
Oct 23 2017
On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:Thanks Ali. Is this for backward compatibility with C? Because, if there is a division, a natural/mathematical (not programmatic) expectation is to see a a double in the result. Arun[...]The rule is that every expression has a type and 22/7 is int.
Oct 24 2017
On Tue, Oct 24, 2017 at 10:02:11AM +0000, Arun Chandrasekaran via Digitalmars-d-learn wrote:On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:[...] I have never seen a programming language in which dividing two integers yields a float or double. Either numbers default to a floating point type, in which case you begin with floats in the first place, or division is integer division, yielding an integer result. T -- Real Programmers use "cat > a.out".On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:Thanks Ali. Is this for backward compatibility with C? Because, if there is a division, a natural/mathematical (not programmatic) expectation is to see a a double in the result.[...]The rule is that every expression has a type and 22/7 is int.
Oct 24 2017
On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:I have never seen a programming language in which dividing two integers yields a float or double. Either numbers default to a floating point type, in which case you begin with floats in the first place, or division is integer division, yielding an integer result. THaven't used Python 3+?
Oct 24 2017
"H. S. Teoh" <hsteoh quickfur.ath.cx> On Tue, Oct 24, 2017 at 04:59:04PM +0000, jmh530 via Digitalmars-d-learn wrote:On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:Haha, I guess I'm behind the times! T -- Gone Chopin. Bach in a minuet.I have never seen a programming language in which dividing two integers yields a float or double. Either numbers default to a floating point type, in which case you begin with floats in the first place, or division is integer division, yielding an integer result. THaven't used Python 3+?
Oct 24 2017
On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:On Tue, Oct 24, 2017 at 10:02:11AM +0000, Arun Chandrasekaran via Digitalmars-d-learn wrote:I'm not denying that all the programming languages does it this way (even if it is a cause of related bugs). I'm just questioning the reasoning behind why D does it this way and if it is for compatibility or if there is any other reasoning behind the decision. ArunOn Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:[...] I have never seen a programming language in which dividing two integers yields a float or double. Either numbers default to a floating point type, in which case you begin with floats in the first place, or division is integer division, yielding an integer result. TOn 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:Thanks Ali. Is this for backward compatibility with C? Because, if there is a division, a natural/mathematical (not programmatic) expectation is to see a a double in the result.[...]The rule is that every expression has a type and 22/7 is int.
Oct 24 2017
On 10/24/2017 09:59 AM, Arun Chandrasekaran wrote:On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:The rule is that every expression has a type and 22/7 is int.I'm just questioning the reasoning behind why D does it this way and if it is for compatibility or if there is any other reasoning behind the decision.I'm not a language designer so I can't be sure but I think it has the same reasons that it has in C. The alternative would not be fit for a system language because we wouldn't know what types would be used for certain operations. And types are related to performance because they may be operated on different sets of CPU registers. In the case of floating point, a CPU need not have floating registers at all. So, we don't want types slip from under our grasp because the compiler decided to help the programmer. (One may think that all common CPUs have FP processing units today but it may not be the case in the future. For example, the not-yet-shipping Mill CPU can be configured to have zero or more processing units of any kind.) And we haven't talked about what type 14/7 should be. If we want that to be int, then I think we're in bigger trouble. (I think a timing values should be shorter than 22/7 and suddenly I get an int in my hand.) And only after writing that last sentence I realize that perhaps you meant this only for literals. If so, having same rules for literals vs. variables is beneficial and very important. There are known problems with C, C++, and D compilers' choosing finer precision during compile time for floating point literals during macro expansions. For example, calculations end up having different results on different compilations. Languages like Python 3+ can afford all of this because types or performance don't play a strong role in that environment. ;) Ali
Oct 24 2017
On Tuesday, October 24, 2017 16:59:31 Arun Chandrasekaran via Digitalmars-d- learn wrote:On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote:Part of it is compatibility. In general, valid C code should either be valid D code with the same semantics, or it shouldn't compile. We haven't done a perfect job with that, but we're close. And dividing two integers resulting in a floating point value doesn't fit with that at all. But regardless of that, there's the question of whether it's even desirable, and in a language that's geared towards performance, it really isn't. Also, many us don't want floating point values creeping into our code anywhere without us being explicit about it. Floating point math is not precise in the way that integer math is, and IMHO it's best to be avoided if it's not needed. Personally, I avoid using floating point types as much as possible and only use them when I definitely need them. If they acted like actual math, that would be one thing, but they don't, because they live in a computer, and D's built-in numerical types are closely modeled after what's in the hardware. Obviously, floating point types can be quite useful, and we want them to work properly, but having stuff automatically convert to floating point types on you without being asked would be a serious problem. And in general, D is far more strict about implicit conversions than C/C++ is, not less. So, it would be really out of character for it to do floating point division with two integers. - Jonathan M DavisOn Tue, Oct 24, 2017 at 10:02:11AM +0000, Arun Chandrasekaran via Digitalmars-d-learn wrote:I'm not denying that all the programming languages does it this way (even if it is a cause of related bugs). I'm just questioning the reasoning behind why D does it this way and if it is for compatibility or if there is any other reasoning behind the decision.On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote:[...] I have never seen a programming language in which dividing two integers yields a float or double. Either numbers default to a floating point type, in which case you begin with floats in the first place, or division is integer division, yielding an integer result. TOn 10/23/2017 07:22 AM, Arun Chandrasekaran wrote:Thanks Ali. Is this for backward compatibility with C? Because, if there is a division, a natural/mathematical (not programmatic) expectation is to see a a double in the result.[...]The rule is that every expression has a type and 22/7 is int.
Oct 25 2017