QStrings and Floats, Current Precision?

[wysota]

I don't see how Qt or C++ would have to guess what you as the user consider "useless". My point of view is that if you want a decimal calculator, you use decimal (aka fixed point) math.You can calculate everything using integers and keep the precision as a separate value and then just put the decimal point in the right place when showing the result.

[tescrin]

I think I can see what you're saying. I did something akin to that elsewhere in the program (or rather a program that uses this keypad dialog.) Still, how many calculators have you used that preserve the actual number of digits? IIRC even my TI-83+ and TI-92 may not have done that (it's hard to remember having not used them for a year or two.)

But I think you still misunderstand. C++ *already* does that. Similar to what I said before if you do:

float x=10.0000, y=3.0010;
cout<<x*y;

float x=10.0000, y=3.0010;
cout<<x*y;

To copy to clipboard, switch view to plain text mode 

the output will be 30.01, not 30.010 (or 30.0100), which true precision would say the result *is*. This is *default functionality* is what I'm saying; and I'm surprised that Qt went out of it's way to "improve" upon functionality without also allowing you to print it the way it would normally.

What I'm calling "useless digits" are the same digits the default truncation C++ gets rid of, however accurate it would be in real world scientific application. Note also, that your calculator would be incorrect if given two values like the above (if I understand you correctly):

float x=10, y=3.0010;
cout<<x*y;

float x=10, y=3.0010;
cout<<x*y;

To copy to clipboard, switch view to plain text mode 

This would output under your code (assuming I understand you) 30.010 (or 30.0100), which is incorrect. We can only know that it is 30. Further more, if a user is using your calculator which value do they expect? They expect that you didn't get rid of their .01 for the sake of precision correctness. They'd expect it to be the "incorrect" or "unprecise" value because they're presumably either smart enough to truncate the amount they were not supposed to use, or don't care to.

I argue that in *any* user realm, the user expects the calculator to give it all of it's information and they don't want several trailing zeros. Again, in acadamia or research you'd likely go figure out the precision yourself and rather have the calculator just calculate.


Disclaimer: I hate to turn this into a topic about the philosophy of keypad precision :S. Technically my question is answered and a solution is posted.


EDIT: It's worth noting that I understand C++ isn't technically truncating digits; that instead it's never saving them in the floating point format because there's no need to. It doesn't change my point at all.

[wysota]

the output will be 30.01, not 30.010 (or 30.0100),

Sure it will but not because of C++ but rather because the binary representation of all these is the same. Your computer simply doesn't differentiate between them. But if you write a decimal number that doesn't have a binary representation then you won't get what you entered but rather what the actual binary representation closest to what you entered is. That's how floating point works. The precision of the number is not determined by any calls to setprecision() (whatever that is) but by the value itself. Some values (like 0.1) do not have a binary representation. What cout does is (probably) that it rounds the binary value to a human-readable decimal representation. QTextStream does the same thing.

#include <QtCore>
#include <iostream>
 
int main() {
  QString s;
  QTextStream str(&s);
  str << 0.000001;
  qDebug() << s;
  std::cout << 0.000001 << std::endl;
  return 0;
}

#include <QtCore>
#include <iostream>

int main() {
  QString s;
  QTextStream str(&s);
  str << 0.000001;
  qDebug() << s;
  std::cout << 0.000001 << std::endl;
  return 0;
}

To copy to clipboard, switch view to plain text mode 

"1e-06"
1e-06

(both will show "0.01" for 0.01)


This all doesn't change the fact that when using floating point, you're risking not showing the actual value that is used for calculation. I would never risk using such calculator for serious calculations, to be honest...

[tescrin]

Ha! I didn't realize you meant to not use floating point at all. For sure.

As it is, this is a simple keypad for user input (it doesn't even do calculations, sort of...) That said, yeah, I can agree with that. Binary representation has it's practical limits.

EDIT: You've never used "setprecision()"? Its a standard C++ cout uh.. right-hand variable. I.E. setprecision(X) limits all cout functionality to read to X decimal places similar to QString::number(<NUM>,'f',X) regardless of the number.

Also, you keep talking as if I didn't make it clear that I understand how floating point is represented. I even displayed so in an example (and mentioned why.) It's worth noting that Cout isn't really doing anything to the value other than allowing the floating point to be interpreted; just as you said there's no distinction for extra zeros. [You're setting floating point bits and then leaving the exponent. There's no real way to set extra zeros in binary without always setting all of them.]

The main issue in this discussion has been that we're viewing the word "Precision" differently. I'm using as the Qt term (and apparently C++ term) meaning "number of decimal places to use" and you seem to be remarking on the actual precision of the value.

[wysota]

As it is, this is a simple keypad for user input (it doesn't even do calculations, sort of...)

Then why do you keep it as a numeric value instead of keeping it as text in the first place?

EDIT: You've never used "setprecision()"? Its a standard C++ cout uh.. right-hand variable.

Then it is std::ostream::setprecision() or something like that. And no, I have never used it, at least not that I remember using it. There is QTextStream::setRealNumberPrecision() if you want it.

It's worth noting that Cout isn't really doing anything to the value other than allowing the floating point to be interpreted

It is the one interpreting it so yeah... I'd say it does something to the value.

just as you said there's no distinction for extra zeros.

That's different. That's done by the compiler (or actually by the parser).

[You're setting floating point bits and then leaving the exponent. There's no real way to set extra zeros in binary without always setting all of them.]

To be honest there are no zeroes there at all. There are (usually) two binary values --- mantissa and exponent. And they are both of fixed width that can contain a lot of zeroes at the end.

The main issue in this discussion has been that we're viewing the word "Precision" differently. I'm using as the Qt term (and apparently C++ term) meaning "number of decimal places to use" and you seem to be remarking on the actual precision of the value.

No, we are interpreting this word the same way. I'm just saying you either have fixed precision or not. There is no "magically-determine-precision-for-me" precision. I'm sure there are lots and lots of decimal values that "cout" (meaning std::ostream) will show in a different way than what you input in your source code file (ignoring any trailing zeroes that do not change the actual value) or in some text field. The more fine grained values you use the higher probability of such behaviour. "cout" can guess that when you give it 0.100000001 then you probably mean 0.1 but at some point you might want to show 0.100000001 and it will instead display 0.1. It's all about heuristics and those are by definition not always correct.