[BUG]: Rounding Values when Using String Type Cast

[hasenradball]

Basic Infos

• [x ] This issue complies with the issue POLICY doc.
• [x ] I have read the documentation at readthedocs and the issue is not addressed there.
• [x ] I have tested that the issue is present in current master branch (aka latest git).
• [x ] I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• [x ] I have filled out all fields below.

Platform

• Hardware: [ESP-12]
• Core Version: [2.6.3]
• Development Env: [Arduino IDE|]
• Operating System: [Windows]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [qio|dio|other]
• Flash Size: [4MB/1MB]
• lwip Variant: [v1.4|v2 Lower Memory|Higher Bandwidth]
• Reset Method: [ck|nodemcu]
• Flash Frequency: [40Mhz]
• CPU Frequency: [80Mhz|160MHz]
• Upload Using: [OTA|SERIAL]
• Upload Speed: [115200|other] (serial upload only)

Problem Description

When using a type cast to cast an float to a String like:
String(pressure, 0) the result is not rounded correctly.
If I make a type cast like this:
String(pressure, 1)the result is rounded correctly.

MCVE Sketch

#include <Arduino.h>

void setup() {
  Serial.begin(115200);
  while (!Serial) yield(); 
  int a = 1014;
  float b = 1014.45;
  float c = 1014.5;

  Serial.println();
  Serial.println(a);
  
  Serial.println();
  Serial.println(b, 1);
  Serial.println(String(b,1));

  Serial.println();
  Serial.println(c, 0);
  Serial.println(String(c ,0));
}

void loop() {
}

Debug Messages

1014

1014.5
1014.5

1015
1014

[hasenradball]

Maybe the problem is located in WString.cpp

String::String(float value, unsigned char decimalPlaces) {
    init();
    char buf[33];
    *this = dtostrf(value, (decimalPlaces + 2), decimalPlaces, buf);
}

String::String(double value, unsigned char decimalPlaces) {
    init();
    char buf[33];
    *this = dtostrf(value, (decimalPlaces + 2), decimalPlaces, buf);
}

[d-a-v]

check our implementation of dtostrf()

It may need some fixes and optimizations.

[hasenradball]

I located the point of root cause...
But I didn't understand the result when debugging.

[hasenradball]

Here my debugging Sequence:

[hasenradball]

Here you find my test file:

Test_file3.zip

[hasenradball]

@d-a-v do you have an idea?
I do not understand the behaviour in the last loop. Why 7 results in 6

[earlephilhower]

This boils down to imprecision with floating point numbers. 1014.5 can't be exactly represented as a float or a double. The FP representation is just under 1014.5.

The output discrepancy is because Print and String use different ways of generating a text string. Print uses a custom sequence of operations, while String uses the same method, essentially, as C-lib printf.

Even the PC will generate 1014 as output when printing 1014.5:

$ cat /tmp/a.c 
#include <stdio.h>
void main() {
	float a=1014.5;
	printf("%.0f\n", a);
}
$ gcc -o /tmp/a /tmp/a.c
$ tmp/a
1014

We should fix both Print and String (well, dtostrf) to just use sprintf() and not try and hand-generate the string, but this specific issue is just a fact of live w/IEEE FP.

[hasenradball]

Hi,
on my Ubuntu it works fine.

#include <stdio.h>

int main(void) {
float a = 1045.5;

printf("%.0f", a);
return 1;
}
frank@frank-ubuntu1:~/Schreibtisch/temp$ ./test
1046frank@frank-ubuntu1:~/Schreibtisch/temp$ 

[earlephilhower]

Try again with 1014.5 and not 1045.5 to see the IEEE FP difference. :)

[hasenradball]

Hi earlhilpower,

have you tested the following?

void setup() {
 WiFi.mode(WIFI_OFF);
 
 Serial.begin(115200);
 if(!Serial) yield();
 Serial.println();
 
 float a = 1014.5;
 float b = 4.95;
 
 Serial.println(a, 2);
 Serial.println(b, 2);
 Serial.println(String(a, 2));
 Serial.println(String(b, 2));

 Serial.println(a, 1);
 Serial.println(b, 1);
 Serial.println(String(a, 1));
 Serial.println(String(b, 1));

 Serial.println(a, 0);
 Serial.println(b, 0);
 Serial.println(String(a, 0));
 Serial.println(String(b, 0));
}

rounding from 2 to 1 digit does't work too...

1014.50
4.95
1014.50
4.95
1014.5
4.9
1014.5
4.9
1015
5
1015
 5

[earlephilhower]

Again, please read up on IEEE floating point imprecision. FP is not base-10, it's base-2, so numbers that look nice and clean can not be exactly represented by the format. That's why applications dealing with money would use binary-coded decimal (BCD) or other tricks to ensure exact representation of base-10 numbers.

[hasenradball]

Hi, ok yes this shows the behavior:

 4.90: 4.9
 4.91: 4.9
 4.92: 4.9
 4.93: 4.9
 4.94: 4.9
 4.95: 4.9
 4.96: 5.0
 4.97: 5.0
 4.98: 5.0
 4.99: 5.0