Searching \ for 'Floating point app notes' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=floating+point+app
Search entire site for: 'Floating point app notes'.

Truncated match.
PICList Thread
'Floating point app notes'
1998\02\09@214802 by Scott Newell

flavicon
face
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

flavicon
face
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

picon face
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_OUTmrtTakeThisOuTspaminame.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\02\10@143844 by Dan Walkowski

flavicon
face
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

face picon face
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
.....shb7KILLspamspam@spam@cornell.edu
Phone(USA): (607) 253-0315

1998\02\10@192011 by Russell McMahon

picon face
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

picon face
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

flavicon
face
On Wed, 11 Feb 1998, Russell McMahon wrote:

> Date: Wed, 11 Feb 1998 09:06:58 +1300
> From: Russell McMahon <apptechspamKILLspamclear.net.nz>
> To: .....PICLISTKILLspamspam.....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}

1998\02\11@230827 by Harold Hallikainen

picon face
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

flavicon
face
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

flavicon
face
>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

flavicon
face
>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_OUTspamTakeThisOuTpha.pvtnet.cz

1998\02\19@155758 by sdattalo

face
flavicon
face
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...