Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54229 > unrolled thread

embedded forth

Back to article view | Back to comp.lang.forth

Contents

  embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-21 11:27 -0800
    Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-21 11:31 -0800
    Re: embedded forth stephen@mpeforth.com - 2017-01-22 00:52 -0800
    Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 17:09 +0000
      Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 09:43 -0800
        Re: embedded Forth stephen@mpeforth.com - 2017-01-22 12:19 -0800
        Re: embedded Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-22 21:25 +0100
        Re: embedded Forth john <anon@example.com> - 2017-01-22 21:04 +0000
          Re: embedded Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-01-22 12:30 -1000
          Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 20:45 -0800
        Re: embedded Forth stephen@mpeforth.com - 2017-01-22 14:08 -0800
          Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 14:55 -0800
            Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 20:41 -0800
              Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 21:19 -0800
        Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 21:36 -0800
          Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:09 -0800
            Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 04:15 -0500
              Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 08:41 -0800
                Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 14:32 -0500
                  Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 11:53 -0800
                    Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 15:10 -0500
                Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 14:34 -0800
                  Re: embedded Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:14 -0600
          Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 03:43 -0500
            Re: embedded Forth john <anon@example.com> - 2017-01-23 10:32 +0000
            keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 08:58 -0300
              Re: keep secrets (was Re: embedded Forth) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-23 07:47 -0500
                Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:18 -0300
                  Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:15 -0500
              Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 14:38 -0500
                Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:43 -0300
                  Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:48 -0500
                    Re: keep secrets (was Re: embedded Forth) "Elizabeth D. Rather" <erather@forth.com> - 2017-01-23 16:30 -1000
                      Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 22:23 -0500
    Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-22 13:44 -0500
      Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 13:38 -0800
        Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 00:45 -0500
          Re: embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:44 -0800
            Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 00:48 -0800
            Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 03:51 -0500
        Re: embedded forth john <anon@example.com> - 2017-01-23 10:02 +0000
      Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-23 09:01 +0000
        Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-23 13:05 +0100
          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 14:40 -0500
            Re: embedded forth Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:12 -0800
            Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:38 +0100
              Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-24 19:51 -0500
                Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-25 11:34 +0100
                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-25 22:13 -0500
                    Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-26 11:36 +0100
                      Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:07 -0500
                Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-26 00:19 -0800
                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:15 -0500
                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 13:08 -0800
                      Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 17:54 -0500
                        Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-27 15:29 -0800
                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 16:28 -0800
                          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 23:58 -0500
                            Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 11:58 -0800
                              Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 15:36 -0500
                                Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 15:05 -0800
                                  Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-28 15:57 -0800
                                    Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
                                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 09:53 -0800
                                      Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-29 19:32 +0100
                                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:53 -0800
                                          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 01:10 -0500
                                            Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 23:11 -0800
                                              Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-29 23:34 -0800
                                                Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:42 +0100
                                              Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:36 +0100
                                                Re: embedded forth ctmalan@gmail.com - 2017-01-30 11:02 -0800
                                                  Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 11:04 -0800
                                                    Re: embedded forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:34 -0600
                                                Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:15 -0800
                                              Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 10:15 -0500
                                                Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:20 -0800
                                                  Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 14:09 -0800
                                                    Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-31 03:04 +0100
                                                      Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 20:19 -0800
                                                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 17:10 -0500
                                                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 14:38 -0800
                                                      Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 23:09 -0500
                                                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-31 09:32 -0800
                                                          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 18:22 -0500
                                                            Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:46 -0800
                                                              Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:11 -0500
                                              Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 01:30 -0500
                                                Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-12 10:21 -0800
                                                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 19:37 -0500
                                                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-14 13:26 -0800
                                                Re: embedded forth Gary Bergstrom <forthprgrmr@gmail.com> - 2017-02-14 11:36 -0800
                                                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-14 18:13 -0500
                                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
                                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 10:20 -0800
                                      Re: embedded forth Cecil Bayona <cbayona@cbayona.com> - 2017-01-29 12:38 -0600
                                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:49 -0800
                                      Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-04 04:22 -0500
                                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-04 17:54 -0800
                                          Re: embedded forth hughaguilar96@gmail.com - 2017-02-04 20:26 -0800
                                            Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-05 07:53 -0800
                                              Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:08 -0800
                                                Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:39 -0800
                                                  Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 06:46 -0800
                                                  Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-13 19:17 -0800
                                                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 06:23 -0800
                                                      Re: embedded forth hughaguilar96@gmail.com - 2017-02-15 11:09 -0800
                                                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 15:24 -0800
                                                          Re: embedded forth jkn_gg@nicorp.f9.co.uk - 2017-02-16 09:49 -0800
                                                            Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 09:12 -0800
                                                            Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-17 12:47 -0800
                                                              Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 16:18 -0800
                                                      Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-16 08:43 -0800
                                                Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 20:47 +0000
                                                  Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 13:36 -0800
                                                    Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 23:18 +0000
                                                      Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:10 -0800
                                                        Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-06 11:12 +0000
                                                      Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:15 -0800
                                                        Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 22:45 -0800
                                                          Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-06 12:04 +0100
                                                Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 03:08 -0800
                                                  Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 06:39 -0500
                                                    Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 07:15 -0800
                                                      Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 15:49 -0500
                                                        Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:14 -0800
                                                          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:19 -0500
                                                            Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 03:48 -0800
                                          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-05 16:08 -0500
                                            Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-07 21:59 -0500
                        Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 11:10 +0100
                          Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 06:15 -0500
                            Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:48 +0100
                              Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 14:37 -0500
                          Re: embedded forth mhx@iae.nl - 2017-01-28 07:48 -0800
                            Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:53 +0100
                              Re: embedded forth mhx@iae.nl - 2017-01-28 15:49 -0800
          Re: embedded forth "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:46 -0300

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#54500

> I think you are still not getting it, but I can't tell for sure.  The 
> point is that either the CORDIC or a multiplier uses pretty much the 
> same resources if designed in the fabric.  Don't focus on one 
> insignificant part (the shifting which is always free in an FPGA).  What 
> is important is what is done with the data after it is shifted.

Please specify. Do you mean approach, based on sin(a+b)?
If so, we use sin(a+b) = sin(a)*cos(b) + cos(a)*sin(b), and this  require multiplication of sin and cos values. Is it what you talking about?
 
> Both the multiplier and the CORDIC can be done time sequentially using 
> logic for one layer of operation or can be pipelined with N layers of 
> logic and registers producing a result on every clock cycle.

We need to compare algorithm with algorithm and implementation with implementation. CORDIC is an implementation, where sequental applying of sin(a+b) formulae is an algorithm. Multiplication is an implementation. What algorithm you use?

> >  This is not too much resources for serious system. For example,
> > 32-bit sin/cos use 403 LUTs in word serial and 3411 in parallel mode.
> > For Kintex-7, the ratio of LUT/DSP is about 200-300.
> 
> That is a pretty large usage.  I can do the same thing using a handful 
> of multipliers.  In 403 LUTs I can build a CPU.  In 3400 LUTs I can 
> build a RISC pipelined CPU with advanced features.

This corresponds with what I know. However, area itself is not an indicator. We need to know what else is located inside FPGA, and what resources are most important to save. With several approaches we can consider a workaround when certain type of FPGA resources is running low.
 
> The FPGAs I use in a product that generate sine waves (among other 
> things) has a total of 3000 LUTs.  Of course it only runs at 8 ksps and 
> these are 16 bit samples.

What about performance index of you approach? For example, (bits * samples_per_second)/LUT. We can calculate this from Xilinx table. In general, if FPGA is not very large, we may start from serial algorithms.

> > Simplest way based on the wide phase accumulator and control the
> > phase increment value. Also, you can change base frequency of overall
> > DSP path in hardware using dynamic reconfiguration port in Clock
> > Management Tile (I mean Xilinx chips).
> 
> That sounds like any other DDS.   You either change the phase step or 
> change the reference frequency.  So the phase step size can be changed 
> on the fly for frequency modulation?

Yes, with control registers. If we write phase <= phase + phase_delta; it is possible to connect phase_delta register to CPU system bus (and directly control phase register on the fly too). We use Forth CPU for control. 

Task of such kind are very informative. Forth CPU allows to connect devices very easy with no overhead on complex system buses like AXI. In this case, it is not so important, what is the performance or area of Forth CPU, because it used for real task with it's own valuability. I'm sure you can imagine the power of hardware module, running on FPGA. With any CPU it's functionality is greatly improving because of reconfiguration capabilities. With Forth CPU we can additionally adapt this system to the man who works with hardware and tightly connect CPU to hardware.

[toc] | [prev] | [next] | [standalone]

#54503

Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
> Please specify. Do you mean approach, based on sin(a+b)?
> If so, we use sin(a+b) = sin(a)*cos(b) + cos(a)*sin(b), and this
> require multiplication of sin and cos values. Is it what you talking
> about?

I think the idea is b is small, so maybe the multiplication can be
approximated by addition, i.e. treat sin(b)=b and cos(b)=1.

> [Rick:]
>> In 403 LUTs I can build a CPU.

Rick, can your 403 LUT cpu do sin/cos as quickly as 403 LUT of Cordic? 

[toc] | [prev] | [next] | [standalone]

#54510

On 1/28/2017 6:57 PM, Paul Rubin wrote:
> Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>> Please specify. Do you mean approach, based on sin(a+b)?
>> If so, we use sin(a+b) = sin(a)*cos(b) + cos(a)*sin(b), and this
>> require multiplication of sin and cos values. Is it what you talking
>> about?
>
> I think the idea is b is small, so maybe the multiplication can be
> approximated by addition, i.e. treat sin(b)=b and cos(b)=1.
>
>> [Rick:]
>>> In 403 LUTs I can build a CPU.
>
> Rick, can your 403 LUT cpu do sin/cos as quickly as 403 LUT of Cordic?

How fast can a CORDIC be done?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54521

воскресенье, 29 января 2017 г., 2:57:41 UTC+3 пользователь Paul Rubin написал:
> Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
> > Please specify. Do you mean approach, based on sin(a+b)?
> > If so, we use sin(a+b) = sin(a)*cos(b) + cos(a)*sin(b), and this
> > require multiplication of sin and cos values. Is it what you talking
> > about?
> 
> I think the idea is b is small, so maybe the multiplication can be
> approximated by addition, i.e. treat sin(b)=b and cos(b)=1.

This causing a big difference. It is very approximating approach.

[toc] | [prev] | [next] | [standalone]

#54524

In article <6415800d-9ed0-4eef-afcf-6291de9a1ef3@googlegroups.com>,
Ilya Tarasov  <ilya74.tarasov@gmail.com> wrote:
>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 29 =D1=
>=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2017 =D0=B3., 2:57:41 UTC+3 =D0=BF=D0=BE=
>=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Paul Rubin =D0=
>=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>> Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>> > Please specify. Do you mean approach, based on sin(a+b)?
>> > If so, we use sin(a+b) =3D sin(a)*cos(b) + cos(a)*sin(b), and this
>> > require multiplication of sin and cos values. Is it what you talking
>> > about?
>>=20
>> I think the idea is b is small, so maybe the multiplication can be
>> approximated by addition, i.e. treat sin(b)=3Db and cos(b)=3D1.
>
>This causing a big difference. It is very approximating approach.

For small b the above becomes
sin(a)*(1-b**2) + cos(a)*b
sin(a) +b*(cos(a)-b*sin(a))

Under no circumstances the coefficient of b can be substantially greater
than one so there are no numerical problems in sight.
The result will not suffer more than the usual rounding errors.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54530

> >This causing a big difference. It is very approximating approach.
> 
> For small b the above becomes
> sin(a)*(1-b**2) + cos(a)*b
> sin(a) +b*(cos(a)-b*sin(a))
> 
> Under no circumstances the coefficient of b can be substantially greater
> than one so there are no numerical problems in sight.
> The result will not suffer more than the usual rounding errors.

This is better approximation, but this just extend the area where results are quite good. Anyway, many ways to calculate sin/cos may coexist to choose optimal for certain task. We don't must avoid exact algorithms just because they require too muc resources.

[toc] | [prev] | [next] | [standalone]

#54535

On 1/29/2017 2:53 PM, Ilya Tarasov wrote:
>>> This causing a big difference. It is very approximating approach.
>>
>> For small b the above becomes
>> sin(a)*(1-b**2) + cos(a)*b
>> sin(a) +b*(cos(a)-b*sin(a))
>>
>> Under no circumstances the coefficient of b can be substantially greater
>> than one so there are no numerical problems in sight.
>> The result will not suffer more than the usual rounding errors.
>
> This is better approximation, but this just extend the area where results are quite good. Anyway, many ways to calculate sin/cos may coexist to choose optimal for certain task. We don't must avoid exact algorithms just because they require too muc resources.

I don't know why you label this an approximation.  The level of accuracy 
is controlled by the tradeoff of how many of the total phase bits you 
assign to a and b.  Any level of accuracy required can be obtained.  You 
need to appreciate fully how close to a straight line the small section 
of a sine function is over very short angles.  It is not at all hard to 
get the accuracy within a single lsb.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54537

 
> I don't know why you label this an approximation.  The level of accuracy 
> is controlled by the tradeoff of how many of the total phase bits you 
> assign to a and b.  Any level of accuracy required can be obtained.  You 
> need to appreciate fully how close to a straight line the small section 
> of a sine function is over very short angles.  It is not at all hard to 
> get the accuracy within a single lsb.

Because of 'for small b'. This is a limitation. Approximation is not a disadvantage by default, but we may face a problem attempting to improve precision. Exact formula don't require any kind of improvement, because it provide any accuracy by default. If it is not exact, we must always answer a question 'how small b must be to obtain desired accuracy?'. Also, different ways to approximation may be applied - what about playing with polynom order?

[toc] | [prev] | [next] | [standalone]

#54538

Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
> If it is not exact, we must always answer a question 'how small b must
> be to obtain desired accuracy?'. 

Why is that a problem?  The math is well known and not complicated.  And
you can choose the size of b by making big enough lookup tables for a.

> Also, different ways to approximation may be applied - what about
> playing with polynom order?

That's also worthwhile--adding more terms slows things down, but you can
move the coefficients around to control the minimax error over an
interval, generally doing better than the Taylor series of the same
order whose error is worst at one end of the interval.  This isn't my
thing but the Wikipedia article on Chebychev polynomials looks like a
good place to start.

[toc] | [prev] | [next] | [standalone]

#54541

In article <87o9ypyp9n.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>> If it is not exact, we must always answer a question 'how small b must
>> be to obtain desired accuracy?'.
>
>Why is that a problem?  The math is well known and not complicated.  And
>you can choose the size of b by making big enough lookup tables for a.
>
>> Also, different ways to approximation may be applied - what about
>> playing with polynom order?
>
>That's also worthwhile--adding more terms slows things down, but you can
>move the coefficients around to control the minimax error over an
>interval, generally doing better than the Taylor series of the same
>order whose error is worst at one end of the interval.  This isn't my
>thing but the Wikipedia article on Chebychev polynomials looks like a
>good place to start.

On my site there is a ubasic program that will calculates
Chebychev polynomials for functions that you have a prototype for
that calculates values in sufficient precision: dminmax.ub.

WARNING: those polynomials fare badly where there are poles nearby
in the complex plane, such as the arctangent.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54540

In article <e8b3a38a-d6b7-41b3-a760-fe07881bdf17@googlegroups.com>,
Ilya Tarasov  <ilya74.tarasov@gmail.com> wrote:
>=20
>> I don't know why you label this an approximation.  The level of accuracy=
>=20
>> is controlled by the tradeoff of how many of the total phase bits you=20
>> assign to a and b.  Any level of accuracy required can be obtained.  You=
>=20
>> need to appreciate fully how close to a straight line the small section=
>=20
>> of a sine function is over very short angles.  It is not at all hard to=
>=20
>> get the accuracy within a single lsb.
>
>Because of 'for small b'. This is a limitation. Approximation is not a disa=
>dvantage by default, but we may face a problem attempting to improve precis=
>ion. Exact formula don't require any kind of improvement, because it provid=
>e any accuracy by default. If it is not exact, we must always answer a ques=
>tion 'how small b must be to obtain desired accuracy?'. Also, different way=
>s to approximation may be applied - what about playing with polynom order?

You're fundamentally mistaken. The small angle is only assumed to
analyse rounding errors. Mathematically the formula is exact.
If a represents degrees and b represents minutes, all angles that represent
whole minutes can be calculated mathematically exact.
There is a table needed for the sin and cosine of 0..90 degress and
for 0..60 minutes.
Instead one could use a table for all seconds angles up to one degree,
which require 3600 entries. Now we have the cos and sine for all
angles that are an exact multiple of seconds.

I'm sure that you can interpolate linearly with an arc second, but I'm
too lazy too calculate that for you.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54551

On Monday, 30 January 2017 13:37:30 UTC+2, Albert van der Horst  wrote:
> >=20
> >> I don't know why you label this an approximation.  The level of accuracy=
> >=20
> >> is controlled by the tradeoff of how many of the total phase bits you=20
> >> assign to a and b.  Any level of accuracy required can be obtained.  You=
> >=20
> >> need to appreciate fully how close to a straight line the small section=
> >=20
> >> of a sine function is over very short angles.  It is not at all hard to=
> >=20
> >> get the accuracy within a single lsb.
> >
> >Because of 'for small b'. This is a limitation. Approximation is not a disa=
> >dvantage by default, but we may face a problem attempting to improve precis=
> >ion. Exact formula don't require any kind of improvement, because it provid=
> >e any accuracy by default. If it is not exact, we must always answer a ques=
> >tion 'how small b must be to obtain desired accuracy?'. Also, different way=
> >s to approximation may be applied - what about playing with polynom order?
> 
> You're fundamentally mistaken. The small angle is only assumed to
> analyse rounding errors. Mathematically the formula is exact.
> If a represents degrees and b represents minutes, all angles that represent
> whole minutes can be calculated mathematically exact.
> There is a table needed for the sin and cosine of 0..90 degress and
> for 0..60 minutes.
> Instead one could use a table for all seconds angles up to one degree,
> which require 3600 entries. Now we have the cos and sine for all
> angles that are an exact multiple of seconds.
> 
> I'm sure that you can interpolate linearly with an arc second, but I'm
> too lazy too calculate that for you.
> 
> Groetjes Albert
> -- 
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

For very small angles sin x = x (radians) and cos x = 1.

There is also a Newton method for calculating sin and cos.

c-:

[toc] | [prev] | [next] | [standalone]

#54552

ctmalan@gmail.com writes:
> There is also a Newton method for calculating sin and cos.

If you have division, rational approximations can do better than
polynomials of similar size, especially around complex poles as Albert
mentions.

[toc] | [prev] | [next] | [standalone]

#54571

Paul Rubin <no.email@nospam.invalid> wrote:
> ctmalan@gmail.com writes:
>> There is also a Newton method for calculating sin and cos.
> 
> If you have division, rational approximations can do better than
> polynomials of similar size, especially around complex poles as
> Albert mentions.

Really?  For sin and cos?  I'm looking at Hart et al and for sin I see
10.67 digits for a degree-5 polynomial and and 10.94 digits for a
degree 3/degree 2 ratio.  Division is *expensive*, but multiplication
these days is often very cheap.

Andrew.

[toc] | [prev] | [next] | [standalone]

#54554

