开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

Re: OT Software compilation was Re: [qex] Some questions on digital filter design

 

Open source projects are a rather challenging environment
ranging from the one-guy team (with an itch that needs scratching)
to corporate teams with hundreds of salaried developers).

The one thing they all have in common is a very blighted channel
between the developer and the "customer".

I can't think of many open source projects that are so limited that
you can try all possible inputs. I can't think of too many developers
that are naive enough to think that they can even think of all possible
inputs on even a trivially complicated app.

For example, your application ran on a VAX, using VMS. And later
HPUX on some HP computers. That is the very definition of an insular
environment.

Octave runs a gadzillian combinations of operating system, hardware,
builds, compilers, libraries, ranging from super computers to smart
phones and watches.... Even the big-endian vs little-endian differences
still cause problems.

I don't think I would be very quick to disparage folks that work in
the open source environment.

Don't believe me? Try adopting a tiny little library program, like say
PyPDF2. And get back to me in a while...

-Chuck Harris


On Thu, 11 Jul 2024 14:16:55 +0000 (UTC) "Reginald Beardsley via
groups.io" <pulaskite@...> wrote:
Not programing ability. Exhaustive test. The most complex part of my
libraries was the parser written using lex and yacc. If you feed a
program *all possible input* and it does what it is supposed to do
you can confidently say it is bug free. The other library was
wrappers for the C standard library to replace the VAX run time
library calls. That's pretty easy to get right.

It was not a complex grammar, so the possible valid input set was
small and if the input did not comply with the grammar it reported
the error in the input to the user in human intelligible form.

This was part of a 500 kLOC port from VMS to Unix. The VMS version
stored the data format in the ALC which was not possible in Unix.

We had fewer than a dozen bug reports the first year in use which was
250,000 runs of various parts of the package. It was instrumented to
report usage back to Dallas from around the world. We found many more
in our testing, but those were fixed *before* the code was released.
We built a huge regression test suite for the package which ran every
time I built the system. If a bug appeared in an intermediate build
all work stopped until we had fixed it and added additional tests.
Same if we got a user submitted bug.

The bug reports asymptotically approached zero over 6 years.

There were three aspects that made this possible:

1) Developer attitude, most of the work was done by two people who
were *very* obsessive about quality. I found a bug in our code and
went to ask the other contractor how we could have missed it. He
started trembling because he thought I was accusing him of creating
the bug which was not the case. We had both worked on that particular
piece of code and had both missed the error and I wanted to see if we
could figure out how to avoid repeating such things. It was a very
subtle error which got caught when I constructed some new test cases.

2) The system was officially released on SunOS 4.1, Intergraph Clix
and AIX. Any error or warning reported on any system was fixed. We
also did a port to HP-UX, but I don't think it was ever shipped
because the affiliate that wanted it refused to pay for the 4 man
weeks of work to validate the results of the regression test suite. I
did the Ultrix and Irix ports as an afternoon lark but did not test
them. But I did get a clean compile and link. The IBM compiler caught
numerous violations of the F77 standard which we fixed. I kept a copy
of the F77 standard by my workstation and Plauger and Brodie's
"Standard C" which is by my workstation still as I type this.

3) The regression test suite which was created as we wrote the code
in incremental fashion.

The bottom line is that if the developers really care about code
quality and take the necessary steps it makes a huge difference in
the result.

No claim that I am superman. Merely that I *really* care about code
quality and do everything I know to ensure that it is correct. Same
with my posts. I reread them many times checking for errors.

Have Fun!
Reg

On Wednesday, July 10, 2024 at 11:46:09 PM CDT, David Kirkby
<drkirkby@...> wrote:



I have certainly read before that all non-trivial software has bugs.
You might believe that your own coding abilities don’t produce bugs.
I can not dispute that.








Re: OT Software compilation was Re: [qex] Some questions on digital filter design

 

Not programing ability. Exhaustive test. The most complex part of my libraries was the parser written using lex and yacc. If you feed a program *all possible input* and it does what it is supposed to do you can confidently say it is bug free. The other library was wrappers for the C standard library to replace the VAX run time library calls. That's pretty easy to get right.

It was not a complex grammar, so the possible valid input set was small and if the input did not comply with the grammar it reported the error in the input to the user in human intelligible form.

This was part of a 500 kLOC port from VMS to Unix. The VMS version stored the data format in the ALC which was not possible in Unix.

We had fewer than a dozen bug reports the first year in use which was 250,000 runs of various parts of the package. It was instrumented to report usage back to Dallas from around the world. We found many more in our testing, but those were fixed *before* the code was released. We built a huge regression test suite for the package which ran every time I built the system. If a bug appeared in an intermediate build all work stopped until we had fixed it and added additional tests. Same if we got a user submitted bug.

The bug reports asymptotically approached zero over 6 years.

There were three aspects that made this possible:

1) Developer attitude, most of the work was done by two people who were *very* obsessive about quality. I found a bug in our code and went to ask the other contractor how we could have missed it. He started trembling because he thought I was accusing him of creating the bug which was not the case. We had both worked on that particular piece of code and had both missed the error and I wanted to see if we could figure out how to avoid repeating such things. It was a very subtle error which got caught when I constructed some new test cases.

