gdalgorithms-list

RE: [Algorithms] decompose onto non-orthogonal vectors

[Discoe, B. <ben...@in...>]

Hi Jonathan!

> This is one of those "fundamental linear algebra things"
> that Ron and I were just talking about.

Yeah.  I wonder why it's still so hard to find and express an answer..

> Just build a transformation matrix from R to S

Could you give me a hint how this is done?

> For instructions on how to make a matrix that goes from
> one space to another, given the basis vectors of each 
> space, consult any one of a trillion graphics books.

The answer apparently isn't in the books i have..

> > I promise i consulted an academic
> 
> What kind of academic was that?

A guy from the Stanford graphics lab, just left the phd program to work on
distributed rendering architectures.. he started on about barycentric
coordinates but couldn't give an actual answer.

Thanks,
Ben

RE: [Algorithms] decompose onto non-orthogonal vectors

[Discoe, B. <ben...@in...>]

> From: ro...@do... [mailto:ro...@do...]
>
> Chapter 1 in any linear algebra book.

I assure i looked in chapters 1 though 18 of my book ("calculus and analytic
geomtry", thomas/finney) and nothing resemling a formula for decomposing a
vector is anywhere in it.  In general, math textbooks tend to be concerned
with axioms and definitions, not with formulas that actually prove to be
useful.

> That is A SYSTEM OF TWO LINEAR EQUATIONS IN TWO UNKNOWNS u, v,
> which you ought to have learned to solve in intermediate algebra,

I was asking if somebody knew the solution, not for how to do the math,
which i'm willing to leave to people who enjoy re-deriving solutions to math
problems.

> 	u = (p1 b2 - p2 b1)/(a1 b2 - a2 b1)
> 	v = (a1 p2 - a2 p1)/(a1 b2 - a2 b1)

OK, i'll believe that after solving for v and substituting twice (a page or
so of algebra) you get that 2d solution.

> If the denominator (a1 b2 - a2 b1) is zero then it means that a and b
> are linearly dependent (i.e. collinear) and either it has no solution
> (if p is not also collinear with a and b) or infinitely many different
> solutions (if p is collinear with a and b)

The picture i drew showed a nondegenerate case.

> Now suppose that you are given this as a 3D problem, say
> 	a = (a1,  a2,  a3) and b = (b1, b2, b3)

Yes.  I'm sorry i forgot to state that i do have 3d vectors, and p is known
to lie in the plane formed by a and b.

> It may or may not have solutions..
> Cramer's rule does not apply here, but Gaussian elimination
> still does.

Is this your way of saying you don't know the answer?

It would be pretty sad if not a single person on the list knows the answer.
I was kinda hoping *you* would, Ron :)

> No, I will not belabor the list with a review of Gaussian elimination
> algorithms.  You will find one in Chapter 1 of your favorite linear
> algebra book.

The index in my textbook does not list "Gaussian elimination".

Thanks,
Ben
http://vterrain.org/

[Algorithms] Diatribe Re: decompose onto non-orthogonal vectors

[Jonathan B. <jo...@bo...>]

In advance I'll say that this diatribe is not directed straight at Ben;
it's to everyone on this list who isn't eager to learn math.


Ben Discoe wrote:

> I was asking if somebody knew the solution, not for how to do the math,
> which i'm willing to leave to people who enjoy re-deriving solutions to math
> problems.

The problem here is that modern graphics programming is *all about* math.
If you don't know the math, you can't play ball.

You shouldn't think of the question you asked as some isolated problem
that you ought to be able to look up in a book.  If this were the best
way to learn how to do things, then you'd need to look up hundreds of
little special-case problems in order to write a modern 3D program
that does interesting things.  And as you've seen, it's often hard
to find a lucid explanation of even one of these problems, even though
lots of people know how to do them.

To understand graphics publications and implement them, and
especially to do new work, you need to be fluent enough in certain
areas of math (linear algebra being a major one) that you just instinctively
know answers to problems like the one you posed.  Once you have this 
knowledge, you'll find that you look at problems in a different way.  
You'll skip over whole truckloads of questions that would have been really 
perplexing before, because now they're non-issues.  Months of programming
work that would have been misguided can now be eliminated.  The scope of things 
you can do will be vastly expanded.

Trying to do 3D graphics without linear algebra is like this: You want to
be a sculptor and create this cool statue called The Thinker, and you've
got the big block of stone, your hammer and chisel are sitting
there on the table... but unfortunately you cut your hands off last
month, so you're squeezing the chisel between two wrist-stumps and
holding the hammer in your mouth and trying to bang away.

It's not good for your dental work.

    -J.

[Algorithms] C++ inherited constructors

[Matt A. <de...@gm...>]

Hi,

I got a question about the C++ class hierarchy.

class a
{
    a () {...}; // constr a
};

class b : a
{
    b () {...}; // constr b
};

b instance;

