Tig Quick Reference Card

November 1st, 2013 No comments

Hello world!

Categories: Uncategorized Tags:

From Acceleration to Displacement

May 27th, 2013 No comments

Recently I was trying to double integrate a sinusoidal acceleration (ex: a frog leaping forward) and was a bit puzzled at first why double integrating the \(\sin(t)\) wave resulted in no displacement after an integral number of cycles:

\[
\begin{eqnarray}
v(t) = \int \sin(t) dt &=& -\cos(t) \\
d(t) = \int -\cos(t) dt &=& -\sin(t)
\end{eqnarray}
\]

Everybody knows that integrating once gives you velocity, and integrating twice gives you displacement (or position). But if that’s the case, why is the displacement (\(-sin(t)\)) above sinusoidal? Shouldn’t the frog be moving forward instead of back and forth?

It turns out my calculus was rusty enough to where I missed one very obvious fact. In the process I learned the distinction between a multiple (or double) integral, which is an integral taken over different variables (ex: \(\int \int f(x, y) dx\ dy\)) and a repeated integral which is taken multiple times over the same variable. What I missed was the difference between an indefinite integral (shown above) and a definite integral (shown below).

So let’s make the problem a little more generic and add amplitude and frequency component to our acceleration signal, and then see what happens to it as we integrate it twice. We’ll start with an acceleration signal defined as:

\[A = a \sin(c*t)\]

and we’ll integrate it twice over the interval start..end (\(s..e\)) to see what we get.

For the first integration we have:

\[
\begin{align}
V_{t = e} = \int_{s}^{e} a \sin(ct) dt &= \ – \frac{a \cos(ct)}{c}\bigg|_{s}^{e} \\
&= -\frac{a \cos(ce)}{c} + \frac{a \cos(cs)}{c}
\end{align}
\]

So that allows us to calculate the velocity at any point \( t = e \) after the starting time \(s\). Now we want to integrate a second time to get the displacement. To avoid confusion with the \(s..e\) interval used for the first integration, we’ll use \(g..h\) as the integration interval this time around. To simplify things, let’s also rename the integration constant (time independent) term \(\frac{a \cos(cs)}{c} \equiv m\).

\[
\begin{align}
D_{t = h} = \int_{g}^{h} -\frac{a \cos(ce)}{c} + m\ de &= -\frac{a \sin(ce)}{c^2} + me \bigg|_{g}^{h} \\
&= \left[ mh – \frac{a \sin(ch)}{c^2} \right] – \left[ mg – \frac{a \sin(cg)}{c^2} \right]
\end{align}
\]

Since both integrations are over the same intervals, we know that \(g \equiv s\) and \(h \equiv e\). Now substitute everything back in and simplify:

\[
\begin{align}
D_{t = e} &= \left[ mh – \frac{a \sin(ch)}{c^2} \right] – \left[ mg – \frac{a \sin(cg)}{c^2} \right] \\
&= \left[ me – \frac{a \sin(ce)}{c^2} \right] – \left[ ms – \frac{a \sin(cs)}{c^2} \right] \\
&= m(e-s)\ – \frac{a \sin(ce)}{c^2} + \frac{a \sin(cs)}{c^2} \\
&= \frac{a \cos(cs)}{c} (e-s)\ – \frac{a \sin(ce)}{c^2} + \frac{a \sin(cs)}{c^2}
\end{align}
\]

If we want to take into account the phase of the signal, we start with:

\[
A = a \sin(ct + p)
\]

and end with:

\[
D = \frac{a \cos(cs+p)}{c} (e-s)\ – \frac{a \sin(ce+p)}{c^2} + \frac{a \sin(cs+p)}{c^2}
\]

So there you have it. The result of integrating a sinusoidal acceleration twice on the interval \(s..e\) in order to arrive at the displacement.

Categories: Uncategorized Tags:

Git – deleting the current branch is denied

August 1st, 2012 No comments

Here’s a solution if you ever get the following error when trying to delete the master branch in a remote repository:

remote: error: By default, deleting the current branch is denied, because the next
remote: error: 'git clone' won't result in any file checked out, causing confusion.
remote: error: 
remote: error: You can set 'receive.denyDeleteCurrent' configuration variable to
remote: error: 'warn' or 'ignore' in the remote repository to allow deleting the
remote: error: current branch, with or without a warning message.
remote: error: 
remote: error: To squelch this message, you can set it to 'refuse'.
remote: error: refusing to delete the current branch: refs/heads/master
To /somewhere/in/the/cloud/repo.git
 ! [remote rejected] master (deletion of the current branch prohibited)
error: failed to push some refs to '/somewhere/in/the/cloud/repo.git'

