Math teachers hear the most often-uttered student phrase in history a lot more than I do, but my ears have twitched to the infamous, “I’ll never use that” or its many variants over the years. Funny how people know right now what will and will not be needed or used for the rest of their lives
Now, taken in strict isolation, a single trig or algebra formula might appear to have limited or no use in the myriad of life situations in someone’s future. It is, however, quite interesting how often problems can be solved by strategic use of a single formula from multiple areas of study. The problem discussed in this post is one such example.
In the prior post, I illustrated how some basic trig concepts could be used to solve a rotation and bounding-box problem without any presumptions or special considerations of the programming environment. This example is similar in that it illustrates how to rotate a box around an arbitrary point in its interior. The box is represented by a sequence of four coordinate pairs. It is not a Flash symbol or anything other than a sequence of coordinates. The drawing environment is simple; it can move the pen, draw lines, and draw filled circles. The programming environment contains the typical set of math functions.
Our math background includes a semester of trig, analytic geometry, and algebra. We know the very basics of vectors, but have not been introduced to matrices or matrix/coordinate transforms. As it happens, all we need to know to solve the stated problem is
1 – Polar coordinates, i.e. x = r cos(a) , y = r sin(a)
2 – Parametric equation of a straight line, i.e. P = (1-t)P0 + tP1
3 – How to add and subtract vectors
4 – How to compute the distance between two points
Refer to the diagram below.
The four points of the box are A (x1,y1), B (x2,y2), C (x3,y3), and D (x4,y4). The rotation point is R (rx,ry). The example code was written in Flex and the coordinate system in the Flash player is y-down. We are not given the coordinates of R. In fact, the box may be at an angle to the horizontal as shown in the lower, right part of the diagram. The only thing we know about R is that the component parallel to each side of the box is a fraction of that side’s length. This is where vector math can be useful.
The coordinates of R can be computed by adding the vectors V1 and V2. The percentage inputs can be converted into numbers t1 and t2 in [0,1]. The exact coordinates of the terminal points of these vectors are obtained from the parametric equation of a line. Let the non-bolded notation V1 and V2 refer to vectors from the origin representing these terminal points. Then, V1 = (1-t1)A + t1B and V2 = (1-t2)A + t2D. Since the initial point of both V1 and V2 is A, the vector constituents (Δx and Δy) are immediately available. Add the vectors and add the result to A to obtain the coordinates for R. So, we can adjust sliders that change the percentage along each side and quickly compute R regardless of any prior rotation since we should always recompute the correct coordinates for A, B, C, and D.
When R is set, imagine lines drawn from R to each of the vectors A, B, C, and D. Let the distances be r1, r2, r3, and r4, respectively. Also compute the angle each line segment makes with the horizontal using the atan2() function. Since this returns a value in [-Π, Π], a small adjustment is made to always record the angles in [0, 2Π]. This makes studying the angle computations a bit easier if you want to trace out the results as part of deconstructing the code.
Also record the initial rotation angle when R is assigned. Subsequent changes to this value rotate the box around R by some delta. If the initial angle of the box is θ, and the delta is δ, then the four points are rotated around R by an angle θ+δ. Compute the coordinates of each new vector, A, B, C, and D by using the formula for polar coordinates and add the center, R.
These concepts are illustrated in an online demo.
The percentage along each side used to compute R is adjusted by sliders as well as the rotation angle. The red dot visually identifies the rotation point, R. You may optionally display the circle traced by each of the four corner points as the box is rotated. There is a _clear (Boolean) variable in the code that you may adjust to either clear the drawing each rotation update or choose to draw over each update of the box. If the value is false, you can produce some spirograph-style drawings.
The UI was created in Flex, but the actual code is very straightforward and does not rely on anything unique to Actionscript. It could be ported to many other environment quite easily. There is also some internal documentation on how to use trig identities to reduce the number of trig computations at each rotation update.
Even more importantly, there is nothing in the code or the algorithm that relies on a box being rotated other than computing R. The actual rotation is applied to a sequence of points using the simplest of concepts from a few math disciplines. I hope this provides some sense of appreciation of problems that can be solved using only the most fundamental techniques from a few branches of applied math.
I think I’m about to set a new personal record for lowest number of posts in a given year. Is it really October already?
Well, at least I’m working and on a pretty interesting project from both a mathematical and programming perspective, so I should be thankful for that.
To this end, I’m currently looking into both Typescript and Jangaroo. Coffeescript is on the list as well, but I’m really looking to get back into Visual Studio and C++/C# development, so Typescript has some natural appeal. Perhaps sufficient time will arise to deep-dive into all three?
I guess we’ll have to wait and see. Sorry again for the waiting part. This has been a strange (but fortunately very profitable) year.
I’m into an extension of my prior gig, so time is still very limited. In addition to family issues, what little time remains is dedicated to supporting existing beta users of the Freehand Drawing Library. And, these users just scored big time. I’ve decided to keep the library private and license it only to customers, providing requested customization at an hourly rate.
Thanks for bearing with the extreme lack of posts this year
Well, this is what every contractor likes to hear – “you’ve been extended.” Although relatively short, it means that between the gig, taking care of family, and supporting users of the Freehand Drawing Library, my lack of blogging will also be extended for a while.
On a personal note, I hope to get back into tennis after being out of practice since April due to a foot injury. Looking forward to hitting this afternoon instead of just watching the US Open
Okay, well, I hope that tells you where my summer is at this point and helps explain the lack of posts. With some luck, I’ll be back to work on the Freehand Drawing Library later this month.
No, I haven’t bugged out. Just going through the typical ‘long haul through the summer.’ For some reason, it’s been this way every year since 2006. It’s a nice problem to have, however, so no complaints here. Just no posts for a while.
I never thought much about blog statistics over the prior year until receiving a WordPress summary. The reflection also caused me to think hard about where I want to take this blog in the upcoming year. So, here’s a brief look back and a brief look ahead.
Over 230,000 visits to this blog were logged in 2011, not very impressive as I suspect there are many top programmers who receive that many visits in one or two months. For a blog devoted primarily to applied math with the occasional tennis diversion, I felt that was better than expected.
The most visitors came from the US, followed by the UK, India, South America, and Australia.
The top referring sites were my business site, algorithmist.net, followed by degrafa.org, Facebook, Stack Overflow, and Flashbookmarks.
The most traffic came from search engines and the top search terms were black mathematicians, puremvc tutorial, TRON Clock, and Prince EXO 3 Black. Where’s my sponsorship from Prince?
The top two posts were from the TRON Clock demo and the top blog commenter was friend and fellow developer, PolyGeek. I’m guessing he’ll be the first person to respond to this post
In terms of traffic, the top four posts were Flex-related and number 5 was the Babolat RPM Blast review. OK, where’s my Babloat sponsorship?
In terms of 2012, I’ll be working a lot on the Freehand Drawing Library and app. development, so I expect personal blog posts to decline. I’m considering guest posts as a means to keep the content fresh and give others a shot at some exposure. So, if you are interested in writing posts on applied math or general programming/algorithm topics and have either a resume or personal site to display your background, please email me at theAlgorithmist [at] gmail.com with the subject ‘Guest Posting on The Algorithmist.’ All posts will contain a link to your personal site or a brief bio.
Continuing my series of posts on business topics, one of the things you find as a solo freelancer is that everyone has a story. Everyone. Sometimes stories are straight from the heart and other times they are complete facades. Reality is most often somewhere in the middle. Part of the challenge in any initial set of discussions is discerning what is fact and what is spin. The goal is to both properly sell your services and mitigate risk.
I’m a developer and mathematician so the first thing I look for in a conversation is whether or not the prospect talks to me like a mathematician or developer. It’s always good for a people to be enthusiastic and optimistic about their business, but I’ve found code words like ‘this is going to be big’ or ‘this will revolutionize’ or similar phrases to be warning signs. Charlie Van Loan at Cornell once told me at a supercomputing conference that “there’s really nothing new under the sun.” I’ve come to understand the wisdom of those words over the years. There are so few truly ‘big’ and ‘revolutionary’ ideas that on the basis of probability alone, the likelihood of the prospect’s claim is small at best.
And, what difference does it make to a developer? Big does not describe the programming or math problem to be solved. If my rate is $X per hour, then it’s still $X per hour whether the prospect’s idea is ‘big’ or ‘small’ or somewhere in between. Big may sound like there is lots of money to be spent, but in reality ‘big’ is likely a setup to entice you into compromise now in exchange for possible future gains.
Trust me when I tell you emphatically that if you compromise today, you will compromise tomorrow and forever more. There are no big gains in the future, except for the client that consistently takes advantage of your good will. That sounds crass, but it comes from personal experience and the experiences of hundreds of other freelancers via private communication.
Big or revolutionary is not a story told to a developer. It’s a story told to a bank, VC, or Angel as part of a request for funding. I’m not a bank. I’m not a VC. I’m not an Angel. I’m not a savior of any organization from its past mistakes or experiences arising from bad luck. Don’t tell me that the development budget is exhausted because of some unexpected complications or that the pitfalls of outsourcing have only just been understood or that a partner just withdrew from the organization. That’s what you tell a financial organization or investor as part of a solicitation for a cash infusion. Don’t make your very first question to me, “what is your rate?” Why should you care if you have yet to determine if I’m the best person for the job? Don’t tell me that you have such a hard time collecting payments from your clients. That’s just fodder for a later excuse that my invoice will be paid after you receive payment from your clients, which is nothing more than a form of implicit financing via floating payables. Financing is provided by banks, VC’s, Angels and other financial sources.
I’m not a bank. I’m a developer.
If someone understands that you are an artist, copywriter, developer, or other service provider and they talk to you like a bank, beware. That conversation is simply designed to provide an initial cover that is later used as an excuse to dilute the value of your time through free or heavily discounted services, or by implicit financing via arbitrary float of their payables.
Now, having said that, I do often help local business that have experienced some bad luck, but I do it with the attitude that it’s one step away from pro bono work. Like the admonition to not gamble with money in Vegas you can’t afford to lose, I don’t help anyone with time I’m not willing to write off.
So, in conclusion, pay close attention to how people address you. Do they talk to you like a service provider or a bank? If it’s the former, then keep talking. If it’s the latter, then be careful. I don’t know about you, but I’m not a bank.
Good luck with your business!
I’m going to switch gears for a while. Don’t worry, I’m still working on open-source stuff and you’ll see some new posts shortly. I’ve received several inquiries about the general process of doing business as a solo freelancer. I can’t claim to have a lock on the perfect strategy for success, but I’ve been doing this since 1997 and will be happy to share my experience. It also provides an opportunity for others to share their expertise.
So, in that spirit, here is my first tip. I’m eternally grateful for a past opportunity to work with Paul Jones, considered by many to be one of the greatest commodity traders of all time. Despite the numerous trading monitors, charts, and advice generated by his support team, Paul’s greatest asset is a small handwritten piece of paper in his office. The hand scratch reads, “Losers breed losses.”
The point is that losing positions tend to not turn into winning positions. Losers don’t breed winners. They tend to breed more losses. Paul approaches a trading day with the attitude that every single open position in his portfolio is a loser. It must *prove* itself to be a winner. We tend to take the opposite attitude with our business positions. We presume that decisions we make are destined to be winners. We think that bad times will turn around and a losing posture will turn to a winning one. Sometimes, it happens, but at a substantial opportunity cost.
My business began as a 3D animator and plug-in developer. I had character design and animation experience not matched by other programmers and C++/math skills not possessed by other animators. It was a really nice niche and I had a lot of money and time invested in that niche. Not just money, but emotional currency as well.
Yet, every morning, I told myself it was a losing position. It had to consistently prove itself to be worthy of continuance. Early after the new millennium, several factors came to the forefront that proved to be the writing on the wall for my so-called niche. The business strategy failed to prove itself a winner, so 2003 was the year I gave up 3D and re-branded myself as a full-time programmer.
Interestingly, the niche that proved to be successful for the last nine years was something I never would have predicted coming from a C/C++/scientific programming background.
Something called Flash.
Nine years is a nice ride and I’ll never be successful attempting to predict the next nine years (nor will you or any of the silly technology pundits). I’ve never been a <insert_the_fab_language_of_the_day> developer and never will. Every day, I wake up with the presumption that Flex/Actionscript is a losing strategy. It must consistently prove itself to be a winner.
Because, losers don’t breed winners. Losers breed losses. Try considering your business decisions in the same light and best of luck to you!
This is a brief overview of a project I’ve been working on for an Agency client. This client does a lot of work with interactive applications involving navigation between ‘views’ and ‘frames’ of individual views. Sometimes, the views correspond to geographic maps, although the images are highly artist-stylized (otherwise we could just use Google/ESRI). In some applications, the views might correspond to a floor plan or concert hall. Each new view represents a different snapshot (revealing more detail) of some larger perspective. We loosely use the term ‘map’ to refer to each view, although programmatically, a view is nothing more than an image. Frames of a view correspond to rectangular regions having the same aspect ratio as the main ‘map’ window. Views may have interactive ‘hotspots’, clickable ‘icons’, and animated overlays associated with them in addition to arbitrary framings. If map projection information is available for a view, icons may be geo-coded.
Instead of developing each such application from scratch, the client wanted a class library, Flash ‘template’ and XML data structure to help organize each application into a common structure. This provides numerous benefits in addition to code re-use. Decoupling visual assets from the primary application facilitates easy distribution of design/development workflow among multiple people. Structuring view/frame layout in XML allows non-coders to make simple changes to the application without touching code. The system employs a template .FLA (this agency works only with Flash) and base Document class that encourages commonality among all applications using this ‘map system.’ This makes it very easy for one person to learn the application structure and quickly help on another application without having to deconstruct another person’s code and decipher library assets. The map system employs an internal transition engine that is programmed to an interface, not any specific implementation. This allows transitions to be coded once and then re-used by simply including the transition in the XML and linking it to a view transition by id. Artists may experiment with different view transitions and parameters simply by editing XML. Framing and frame transitions are an interesting exercise in analytic geometry. These are handled internal to the system by a general-purpose zooming engine.
The template .FLA allows a designer to position the ‘map’ application by placing a blank MovieClip on Stage. Since all such applications begin with a common, base template, the clip already resides on Stage for the artist. The widow size is set in XML. The system itself handles internal preloading of the application and all map assets. The lead developer extends the base Document class to override event handlers and add any application-specific logic outside the map. Some of the wiring with regard to hotspots and other interactive elements is handled in XML. Printing is automatically integrated into the system. Either the map or the entire Stage may be printed and print parameters are assigned in XML. Modality is also automatically handled internal to the system and exposed to the application developer via the system API.
Unfortunately, I can’t show the XML or even discuss the code in detail as it’s proprietary, but here are some screen shots shown views/framing, hotspots, and animated overlays.
This application involved a very complex transition between views. Once coded, however, the parameters can be modified in XML and re-used in other map applications simply by including the transition class in the XML and assigning it to a view transition via id. Hotspot interactivity is wired into the main application in XML as each hotspot graphic is associated with a class extending MovieClip inside the system.
This application used only one view with many framings/overlays. Frame transitions are handled internally by the zoom engine. After specifying the framing (rectangle coordinates), the designer sets the transition time in seconds in XML. The application developer initiates the transition from the Document class. A default handler is always overridden to implement app-specific functionality after each transition completes.
Although the term ‘map’ is used to describe the system, the manipulation of views/frames is generic and does not necessarily pertain to geo-coded data. In addition to the numerous coding challenges (including being forced to debug/develop using the Flash IDE), I enjoyed the practical application of analytic geometry in this project. I can only hope that the client is open to extending this system to work with AS only projects in FlashBuilder in the future