[Proj] Re: Global Gauss-Kruger and libproj4---the final story

[strebe]

Timeline:

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.

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.

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.

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.

Regards,
-- daan Strebe


On Thursday 28 August 2008 10:23:31 pm strebe wrote:
> On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden"
> <geraldi.evenden at gmail.com> wrote:
>> Let's see. tan(x) has two values at x=90
>> degrees: +inf and -inf. So it is no longer a function, eh?
>> Infinity is not a value. Your conception and definitions are not
>> mathematical.
>>
>> Tangent is undefined at an abscissa of 90°±180°, with the
>> ordinate increasing asymptotically as the abscissa approaches 90°±180° from
>> lesser values, and with the ordinate decreasing asymptotically as the
>> abscissa approaches 90°±180° from greater values. I will not respond to any
>> argument over this, since it is basic mathematics, available anywhere. Any
>> mathematician would disagree with your characterization. Infinity as a
>> value is a convenient fiction, but it does not always work, and it does not
>> bear on the question of whether tangent is a function or not. I can't find
>> any such distinction for the definition of a "function." Please give
>> reference.
>> See, for example, 
>>
>> http://mathworld.wolfram.com/MultivaluedFunction.html
>
>LOL. It is still a function. So?




On Aug 29, 2008, at 7:57:48 AM, "Gerald I. Evenden" <geraldi.evenden at gmail.com> wrote:
From:   "Gerald I. Evenden" <geraldi.evenden at gmail.com>
Subject:    Re: Global Gauss-Kruger and libproj4---the final story
Date:   August 29, 2008 7:57:48 AM PDT
To: strebe <strebe at aol.com>
Cc: proj at lists.maptools.org
On Thursday 28 August 2008 10:23:31 pm strebe wrote:
> On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden"
> <geraldi.evenden at gmail.com> wrote: Let's see. tan(x) has two values at x=90
> degrees: +inf and -inf. So it is no longer a function, eh?
> Infinity is not a value. Your conception and definitions are not
> mathematical.
>
> Tangent is undefined at an abscissa of 90°±180°, with the
> ordinate increasing asymptotically as the abscissa approaches 90°±180° from
> lesser values, and with the ordinate decreasing asymptotically as the
> abscissa approaches 90°±180° from greater values. I will not respond to any
> argument over this, since it is basic mathematics, available anywhere. Any
> mathematician would disagree with your characterization. Infinity as a
> value is a convenient fiction, but it does not always work, and it does not
> bear on the question of whether tangent is a function or not. I can't find
> any such distinction for the definition of a "function." Please give
> reference.
> See, for example, 
>
> http://mathworld.wolfram.com/MultivaluedFunction.html

LOL. It is still a function. So?

> A bazillion other Web pages will do, easily searched for.
> Even if your questionable definition were true, it merely verifies that 
> proj_fwd() is a function because it only returns one value. It is defined 
> that way in the documentation.
> You have, yet again, confused yourself about the who is arguing what. Yes.
> You treat projections as functions. That's clear. That's always been clear.
> That's THE problem.

It only seems to be only a problem with you. I have not had anyone else bitch 
and moan about it.

> You have decided it's not YOUR problem, so now it's 
> your clients' problem. That doesn't make the problem go away. It just
> changes who it's a problem for.  I have specifically acknowledged multiple
> times that you have chosen, for your convenience, to ignore the multivalued
> results of projection formulæ in order to treat projections as functions.
> Why are you crowing 

Why do you insist on getting insulting. I merely define a condition. Is 
it "crowing" about it???

> about this evidence of proj_fwd() being a function when 
> its functional nature is exactly why we're even having this conversation?
> In terms of interruptions applying to all projections I presume you are
> referring to the del-lon=180 condition. In many projection software this is
> not a break and the map merely repeats on in the x direction.
> That is impossible for almost all projections that are not cylindric or
> pseudocylindric. It's merely a convenient evasion of responsibility that

LOL again.

> works for two common classes of projections. Meanwhile it can't work for
> most projections because most projections depend on trigonometric (and
> therefore periodic) manipulations of longitude, resulting in extended
> longitudinal ranges wrapping back onto themselves — resulting, even, on
> 180°E mapping onto 180°W. As far as I am
> aware it is always the graphic programmers job to handle this condition
> and  not the projection routine: when at the map edge recall the function
> with the sign of the lon term reversed.
> As far as "recall the function with the sign of the lon term reversed"
> goes, see the prior comment.

Hey sweet cheeks. Since you hate libproj4 so much why do you even bother 
sticking around here. I guess it is for the datum issues which I do not 
involve myself with.

> This was never about whose job it is. You're free to decide what's your job
> and what isn't. Rather, it's a matter of what has to happen regardless of
> who does what in order to get the job done. 