2) The system was officially released on SunOS 4.1, Intergraph Clix and AIX. Any error or warning reported on any system was fixed. We also did a port to HP-UX, but I don't think it was ever shipped because the affiliate that wanted it refused to pay for the 4 man weeks of work to validate the results of the regression test suite. I did the Ultrix and Irix ports as an afternoon lark but did not test them. But I did get a clean compile and link. The IBM compiler caught numerous violations of the F77 standard which we fixed. I kept a copy of the F77 standard by my workstation and Plauger and Brodie's "Standard C" which is by my workstation still as I type this.

3) The regression test suite which was created as we wrote the code in incremental fashion.

The bottom line is that if the developers really care about code quality and take the necessary steps it makes a huge difference in the result.

No claim that I am superman. Merely that I *really* care about code quality and do everything I know to ensure that it is correct. Same with my posts. I reread them many times checking for errors.

Have Fun!
Reg

On Wednesday, July 10, 2024 at 11:46:09 PM CDT, David Kirkby <drkirkby@...> wrote:



I have certainly read before that all non-trivial software has bugs. You might believe that your own coding abilities don’t produce bugs. I can not dispute that.



Re: OT Software compilation was Re: [qex] Some questions on digital filter design

 

Ok, I'll bite:

On my Debian Bullseye linux 64bit system's Octave,
my HP67 calculator, and in my head, 2^3^4 = 4096.

On my TI 84 Plus C, 2^3^4 = 2.42E24...

I don't consider MatLab to be important enough to have,
so I will imagine that it provides the same answer as
Octave.

So, clearly, the TI84 has a difference of opinion on
operator precedence order.

2^(3^4) = 2.42E24
(2^3)^4 = 4096

The only precedence order that I remember is the one I
learned in grade school: MDAS, or My Dear Aunt Sally,
and for equal precedence chains of calculations: left to
right.

What does 2^3^4 equal out in Kirkbyland?

When I built SageMath on my 64 bit Debian linux system,
it ran configure, and configure used my system GCC compiler,
Python, Fortran, Clib, etc...

-Chuck Harris

On Thu, 11 Jul 2024 05:45:55 +0100 "David Kirkby"
<drkirkby@...> wrote:
...
If you want a simple example of a bug in Octave, compute 2^3^4. Octave
gives the wrong result, which ensures compatibility with MATLAB which
also gives the wrong result. ? Then try it in Mathematica or Python
and you will get the correct result.


I don’t know if it still does, but Sagemath used to ship with a
specific gcc version, as such a large program would trigger one bug
in gcc or another.

I am fairly certain that “stable” versions of gcc are released which
fail tests on one system or the other. A few test failures are
accepted as being okay in the compiler.

I know of quite a few bugs in open-source software, with another
example being the NEC code from the university of York. Several of us
have looked at that and can not see the problem, but it fails a
self-test on some systems but not others. The self-test is actually
correct as NEC gives the same results. Few people are skilled in
Fortran nowadays.

Dave


Rr
I _





Re: OT Software compilation was Re: [qex] Some questions on digital filter design

 

On Wed, 10 Jul 2024 at 15:28, Reginald Beardsley via <pulaskite=[email protected]> wrote:

I do not like Linux/Gnu because the current generation of developers arbitrarily choose to drop or modify various command line options to basic tools. The hallmark of Unix in the old days was stability. The next release would not break *anything* developed on the previous release except
workarounds for bugs.

The advantage of UNIX over Linux is that there is a POSIX standard of what commands should exist and what options they should take. However, nowadays your chances of downloading a substantial open-source program and it compiling on a POSIX compliment UNIX system are slim.? So although I would personally prefer to use a Solaris system over a Linux one, in practice nowadays Solaris is not practical for a desktop workstation.?

Lots of software that used to run on Solaris is no longer supported. The Qt development system is one, Mathematica being another. I think the last version of Mathematica to run on Solaris was 6 or 7, but the latest version is 14.?


'
In my view, a user bug report is a significant black mark on one's skills as a programmer. I wrote a pair of 15 kLOC libraries which never had a bug found in 6 years of supported use and another 6-8 years unsupported. Every time they were compiled a comprehensive test suite fed it *all* possible inputs and checked that it responded to correctly to *all* possible user errors. One library did need a single change.

I have certainly read before that all non-trivial software has bugs. You might believe that your own coding abilities don’t produce bugs. I can not dispute that.?

I have had a bug report open for 6 months or so for Maxima,?


which is the computer algebra system I have to use on a mathematics degree, and is the main one used by Sagemath. This is a regression, as Maxima used to give the correct answer (12 ?Pi/13) but now gives an incorrect answer (25 Pi/13). The Maxima developers acknowledge it’s a bug and have identified the exact commit on Github which caused the regression, but they don’t understand why it caused the error, so it hasn’t been fixed. Realistically the Maxima bug probably never will be fixed as I can’t find a simpler example to demonstrate it.

For what it’s worth, on the Mathematica version I tried, Mathematica gave a huge expression, not a simple irrational number. But when I converted the Mathematica answer to a numerical number it is correct.?

As for the SunOS 32 to 64 bit transition, that merely required setting the proper #defines for large file support which were very well documented. I don't recall any other changes besides trivial things such as replacing "int" with "long" if you actually needed large file support.

I can not remember the details, but I know that I got Sagemath to the point where?

1) It built and passed all tests on a 64-bit SPARC if compiled as the default 32-bit.
2) Would not build on Open Solaris on x86.
3) Would build on a 64-bit SPARC if compiled for 64-bit, but wasn’t stable.?

As I wrote before, the usefulness of a Solaris version has fallen dramatically, so it’s not worth investigating further.?

In theory with access to the source code we can fix bugs, but in practice that’s often not the case.?