> You're fundamentally mistaken. The small angle is only assumed to
> analyse rounding errors. Mathematically the formula is exact.
> If a represents degrees and b represents minutes, all angles that represent
> whole minutes can be calculated mathematically exact.
> There is a table needed for the sin and cosine of 0..90 degress and
> for 0..60 minutes.
> Instead one could use a table for all seconds angles up to one degree,
> which require 3600 entries. Now we have the cos and sine for all
> angles that are an exact multiple of seconds.

You are trying to retell me a page from my book :)
 
> I'm sure that you can interpolate linearly with an arc second, but I'm
> too lazy too calculate that for you.

I was not so lazy and calculate seconds when compare it to interpolation. Error is small, but not zero. With seconds, we will have 90 degrees + 60 minutes + 60 seconds table, but 90*60*60 combinations. We can repeat this many times. Combination of tables, angle rotation and interpolation is working but we need to know how exactly.

[toc] | [prev] | [next] | [standalone]

#54544

On 1/30/2017 2:11 AM, Ilya Tarasov wrote:
>
>> I don't know why you label this an approximation.  The level of accuracy
>> is controlled by the tradeoff of how many of the total phase bits you
>> assign to a and b.  Any level of accuracy required can be obtained.  You
>> need to appreciate fully how close to a straight line the small section
>> of a sine function is over very short angles.  It is not at all hard to
>> get the accuracy within a single lsb.
>
> Because of 'for small b'. This is a limitation. Approximation is not a disadvantage by default, but we may face a problem attempting to improve precision. Exact formula don't require any kind of improvement, because it provide any accuracy by default. If it is not exact, we must always answer a question 'how small b must be to obtain desired accuracy?'. Also, different ways to approximation may be applied - what about playing with polynom order?

I don't understand what you are going on about.  This will do the job to 
any level of accuracy required.  Are you saying you don't like thinking 
about your work?  What you call approximation, I call engineering.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54555

> I don't understand what you are going on about.  This will do the job to 
> any level of accuracy required.  Are you saying you don't like thinking 
> about your work?  What you call approximation, I call engineering.

Engineering is a way to solve a task, but task must be stated first. Let's think about angle rotating. Ok, we have a way to calculate sin(a+b), so we can represent any angle as a sum of several angles, with sin and cos values listed in a table. What is an optimal way to choose that angles? From the first look, we may list degrees, minutes and seconds, but is it optimal?

[toc] | [prev] | [next] | [standalone]

#54556

Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
> From the first look, we may list degrees, minutes and seconds, but is
> it optimal?

It's convenient, so the question then is whether it's close enough.

Optimal involves non-uniform placement of the interpolation points,
e.g. at the so-called Chebychev nodes according to Wikipedia.  I'd
expect that with non-optimal placement, you can still get the same
accuracy by using more points.  That seems ok to me if you have enough
memory for the bigger tables.

Using naive deg/min/sec interpolation (see below) I get a max error of
about 1.56e-4 which is well above 1 ULP in single precision.  I think
that can be improved by just moving the interpolation point slightly.
There's too stuff going on here at the moment for me to figure that out
right now, but this is a start.

================================================================

: dms.1 ( f:x -- f:int f:frac ) fdup f>s s>f ftuck f- ;
: f>dms ( F:degrees -- F:degrees F:minutes F:seconds )
    dms.1 60e f* dms.1 60e f* dms.1 f+ ;

: dms>f ( F:d F:m F:s -- F:dd )    60e f/ f+ 60e f/ f+ ;
: deg>rad ( F:d -- F:rad ) pi f* 180e f/ ;
: rad>deg ( F:rad -- F:deg ) 180e f* pi f/ ;
: min>rad ( F:min -- F:rad ) 60e f/ deg>rad ;
: sec>rad ( F:min -- F:rad ) 60e f/ min>rad ;