When creating an instance of b, constructors for both class a and class b
are called.
Is there a way to suppress the automatic calling of constructor a ?
Or something like 'overloading' the old constructor by a new one ?
I couldn't find anything like that in the compiler docs.

Any help appreciated,
Matt

Re: [Algorithms] C++ inherited constructors

[Favnir <fa...@wi...>]

The only way you can do this is to define a (preferably) protected
do-nothing constructor for the base class, and inherit it in the =
subclass
constructor.

But, why in the world would you need to do this, in the first place?

Are,
F

  ----- Original Message -----=20
  From: Matt Adams=20
  To: gda...@li...=20
  Sent: Saturday, July 15, 2000 12:22 PM
  Subject: [Algorithms] C++ inherited constructors


  Hi,

  I got a question about the C++ class hierarchy.

  class a
  {
      a () {...}; // constr a
  };

  class b : a
  {
      b () {...}; // constr b
  };

  b instance;

  When creating an instance of b, constructors for both class a and =
class b
  are called.
  Is there a way to suppress the automatic calling of constructor a ?
  Or something like 'overloading' the old constructor by a new one ?
  I couldn't find anything like that in the compiler docs.

  Any help appreciated,
  Matt


  _______________________________________________
  GDAlgorithms-list mailing list
  GDA...@li...
  http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] C++ inherited constructors

[Matt A. <de...@gm...>]

I need this for aesthetic reasons :)
I've got an abstract CThread class. If a want to create a new thread, I
build my process class and inherit CThread, which creates a new thread by
construction.
Now I want my main-threadloop-class to inherit CThread, too, to provide all
the thread functionality to my main thread. But that thread already exists
 created by compiler ), and shouldn't be created again by CThread.
Of course I can put CThread () and ~CThread () in functions like Create()
and Destroy() and leave the constructor / destructor empty. But it'd be
nicer if it could be done in another way...

----- Original Message -----
From: Favnir
To: gda...@li...
Sent: Saturday, July 15, 2000 1:32 PM
Subject: Re: [Algorithms] C++ inherited constructors

The only way you can do this is to define a (preferably) protected
do-nothing constructor for the base class, and inherit it in the subclass
constructor.

But, why in the world would you need to do this, in the first place?

Are,
F

----- Original Message -----
From: Matt Adams
To: gda...@li...
Sent: Saturday, July 15, 2000 12:22 PM
Subject: [Algorithms] C++ inherited constructors


Hi,

I got a question about the C++ class hierarchy.

class a
{
    a () {...}; // constr a
};

class b : a
{
    b () {...}; // constr b
};

b instance;

When creating an instance of b, constructors for both class a and class b
are called.
Is there a way to suppress the automatic calling of constructor a ?
Or something like 'overloading' the old constructor by a new one ?
I couldn't find anything like that in the compiler docs.

Any help appreciated,
Matt


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] C++ inherited constructors

[Will P. <wi...@cs...>]

I don't completely understand your problem, but it might be solvable by
using containment rather than inheritance, i.e. a process *has* a thread
rather than *is* a thread.  I think it would allow for the semantics you
want.  You could pass in an external thread for the process/main loop to
"have" through a constructor argument, or you could just have the
process/main loop create a thread through it's default argumentless
constructor.

The same goes with your main loop class: it has a thread, not is a
thread.

It's an idea, anyway. :)

Will

----
Will Portnoy
http://www.cs.washington.edu/homes/will

On Sat, 15 Jul 2000, Matt Adams wrote:

> I need this for aesthetic reasons :)
> I've got an abstract CThread class. If a want to create a new thread, I
> build my process class and inherit CThread, which creates a new thread by
> construction.
> Now I want my main-threadloop-class to inherit CThread, too, to provide all
> the thread functionality to my main thread. But that thread already exists
>  created by compiler ), and shouldn't be created again by CThread.
> Of course I can put CThread () and ~CThread () in functions like Create()
> and Destroy() and leave the constructor / destructor empty. But it'd be
> nicer if it could be done in another way...
> 
> ----- Original Message -----
> From: Favnir
> To: gda...@li...
> Sent: Saturday, July 15, 2000 1:32 PM
> Subject: Re: [Algorithms] C++ inherited constructors
> 
> The only way you can do this is to define a (preferably) protected
> do-nothing constructor for the base class, and inherit it in the subclass
> constructor.
> 
> But, why in the world would you need to do this, in the first place?
> 
> Are,
> F
> 
> ----- Original Message -----
> From: Matt Adams
> To: gda...@li...
> Sent: Saturday, July 15, 2000 12:22 PM
> Subject: [Algorithms] C++ inherited constructors
> 
> 
> Hi,
> 
> I got a question about the C++ class hierarchy.
> 
> class a
> {
>     a () {...}; // constr a
> };
> 
> class b : a
> {
>     b () {...}; // constr b
> };
> 
> b instance;
> 
> When creating an instance of b, constructors for both class a and class b
> are called.
> Is there a way to suppress the automatic calling of constructor a ?
> Or something like 'overloading' the old constructor by a new one ?
> I couldn't find anything like that in the compiler docs.
> 
> Any help appreciated,
> Matt
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] C++ inherited constructors

