|
|
View previous topic :: View next topic |
Author |
Message |
eleqtc
Joined: 20 Jan 2004 Posts: 5
|
atof error ?? |
Posted: Tue Aug 16, 2005 4:50 pm |
|
|
Hi,
Code below receives an ascii code number into the buffer, prints it back out to verify, converts to float and prints out again however these are my results. Anyone verify this is a bug or have I missed something please ?
Thanks,
Tony
enter and the float_printf_result
1.001004 gives 1.00100408 (OK)
2.3456 gives 2.34560016 (OK)
0.001 gives .100000 (now the errors....)
0.001004 gives .100400
100.0 gives 14.100654
which is a pain as I'm storing 0.001004 type fractions.
Code: |
PCM version 3.231
#include <16F88.H>
#fuses MCLR, NOBROWNOUT, NOLVP, NOWDT, NOCPD, NOPROTECT, HS, noPUT, NODEBUG
#use delay(clock=16000000) // Change if you use a different clock
#use fast_io(A)
#use fast_io(B)
#use rs232(baud=57600, rcv=PIN_B2,xmit=PIN_B5, parity=N, bits=8 )
#use I2C(master, sda=PIN_B1, scl=PIN_B4, force_hw, fast )
#include <stdio.h>
#include <stdlib.h>
void main (void) {
char buffer[25] ;
float tmp;
int x;
putc('*'); // indicate ready to receive data
putc(' ');
for (x=0;x<25;x++) { // init buffer to zero
buffer[x]=0;
}
gets(buffer);
printf(buffer); // prints back exactly what I entered OK
tmp=atof(buffer);
printf("\n\r");
printf("%2.8f \r\n", tmp); // errors encountered
while(true){ }
} // main | [/code] |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Aug 16, 2005 4:56 pm |
|
|
Version 3.231 for both PCM and PCH is buggy with respect to the
display of floating point numbers. They print incorrect values.
CCS tried to fix the rounding problem, but it needs more work.
I suggest going back to vs. 3.230 if you've got it. |
|
|
eleqtc
Joined: 20 Jan 2004 Posts: 5
|
Re.atof bugs |
Posted: Wed Aug 17, 2005 4:23 am |
|
|
Thanks PCM Programmer. I was experiencing problems with 3.180 so forked out some dosh to upgrade. I'll try 3.191.
Thanks,
Tony |
|
|
C-H Wu Guest
|
atof() is ok, %2.8f is buggy |
Posted: Thu Aug 18, 2005 12:13 am |
|
|
atof() is ok, %2.8f is not a good idea, failed in three cases, %12.8f failed in one case, %f still works fine, here is my test report with code.
Code: | code (PIC18F4620) 3.231 (ROM 22016) 3.226 / 3.228 (ROM 21814)
--------------------------------------------------------------------------------------------------------
strcpy(s, "1.001004");
printf("\r\nstring s = %s", s); tmp = atof(s); 1.001004 1.001004
printf("\r\natof(s) = %f", tmp); 0001.001004 1.001004
printf("\r\natof(s) = %2.8f", tmp); 1.00100408 1.00100409
printf("\r\natof(s) = %12.8f\r\n", tmp); 01.00100408 1.00100409
strcpy(s, "0.001");
printf("\r\nstring s = %s", s); tmp = atof(s); 0.001 0.001
printf("\r\natof(s) = %f", tmp); 0000.001000 .001000
printf("\r\natof(s) = %2.8f", tmp); .100000 %2.8f bug .00100000
printf("\r\natof(s) = %12.8f\r\n", tmp); 00.00100000 .00100000
strcpy(s, "0.001004");
printf("\r\nstring s = %s", s); tmp = atof(s); 0.001004 0.001004
printf("\r\natof(s) = %f", tmp); 0000.001004 .001004
printf("\r\natof(s) = %2.8f", tmp); .100400 %2.8f bug .00100400
printf("\r\natof(s) = %12.8f\r\n", tmp); 00.00100400 .00100400
strcpy(s, "100.0");
printf("\r\nstring s = %s", s); tmp = atof(s); 100.0 100.0
printf("\r\natof(s) = %f", tmp); 0100.000000 99.999999
printf("\r\natof(s) = %2.8f", tmp); 14.10065408 %2.8f bug 99.99999940
printf("\r\natof(s) = %12.8f\r\n", tmp); 14.10065408 %12.8f bug 99.99999940
|
3.230 has some other bug I reported to CCS, and told to be fixed in 3.231.
3.225 and before has other bugs which I can not live with.
Well, 3.226 and 3.228 are my only hopes now.
Any information regarding 3.226 / 3.228 are appreciated.
Best wishes
C-H Wu |
|
|
C-H Wu Guest
|
atof() is ok, %2.8f is buggy |
Posted: Thu Aug 18, 2005 12:14 am |
|
|
atof() is ok, %2.8f is not a good idea, failed in three cases, %12.8f failed in one case, %f still works fine, here is my test report with code.
Code: | code (PIC18F4620) 3.231 (ROM 22016) 3.226 / 3.228 (ROM 21814)
--------------------------------------------------------------------------------------------------------
strcpy(s, "1.001004");
printf("\r\nstring s = %s", s); tmp = atof(s); 1.001004 1.001004
printf("\r\natof(s) = %f", tmp); 0001.001004 1.001004
printf("\r\natof(s) = %2.8f", tmp); 1.00100408 1.00100409
printf("\r\natof(s) = %12.8f\r\n", tmp); 01.00100408 1.00100409
strcpy(s, "0.001");
printf("\r\nstring s = %s", s); tmp = atof(s); 0.001 0.001
printf("\r\natof(s) = %f", tmp); 0000.001000 .001000
printf("\r\natof(s) = %2.8f", tmp); .100000 %2.8f bug .00100000
printf("\r\natof(s) = %12.8f\r\n", tmp); 00.00100000 .00100000
strcpy(s, "0.001004");
printf("\r\nstring s = %s", s); tmp = atof(s); 0.001004 0.001004
printf("\r\natof(s) = %f", tmp); 0000.001004 .001004
printf("\r\natof(s) = %2.8f", tmp); .100400 %2.8f bug .00100400
printf("\r\natof(s) = %12.8f\r\n", tmp); 00.00100400 .00100400
strcpy(s, "100.0");
printf("\r\nstring s = %s", s); tmp = atof(s); 100.0 100.0
printf("\r\natof(s) = %f", tmp); 0100.000000 99.999999
printf("\r\natof(s) = %2.8f", tmp); 14.10065408 %2.8f bug 99.99999940
printf("\r\natof(s) = %12.8f\r\n", tmp); 14.10065408 %12.8f bug 99.99999940
|
3.230 has some other bug I reported to CCS, and told to be fixed in 3.231.
3.225 and before has other bugs which I can not live with.
Well, 3.226 and 3.228 are my only hopes now.
Any information regarding 3.226 / 3.228 are appreciated.
Best wishes
C-H Wu |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Aug 18, 2005 1:26 am |
|
|
PCM and PCH vs. 3.231 have a floating point display bug.
With the test program shown below, vs. 3.230 displays this:
3198.999911
That's the same old problem where they don't display the number
correctly. It should be: 3199.000000
With vs. 3.231, they tried to fix it, but they caused a bug which
displays it as: -1095.967232
If you use width and precision values, such as "%4.1f" then it displays
3199.0 which is correct.
I emailed them about this a few days ago, so I think they're working on it.
Code: | #include <16F877.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock = 4000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
void main()
{
float f;
f = 3199.0;
printf("%f\n\r", f);
while(1);
} |
|
|
|
Ttelmah Guest
|
|
Posted: Thu Aug 18, 2005 3:10 am |
|
|
I would say, that %2.8, might be 'aggravating' the probem on other versions of the compiler.
The first number is the minimum field width, then you are asking to print 8 digits after the DP. Having the second value larger than the first, would on 'heavier duty' compilers, not be a problem, with the trailing digits truncating when the number hasn't got non zero trailing digits, but I'd not want to rely on it with the CCS implementation...
I'd suggest getting rid of the first number entirely. It is really doing nothing, and might well help confuse the compiler!.
Best Wishes |
|
|
C-H Wu Guest
|
3199, what a magic number ! |
Posted: Fri Aug 26, 2005 9:23 am |
|
|
PCM programmer wrote: | PCM and PCH vs. 3.231 have a floating point display bug.
...
With the test program shown below, vs. 3.230 displays this:
3198.999911
That's the same old problem where they don't display the number
correctly. It should be: 3199.000000
With vs. 3.231, they tried to fix it, but they caused a bug which
displays it as: -1095.967232
...
I emailed them about this a few days ago, so I think they're working on it.
|
PCH 3.232 ... still the same bug with 3199 !
Code: |
x = 3199; // display
printf("\r\n x = %f", x); // -1095.967232 :shock:
printf("\r\n x = %6.1f \r\n", x); // 3199.0 :grin:
printf("\r\n x = %9.3f \r\n", x); // 3199.000 :)
printf("\r\n x = %9.6f \r\n", x); // -1095.967232 :cry:
printf("\r\n x = %12.6f \r\n", x); // -1095.967232 :eek:
printf("\r\n x = %12.8f \r\n", x); // 20.72445051 :shock:
|
how many e-mail are needed to fix this bug ? |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Aug 26, 2005 12:33 pm |
|
|
Quote: | PCH 3.232 ... still the same bug with 3199 ! |
I noticed that too. If CCS cannot handle certain values for width
or precision, then they should issue an error message at compile time.
Or, at runtime, they should truncate it to something that they can handle.
They should never dump out a wildly incorrect result, like they do with
my example. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|