Re: [Rd] pbinom with size argument 0 (PR#8560)
P Ehlers <[EMAIL PROTECTED]> writes: > I prefer a (consistent) NaN. What happens to our notion of a > Binomial RV as a sequence of Bernoulli RVs if we permit n=0? > I have never seen (nor contemplated, I confess) the definition > of a Bernoulli RV as anything other than some dichotomous-outcome > one-trial random experiment. What's the problem ?? An n=0 binomial is the sum of an empty set of Bernoulli RV's, and the sum over an empty set is identically 0. > Not n trials, where n might equal zero, > but _one_ trial. I can't see what would be gained by permitting a > zero-trial experiment. If we assign probability 1 to each outcome, > we have a problem with the sum of the probabilities. Consistency is what you gain. E.g. binom(.,n=n1+n2,p) == binom(.,n=n1,p) * binom(.,n=n2,p) where * denotes convolution. This will also hold for n1=0 or n2=0 if the binomial in that case is defined as a one-point distribution at zero. Same thing as any(logical(0)) etc., really. -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Troubles with Fortran and C (was with the function rmultinom.c of the R's Random Number Generator)
Thank you for the answer. However, I sought in Doc. Writing R
extensions, in particular in the paragraph 5.6 "Calling C from FORTRAN
and vice versa" (page 67) but I did not find anything which could help me to
correct my code. Indeed, rmultinom.c is a particular function
since arrays are passed in arguments. Has somebody ever
written a wrapper for this function?
Thanks in advance,
Sophie.
At 17:06 20/01/06 +, Prof Brian Ripley wrote:
>All arguments to functions called from C by Fortran are pointers
>(or should be: yours are not). The error is within your own code.
>
>You don't want to call rndstart and rndend around every call, only before
>the first and after the last.
>
>This is not the list for advice om mixed Fortran/C programming, though.
>On Fri, 20 Jan 2006, Sophie Ancelet wrote:
>
>>
>> Hi,
>>
>> I'm simulating a Markov chain in Fortran interfaced with R-2.2.1 in order
>> to generate data according to a Markov Random Field called the Potts model.
>>
>> R Version:
>> platform i686-pc-linux-gnu
>> arch i686
>> os linux-gnu
>> system i686, linux-gnu
>> status
>> major2
>> minor2.1
>> year 2005
>> month12
>> day 20
>> svn rev 36812
>>
>>
>>
>>
>> Each loop of my Fortran calls the function rmultinom.c of the R's Random
>> Number Generator through the wrapper:
>>
>> #include
>> #include
>> void F77_SUB(sarmultinom)(int n,
>> double* prob,
>> int K,
>> int* rN){
>> rmultinom(n, prob, K, rN);}
>>
>>
>>
>> My fortran program is:
>>
>> subroutine testsarmultinom(n,prob,K,rN)
>> implicit none
>> integer n,K,rN(K)
>> double precision prob(K)
>>
>> call rndstart()
>> call sarmultinom(n,prob,K,rN)
>> call rndend()
>> end
>>
>>
>> In order to understand better how the function rmultinom.c works, I have
>> written an R code which calls this fortran subroutine as follows:
>>
>> system("R CMD SHLIB test-multinom.f wrapper.c")
>> dyn.load("~/Package/test/test-multinom.so")
>>
>> n=1
>> prob=c(0.6,0.1,0.3)
>> K=3
>> rN=c(1,0,0)
>> res<- .Fortran("testsarmultinom",
>> as.integer(n),
>> as.double(prob),
>> as.integer(K),
>> as.integer(rN))
>>
>>
>> Unfortunately, I have some trouble with the results. First, this command
>> always returns 0 values. In other words, I always get:
>>
>>> res[[4]]
>> [1] 0 0 0
>>
>>
>> Moreover, if I run this R code a second time, an error message appears:
>> Segmentation fault.
>>
>> Has somebody ever used rmultinom.c and encountered these problems? My code
>> must be wrong but I don't know where. In this case, what is the correct way
>> to call the C function rmultinom.c?
>>
>> Thanks in advance,
>>
>> Sophie.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pbinom with size argument 0 (PR#8560)
On Sun, 5 Feb 2006, Peter Dalgaard wrote: > P Ehlers <[EMAIL PROTECTED]> writes: > >> I prefer a (consistent) NaN. What happens to our notion of a >> Binomial RV as a sequence of Bernoulli RVs if we permit n=0? >> I have never seen (nor contemplated, I confess) the definition >> of a Bernoulli RV as anything other than some dichotomous-outcome >> one-trial random experiment. > > What's the problem ?? > > An n=0 binomial is the sum of an empty set of Bernoulli RV's, and the > sum over an empty set is identically 0. > >> Not n trials, where n might equal zero, >> but _one_ trial. I can't see what would be gained by permitting a >> zero-trial experiment. If we assign probability 1 to each outcome, >> we have a problem with the sum of the probabilities. > > Consistency is what you gain. E.g. > > binom(.,n=n1+n2,p) == binom(.,n=n1,p) * binom(.,n=n2,p) > > where * denotes convolution. This will also hold for n1=0 or n2=0 if > the binomial in that case is defined as a one-point distribution at > zero. Same thing as any(logical(0)) etc., really. Consistency is a Good Thing, and I had already altered the codebase to consistently allow size=0 as a discrete distribution concentrated at 0. There were other inconsistencies, e.g. whether the geometric/negative binomial functions allow prob=0 or prob=1. I have no problem with prob=1 (it is a discrete distribution concentrated on one point) and this was addressed for rnbinom before (PR#1218) but subsequently broken (which is why we like regression tests ...). However prob=0 does not correspond to a proper distribution unless Inf is allowed as a value, and it was not so documented (nor implemented). Indeed we had > dgeom(2, prob=0) [1] 0 > dgeom(Inf, prob=0) [1] 0 > pgeom(Inf, prob=0) [1] 0 and in fact dgeom gave zero for every allowed value. So I cannot accept that as being right (and we even have a d-p-q-r test with prob=0). -- 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-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pbinom with size argument 0 (PR#8560)
On 05-Feb-06 [EMAIL PROTECTED] wrote: > Hello all > > A pragmatic argument for allowing size=3D=3D0 is the situation where > the size is in itself a random variable (that's how I stumbled over > the inconsistency, by the way). > > For example, in textbooks on probability it is stated that: > > If X is Poisson(lambda), and the conditional=20 > distribution of Y given X is Binomial(X,p), then=20 > Y is Poisson(lambda*p). > > (cf eg Pitman's "Probability", p. 400) > > Clearly this statement requires Binomial(0,p) to be a well-defined > distribution. > > Such statements would be quite convoluted if we did not define > Binomial(0,p) as a legal (but degenerate) distribution. The same > applies to codes where the size parameter may attain the value 0. > > Just my 2 cents. > > Cheers, > > Uffe Uffe's pragmatic argument is of course convincing at least in the circumstances he refers to. However, Peter Ehlers' posting has re-stimulated the underlying ambiguity I feel about this issue (intially, that the probability of a "non-event" should be undefined). Thus I can envisage different circumatances in which one or the other view could be appropriate. Uffe observes a Poisson-distributed number of Bernoulli trials and records the number of "successes", with zero if the Poisson distribution says "zero trials". In that case no Bernoulli trial has been carried out, so the issue of what the distribution over its empty set of outcomes should be is irrelevant. However, he can encapsulate this process mathematically by assigning P=1 to the outcome r=0 when n=0, and this may well lead to a more straightforward R program, for instance (which, reading between the lines, may well be what really happened in his case). On the other hand, suppose I (and maybe Peter Ehlers too) am simulating a study in which random numbers (according to some distribution) of subjects become available, in each "sweep" of the study, for questionnaire, and the outcome of interest is the number in the "sweep" answering "Yes" to a question. Part of this simulation is to create a database of responses along with concomitant variables. It is possible (and under some circumstances perhaps more likely) that the number of available subjects in a "sweep" is zero -- these people cannot be contacted, say. Maybe I'm studying a "missing data" situation. In that case it would be natural to enter "r=NA" in the database for those sweeps which produces no responses. This would denote "missing data". And natural also to (initially, before embarking on say an imputation exercise) to attribute "P=NA" to the probability of "Yes" for such a group since we do not have any direct information (though may be able to exploit associations between other variables to obtain indirect information, under certain assumptions). So maybe one could need implementations of pbinom and dbinom which work differently in different circumstances. But what remains important is that, whichever way they work in given circumstances, they should be consistent with each other. Best wishes to all, Ted. E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 06-Feb-06 Time: 10:10:19 -- XFMail -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Troubles with the function rmultinom.c of the R's Random Number Generator
Thank you for the answer. However, I sought in Doc. Writing R
extensions, in particular in the paragraph 5.6 "Calling C from FORTRAN
and vice versa" (page 67) but I did not find anything which could help me to
correct my code. Indeed, rmultinom.c is a particular function
since arrays are passed in arguments. Has somebody ever
written a wrapper for this function?
Thanks in advance,
Sophie.
At 17:06 20/01/06 +, Prof Brian Ripley wrote:
>All arguments to functions called from C by Fortran are pointers
>(or should be: yours are not). The error is within your own code.
>
>You don't want to call rndstart and rndend around every call, only before
>the first and after the last.
>
>This is not the list for advice om mixed Fortran/C programming, though.
>On Fri, 20 Jan 2006, Sophie Ancelet wrote:
>
>>
>> Hi,
>>
>> I'm simulating a Markov chain in Fortran interfaced with R-2.2.1 in order
>> to generate data according to a Markov Random Field called the Potts model.
>>
>> R Version:
>> platform i686-pc-linux-gnu
>> arch i686
>> os linux-gnu
>> system i686, linux-gnu
>> status
>> major2
>> minor2.1
>> year 2005
>> month12
>> day 20
>> svn rev 36812
>>
>>
>>
>>
>> Each loop of my Fortran calls the function rmultinom.c of the R's Random
>> Number Generator through the wrapper:
>>
>> #include
>> #include
>> void F77_SUB(sarmultinom)(int n,
>> double* prob,
>> int K,
>> int* rN){
>> rmultinom(n, prob, K, rN);}
>>
>>
>>
>> My fortran program is:
>>
>> subroutine testsarmultinom(n,prob,K,rN)
>> implicit none
>> integer n,K,rN(K)
>> double precision prob(K)
>>
>> call rndstart()
>> call sarmultinom(n,prob,K,rN)
>> call rndend()
>> end
>>
>>
>> In order to understand better how the function rmultinom.c works, I have
>> written an R code which calls this fortran subroutine as follows:
>>
>> system("R CMD SHLIB test-multinom.f wrapper.c")
>> dyn.load("~/Package/test/test-multinom.so")
>>
>> n=1
>> prob=c(0.6,0.1,0.3)
>> K=3
>> rN=c(1,0,0)
>> res<- .Fortran("testsarmultinom",
>> as.integer(n),
>> as.double(prob),
>> as.integer(K),
>> as.integer(rN))
>>
>>
>> Unfortunately, I have some trouble with the results. First, this command
>> always returns 0 values. In other words, I always get:
>>
>>> res[[4]]
>> [1] 0 0 0
>>
>>
>> Moreover, if I run this R code a second time, an error message appears:
>> Segmentation fault.
>>
>> Has somebody ever used rmultinom.c and encountered these problems? My code
>> must be wrong but I don't know where. In this case, what is the correct way
>> to call the C function rmultinom.c?
>>
>> Thanks in advance,
>>
>> Sophie.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Troubles with the function rmultinom.c of the R's Random Number Generator
Sophie Ancelet wrote:
> Thank you for the answer. However, I sought in Doc. Writing R
> extensions, in particular in the paragraph 5.6 "Calling C from FORTRAN
> and vice versa" (page 67) but I did not find anything which could help me to
> correct my code. Indeed, rmultinom.c is a particular function
> since arrays are passed in arguments. Has somebody ever
> written a wrapper for this function?
You probably haven't managed to digest what Prof Ripley was writing:
"All arguments to functions called from C by Fortran are pointers
(or should be: yours are not)" - here is a more hand-holding kind
of answer, which is exactly the same advice, really - you need to
be doing something like this (note the pointers) instead:
>>>void F77_SUB(sarmultinom)(int *n,
>>> double** prob,
>>> int *K,
>>> int** rN){
>>>rmultinom(n, prob, K, rN);}
I'll be interested to see what breaks - do you mind sending me
both of test-multinom.f wrapper.c direct for me to have a look?
HTL
> At 17:06 20/01/06 +, Prof Brian Ripley wrote:
>
>>All arguments to functions called from C by Fortran are pointers
>>(or should be: yours are not). The error is within your own code.
>>
>>You don't want to call rndstart and rndend around every call, only before
>>the first and after the last.
>>
>>This is not the list for advice om mixed Fortran/C programming, though.
>
>
>
>
>
>>On Fri, 20 Jan 2006, Sophie Ancelet wrote:
>>
>>
>>>Hi,
>>>
>>>I'm simulating a Markov chain in Fortran interfaced with R-2.2.1 in order
>>>to generate data according to a Markov Random Field called the Potts model.
>>>
>>>R Version:
>>>platform i686-pc-linux-gnu
>>>arch i686
>>>os linux-gnu
>>>system i686, linux-gnu
>>>status
>>>major2
>>>minor2.1
>>>year 2005
>>>month12
>>>day 20
>>>svn rev 36812
>>>
>>>
>>>
>>>
>>>Each loop of my Fortran calls the function rmultinom.c of the R's Random
>>>Number Generator through the wrapper:
>>>
>>>#include
>>>#include
>>>void F77_SUB(sarmultinom)(int n,
>>> double* prob,
>>> int K,
>>> int* rN){
>>>rmultinom(n, prob, K, rN);}
>>>
>>>
>>>
>>>My fortran program is:
>>>
>>>subroutine testsarmultinom(n,prob,K,rN)
>>>implicit none
>>>integer n,K,rN(K)
>>>double precision prob(K)
>>>
>>>call rndstart()
>>>call sarmultinom(n,prob,K,rN)
>>>call rndend()
>>>end
>>>
>>>
>>>In order to understand better how the function rmultinom.c works, I have
>>>written an R code which calls this fortran subroutine as follows:
>>>
>>>system("R CMD SHLIB test-multinom.f wrapper.c")
>>>dyn.load("~/Package/test/test-multinom.so")
>>>
>>>n=1
>>>prob=c(0.6,0.1,0.3)
>>>K=3
>>>rN=c(1,0,0)
>>>res<- .Fortran("testsarmultinom",
>>> as.integer(n),
>>> as.double(prob),
>>> as.integer(K),
>>> as.integer(rN))
>>>
>>>
>>>Unfortunately, I have some trouble with the results. First, this command
>>>always returns 0 values. In other words, I always get:
>>>
>>>
res[[4]]
>>>
>>>[1] 0 0 0
>>>
>>>
>>>Moreover, if I run this R code a second time, an error message appears:
>>>Segmentation fault.
>>>
>>>Has somebody ever used rmultinom.c and encountered these problems? My code
>>>must be wrong but I don't know where. In this case, what is the correct way
>>>to call the C function rmultinom.c?
>>>
>>>Thanks in advance,
>>>
>>>Sophie.
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] extending "list" in S4: loss of element names
using R 2.3 of 1/31/06
> new("list")
list()
> new("list", list(a=1))
$a
[1] 1
> setClass("listlike", contains="list")
[1] "listlike"
> new("listlike", list(a=1))
An object of class "listlike"
[[1]]
[1] 1
Why does the list in the second construction lose
the element name? A workaround is to endow the
listlike class with a names slot, but it would
be nice for the names to be propagated from the
data to the object.
Loss of names in a numeric construction does
not require extension:
> new("numeric", c(a=1))
[1] 1
But coercion can allow names to persist.
> as(c(a=1), "numeric")
a
1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The install.R and R_PROFILE.R files
On 5 Feb 2006, [EMAIL PROTECTED] wrote: > I had a bumpy ride with this one. > > Ruuid/src/Makefile.win refers to src/include, which is not in a > binary distribution so cannot be installed from an installed version > of R 2.2.1. (That's a bug report.) Thanks for the report, this has been fixed in the devel version of Ruuid. > graph throws an S4 signature error in R-devel. Also fixed in devel, thanks. > After fixing those, it works with LazyLoad on Windows but not in > Unix where there is an error in the INSTALL script which I have now > fixed. Excellent, thanks. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] saving PDF with multiple diagrams results in crash (PR#8569)
Full_Name: Alexander Holzbach
Version: 2.2.0
OS: Mac OS X 10.3.9
Submission from: (NULL) (129.13.186.1)
when i build an area with multiple diagrams (par(mfrow=c(1,3)) ) and try to save
this to a pdf via "save as.." or by setting pdf("filename") r crashes
reproducable.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] saving PDF with multiple diagrams results in crash (PR#8569)
On Feb 6, 2006, at 1:11 PM, [EMAIL PROTECTED]
wrote:
> Full_Name: Alexander Holzbach
> Version: 2.2.0
> OS: Mac OS X 10.3.9
> Submission from: (NULL) (129.13.186.1)
>
>
> when i build an area with multiple diagrams (par(mfrow=c(1,3)) )
> and try to save
> this to a pdf via "save as.." or by setting pdf("filename") r crashes
> reproducable.
Firstly, please update at least to R 2.2.1 before reporting bugs
(preferably to R-patched). Secondly, can you, please, send us exactly
the code you use (and/or exactly the steps you take)? I'm not able to
reproduce it in R 2.2.1 from your brief description.
Thanks,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] match gets confused by S4 objects
If one accidentally calls match(x, obj), where obj is any S4 instance,
the result is NA.
I was expecting an error because, in general, if a match method is not
defined for a particular S4 class, I don't know what a reasonable
default could be. Specifically, here's what I see
setClass("FOO", representation(a="numeric"))
foo <- new("FOO", a=10)
match("a", foo)
[1] NA
And my thinking is that this should be an error, along the lines of
match("a", function(x) x)
Unless, of course, a specific method for match, table="FOO" has been
defined.
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] match gets confused by S4 objects
An S4 object is just a list with attributes, so a vector type. match()
works with all vector types including lists, as you found out (or could
have read).
If in the future those proposing it do re-implement an S4 object as an new
SEXP then this will change, but for now the cost of detecting objects
which might have an S4 class defined somewhere is just too high (and would
fall on those who do not use S4 classes).
On Mon, 6 Feb 2006, Seth Falcon wrote:
> If one accidentally calls match(x, obj), where obj is any S4 instance,
> the result is NA.
>
> I was expecting an error because, in general, if a match method is not
> defined for a particular S4 class, I don't know what a reasonable
> default could be. Specifically, here's what I see
>
> setClass("FOO", representation(a="numeric"))
> foo <- new("FOO", a=10)
> match("a", foo)
> [1] NA
>
> And my thinking is that this should be an error, along the lines of
> match("a", function(x) x)
>
> Unless, of course, a specific method for match, table="FOO" has been
> defined.
--
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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] invalid graphics state using dev.print
Paul, On Feb 6, 2006, at 5:24 PM, Paul Roebuck wrote: > Tried on R-Sig-Mac with no responses, but I need some kind of answer. > [...] > Does the following work on your system? Interesting, no, it doesn't either. For png and pdf I use Quartz + quartz.save (it produces much nicer results) so I didn't really notice, but you're right. First I thought those graphics state issues are specific to the Quartz device, but you have proven that it's not. It's in fact not even Mac-specific - I have just reproduced it on a Linux box - that's why I'm moving this to R-devel. Here is a small reproducible example: x11() plot(rnorm(10)) dev.print(png) I'll try to have a look at it later today, but I can't promise anything. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] R compile on AIX 5.2
Professor Ripley, Following your advice, I am now using an updated version of gcc (4.0.2 to be exact) as well as a true fortran compiler (XL Fortran Compiler v10.1.0.0 from IBM). I am still experiencing difficulty in running "make" after a successful "configure". Any additional insight you could provide would be greatly appreciated. Output of make is as follows: Running Make R-2.2.1: /home/mbeason/work/R-2.2.1/src/main /usr/local/bin/gcc -Wl,-brtl -Wl,-bdynamic -Wl,-bE:../../etc/R.exp -Wl,-bM:SRE -L/usr/local/lib -o R.bin Rmain.o CConverters.o CommandLineArgs.o Rdynload.o Renviron.o RNG.o apply.o arithmetic.o apse.o array.o attrib.o base.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cov.o cum.o dcf.o datetime.o debug.o deparse.o deriv.o dotcode.o dounzip.o dstruct.o duplicate.o engine.o envir.o errors.o eval.o format.o fourier.o gevents.o gram.o gram-ex.o graphics.o identical.o internet.o iosupport.o lapack.o list.o logic.o main.o mapply.o match.o memory.o model.o names.o objects.o optim.o optimize.o options.o par.o paste.o pcre.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o regex.o registration.o relop.o saveload.o scan.o seq.o serialize.o size.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o version.o vfonts.o xxxpr.o ../unix/libunix.a ../appl/libappl.a ../nmath/libnmath.a -lg -lxlf90 -L/usr/lpp/xlf/lib -lxlopt -lxlf -lxlomp_ser -lm /lib/crt0.o ../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a -lintl -lreadline -ldl -lm -lc -liconv ld: 0711-317 ERROR: Undefined symbol: ch2inv ld: 0711-317 ERROR: Undefined symbol: chol ld: 0711-317 ERROR: Undefined symbol: cg ld: 0711-317 ERROR: Undefined symbol: ch ld: 0711-317 ERROR: Undefined symbol: rg ld: 0711-317 ERROR: Undefined symbol: rs ld: 0711-317 ERROR: Undefined symbol: dchdc ld: 0711-317 ERROR: Undefined symbol: dpbfa ld: 0711-317 ERROR: Undefined symbol: dpbsl ld: 0711-317 ERROR: Undefined symbol: dpoco ld: 0711-317 ERROR: Undefined symbol: dpodi ld: 0711-317 ERROR: Undefined symbol: dpofa ld: 0711-317 ERROR: Undefined symbol: dposl ld: 0711-317 ERROR: Undefined symbol: dqrcf ld: 0711-317 ERROR: Undefined symbol: dqrdc ld: 0711-317 ERROR: Undefined symbol: dqrdc2 ld: 0711-317 ERROR: Undefined symbol: dqrls ld: 0711-317 ERROR: Undefined symbol: dqrsl ld: 0711-317 ERROR: Undefined symbol: dqrqty ld: 0711-317 ERROR: Undefined symbol: dqrqy ld: 0711-317 ERROR: Undefined symbol: dqrrsd ld: 0711-317 ERROR: Undefined symbol: dqrxb ld: 0711-317 ERROR: Undefined symbol: dsvdc ld: 0711-317 ERROR: Undefined symbol: dtrsl ld: 0711-317 ERROR: Undefined symbol: dtrco ld: 0711-317 ERROR: Undefined symbol: lminfl ld: 0711-317 ERROR: Undefined symbol: .zgemm ld: 0711-317 ERROR: Undefined symbol: .dsyrk ld: 0711-317 ERROR: Undefined symbol: .dtrsm ld: 0711-317 ERROR: Undefined symbol: .dcopy ld: 0711-317 ERROR: Undefined symbol: .dtrsl ld: 0711-317 ERROR: Undefined symbol: .ddot ld: 0711-317 ERROR: Undefined symbol: .dnrm2 ld: 0711-317 ERROR: Undefined symbol: .dscal ld: 0711-317 ERROR: Undefined symbol: .daxpy ld: 0711-317 ERROR: Undefined symbol: .dpofa ld: 0711-317 ERROR: Undefined symbol: .intpr0_ ld: 0711-317 ERROR: Undefined symbol: .i_len ld: 0711-317 ERROR: Undefined symbol: .realp0_ ld: 0711-317 ERROR: Undefined symbol: .dblep0_ ld: 0711-317 ERROR: Undefined symbol: .rexitc_ ld: 0711-317 ERROR: Undefined symbol: .rwarnc_ ld: 0711-317 ERROR: Undefined symbol: .xerbla_ ld: 0711-317 ERROR: Undefined symbol: .d_sign ld: 0711-317 ERROR: Undefined symbol: .d_cnjg ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 1. Stop. Running make with R-devel_2006-02-05: /home/mbeason/work/R-devel/src/appl f95 -g -c ch2inv.f -o ch2inv.o "ch2inv.f", line 1.2: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 2.1: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 3.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 4.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 5.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 6.1: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 7.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 7.39: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 8.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 9.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 9.41: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 10.8: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 11.1: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 12.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 13.4: 1515-019 (S) Syntax is incorrect. "ch2inv.f", line 13.38: 15