[Matt A. <de...@gm...>]

This wouldn't solve the problem : When I create an instance of CThread ( or
if one is created by using containment )
the constructor is also called and therefore a new thread is created which I
dont want.
Yes and I don't want to create the instance by malloc() but by new or by
containment, which automatically call the constructor.
Anyway, since there's no way to suppress the constructor call, I chose a
workaround.
Aesthetic is not everything :)
Thanks for all the answers to this topic,
Matt

----- Original Message -----
From: Will Portnoy <wi...@cs...>
To: <gda...@li...>
Sent: Saturday, July 15, 2000 9:52 PM
Subject: Re: [Algorithms] C++ inherited constructors


> I don't completely understand your problem, but it might be solvable by
> using containment rather than inheritance, i.e. a process *has* a thread
> rather than *is* a thread.  I think it would allow for the semantics you
> want.  You could pass in an external thread for the process/main loop to
> "have" through a constructor argument, or you could just have the
> process/main loop create a thread through it's default argumentless
> constructor.
>
> The same goes with your main loop class: it has a thread, not is a
> thread.
>
> It's an idea, anyway. :)
>
> Will
>
> ----
> Will Portnoy
> http://www.cs.washington.edu/homes/will
>
> On Sat, 15 Jul 2000, Matt Adams wrote:
>
> > I need this for aesthetic reasons :)
> > I've got an abstract CThread class. If a want to create a new thread, I
> > build my process class and inherit CThread, which creates a new thread
by
> > construction.
> > Now I want my main-threadloop-class to inherit CThread, too, to provide
all
> > the thread functionality to my main thread. But that thread already
exists
> >  created by compiler ), and shouldn't be created again by CThread.
> > Of course I can put CThread () and ~CThread () in functions like
Create()
> > and Destroy() and leave the constructor / destructor empty. But it'd be
> > nicer if it could be done in another way...
> >
> > ----- Original Message -----
> > From: Favnir
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 1:32 PM
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> > The only way you can do this is to define a (preferably) protected
> > do-nothing constructor for the base class, and inherit it in the
subclass
> > constructor.
> >
> > But, why in the world would you need to do this, in the first place?
> >
> > Are,
> > F
> >
> > ----- Original Message -----
> > From: Matt Adams
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 12:22 PM
> > Subject: [Algorithms] C++ inherited constructors
> >
> >
> > Hi,
> >
> > I got a question about the C++ class hierarchy.
> >
> > class a
> > {
> >     a () {...}; // constr a
> > };
> >
> > class b : a
> > {
> >     b () {...}; // constr b
> > };
> >
> > b instance;
> >
> > When creating an instance of b, constructors for both class a and class
b
> > are called.
> > Is there a way to suppress the automatic calling of constructor a ?
> > Or something like 'overloading' the old constructor by a new one ?
> > I couldn't find anything like that in the compiler docs.
> >
> > Any help appreciated,
> > Matt
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] C++ inherited constructors

[Jim O. <j.o...@in...>]

> This wouldn't solve the problem : When I create an instance of CThread
 or
> ...
> Aesthetic is not everything :)

A formal (aesthetic) solution *could* be to define a common base class for
both your thread an application class, say Process:

class Process {
    /* Pure virtual stuff here */
    Process() { }

    virtual void execute()    = 0;
};

class Thread : public Process {
    /* Thread stuff goes here */
    Thread() { /* Intialize thread here */ }

    void execute();
};

class App : Process {
    App() { /* Initialize app here */ }

    void execute();
}

Jim Offerman

Innovade
- designing the designer

RE: [Algorithms] C++ inherited constructors

[Aaron D. <ri...@ho...>]

Why not have your base class constructor call a virtual private member
function and overload that function in the derived class?

> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On Behalf Of Matt
> Adams
> Sent: Saturday, July 15, 2000 9:19 PM
> To: gda...@li...
> Subject: Re: [Algorithms] C++ inherited constructors
>
>
>
> I need this for aesthetic reasons :)
> I've got an abstract CThread class. If a want to create a new thread, I
> build my process class and inherit CThread, which creates a new thread by
> construction.
> Now I want my main-threadloop-class to inherit CThread, too, to
> provide all
> the thread functionality to my main thread. But that thread already exists
>  created by compiler ), and shouldn't be created again by CThread.
> Of course I can put CThread () and ~CThread () in functions like Create()
> and Destroy() and leave the constructor / destructor empty. But it'd be
> nicer if it could be done in another way...
>
> ----- Original Message -----
> From: Favnir
> To: gda...@li...
> Sent: Saturday, July 15, 2000 1:32 PM
> Subject: Re: [Algorithms] C++ inherited constructors
>
> The only way you can do this is to define a (preferably) protected
> do-nothing constructor for the base class, and inherit it in the subclass
> constructor.
>
> But, why in the world would you need to do this, in the first place?
>
> Are,
> F
>
> ----- Original Message -----
> From: Matt Adams
> To: gda...@li...
> Sent: Saturday, July 15, 2000 12:22 PM
> Subject: [Algorithms] C++ inherited constructors
>
>
> Hi,
>
> I got a question about the C++ class hierarchy.
>
> class a
> {
>     a () {...}; // constr a
> };
>
> class b : a
> {
>     b () {...}; // constr b
> };
>
> b instance;
>
> When creating an instance of b, constructors for both class a and class b
> are called.
> Is there a way to suppress the automatic calling of constructor a ?
> Or something like 'overloading' the old constructor by a new one ?
> I couldn't find anything like that in the compiler docs.
>
> Any help appreciated,
> Matt
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] C++ inherited constructors

