[Insight-developers] Integrating the New Statistics framework into ITK

[Bill Lorensen]

Ah, but we did release Calculators in Statistics. I'm not suggesting
that Calculators be implemented as Filters, rather that Filters be
implemented using Calculators.

We never released a  MedianImageCalculator, so there is no need to add
one now. But we did release Calculators in Statistics and we all
agreed to that API.

I realize that it is probably not practical to keep the new Statistics
100% backward compatible, but shouldn't we try as best we can?

Bill

On Thu, Apr 9, 2009 at 4:22 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Bill Lorensen wrote:
>>
>> Just a few initial comments:
>>
>> I see in general that Calculators have been replaced with Filters. It
>> is a great idea to have filters. However, I'm suprised that the
>> calculators are gone. In other parts of ITK, we have both Calculators
>> and Filters. The Filters are implemented using the Calculators.
>>
>> I wonder was there any consideration to minimize backward compatibility
>> issues.
>>
> ---------------
>
> Bill,
>
> The main purpose of the refactoring was to make the Statistics
> Framework compatible with the pipeline architecture of the
> rest of the toolkit, and to solve for a number of structural
> problems in the implementations (e.g. SubSamples of SubSamples).
>
> In that regard the main change was to convert:
>
>     * Samples    ----->  DataObjects
>     * Calculator ----->  Filters
>
> In the current statistics framework most operations are done by
> Calculators. This was mostly due to the disconnection with the
> pipeline architecture of the rest of the toolkit.
>
> We could indeed reimplement the old Calculators based on using
> the new Filters, but it will not correspond to the duality that
> you refer to in other sections of the toolkit.
>
> To be more concrete:
>
> In ITK we have the ImageStatistics filter and we have the
> Calculators that will compute min, max, variance ... etc.
>
> But...
> we don't have both a MedianImageFilter and a MedianImageCaculator,
> we don't have AnisotropicImagefilter and AnisotropicImageCalculators
> ... etc... That is, not every filter is duplicated into a calculator.
>
> This latter will be more a duplication of functionality (not to
> mention a maintenance nightmare).
>
>
> Calculators are a functional programming approach and they break away
> from the data pipeline architecture of the rest of the toolkit.
>
>
> If users are going to migrate and to learn a new framework,
> we should avoid cluttering it with the same weaknesses that
> we are trying to get away from.
>
>
> Given that we are not going to remove the existing Statistics
> Framework anyways, there is not much point into crippling the
> new Framework with the burden of being backward compatible with
> the structure that we already identified as having a number of
> design limitations.
>
>
> ---
>
> The rationale for the DensityFrequencyContainer being renamed as "2"
> is detailed in the Migration Guide, at:
> http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Migration_Users_Guide#Frequency_Containers
>
> It also lists the deperecated API (methods from the old class
> that are no longer available in the new class), and the New API
> (methods that replace the deprecated methods).
>
>
>
>   Luis
>
>