When I run the following line, I get a space after the decimal instead of a “0”.
Debug.Print("Bad Parsing: " + (24.0625f).ToString());
Output I am getting: “Bad Parsing: 24. 62500000”
If the tenths value is 0, the ToString has a space in the tenths position. Can anyone reproduce this? I am running on a Cerberus with a custom 4.3 firmware, but I welcome any testers to try this.
-Valkyrie-MT
tested on spider and 4.2
working correct getting
Bad Parsing: 24.0625
@ VB-Daniel - Thanks. That narrows the scope of where I have to look. It’s probably a bug introduced in the 4.3 firmware. What is also interesting are all the trailing zeros I have, but you do not. I tried this in the emulator and it returned the exact same thing as your spider.
Did you try on the emulator?
@ Gus - Yes, I tried it on the emulator, where it worked correctly. I just tried it on the official GHI 4.2 firmware on my CerbuinoBee and that worked correctly as well. But the same device with my GCC compiled 4.3 firmware returned the bad result. Now I know it is my firmware. I’ll have to go digging through the firmware source to see if I can spot the problem. If I can’t, I’ll have to write my own float.ToString() method, which would make me sad…
Update: I tried another device that has a 4.3 firmware built with RVDS and it worked correctly, so now I suspect either GCC or maybe the floating point configuration in my firmware.
-Valkyrie-MT
And down the rabbit hole I go… So the .ToString() method is in C:\MicroFramework43\Framework\Subset_of_CorLib\System\Single.cs. That calls a method in more generic class called Number.Format() (Number.cs file). Number.Format calls “FormatNative” which is in a C++ file here: C:\MicroFramework43\CLR\Libraries\CorLib\corlib_native_System_Number.cpp. I took that file and diffed it with the one from 4.2 and there were many changes in 4.3. Ah ha! I figured MS just introduced a bug, but when I put the older version in and rebuilt the firmware, it still had the same problem :(. All other files have inconsequential differences with the 4.2 firmware.
So, now I will just modify the Number.Format() method to replace spaces with Zeros. Not ideal, but oh well. That’s what you get when you venture off on your own with firmware… you’re the only tester!
So I changed a lower level method called from the Format() method. Here is what I hacked in:
private static String PostProcessFloat(String original, char format, NumberFormatInfo info)
{
String result = original;
if (format == 'N')
{
result = InsertGroupSeperators(result, info);
}
result = ReplaceDecimalSeperator(result, info);
result = ReplaceNegativeSign(result, info);
// *** BEGIN UGLY WORKAROUND ***
// Replace spaces with zeros. But, why would there be spaces?
// This is a workaround for a bug of unknown origin.
// Debug.Print("Bad Parsing: " + (24.0625f).ToString("F3"));
// would output "Bad Parsing: 24. 62"
var resultChars = result.ToCharArray();
for (var i = 0; i < resultChars.Length; i++)
if (resultChars[i] == ' ') resultChars[i] = '0';
return new string(resultChars);
// *** END EGLY WORKAROUND ***
//return result;
}
That gave me this result:
Bad Parsing: 24.062500000
It’s a bit troubling that I don’t know the cause, but I’ve got bigger fish to fry!
I’ve also encountered other parsing artifacts, such as double.Parse(“1009”) returns 1008.99999999.
@ Iggmoe - [quote]I’ve also encountered other parsing artifacts, such as double.Parse(“1009”) returns 1008.99999999[/quote]
for me it’s no parseing error. It’s an result how double where processed in computer technic.