[Michael H. <he...@po...>]

You can't call virtual functions from constructors.  Doing so is
undefined in C++.  (MSVC will call the local instantiation, even when
there's an overloaded one, for instance.)

mike

----- Original Message -----
From: "Aaron Drew" <ri...@ho...>
To: <gda...@li...>
Sent: Sunday, July 16, 2000 12:41 AM
Subject: RE: [Algorithms] C++ inherited constructors


> Why not have your base class constructor call a virtual private
member
> function and overload that function in the derived class?
>
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On Behalf Of
Matt
> > Adams
> > Sent: Saturday, July 15, 2000 9:19 PM
> > To: gda...@li...
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> >
> >
> > I need this for aesthetic reasons :)
> > I've got an abstract CThread class. If a want to create a new
thread, I
> > build my process class and inherit CThread, which creates a new
thread by
> > construction.
> > Now I want my main-threadloop-class to inherit CThread, too, to
> > provide all
> > the thread functionality to my main thread. But that thread
already exists
> >  created by compiler ), and shouldn't be created again by CThread.
> > Of course I can put CThread () and ~CThread () in functions like
Create()
> > and Destroy() and leave the constructor / destructor empty. But
it'd be
> > nicer if it could be done in another way...
> >
> > ----- Original Message -----
> > From: Favnir
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 1:32 PM
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> > The only way you can do this is to define a (preferably) protected
> > do-nothing constructor for the base class, and inherit it in the
subclass
> > constructor.
> >
> > But, why in the world would you need to do this, in the first
place?
> >
> > Are,
> > F
> >
> > ----- Original Message -----
> > From: Matt Adams
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 12:22 PM
> > Subject: [Algorithms] C++ inherited constructors
> >
> >
> > Hi,
> >
> > I got a question about the C++ class hierarchy.
> >
> > class a
> > {
> >     a () {...}; // constr a
> > };
> >
> > class b : a
> > {
> >     b () {...}; // constr b
> > };
> >
> > b instance;
> >
> > When creating an instance of b, constructors for both class a and
class b
> > are called.
> > Is there a way to suppress the automatic calling of constructor a
?
> > Or something like 'overloading' the old constructor by a new one ?
> > I couldn't find anything like that in the compiler docs.
> >
> > Any help appreciated,
> > Matt
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>

Re: [Algorithms] C++ inherited constructors

[Peter D. <pd...@mm...>]

> You can't call virtual functions from constructors.  Doing so is
> undefined in C++.  (MSVC will call the local instantiation, even when
> there's an overloaded one, for instance.)

Actually you can, and it's well defined. The problem is that in the
constructor the static and the dynamic type of "this" are the same.

#include <iostream>

struct A
{
    virtual void f() const { std::cout << "A::f()\n"; }
};

void g(A const & a)
{
    a.f();
}

struct B: A
{
    B() { g(*this); }
    virtual void f() const { std::cout << "B::f()\n"; }
};

struct C: B
{
    virtual void f() const { std::cout << "C::f()\n"; }
};

int main()
{
    C c;
    return 0;
}

--
Peter Dimov
Multi Media Ltd.

Re: [Algorithms] C++ inherited constructors

[Timur D. <ti...@3d...>]

Because base constructor will not call member method virtually, it will call
base class method.

_______________________
 Timur Davidenko.
 3Dion Inc. (www.3dion.com)
 e-mail: ti...@3d...


----- Original Message -----
From: "Aaron Drew" <ri...@ho...>
To: <gda...@li...>
Sent: Sunday, July 16, 2000 9:41 AM
Subject: RE: [Algorithms] C++ inherited constructors


> Why not have your base class constructor call a virtual private member
> function and overload that function in the derived class?
>
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On Behalf Of Matt
> > Adams
> > Sent: Saturday, July 15, 2000 9:19 PM
> > To: gda...@li...
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> >
> >
> > I need this for aesthetic reasons :)
> > I've got an abstract CThread class. If a want to create a new thread, I
> > build my process class and inherit CThread, which creates a new thread
by
> > construction.
> > Now I want my main-threadloop-class to inherit CThread, too, to
> > provide all
> > the thread functionality to my main thread. But that thread already
exists
> >  created by compiler ), and shouldn't be created again by CThread.
> > Of course I can put CThread () and ~CThread () in functions like
Create()
> > and Destroy() and leave the constructor / destructor empty. But it'd be
> > nicer if it could be done in another way...
> >
> > ----- Original Message -----
> > From: Favnir
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 1:32 PM
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> > The only way you can do this is to define a (preferably) protected
> > do-nothing constructor for the base class, and inherit it in the
subclass
> > constructor.
> >
> > But, why in the world would you need to do this, in the first place?
> >
> > Are,
> > F
> >
> > ----- Original Message -----
> > From: Matt Adams
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 12:22 PM
> > Subject: [Algorithms] C++ inherited constructors
> >
> >
> > Hi,
> >
> > I got a question about the C++ class hierarchy.
> >
> > class a
> > {
> >     a () {...}; // constr a
> > };
> >
> > class b : a
> > {
> >     b () {...}; // constr b
> > };
> >
> > b instance;
> >
> > When creating an instance of b, constructors for both class a and class
b
> > are called.
> > Is there a way to suppress the automatic calling of constructor a ?
> > Or something like 'overloading' the old constructor by a new one ?
> > I couldn't find anything like that in the compiler docs.
> >
> > Any help appreciated,
> > Matt
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] C++ inherited constructors

