V5.00: FloatTostr: destination string parameter too large?

[Dany]

Hi, "FloatToStr" (conversions lib) should have enough with a destination parameter of 17 characters (excluding the trailing zero): see http://www.mikroe.com/forum/viewtopic.p ... 8&start=21

However, if using "FloatToStr" with a destination string[17] then the following hint still occurs (mP PRO v5.00):

hint: 3029 1016 Warning: Source size (17) does not match destination size (23) StrngUtils.mpas

1. Apparently FloatToStr still expects a destination string of 23 characters (excluding the trailing zero). According to Janni (see the ref above), max 17 chars should be enough.

2. Also the FloatToStr help stays string[23].

3. Additionally the example in the help shows a (riskfull!!) usage of "string[10]" instead of string[17] (or string[23]):

var ff1, ff2, ff3 : real;
txt : array[10] of char; // <---------------- here !!
...
ff1 := -374.2;
ff2 := 123.456789;
ff3 := 0.000001234;

FloatToStr(ff1, txt); // txt is "-374.20001"

mE,
- How many characters are actually needed to hold the result of FloatToStr????
- Could you please adapt the function's header (e.g. replace the string[23] by string[17), and adapt the help?

See also e.g. http://www.mikroe.com/forum/viewtopic.php?f=86&t=28133 which suggests that 10 chars should be enough???

Also valid for dsPIC30/33 and PIC24 compiler (and possibly for others too).

Thanks in advance!

[janni]

According to Janni (see the ref above), max 17 chars should be enough.

That was in 2009, many versions ago .
More recent estimate for minimal strig length was made here - that was for mP32, but should be valid for all mP/mB compilers (mC compilers have different FloatToStr procedure).
So, 10 chars will not be enough, but 11 should - at least in many cases. Large numbers may need more chars, but then, at least in mP32, the converted number differs from the real one .

If nobody from mE responds, I'll do some checking for PIC compilers in a free moment.

[Dany]

According to Janni (see the ref above), max 17 chars should be enough.

That was in 2009, many versions ago .
More recent estimate for minimal strig length was made here - that was for mP32, but should be valid for all mP/mB compilers (mC compilers have different FloatToStr procedure).
So, 10 chars will not be enough, but 11 should - at least in many cases. Large numbers may need more chars, but then, at least in mP32, the converted number differs from the real one .

If nobody from mE responds, I'll do some checking for PIC compilers in a free moment.

Thanks Janni.

I hope that people of mE will provide the correct figure (worst case).
Anyway: the v5.00 conversion library still wants a string[23] (see the warning), and also the help says string[23], which is certainly too large. On the other hand: the help example shows a too small string (string[10]) usage...

p.s. the resolution before conversion to a string of a real in mP is 7 digits (see note from help below). Does that mean that the string can only have 7 digits, possibly preceded by a minus sign, possibly having a decimal point? (The "E" notition is never used) In this case the worst case length of the FloatToStr destination string would be 7 + 2 = 9, or is this a too simple approach? (yes it is, see the next post)

Note: Given floating point number will be truncated to 7 most significant digits before conversion

Thanks in advance.

[Dany]

Tested in mP v5.00:

As far as I can see

- a "sign" is only there with negative values
- the number of digits before the decimal point (which is always there) is maximal 10 (and at least one)
- there is always a decimal point
- there are always 5 digits after the decimal point (right padded with zeroes if needed).

This makes a maximum total of (still) 17. --> your calculation is still right Janni.

Something odd (or perhaps not): the real number 3999999999 gives a string like "2147483647.21474" which is far from the original number.

p.s. the example in the help saying

Code: Select all

ff3 := 0.000001234;
  FloatToStr(ff3, txt);  // txt is "0.000000"

is also wrong: the result is "0.00000".

[janni]

This makes a maximum total of (still) 17. --> your calculation is still right Janni.

Indeed . I've already forgotten, but, when converting to string, the integer part of fp number cannot go out of range for longint, so it cannot be longer than 10 digits.

This also means that numbers that may be correctly converted have to fit within -2 147 483 648 and 2 147 483 647. (Only in my real2str procedure I've done it a bit differently, so the conversion range may be twice larger.)

To display larger values one needs engineering or scientific notation.

Answer to your original question is then that the output string cannot be shorter than 11 chars but needs not to be longer than 17 chars (plus termination char in both cases).

[Dany]

This makes a maximum total of (still) 17. --> your calculation is still right Janni.

Indeed . I've already forgotten, but, when converting to string, the integer part of fp number cannot go out of range for longint, so it cannot be longer than 10 digits.

This also means that numbers that may be correctly converted have to fit within -2 147 483 648 and 2 147 483 647. (Only in my real2str procedure I've done it a bit differently, so the conversion range may be twice larger.)

To display larger values one needs engineering or scientific notation.

Answer to your original question is then that the output string cannot be shorter than 11 chars but needs not to be longer than 17 chars (plus termination char in both cases).

Thanks Janni. This means that my initial remarks (see first post in this thread) are indeed valid.

Thanks in advance mE!

p.s. I edited the original post to make it more clear what the issues are.

[Dany]

The help still mentions string[23] as destination string size... The wrong examples using string[10] are also still there...

No answer from mE yet?

[darko.minic]

Hi Dany,

Thank you for mentioned this, we will certainly investigate this.

Regards,
Darko