Re: [Lapackpp-devel] Updated display for lapackpp to display matrices in MATLAB and MAPLE formats

[Christian S. <sti...@tu...>]

Hi Jacob,

Jacob (Jack) Gryn schrieb:
>>- Could you please move the enum pFormat into the LaPreference class
>>instead of having it as a global type? 
> 
> I didn't know I can do typedefs inside class definitions, but I'll play
> around with it.  I may need to change the num type to an int, and use a few
> definitions.  The problem with this is that you'd always need to check if
> the value is valid.    In any case, when using the enum type, aren't the
> possible values restricted only to the scope of those variables?

Errr... IIRC you can surely have typedefs inside classes. That's what 
the STL uses all the time. Anyway, I've been using enums in classes 
before, see e.g.
http://simthetic.sourceforge.net/simthetic/api-doc/html/propertylist_8h-source.html

class Property {
   public:
     enum p_type { bool_t, int_t, /*...*/ };
     //...
}

(The expected result is obtained with or without typedef; I'm not 
totally sure why one or the other was better.)

>>- Right now the code of the LaGenMatDouble class is copied into
>>LaGenMatFloat. Since printing of matrices is not at all time-critical, I
>>was wondering whether you can get rid of this code duplication by
>>calling the LaGenMatDouble::operator<< from the
>>LaGenMatFloar::operator<< with a locally converted copy of the Float
>>matrix? 
> 
> I know, this bothered me as well that I had to make a copy.  Can I easily
> convert the datatypes from LaGenMatFloat to LaGenMatDouble?  

No, you cannot easily copy these all at once. You can only create a new 
matrix and then copy all elements one-by-one, because only the 
conversion from one float to one double is well-defined.

> This is why I
> think using a class inheritance system for all the matrices and vectors
> would be better.

We have discussed this before, haven't we? In short, this would only be 
possible if the element access functions were virtual functions, and 
this adds an extra vtable lookup for each element access, which is a 
considerable overhead which is not tolerable. Therefore the element 
access functions *must* stay inline functions which means they cannot be 
virtual, and this in turn means that any class inheritance is rather 
pointless.

>>- Your explanation is quite nice. Can you add that to laprefs.h in
>>doxygen format? That way, other people would immediately find this, too.
> 
> Ok.  I'll try and do this.
> 
> Jack

Thanks.

Christian