Andre Wobst <wobsta@...>:
> Ok, lets do some ASCII art (is it art?):
> /x'\ /a b\/x\ /e\
> | | =3D | || | + | |
> \y'/ \c d/\y/ \f/
> If you do not define the transformation matrix (i.e. the variables a,
> b, c, and d) and you also keep the point p, i.e. x and y, variable,
> the left hand side contains terms like a*x, which is non-linear.
> You may, at a later point, find out, that you already know the value
> of x, for example. Than the term becomes linear ...
Ah, right. Indeed. Intuitively it just seems underdetermined if you're
trying to find out the transform *and* the points, even if you know
enough to make it, say, a quadratic problem (or something).
In practical applications I guess you'd always(?) know enough about
the points to get rid of such non-linear terms.
> And I think, that's what needs to be coded.
Right. I have no idea (off the top of my head, at least) how one would
deal with that; just a bit of book-keeping, perhaps? ;)
> Or just think what we can code right now after thinking about the
> problem. I think its not that complex.
> Those non-linear terms might be hidden in some additional
> "non-linear variable" in a code along the lines I've started. Should
> be possible. Just replace a*x by AX and keep on going.
Sounds like a clever move.
> Once a or x becomes available by other means, the "non-linear
> variable" can be resolved and a linear equation is restored.
Yeah -- a bit of book-keeping, still...
> What's also needed are equations for 2d points etc., but those might
> be build on top of the term class as well.
I'm dealing with these email out of order, so I guess this part is
already solved (by your vector equation code).
> So I think, yes, we can really get this working ...
> PS: I've also seen your comment about isinstance. Right. Currently I'm
> using it in this solver code to differenciate in __add__ etc.
> between the different types. Not yet perfect, right ... ;-)
> (I've the Python Cookbook and read about isstring, yes.)
Heh. It works, for now; just thought I'd mention it. Perhaps the code
can be made more generic at some later stage (so that I can, for
example, multiply terms by a number-like class without having to
subclass int or the like).
BTW: Unless you're targeting old Pythons (maybe you are?) you don't
have to use types.IntType and the like; just use int (and float and
long). e.g. isinstance(foo, (int, float, long)). (No big point, as
types.IntType is simply int and so forth.)
Magnus Lie Hetland "Canned Bread: The greatest thing since sliced
http://hetland.org bread!" [from a can in Spongebob Squarepants]