Python "why" questions

Martin Braun martin.braun at kit.edu
Fri Aug 20 04:23:08 EDT 2010


On Thu, Aug 19, 2010 at 07:13:50PM +0000, Steven D'Aprano wrote:
> Mathematics is an ancient art that values tradition and convention. It 
> doesn't matter how hard it was to come up with a proof, or how difficult 
> to verify it. Mathematicians value logical correctness and some 
> undefinable sense of elegance over how easy it is to verify, the 
> readability of the notation, resistance to errors, and the ability of 
> mediocre mathematicians to make useful contributions. Mathematical 
> notation and conventions are not, by any stretch of the imagination, 
> designed to reduce errors. Mathematicians consider it a good thing that 
> they are still mostly using the same notation invented by (say) Leibniz.

Another thing worth mentioning (I guess here is a good a place as any
other) is the fact that programming and mathematics are still pretty
different things, despite how much we programmers would like to think
ourselves as some kind of mathematician.  
Fields-medal winners are not likely to be writing database applications
in their spare time, or to save up money for blackboards and pencils.

But mathematics is a wide field, and one area I'm very familiar in is
signal processing, which has taken a lot of mathematics to make our
algorithms work. In fact, of all electrical engineering disciplines,
signal processing is probably the most mathematical.

I find this thread extremely interesting, but what surprised me that
everyone seems to agree that mathematics is 1-based, but we Pythoneers
should stick to zero-based. I disagree. To make sure I'm not going
crazy, I took the top five books lying on my desk, which were the DSP
book by Oppenheim/Schafer, two books by Stephen M. Kay (Spectral
Estimation and Estimation Theory) and the Channel Coding book by Lin &
Costello. This is isn't pure mathematics (as in proving the Goldbach
conjecture), but nevertheless, this is serious mathematics and,
surprise, they most exclusively use zero-based notation.
You probably don't have those books in grabbing distance, so here's some
examples for zero-based stuff:

- The definition of the FFT and one-sided z-transform (practically
  everywhere I've seen)
- Time indices for time-discrete signals usually start at 0 for causal
  signals, same goes for filters (impulse responses)
- Vector representation of polynomials
- The Levinson-Durbin recursion algorithm is way more readable with
  zero-based indices (step 0 is an initialisation step)
- Even most matrices used in the context for coding use zero-based
  indexing (i.e., the left-most column is column zero). I would like to
  add that dealing with linear algebra in GF2 is a bit different from
  handling complex signals as in the previous examples, so this is
  something to consider.

I realize a lot of this has it's root in the application, e.g.
shift-registers (index 0 means it's run through 0 shift registers). But
it's been adopted for the mathematics because it's useful there as well
(e.g. because x^0 = 1 for any non-zero value of x).

Both mathematics and programming have two kinds of iterations: where
index matters, and where it doesn't (why not iterate 'apple',
'banana', 'cherry' etc.). In practically all cases I deal with where the
index matters, zero-based suits me better. The one-based indexing Matlab
uses drives me crazy, and that's specifically designed for engineers.

Martin

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20100820/e2413a2b/attachment-0001.sig>


More information about the Python-list mailing list