| View previous topic :: View next topic |
| Author |
Message |
bart.dinger
Joined: 02 Nov 2005
Posts: 9
|
| Math problems with 3.240 |
 Posted: Sun Dec 04, 2005 6:01 pm |
 |
|
Anybody else finding math problems with 3.240? I'm doing some complicated calculations (including log functions) and a peice of code that works perfectly in 2.236 doesn't generate the correct result in 3.240.
I've had to go back 2.236 because I can't figure out whats changed in the compiler that causes my problem.
simple line like
x=log(y)
(where y is a float) give incorrect answer when viewing in watch window, hence further calcs are also corrupt, yet same line works when I reinstall 2.236. Have they made changes to the math library? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Dec 04, 2005 6:06 pm |
|
|
| Post a small sample program that we can test. |
|
|
bart.dinger
Joined: 02 Nov 2005
Posts: 9
|
|
| Posted: Sun Dec 04, 2005 10:17 pm |
|
|
#include <16F873A.h>
#fuses XT,NOWDT,DEBUG,NOLVP,NOBROWNOUT,PUT
#include <MATH.h>
#include <STDLIB.H>
float x;
float y;
void main() { // main loop
y=550;
while (1) {
x= log(y);
delay_cycles(25); // set breakpoint here
}
}
Version 2.236, y is 6.309918 (correct)
Version 2.240, y is -1159.700 (This is clearly incorrect)
Running on Mplap 7.21, PIC873A using ICDII |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Dec 05, 2005 12:05 am |
|
|
There's a difference between the .LST files for the two versions. It starts
with the code generated for this line in the log() function, in math.h:
y = (y - 1.0)/(y + 1.0);
So they must have changed something in their floating point routines.
You should report the bug to CCS support, and include that sample
program that you posted. |
|
|
RKnapp
Joined: 23 Feb 2004
Posts: 51
|
| Yes -- on 3.240 all my math went to heck, too |
| Posted: Mon Dec 05, 2005 1:06 pm |
|
|
Yes, dang it.
Upgrading to PCWH v3.240 this morning (I've been on other projects for awhile, so my previous version is 2.235) caused all my floating point math running on my PIC18F8722s to go wild. Unfortunately I have a very large, complex program so I'm not sure where to start cutting out a piece of example code. But I guess my plan is first to revert back to 2.235 and see if I can restore functionality.
I don't use logarithms -- just mutiplies and divides -- so the problem must lie in something simple but crucial.
This particular upgrade also forced me to recreate my .pjt file, which has not been necessary with previous version. I wonder if there is a connection...?
Did anyone alert CCS?
 Robert |
|
|
bart.dinger
Joined: 02 Nov 2005
Posts: 9
|
|
| Posted: Mon Dec 05, 2005 1:21 pm |
|
|
| Do they have a special email address to report bugs to? I orginally emailed them to the address on the front page, but didn't get a reply, which is why I posted here. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
Briartek
Joined: 07 Nov 2003
Posts: 5
|
| Re: Math problems with 3.240 |
| Posted: Mon Dec 05, 2005 3:04 pm |
|
|
| bart.dinger wrote: | Anybody else finding math problems with 3.240? I'm doing some complicated calculations (including log functions) and a peice of code that works perfectly in 2.236 doesn't generate the correct result in 3.240.
I've had to go back 2.236 because I can't figure out whats changed in the compiler that causes my problem.
simple line like
x=log(y)
(where y is a float) give incorrect answer when viewing in watch window, hence further calcs are also corrupt, yet same line works when I reinstall 2.236. Have they made changes to the math library? |
Definately, I just upgraded to 2.40 and all of the conversions from strtod are incorrect. I read in a GPS string and convert lat & lon to floating point with this command. What worked in 2.35 is now broke in 2.40; 3849.5760 strtod's to -47.4238 and 07703.5591 strtod's to 47.4400. (guess where i am sitting?). Dont they have simple programs to test this with before they release it?? If so, how did this one get through the cracks! |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Dec 05, 2005 3:12 pm |
|
|
One question?.
I haven't played with 3.240 yet (I usually 'lt the dust settle', unless it has a feature I need), but notice that the 'report' on their web site, for what is changed, talks about alterations to the optimiser. Has anyone tried turning the optimiser down?. There were some lovely bugs when they added extra optimisations for the 18 chips in the past, which were 'avoidable' by lowering the optimiser settings, and it might be another one of the same sort...
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Dec 05, 2005 4:01 pm |
|
|
| Quote: | Has anyone tried turning the optimiser down?
|
On the example shown below, I tried it with PCM vs. 3.240 at #opt 9,
#opt 7, and 5, and it had the same error every time:
| Quote: |
x = -1159.700480
x = -1159.700480
x = -1159.700480
|
| 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)
#opt 5
#include <MATH.h>
#include <STDLIB.H>
float x;
float y;
void main()
{
y=550;
x= log(y);
printf("x = %f \n", x);
while(1);
} |
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Dec 08, 2005 1:01 pm |
|
|
It looks like CCS fixed that problem with vs. 3.241 (just released).
The test program posted above now displays:
x = 6.309919 |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Dec 08, 2005 1:47 pm |
|
|
On the other hand, the floating point display routine still has bugs:
PCM vs. 3.241 displays: -694.967296
PCM vs. 3.240 displays: -694.967296
PCM vs. 3.236 displays: -694.967296
PCM vs. 3.191 displays: 3599.999845
It should display: 3600.000000
Test program:
| 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)
//============================
main()
{
float f;
f = 3600.0;
printf("%f \n\r", f);
while(1);
} |
|
|
|
RKnapp
Joined: 23 Feb 2004
Posts: 51
|
| Still Something Squirrely about 3.241's Floating Point Math |
| Posted: Tue Dec 13, 2005 5:49 pm |
|
|
Friends,
Dang it, there is still something wrong with floating point math in PCWH v3.241. I'd submitted a bug report earlier and am always pleased with how responsive CCS is -- they quickly came out with 3.241 as a fix to 3.240,* but there is still something wrong.
It sounds lame, but I can't figure out where (in my thousands of lines) the problem occurs. I have several 8722 processors handing off data. But the problem doesn't happen in 3.235.
I'm sorry I can't be of more help, but I've lost a week of a tight schedule on this already and am just saying, "if in doubt, revert, and see if it still happens."
Good luck,
Robert
*I used to work for a company which maddeningly insisted "there are no bugs" to anyone, even its own employees. When up against the wall with hard evidence, the managers would then allow, "Okay. It will be fixed." Translation: the product is still selling, so get lost. I am very grateful that CCS is not like this. |
|
|
bart.dinger
Joined: 02 Nov 2005
Posts: 9
|
|
| Posted: Tue Dec 13, 2005 8:29 pm |
|
|
Yeah I still have a problem with 3.241 too :( and am still using 3.236. I don't think its the floating point thing anymore tho, there is something else wrong  |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Dec 14, 2005 4:56 am |
|
|
I have to agree. Something else 'screwy' is going on. The problem is narrowing it down to a small demonstrable fault. I have a very large program, that has worked fine for perhaps the last thirty or more compiler versions. Happened to need to recompile it, and tried various versions to see what happened. 3.236, works fine. 3.240, caused two fp arithmetic operations to completely screw up. 3.241, fixed these, but then introduced some odd formatting errors in a couple of output statements (both using large RAM arrays). I'd suspect there is a memory problem somewhere, but tracking it down is going to need more time than I can spare....
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
