<html><body name="Mail Message Editor"><div><br></div><div>Timeline:</div><div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">28 August 2008 05:04:53 PM: Strebe has stated that a function has one value for a single input. Evenden's premise: tan(x) has two values at 90°. Evenden's conclusion: Strebe must therefore believe tangent is not a function.</span></div><div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">28 August 2008 10:23:31 PM: Strebe explains that tan(x) does not have two values at x=90°. This destroys Evenden's premise and therefore his conclusion.</span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px;">29 August 2009 07:57:48 AM: Either unwilling to acknowledge that his conclusion about Strebe is false, or incapable of following his own chain of reasoning, Evenden pretends instead that Strebe has demonstrated that tangent is a function, and ridicules that, evidently as insignificant.</span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px;"><br></span></div><div>Mr. Evenden, mocking someone else for your own fallacies makes for an amusing read, but I doubt it furthers the purpose of the list. You abandon the original premises, substituting new ones, in every single chain of (un)reasoning recorded below. I ought to have left the conversation when I said I would. I apologize to the list for encouraging this epic nonsense.</div><div><br></div><div>Regards,</div><div>-- daan Strebe</div><div><br></div><div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">On Thursday 28 August 2008 10:23:31 pm strebe wrote:<br>> On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden"<br>> <geraldi.evenden@gmail.com> wrote:</span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">>> Let's see. tan(x) has two values at x=90<br>>> degrees: +inf and -inf. So it is no longer a function, eh?<br>>> Infinity is not a value. Your conception and definitions are not<br>>> mathematical.<br>>><br>>> Tangent is undefined at an abscissa of 90°±180°, with the<br>>> ordinate increasing asymptotically as the abscissa approaches 90°±180° from<br>>> lesser values, and with the ordinate decreasing asymptotically as the<br>>> abscissa approaches 90°±180° from greater values. I will not respond to any<br>>> argument over this, since it is basic mathematics, available anywhere. Any<br>>> mathematician would disagree with your characterization. Infinity as a<br>>> value is a convenient fiction, but it does not always work, and it does not<br>>> bear on the question of whether tangent is a function or not. I can't find<br>>> any such distinction for the definition of a "function." Please give<br>>> reference.<br>>> See, for example, <br>>><br>>> http://mathworld.wolfram.com/MultivaluedFunction.html</span></div><div><span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 11px; ">><br>>LOL. It is still a function. So?<br><br></span></div><div><br></div><div><br></div><br>On Aug 29, 2008, at 7:57:48 AM, "Gerald I. Evenden" <geraldi.evenden@gmail.com> wrote:<br><blockquote style="padding-left: 5px; margin-left: 5px; border-left-width: 2px; border-left-style: solid; border-left-color: blue; color: blue; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="width: 100%; "><div id="felix-mail-header-block" style="color: black; background-color: white; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: silver; padding-bottom: 1em; margin-bottom: 1em; width: 100%; "><table border="0" cellpadding="1" cellspacing="1" width="100%"><tbody><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>From:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span title=""Gerald I. Evenden" <geraldi.evenden@gmail.com>">"Gerald I. Evenden" <geraldi.evenden@gmail.com></span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>Subject:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span style="font-weight: bold; ">Re: Global Gauss-Kruger and libproj4---the final story</span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>Date:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span>August 29, 2008 7:57:48 AM PDT</span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>To:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span title="strebe <strebe@aol.com>">strebe <strebe@aol.com></span></td></tr><tr><td width="70px" style="font-family: 'Lucida Grande'; font-size: 8pt; color: gray; text-align: right; vertical-align: top; font-weight: bold; "><span>Cc:</span></td><td style="font-family: 'Lucida Grande'; font-size: 8pt; color: black; text-align: left; vertical-align: top; padding-left: 5px; "><span title="proj@lists.maptools.org">proj@lists.maptools.org</span></td></tr></tbody></table></div><div id="felix-mail-content-block" style="color: black; background-color: white; width: 100%; "><div style="font-family: monospace; color: black; background-color: white; font-size: 8pt; ">On Thursday 28 August 2008 10:23:31 pm strebe wrote:<br>> On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden"<br>> <geraldi.evenden@gmail.com> wrote: Let's see. tan(x) has two values at x=90<br>> degrees: +inf and -inf. So it is no longer a function, eh?<br>> Infinity is not a value. Your conception and definitions are not<br>> mathematical.<br>><br>> Tangent is undefined at an abscissa of 90°±180°, with the<br>> ordinate increasing asymptotically as the abscissa approaches 90°±180° from<br>> lesser values, and with the ordinate decreasing asymptotically as the<br>> abscissa approaches 90°±180° from greater values. I will not respond to any<br>> argument over this, since it is basic mathematics, available anywhere. Any<br>> mathematician would disagree with your characterization. Infinity as a<br>> value is a convenient fiction, but it does not always work, and it does not<br>> bear on the question of whether tangent is a function or not. I can't find<br>> any such distinction for the definition of a "function." Please give<br>> reference.<br>> See, for example, <br>><br>> http://mathworld.wolfram.com/MultivaluedFunction.html<br><br>LOL. It is still a function. So?<br><br>> A bazillion other Web pages will do, easily searched for.<br>> Even if your questionable definition were true, it merely verifies that <br>> proj_fwd() is a function because it only returns one value. It is defined <br>> that way in the documentation.<br>> You have, yet again, confused yourself about the who is arguing what. Yes.<br>> You treat projections as functions. That's clear. That's always been clear.<br>> That's THE problem.<br><br>It only seems to be only a problem with you. I have not had anyone else bitch<span class="Apple-converted-space"> </span><br>and moan about it.<br><br>> You have decided it's not YOUR problem, so now it's<span class="Apple-converted-space"> </span><br>> your clients' problem. That doesn't make the problem go away. It just<br>> changes who it's a problem for. I have specifically acknowledged multiple<br>> times that you have chosen, for your convenience, to ignore the multivalued<br>> results of projection formulæ in order to treat projections as functions.<br>> Why are you crowing<span class="Apple-converted-space"> </span><br><br>Why do you insist on getting insulting. I merely define a condition. Is<span class="Apple-converted-space"> </span><br>it "crowing" about it???<br><br>> about this evidence of proj_fwd() being a function when<span class="Apple-converted-space"> </span><br>> its functional nature is exactly why we're even having this conversation?<br>> In terms of interruptions applying to all projections I presume you are<br>> referring to the del-lon=180 condition. In many projection software this is<br>> not a break and the map merely repeats on in the x direction.<br>> That is impossible for almost all projections that are not cylindric or<br>> pseudocylindric. It's merely a convenient evasion of responsibility that<br><br>LOL again.<br><br>> works for two common classes of projections. Meanwhile it can't work for<br>> most projections because most projections depend on trigonometric (and<br>> therefore periodic) manipulations of longitude, resulting in extended<br>> longitudinal ranges wrapping back onto themselves — resulting, even, on<br>> 180°E mapping onto 180°W. As far as I am<br>> aware it is always the graphic programmers job to handle this condition<br>> and not the projection routine: when at the map edge recall the function<br>> with the sign of the lon term reversed.<br>> As far as "recall the function with the sign of the lon term reversed"<br>> goes, see the prior comment.<br><br>Hey sweet cheeks. Since you hate libproj4 so much why do you even bother<span class="Apple-converted-space"> </span><br>sticking around here. I guess it is for the datum issues which I do not<span class="Apple-converted-space"> </span><br>involve myself with.<br><br>> This was never about whose job it is. You're free to decide what's your job<br>> and what isn't. Rather, it's a matter of what has to happen regardless of<br>> who does what in order to get the job done. <br><br>I have defined where libproj4 begins and ends long ago. So? If you do not<span class="Apple-converted-space"> </span><br>like it go somewhere else rather than pursue these windmills.<br><br>> You have declared with much sophistry that somehow the ellipsoidal<br>> transverse Mercator can't be accommodated in libproj4 because of the cusps.<br>> That's nonsense. There is nothing unique to that projection from libproj4's<br>> perspective. Since you have put the onus of interruptions and odd<br>> boundaries on the client,<br><br>Because, by definition, that's where it is placed. Again, if you have never<span class="Apple-converted-space"> </span><br>liked the conditions of the program why do you stick around and persist with<span class="Apple-converted-space"> </span><br>character assassinations on graphical issues that other user are most likely<span class="Apple-converted-space"> </span><br>aware of?<br><br>> then the same would be true in the case of the<span class="Apple-converted-space"> </span><br>> ellipsoidal transverse Mercator. Meanwhile libproj4 could happily provide<br>> one result of the multivalued formulæ along the cusp, just as it does for<br>> every projection. BTW: you are the first person I have ever heard that<br>> refers to the wrap-around condition of longitude as an interruption if,<br>> indeed, that is what you are referring to.<br>> That is what I am referring to. It is an interruption by any rational<br>> analysis. I don't care if you call it a phlabbergompkin to distinguish it<br>> from what you call an interruption (which you would never be able to<br>> provide a definition for that's not arbitrary). It's exactly the same<br>> thing, and what you seem to think of as an "uninterrupted" map is<br>> undeniably interrupted. It's not important what it's called. It's important<br>> what it does. What it does is separate points on the map that are adjacent<br>> on the globe. If there are other examples, other than projections commonly<br>> recognized as interrupted (for example Goode) *please* name them.<br>> *Berghaus star<br>> *Peirce quincuncial<br>> *Waterman<br>> *Fuller dymaxion<br>> *Cahill butterfly<br>> *Guyou<br>> *Raizs armadillo<br>> *two-point equidistant<br>> *vertical perspective<br>> *general perspective<br>> *all of the dozens of polyhedral projections described in the literature<br>> *any projection in oblique aspect (which you handle with something of a<br>> hack, it appears)<br><br>As I have said many times, libproj4 does not handle cartoon projections like<span class="Apple-converted-space"> </span><br>Berghaus star. Among some of the above I presume that you may be referring<span class="Apple-converted-space"> </span><br>to visibility cutoffs such as in the perspectives and libproj4 indicates<span class="Apple-converted-space"> </span><br>these by returning unprojectable condition. Several have odd boundaries<span class="Apple-converted-space"> </span><br>which libproj4 handles properly by also returning unprojectable status for a<span class="Apple-converted-space"> </span><br>point outside the visible or plottable boundary.<br><br>With the comment about the oblique procedure you are also insulting the late<span class="Apple-converted-space"> </span><br>John Snyder as I merely implemented his formulae. Which is true with several<span class="Apple-converted-space"> </span><br>of the other projections as I relied upon his formulae for conditions of<span class="Apple-converted-space"> </span><br>visibility---the results are reflected in the return condition of the<span class="Apple-converted-space"> </span><br>libproj4 *function*.<br><br>> Since whatever definition you use for "interruption" appears to be<br>> arbitrary, and I have no access to your arbitrary definition, I cannot<br>> guarantee that you'll agree that all the projections in that list are<br>> "interrupted" by your definition but are not "commonly recognized" as<br>> interrupted.<br><br>My goodness, how you like to convolute an argument. It has long been<span class="Apple-converted-space"> </span><br>recognized by me that we *do not* have a common definition for "interrupted"<span class="Apple-converted-space"> </span><br>projection. But you like to persist in exploring this issue in an attempt to<span class="Apple-converted-space"> </span><br>support you claims and issues.<br><br>As another example, you appear to term the "invisibility" of a point in a<span class="Apple-converted-space"> </span><br>projection like near-sided perspective as a interuption or at least the line<span class="Apple-converted-space"> </span><br>where visibility does or does not occur (the "limb"). For libproj4 the issue<span class="Apple-converted-space"> </span><br>is *only* where a point is visible or not---nor is the boundary of visibility<span class="Apple-converted-space"> </span><br>an interruption. *Please* remember that libproj4 very easily tells the user<span class="Apple-converted-space"> </span><br>about the visibility of the point.<br><br>There is nothing else to be said. If you do not like it, fine. Go someplace<span class="Apple-converted-space"> </span><br>else. I have been perfectly transparent and hopefully clear as to what<span class="Apple-converted-space"> </span><br>libproj4 provides and have not hidden anything.<br><br>> That's not my problem, and I will not argue over the list or<span class="Apple-converted-space"> </span><br>> its meaning. I chose projections whose natural boundaries do not follow the<br>> common cylindric or azimuthal bounding parallels and meridians. The list is<br>> hardly exhaustive.<br><br>The number of projections is beyond estimation. libproj4 only scratches the<span class="Apple-converted-space"> </span><br>surface with about 170 entry points, some of which create other "named"<span class="Apple-converted-space"> </span><br>projections with appropriate options. My efforts are limited to what<span class="Apple-converted-space"> </span><br>descriptions are available and even here I have not included some because of<span class="Apple-converted-space"> </span><br>some unique property or condition of the projection. The lastest victim<span class="Apple-converted-space"> </span><br>being the world extent TM.<br><br>> Perhaps you'll claim those are all cartoon projections, or nobody uses<br>> them, or whatever else. I don't care. Not my problem. It's a reasonable<br>> policy for you to limit your software to handle 95% of the needs and blow<br>> off the rest. It's not reasonable for you to claim your reasons are founded<br>> on some natural property of map projections. They're not.<br><br>Two states are apparent either I failed to give a clear description of the<span class="Apple-converted-space"> </span><br>original problem or you do not have the mental capability to understand it.<br><br>All this subsequent BS has had little to do with my original issue.<br><br>> My point has only<span class="Apple-converted-space"> </span><br>> ever been that you're rationalizing your decision not to support the<br>> ellipsoidal transverse Mercator with fallacious arguments, and I do not<br>> wish for the (doubtless rapidly fading) audience to be confused by such<br>> remarks.<br><br>I realize that this is merely a lover's quarrel and certainly will not be our<span class="Apple-converted-space"> </span><br>last. Of course, I will make the obligatory counter claim about your<span class="Apple-converted-space"> </span><br>irrational arguments and ridiculous conditions.<span class="Apple-converted-space"> </span><br>><br>> Regards,<br>> -- daan Strebe<br><br>Goodnight sweetheart. Don't let the bedbugs bite.<br>...<br>--<span class="Apple-converted-space"> </span><br>The whole religious complexion of the modern world is due<br>to the absence from Jerusalem of a lunatic asylum.<br>-- Havelock Ellis (1859-1939) British psychologist<br><br></div></div></div></span></blockquote><br><div><br></div><div class="aol_ad_footer" id="u49EDD80EBC52441689F7742F65C12407"><FONT style="color: black; font: normal 10pt ARIAL, SAN-SERIF;"><HR style="MARGIN-TOP: 10px"><A title="http://mapquest.com/toolbar?ncid=mpqmap00050000000010" href="http://mapquest.com/toolbar?ncid=mpqmap00050000000010" target="_blank">Get the MapQuest Toolbar</A>. Directions, Traffic, Gas Prices & More!</FONT></div></body></html>