I have defined where libproj4 begins and ends long ago. So? If you do not 
like it go somewhere else rather than pursue these windmills.

> You have declared with much sophistry that somehow the ellipsoidal
> transverse Mercator can't be accommodated in libproj4 because of the cusps.
> That's nonsense. There is nothing unique to that projection from libproj4's
> perspective. Since you have put the onus of interruptions and odd
> boundaries on the client,

Because, by definition, that's where it is placed. Again, if you have never 
liked the conditions of the program why do you stick around and persist with 
character assassinations on graphical issues that other user are most likely 
aware of?

> then the same would be true in the case of the 
> ellipsoidal transverse Mercator. Meanwhile libproj4 could happily provide
> one result of the multivalued formulæ along the cusp, just as it does for
> every projection. BTW: you are the first person I have ever heard that
> refers to the wrap-around condition of longitude as an interruption if,
> indeed, that is what you are referring to.
> That is what I am referring to. It is an interruption by any rational
> analysis. I don't care if you call it a phlabbergompkin to distinguish it
> from what you call an interruption (which you would never be able to
> provide a definition for that's not arbitrary). It's exactly the same
> thing, and what you seem to think of as an "uninterrupted" map is
> undeniably interrupted. It's not important what it's called. It's important
> what it does. What it does is separate points on the map that are adjacent
> on the globe. If there are other examples, other than projections commonly
> recognized as interrupted (for example Goode) *please* name them.
> *Berghaus star
> *Peirce quincuncial
> *Waterman
> *Fuller dymaxion
> *Cahill butterfly
> *Guyou
> *Raizs armadillo
> *two-point equidistant
> *vertical perspective
> *general perspective
> *all of the dozens of polyhedral projections described in the literature
> *any projection in oblique aspect (which you handle with something of a
> hack, it appears)

As I have said many times, libproj4 does not handle cartoon projections like 
Berghaus star. Among some of the above I presume that you may be referring 
to visibility cutoffs such as in the perspectives and libproj4 indicates 
these by returning unprojectable condition. Several have odd boundaries 
which libproj4 handles properly by also returning unprojectable status for a 
point outside the visible or plottable boundary.

With the comment about the oblique procedure you are also insulting the late 
John Snyder as I merely implemented his formulae. Which is true with several 
of the other projections as I relied upon his formulae for conditions of 
visibility---the results are reflected in the return condition of the 
libproj4 *function*.

> Since whatever definition you use for "interruption" appears to be
> arbitrary, and I have no access to your arbitrary definition, I cannot
> guarantee that you'll agree that all the projections in that list are
> "interrupted" by your definition but are not "commonly recognized" as
> interrupted.

My goodness, how you like to convolute an argument. It has long been 
recognized by me that we *do not* have a common definition for "interrupted" 
projection. But you like to persist in exploring this issue in an attempt to 
support you claims and issues.

As another example, you appear to term the "invisibility" of a point in a 
projection like near-sided perspective as a interuption or at least the line 
where visibility does or does not occur (the "limb"). For libproj4 the issue 
is *only* where a point is visible or not---nor is the boundary of visibility 
an interruption. *Please* remember that libproj4 very easily tells the user 
about the visibility of the point.

There is nothing else to be said. If you do not like it, fine. Go someplace 
else. I have been perfectly transparent and hopefully clear as to what 
libproj4 provides and have not hidden anything.

> That's not my problem, and I will not argue over the list or 
> its meaning. I chose projections whose natural boundaries do not follow the
> common cylindric or azimuthal bounding parallels and meridians. The list is
> hardly exhaustive.

The number of projections is beyond estimation. libproj4 only scratches the 
surface with about 170 entry points, some of which create other "named" 
projections with appropriate options. My efforts are limited to what 
descriptions are available and even here I have not included some because of 
some unique property or condition of the projection. The lastest victim 
being the world extent TM.

> Perhaps you'll claim those are all cartoon projections, or nobody uses
> them, or whatever else. I don't care. Not my problem. It's a reasonable
> policy for you to limit your software to handle 95% of the needs and blow
> off the rest. It's not reasonable for you to claim your reasons are founded
> on some natural property of map projections. They're not.

Two states are apparent either I failed to give a clear description of the 
original problem or you do not have the mental capability to understand it.

All this subsequent BS has had little to do with my original issue.

> My point has only 
> ever been that you're rationalizing your decision not to support the
> ellipsoidal transverse Mercator with fallacious arguments, and I do not
> wish for the (doubtless rapidly fading) audience to be confused by such
> remarks.

I realize that this is merely a lover's quarrel and certainly will not be our 
last. Of course, I will make the obligatory counter claim about your 
irrational arguments and ridiculous conditions. 
>
> Regards,
> -- daan Strebe

Goodnight sweetheart. Don't let the bedbugs bite.
...
-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080829/c425194c/attachment.html>