\ approximate sin x using d/m/s interpolation
: xsin ( F:deg -- F:approximate sine )
    f>dms  sec>rad  { F: s } min>rad { F: m } deg>rad { F: d }
    d fcos m fsin f*  
    d fsin m fcos f* f+
    fdup fcos s f*
    f+ ;

: fclearstack  fdepth 0 ?do fdrop loop ;
: cs clearstack fclearstack ;

: err ( deg -- e ) fdup xsin fswap deg>rad fsin f/ 1e f- fabs ;
: maxerr ( -- e ) cs 0e 89999 1 do i s>f 1e-3 f*  err  fmax loop ;

[toc] | [prev] | [next] | [standalone]

#54560

In article <87d1f4yzcs.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Ilya Tarasov <ilya74.tarasov@gmail.com> writes:
>> From the first look, we may list degrees, minutes and seconds, but is
>> it optimal?
>
>It's convenient, so the question then is whether it's close enough.
>
>Optimal involves non-uniform placement of the interpolation points,
>e.g. at the so-called Chebychev nodes according to Wikipedia.  I'd
>expect that with non-optimal placement, you can still get the same
>accuracy by using more points.  That seems ok to me if you have enough
>memory for the bigger tables.
>
>Using naive deg/min/sec interpolation (see below) I get a max error of
>about 1.56e-4 which is well above 1 ULP in single precision.  I think
>that can be improved by just moving the interpolation point slightly.
>There's too stuff going on here at the moment for me to figure that out
>right now, but this is a start.
>
>================================================================
>
>: dms.1 ( f:x -- f:int f:frac ) fdup f>s s>f ftuck f- ;
>: f>dms ( F:degrees -- F:degrees F:minutes F:seconds )
>    dms.1 60e f* dms.1 60e f* dms.1 f+ ;
>
>: dms>f ( F:d F:m F:s -- F:dd )    60e f/ f+ 60e f/ f+ ;
>: deg>rad ( F:d -- F:rad ) pi f* 180e f/ ;
>: rad>deg ( F:rad -- F:deg ) 180e f* pi f/ ;
>: min>rad ( F:min -- F:rad ) 60e f/ deg>rad ;
>: sec>rad ( F:min -- F:rad ) 60e f/ min>rad ;
>
>\ approximate sin x using d/m/s interpolation
>: xsin ( F:deg -- F:approximate sine )
>    f>dms  sec>rad  { F: s } min>rad { F: m } deg>rad { F: d }
>    d fcos m fsin f*
>    d fsin m fcos f* f+
>    fdup fcos s f*
>    f+ ;
>
>: fclearstack  fdepth 0 ?do fdrop loop ;
>: cs clearstack fclearstack ;
>
>: err ( deg -- e ) fdup xsin fswap deg>rad fsin f/ 1e f- fabs ;
>: maxerr ( -- e ) cs 0e 89999 1 do i s>f 1e-3 f*  err  fmax loop ;

Interpolating between exact points 1" apart:
The most unfavourable is interpolating between -.5" and +.5"
1" is 4.8E-6 radians, so both cosines are
1- .59E-11 radians. The average is the same, which is the
interpolated value for cos(0), which is then .59E-11 off,
a respectable precision.
This can be accomplised by sin and cos tables for 90 degree
values, 60 minute angles and 60 second angles.
A value can calculated using 7 multiplications.

So this is no shabby method, although probably Chebychev
polynomials are better.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54564

albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
> Interpolating between exact points 1" apart: ...
> 1- .59E-11 radians. The average is the same, which is the
> interpolated value for cos(0), which is then .59E-11 off,
> a respectable precision.

That's well within 1 ulp.  I only interpolated between minutes, I'll try
putting in seconds.  I also didn't use the x**2 term for approximating
the cosine near x=0.  I just used cos x = 1.

> This can be accomplised by sin and cos tables for 90 degree values, 60
> minute angles and 60 second angles.  A value can calculated using 7
> multiplications.

Nice.

[toc] | [prev] | [next] | [standalone]

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.lang.forth

csiph-web