[Insight-developers] class name abbreviations

Fri, 18 Apr 2003 15:11:20 -0400

After doing some thinking and talking with George, I have an idea for 
how to simplify things a little, but my idea raises a semantic 
question.  I could eliminate the intermediate 
DifferentiableParametricPath class if I implement a very simple and 
naive numerical derivative virtual function in the ParametricPath 
class, and then overload that function with a proper closed-form 
derivative function in the FourierSeriesParametricPath function.  The 
benefit of ParametricPath class having a numeric derivative virtual 
function is that users of ITK could still create their own descendants 
of ParametricPath without having to worry about implementing derivative 
functions that they may not need.  In essence, I would be creating a 
numeric derivative "place holder" virtual function that I never intend 
to actually use, and I would document the function as such.  Is such a 
place holder acceptable?  If not, would someone else be willing to 
implement a modern numeric-derivative member function some time?

On Thursday, April 17, 2003, at 05:48 PM, John M. Galeotti wrote:

> I Agree the "Function" should probably be dropped if abbreviations are 
> not allowed.
>
> My reason for making a separate DifferentiableParametricPath class is 
> not that some types of parametric paths would not be C0, but rather 
> that I did not want to force users to implement a 
> spatial-derivative-of-path function for every parametric path class 
> they may want to create for their own code.  I am using the 
> spatial-derivative to find the normal to the path at a given point.
>
> I am reserving the word "parametric" for those paths that have a 
> "direct" mapping from input to output index, as opposed to chain codes 
> which must iterate over their input to find an output index.  Also, 
> parametric functions exist in continuous ND space, and loose their 
> "infinite" precision when mapped to index space; chain codes, on the 
> other hand, natively exist in index space, requiring interpolation for 
> sub-pixel operations.
>
> On Thursday, April 17, 2003, at 11:50 AM, Miller, James V (Research) 
> wrote:
>
>> At a minimum, you can probably drop the "Function" from these.
>>
>> FunctionBase
>> Path
>> ParametricPath
>> ***DifferentiableParametricPath***
>> FourierSeriesParametricPath
>>
>> Is the DifferentiableParametricPath class needed? Won't all 
>> parametric paths
>> be differentiable? At polyline isn't differentiable at the vertices 
>> but you
>> can probably adopt a convention for the derivative at a vertex that is
>> suitable for the types of operations you want to do on a path. I 
>> imagine
>> all the paths of interest here are at least C0.
>> Along this train of thought, are there any paths that you cannot 
>> consider
>> parametric? If a path cannot be parameterized by arc-length, how do 
>> you walk
>> the path? I have used polylines are parametric curves for defining
>> ruled surfaces, probes into data sets, etc. So the hierarchy could be
>>
>> FunctionBase
>> ParametricPath (or just Path)
>> FourierSeriesParametricPath (or just FourierSeriesPath)
>>
>> (On a side note, what are you trying to take the derivative of?  The
>> parametric curve? Or the (image) data under the curve? )
>>
>> Another alternative is to follow the FEM pattern of using C0, C1, C2, 
>> etc.
>> to indicate the continuity of the path (and thus how many derivatives 
>> are
>> supported by the path). This may not be appropriate here since 
>> something
>> like a B-Spline class could represent any number of derivatives, with
>> the programmer specifying at run-time the order of the spline.
>>
>>
>>
>>> -----Original Message-----
>>> From: John M. Galeotti [mailto:jgaleotti@cmu.edu]
>>> Sent: Thursday, April 17, 2003 11:27 AM
>>> To: Luis Ibanez
>>> Cc: Lorensen, William E (Research);
>>> insight-developers@public.kitware.com
>>> Subject: Re: [Insight-developers] class name abbreviations
>>>
>>>
>>> I suppose a better question then would be how much I need to included
>>> the names of parents in the names of children, when I intend for the
>>> children to actually be used as instances of the parents.  In this
>>> specific case,
>>> FourierSeriesDifferentiableParametricFunctionPath would
>>> actually be used as an argument to a function requiring a
>>> DifferentiableParametricFunctionPath object, etc.  So, with that in
>>> mind, is it still fine to drop the "DifferentiableParametricFunction"
>>> part from the long FourierSeries... name?
>>>
>>> FourierSeriesDifferentiableParametricFunctionPath derives from
>>> DifferentiableParametricFunctionPath which derives from
>>> ParametricFunctionPath which derives from
>>> Path which derives from
>>> FunctionBase
>>>
>>> John
>>> jgaleotti@cmu.edu
>>>
>>> On Thursday, April 17, 2003, at 10:47 AM, Luis Ibanez wrote:
>>>
>>>>
>>>> John,
>>>>
>>>> I may be missing something here, but...
>>>> as far as I understand, Fourier Series are
>>>> always "Parametric" and are always "Differentiable",
>>>>
>>>> so it is probably safe to name the class just:
>>>>
>>>>       "FourierSeriesPath"
>>>>
>>>> It may still derive from a base class
>>>>
>>>>     "DifferentiableParametricPath"
>>>>
>>>>
>>>> If there is any functionality that can be factorized.
>>>>
>>>>
>>>>    Luis
>>>>
>>>>
>>>> ----------------------------------
>>>> Lorensen, William E (Research) wrote:
>>>>> How about
>>>>> FourierSeriesParametricPath
>>>>> FourierDifferentiableParametricPath
>>>>> FourierSeriesDifferentiablePath
>>>>> Your abbreviation is far too terse.
>>>>> Bill
>>>>> -----Original Message-----
>>>>> From: John M. Galeotti [mailto:jgaleotti@cmu.edu]
>>>>> Sent: Thursday, April 17, 2003 5:18 AM
>>>>> To: insight-developers@public.kitware.com
>>>>> Subject: [Insight-developers] class name abbreviations
>>>>> Although abbreviations are discouraged in ITK, I plan to
>>> add a class
>>>>> to ITK with a 49 character name, specifically
>>>>> FourierSeriesDifferentiableParametricFunctionPath.  Is there a
>>>>> standard way I should go about abbreviating some of those
>>> words?  Is
>>>>> the name FSDiffParamFuncPath to terse?
>>>>> John Galeotti
>>>>> jgaleotti@cmu.edu
>>>>> _______________________________________________
>>>>> Insight-developers mailing list
>>>>> Insight-developers@public.kitware.com
>>>>> http://public.kitware.com/mailman/listinfo/insight-developers
>>>>> _______________________________________________
>>>>> Insight-developers mailing list
>>>>> Insight-developers@public.kitware.com
>>>>> http://public.kitware.com/mailman/listinfo/insight-developers
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Insight-developers mailing list
>>>> Insight-developers@public.kitware.com
>>>> http://public.kitware.com/mailman/listinfo/insight-developers
>>>
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers@public.kitware.com
>>> http://public.kitware.com/mailman/listinfo/insight-developers
>>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers@public.kitware.com
>> http://public.kitware.com/mailman/listinfo/insight-developers
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers