Re: operator overloading .. more
From: ma740988 (ma740988_at_pegasus.cc.ucf.edu)
Date: 02/08/04
- Next message: J.: "What does this mean?"
- Previous message: Robert W Hand: "Re: operator overloading .. more"
- In reply to: Josh Sebastian: "Re: operator overloading .. more"
- Next in thread: Josh Sebastian: "Re: operator overloading .. more"
- Reply: Josh Sebastian: "Re: operator overloading .. more"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Feb 2004 17:14:26 -0800
Josh Sebastian <curien@cox.net> wrote in message news:<pan.2004.02.07.17.36.13.579861@cox.net>...
> On Sat, 07 Feb 2004 08:23:05 -0800, ma740988 wrote:
>
> >> How is a 5X5 MATRIX<float> an ARRAY<float>? I would argue that it is
> >> not.
> > Interesting ... My problem was I was thinking in terms of the
> > "machine". In effect - in my view a 5X5 becomes a 25 to ARRAY, and of
> > course that just how the "machine" views it. 25 pieces of float in
> > contiguous (I thikn ) memory
>
> Maybe. Or maybe it's not contiguous. For example,
>
> int statmat[5][5];
>
> will be 25 ints in a contiguous block of memory. But
>
> int** dynmat = new int[5];
> for(size_t i=0; i!=5; ++i)
> dynmat[i] = new int[5];
>
> will give 5 non-contiguous blocks of 5 contiguous ints.
How so??
>
> > Point well taken. Though in some respects, isn't this like discussing
> > which way to place the toilet paper on the roll?
>
> No, not in this case, I'm afraid. There is simply a better way. There are
> a couple of alternatives in the "better way", which do follow your
> analogy. But inheriting matrix from array is simply wrong.
This has been a very humbling experience. I'll have to change the
design :)
> No, he's saying
>
> class MATRIX {
> ARRAY<ARRAY<T> > my_array;
Intutively it seems obvious but, I must say that I dont completely
understand this syntax nonetheless i'm off reviewing it.
> // ...
> };
>
> > instead of the current approach. The same can be said for a vector
> > then
>
> What do you mean by "vector"? Do you mean the mathematical sense or the
> C++ sense. In C++ terminology, a vector is simply a resizeable array (and,
> counter-intuitively, a mathematical vector is a valarray -- go figure).
>
A few days ago i was trying to reconcile the difference between a
valarray and - if you will - a C++ array. My head was starting to spin
so I left with the conclusion (based on the msdn source code for
valarray) that valarrays is not resizable.
In any event, I'm interested in the C++ sense.
> > #ifndef VECTOR_H
> > #define VECTOR_H
> >
> > template < class T>
> > class VECTOR
> > {
> > ARRAY<T> my_array;
> >
> > };
> > #endif;
> > But then a vector multiplied by a matrix is a vector.
>
> You sure about that? My TI-85 is pretty insistent that they're
> incompatible data types. Even if you argued that you could multiply
>
> [[1]
> [[1 2 3]] * [2]
> [3]]
>
> you'd get a 1x1 matrix, which you might as well call a scalar.
Huh!!! An N * N matrix A multiplied by an N dimensional vector V
equals an M dimensional vector
>
> > but a vector is
> > an array isn't it or a 1 d array if you will?
>
> Mathematically, a vector is an ordered tuple. C++-wise, yes, a vector is
> an array (but not a mathematical array!).
>
> > So the vector should be
> > inherited. Correct?
>
> Depends on what you mean by "vector". :-}
> It also depends on how you intend to use them. If you mean for a vector to
> be a special-case of a matrix where the number of rows must be 1, then it
> might make sense to use inheritance. If you don't need to treat them as
> "the same", then no, it doesn't.
>
> Whenever you use public inheritance, think of the Liskov Substitution
> Principle (LSP), which is that if you have two types A and B, B should be
> publicly derived from A if and ONLY IF it is useful and sensical to use an
> object of type B anywhere it's sensible to use an object of type A.
>
Thanks for the pointer. I must look into LSP
> That doesn't seem to be the case with arrays and matrices, IMO, especially
> since you have a potentially infinite class hierarchy. Why stop with 2-D
> matrices? Why not 3-D, 4-D, N-D? Well, if an array is derived from a
> matrix, then it makes sense for a matrix to be derived from the 3-D
> version, which is derived from the 4-D version, which is... I think you
> get the point.
How could i effectively design the MATRIX class to account for n
dimensional MATRIX???
>
> If you can't model something correctly (which is the case with the above
> conceptual model), don't do it half-assed (please pardon my French). Come
> up with a way to model it well that is expressible in C++.
>
> > Unfortunately my compiler has no support for the STL algorithms, etc.
> > etc.
>
> Unless you're doing embedded work, there's no excuse for that. GCC and BCC
> are free.
embedded work. That it is. Trying to run a servo stabilization loop on
a DSP. Belive me i'm not a fan of reinventing the wheel. Boost is one
of those i'd like to start using but the level of sophistication will
certainly place my compiler in a tailspin.
>
> > so i cant use std::vector for the vector.
>
> So you meant C++ vectors? In that case, it doesn't make sense to multiply
> them at all.
>
> Josh
So now if i were to summarize.
[QUOTE]
"If you mean for a vector to be a special-case of a matrix where the
number of rows must be 1, then it might make sense to use
inheritance."
[QUOTE]
Yes
So now
template <class T>
class MATRIX
{
T *data;
int length;
public:
MATRIX();
MATRIX(int row, col);
~MATRIX();
MATRIX(const MATRIX<T>& v) ;
MATRIX<T>& operator =(const MATRIX<T> &original);
MATRIX<T>& operator= ( MATRIX<T> const & );
MATRIX<T>& operator= ( T const * );
// lots of other overloaded operators
// later
MATRIX<T>& operator*= (const MATRIX<T>& );
MATRIX<T>& operator*= (const T );
MATRIX<T> operator*(const MATRIX<T>& ) const;
MATRIX<T> operator*(T ) const;
ARRAY<ARRAY<T> > my_array; // key
};
template <class T>
class ARRAY
{
};
template <class T>
class VECTOR : public ARRAY
{
};
- Next message: J.: "What does this mean?"
- Previous message: Robert W Hand: "Re: operator overloading .. more"
- In reply to: Josh Sebastian: "Re: operator overloading .. more"
- Next in thread: Josh Sebastian: "Re: operator overloading .. more"
- Reply: Josh Sebastian: "Re: operator overloading .. more"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
