Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 29 of 181

PROGRAMMER'S TOOLBOX • LISTING 4 • • •• int para_shrink(doubLe &x0, doubLe &x1, doubLe &x2, doubLe &yO, doubLe &y1, doubLe &y2){ doubLe too_cLose; #define MAX-PARA 2 static int countO = 0; static int count2 = 0; if(countO == MAX-PARA){ countO = 0; return FALSE; } if(count2 == MAX-PARA){ count2 = 0; return FALSE; } doubLe x = para_fit(xO, x1, x2, yO, y1, y2); too_cLose = (x2 - xO)/20; if(max(x-xO, x2-x) < too_cLose){ return FALSE; } ++countO; ++count2; doubLe y = f(x); if(x < x1){ if(y> y1){ xO = x; yO = y; countO = 0; } eLse{ x2 y2 x1; y1; x1 = x; y1 = y; count2 = 0; } } eLse{ if(y > y1){ x2 = x; y2 = y; count2 = 0; } eLse{ xO = x1; yO = y1; x1 = x; y1 = y; countO = 0; } } return TRUE; 28 OOOBER 2000 El11bedded Systel11s Progral11l11ing throughout the process (except when th ey' re equal, of course, in which case we' re done) . The new version is shown in Listing 2. Function para_shrinkO ca n now be simplified a bit, since we know the o rder of the x's. We can also eliminate all those silly swaps. The new code fo r this function is shown in Listing 3. The corresponding performance is shown in Figure 3. code fo r goLd_shrinkO, you' ll see tha t it always does just o ne bisectio n, and that o ne is always between Xo and X l ' In practi ce, the whole point of bisections is to pull both endpoints in , but someone got tr icky a nd ho ped to save a littl e code by only doing o ne bisection pe r pass. That someone was me. My o nly excuse is that I had a little encouragement from both Bre nt and the Numerical Recipes au tho rs, who used the same approach. Tha t approach limits th e numbe r o f fun cti on evaluatio ns pe r pass throu gh th e o ute r loop to o ne, whi ch may make it nice [o r counting fun ction evalua tions, but has littl e to o ffe r othe rwise. We save duplicating a few lines of code, which ma kes the ro utin e that much sho rter and more compact. On the down sid e, we have a ll those stupid swaps, which not o nly con [use th e heck o ut of me (as my e rro rs in the swap tes t full y a ttest), bUl eat CPU cycles as well. A side effect is that we can ' t be sure whe th e r X is increasing to th e left o r th e right. In reu'ospect, I believe that ome- one (again, me; who else?) got entire- ly too tricky for his own good. Given a choice between tight and tl;cky, and large but simple, I'll take simple every time. So let's begin the process of sim- plification by writing goLd_shrinkO the way it should have been in the first place, and have it reduce both sides of the in terval each call. We ' ll require, and assume, that:

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11