Object oriented interface

[sjkisner]

I pushed a branch oo_interface that includes a definition of a new callable class Recon that wraps svmbir.recon(). What it currently does is very simple. Instances of Recon have the attribute .params which is a dictionary of all the arguments to svmbir.recon(). An instance of Recon is callable, and can be used with the same syntax as svmbir.recon(). So,

img = svmbir.recon(sino,angles,**kwargs)

Can be achieved equivalently with,

rec_op = svmbir.Recon(**kwargs)
img = rec_op(sino,angles)    # can also add keyword arguments here

Additionally it defines the following methods:

 __init__(self, **kwargs)      # defines/sets initial 'params' attribute
 __call__(self, sino, angles, **kwargs)    # calls svmbir.recon()
set_defaults()             # resets params attribute to defaults
set_params(**kwargs)       # sets params entries by keyword
save_params(filename)      # save params dict to numpy/pickle file
load_params(filename)      # load params dict from numpy/pickle file
backproject(sino, angles, **kwargs)    # backprojector

I added a file demo/demo_oo.py that illustrates further.

We can use this thread to discuss this and further development of an OO interface for svmbir.

[gbuzzard]

I think this is a great idea. A few thoughts:

1. I think we should think about the object name so that it matches conceptually the purpose and use of the object. At the moment, the object is designed to encapsulate parameters about the system geometry and to perform forward and back projections, recon, and some auxiliary tasks. Because of this multi-faceted nature, the name should be more general, and I think also the object itself should not be callable. At the moment I’m not sure what a good name is. Maybe something like ParallelBeamSystem. That’s pretty long but captures the spirit of what we’re trying to do. Then we could have ConeBeamSystem in mbircone, etc.
2. The current implementation using the object as a wrapper around the functional forms is not very elegant from a coding point of view, but it has the advantages of being very easy to implement and backwards compatible. I would lean towards doing it that way for now, perhaps with a deprecation warning for calling the functional form directly. But I could be persuaded otherwise.