If you want a simple example of a bug in Octave, compute 2^3^4. Octave gives the wrong result, which ensures compatibility with MATLAB which also gives the wrong result. ? Then try it in Mathematica or Python and you will get the correct result.?

I don’t know if it still does, but Sagemath used to ship with a specific gcc version, as such a large program would trigger one bug in gcc or another.?

I am fairly certain that “stable” versions of gcc are released which fail tests on one system or the other. A few test failures are accepted as being okay in the compiler. ?

I know of quite a few bugs in open-source software, with another example being the NEC code from the university of York. Several of us have looked at that and can not see the problem, but it fails a self-test on some systems but not others. The self-test is actually correct as NEC gives the same results.? Few people are skilled in Fortran nowadays.?

Dave


Rr
I _


OT Intellectual Integrity

 

Intellectual?integrity?requires?that?one?admit?when?one?is?incorrect?and?not?obfuscate?the?argument?with?irrelevant?details??to?confuse?and?intimidate?the?other?party?in?the?discussion.

There?is?no?shame?in?being?wrong.??It?happens?to?everyone.??How?one?acts?matters.

Introducing?obscure?and?irrelevant?topics?into?a?discussion?is?the?hallmark?of?the?poseur.??It?is?also?a?display?of?complete?contempt?for?the?audience.??The?most?extreme?insult?possible.

I?did?not?like?writing?my?reply?to?Mr.?Marks.??But?having?suffered?such?people?at?work?I'm?certainly?not?going?to?tolerate?it?here. The 5 years I spent getting a solid liberal arts undergraduate degree has served me well. My sole regret is I didn't take more math. I had a lot of catch up to do in grad school.

Have?Fun!
Reg


OT Software compilation was Re: [qex] Some questions on digital filter design

 


For 10 years I built the Gnu utilities and everything else using Gnu make without the least problems. I chose to do that because make was different on many systems I was supporting. This made it easy to define the various defines for things like ar(1), etc. I used "uname -a" to select which set of definitions to use at the start of my standard Makefile template.

The abomination that X propagated, imake, took fewer than 100 lines and expanded it into thousands. The fatal flaw being the expectation that the cpp(1) was the same everywhere. Eventually imake carried around it's own version of cpp(1).

I do not like Linux/Gnu because the current generation of developers arbitrarily choose to drop or modify various command line options to basic tools. The hallmark of Unix in the old days was stability. The next release would not break *anything* developed on the previous release except
workarounds for bugs.
'
In my view, a user bug report is a significant black mark on one's skills as a programmer. I wrote a pair of 15 kLOC libraries which never had a bug found in 6 years of supported use and another 6-8 years unsupported. Every time they were compiled a comprehensive test suite fed it *all* possible inputs and checked that it responded to correctly to *all* possible user errors. One library did need a single change. I tested errno after for a call to getcwd(3c). A subsequent Solaris release failed to set errno correctly. I always set errno = 0 prior to calls which set it. The person who fixed it decided that if getcwd returned a null pointer that was an acceptable workaround and inserted a #ifdef for Sun systems. That code compiled on 6 systems, though it was only supported on 3 for the simple reason that the HP users declined to pay for verifying the test suite. The other 2 systems were built by me one afternoon when I didn't have anything to do.

As for the SunOS 32 to 64 bit transition, that merely required setting the proper #defines for large file support which were very well documented. I don't recall any other changes besides trivial things such as replacing "int" with "long" if you actually needed large file support.


On Tuesday, July 9, 2024 at 08:29:17 PM CDT, Chuck Harris <cfharris@...> wrote:


Well, looks like you have an axe to grind, so I won't
get into it much with you. Open source software has to
cater to the characters that create it.

I have only used sagemath compiled to 64 bit on linux, so
your complaint about that is dated.

The configure package, written by Larry Wall, makes tests
like for the name used on the sh script. Sometimes sh is
sh, other times it is borne shell, or korn shell, or something
totally different aliased as sh... Likely, nothing to do with
Sagemath.

There are things that need work, but at least they don't
charge you to beta test their software.

Nothing is stopping anyone from forking the project, and
doing it themselves. I'd love to see your fork of the project.
Try that with mathematica.

In anycase, as flawed as you think the project is, I would bet
that it can easily run a version of Reg's filter code.

-Chuck Harris



Re: Some questions on digital filter design

 

Well, looks like you have an axe to grind, so I won't
get into it much with you. Open source software has to
cater to the characters that create it.

I have only used sagemath compiled to 64 bit on linux, so
your complaint about that is dated.

The configure package, written by Larry Wall, makes tests
like for the name used on the sh script. Sometimes sh is
sh, other times it is borne shell, or korn shell, or something
totally different aliased as sh... Likely, nothing to do with
Sagemath.

There are things that need work, but at least they don't
charge you to beta test their software.

Nothing is stopping anyone from forking the project, and
doing it themselves. I'd love to see your fork of the project.
Try that with mathematica.

In anycase, as flawed as you think the project is, I would bet
that it can easily run a version of Reg's filter code.

-Chuck Harris


On Wed, 10 Jul 2024 00:29:08 +0100 "David Kirkby"
<drkirkby@...> wrote:
On Tue, 9 Jul 2024 at 14:55, Chuck Harris via groups.io <cfharris=
[email protected]> wrote:

Recently, I was playing with open source Sagemath, and
it is quite interesting. It is a python based scripted
language that is much like mathematica. It is a symbolic
math package that does integration and differentiation.
It understands parallelism, though it needs you to give
it some help.

I used to work on the development of that. I got it ported to 32-bit
SPARC, but it wasn’t happy if compiled 64-bit. Unfortunately the
timing of the port coincided with Oracle buying Sun, and basically
making the use of a Solaris version less attractive.

I would disagree that Sagemath is like Mathematicia.



Basically, you can think of it as giving the entire GNU
mathematics related packages a common user interface...

Sagemath adds a Python interface onto everything it includes, but
many of the things it uses have no library interface, so the
interface lacks the consistency of Mathematica. Sagemath simply uses
Expect or similar to pass data between programs.

Sagemath can call Mathematica, but unless things have changed, it
doesn’t do this via the API to Mathematica, but just uses Expect.

Most calculus in Sagemath is done with Maxima. Again, Maxima has no
library interface, so something like Expect is used.

I don’t know what it is like now, but I used to get fed up with the
speed of new releases, each time adding new features. I was regularly
nagging to have a bug-fix release, where no new functionality is
added, but bugs fixed. Professor Stein once said that I could be the
release manager for such a bug-fix release, but not to take too long
about it. I decided that unless done correctly it wasn’t worth doing.

I recall one developer saying that he didn’t care about bugs in his
code, as he would fix them if reported. He was an extreme example
though.

I tried to get Professor Stein to buy 15 or so books on software
engineering, and give them to the developers doing the most
development, but I couldn’t convince him to do that. I don’t know if
things have changed, but I certainly didn’t feel that there was as
much emphasis on quality control as I would have wanted to see.

Some mathematicians can write good code, but there was, and perhaps
still is, really crap code in Sagemath. My favourite bit of code
started

#!/bin/sh

The script then went to check some common commands like ls and cp
existed. The biggest laugh was that it also checked if sh existed.?


It took some of the really ugly montecarlo integrals that
my son, the particle physicist, was working on, and found
that SageMath gave better answers than Mathematica, though
its speed was about an order of magnitude slower.

There are certainly going to be cases where one package beats
another, but overall I think Mathematicia is hard to beat, and it’s
free on a Raspberry Pi.

In my opinion at least, it’s never going to meet its mission of
creating a viable alternative to Magma, Maple, Mathematicia and
Matlab.



-Chuck Harris

Dave.






Re: Some questions on digital filter design

 

On Tue, 9 Jul 2024 at 14:55, Chuck Harris via <cfharris=[email protected]> wrote:
Recently, I was playing with open source Sagemath, and
it is quite interesting.? It is a python based scripted
language that is much like mathematica.? It is a symbolic
math package that does integration and differentiation.
It understands parallelism, though it needs you to give
it some help.

I used to work on the development of that. I got it ported to 32-bit SPARC, but it wasn’t happy if compiled 64-bit. Unfortunately the timing of the port coincided with Oracle buying Sun, and basically making the use of a Solaris version less attractive.?

I would disagree that Sagemath is like Mathematicia.


Basically, you can think of it as giving the entire GNU
mathematics related packages a common user interface...

Sagemath adds a Python interface onto everything it includes, but many of the things it uses have no library interface, so the interface lacks the consistency of Mathematica. Sagemath simply uses Expect or similar to pass data between programs.?

Sagemath can call Mathematica, but unless things have changed, it doesn’t do this via the API to Mathematica, but just uses Expect.?

Most calculus in Sagemath is done with Maxima. Again, Maxima has no library interface, so something like Expect is used.?

I don’t know what it is like now, but I used to get fed up with the speed of new releases, each time adding new features. I was regularly nagging to have a bug-fix release, where no new functionality is added, but bugs fixed. Professor Stein once said that I could be the release manager for such a bug-fix release, but not to take too long about it. I decided that unless done correctly it wasn’t worth doing.?

I recall one developer saying that he didn’t care about bugs in his code, as he would fix them if reported. He was an extreme example though.?

I tried to get Professor Stein to buy 15 or so books on software engineering, and give them to the developers doing the most development, but I couldn’t convince him to do that.?I don’t know if things have changed, but I certainly didn’t feel that there was as much emphasis on quality control as I would have wanted to see.?

Some mathematicians can write good code, but there was, and perhaps still is, really crap code in Sagemath. My favourite bit of code started

#!/bin/sh

The script then went to check some common commands like ls and cp existed. The biggest laugh was that it also checked if sh existed.?

It took some of the really ugly montecarlo integrals that
my son, the particle physicist, was working on, and found
that SageMath gave better answers than Mathematica, though
its speed was about an order of magnitude slower.

There are certainly going to be cases where one package beats another, but overall I think Mathematicia is hard to beat, and it’s free on a Raspberry Pi.?

In my opinion at least, it’s never going to meet its mission of creating a viable alternative to Magma, Maple, Mathematicia and Matlab.?


-Chuck Harris

Dave.?


Re: Some questions on digital filter design

 

Chuck,

Many thanks. I'll have try it out and perhaps move back to OpenIndiana. Debian has been driving me crazy because the admin is so screwy. It is simply not Unix. Though that doesn't change the fact that I don't like MATLAB.

In the mid '90s I had to install MATLAB at work, but the install kept failing on SunOS no less. When I investigated I discovered that there were 30,000 lines of scripts being run by the installer. I sent Mathworks an email saying, "I don't know whether to laugh or cry. Some people write operating systems in fewer lines."

Have Fun!
Reg


On Tuesday, July 9, 2024 at 12:12:56 PM CDT, Chuck Harris <cfharris@...> wrote:


FYI, I just checked, and Eaton says Octave builds under
Solaris just fine as of July 2018, and closed the
bug #54235.

Octave 4.4.0
Solaris 10.

-Chuck Harris


On Tue, 9 Jul 2024 14:04:48 +0000 (UTC) "Reginald Beardsley via
groups.io" <pulaskite@...> wrote:
>?
> Octave originally was explicitly not a MATLAB clone when John Eaton
> developed it at the chemistry department at UT Austin He eventually
> yielded to pressure to make it MATLAB compatible.
>
> Because nothing more recent that 2.95 will compile on Solaris I have
> largely ceased to use it. In particular because the plotting is so
> wretched relative to Gnuplot which was used previously in Octave.
>
> Electrical engineering is engineering, accomplishing a task under a
> set of constraints. Elastic wave theory is mathematical physics. For
> reasons beyond my comprehension the EE community accepted a
> compromise we do not accept in reflection seismology. Doing so would
> reduce many important results to gibberish.
>
> In particular the layering of geological strata constitute a filter
> and the goal of reflection seismology is to discover the layer
> properties from the filter response. As that is a physical filter it
> must be causal. I have written the code for a wide range of problems
> in signal processing, wave propagation in elastic and acoustic media
> and the variation of the mechanical properties of porous media as a
> function of the bulk modulus of the fluid variation with pressure and
> temperature.
>
> Because I am working on a digital implementation of twin pass band
> tuning for use in an SDR I thought I should consult the EE literature
> on DSP. As I now consider that to be deeply flawed I shall continue
> the practice of the reflection seismology community and use a causal
> filter in instances where I do not specifically desire a zero phase
> filter.
>
> Have Fun!
> Reg






Re: Some questions on digital filter design

 

FYI, I just checked, and Eaton says Octave builds under
Solaris just fine as of July 2018, and closed the
bug #54235.

Octave 4.4.0
Solaris 10.

-Chuck Harris


On Tue, 9 Jul 2024 14:04:48 +0000 (UTC) "Reginald Beardsley via
groups.io" <pulaskite@...> wrote:

Octave originally was explicitly not a MATLAB clone when John Eaton
developed it at the chemistry department at UT Austin He eventually
yielded to pressure to make it MATLAB compatible.

Because nothing more recent that 2.95 will compile on Solaris I have
largely ceased to use it. In particular because the plotting is so
wretched relative to Gnuplot which was used previously in Octave.

Electrical engineering is engineering, accomplishing a task under a
set of constraints. Elastic wave theory is mathematical physics. For
reasons beyond my comprehension the EE community accepted a
compromise we do not accept in reflection seismology. Doing so would
reduce many important results to gibberish.

In particular the layering of geological strata constitute a filter
and the goal of reflection seismology is to discover the layer
properties from the filter response. As that is a physical filter it
must be causal. I have written the code for a wide range of problems
in signal processing, wave propagation in elastic and acoustic media
and the variation of the mechanical properties of porous media as a
function of the bulk modulus of the fluid variation with pressure and
temperature.

Because I am working on a digital implementation of twin pass band
tuning for use in an SDR I thought I should consult the EE literature
on DSP. As I now consider that to be deeply flawed I shall continue
the practice of the reflection seismology community and use a causal
filter in instances where I do not specifically desire a zero phase
filter.

Have Fun!
Reg


Re: Some questions on digital filter design

 

The attached images are from a 200 MHz Instek DSO. 34 has the sinc interpolation turned on, 35 was taken in dot mode with infinite persistence.

35 shows the correct waveform whereas 34 has spurious perturbations before the start of the 100 ns Gaussian pulse made by one of Leo Bodnar's excellent pulsers which he modified to satisfy a request from CERN for an inexpensive, very fast pulse.

This is an example in which the interpolator is inappropriate. It should be minimum phase. As I mentioned earlier in this thread every DSO I've used has the same problem. It's the reason I have Tek 485, 2465 and 7104 model analog scopes in addition to an 11801.

Should anyone doubt the accuracy of the dot mode display I can fire up the Tek 11801 and feed the signal to a 40 GHz SD-32 sampling head. Though as I have a 2.92 mm to 3.5 mm adapter fitted it's limited to 30 GHz and the BNC to 3.5 adapter will knock that down quite a bit more.


Re: Some questions on digital filter design

 


It turns out Jeff is correct. The error in my thinking is a consequence of the particulars of filtering of reflection seismic data. Because time of arrival for a reflection is the single most critical concern, a filter which introduced a delay as in Jeff's example would be unacceptable.

This has resulted in the term "causal" implying minimum phase in conversation in the seismic field and it is immediately understood that only the minimum phase subset of causal operators is meant. That is not the case in communications systems.

Many thanks to all who have participated in this discussion.

The resolution of the apparent conundrum is due to:

An Introduction to Digital Signal Processing
John H. Karl
Academic Press 1989

which is the book I always recommend to people wanting to learn DSP as it is the clearest and most complete explanation of the fundamentals I have in my library and to which I typically refer when I have questions.

I'm sufficiently obsessive that I always look up equations rather than trust memory. It is very painful to discover that you've spent days debugging a complex program because you made a mistake in coding the equation. Or as I often had to do, find someone else's mistake. Uninitialized variables being one of the more common problems.

Have Fun!
Reg
On Tuesday, July 9, 2024 at 09:04:53 AM CDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:



Octave originally was explicitly not a MATLAB clone when John Eaton developed it at the chemistry department at UT Austin He eventually yielded to pressure to make it MATLAB compatible.

Because nothing more recent that 2.95 will compile on Solaris I have largely ceased to use it. In particular because the plotting is so wretched relative to Gnuplot which was used previously in Octave.

Electrical engineering is engineering, accomplishing a task under a set of constraints. Elastic wave theory is mathematical physics. For reasons beyond my comprehension the EE community accepted a compromise we do not accept in reflection seismology. Doing so would reduce many important results to gibberish.

In particular the layering of geological strata constitute a filter and the goal of reflection seismology is to discover the layer properties from the filter response. As that is a physical filter it must be causal. I have written the code for a wide range of problems in signal processing, wave propagation in elastic and acoustic media and the variation of the mechanical properties of porous media as a function of the bulk modulus of the fluid variation with pressure and temperature.

Because I am working on a digital implementation of twin pass band tuning for use in an SDR I thought I should consult the EE literature on DSP. As I now consider that to be deeply flawed I shall continue the practice of the reflection seismology community and use a causal filter in instances where I do not specifically desire a zero phase filter.

Have Fun!
Reg



On Tuesday, July 9, 2024 at 01:55:10 AM CDT, David Kirkby <drkirkby@...> wrote:


On Tue, 9 Jul 2024 at 00:36, Reginald Beardsley via <pulaskite=[email protected]> wrote:
Here's a zerophase equivalent. Running it turned up a typo in the comment block in minphase.m which has "$" where it should be "#". I wrote the comment block after I tested it, so I missed the typo. Lesson learned.

Have Fun!
Reg


IMHO, given Octave is a clone of MATLAB it would be better to use % for a comment rather than #. The # is an Octave specific extension that is not supported by MATLAB, whereas % is supported by both MATLAB and Octave.?

Dave.?


Re: Some questions on digital filter design

 


Octave originally was explicitly not a MATLAB clone when John Eaton developed it at the chemistry department at UT Austin He eventually yielded to pressure to make it MATLAB compatible.

Because nothing more recent that 2.95 will compile on Solaris I have largely ceased to use it. In particular because the plotting is so wretched relative to Gnuplot which was used previously in Octave.

Electrical engineering is engineering, accomplishing a task under a set of constraints. Elastic wave theory is mathematical physics. For reasons beyond my comprehension the EE community accepted a compromise we do not accept in reflection seismology. Doing so would reduce many important results to gibberish.

In particular the layering of geological strata constitute a filter and the goal of reflection seismology is to discover the layer properties from the filter response. As that is a physical filter it must be causal. I have written the code for a wide range of problems in signal processing, wave propagation in elastic and acoustic media and the variation of the mechanical properties of porous media as a function of the bulk modulus of the fluid variation with pressure and temperature.

Because I am working on a digital implementation of twin pass band tuning for use in an SDR I thought I should consult the EE literature on DSP. As I now consider that to be deeply flawed I shall continue the practice of the reflection seismology community and use a causal filter in instances where I do not specifically desire a zero phase filter.

Have Fun!
Reg



On Tuesday, July 9, 2024 at 01:55:10 AM CDT, David Kirkby <drkirkby@...> wrote:


On Tue, 9 Jul 2024 at 00:36, Reginald Beardsley via <pulaskite=[email protected]> wrote:
Here's a zerophase equivalent. Running it turned up a typo in the comment block in minphase.m which has "$" where it should be "#". I wrote the comment block after I tested it, so I missed the typo. Lesson learned.

Have Fun!
Reg


IMHO, given Octave is a clone of MATLAB it would be better to use % for a comment rather than #. The # is an Octave specific extension that is not supported by MATLAB, whereas % is supported by both MATLAB and Octave.?

Dave.?


Re: Some questions on digital filter design

 

Recently, I was playing with open source Sagemath, and
it is quite interesting. It is a python based scripted
language that is much like mathematica. It is a symbolic
math package that does integration and differentiation.
It understands parallelism, though it needs you to give
it some help.

Basically, you can think of it as giving the entire GNU
mathematics related packages a common user interface...

It took some of the really ugly montecarlo integrals that
my son, the particle physicist, was working on, and found
that SageMath gave better answers than Mathematica, though
its speed was about an order of magnitude slower.

-Chuck Harris


On Tue, 9 Jul 2024 07:54:56 +0100 "David Kirkby"
<drkirkby@...> wrote:
On Tue, 9 Jul 2024 at 00:36, Reginald Beardsley via groups.io
<pulaskite= [email protected]> wrote:

Here's a zerophase equivalent. Running it turned up a typo in the
comment block in minphase.m which has "$" where it should be "#". I
wrote the comment block after I tested it, so I missed the typo.
Lesson learned.

Have Fun!
Reg

IMHO, given Octave is a clone of MATLAB it would be better to use %
for a comment rather than #. The # is an Octave specific extension
that is not supported by MATLAB, whereas % is supported by both
MATLAB and Octave.

Dave.


Re: Some questions on digital filter design

 

On Tue, 9 Jul 2024 at 00:36, Reginald Beardsley via <pulaskite=[email protected]> wrote:
Here's a zerophase equivalent. Running it turned up a typo in the comment block in minphase.m which has "$" where it should be "#". I wrote the comment block after I tested it, so I missed the typo. Lesson learned.

Have Fun!
Reg


IMHO, given Octave is a clone of MATLAB it would be better to use % for a comment rather than #. The # is an Octave specific extension that is not supported by MATLAB, whereas % is supported by both MATLAB and Octave.?

Dave.?


Re: Some questions on digital filter design

 

Here's a zerophase equivalent. Running it turned up a typo in the comment block in minphase.m which has "$" where it should be "#". I wrote the comment block after I tested it, so I missed the typo. Lesson learned.

Have Fun!
Reg


On Monday, July 8, 2024 at 05:08:36 PM CDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:


?I've?attached?a?longer?Octave?script?which?demonstrates?the?minimum?phase?impulse
response?for?the?same?corner?frequency?with?decreasing?roll?off?of?the?filter?skirt.

Because?the?time?domain?impulse?response?is?a?graph?of?the?filter?taps,?it?should?be?clear
as?the?skirt?slope?gets?becomes?more?gradual,?fewer?taps?are?needed?for?an?FIR?filter.

In?light?of?the?comments?about?the?phase?delay?of?the?digital?filters?which?prompted?this?thread?the?advantages?should?be?obvious.

In?a?production?code?I?would?use?a?sine?or?raised?cosine?taper?to?eliminate?artifacts
introduced?by?the?sharp?corners?of?the?skirts.

I?encourage?anyone?with?a?serious?interest?in?DSP?to?run?the?script?and?contemplate?the?implications.?In?particular?relative?to?the?practice?of?simply?shifting?the?zero?phase?filter
impulse?response.

My?rule?of?thumb?is?to?put?the?corner?at?1/2?of?Nyquist?as?it?ensures?minimal?ringing?without?imposing?too?much?demand?on?the?sample?rate.?It?comes?closer?to?my?gold?standard?of?analog?Tektronix
scopes.?Like?many?others?of?my?generation,?I?am?of?the?"Tektronix?for?scopes,?HP?for?everything?else"?school.?Sadly?that?does?not?apply?to?current?Tektronix?scopes?or?any?other?DSO?from?any?maker.

Have?Fun!
Reg






Re: Some questions on digital filter design

 

I've?attached?a?longer?Octave?script?which?demonstrates?the?minimum?phase?impulse
response?for?the?same?corner?frequency?with?decreasing?roll?off?of?the?filter?skirt.

Because?the?time?domain?impulse?response?is?a?graph?of?the?filter?taps,?it?should?be?clear
as?the?skirt?slope?gets?becomes?more?gradual,?fewer?taps?are?needed?for?an?FIR?filter.

In?light?of?the?comments?about?the?phase?delay?of?the?digital?filters?which?prompted?this?thread?the?advantages?should?be?obvious.

In?a?production?code?I?would?use?a?sine?or?raised?cosine?taper?to?eliminate?artifacts
introduced?by?the?sharp?corners?of?the?skirts.

I?encourage?anyone?with?a?serious?interest?in?DSP?to?run?the?script?and?contemplate?the?implications.?In?particular?relative?to?the?practice?of?simply?shifting?the?zero?phase?filter
impulse?response.

My?rule?of?thumb?is?to?put?the?corner?at?1/2?of?Nyquist?as?it?ensures?minimal?ringing?without?imposing?too?much?demand?on?the?sample?rate.?It?comes?closer?to?my?gold?standard?of?analog?Tektronix
scopes.?Like?many?others?of?my?generation,?I?am?of?the?"Tektronix?for?scopes,?HP?for?everything?else"?school.?Sadly?that?does?not?apply?to?current?Tektronix?scopes?or?any?other?DSO?from?any?maker.

Have?Fun!
Reg


Re: Some questions on digital filter design

 

Oh, well. There's a reason I don't trust Wikipedia. As I remarked, no analog filter behaves in the manner of the example you cited. We can leave it there.

Have Fun!
Reg


On Monday, July 8, 2024 at 02:27:24 PM CDT, Jeff Anderson <jca1955@...> wrote:


To quote your Wikipedia source (with my highlighting):

In certain linear physical systems, or in engineering fields such as?, the response function??describes how some time-dependent property??of a physical system responds to an impulse???at time??For example,??could be the??of a??and??the applied force of a??driving the pendulum motion. The response??must be zero for??since a system cannot respond to a force before it is applied. It can be shown (for instance, by invoking?) that this causality condition (...)



The example I gave of a time-shifted, truncated, sinc impulse response satisfies this condition, and therefore, per the above quote, it is causal.?

I really don't see this discussion going anywhere.? You have not convinced me that you are correct.? And I have not convinced you.

Thank you for the discussion.

- Jeff, k6jca


On Monday, July 8, 2024 at 09:58:18 AM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:


It might be "casual", but it's not causal. The proof is called the Kramers-Kronig relation. I generally am reluctant to cite Wikipedia for anything, but this looks to be approximately correct and easier to locate than in my library.

https://en.wikipedia.org/wiki/Kramers%E2%80%93Kronig_relations

Have Fun!
Reg


On Monday, July 8, 2024 at 09:15:31 AM CDT, Jeff Anderson <jca1955@...> wrote:


As the figure in the reference shows, the filter is still symmetric, but it is now non-anticipatory, and thus, by definition, casual.

- Jeff, k6jca


On Monday, July 8, 2024 at 07:09:23 AM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:



Indeed it does because the zero phase response has been convolved with dirac(t - tau) instead of dirac(t). That convolution does not make the filter causal. It merely delays the filter output by tau.

Show me an analog filter which produces such a response.

Have Fun!
Reg

On Monday, July 8, 2024 at 08:27:56 AM CDT, Jeff Anderson <jca1955@...> wrote:


If you shift time for your Zerophase impulse response so that t0 is now at its left side, rather than being in the center, you now have a symmetric, causal, filter.? See attached.

This is how I designed my real-time FIR filters that were realized in hardware.

- Jeff, k6jca


On Sunday, July 7, 2024 at 06:00:11 PM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:


After a great deal of rummaging around on multiple systems I found an example of a minimum phase wavelet with a boxcar spectrum that I did 6 years ago.

In minphase t0 is at the left. In zerophase t0 is in the center. I've attached the octave script that created the plots. The minphase plot is zero before t0. Same spectrum, but very different wavelets.
Zerophase is symmetric about t0 and is not causal. Minphase is causal.

Would you accept zerophase as the impulse response on a scope? I certainly would not. This is a contrived case for the simple reason that the boxcar<=>sinc transform pair are well known. The sharp edge on the boxcar causes all the ringing.

Have Fun!
Reg


Re: Some questions on digital filter design

 

To quote your Wikipedia source (with my highlighting):

In certain linear physical systems, or in engineering fields such as?, the response function??describes how some time-dependent property??of a physical system responds to an impulse???at time??For example,??could be the??of a??and??the applied force of a??driving the pendulum motion. The response??must be zero for??since a system cannot respond to a force before it is applied. It can be shown (for instance, by invoking?) that this causality condition (...)



The example I gave of a time-shifted, truncated, sinc impulse response satisfies this condition, and therefore, per the above quote, it is causal.?

I really don't see this discussion going anywhere.? You have not convinced me that you are correct.? And I have not convinced you.

Thank you for the discussion.

- Jeff, k6jca


On Monday, July 8, 2024 at 09:58:18 AM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:


It might be "casual", but it's not causal. The proof is called the Kramers-Kronig relation. I generally am reluctant to cite Wikipedia for anything, but this looks to be approximately correct and easier to locate than in my library.

https://en.wikipedia.org/wiki/Kramers%E2%80%93Kronig_relations

Have Fun!
Reg


On Monday, July 8, 2024 at 09:15:31 AM CDT, Jeff Anderson <jca1955@...> wrote:


As the figure in the reference shows, the filter is still symmetric, but it is now non-anticipatory, and thus, by definition, casual.

- Jeff, k6jca


On Monday, July 8, 2024 at 07:09:23 AM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:



Indeed it does because the zero phase response has been convolved with dirac(t - tau) instead of dirac(t). That convolution does not make the filter causal. It merely delays the filter output by tau.

Show me an analog filter which produces such a response.

Have Fun!
Reg

On Monday, July 8, 2024 at 08:27:56 AM CDT, Jeff Anderson <jca1955@...> wrote:


If you shift time for your Zerophase impulse response so that t0 is now at its left side, rather than being in the center, you now have a symmetric, causal, filter.? See attached.

This is how I designed my real-time FIR filters that were realized in hardware.

- Jeff, k6jca


On Sunday, July 7, 2024 at 06:00:11 PM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:


After a great deal of rummaging around on multiple systems I found an example of a minimum phase wavelet with a boxcar spectrum that I did 6 years ago.

In minphase t0 is at the left. In zerophase t0 is in the center. I've attached the octave script that created the plots. The minphase plot is zero before t0. Same spectrum, but very different wavelets.
Zerophase is symmetric about t0 and is not causal. Minphase is causal.

Would you accept zerophase as the impulse response on a scope? I certainly would not. This is a contrived case for the simple reason that the boxcar<=>sinc transform pair are well known. The sharp edge on the boxcar causes all the ringing.

Have Fun!
Reg


Re: Some questions on digital filter design

 

It might be "casual", but it's not causal. The proof is called the Kramers-Kronig relation. I generally am reluctant to cite Wikipedia for anything, but this looks to be approximately correct and easier to locate than in my library.

https://en.wikipedia.org/wiki/Kramers%E2%80%93Kronig_relations

Have Fun!
Reg


On Monday, July 8, 2024 at 09:15:31 AM CDT, Jeff Anderson <jca1955@...> wrote:


As the figure in the reference shows, the filter is still symmetric, but it is now non-anticipatory, and thus, by definition, casual.

- Jeff, k6jca


On Monday, July 8, 2024 at 07:09:23 AM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:



Indeed it does because the zero phase response has been convolved with dirac(t - tau) instead of dirac(t). That convolution does not make the filter causal. It merely delays the filter output by tau.

Show me an analog filter which produces such a response.

Have Fun!
Reg

On Monday, July 8, 2024 at 08:27:56 AM CDT, Jeff Anderson <jca1955@...> wrote:


If you shift time for your Zerophase impulse response so that t0 is now at its left side, rather than being in the center, you now have a symmetric, causal, filter.? See attached.

This is how I designed my real-time FIR filters that were realized in hardware.

- Jeff, k6jca


On Sunday, July 7, 2024 at 06:00:11 PM PDT, Reginald Beardsley via groups.io <pulaskite@...> wrote:


After a great deal of rummaging around on multiple systems I found an example of a minimum phase wavelet with a boxcar spectrum that I did 6 years ago.

In minphase t0 is at the left. In zerophase t0 is in the center. I've attached the octave script that created the plots. The minphase plot is zero before t0. Same spectrum, but very different wavelets.
Zerophase is symmetric about t0 and is not causal. Minphase is causal.

Would you accept zerophase as the impulse response on a scope? I certainly would not. This is a contrived case for the simple reason that the boxcar<=>sinc transform pair are well known. The sharp edge on the boxcar causes all the ringing.

Have Fun!
Reg