Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19765 > unrolled thread
| Started by | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| First post | 2013-02-16 07:35 -0800 |
| Last post | 2013-03-15 21:13 -0700 |
| Articles | 20 on this page of 105 — 21 participants |
Back to article view | Back to comp.lang.forth
Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-16 07:35 -0800
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-17 13:57 +0200
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-17 09:40 -0600
Re: Integer cosine function "Elizabeth D. Rather" <erather@forth.com> - 2013-02-17 07:51 -1000
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-17 19:06 +0200
Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-18 14:46 +0000
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-19 20:01 +0100
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-19 21:34 +0200
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-19 21:46 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-19 15:55 -0800
Re: Integer cosine function Coos Haak <chforth@hccnet.nl> - 2013-02-21 00:59 +0100
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-18 09:19 -0800
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-18 14:27 -0500
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-18 20:53 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-18 19:10 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-19 13:13 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-19 23:04 -0500
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-20 10:00 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:04 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-21 19:03 -0500
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 02:45 +0100
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-22 02:32 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 16:01 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 22:07 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 10:27 -0500
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 03:59 -0600
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-22 02:30 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 15:56 +0100
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-22 16:13 +0100
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 17:45 +0100
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-22 18:44 +0100
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 19:19 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 14:43 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-23 01:30 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 21:51 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 01:43 +0100
Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:55 +0000
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 21:01 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-25 23:22 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-26 15:11 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-27 08:05 -0500
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 22:14 -0500
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-27 22:56 -0500
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:37 -0500
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-03-07 13:12 -0500
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-28 08:00 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:38 -0500
Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-02-28 16:55 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:38 -0500
Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 11:08 +0000
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 03:39 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:49 -0500
Re: Integer cosine function stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-05 10:20 +0000
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 00:12 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-08 04:21 -0500
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:50 -0500
Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 07:16 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:56 -0500
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 00:24 -0800
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 07:34 -0800
Re: Integer cosine function Lars Brinkhoff <lars.spam@nocrew.org> - 2013-02-28 12:57 +0100
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 17:07 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-28 19:37 -0800
Re: Integer cosine function stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-01 10:56 +0000
Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-01 13:52 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 17:48 -0800
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-03-13 17:44 -0400
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:36 -0500
Re: Integer cosine function Elizabeth D Rather <erather@forth.com> - 2013-03-01 19:14 -1000
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-03-02 09:34 +0200
Re: Integer cosine function kenney@cix.compulink.co.uk - 2013-03-02 09:06 -0600
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-26 08:53 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-26 16:59 -0500
Re: Integer cosine function albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-27 00:52 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 04:07 -0500
Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-05 20:51 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 17:58 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-06 16:39 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 14:21 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 00:11 +0100
Re: Integer cosine function albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-06 23:44 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 16:24 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 01:59 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 19:48 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 16:22 +0100
Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-06 23:37 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 09:54 -0500
Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-05 21:03 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 15:59 -0800
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 16:38 -0800
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:07 -0600
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 19:39 +0100
Re: Integer cosine function "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:23 -1000
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:44 -0600
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 13:00 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-23 01:09 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-22 21:16 -0500
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-22 20:28 -0500
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-27 07:59 -0800
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-27 08:48 -0800
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-27 10:23 -0800
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-03-15 10:14 -0700
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-03-15 13:19 -0700
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-03-15 13:28 -0700
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-03-15 21:13 -0700
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-02-16 07:35 -0800 |
| Subject | Integer cosine function |
| Message-ID | <e9dccc41-1a28-438d-bfa9-cadfc703137f@googlegroups.com> |
Here's an integer cosine I just wrote that has pretty good precision. Testbench is included. I'm posting it here in case someone wants to add more transcendental functions or if I want to find it again in 20 years.
\ Cosine function in 32-bit ANS Forth
\ Angle input is 32-bit
\ Output range is 0 to +/-$7FFFFFFF
\ Accuracy is 28.7 bits, worst case error 10/2^32.
\ See Jack Ganssle's Guide to Approximations for FP C version.
HEX
6487ED51 CONSTANT C1 7FFFFFFF CONSTANT C2
80000001 CONSTANT C3 15555553 CONSTANT C4
FE93E947 CONSTANT C5 000D00BD CONSTANT C6
FFFFB61E CONSTANT C7 00000111 CONSTANT C8
VARIABLE X2
: ROUND ( d -- n ) \ round to nearest
80000000 0 D+ NIP
;
: TERM ( y w -- y' ) \ y*X2/2 + w
SWAP X2 @ M* D2* D2* D2* ROUND +
;
: COS1Q ( angle -- n ) \ 1st quadrant
C1 M* D2* D2* ROUND \ scale to pi/2 = $40000000
DUP M* NIP X2 !
C8 C7 TERM C6 TERM C5 TERM
C4 TERM C3 TERM C2 TERM
;
: COS ( angle -- n ) \ angle is 32-bit circle
DUP 0< IF INVERT THEN
DUP 40000000 AND IF INVERT
3FFFFFFF AND COS1Q NEGATE
ELSE COS1Q THEN
;
DECIMAL
1 [IF]
\ translate coefficients from
\ Jack Ganssle's Guide to Approximations.
\ also test for worst case error
REQUIRES FPMATH
VARIABLE TALLY
: FRAC ( r -- ) \ convert to 32-bit constants
TALLY @ 1 AND 0= IF CR THEN
$80000000 0 D>F F* 1 TALLY +!
TALLY @ 2 > IF \ they double as you go down
TALLY @ 2 - 0 DO F2* LOOP
THEN ." "
F>D HEX <# # # # # # # # # #> TYPE
." CONSTANT C" DECIMAL TALLY @ .
;
: SHOW ( -- ) CR \ Output coefficients to screen
1E0 FATAN FRAC
0.99999999999925182E0 FRAC
-0.49999999997024012E0 FRAC
0.041666666473384543E0 FRAC
-0.001388888418000423E0 FRAC
0.000024801040648456E0 FRAC
-0.000000275246963843E0 FRAC
0.000000001990785685E0 FRAC
;
\ Test sweeps through the circle to find the maximum error
\ On a typical PC, "20 WORST" tests a million points fast.
VARIABLE ERROR VARIABLE SPAN
DFVARIABLE ANGLE
HEX
: TEST1 ( i -- n ) 20 SPAN @ - LSHIFT COS ;
: TEST2 ( i -- n ) S>F ANGLE DF@ F* FCOS 7FFFFFFF S>F F* F>S ;
DECIMAL
: SETANGLE ( span -- )
1E0 FATAN 8E0 F* ( 2pi) 0 ?DO F2/ LOOP ANGLE DF! ;
: WORST ( n -- u ) \ Brute force sweep for worst estimate
DUP SPAN ! SETANGLE 0 ERROR !
1 SPAN @ LSHIFT 0 DO
I TEST1 I TEST2 - ABS
ERROR @ MAX ERROR !
LOOP
ERROR @ ;
[THEN]
[toc] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2013-02-17 13:57 +0200 |
| Message-ID | <17789018018434@frunobulax.edu> |
| In reply to | #19765 |
Brad Eckert <hwfwguy@gmail.com> writes Re: Integer cosine function > Here's an integer cosine I just wrote that has pretty good precision. > Testbench is included. I'm posting it here in case someone wants to add > more transcendental functions or if I want to find it again in 20 years. [..] If the latter, please rewrite for 64-bits (or more ;-) Of course, in another 20 years FP hardware will be standard. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-17 09:40 -0600 |
| Message-ID | <xqCdnSGb_dqYZ73MnZ2dnUVZ_rmdnZ2d@supernews.com> |
| In reply to | #19771 |
Marcel Hendrix <mhx@iae.nl> wrote: > Brad Eckert <hwfwguy@gmail.com> writes Re: Integer cosine function > >> Here's an integer cosine I just wrote that has pretty good precision. >> Testbench is included. I'm posting it here in case someone wants to add >> more transcendental functions or if I want to find it again in 20 years. > [..] > > If the latter, please rewrite for 64-bits (or more ;-) Really? A 32-bit angle gets you an accurate location within 10mm on the surface of the Earth. What will this cosine be calculating, I wonder. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-17 07:51 -1000 |
| Message-ID | <TsKdnRzd7_s9hbzMnZ2dnUVZ_j6dnZ2d@supernews.com> |
| In reply to | #19774 |
On 2/17/13 5:40 AM, Andrew Haley wrote: > Marcel Hendrix <mhx@iae.nl> wrote: >> Brad Eckert <hwfwguy@gmail.com> writes Re: Integer cosine function >> >>> Here's an integer cosine I just wrote that has pretty good precision. >>> Testbench is included. I'm posting it here in case someone wants to add >>> more transcendental functions or if I want to find it again in 20 years. >> [..] >> >> If the latter, please rewrite for 64-bits (or more ;-) > > Really? A 32-bit angle gets you an accurate location within 10mm on > the surface of the Earth. What will this cosine be calculating, I > wonder. Exactly. More bits can't buy you more resolution than your original measurements justify. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2013-02-17 19:06 +0200 |
| Message-ID | <07971618018434@frunobulax.edu> |
| In reply to | #19777 |
"Elizabeth D. Rather" <erather@forth.com> Re: Integer cosine function > On 2/17/13 5:40 AM, Andrew Haley wrote: >> Marcel Hendrix <mhx@iae.nl> wrote: >>> Brad Eckert <hwfwguy@gmail.com> writes Re: Integer cosine function >>> >>>> Here's an integer cosine I just wrote that has pretty good precision. >>>> Testbench is included. I'm posting it here in case someone wants to add >>>> more transcendental functions or if I want to find it again in 20 years. >>> [..] >>> >>> If the latter, please rewrite for 64-bits (or more ;-) >> >> Really? A 32-bit angle gets you an accurate location within 10mm on >> the surface of the Earth. What will this cosine be calculating, I >> wonder. > Exactly. More bits can't buy you more resolution than your original > measurements justify. My comment has nothing to do with precision/accuracy. Brad's code simply *doesn't work correctly* for the 64-bit and higher Forth's we'll have in 20 years, that's all. Look at the source to see why, it's instructive. -marcel
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-02-18 14:46 +0000 |
| Message-ID | <2013Feb18.154609@mips.complang.tuwien.ac.at> |
| In reply to | #19778 |
mhx@iae.nl (Marcel Hendrix) writes:
>My comment has nothing to do with precision/accuracy. Brad's code
>simply *doesn't work correctly* for the 64-bit and higher Forth's
>we'll have in 20 years, that's all.
We have had 64-bit Forths for at least 17 years (and I think PFE was
erlier then Gforth, so probably 18 or more).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-19 20:01 +0100 |
| Message-ID | <slrnki7mje.500.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19778 |
In comp.lang.forth, Marcel Hendrix wrote: > My comment has nothing to do with precision/accuracy. Brad's code > simply *doesn't work correctly* for the 64-bit and higher Forth's > we'll have in 20 years, that's all. Look at the source to see why, > it's instructive. What do you think about this then (the result given as a ratio): : power ( m n - m^n ) ?dup if 1 swap 0 do over * loop nip else drop 1 then ; : intCosinus14 ( n -- num denom ) 87178291200 over 43589145600 swap 2 power * - over 3632428800 swap 4 power * + over 121080960 swap 6 power * - over 2162160 swap 8 power * + over 24024 swap 10 power * - over 182 swap 12 power * + over 14 power - nip 87178291200 ; Yes, when "closing the circle" (around the 5-6 rad) it's losing accuracy. Anyway we could take advantage out of the fact, it's periodical function. -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2013-02-19 21:34 +0200 |
| Message-ID | <04691416018434@frunobulax.edu> |
| In reply to | #19826 |
Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes Re: Integer cosine function > In comp.lang.forth, Marcel Hendrix wrote: >> My comment has nothing to do with precision/accuracy. Brad's code >> simply *doesn't work correctly* for the 64-bit and higher Forth's >> we'll have in 20 years, that's all. Look at the source to see why, >> it's instructive. You didn't read Brad's code, did you? When I say 'doesn't work correctly for a 64-bit Forth', I mean that code like | : ROUND ( d -- n ) \ round to nearest | 80000000 0 D+ NIP | ; only works for a 32bit 2's complement Forth. I do not say that Brad's algorithm is wrong or inaccurate as such. > What do you think about this then (the result given as a ratio): > > : power ( m n - m^n ) ?dup if 1 swap 0 do over * loop nip else drop 1 then ; Use Horner's rule. Erase your post before somebody reads it. > : intCosinus14 ( n -- num denom ) > 87178291200 > over 43589145600 swap 2 power * - over 3632428800 swap 4 power * + > over 121080960 swap 6 power * - over 2162160 swap 8 power * + > over 24024 swap 10 power * - over 182 swap 12 power * + > over 14 power - > nip 87178291200 > ; You're using n^14, without scaling. This needs a 131 bit Forth. > Yes, when "closing the circle" (around the 5-6 rad) it's losing accuracy. > Anyway we could take advantage out of the fact, it's periodical function. For simulation and graphics, the argument can be many times PI. Better to work in square degrees (400 degrees = 2*pi). -marcel
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2013-02-19 21:46 +0100 |
| Message-ID | <slrnki7snr.9es.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #19828 |
In comp.lang.forth, Marcel Hendrix wrote: > You're using n^14, without scaling. This needs a 131 bit Forth. Actually... how did you calculate it? -- It's us, the scobs.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-02-19 15:55 -0800 |
| Message-ID | <034f2d6d-26f1-40e5-9be1-9d6530c39170@c6g2000yqh.googlegroups.com> |
| In reply to | #19826 |
On Feb 19, 12:01 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com> wrote: > Yes, when "closing the circle" (around the 5-6 rad) it's losing accuracy. > Anyway we could take advantage out of the fact, it's periodical function. That is why the slide-rule has a separate scale for small angles. One thing about slide-rules, you do get to see precision visually (how closely the marks are scrunched together) --- although because the thing is logarithmic, even with a linear scale they are going to be closer together on one side than the other, so you have to take that into account too.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2013-02-21 00:59 +0100 |
| Message-ID | <1sukaw7yxafzh.zufy4j55zdlt.dlg@40tude.net> |
| In reply to | #19835 |
Op Tue, 19 Feb 2013 15:55:51 -0800 (PST) schreef Hugh Aguilar: > On Feb 19, 12:01 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com> > wrote: >> Yes, when "closing the circle" (around the 5-6 rad) it's losing accuracy. >> Anyway we could take advantage out of the fact, it's periodical function. > > That is why the slide-rule has a separate scale for small angles. > > One thing about slide-rules, you do get to see precision visually (how > closely the marks are scrunched together) --- although because the > thing is logarithmic, even with a linear scale they are going to be > closer together on one side than the other, so you have to take that > into account too. The L-scale is logarithmic, but in reality linear. There is no difference in spacing at the left vs. the right. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-02-18 09:19 -0800 |
| Message-ID | <89bb98a3-8bb7-4fc3-a0f6-00d3a7f2754e@googlegroups.com> |
| In reply to | #19777 |
On Sunday, February 17, 2013 10:51:28 AM UTC-7, Elizabeth D. Rather wrote: > > Exactly. More bits can't buy you more resolution than your original > measurements justify. > It's used for building tables in a signal processing application. Looking for low noise. I think most MCUs will still be 32-bit or less in 20 years. The 8051 still hasn't gone away.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-18 14:27 -0500 |
| Message-ID | <kftv9j$nbj$1@dont-email.me> |
| In reply to | #19799 |
On 2/18/2013 12:19 PM, Brad Eckert wrote: > On Sunday, February 17, 2013 10:51:28 AM UTC-7, Elizabeth D. Rather wrote: >> >> Exactly. More bits can't buy you more resolution than your original >> measurements justify. >> > It's used for building tables in a signal processing application. Looking for low noise. > > I think most MCUs will still be 32-bit or less in 20 years. The 8051 still hasn't gone away. 20 years is a *long* time. I bet there are a lot fewer 4 bit processors used now than there were even just 10 years ago. I seem to recall a forecast somewhere that did show 8 bit MCUs dropping in volume over the years. But I doubt the 32 bit units will be edged out by 64 or 128 bit processors. Unless the embedded apps have to go 128 bits to be able to address the on chip memory. lol -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-18 20:53 +0100 |
| Message-ID | <kfu0r6$96g$1@online.de> |
| In reply to | #19799 |
Brad Eckert wrote: > I think most MCUs will still be 32-bit or less in 20 years. The 8051 still > hasn't gone away. Yes, but even 10 years ago, when one of our customers wanted an 8051 "because we always have used that", it was just a conservative, uninformed decision, not the best choice. The people who had been behind that decisions have all retired some years ago. The chip is still in production. That's how conservative decisions work: They are made by people who decide once for their entire career. These people need to retire to make different decisions, and they will be done, and yes, probably again for the entire career. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-02-18 19:10 -0800 |
| Message-ID | <195f2b84-892e-468d-8b3d-44fe137e0082@xb8g2000pbc.googlegroups.com> |
| In reply to | #19802 |
On Feb 18, 12:53 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > Brad Eckert wrote: > > I think most MCUs will still be 32-bit or less in 20 years. The 8051 still > > hasn't gone away. > > Yes, but even 10 years ago, when one of our customers wanted an 8051 > "because we always have used that", it was just a conservative, uninformed > decision, not the best choice. The people who had been behind that > decisions have all retired some years ago. The chip is still in production. > > That's how conservative decisions work: They are made by people who decide > once for their entire career. These people need to retire to make different > decisions, and they will be done, and yes, probably again for the entire > career. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself"http://bernd-paysan.de/ I know a guy in his 20s (he was working through the labor agency at a landscaping job last summer, and so was I) who had graduated from one of those expensive trade schools to learn to be an electrical technician, and they taught entirely from the 8051. He seems to know how to troubleshoot faulty boards, and that is the skill that he is proud of, but he is going to have to learn the new chips to get a job. A lot of times when you apply for work there is an HR girl who asks: "How many years of experience do you have with X technology?" She doesn't have the slightest idea what X or Y or anything else is, but her job is just to weed out all of the wanna-bees who just apply for every job posted no matter what it is. That was always a big problem for me because X was never "Forth" --- I remember back in the late 1990s shortly after leaving Testra that I was even rejected for a QBasic programming job because I had zero years of experience in it, and nobody seemed to consider my having written MFX to be relevant to general programming --- I was applying for the QBasic job even though I knew that it would be a dead-end job, because I realized that I had zero chance of getting a C job with my Forth background (because C programmers think that Forth programmers are profoundly incompetent) --- I ended up getting a job as an IBM370 assembly-language programmer, which is also a dead-end job (they apparently couldn't find anybody with any experience who was not in the grave or the old- folks home, so they hired me and I learned it on the fly). It is more about being "standard" and "up-to-date" than about making the "best choice."
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-19 13:13 +0100 |
| Message-ID | <kfvq9k$u9h$1@online.de> |
| In reply to | #19808 |
Hugh Aguilar wrote: > It is more about being "standard" and "up-to-date" than about making > the "best choice." Someone who's microcontroller experience is limited to the 8051 might be "standard", but he's certainly *not* "up-to-date". And well, if a company uses HR to decide technical competence, the company is probably full of idiots already. The HR is there to protect the idiots in the company from newcomers who would point out that they are naked. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-19 23:04 -0500 |
| Message-ID | <kg3fir$sej$6@dont-email.me> |
| In reply to | #19808 |
On 2/18/2013 10:10 PM, Hugh Aguilar wrote: > A lot of times when you apply for work there is an HR girl who asks: > "How many years of experience do you have with X technology?" She > doesn't have the slightest idea what X or Y or anything else is, but > her job is just to weed out all of the wanna-bees who just apply for > every job posted no matter what it is. Uh, is there some reason why it is always an HR "girl"? Are the guys all in engineering or something? Only girls are HR people? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Gary Bergstrom <g.bergstrom@ieee.org> |
|---|---|
| Date | 2013-02-20 10:00 -0800 |
| Message-ID | <7532b5f1-3390-4449-b16d-ff147eb50d76@googlegroups.com> |
| In reply to | #19802 |
On Monday, February 18, 2013 2:53:09 PM UTC-5, Bernd Paysan wrote: > Brad Eckert wrote: > > I think most MCUs will still be 32-bit or less in 20 years. The 8051 still > > hasn't gone away. > Yes, but even 10 years ago, when one of our customers wanted an 8051 > "because we always have used that", it was just a conservative, uninformed > decision, not the best choice. The people who had been behind that > decisions have all retired some years ago. The chip is still in production. > Bernd Paysan > In the embedded world you should look at how many new chips have an embedded 8051 in them for control. It's hard to spin your own chips using a "informed decision". Easier to buy what is cheap and available. Maybe the vendors will start to switch to some better choice, but I see more and more embedded 8051's every month. Gary Bergstrom
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-21 13:04 +0100 |
| Message-ID | <kg52g7$abo$1@online.de> |
| In reply to | #19850 |
Gary Bergstrom wrote: > In the embedded world you should look at how many new chips have an > embedded 8051 in them for control. It's hard to spin your own chips using > a "informed decision". Easier to buy what is cheap and available. Maybe > the vendors will start to switch to some better choice, but I see more and > more embedded 8051's every month. Yes, this was a full custom chip we did, and the customer wanted an embedded 8051, which did cost him another $100k (IP only, not to mention the area overhead). Well, our next customer was happy to choose the b16 over an 8051, because he did only specify that there need to be some "state machine" inside for controlling, and didn't require any particular implementation. It's this kind of micro-management which causes "standard" parts like the 8051 to be everywhere, even when there's no need for it. We had offered that 8051 customer that we can do the firmware, too, which would have meant that we could go to market more quickly. The customer took almost 2 years to develop the firmware themselves (well, it was all outsourced to contractors...), getting the company I worked for in financial troubles, because we didn't get our investment back in due time. The next customer wasn't really much better. Though he did allow us to use the b16, he did insist on a ROM for the program, which meant the turnaround times for development were looooong. Most decisions people make are irational personal taste decisions. Blaise Pascal already noticed that a few centuries ago. It's just that way. My personal taste is that the 8051 is utter crap. Though there are worse things than the 8051 ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-21 19:03 -0500 |
| Message-ID | <kg6cjl$2he$1@dont-email.me> |
| In reply to | #19870 |
On 2/21/2013 7:04 AM, Bernd Paysan wrote: > > Most decisions people make are irational personal taste decisions. Blaise > Pascal already noticed that a few centuries ago. It's just that way. My > personal taste is that the 8051 is utter crap. Though there are worse > things than the 8051 ;-). I had not heard that about Pascal. It seems to be true though and contrary to one of the basic premises of Keynesian economic theory that everyone bases their decisions on "perfect knowledge" so as to maximize their utility. Obviously they may be what they think they are doing, but they seldom have "perfect knowledge" and often don't really make good decisions. Even corporations can be run by the "herd" mentality. Look how many times all the companies in a given area start doing the same things even when they turn out poorly. Did they all just happen to make the same bad decision? Or were they all following each other as in a herd? Once I read that insurance companies don't like to stand out from the crowd because that is unnecessary exposure to risk. If they all share in a major loss, none are more likely than the others to be devastated by it. So insurance companies don't want to dominate in any geographic or business areas. -- Rick
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web