Thanks for taking a look at my post, but unless I have missed
something very obvious y should be quadratic, you seem to have lost
some astrices when you copied the equation.
The values given were constructed in Geogebra and the answer should be
x = 4.4, y = 2.22 which I checked manually so I'm pretty sure it's
correct.

Also, I suppose I should have stated the whole of my thoughts on this
as well. I'm actually ok with the last solution in my code for the 2D
case but I would like to solve the intersection of
hyperboloids of two sheets for which the last solution method doesn't
seem to apply very well. To give a little more background the inputs
to the method are times of arrival of a wave such as sound at
synchronized receivers ( trilateration / multilateration ) which will
be determined by correlation and peak detection. I've been playing
with some image alignment code and I think  I can get that working
without too much fuss.
The equations I would eventually like to solve are :

    eq1 = y**2/(e**2 - a) + z**2/(e**2 - a) - (x + e)**2/a + 1
    eq2 = x**2/(e**2 - b) + z**2/(e**2 - b) - (y - e)**2/b + 1
    eq3 = y**2/(e**2 - c) + z**2/(e**2 - c) - (x - e)**2/c + 1
    eq4 = ((x - e)/r2 + (y - e)/r2)**2/(2*e**2 - d) + z**2/(2*e**2 -
d) - (-(x - e)/r2 + (y - e)/r2)**2/d + 1
    # for four receivers there would be a fifth difference of the form
of eq5 but  I was to lazy to derive it, probably just toggles a couple
term signs anyway.

    s = solve([eq1, eq2, eq3, eq4], [x, y,z])

Now I know I can solve eq1 and eq3 for the value(s) of x, I still am
working on applying some kind  of insight to the rest  of these to get
y and z in a timely fashion.

I had not seen the  as_numer_denom method in the docs yet, I'll see
what fun can be had with that. I always forget about the _  for recent
results in python thanks for the reminder.

Indeed CAS certainly lack in intuition, even if I give solve
    eqs1 = eq1/eq1.coeff(y**2)
    eqs3 = eq3/eq3.coeff(y**2)

    xs = solve([eqs1, eqs3], x)

Which would be obvious for a human it can't solve it unless I give it
the first step.

    xs = solve(eqs1 - eqs3, x)

It appears after playing around a bit the form it gets  stuck on is:

    9.81136146495961 + 0.45513230707436*z**2 - 18.9262373938263*(1.5 -
y)**2

As you had indicated it doesn't seem to have a rule for the root of a
sum, nice to see that you already have that as a planned feature :)
As an aside I really like that you always have the pure python
implementation available, wish scipy would've done that too.
So I'll break it don't into some more digestible bits for Sympy,
thanks again.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Reply via email to