lapackpp-devel

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

[Jacob \(Jack\) G. <jg...@cs...>]

Ok.

 

So I've committed the addition of an LaPreferences class, along with
modified LaGenMatDouble, LaGenMatFloat, and LaGenMatComplex classes to
support the new output formats (only operator<< has changed, along with the
additional include of LA_PREFS_H).  

 

The following is how one would modify the output display format to be
compatible with their favourite math program:

 

Place

#include LA_PREFS_H  

In the include statements, somewhere after "lafnames.h"

 

At the beginning of your code, call

 

LaPreferences::setPrintFormat(pFormat p, bool newlines);

 

Where pFormat is an enum type, that can be one of the following {NORMAL,
MATLAB, MAPLE}, 

and bool newlines toggles multiline matrix output (true = places a newline
after each matrix row, false uses only the appropriate MATLAB/MAPLE
delimiter) - this option is ignored if pFormat == NORMAL

 

Enjoy! :-)

 

BTW, I only did those 3 classes for now, it would take a while for me to
implement and test all the classes, many of which I've never used before;
but if anyone wants, feel free to make appropriate changes based on what's
been done to gmc.cc, gmd.cc, gmf.cc.  

 

I really think it would be simpler to do if the matrix classes were derived
from a single base class, so only one version of the operator<< would be
needed (except for the ones with complex #'s).

 

Jack

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

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

Dear Jacob,

ok, thanks f=FCr adding this. It looks quite nice. Just some small=20
nitpicking from my side:

- Could you please move the enum pFormat into the LaPreference class=20
instead of having it as a global type? Currently, the symbols NORMAL,=20
MATLAB, MAPLE are global values of the enum and might very well collide=20
with some defines or whatever in some application. If they are inside=20
the LaPreference class, they can be used as LaPreference::NORMAL=20
everywhere and will avoid any collisions.

- Right now the code of the LaGenMatDouble class is copied into=20
LaGenMatFloat. Since printing of matrices is not at all time-critical, I=20
was wondering whether you can get rid of this code duplication by=20
calling the LaGenMatDouble::operator<< from the=20
LaGenMatFloar::operator<< with a locally converted copy of the Float=20
matrix? That way, the actual implementation of the output code would=20
only exist once for doubles, and once for complex, but not more than that.

- Your explanation is quite nice. Can you add that to laprefs.h in=20
doxygen format? That way, other people would immediately find this, too.

Thanks for this contribution. If you are satisfied with the result, I=20
would prepare a new release (2.1.3 or 2.2.0).

Christian


Jacob (Jack) Gryn schrieb:

> Ok.
>=20
> =20
>=20
> So I=92ve committed the addition of an LaPreferences class, along with=20
> modified LaGenMatDouble, LaGenMatFloat, and LaGenMatComplex classes to=20
> support the new output formats (only operator<< has changed, along with=
=20
> the additional include of LA_PREFS_H).=20
>=20
> =20
>=20
> The following is how one would modify the output display format to be=20
> compatible with their favourite math program:
>=20
> =20
>=20
> Place
>=20
> #include LA_PREFS_H=20
>=20
> In the include statements, somewhere after =93lafnames.h=94
>=20
> =20
>=20
> At the beginning of your code, call
>=20
> =20
>=20
> LaPreferences::setPrintFormat(pFormat p, bool newlines);
>=20
> =20
>=20
> Where pFormat is an enum type, that can be one of the following {NORMAL=
,=20
> MATLAB, MAPLE},
>=20
> and bool newlines toggles multiline matrix output (true =3D places a=20
> newline after each matrix row, false uses only the appropriate=20
> MATLAB/MAPLE delimiter) =96 this option is ignored if pFormat =3D=3D NO=
RMAL
>=20
> =20
>=20
> Enjoy! J
>=20
> =20
>=20
> BTW, I only did those 3 classes for now, it would take a while for me t=
o=20
> implement and test all the classes, many of which I=92ve never used=20
> before; but if anyone wants, feel free to make appropriate changes base=
d=20
> on what=92s been done to gmc.cc, gmd.cc, gmf.cc. =20
>=20
> =20
>=20
> I really think it would be simpler to do if the matrix classes were=20
> derived from a single base class, so only one version of the operator<<=
=20
> would be needed (except for the ones with complex #=92s).
>=20
> =20
>=20
> Jack
>=20

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

[Jacob \(Jack\) G. <jg...@cs...>]

> -----Original Message-----
> From: lap...@li... =
[mailto:lapackpp-devel-
> ad...@li...] On Behalf Of Christian Stimming
> Sent: Thursday, March 17, 2005 3:24 AM
> To: Jacob (Jack) Gryn
> Cc: lap...@li...
> Subject: Re: [Lapackpp-devel] Updated display for lapackpp to display
> matrices in MATLAB and MAPLE formats
>=20
> Dear Jacob,
>=20
> ok, thanks f=FCr adding this. It looks quite nice. Just some small
> nitpicking from my side:
>=20
> - Could you please move the enum pFormat into the LaPreference class
> instead of having it as a global type? Currently, the symbols NORMAL,
> MATLAB, MAPLE are global values of the enum and might very well =
collide
> with some defines or whatever in some application. If they are inside
> the LaPreference class, they can be used as LaPreference::NORMAL
> everywhere and will avoid any collisions.

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?

> - 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? That way, the actual implementation of the output code would
> only exist once for doubles, and once for complex, but not more than =
that.

I know, this bothered me as well that I had to make a copy.  Can I =
easily
convert the datatypes from LaGenMatFloat to LaGenMatDouble?  This is why =
I
think using a class inheritance system for all the matrices and vectors
would be better.

> - 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 for this contribution. If you are satisfied with the result, I
> would prepare a new release (2.1.3 or 2.2.0).
>=20
> Christian
>=20
>=20
> Jacob (Jack) Gryn schrieb:
>=20
> > Ok.
> >
> >
> >
> > So I=92ve committed the addition of an LaPreferences class, along =
with
> > modified LaGenMatDouble, LaGenMatFloat, and LaGenMatComplex classes =
to
> > support the new output formats (only operator<< has changed, along =
with
> > the additional include of LA_PREFS_H).
> >
> >
> >
> > The following is how one would modify the output display format to =
be
> > compatible with their favourite math program:
> >
> >
> >
> > Place
> >
> > #include LA_PREFS_H
> >
> > In the include statements, somewhere after =93lafnames.h=94
> >
> >
> >
> > At the beginning of your code, call
> >
> >
> >
> > LaPreferences::setPrintFormat(pFormat p, bool newlines);
> >
> >
> >
> > Where pFormat is an enum type, that can be one of the following =
{NORMAL,
> > MATLAB, MAPLE},
> >
> > and bool newlines toggles multiline matrix output (true =3D places a
> > newline after each matrix row, false uses only the appropriate
> > MATLAB/MAPLE delimiter) =96 this option is ignored if pFormat =3D=3D =
NORMAL
> >
> >
> >
> > Enjoy! J
> >
> >
> >
> > BTW, I only did those 3 classes for now, it would take a while for =
me to
> > implement and test all the classes, many of which I=92ve never used
> > before; but if anyone wants, feel free to make appropriate changes =
based
> > on what=92s been done to gmc.cc, gmd.cc, gmf.cc.
> >
> >
> >
> > I really think it would be simpler to do if the matrix classes were
> > derived from a single base class, so only one version of the =
operator<<
> > would be needed (except for the ones with complex #=92s).
> >
> >
> >
> > Jack
> >
>=20
>=20
>=20
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real =
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
> _______________________________________________
> lapackpp-devel mailing list
> lap...@li...
> https://lists.sourceforge.net/lists/listinfo/lapackpp-devel