[Insight-developers] class name abbreviations

John M. Galeotti jgaleotti@cmu.edu
Thu, 17 Apr 2003 17:48:21 -0400


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