The reason you’re seeing the error is that HEAD on the remote repository by default contains something like this (see also line 9 in the error message above):

ref: refs/heads/master

If you have access to the remote repository, simply modify the HEAD file to point to a different branch and then you’ll be able to delete the remote master branch. There are some significant implications to modifying the remote HEAD, especially if other users are tracking that branch, so make sure you know what you’re doing if you choose to point it to some other arbitrary branch.

Categories: Uncategorized Tags:

Editing GEDCOM files with vim

March 5th, 2012 No comments

GEDCOM files sometimes have no indentation. That makes it difficult to read or edit them with a text editor. Using the following simple instructions, you can auto-indent the file so that it is more readable in the vim editor.

Compare the readability of the two formats

Save the next few lines into a file called gedcom_indent. Make the file executable and place it somewhere in your path.

#!/usr/bin/env python

from __future__ import print_function
import sys

for line in sys.stdin:
    line = line.lstrip()
    try:
        level = int(line.split(' ', 1)[0])
        print('\t' * level, end='')
    except:                                                                                                                                            
        pass
    print(line, end='', sep='')

Now add the following 2 lines to your ~/.vimrc file:

autocmd BufReadPost,FileReadPost *.ged %!gedcom_indent
autocmd FileType gedcom set foldmethod=indent nolist ts=4

This tells vim to filter any file with a “ged” extension through the small gedcom_indent filter (which will add leading tabs to the file). The second line tells it to make each TAB count for 4 spaces, and to fold based on indentation.

Categories: Uncategorized Tags: , ,

The Android IPC system

January 3rd, 2011 7 comments

The information below comes from a number of sources, including my own experiments with the Android IPC and some disparate internet sources.

The overall architecture of the Android IPC system is shown in the diagram below. It consists of four major blocks; one in kernel space, and the other three in user space. The dashed lines represent the logical RPC calls. The solid lines represent the actual data flow.

  • BinderDriver: This is the core of IPC system. It passes data between a ServiceProvider(s) and a ServiceUser(s). This kernel component is provided by Android.
  • ServiceProvider: Provides some kind of service. It parses the received RPC data from the BinderDriver and does the real work. Application developers will either make use of existing service providers (such as the Camera or AudioFlinger), or in some cases will write their own.
  • ServiceManager: This is a special singleton ServiceProvider that provides service manager services for other service providers. This component is provided by Android.
  • ServiceUser: This is the client. It remote calls the ServiceProvider by generating an RPC and sending it to the BinderDriver. Application developers typically write their own ServiceUser as part of their application.

Here is a typical flow of events for a fictitious MultServiceProvider (a service provider that multiplies two numbers for a client) and a MultServiceUser client which doesn’t know how to do multiplication (maybe because the numbers are quaternions) and needs to use the MultServiceProvider:

  1. ServiceManager runs first (at power-up) and registers a special node (node O) with the BinderDriver.
  2. The MultServiceProvider gets an IServiceManager proxy object for the special node O by calling the global defaultServiceManager() function.
  3. The MultServiceProvider then calls defaultServiceManager()->addService("Multiplier", new MultServiceProvider()) to add itself as a service provider and then waits in an infinite loop for someone to request its services. The addService RPC call is routed to the ServiceManager through the BinderDriver.
  4. The BinderDriver notices that the RPC is for the ServiceManager to add a new service, so besides routing the RPC to the ServiceManager it generates another node (let’s call it node M), for the new MultServiceProvider.
  5. The ServiceManager reads the data from the BinderDriver and processes the IServiceManager::addService RPC call.
  6. The MultServiceUser client process gets an IServiceManager proxy object for the special node O (again by using defaultServiceManager()).
  7. The client does an IServiceManager::getService("Multiplier") RPC call to get the MultServiceProvider. This call is routed to the ServiceManager through the BinderDriver.
  8. The ServiceManager reads the RPC data from the BinderDriver, processes the IServiceManager::getService request and returns back the node representing the MultServiceProvider.
  9. MultServiceUser calls MultServiceProvider::multiply(a, b). This call is routed to  the MultServiceProvider by the BinderDriver.
  10. The MultServiceProvider handles the MultServiceProvider::multiply RPC call and sends the product of the 2 numbers in a reply to the BinderDriver.
  11. The BinderDriver routes the reply back to the client.
  12. The client reads the data from the BinderDriver which contains the result of “a * b”.

In a future post I hope to discuss the whole architecture in more detail, with concrete code examples for how to use IBinder, IInterface, BBinder, BpInterface, BnInterface, etc… to create a ServiceProvider and a ServiceUser all in native C++ code on Android.

Categories: Uncategorized Tags: