similar to: R-alpha: christmas wish (partial support for single)

[R-devel'ers: spill over from R-core .. -- MM] >>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes: >>>>> Robert Gentleman writes: >> In preparing the next Windows release I want to make opening up >> system data files (and their documentation) more transparent. I >> would really like to adopt the

I tried to convert hastie & tibshiranis mda package to R but ended with a bunch of unresolved symbols: R.binary: can't resolve symbol 'dbksl_' R.binary: can't resolve symbol 'dblepr_' R.binary: can't resolve symbol 'dqrdca_' R.binary: can't resolve symbol 'intpr_' R.binary: can't resolve symbol 'pack_' R.binary: can't resolve

>>>>> Thomas Lumley writes: > On Fri, 1 Aug 1997, Kurt Hornik wrote: >> Thomas, >> >> Could you add the "-lf2c" at the end of the line >> @$(LD) $(SHLIBLDFLAGS) -o $(LIBNAME).so $(OBJS) >> in acepack's src-c/Makefile? >> >> I ran across an identical pow_dd problem recently with another package. >> Did we always need

I am currently attempting to install R on our DEC Alpha computer, and am having a little trouble. I have f2c installed in lieu of a Fortran compiler, and have installed libf2c in a subdirectory below where f2c lives, although as you can see below, libf2c is not being found during configuration. I'm not sure what I would need to do to rectify this. However, my main problem is with the

Hi, I was looking at configure.in for R-1.4.1 and in the case "${host_cpu}" in part under alpha CPU's, the switch of -mieee for g77 and -fpe3 otherwise is an OSF specific, not alpha specific issue. In particular, if someone used f2c-f77 (shell script which emulates a fortran compiler with f2c and the c compiler), they'd get the broken -fpe3. I'd probably either test for

> If we don't assume that everyone has f2c then people distributing > libraries need to distribute all or part of libf2c. Source to libf2c is > readily available. I'm a bit confused about this discussion, but since I don't have f2c on the computer I've been using the past week, I assume most of the necessary parts on this library have been distributed with R (but I

[[Again I diverge to R-devel, I think we need more opinions here...]] >>>>> "KH" == Kurt Hornik <hornik@ci.tuwien.ac.at> writes: >>>>> Ross Ihaka writes: >> I am beginning to get a bit more free time and I would like to get a >> "stable" version out as soon as possible. (This is of course so I can >> break

[I do think this discussion belongs to R-devel rather than anywhere else .. MM] >>>>> "Kurt" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes: >>>>> Peter Dalgaard BSA writes: >> Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes: KH>>> While trying to write documentation for data.class(), I came

>> I'm a bit confused about this discussion, but since I don't have f2c on ... >A lot of Fortran code doesn't require any libf2c routines. When routines >are needed the most common ones are the exponentiation routines pow_dd, >pow_ii and pow_di (pow_ri is for single precision reals and so is less >needed in R, which uses double precision). However, *some* fortran

Batch: For me, batch in its present state is broken and useless. My primary need for batch is to produce a final output file of a session after I have worked out a sequence of procedures. I save my instructions in a file that I can source, then run it in batch to have a copy of input and output together. (If there was a log file (or dribble), this problem would be solved.) At present, there are

>>>>> "KH" == Kurt Hornik <Kurt.Hornik@ci.tuwien.ac.at> writes: >>>>> Robert Gentleman writes: >>> In preparing the next Windows >>> release I want to make opening up system data files (and their >>> documentation) more transparent. I would really like to adopt >>> the convention that data files use

Hi, Kurt Hornik and myself have an almost successful build of R on AIX including dynamic loading of libraries ... which fails make check :-( Anyway, as we have no AIX experience at all, maybe somebody else knows what's going on. Here's the problem: > 1/0 [1]INF > is.finite(1/0) [1] TRUE R was built using the flags included below, gcc version is 2.7.2. Does anybody with

Kurt writes KH>> * I am also not sure whether one should include the write.table() KH>> function I posted some time ago. It seems to be a bad idea to make a KH>> contrib package out of it (containing only a single function ...). Yes, I think we should have a good "write" function for data.frames. However, I would go even further and 'vote' for a GENERIC

When trying to build R-1.1.0, the configure script reported no Fortran compiler, even though '/usr/bin/f2c' was present, and R-1.0.1 had found and successfully used this. I traced this to an apparent typo in line 2067 of configure: for name in g77 fort77 f77 f90 xlf cf77 fc; do changing this to: for name in g77 fort77 f77 f90 xlf cf77 f2c; do allowed the script to 'find'

>R INSTALL dse rlibs >Installing package `dse' ... >libs >gcc -g -fpic -I/usr/local/R-0.61/include -c dsefor.c -o dsefor.o >/tmp/cca02533.i:1: numeric constant with no digits >/tmp/cca02533.i:1: numeric constant with no digits >... >is there something wrong with my gcc or is there some >option missing somewhere? >I suspect the problem might have to do with

>R INSTALL dse rlibs >Installing package `dse' ... >libs >gcc -g -fpic -I/usr/local/R-0.61/include -c dsefor.c -o dsefor.o >/tmp/cca02533.i:1: numeric constant with no digits >/tmp/cca02533.i:1: numeric constant with no digits >... >is there something wrong with my gcc or is there some >option missing somewhere? >I suspect the problem might have to do with

Ok, I did the following experiment dyn.load("/usr/local/lib/libf2c.so.2.0") dyn.load("try.so") .Fortran("try", 10.5) where try.so contains the following compiled subroutine subroutine try(x) double precision x write(*,*) x return end It worked just fine (at least here on my FreeBSD machine at home). So it seems that it will be

Dear Dirk, I have had the exactly same problem like Ivo and his solution worked for me. Hence the USE=f77 flag is NOT a typo but a Gentoo quirk. As far as modifying the configure script is concerned, I believe that it is certainly possible to perform said check (if 'f77 --version == f2c' then die) only on x86_64 platforms. And I'd argue it is f2c's fault. AMD64 linux distros have

My appologies, this estimation is about right, I spent last week at COMPSTAT in prague and didn't follow the list closely. Inspite of this fact I believe my posting is not entirely out of date. regards Diman Todorov ------------------------------ You are 8 days behind the times -- take a look at the current R-devel. On Sun, 29 Aug 2004, Diman Todorov wrote: > Dear Dirk, > I

I am beginning a much-delayed update of odesolve to include several ordinary differential equation solvers from the Livermore package ODEPACK. These are much-used and reliable Fortran codes, and I plan (as I did for lsoda in the current odesolve package) to make as few changes as possible to the Fortran 77 code. However, recently someone wanted to make nested calls to lsoda, which will not work,