Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nfchoa sosfilter #65

Closed
wants to merge 4 commits into from
Closed

Nfchoa sosfilter #65

wants to merge 4 commits into from

Conversation

hagenw
Copy link
Member

@hagenw hagenw commented Feb 18, 2016

This is a subtask from #57, which discusses only the improvement of the SOS filter implementations.

The time domain driving functions (plane wave and point source) can be
computed either by
(i) bilinear transform ('defualt') or
(ii) matched z-transfomr ('matchedz')
sphbesselh_zeros(0) returns [] which leads to an error in the filtering for
calculating the driving function under Octave. I changed the behavior that order
0 is now skipped and the first entry of dm is the unfiltered pulse, which will
give the same result for Matlab and Octave.
@hagenw
Copy link
Member Author

hagenw commented Feb 24, 2016

It is working under Octave, but the new filter implementation seems to be a lot more unstable.
Try the following:

Under master branch:

>> conf = SFS_config;
>> conf.secondary_sources.number = 56;
>> conf.nfchoa.order = 7;
>> conf.N = 8;
>> x0 = secondary_source_positions(conf);
>> [~,dm] = driving_function_imp_nfchoa(x0,[0 -1 0],'pw',conf)
dm =

   1.00000   0.00000   0.00000   0.00000   0.00000   0.00000   0.00000   0.00000
  -0.99741   0.00516   0.00513   0.00511   0.00508   0.00505   0.00503   0.00500
   0.99226  -0.01540  -0.01524  -0.01508  -0.01492  -0.01476  -0.01461  -0.01446
  -0.98458   0.03055   0.03000   0.02945   0.02891   0.02838   0.02785   0.02733
   0.97444  -0.05039  -0.04896  -0.04755  -0.04617  -0.04481  -0.04349  -0.04219
  -0.96191   0.07462   0.07152   0.06852   0.06559   0.06275   0.06000   0.05732
   0.94708  -0.10285  -0.09699  -0.09135  -0.08593  -0.08072  -0.07571  -0.07091
  -0.93007   0.13467   0.12455   0.11494   0.10581   0.09717   0.08897   0.08122

Now do the same under the nfchoa_sosfilter branch:

>> conf = SFS_config;
>> conf.secondary_sources.number = 56;
>> conf.nfchoa.order = 7;
>> conf.N = 8;
>> x0 = secondary_source_positions(conf);
>> [~,dm] = driving_function_imp_nfchoa(x0,[0 -1 0],'pw',conf)
dm =

   1.0000e+00   0.0000e+00   0.0000e+00   0.0000e+00   0.0000e+00   0.0000e+00   0.0000e+00   0.0000e+00
  -2.0026e+00  -1.0357e-02  -4.0173e-05  -1.0304e-02  -9.3253e-05  -1.0251e-02  -1.4579e-04  -1.0199e-02
   9.9996e-01   8.0031e-05   1.9857e-05   3.1519e-04  -9.7690e-05   8.9220e-04  -9.0432e-04   2.8262e-03
  -2.0103e+00  -4.1390e-06  -1.5719e-04   4.7748e-01  -3.8074e-03   4.6288e+00  -1.4899e-01   4.0835e+01
   9.9974e-01   7.3942e-08   3.1905e-04  -3.8231e-02   9.1867e-04  -1.2901e+00  -1.0752e+00  -3.7306e+01
  -2.0182e+00  -6.8764e-09  -2.6361e-03  -1.7587e+01  -3.3668e-01  -2.3411e+03  -1.8376e+02  -2.3342e+05
   9.9911e-01   1.9117e-10   5.3132e-03   2.6142e+00   1.3499e+00   1.3028e+03  -7.8639e+02   4.5332e+05
  -2.0257e+00  -2.5651e-11  -4.3534e-02   5.6610e+02  -4.7270e+01   1.1766e+06  -1.9883e+05   1.4867e+09

If you do the same with larger conf.N values you will end up with very high number like e+250 and a lot of NaN.

@hagenw
Copy link
Member Author

hagenw commented Apr 28, 2016

As there seems to be no easy solution to the problems we face under Octave, I would say we will not fix this in the near future.

@hagenw hagenw closed this Jun 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants