<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; javascript</title>
	<atom:link href="http://gidden.net/tom/tag/javascript/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Fri, 02 Jul 2010 13:00:07 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1-alpha-15359</generator>
		<item>
		<title>Mechanics Experiments with &lt;canvas&gt;</title>
		<link>http://gidden.net/tom/2007/04/03/mechanics-with-canvas/</link>
		<comments>http://gidden.net/tom/2007/04/03/mechanics-with-canvas/#comments</comments>
		<pubDate>Tue, 03 Apr 2007 11:54:20 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Blogroll]]></category>
		<category><![CDATA[General]]></category>
		<category><![CDATA[Programming]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[canvas]]></category>
		<category><![CDATA[collision]]></category>
		<category><![CDATA[inertia]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[mass-moment-of-inertia]]></category>
		<category><![CDATA[mathematics]]></category>
		<category><![CDATA[maths]]></category>
		<category><![CDATA[mechanics]]></category>
		<category><![CDATA[moment-of-inertia]]></category>
		<category><![CDATA[polygons]]></category>
		<category><![CDATA[rigid-body-dynamics]]></category>
		<category><![CDATA[trigonometry]]></category>
		<category><![CDATA[verlet]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/04/03/mechanics-with-canvas/</guid>
		<description><![CDATA[A couple of months ago, I spent a few weeks playing with &#60;canvas&#62;.  The main reason was to write a game (currently on the back burner, but not "cold" as yet), and also to re-learn some simple mechanics and trigonometry I've forgotten since c.1993.  I've put together a little bit of code ("testbed") which lets me put together simple interactive diagrams.  Due to the lack of text support in &#60;canvas&#62;, unfortunately I can't label everything diligently.  My old maths teacher, Mr. Slatter, would be horrified.

I mainly got sidetracked trying to calculate the scalar, or mass moment of inertia of an arbitrary polygon.  This would be used to calculate what happens when something hits a polygon.  Unfortunately, I couldn't find any pertinent information about it, and a lot of conflicting (or just plain wrong) stuff confusing it with other things with similar names.  I even rootled through the garage and found my trusty 3rd Edition of Stroud, which got me through A-level maths.  Anyway, I finally found the answer and then took a break from the code.  I should really get back to it sometime.
After seeing some experiments done by my friend Martin, I've thrown caution to the wind and decided to publicise my egregious lack of mathematical knowledge, along with my hacky approach to non-browser-portable Javascript.  So, below is a cut-n-paste list of the experiments... comments are extremely welcome.

These pages are simple Javascript experiments with various geometric situations to try things out.
They are most likely to work in Firefox, but will probably run fastest in Opera if at all.  Safari is okay, as is Camino.

Experiment 1: Intersection between a stationary circle and a polygon.  Comparison of line normals against direction to intersection points gives whether the circle is inside or outside the polygon.  Uses the circle/line intersection test.
Experiment 2: Collision of circle in motion against a line.  Uses similar triangles to work out collision "time", and then reflects both C and C-prime in the line to give new positions for constraints.
Experiment 3a: Intersection of a circle in motion against a polygon, including corners.  Uses two methods: similar triangles technique for collision against edges, and circle/line intersection test for collision against corners.  Uses the first collision, using simple minimum finding.
Experiment 3b: As above, but using simpler algorithms.
Experiment 4: Oliver Humpage kindly wrote some PHP code simulating a simple collision between a point and a polygon.  I've translated this to the same framework I've used here.
Experiment 5: First step in calculating mass moment of inertia (MMI): triangulation of simple (but not necessarily convex) polygon using Ear Cutting.  This is non-optimal, but since the search for a simpler mechanism an open problem, I'm okay with going for the O(n2) solution since we're only doing this once (as long as the polygon doesn't change shape), and we're only doing it for a small n.
Experiment 6a: MMI test, using bh3/36, which doesn't seem right.  Comparison circles are also given.  One problem here is confusion between (scalar) {mass,polar,area} moments of inertia, probably thanks to structural engineers making a mockery of the terminology.  In particular, I think the author of this page has picked the wrong one (possibly "area" rather than "mass").  Wikipedia's not helpful on this point, and my calculus isn't really up to the task.  Finding a formula for the MMI around the centroid of a triangle (in 2D) is proving difficult.  I'm not sure if this value will even help:  the parallel axis theorem only works for axes in the plane of the shape, while we're trying to get it around an axis normal to the plane of the shape.
Experiment 6b: The above method doesn't seem to work, so trying a different method.  Seems to work well, although the figures go weird when the triangle is "inverted", ie. the vertices are anticlockwise.
Experiment 6c: Brute force approach, by gridding the triangle and treating each point as a point mass.  This should give an approximation for comparison of the other experiments.  Interestingly, there seems to be a relationship between the approximation and the largest (pale blue) circle (bounding circle around the centroid).  For an equilateral triangle, the approximation is about half that of the circle, and for a sliver-like oblique triangle, it's about 27%.  I suspect the range might be &#188; to &#189;, in inverse relation to the largest angle of the triangle (60&#176;&#8658;&#189;, 180&#176;&#8658;&#188;), but not necessarily inverse proportional.  The sliver, of course, tends to that of a thin rod, given by (ml2)/12.  As the rod has no area (our current analogue for mass), it gets tricky.
Experiment 6d: To compare the results of 6b and 6c.  Seems to match very well.
Experiment 7: Combines Experiment 5 with Experiment 6d to demonstrate the use of the MMI calculations on the arbitrary simple polygon.  The methods are functionized, and also parameterized to allow a different rotation axis point to the triangle's centroid: in this case, the polygon's centroid.  It demonstrates that the method from Experiment 6b is correct and general enough to use for the polygon.  This confirms the mass moment of inertia of a simple polygon around an axis normal to the plane of the polygon and through its centroid!
Verlet Experiment: Test of point-based verlet integration mechanism.  Simulates all objects as point meshes.  Too slow for use in a Javascript-based game, I think.
Mandelbrot: To demonstrate to Steve how canvasses work.  WARNING: Runs badly in anything but Opera.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/04/03/mechanics-with-canvas/feed/</wfw:commentRss>
		<slash:comments>-1</slash:comments>
		</item>
		<item>
		<title>Mac Flight Tracker widget timezone bug</title>
		<link>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</link>
		<comments>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/#comments</comments>
		<pubDate>Thu, 10 Aug 2006 20:54:07 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[bdt]]></category>
		<category><![CDATA[bst]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[dashboard]]></category>
		<category><![CDATA[flight-tracker]]></category>
		<category><![CDATA[flighttracker]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[nsdate]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[os_x]]></category>
		<category><![CDATA[tiger]]></category>
		<category><![CDATA[timezone]]></category>
		<category><![CDATA[widget]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</guid>
		<description><![CDATA[The Flight Tracker dashboard widget that comes with Mac OS X 10.4 (Tiger) seems to have a fairly major bug.  However, this bug seems to be the result of something quite obscure to do with timezones, and it only seems to manifest itself in the UK during the summer.

I've noticed this problem a few times:  specifically whenever any one of my close friends or family members flies anywhere.  This time, my mother is on her way back from San Diego to Bristol via Newark.  Thanks to the incredibly annoying terrorist attack attempt today, my dad and I were understandably concerned about flight delays, so I pulled up the Flight Tracker.  Unfortunately, the information seems completely wrong.
Turns out, the minutes are right but the hours don't relate to any of the relevant timezones.
Anyway, a little background.  Here in the UK, we have two main time scenarios:  firstly GMT, which is for all intents and purposes, UTC.  We also use BST:  "British Summer Time" which is UTC+1h, and kicks in for archaic agrarian reasons and the "Think of the children!" brigade who are convinced it'll stop traffic accidents.
While the rest of OS X seems okay and correctly uses BST, Apple's Mail.app has always strangely listed incoming mail as being sent relative to "BDT", which comes out as "British Daylight Time", which is fairly meaningless as there's no such thing.  The times are correct, but they just have the wrong abbreviation afterwards.  On researching it, this seems to be the result of bad data from the Unicode people which might have made its way into NSDate.  Anyway, it's usually just a cosmetic thing, and of little or no consequence.
I believe, however, that it's the cause of the Flight Tracker widget's problems.  To test this, I altered the widget to display the timezone, by replacing the bit in FlightTracker.js, in function formatDateForDisplay() that says
var timeStr = date.toLocaleTimeString("short");
with
var timeStr = date.toLocaleTimeString("long");
This reveals that the times are supposedly in "BDT".  I believe this might be the problem.  I think something is reinterpreting this as "Brazilian Daylight Time", which would explain the weird offsets.  I think JavascriptCore or something is referring to the same bad data as Mail.app, probably via NSDate.  I'm not a Safari hacker, and I haven't really investigated that far, so I'm not sure where the problem is.
Looking a bit deeper into FlightTracker.js, I'm not really surprised there's a problem.  The timezone calculation code is fairly messy, with comments such as:
// We're going to be stupid and hard coded about parsing the server provided date strings for now
// ??? for some reason parseInt returns 0 on this but parsefloat works ???
and
// here we do proper handling of the timezone offsets.
// We enter everything in pretending it's UTC time
// and then we convert it to miliseconds since 1970,
// add the timezone offset in miliseconds to it
// and then set this as the new UTC time
There seems to be some string hacking going on at several places to decode the data sent from FlyteComm.  The original data is reasonably well structured, with the timezone offsets being given correctly as -0700 and +0100, which presumably indicate that the times are given as local times of the departure/arrival locations, as per normal for the airline industry.
I'm not completely sure what's going on, as I'm not really set up to debug someone else's widget, especially one with weird custom controls, and barely any code comments.  It's obvious to me that the widget isn't particularly well written, and is one of those things that "just works".  It was probably hacked up for fun by a Dashboard developer, and then fasttracked to the nearest Steve Jobs keynote rehearsal.  As Steve Jobs's Dashboard demos tend to be done at MWSF and WWDC, I doubt this problem has ever really been seen at Apple.  I bet if it was a problem with Pacific Daylight Time being misinterpreted, it'd be fixed immediately!  I've done a little bit of googling, and it looks like the BDT bug has already been submitted to Apple (several times), and it's still there.
When I get a chance, I may try to debug this one further, and perhaps rewrite FlightTracker's timezone code properly using the correct offsets rather than performing nasty magic using getLocaleTimeString().
What I would prefer is that the timezone of each time is given next to the time.  Ideally, they should toggle-on-click or slowly fade between local times (to the flight) and local times to the machine, and possibly relative times ("1 hour ago", "in 53 minutes", etc.)  That would make the tool a lot more intuitive anyway.  I'd rather not reinvent the whole widget, as in all other ways, the widget's really not too bad.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/feed/</wfw:commentRss>
		<slash:comments>15</slash:comments>
		</item>
	</channel>
</rss>
