From AstroBaki
Revision as of 15:08, 11 May 2015 by WikiSysop (talk | contribs) (Created page with '== AIPY Philosophy (e.g. Pedantry) == === AIPY is: === * A module adding tools for interferometry to Python (not visa versa)‏ * An amalgam of pure-Python and wrappers around C…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

AIPY Philosophy (e.g. Pedantry)[edit]

AIPY is:[edit]

  • A module adding tools for interferometry to Python (not visa versa)‏
  • An amalgam of pure-Python and wrappers around C++ and Fortran
  • Object-Oriented
  • A collection of low- to mid-level operations (you write the program)‏
  • A toolkit (i.e. a grocery store, not a restaurant)‏

AIPY is not:[edit]

  • A solution (it is just a tool to help you find it)‏
  • A one-stop shop (it makes use of other open-source projects)‏
  • A replacement for other interferometry packages
  • Wedded to a file format (but only MIRIAD-UV, FITS currently supported)‏

Why Another Interferometry Package?[edit]

New Problems to Solve[edit]

  • Wide fields of view
  • Large relative bandwidths
  • Huge numbers of antennas
  • Non-tracking primary beams
  • Real-time processing
  • Source separation
  • Ionospheric distortion

Why Python?[edit]

  • Interpreted (up to 5x more productive than compiled languages, according to Burton Group study)‏
  • Object-Oriented
  • Readable
  • Fast, high-level data types
  • Large community of programmers
  • Fast-growing community of numerical/scientific/astronomy programmers


  • Generally, only a small fraction of code needs to run fast
  • Python's profiler can tell you where the bottlenecks are
  • Bottlenecks can be recoded in C/C++/ Fortran and wrapped into Python
  • NumPy, the foundation of numerical/vectorized processing in Python, is coded in C and runs on average only 1.5 times slower than pure C
  • You should only be allowed to worry about speed while your code is actually running

Zen of AIPY (with apologies to The Zen of Python)[edit]

  • Explicit is better than implicit
  • Simple is better than complex
  • Complex is better than complicated
  • Special cases aren't special enough to break the rules
  • Practicality beats purity
  • There should be one (and preferably only one) obvious way to do it, although that way may not be obvious at first unless you're Dutch
  • Now is better than never
  • In the face of ambiguity, refuse the temptation to guess
  • Don't handicap the programmer; allow them all the rope they want
  • Don't hide data; return it (or at least grant access) at every turn