From Martin Maechler <maechler@stat.math.ethz.ch>  Wed May 24 13:55:54 2000
From: Martin Maechler <maechler@stat.math.ethz.ch> (Martin Maechler)
Date: Wed, 24 May 2000 14:55:54 +0200 (CEST)
Subject: [Rd] hypot(x,y) instead of pythag(a,b) ?!
In-Reply-To: <Pine.GSO.4.05.10005240940410.4891-100000@auk.stats>
References: <14635.33218.325606.890109@aragorn.ci.tuwien.ac.at>
 <Pine.GSO.4.05.10005240940410.4891-100000@auk.stats>
Message-ID: <14635.53594.717309.718373@gargle.gargle.HOWL>

>>>>> "BDR" == Prof Brian D Ripley <ripley@stats.ox.ac.uk> writes:

    >> >>>>> Martin Maechler writes:
    >> 
    >> > My "theses"
    >> 
    >> >    o when hypot() is available, it should be used since it will be 
    >> >      efficient, precise, etc.
    >> >    o when it's not available, our "configure" should find out, and set
    >> >      corresponding "HAVE_HYPOT" to `false'.

    BDR> Are there any such systems?  After all 1.0.1 requires hypot, and we
    BDR> have heard no complaints.  I suspect the cause of the confusion is
    BDR> (plot.c)

    BDR> #ifdef Macintosh
    BDR> # define hypot pythag
    BDR> #endif

    BDR> so assume that the Mac port did not have hypot. However, a
    BDR> different version appears in the 1.0.1 sources, and it appears
    BDR> _after_ hypot is first used, so I am puzzled as to how the current
    BDR> version got there, or why it would work. (If a system does not
    BDR> have hypot, presumably its headers do not either!)

    >> >    o in that case, we should provide a hypot()  {for the above code to
    >> >      work!}, and we probably should use (an improvement?) of the current
    >> >      pythag() function [src/appl/pythag.c in R versions <= 1.0.1].

    >> >    o Hence, we should drop pythag() from the R API and rather say
    >> >    that we provide hypot() whenever the system's C library (or its
    >> >    "math.h", aka libm.*, aka "-m" part, respectively) does *not*
    >> >    provide it.

    BDR> I was puzzled as to why you put it in the API at all.

{my ignorance about the widely available hypot() !}

    >> >    o I think an R function  hypot() would also make sense.

    BDR> Don't think so.  What you we is an n-term not 2-term version, and that's
    BDR> what vecnorm would do (if we had it).
agreed, good point!
  [does S-plus'  vecnorm()  avoid underflow and overflow reliably?]

    BDR> This does all seem to me to be trying to solve a non-existent problem.

Not according to our own (R core) standards,
which I thought to be roughly like 

 GOLD>> We require ANSI C 
 GOLD>> and everything else must be tested for by configure
 GOLD>>   (and worked around either be saying (warning) "is not available",
 GOLD>>    or by providing own code).
  
I think hypot() definitely falls in that class, 
particularly since it's not even POSIX [as of Lewine(1991)]

Martin
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] hypot(x,y) instead of pythag(a,b) ?!
Martin Maechler