similar to: 0.65 HPUX/AIX update

I've made some more changes to configure/make which still don't solve everything but I think I have to stop for now. Status AIX: * I can compile with gcc/f77/make. * AIX make check fails (cannot build base-Ex.R). * GNU make check fails in the contour example. * Plotting is broken (tickmarks go all the way thru). * IEEE fp stuff is strange (will look into this). * I still need f77 for

Full_Name: Albrecht Gebhardt Version: 0.65.0 OS: Digital Unix 4.0E Submission from: (NULL) (212.17.104.62) Plottimg on the Alpha stopped working with 0.65.0. The tickmarks have a length of -Inf and go across the whole plot. A first solution is the following patch: --- src/main/plot.c.alpha-patch Mon Sep 13 01:37:11 1999 +++ src/main/plot.c Mon Sep 13 01:58:16 1999 @@ -832,7 +832,7 @@

Update (for me): * On HPUX (cc/f77/make), make check passes the Examples but fails in arith-true.R because is.infinite(.Machine$double.base ^ .Machine$double.max.exp) gives FALSE. Interestingly > .Machine$double.base [1] 2 > .Machine$double.max.exp [1] 1024 > 2 ^ 1024 [1] 1.797693e+308 > 2 ^ 1025 [1] 1.797693e+308 > 2 ^ 2024 [1] 1.797693e+308 so I guess we need help here. *

Can anybody of the architects of R enlighten me about the reasoning behind the selection of the IEEE 754 mode for the building of R, please? Special points of interest are: 1. The selection seems to be based on the availability of isnan() and finite(). Is this a common way to test for IEEE 754? 2. The C9x draft introduces isfinite() instead of finite() (and as I see, some systems, e.g. the

Martin: With the recent change of adding -D_XOPEN_SOURCE_EXTENDED I cannot get artihmetic.c to compile---it dies because of undefined acosh etc. Is this specific of the system that I have access to? -k -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info",

Hi, this relates to R-devel of 1999/July/18. I will outline what I had to change to get R to compile with cc then with gcc. Note that R compiled with cc works, R compiled with gcc is broken. --> Compile with cc: 1) Edit src/main/saveload.c: disable the undefine! With the #undef _XOPEN_SOURCE_EXTENDED the compilation dies an untimely death. (And the header files are not as badly broken

Full_Name: Morten Welinder Version: 2.1.0 OS: src only Submission from: (NULL) (216.223.241.212) Now that pcauchy has been fixed, it is becoming clear that qcauchy suffers from the same problems. qcauchy(pcauchy(1e100,0,1,FALSE,TRUE),0,1,FALSE,TRUE) should yield 1e100 back, but I get 1.633178e+16. The code below does much better. Notes: 1. p need not be finite. -Inf is ok in the log_p

libswfdec/swfdec_as_context.c | 20 + libswfdec/swfdec_as_interpret.c | 9 libswfdec/swfdec_as_string.c | 15 - libswfdec/swfdec_as_strings.c | 2 libswfdec/swfdec_as_types.c | 2 test/trace/Makefile.am | 28 + test/trace/isnan-5.swf |binary

On 9/29/19 1:09 PM, Jan Gorecki wrote: > Dear R developers, > > I spotted that R_isNA and R_IsNaN could be improved when applied on a > vector where we could take out small part of their logic, run it once, > and then reuse inside the loop. Dear Jan, Looking at your examples, I just see you have hand-inlined R_IsNA/R_IsNaN, or is there anything more? In principle we could put

I submitted a patch keeping the traditional approach, HAVE_FINITE_IN_FLOAT_H and HAVE_ISNAN_IN_FLOAT... Just another case added to the others instead of a custom approach. --- Paolo On Oct 19, 2004, at 12:16 PM, Morten Ofstad wrote: > I don't know if Paolo submitted his patches for these files, but they > are not in the CVS -- I've chosen a slightly different strategy, >

>>>>> "Janusz" == Janusz Kawczak <jkawczak@fisher.stats.uwo.ca> writes: [You wrote to "owner-r-help@...." -- that's just me (MM); why did you not use the mailing list ? (R-devel or R-help)] Janusz> Hello, I am getting this 'strange' message when running the R Janusz> program on AIX 4.2.1. I have not had any problems with the

(Drats! Jitterbug is playing tricks with the PR# again. Attempting to refile so that we can kill PR#10509) Peter Dalgaard wrote: > Kurt.Hornik at wu-wien.ac.at wrote: > =20 >> ------- Start of forwarded message ------- >> Date: Tue, 13 Nov 2007 21:44:57 +0100 >> To: Steve Mongin <sjm at ccbr.umn.edu> >> Cc: cran at r-project.org >> Subject: Re: range(

Hi, By going through the mailing list archives, I noticed that people use the arrows() command to add error bars to their plots. I think there is a problem when trying to draw arrows of zero length. In the following code, certainly the x driver produces an odd-angled line. In the postscript device, NaNQ values are generated; when the postscript file is viewed in Ghostview, an error is then

Vince Carey found this (thank you!). Since the fix to the problem is not entirely obvious, I post this to R-devel as RFC: help(dist) says: >> Missing values are allowed, and are excluded from all computations >> involving the rows within which they occur. If some columns are >> excluded in calculating a Euclidean, Manhattan or Canberra >> distance, the sum is

R-2.9.0/include/R_ext/Arith.h has: int R_IsNA(double); /* True for R's NA only */ int R_IsNaN(double); /* True for special NaN, *not* for NA */ int R_finite(double); /* True if none of NA, NaN, +/-Inf */ #define ISNA(x) R_IsNA(x) /* True for *both* NA and NaN. The first and last lines are contradictory - if R_IsNA is true only for NA, not NaN, then ISNA should be the same.

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 10:20:39 +0200 > >I'm using scons to generate that files from .in files. I implemented in it >the configure check regarding iterators, hash and so on... >something like: > Hey, you've found the tool that makes it possible to generically reading Makefiles... Cool - The tool I've

Dear R developers, I spotted that R_isNA and R_IsNaN could be improved when applied on a vector where we could take out small part of their logic, run it once, and then reuse inside the loop. I setup tiny plain-C experiment. Taking R_IsNA, R_IsNaN from R's arithmetic.c, and building R_vIsNA and R_vIsNaN accordingly. For double input of size 1e9 (having some NA and NaN) I observed following

[Copied to R-bugs so it goes into the database.] On Mon, 13 Sep 1999, Ralf Herbrich wrote: > > Hello, > > I installed the new release 0.65.0 of R on our local Solaris system. As I > already (and sucessfully) installed the 0.64.0 and 0.64.1 version of R, I > hadn't had any trouble during the installation. But as I've started R in > order to see the demo I've got

Recently I reviewed my RPM spec files for DU 4.0, and noticed that I forgot to post some problems + patches: 1. ./configure fails to choose a PIC flag, I simply removed the AC_MSG_ERROR and it works. There is actually no PIC flag for DEC cc (with DU 4.0E) --- ./configure.in.alpha-patch Mon Aug 23 06:36:28 1999 +++ ./configure.in Sun Sep 12 17:38:27 1999 @@ -541,7 +541,9 @@

On Mar 3, 2010, at 9:32 AM, Jochen Wilhelmy wrote: > >> Is x*0 => 0 true if isnan(x)? >> > then where do I have to add it if I want to make it a non-standard > modification > of my local llvm version? > would it make sense to add a subset of float to llvm or a kind of modifier > (e.g. valid float to indicate that it is always valid and not nan) to > allow