[Jim O. <j.o...@in...>]

> Why not have your base class constructor call a virtual private member
> function and overload that function in the derived class?

I wouldn't rely on such a thing - vtable's tend to have a nasty habbit of
not being properly initialized in the constructor and desctructor. I once
spend far to much time hunting a bug which turned out to be a pure virtual
call in one of my inline destructors...

I'd either stick to Adam's good advise, or use the protected constructor
trick (note that this doesn't have to be the default constructor... I use a
Thread::Thread(bool doNotInitialize) internally).

Jim Offerman

Innovade
- designing the designer
----- Original Message -----
From: "Aaron Drew" <ri...@ho...>
To: <gda...@li...>
Sent: Sunday, July 16, 2000 9:41 AM
Subject: RE: [Algorithms] C++ inherited constructors


>
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On Behalf Of Matt
> > Adams
> > Sent: Saturday, July 15, 2000 9:19 PM
> > To: gda...@li...
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> >
> >
> > I need this for aesthetic reasons :)
> > I've got an abstract CThread class. If a want to create a new thread, I
> > build my process class and inherit CThread, which creates a new thread
by
> > construction.
> > Now I want my main-threadloop-class to inherit CThread, too, to
> > provide all
> > the thread functionality to my main thread. But that thread already
exists
> >  created by compiler ), and shouldn't be created again by CThread.
> > Of course I can put CThread () and ~CThread () in functions like
Create()
> > and Destroy() and leave the constructor / destructor empty. But it'd be
> > nicer if it could be done in another way...
> >
> > ----- Original Message -----
> > From: Favnir
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 1:32 PM
> > Subject: Re: [Algorithms] C++ inherited constructors
> >
> > The only way you can do this is to define a (preferably) protected
> > do-nothing constructor for the base class, and inherit it in the
subclass
> > constructor.
> >
> > But, why in the world would you need to do this, in the first place?
> >
> > Are,
> > F
> >
> > ----- Original Message -----
> > From: Matt Adams
> > To: gda...@li...
> > Sent: Saturday, July 15, 2000 12:22 PM
> > Subject: [Algorithms] C++ inherited constructors
> >
> >
> > Hi,
> >
> > I got a question about the C++ class hierarchy.
> >
> > class a
> > {
> >     a () {...}; // constr a
> > };
> >
> > class b : a
> > {
> >     b () {...}; // constr b
> > };
> >
> > b instance;
> >
> > When creating an instance of b, constructors for both class a and class
b
> > are called.
> > Is there a way to suppress the automatic calling of constructor a ?
> > Or something like 'overloading' the old constructor by a new one ?
> > I couldn't find anything like that in the compiler docs.
> >
> > Any help appreciated,
> > Matt
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] C++ inherited constructors

[Michael H. <he...@po...>]

Make class A's default constructor do nothing, and make a second one
that takes a useless argument.  You can do it like this:

class A {
protected:
    A()    {}    // B can call this, but users will get warnings if
they use it
public:
    A(bool x);
};

class B: public A {
public:
    B();        // calls A(), which does nothing
};

mike

----- Original Message -----
From: "Matt Adams" <de...@gm...>
To: <gda...@li...>
Sent: Saturday, July 15, 2000 3:22 AM
Subject: [Algorithms] C++ inherited constructors


