# Convert float to string... strange results
**URL:** https://mworks.discourse.group/t/convert-float-to-string-strange-results/669
**Category:** Support
**Created:** [September 26, 2011, 9:44am UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669 "2011-09-26T09:44:37Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [September 26, 2011, 9:44am UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/1 "2011-09-26T09:44:37Z")
Hi Chris,
I got some strange conversion errors, when i’m convert a float to a string value (like "XYZ: " + (string)floatValue)). I append a small experiment file which (hopefully) reproduce the error.
(in C):
aFloat = 0.9;
for (cx = 1; cx \< 5; cx++) {
aFloat += 0.15;
aString = “=\> " + (string)aFloat + " \<=”; // this line is mWorks syntax
}
the results for aFloat: 1.05, 1.2, 1.35, 1.5, 1.65
the results for aString: “=\> 1.05 \<=”, “=\> 1.2 \<=”, “=\> 1.349999999 \<=”, “=\> 1.499999997 \<=”, “=\> 1.64999995 \<=”
I try many things and check this loop with an older and the actual 0.5 version of mWorks…
Lieben Gruß aus Göttingen
Ralf
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [September 26, 2011, 9:44am UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/2 "2011-09-26T09:44:37Z")
Attachment: [convert.xml](https://mworks.discourse.group/uploads/short-url/lR51wpBfZLFJo4qfnNJeLavovdK.xml) (2.89 KB)
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [September 26, 2011, 3:47pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/3 "2011-09-26T15:47:45Z")
Hi Ralf,
I see what you’re saying, although I do get slightly different strings than you:
```
1.05
1.2
1.349999999999999
1.4999999999999998
1.6499999999999997
```
However, this isn’t an error, but rather a reflection of the fact that the numbers you’re using (0.9 and 0.15) can’t be represented exactly as double-precision floating-point values. The Python tutorial has a [nice explanation of this](http://docs.python.org/tutorial/floatingpoint.html#representation-error), which is also fully applicable to C/C++ and MWorks. I’ve attached a short Python script that shows the issue in action. Here’s what it produces on my machine:
```
$ python2.6 float2string.py
0.90 => 0.90000000000000002
0.15 => 0.14999999999999999
1.05 => 1.05
1.20 => 1.2
1.35 => 1.3499999999999999
1.50 => 1.4999999999999998
1.65 => 1.6499999999999997
```
As noted in the tutorial, Python 2.7 does a better job with printing inexact floats, and we could probably adopt its approach in MWorks. Unfortunately, it doesn’t help much in this case:
```
$ python2.7 float2string.py
0.90 => 0.9
0.15 => 0.15
1.05 => 1.05
1.20 => 1.2
1.35 => 1.3499999999999999
1.50 => 1.4999999999999998
1.65 => 1.6499999999999997
```
Another option would be to support [printf](http://www.cplusplus.com/reference/clibrary/cstdio/printf/)-style precision modifiers (or something equivalent) in MWorks, although that might be more trouble than it’s worth.
Chris
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [September 26, 2011, 3:47pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/4 "2011-09-26T15:47:45Z")
Attachment: [float2string.py](https://mworks.discourse.group/uploads/short-url/7o4AQiPX7ubj8K7RiYc0jZtUAdQ.py) (183 Bytes)
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [September 27, 2011, 6:51pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/5 "2011-09-27T18:51:38Z")
Hi Chris,
thanks for the fast answer. The only thing I can say is: omg … I forgot the floating point problem…
I think a little bit about the problem. We use strings to automate things like the output of staircases or the input for psychometric functions (multiple parameter). Fixing the problem with a printf-function sounds great, but I see the trouble too…
Maybe, we can put the printf for conversion on the feature wish list for 0.5 final?
Mit sonnigen Gruß
Ralf
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [September 28, 2011, 3:18pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/6 "2011-09-28T15:18:06Z")
> Maybe, we can put the printf for conversion on the feature wish list for 0.5 final?
I’ll have to think about how a printf-style function would fit in with the existing expression parser/syntax, but it should be possible. We could also opt to use less-than-full precision when converting floats to strings, as including 16 decimal places is undoubtedly overkill.
Chris
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [January 5, 2012, 8:58pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/7 "2012-01-05T20:58:11Z")
Hi Ralf,
I’ve added a new function, `format()`, to the expression parser, which does printf-style string formatting. Usage is as you’d expect:
```
format("%d * %.2f = %s", 2, 3.0, "six") -> "2 * 3.00 = six"
```
I’ve attached a new version of your example experiment that shows it in action.
The actual formatting is handled by `boost::format`. For details on the format string syntax, see the [boost::format docs](http://www.boost.org/doc/libs/1_45_0/libs/format/doc/format.html#printf_directives).
This should be available in the nightly build shortly.
Cheers,
Chris
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [January 5, 2012, 8:58pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/8 "2012-01-05T20:58:11Z")
Attachment: [convert\_with\_format\_func.xml](https://mworks.discourse.group/uploads/short-url/blZYFqQZa0bpI1I4qPSeA0T4QXi.xml) (2.89 KB)
---
### Author:  [@cstawarz](https://mworks.discourse.group/u/cstawarz)
#### Post date: [July 19, 2022, 11:44pm UTC](https://mworks.discourse.group/t/convert-float-to-string-strange-results/669/9 "2022-07-19T23:44:43Z")