# Taming the T-handle continued

This is a simple continuation from the last post “Taming the T-handle“. We ended up with the equation

(1) where

(2) To find let us assume that , we need to integrate Setting we transform the above into Searching the net we can find the integral of this type, for instance on the Wolfram’s page about elliptic integrals of the third order we can find: Then we set therefore – see Jacobi amplitude- realism or cubism,
so that In principle we could now substitute the values of and consider our task essentially done. But that would be not very prudent! The point is that we have the parameter and, depending on the case, this parameter can have value:  and The case is very special and should be treated separately. No elliptic functions are needed in this case. Moreover not every software used for calculations and simulations will know what to do with and even if it pretends to know, it may happen that in this domain the software is not sufficiently tested and debugged. It is for this reason that we now consider the three cases separately.

The case of i.e. This is the most straightforward case. From Taming the T-handle, Eq. (10), we have

(3) (4) Thus and we are done.

The case of i.e. This is a tricky case. For we have (see Jacobi Elliptic Functions, Eqs. (33)-(35), and this comment)

(5) To find we need to integrate We can go to Wolfram Alpha, and ask it to integrate it. It will, but we will not like the answer. It looks very-very ugly! In principle we could try to simplify it, but it is better to make one step back in order to make two steps forward! Let us go back to Eq. (1) and write it as just one fraction:

(6) Now, we write and get

(7) So, we need to integrate the function

(8) We can go again to Wolfram Alpha and what we get this time is so much nicer! All we have to substitute the constants. It is a mechanical task, so we can use REDUCE, so we use REDUCE or any other software capable of symbolic computation. I used Mathematica. Here is the result, followed by a complete summary of the case:

(9) (10) (11) (12) (13) (14) (15) Changing signs of any two of three components we can obtain altogether four different evolutions of a painted T_handle. But that, and also the case of must wait for the next post.

But here are four pictures of the painted T-handle, rotated according to the above algorithm, at where the three last cases correspond to flipped sign of as follows:  ### Update

You can download my experimental Mathematica cdf file that can be run using free CDF Player. It shows the code and the animation for the four cases mentioned above.

## 16 thoughts on “Taming the T-handle continued”

1. Bjab says: -> (The dot over d is unneeded I suppose. (In many places.))

2. Bjab says:

From we have ->
?

3. Bjab says:

so e can ->
so we can

4. Bjab says:

sign of ->
sign of 5. Bjab says:

In (13): -> 1. arkajad says:

All fixed. Thanks.

6. Bjab says:

So now there is a hypothesis that:
velocity of the end of the leg of T-handle is always perpendicular to the plane of T-handle.

1. Bjab says:

Always means: when m=1

1. arkajad says:

We will look into your hypothesis within the coming new blog post.

7. Ronan says:

I am struggling a bit with in Maple.
When I enter the values putting d=49/100
I get My m is the square root of your m because of the way Maple handles Jacobi functions.

Setting t=0 have tested up to 50 the function evaluates to -.82693+3.6654*I

I have had some success by getting an amimation to run for d=1/2. I will post it when I am more sure about my code/understanding.

1. arkajad says:

OK. I will look into this problem.

2. arkajad says:

I noticed two things: you have opposite signs where c2 and c3 are. Perhaps you reversed the order of I1,I2,I3?
There should be + sign after t/3 and there should be -3 under EllipticPi.

1. Ronan says:

The + and – reversal is Maple. It states in the FunctionAdvisor EllipticPi(-A,B,C)= -EllipticPi(A,B,C). So it swaps the signs itself. It will look further into it tonight. Would you be able to test in your Maple?

1. arkajad says:

The problem is, as I see now, that EllipticPi is defined in Maple in a somewhat different way. I will try to figure it out how to convert.

2. arkajad says:

The conversion is not that simple. I yet have to work it out, and then test. I think I know how to do it. And since I can’t find it online, I may devote the whole next post to this technical problem.