Changes between Version 23 and Version 24 of SwiggingHlsvd


Ignore:
Timestamp:
Jul 14, 2009, 4:58:51 PM (10 years ago)
Author:
flip
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SwiggingHlsvd

    v23 v24  
    126126
    127127Our Python call is just two lines of code, and could be one:
    128 ::
    129 
    130     root, fre, dam, amp, phase, sv, snoise, rms, nitf, ndiv = \
    131         hlsvd(y, ndp, tstep, m, nssv, nit)
    132 
     128}}}
     129{{{
     130!python
     131
     132root, fre, dam, amp, phase, sv, snoise, rms, nitf, ndiv = \
     133    hlsvd(y, ndp, tstep, m, nssv, nit)
     134}}}
     135
     136{{{
     137#!rst
    133138
    134139With this Pythonic interface in mind, let's look at how the interfaces generated by SWIG and ctypes stack up.
     
    144149The resulting code is something only a mother could love. I should point out that I think SWIG is near miraculous in what it can do, and I don't intend any of my snide comments as criticism of SWIG or its developers. It's just that autotranslated code has all the charm of autotranslated writing. If you've ever used Babelfish, you know what I'm talking about. Meaning is (usually) preserved, albeit crudely, but all the idioms are lost and it's eminently clear that the text (or in this case, the interface) was not created by a native speaker.
    145150
    146 So we get ugly code like this (where inputs is a Python list I populated from a file):
    147 ::
    148 
    149     yr = hlsvd_wrapper.new_float_array(2048)
    150     for i in range(0, 2048):
    151         hlsvd_wrapper.float_array_setitem(yr, i, inputs[i])
    152 
    153 
     151So we get ugly code like the example below (in which ``inputs`` is a Python list I populated from a file):
     152}}}
     153{{{
     154#!python
     155
     156yr = hlsvd_wrapper.new_float_array(2048)
     157for i in range(0, 2048):
     158   hlsvd_wrapper.float_array_setitem(yr, i, inputs[i])
     159}}}
     160
     161{{{
     162#!rst
    154163And this (which I think is only necessary because of ``hlsvd()``'s pass-by-reference awkwardness I mentioned above):
    155 ::
    156 
    157    tstep = hlsvd_wrapper.new_tstep()
    158    hlsvd_wrapper.tstep_assign(tstep, .256)
    159 
     164}}}
     165
     166{{{
     167#!python
     168tstep = hlsvd_wrapper.new_tstep()
     169hlsvd_wrapper.tstep_assign(tstep, .256)
     170}}}
    160171
    161172And a series of calls like this one to create the output arrays:
    162 ::
    163 
    164    rootr = hlsvd_wrapper.new_double_array(50)
     173
     174{{{
     175#!python
     176rootr = hlsvd_wrapper.new_double_array(50)
     177}}}
     178
     179{{{
     180#!rst
    165181
    166182In all, here's what one has to do just to create (not populate) the variables to be used in the call to ``hlsvd()``:
    167 ::
    168 
     183}}}
     184
     185{{{
     186#!python
    169187    yr = hlsvd_wrapper.new_float_array(2048)
    170188    yi = hlsvd_wrapper.new_float_array(2048)
     
    186204    ndiv = hlsvd_wrapper.new_ndiv()
    187205    nitf = hlsvd_wrapper.new_nitf()
    188 
     206}}}
    189207
    190208The call itself looks like this:
    191 ::
    192 
     209
     210{{{
     211#!python
    193212    hlsvd_wrapper.hlsvd(yr, yi, ndata, ndp, tstep, m, nssv,
    194213                         rootr, rooti, fre, dam, amp, phase, sv, snoise,
    195214                         rms, ndiv, nit, nitf)
    196 
     215}}}
    197216
    198217Note that every disadvantage of the C interface remains. There's no distinction between input and output parameters. The complex numbers are still represented as correlated lists of floats. The list/array sizes must be specified explicitly, and an opportunity for memory corruption or a crash exists if one gets it wrong. One must keep track of which variables are floats and which are doubles. And it's many more lines of code than the Python version. (Some of this is exacerbated by ``hlsvd()``'s pass-by-reference interface.)