Post by thread:Floating point app notes

Are any of the Microchip floating point app notes reasonably bug free? I've just finished downloading AN575, revision 2.7 and 2.8. I don't see any difference from v2.02 offhand, other than a few variable renames. In the past I've read on the Piclist that the divide routine is buggy, that the multiply routine doesn't always round correctly, and that the addition and subtraction routines fail under some circumstances (something about large magnitude differences (2^24) and opposite signs). I've also read that the normalize routine doesn't always shift properly, causing rounding and carry errors. But these posts didn't mention which revision of the library they found the bugs in. And Microchip didn't bother adding any comments to the code warning of bugs (or bug corrections)! Has anyone found a solid floating point library? thanks in advance, newell

On Mon, 9 Feb 1998, Scott Newell wrote: > [...] > In the past I've read on the Piclist that the divide routine is buggy, that > the multiply routine doesn't always round correctly, and that the addition > and subtraction routines fail under some circumstances (something about > large magnitude differences (2^24) and opposite signs). I've also read > that the normalize routine doesn't always shift properly, causing rounding > and carry errors. And don't forget that the sqrt routine chews up 3,000 some odd cycles, for a poor aproximation, when the exact result can be gotten in less than 200 cycles. > [...]

At 08:35 1998-02-10 -0700, you wrote: >On Mon, 9 Feb 1998, Scott Newell wrote: > >> [...] > >> In the past I've read on the Piclist that the divide routine is buggy, that >> the multiply routine doesn't always round correctly, and that the addition >> and subtraction routines fail under some circumstances (something about >> large magnitude differences (2^24) and opposite signs). I've also read >> that the normalize routine doesn't always shift properly, causing rounding >> and carry errors. > > And don't forget that the sqrt routine chews up 3,000 some odd cycles, > for a poor aproximation, when the exact result can be gotten in less than > 200 cycles. > >> [...] > Oh, shit! Is it that bad! How can we obtain correct libraries, then? BTW do the C compilers do correct math, then? /Morgan / Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \ \ spam_OUTmrtTakeThisOuTiname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331 /

At 08:35 AM 2/10/98 -0700, you wrote: <snip> > And don't forget that the sqrt routine chews up 3,000 some odd cycles, > for a poor aproximation, when the exact result can be gotten in less than > 200 cycles. > >> [...] > BTW, I'm just curious, what method do most sqrt routenes use? I once wrote a very small QBASIC program just for the heck of it that calculated sqrt using newton's method on the equation x^2 = c where c was the input and the newton's method result for x was the output. It converged to a VERY accurate result in only a few loops. I know that QBASIC is quite different from assembler, of course, but the same basic algorithim can be used as long as you have access to a division routene. Another method which is a bit more primitive but is bascially the same thing is the Heron (sp?) of Alexandria's method. I have never tried it, but I think it executes in roughly the same amount of time. Sean +--------------------------------+ | Sean Breheny | | Amateur Radio Callsign: KA3YXM | | Electrical Engineering Student | +--------------------------------+ Fight injustice, please look at http://homepages.enterprise.net/toolan/joanandrews/ Personal page: http://www.people.cornell.edu/pages/shb7 .....shb7KILLspam@spam@cornell.edu Phone(USA): (607) 253-0315

Care here. Scott only mentioned that the square root takes 3000 odd cycles. He DIDN'T actually confirm anything else that you believed had been heard on the PICLIST about the routines' accuracy etc. I have a pending requirement for something which uses floating point routines and had noted the Microchip ones as a potential source. I'm sure Microchip would be delighted if anyone pointed out problems with their suggested code AND proposed a proper fix. I would be extremely grateful for any such information. Hopefully, part of using such code would involve understanding it and deriving the underlying algorithm, which MAY help spot bugs but that's not always the way things get done :-). So, does anyone have any factual information on the quality of the Microchip floating point routines? (No doubt this is another cyclically asked question - Where did you say the PICLIST FAQ was ? :-) {Original Message removed}

On Wed, 11 Feb 1998, Russell McMahon wrote: > Date: Wed, 11 Feb 1998 09:06:58 +1300 > From: Russell McMahon <apptechKILLspamclear.net.nz> > To: .....PICLISTKILLspam.....MITVMA.MIT.EDU > Subject: Re: Floating point app notes > > Perhaps you'd like to post the improved code? sqrt routines were posted here before... a few years ago. {Quote hidden}> (provided, of course, that it satisfies the requirements of > code found on the internet as per another thread :-)) > > > >On Mon, 9 Feb 1998, Scott Newell wrote: > > > > And don't forget that the sqrt routine chews up 3,000 > some odd cycles, > > for a poor aproximation, when the exact result can be > gotten in less than > > 200 cycles. > > > >> [...] > > >

Several months ago I have posted these corrections to the floating point library: The following applies to the FP32_14.a16 library, you can probably locate appropriate code segment in other libraries as well. I did not change any labels, so compare them to the original code. Changes are commented in capitals. Addition and subtraction: ... FPA32 MOVF AARG+B0,W ; exclusive or of signs in TEMP XORWF BARG+B0,W MOVWF TEMP MOVF AEXP,W ; use AARG if AEXP >= BEXP SUBWF BEXP,W BTFSS _C GOTO USEA32 MOVF BEXP,W ; otherwise, swap AARG and BARG XORWF AEXP,W ; THIS WAS NOT ACTUALLY A BUG BUT SWAPPING AARG AND BARG XORWF BEXP,F ; IS 6 INSTRUCTIONS SHORTER THIS WAY XORWF AEXP,F MOVF BARG+B0,W XORWF AARG+B0,W XORWF BARG+B0,F XORWF AARG+B0,F MOVF BARG+B1,W XORWF AARG+B1,W XORWF BARG+B1,F XORWF AARG+B1,F MOVF BARG+B2,W XORWF AARG+B2,W XORWF BARG+B2,F XORWF AARG+B2,F USEA32 MOVF AARG+B0,W MOVWF SIGN ; save sign in SIGN BSF AARG+B0,MSB ; make MSB's explicit BSF BARG+B0,MSB MOVF BARG+B0,W MOVWF ACC+B3 MOVF BARG+B1,W MOVWF ACC+B4 MOVF BARG+B2,W MOVWF ACC+B5 MOVF BEXP,W ; compute shift count in BEXP SUBWF AEXP,W MOVWF BEXP BTFSC _Z GOTO AROUND32 MOVLW 8 SUBWF BEXP,W BTFSS _C ; if BEXP >= 8, do byte shift GOTO ALIGNB32 MOVWF BEXP RLF ACC+B5 ; rotate next bit for rounding MOVF ACC+B4,W MOVWF ACC+B5 MOVF ACC+B3,W MOVWF ACC+B4 CLRF ACC+B3 MOVLW 8 SUBWF BEXP,W BTFSS _C ; if BEXP >= 8, do byte shift GOTO ALIGNB32 MOVWF BEXP RLF ACC+B5 ; rotate next bit for rounding MOVF ACC+B4,W MOVWF ACC+B5 CLRF ACC+B4 MOVLW 8 ; THIS TEST WAS MISSING AND ERRORS OCCURED SUBWF BEXP,W ; AS A RESULT BTFSC _C GOTO FIXSIGN32 ALIGNB32 MOVF BEXP,W ; already aligned if BEXP = 0 Multiplication: MROUND32 BTFSC FPFLAGS,RND BTFSS ACC+B5,LSB GOTO MUL32OK RLF ACC+B0 ; rotate next significant bit into MOVLW 0x01 ; ADDITION INSTEAD OF INCREMENT BTFSC _C ; HANDLES CARRY FLAG CORRECTLY ADDWF ACC+B5 ; carry for rounding BTFSC _C ADDWF ACC+B4 BTFSC _C ADDWF ACC+B3 BTFSS _C ; has rounding caused carryout? GOTO MUL32OK Regards, Josef

>Several months ago I have posted these corrections to the floating point >library: > >The following applies to the FP32_14.a16 library, you can probably locate >appropriate code segment in other libraries as well. I did not change any >labels, so compare them to the original code. Changes are commented in capitals. Thanks. This is the exactly the kind of post I was hoping for. Regarding the slow FP sqrt function: If you're doing FP on a pic, speed probably isn't a big concern. I'm certainly not defending slow code, but sometimes having slow code that works is more important than fast code that you don't have! Seriously, aren't most of the 300 cycles sqrt functions actually fixed point? I think all the clever sqrt routines I've seen are fixed point, if not integer, algorithms. thanks, newell

>Regarding the slow FP sqrt function: If you're doing FP on a pic, speed >probably isn't a big concern. I'm certainly not defending slow code, but >sometimes having slow code that works is more important than fast code that >you don't have! > >Seriously, aren't most of the 300 cycles sqrt functions actually fixed >point? I think all the clever sqrt routines I've seen are fixed point, if >not integer, algorithms. Probably fixed point (a lookup table + interpolation). On the other hand, improving efficiency of a floating point calculation based on polynomial approximation is quite feasible: y = a0 + a1*x + a2*x^2 + a3*x^3... You keep partial sum in one memory location and calculate an*x^n in another. After certain value of n>=N, the additional terms are small enough to be omitted, but this N also depends on x. An easy way is to compare binary exponents of the partial sum and current term (an*x^n). These exponents are stored in the first byte of the floating point number, biased by 0x80, (exponent 00 belongs to number 0.0). If you require say ten valid digits in your result, you perform the calculation until the exponent of the term is either by eleven or more smaller than the exponent of the partial sum or equal to zero (can't go smaller). It would require some four or five instructions each loop you can probably afford. The only problem is you have to dig thru the routine to find the place. If the original poster does not hurry, I would volunteer to make the improvement, than post the new sqrt function to web. Josef EraseMEeuroclassspam_OUTTakeThisOuTpha.pvtnet.cz

Dan Walkowski wrote: > > John Halleck said: > > > And don't forget that the sqrt routine chews up 3,000 some odd > > cycles, > > for a poor aproximation, when the exact result can be gotten in less > > than > > 200 cycles. > > > > > So where does one find some code that behaves as mentioned? Someone out > there could be a real hero by writing some trustworthy and useable math > routines.... http://www.interstice.com/~sdattalo/technical/software/pic/picsqrt.html Although this works only for 16 bit integers. Scott -- __o I buy pizza instead of gas. \< (*)/(*)