Truncated match.
PICList
Thread
'Floating point app notes'
1998\02\09@214802
by
Scott Newell
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
1998\02\10@104055
by
John Halleck
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.
> [...]
1998\02\10@140410
by
Morgan Olsson
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_OUTmrtTakeThisOuT
iname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331 /
1998\02\10@143844
by
Dan Walkowski
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....
Dan
1998\02\10@190632
by
Sean Breheny
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
1998\02\10@192011
by
Russell McMahon
Perhaps you'd like to post the improved code?
(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.
>
>> [...]
>
1998\02\10@192018
by
Russell McMahon
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}
1998\02\10@203828
by
John Halleck
On Wed, 11 Feb 1998, Russell McMahon wrote:
> Date: Wed, 11 Feb 1998 09:06:58 +1300
> From: Russell McMahon <apptech
KILLspamclear.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.
> >
> >> [...]
> >
>
1998\02\11@230827
by
Harold Hallikainen
The latest Embedded Systems Programming magazine has a large article on
computing square roots.
Harold
_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
1998\02\12@050633
by
Josef Hanzal
|
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
1998\02\12@204150
by
Scott Newell
>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
1998\02\16@123311
by
Josef Hanzal
|
>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_OUT
TakeThisOuTpha.pvtnet.cz
1998\02\19@155758
by
sdattalo
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. \<
(*)/(*)
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- Today
- New search...