Re: [R] Solaris10-amd64-studio10 compilers

2005-08-20 Thread Vin Everett
Prof Brian Ripley wrote:
 On Fri, 19 Aug 2005, Vin Everett wrote:
 
 I am trying to compile R-2.1.1 on Solaris10, with the Studio10 compilers.

 When I try to compile 64bit with
 CFLAGS=-xarch=amd64
 export CFLAGS

 I get a configure failure on

 checking for rl_callback_read_char in -lreadline... no
 checking for history_truncate_file... no
 configure: error: --with-readline=yes (default) and headers/libs are not
 available

 unset CFLAGS and its fine will compile 32bit.

 Any ideas gratefully received.

 I should say I installed the readline headers etc /usr/local
 
 
 So, your readline is probably not 64-bit: see the R-admin manual and 
 check in config.log.
 
 a configure with --without-readline but with CFLAGS=-xarch=amd64
 goes on to

 checking for dummy main to link with Fortran libraries... none
 checking for Fortran name-mangling scheme... unknown
 configure: WARNING: unknown Fortran name-mangling scheme
 checking whether f77 appends underscores to external names... unknown
 configure: error: cannot use Fortran

 Again this is the studio10 fortran.
 
 
 Please note you need to set FFLAGS to match.  If you consult the R-admin 
 manual you will see that sparc users need somewhat different settings: 
 please emulate those.
 


Thanks Brian,

I will give that a try.

Cheers Vin

-- 
[EMAIL PROTECTED]
JDRF/WT Diabetes and Inflammation Laboratory (DIL)
Cambridge Institute for Medical Research (CIMR)
Wellcome Trust/MRC Building Addenbrooke's Hospital
Hills Road Cambridge CB2 2XY
Tel +44 1223 763212
Fax +44 1223 762102
Mob +44 7990 966266

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] FFT, frequs, magnitudes, phases

2005-08-20 Thread Martin Maechler
 PD == Peter Dalgaard [EMAIL PROTECTED]
 on 19 Aug 2005 14:16:42 +0200 writes:

PD Wolfgang Waser [EMAIL PROTECTED] writes:
 Hi,
 
 I'm in dire need of a fast fourier transformation for me
 stupid biologist, i.e. I have a heartbeat signal and
 would like to decompose it into pure sin waves, getting
 three vectors, one containing the frequencies of the sin
 waves, one the magnitudes and one the phases (that's what
 I get from my data acquisition software's FFT function).
 I'd be very much obliged, if someone could point out
 which command would do the job in R.

PD fft(), but notice that it gives the complex
PD transform. You need to do a little homework to get at
PD the magnitude/phase values. (Basically, you just have to
PD take Mod() and Arg(), but there some conventions about
PD the frequencies and multipliers that one can get wrong).

Once you've finished the homework, others might be interested
in your result... so it will be found in the future using 
RSiteSearch().

Martin

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] Installing R in Fedora Core 4

2005-08-20 Thread Prof Brian Ripley
On Fri, 19 Aug 2005, Gavin Simpson wrote:

 On Fri, 2005-08-19 at 11:07 -0400, White, Charles E WRAIR-Wash DC wrote:
 -Original Message-
 On Fri, 8/19, Gavin Simpson wrote:
 Peter Dalgaard has noted, on the R-Devel list (sorry I can't provide the
 link to the mail - the link from the R site to the mail archives wasn't
 working when I tried), that there are problems with the R rpm from
 Fedora Extras, including a strange printing bug. I believe Peter now
 thinks this is a bug in R (seem to have deleted that post - doh) exposed
 by the compilation flags used by the maintainer of the Fedora Extras
 rpm.

 If you want and rpm to install, then Martyn Plummer provides R binaries
 for Red Hat / Fedora systems that are available from CRAN e.g: for FC4
 http://www.stats.bris.ac.uk/R/bin/linux/redhat/fc4/

 Martyn has also made these available via a yum-compatible repository, so
 the benefits you note of auto-notification of updates etc. apply here as
 well.

 HTH

 G
 -End Original Message-

 The last time I tried to use the Martyn Plummer RPMs they were compiled
 without enabling shared libraries and I ended up compiling R myself so
 that I could use JGR. Messages describing the problem with the version
 actually on the Extras CD were my other unstated reason for describing
 yum instead of downloading the CD. I haven't heard there is a problem
 with Fedora's new RPMs but that doesn't prove that there aren't any. I
 fully agree with Martyn Plummer's readme notice that describes Fedora
 Core as bleeding edge technology not to be trusted for production use.
 Fedora Core describes itself that way.

 Do you mean the shared library libR.so? If so, the README in the FC3
 section indicates that these rpms now include the functionality you
 require. The absence of a README in the FC4 section means it is not
 clear from there if these rpms are also compiled with the shared
 library.

They almost certainly are, for 2.1.1, since they are compiled from the 
same spec file.

 From Peter's email, it would seem that the maintainer of the R rpm for
 Extras continues to use the compiler flags that cause the problems
 previously described (I haven't confirmed that this is still the case
 mind you).

It is confirmed not the case for R-devel, but is for 2.1.1 which is 
what the RPMs are for.

 Although FC4 is bleeding edge, I've had very few problems with in on my
 new laptop or my home desktop - after initial gcc v4.0.0 and gfortran
 teething troubles that is.

Although gcc 4.0.1 has helped, there are dozens of ongoing problems which 
seems squarely laid at the door of gfortran, as well as an appreciable 
performance loss.  On AMD64 there are subtle incompatibility issues 
between gfortran and everything else (g77, gcc3 and gcc4) that make mixing 
C and Fortran code tricky at best.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


[R] diagonal matrices

2005-08-20 Thread Afshartous, David
 
Hello all,
 
I have matrices V.i  of dimension n.i x n.i, where i = 1, ..., J, and the  sum 
of n.i  equals N.  (and n.i ! = n.j)
 
goal: create one large matrix V, where V has matrices V.i on diagonal.
 
I create each matrix V.i in a for loop (1 to J), so each time I'd like to 
augment V with the 
most recently calculated V.i, such that I'll have V after the final iteration 
of the for loop.
 
question: how to initialize V and do the augmentation.   any advice much 
appreciated.
 
cheers,
dave 
 
ps - please respond directly to [EMAIL PROTECTED], thanks!
 
 

[[alternative HTML version deleted]]

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] Determining physical display dimensions

2005-08-20 Thread Marc Schwartz
On Fri, 2005-08-19 at 13:17 -0500, Earl F. Glynn wrote: 
 Berton Gunter [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
 
  Failing that, (how) can this be done for Windows (XP or 2000, say) ?
 
 Take a look at the Windows GetDeviceCaps API call
 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_88s3.asp
 
 Parameters that can be queried include:
 HORZRES  Width, in pixels, of the screen.
 VERTRES Height, in raster lines, of the screen.
 
 HORZSIZE Width, in millimeters, of the physical screen
 VERTSIZE  Height, in millimeters, of the physical screen
 
 The specifics of how to use this API call will vary by language.  Google
 will be your friend.


FWIW, in case anyone should see this thread and wonder how to do this
somewhat easily in R for systems running X, there is a CLI utility
called 'xdpyinfo' that returns a great deal of data on the connected
display(s).


 display.size - system(xdpyinfo | grep dimensions, intern = TRUE)
 display.dpi - system(xdpyinfo | grep resolution, intern = TRUE)

 display.size
[1]   dimensions:1600x1200 pixels (301x231 millimeters)

 display.dpi
[1]   resolution:135x132 dots per inch


One can then parse the above using R functions as required. Such as:

 d.size - unlist(strsplit(display.size, split = [[:space:]|(|)|x]))

 d.size
[1] dimensions: 
[5] 16001200
[9] pi  els 301
[13] 231 millimeters 


 h.pix - as.numeric(d.size[7])
 v.pix - as.numeric(d.size[8])

 h.mm - as.numeric(d.size[12])
 v.mm - as.numeric(d.size[13])


 line1 - sprintf(The current display is %d x %d pixels, 
h.pix, v.pix)


 line2 - sprintf(with a physical size of %d x %d mm, h.mm, v.mm)


 cat(line1, line2, sep = \n)
The current display is 1600 x 1200 pixels
with a physical size of 301 x 231 mm


This can get more complicated with multi-monitor systems, depending upon
whether you are running in xinerama (multi-monitor spanning mode) or
non-xinerama mode and consideration for symmetric or asymmetric
resolutions. 'man xdpyinfo' and 'man X' (noting the 'DISPLAY'
environment variable) will be helpful here to determine which
display/screen R is running on.

For example, on my system which has two displays, each with 1600x1200, I
get:

 Sys.getenv(DISPLAY)
DISPLAY
 :0.0

with R running on the main laptop LCD (15 diag), versus:

 Sys.getenv(DISPLAY)
DISPLAY
 :0.1

with R running on the external LCD (20.1 diag), with the DISPLAY
variable indicating:

:DisplayNumber.ScreenNumber


Thus, on my system, the output of the system() calls are actually:

 display.size - system(xdpyinfo | grep dimensions, intern = TRUE)
 display.dpi - system(xdpyinfo | grep resolution, intern = TRUE)

 display.size
[1]   dimensions:1600x1200 pixels (301x231 millimeters)
[2]   dimensions:1600x1200 pixels (411x311 millimeters)

 display.dpi
[1]   resolution:135x132 dots per inch
[2]   resolution:99x98 dots per inch


HTH,

Marc Schwartz

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] diagonal matrices

2005-08-20 Thread Prof Brian Ripley
On Sat, 20 Aug 2005, Afshartous, David wrote:

 I have matrices V.i of dimension n.i x n.i, where i = 1, ..., J, and the 
 sum of n.i equals N.  (and n.i ! = n.j)

 goal: create one large matrix V, where V has matrices V.i on diagonal.

 I create each matrix V.i in a for loop (1 to J), so each time I'd like 
 to augment V with the most recently calculated V.i, such that I'll have 
 V after the final iteration of the for loop.

 question: how to initialize V and do the augmentation.  any advice much 
 appreciated.

It is probably best to pre-create a matrix and fill in the blocks.  As in

V - matrix(0, N, N)
# let n be a vector of what you called n.i
n0 - c(0, cumsum(n))
for(i in 1:J) {
ind - (n0[i]+1):n0[i+1]
V[ind, ind] - V.i
}


 cheers,
 dave

 ps - please respond directly to [EMAIL PROTECTED], thanks!

Please set that as your reply address to ease the lot of your helpers.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html


Re: [R] repeated - R package - Compilation Error

2005-08-20 Thread Martin Maechler
 rab45 == rab45  rab45
 on Thu, 11 Aug 2005 09:25:14 -0400 (EDT) writes:

 .

rab45 I'm not sure what your point is. I'm getting a compilation error for 
a
rab45 package that should compile without errors. The error message 
doesn't say
rab45 anything about needing anything - it doesn't complain about
rab45 dependencies. Now once I got repeated to compile, it did give a
rab45 *warning message about needing rmutils. But rmutils won't compile 
and
rab45 gives several error messages (in my other post). I've installed many 
R
rab45 packages and I've never seen problems like this before.

well, probably the others where CRAN or bioconductor packages ?

You know, there *is* a reason why we (actually, the repository
maintainers) require that a package runs  R CMD check without
a warning.  
If package authors are not willing to clean up and document
their code well enough to be accepted by CRAN,  you have to
expect hardship when trying to install / use the package

Martin Maechler

__
R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html