> Hi,
>
> I got a question about the C++ class hierarchy.
>
> class a
> {
>     a () {...}; // constr a
> };
>
> class b : a
> {
>     b () {...}; // constr b
> };
>
> b instance;
>
> When creating an instance of b, constructors for both class a and
class b
> are called.
> Is there a way to suppress the automatic calling of constructor a ?
> Or something like 'overloading' the old constructor by a new one ?
> I couldn't find anything like that in the compiler docs.
>
> Any help appreciated,
> Matt
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>

Re: [Algorithms] C++ inherited constructors

[Gabor F. <xl...@po...>]

i don't know if you can supress it, but why do you want to do it?

object "a" must be constructed before the construction of "b" begins ,
and the only way to construct-initialize "a" is thru an "a"-constructor.

if you have access to the sources of "a" you can create an empty constructor
for "a"....

but once again... why?

Gabor


Gabor Farkas - student / Comenius University ,Slovak Republic
----
If my mad scientist/wizard tells me he has almost perfected my Superweapon
but it still needs more testing, I will wait for him to complete the tests.
No one ever conquered the world using a beta version.
(www.eviloverlord.com)
----

----- Original Message -----
From: "Matt Adams" <de...@gm...>
To: <gda...@li...>
Sent: Saturday, July 15, 2000 12:22 PM
Subject: [Algorithms] C++ inherited constructors


> Hi,
>
> I got a question about the C++ class hierarchy.
>
> class a
> {
>     a () {...}; // constr a
> };
>
> class b : a
> {
>     b () {...}; // constr b
> };
>
> b instance;
>
> When creating an instance of b, constructors for both class a and class b
> are called.
> Is there a way to suppress the automatic calling of constructor a ?
> Or something like 'overloading' the old constructor by a new one ?
> I couldn't find anything like that in the compiler docs.
>
> Any help appreciated,
> Matt
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] C++ inherited constructors

[Stephen J B. <sj...@li...>]

On Sat, 15 Jul 2000, Matt Adams wrote:

> I got a question about the C++ class hierarchy.

NO, NO, NO!!!

OFF TOPIC!!!

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] C++ inherited constructors

[Scott M. <sc...@3d...>]

This question would probably be more welcome on the Software Engineering
Gamedev list (sweng-gamedev).  Here's the info for it in case you're
interested.

------------------------------------------------

Welcome to the sweng-gamedev mailing list!

Please save this message for future reference.  Thank you.

If you ever want to remove yourself from this mailing list,
you can send mail to <Maj...@in...> with the following
command in the body of your email message:

    unsubscribe sweng-gamedev

or from another account, besides sc...@3d...:

    unsubscribe sweng-gamedev sc...@3d...

If you ever need to get in contact with the owner of the list,
(if you have trouble unsubscribing, or have questions about the
list itself) send email to <own...@in...> .
This is the general rule for most mailing lists when you need
to contact a human.

 Here's the general information for the list you've subscribed to,
 in case you don't already have it:

The Game Software Engineering List Charter
==========================================

Welcome to SwEng-Gamedev!

This list is provided as a forum for game developers to discuss and develop
software engineering strategies for developing their engines.  Discussion
of game patterns and other abstractions is heartily encouraged!  Case
studies (unless in violation of an NDA!) are also a welcome way to learn --
a game-engine autopsy of sorts.

Discussions of lower-level programming issues like individual algorithms
and their implementation is generally discouraged.  However, there are
exceptions; if an algorithm is of a broad enough scope that it deserves
abstractions in its implementation, for instance, it's worth discussing.
And nobody likes a list plagued by people shouting "OFF-TOPIC!  GET OUT!"
so let's generally try to allow for a little wiggle room in discussions.

Furthermore, as C/C++ are the primary languages used today for game
development, discussions of patterns will likely use reference
implementations or example headers in one of these languages.  Other
languages are certainly welcome, but before writing up an example in
Prolog, consider how useful it'll be to most of the list.  Furthermore,
this isn't an appropriate place to evangelize your favorite obscure
language.

Also, as alluded to above, it's important that discussions take
intellectual property laws and professionalism into account.  For every
subscriber, the following rules apply:

  1) Your company must know you are on this list.
  2) Assume all things you say on this list will be public.
  3) No open recruiting.

Hopefully, by sticking to these, we'll keep discussing both smoothly
flowing and also legal!

To send mail to the list, send to 'swe...@in...'.

Enjoy!

Re: [Algorithms] C++ inherited constructors

[Scott M. <sc...@3d...>]

My apologies, that last was meant for the original poster, not the list.

Re: [Algorithms] decompose onto non-orthogonal vectors

[<ro...@do...>]

Discoe, Ben  wrote:

>
>> From: ro...@do... [mailto:ro...@do...]
>>
>> Chapter 1 in any linear algebra book.
>
>I assure i looked in chapters 1 though 18 of my book ("calculus and analytic
>geomtry", thomas/finney) and nothing resemling a formula for decomposing a
>vector is anywhere in it. 

Ah, while that is a fine calculus book, it is not an elementary linear
algebra book.  The main point you missed is that the single vector
equation is a set of two (in 2D) or three (in 3D) scalar equations.

> In general, math textbooks tend to be concerned
>with axioms and definitions, not with formulas that actually prove to be
>useful.
>

This assertion betrays an utterly mathophobic attitude, which is
likely to hinder your continuing progress.  The fact is that a lot of
the math nonsense we see posted to lists like this simply results from
people not taking sufficient care to define their terms.

>> That is A SYSTEM OF TWO LINEAR EQUATIONS IN TWO UNKNOWNS u, v,
>> which you ought to have learned to solve in intermediate algebra,
>
>I was asking if somebody knew the solution, not for how to do the math,
>which i'm willing to leave to people who enjoy re-deriving solutions to math
>problems.
>
>> 	u = (p1 b2 - p2 b1)/(a1 b2 - a2 b1)
>> 	v = (a1 p2 - a2 p1)/(a1 b2 - a2 b1)
>

Again a statement that doesn't make much sense to me.  You can't learn
in advance all solutions to all problems. Education consists of
learning how to have the courage to attack problems whose solution you
don't already know.  It would have been no benefit at all to you to to
simply write down the above formulas, in fact it would have been wrong
because, as it turns out, you were actually thinking of the 3D version
of the problem.

That's another important relevant point.  There is no hope of solving
a problem, or even having a sensible discussion about it, if it is not
clearly and completely stated.  An enormous number of the math queries
that we see posted to newsgroups and email lists are impossible to
answer because they are not clearly stated, the problem statement
doesn't make sense.  Taking math courses from good teachers is one of
the best ways to improve ones understanding of when a problem
statement makes sense.

>OK, i'll believe that after solving for v and substituting twice (a page or
>so of algebra) you get that 2d solution.
>



>> If the denominator (a1 b2 - a2 b1) is zero then it means that a and b
>> are linearly dependent (i.e. collinear) and either it has no solution
>> (if p is not also collinear with a and b) or infinitely many different
>> solutions (if p is collinear with a and b)
>
>The picture i drew showed a nondegenerate case.
>

Yes, but whenever one writes down an algebraic formula that involves
division, one MUST ask under what conditions the divisor can be zero.
For good reasons, computers don't like to divide by zero.  

>> Now suppose that you are given this as a 3D problem, say
>> 	a = (a1,  a2,  a3) and b = (b1, b2, b3)
>
>Yes.  I'm sorry i forgot to state that i do have 3d vectors, and p is known
>to lie in the plane formed by a and b.
>

Apology accepted. See comment above. 

>> It may or may no have solutions..
>> Cramer's rule does not apply here, but Gaussian elimination
>> still does.
>
>Is this your way of saying you don't know the answer?
>
OF COURSE NOT.  

>It would be pretty sad if not a single person on the list knows the answer.
>I was kinda hoping *you* would, Ron :)
>

The point you have evidently missed is that in the 3D case nobody
knows the answer a prior, nobody can write down a simple algebraic
formula giving the answer.    The point is that the algorithm for
finding the answer in ANY case is just one of the basic techniques
that we learn in elementary linear algebra. 
 
Talk about "sad":    What makes me sad is prevalence of mathophobia.
What makes me sadder is that so few participants in this list could
help you here.  What makes me saddest is the posting of completely
erroneous solutions to problems such as this.

>> No, I will not belabor the list with a review of Gaussian elimination
>> algorithms.  You will find one in Chapter 1 of your favorite linear
>> algebra book.
>
>The index in my textbook does not list "Gaussian elimination".
>

Try a linear algebra textbook, not a calculus and analytic geometry
text book.

>Thanks,

Welcome

RE: [Algorithms] decompose onto non-orthogonal vectors

[Tom F. <to...@mu...>]

Throw one of the dimensions away (any one) - then you have only two
equations. NOW can you solve it? :-)

The third dimension will just give the same answer if p lies in the plane of
a and b. If it isn't, then it's not a well-formed question, and you'll need
another axis (c) to define a suitable basis. Then you have three dimensions
and three unknowns, which you solve as you stated.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Klaus Hartmann [mailto:k_h...@os...]
> Sent: 15 July 2000 15:01
> To: gda...@li...
> Subject: Re: [Algorithms] decompose onto non-orthogonal vectors
> 
> 
> 
> ----- Original Message -----
> From: Scott Justin Shumaker <sjs...@um...>
> To: <gda...@li...>
> Sent: Saturday, July 15, 2000 9:15 AM
> Subject: Re: [Algorithms] decompose onto non-orthogonal vectors
> 
> 
> > Okay, let me try and explain this as simply as possible.  
> You want to find
> > scalars u,v such that u*a + v*b = p.  Since these are 3-dimensional
> > vectors, you have 3 equations and 2 unknowns:
> >
> > u*a1 + v*b1 = p1
> > u*a2 + v*b2 = p2
> > u*a3 + v*b3 = p3
> >
> > where p1,p2,p3 are the coordinates of the point p, likewise 
> for a1,a2,a3
> > and a, and b1,b2,b3 and b.
> >
> > How do you solve a system of 3 linear equations with 2 
> unknowns?  If you
> > don't know Gaussian elimination, this can be done with some simple
> > algebraic rules and substituion.
> 
> Okay, this may become very embarrassing for me now... :) How 
> can you solve a
> system of 3 linear equations in two unknows, u, v, if they 
> cannot be reduced
> to two linear equations (for example, a2 = a3, b2 = b3, and 
> p2 = p3)???
> 
> Let's assume that we change the 3 linear equations as follows:
> 
> u*a1 + v*b1 + w*c1 = p1
> u*a2 + v*b2 + w*c2 = p2
> u*a3 + v*b3 + w*c3 = p3
> 
> Then there's a unique solution, if
> 
>       | a1 b1 c1 |
> det | a2 b2 c2 | != 0
>       | a3 b3 c3 |
> 
> If we set c1 = c2 = c3 = 0, then we have the same system as 
> above (yours),
> but with 3 unknowns:
> 
> u*a1 + v*b1 + w*0 = p1
> u*a2 + v*b2 + w*0 = p2
> u*a3 + v*b3 + w*0 = p3
> 
> Then
>                | a1 b1 0 |
> Dn = det | a2 b2 0  | = 0
>                | a3 b3 0 |
> 
> Since Dn = 0, we get a division by zero, and thus there's an 
> infinite number
> of solutions.
> 
> ... or did I just miss something???
> 
> Niki
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] decompose onto non-orthogonal vectors

[<ro...@do...>]

Tom Forsyth  wrote:

>Throw one of the dimensions away (any one) - then you have only two
>equations. NOW can you solve it? :-)
>
>The third dimension will just give the same answer if p lies in the plane of
>a and b. If it isn't, then it's not a well-formed question, and you'll need
>another axis (c) to define a suitable basis. 

Not true.  p can very well lie in the plane of a and b without that
plane being a coordinate plane.  In that case, the problem is well
formed and your solution will give the wrong answer.

Re: [Algorithms] decompose onto non-orthogonal vectors

[<ro...@do...>]

I  wrote:

>Tom Forsyth  wrote:
>
>>Throw one of the dimensions away (any one) - then you have only two
>>equations. NOW can you solve it? :-)
>>
>>The third dimension will just give the same answer if p lies in the plane of
>>a and b. If it isn't, then it's not a well-formed question, and you'll need
>>another axis (c) to define a suitable basis. 
>
>Not true.  p can very well lie in the plane of a and b without that
>plane being a coordinate plane.  In that case, the problem is well
>formed and your solution will give the wrong answer.

 Ooops, you are indeed correct.   But your solution does not detect
the ill-formed case.  And moreover, you do have to be careful about
which dimension to throw away.  If the thing does lie in one of the
coordinate planes then you can't throw away that dimension.  And you
can also use some intellegence about which coordiate plane to throw
away to minimize the errors.

[Algorithms] Quaternions in IK

[Auday <au...@so...>]

Hi all ,

Does any one know an efficient way of constraining quaternions in IK 
without factorizing them into 3 axis quaternions ?
Finding the required rotation quaternion in IK is pretty easy , but how can 
we make sure that it doesn't violate or 3 constrains of the 3DOFs of the 
joint ? what I'm doing now is factorizing the IK result quaternion of the 
joint into xrotation quaternion yrotation quaternion and zrotation 
quaternion , constrain them by their maximums and recombine them again , 
which is obviously a very expensive process.

any ideas ? or maybe references ?

Thanks

Auday

Re: [Algorithms] Quaternions in IK

[Jeff L. <je...@di...>]

I looked into this for quite a while some time ago.  I asked quite a few people about it as well.  The consensus is that everyone converts from Quaternion to Euler and back to handle DOF restrictions.  Intuitively it seems that there should be a way to restrict the motion of a quaternion to a particular portion of the hypersphere.  It is a bit beyond my math skills though.  I have a math grad starting work for me this month so I can put her on the task. :) No better research tool then a graduate student.

In implementation, for me the conversion isn't too severe.  I only calculate the IK solution when needed and I classify joints that are 1 DOF so they are not effected.

-Jeff

At 05:36 AM 9/3/2000 -0700, you wrote:
>Hi all ,
>
>Does any one know an efficient way of constraining quaternions in IK without factorizing them into 3 axis quaternions ?
>Finding the required rotation quaternion in IK is pretty easy , but how can we make sure that it doesn't violate or 3 constrains of the 3DOFs of the joint ? what I'm doing now is factorizing the IK result quaternion of the joint into xrotation quaternion yrotation quaternion and zrotation quaternion , constrain them by their maximums and recombine them again , which is obviously a very expensive process.
>
>any ideas ? or maybe references ?
>
>Thanks
>
>Auday
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list