-
@user6350, working on getting Espruino to understand my 'old' marine #GPS, I read through your code in post http://forum.espruino.com/conversations/1578/#comment26928. I tried to understand getUTMLatitudeZoneLetter(latitude) {... #latitudezone function. Analyzing the implied algorithm and underlaying data values and structure, a How about:... popped up in my head:
How about arithmetically coming up with an index pointing at a character in a string of the UTM latitude zone letters:
And this would be the code:
function getUTMLatitudeZoneLetter4(latitude) { return ( ((latitude >= -80) && (latitude <= 84)) // defined, valid range ? "CDEFGHJKLMNPQRSTUVWX".charAt(Math.floor((latitude * 1 + 80) / 8)) // valid : "Z" // undefined and invalid ); }The two-termed logical AND expressions, for example,
((84 >= latitude) && (latitude >= 72))
threw me off. Two-termed logical expressions are usually only used for dealing with non-contiguous ranges.To verify the How about, I first morphed the given, quite redundant code into a more concise form - of which one you find below.
function getUTMLatitudeZoneLetter3(latitude) { return ( // interval: (latitude > 84) ? "Z" // invalid : (latitude >= 72) ? "X" // [72..84] - incl 72N .. incl 84N : (latitude >= 64) ? "W" // [64..72) - incl 64N .. excl 72N : (latitude >= 56) ? "V" : (latitude >= 48) ? "U" : (latitude >= 40) ? "T" : (latitude >= 32) ? "S" : (latitude >= 24) ? "R" : (latitude >= 16) ? "Q" : (latitude >= 8) ? "P" : (latitude >= 0) ? "N" : (latitude >= -8) ? "M" : (latitude >= -16) ? "L" : (latitude >= -24) ? "K" : (latitude >= -32) ? "J" : (latitude >= -40) ? "H" : (latitude >= -48) ? "G" : (latitude >= -56) ? "F" : (latitude >= -64) ? "E" : (latitude >= -72) ? "D" : (latitude >= -80) ? "C" // [-80..-72) - iexcl 72S .. incl 80S : "Z" // invalid ); }After that it became clear how the arithmetic version would look like for the computational approach. Separating the defined range from the undefined ones is though still best done with the comparison approach. The values in the defined range are converted by a formula into range of 0..18, just parallel matching the "CDE...X" string. Note that letters I and O are 'skipped'.
Luckily, the irregular interval [72..84] N still works for the divide by 8, because the top value is less than 2 * 8 and collapse with Math.floor() to the the range of [72..80).
I'd like to point out a nice, genuine JavaScript language behaviors: #operatoroverloading, and #typeconversion. You may wonder about the multiplication by 1 in the correction term (latitude * 1 + 80) to base the defined range to begin with 0. JavaScript has the nice feature - Java-ists call it flaw - of going further with auto type conversion than many other languages - especially (strongly, static) typed ones. When the function argument latitude is as a string - which it most likely is when reading plainly from the wire) - then types matter expressions operator overloading.
Therefore, the value of (latitude + 80) with latitude having the string value "-80", the expression ("-80" + 80) evaluates to "-8080" string, because the "-80" is a string type and defines the type precedence of the operator overloading: + operator becomes string concatenation and hence the result is a string too. JavaScript will convert the number 80 into a string to accommodate the concatenation. Reordering and taking the number 80 first - (80 + latitude) - does not help either. The number 80 is operator overloading happens again to accommodate the "-80" string. Multiplying the latitude by 1 - (latitude * 1 + 80) - solves the issue with no (real) harm or value effect, even when latitude is (already) a number. Multiplication has no operator overloading and numeric is the only option. The "-80" string is converted to the number -80 to accommodate it and the expression evaluates to 0 - just as expected ;-).
Furthermore, notice the opening parenthesis on the same line of the return statement. This is because of another JavaScript genuine 'feature', or #returnpitfall, #jspitfall: If a line feed follows a return, the return is considered as complete and the function returns #undefined, no matter what keeps going on in the next line(s). I could have of course put something relevant after the return keyword to avoid it, for example, the logical expression for separating the valid from the invalid ranges:
function getUTMLatitudeZoneLetter4(latitude) { return ((latitude >= -80) && (latitude <= 84)) // defined, valid range ? "CDEFGHJKLMNPQRSTUVWX".charAt(Math.floor((latitude * 1 + 80) / 8)) // valid : "Z"; // undefined and invalid(?) }Try it yourself with the uploaded .html file... ;-).
For some (random and visualizing) unit testing I like to have a visual UI environment that I can drive with HTML5/JavaScript. Therefore I created a simple file-protocol served .html file. See uploaded screenshot and .html file. You can download the .html file, look at the various implementations, open it in a browser (with no harm) and play with it.
2 Attachments
-
You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
allObjects
File not uploaded, so I copied the code here.
Please find here the example firmware