[Insight-developers] NumericTraits for RGBPixel

Bradley Lowekamp blowekamp at mail.nih.gov
Thu Jan 15 11:46:19 EST 2009


Hello Rupert,

That wiki page looks familiar. Yes, this definition of operator< does  
define a product order on a Cartesian product and it causes a strict  
partial order. I would be quite interested in any uses of this is  
definition for c++. As this would not be compatible with common sort  
algorithms.

I am not sure about your new definition, but these are the 3 that  
wikipedia outlines for essentially our case:

     * Lexicographical order: (a,b) ≤ (c,d) if and only if a < c or  
(a = c and b ≤ d).
     * (a,b) ≤ (c,d) if and only if a ≤ c and b ≤ d (the product  
order).
     * (a,b) ≤ (c,d) if and only if (a < c and b < d) or (a = c and b  
= d) (the reflexive closure of the direct product of the corresponding  
strict total orders).

Currently the second is implemented. I don't know why this was chosen.  
If the first one was implemented it'd would cause this class to be  
well ordered or totally ordered making this operator behave as one  
would expect it to. (The meaning in terms of RGB, may not be meaning  
full, but one could uses sorting and searching algorithms to find the  
same element.)

Aside from all this if

max is defined as:
< Type::max(), Type::max(), Type::max() >

then
There does not exist an element such that:
max < (does not exits) => true

it's just not unique :)
But weather that's a useful concept, I don't know.
And I am not even going to bring up the issue of distance and the  
operator- (opps).

Brad



On Jan 15, 2009, at 7:22 AM, Rupert Brooks wrote:

> Hi Brad,
>
> I'll just point out that this < operator, as defined on RGBPixel,
> defines a strict partial ordering of the set (see
> http://en.wikipedia.org/wiki/Partially_ordered_set ).  I would
> therefore hesitate to call it a bug.  You are correct though that it
> does not define a maximum.
>
> Whether its a useful or well documented concept is open to debate.
> Myself, i have never used RGBPixel in ITK, so i have no experience
> with it to offer.
>
> At first thought - i think that if the non strict partial ordering <=
> (which may or may not be defined, i didnt check) is used, then a
> unique maximum can be defined as
> < Type::max(), Type::max(), Type::max() >  All other elements are <=
> to this one.  I think the same result could be achieved by redefining
> < as meaning
> "having any element less than, and no element greater than"
>
> Check my math though, its early :-)
>
> Cheers,
> Rupert B.
>
> On Wed, Jan 14, 2009 at 11:39 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Hello,
>> I see that < is in fact defined for RGBPixelType:
>> /**
>> * Returns the results from a test for less than (all components  
>> must be
>> less than)
>> */
>> template<class T>
>> bool
>> RGBPixel<T>
>> ::operator<(const Self & r) const
>> {
>>  for( unsigned int i=0; i<3; i++)
>>    {
>>    if((*this)[i] >= r[i])
>>      {
>>      return false;
>>      }
>>    }
>>  return true;
>> }
>> Hrmm... this is a very "interesting" definition of the < operator.  
>> It does
>> not produce a well ordered set. It is logically inconsistent. And  
>> you can
>> not define a unique maximum from it. Consider the following:
>> Let a = (1,0,0) and b = (0,1,0)
>> as defined above:
>> a < b =>false
>> b < a => false
>> a == b => false
>> Let  c = (255, 255, 255)  and d = (255, 0, 0)
>> c < d => false;
>> d < c => false;
>> c == d => false;
>>
>> By interesting, I mean I'd like to call it a bug.
>> Brad
>>
>>
>> On Jan 14, 2009, at 10:51 AM, Bradley Lowekamp wrote:
>>
>> Hello,
>> ITK does not have max defined for any of the vector or array like  
>> classes
>> either. I am pretty sure that this was done on purpose.
>>
>> From a theoretical point of view, a maximum is defined as the  
>> greatest
>> element in a set. This essentially implies that the set can be  
>> ordered and
>> have comparative operators. I don't think this is true for vector- 
>> like
>> elements.
>>
>> Does the connected components algorithm need the max trait?
>>
>> Brad
>> On Jan 14, 2009, at 9:18 AM, Gaëtan Lehmann wrote:
>>
>> Hi,
>>
>> I'm fixing the bug uncovered by Julien Michel in
>> ConnectedComponentImageFilter with RGB images as input, and want to  
>> add a
>> test for it.
>> However, I can't succeed to build the modified test because
>> itk::NumericTraits< RGBPixelType< unsigned char > >::max() is not  
>> defined.
>> Is it done on purpose?
>>
>> Also, some functions defined in those numeric traits look  
>> suspicious to me,
>> like
>>
>> typedef _TYPENAME_ NumericTraits<T>::RealType        
>> ElementRealType; \
>> typedef RGBPixel<ElementRealType>         RealType; \
>> static const RealType max( const Self & a ) \
>>   {  \
>>     RealType b(a.Size());  \
>>     b.Fill( NumericTraits< T >::max() ); \
>>     return b; \
>>   } \
>>
>> Why should max( const Self & a ) return a RealType? Why b inside the
>> function is filled with the size of a (which is always 3), and then  
>> filled
>> with zeros?
>> For the scalar types, that function simply return the value of max().
>>
>> Regards,
>>
>> Gaëtan
>>
>>
>> --
>> Gaëtan Lehmann
>> Biologie du Développement et de la Reproduction
>> INRA de Jouy-en-Josas (France)
>> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
>> http://voxel.jouy.inra.fr  http://www.mandriva.org
>> http://www.itk.org  http://www.clavier-dvorak.org
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>> ========================================================
>> Bradley Lowekamp
>> Lockheed Martin Contractor for
>> Office of High Performance Computing and Communications
>> National Library of Medicine
>> blowekamp at mail.nih.gov
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>> ========================================================
>>
>> Bradley Lowekamp
>>
>> Lockheed Martin Contractor for
>>
>> Office of High Performance Computing and Communications
>>
>> National Library of Medicine
>>
>> blowekamp at mail.nih.gov
>>
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
>
>
>
> -- 
> --------------------------------------------------------------
> Rupert Brooks, Ph. D.
>
> Attaché de recherches | Research Associate
> Simulation des Matériaux Déformables | Simulation of Deformable  
> Materials
> Institut des matériaux industriels | Industrial Materials Institute
> Conseil national de recherches Canada | National Research Council  
> Canada
> 75, de Mortagne, Boucherville, Québec, Canada, J4B 6Y4
> Gouvernement du Canada | Government of Canada

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090115/529ac12d/attachment.htm>


More information about the Insight-developers mailing list