Re: [Rd] R 2.1.1 slated for June 20
Marc Schwartz <[EMAIL PROTECTED]> writes: > On Wed, 2005-06-15 at 00:01 +0200, Peter Dalgaard wrote: > > Marc Schwartz <[EMAIL PROTECTED]> writes: > > > > > Prof. Ripley, > > > > > > If my read of the config.log is correct, it would appear that g77 was > > > used and not gfortran (which is installed): > > > > > > ... > > > C compiler:gcc -g -O2 > > > C++ compiler: g++ -g -O2 > > > Fortran compiler: g77 -g -O2 > > > ... > > > > Mine was > > > > > > C compiler:gcc -g -O2 > > C++ compiler: g++ -g -O2 > > Fortran compiler: f95 -g -O2 > > > > (and f95 is a link to gfortran) > > > Interesting. Did you do anything different on the ./configure line? > > $ ls -l /usr/bin/f95 > lrwxrwxrwx 1 root root 8 Jun 13 21:18 /usr/bin/f95 -> gfortran > > I just tried it again (having installed some FC updates) and I still get > g77... I just didn't install g77... (it's listed under "back-compatibility tools" or something like that). -- 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
[Rd] source() chdir does not work (PR#7940)
Full_Name: Alex Galakhov
Version: 2.1.0
OS: Linux (Debian)
Submission from: (NULL) (195.19.131.68)
After software upgrade source() does not work properly anymore. It completely
ignores the chdir= parameter. This is because is.character(file) is always false
after the assignment file<-file(file).
The fix is (written by hand in diff-like syntax, hopefully, you'll understand
it):
source<- function (blablabla) {
+filename <- file
...blablabla
-if (chdir && is.character (file) && ... dirname(file) ...) {
+if (chdir && is.character (filename) && ... dirname(filename) ...) {
+close(file) # since we can have only one on.exit(), we close file here
...blablabla
on.exit(setwd(owd));
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] source() chdir does not work (PR#7940)
This is already fixed:
o source(file, chdir = TRUE) was not checking that 'file' was a
filepath (rather than a URL). For 2.1.0 only, it did not work
even if 'file' was a filepath.
>From the R FAQ:
Before you actually submit a bug report, you should check whether the
bug has already been reported and/or fixed. First, try the "Search
Existing Reports" facility in the Bug Tracking page at
`http://bugs.R-project.org/'. Second, consult
`https://svn.R-project.org/R/trunk/NEWS', which records changes that will
appear in the _next_ release of R, including some bug fixes that do not
appear in Bug Tracking. (Windows users should additionally consult
`https://svn.R-project.org/R/trunk/src/gnuwin32/CHANGES'.) Third, if
possible try the current r-patched or r-devel version of R. If a bug has
already been reported or fixed,
please do not submit further bug reports on it.
^^
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Alex Galakhov
> Version: 2.1.0
> OS: Linux (Debian)
> Submission from: (NULL) (195.19.131.68)
>
>
> After software upgrade source() does not work properly anymore. It completely
> ignores the chdir= parameter. This is because is.character(file) is always
> false
> after the assignment file<-file(file).
>
> The fix is (written by hand in diff-like syntax, hopefully, you'll understand
> it):
>
> source<- function (blablabla) {
> +filename <- file
> ...blablabla
> -if (chdir && is.character (file) && ... dirname(file) ...) {
> +if (chdir && is.character (filename) && ... dirname(filename) ...) {
> +close(file) # since we can have only one on.exit(), we close file here
> ...blablabla
> on.exit(setwd(owd));
> }
--
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
[Rd] Calling C function from Fortran
Hi all,
the example in the R doc
and the hints from Shusong Jin , Ingmar Visser and Reid Huntsinger
(thanks all three) refer to the case where the function does not have
arguments.
I'm still looking for a proper sequence of commands
to call C functions with arguemnts from R.
Imagine I want to evaluate the gamma function.
I want to use the C function called by R.
(I guess it is the one corresponding to the source code
I found in the directory R-2.1.0/src/nmath/gamma.c
of the source distribution).
The following programs do not work (it returns fancy values)
#include
#include
void F77_SUB(mygammac)(double x, double y) { y = gammafn(x); }
subroutine mygammaf(x,y)
double precision x,y
call mygammac(x,y)
end
called in R through
x <- 3
y <- -999
res <- .Fortran("mygammaf",
as.double(x),
as.double(y))
While changing the C code into
#include
#include
void F77_SUB(mygammac)(double *x, double *y) { *y = gammafn(*x); }
seems to work fine.
But R-2.1.0/src/nmath/gamma.c does not need a pointer ?
What is wrong whit he first set of lines ?
What is the correct way to call the C function in R-2.1.0/src/nmath/gamma.c ?
Thanks in advance
Gilles
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.table confused by rownames/colnames (PR#7941)
Full_Name: Axel Rasche
Version: 2.1.0
OS: Win2000
Submission from: (NULL) (141.14.21.81)
Hi,
write.table does not accept the second statement with
.
I do not see why this should not be possible.
test = matrix(1:4, 2, 2, dimnames = list( c("a","b"), c("c","d") ))
write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
col.names = NA, row.names = FALSE)
write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
col.names = NA)
write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
col.names = TRUE, row.names = FALSE)
write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
col.names = FALSE, row.names = FALSE)
Thanks,
Axel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.1.1 slated for June 20
On Tue, 2005-06-14 at 23:08 -0500, Marc Schwartz wrote: > In reviewing the Add/Remove Application GUI, gfortran is listed as an > "Extra Package" in the Development Tools Group. > > g77 is not listed in that Group or in the Legacy Development Group, so > it would appear that it is a "silent" part of the "Everything" > installation procedure. > > Removing the offending RPM: > > rpm -e compat-gcc-32-g77-3.2.3-47.fc4 Correction: I noted that under the Legacy Development Group there is just a general category for "compat-gcc-32", which upon further review appears to include the above g77 RPM as well as: compat-gcc-32-c++-3.2.3-47.fc4 compat-gcc-32-3.2.3-47.fc4 My oversight. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] italic (PR#7932)
[EMAIL PROTECTED] wrote: > Full_Name: G. Grothendieck > Version: R version 2.1.0, 2005-05-14 > OS: Windows XP > Submission from: (NULL) (216.59.254.207) > > > This code: > > >>plot(1:10) >>text(5,5,lab=expression(italic(22*"33"))) For mathematical non-character-string annotation a math font is used that does not support italic/bold/bolditalic/plain. It seems to be worth adding this information to ?plotmath, such as: "(only for characters, but not for math font)". Uwe Ligges > > has the effect of italicizing 33 (which is a character string) but not 22 > (which is not). I would have thought that both, not just 33, would be > italicized. > > I had previously posted about this last week: > > https://www.stat.math.ethz.ch/pipermail/r-devel/2005-June/033526.html > > however, no one responded. > > __ > 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
Re: [Rd] R 2.1.1 slated for June 20
On Wed, 2005-06-15 at 07:51 +0100, Prof Brian Ripley wrote: > Our preference is F77 compilers over F9x ones, as the lists Simon showed > reflects - we decided to prefer F95 to F90 in future, though. > > My experience is that g77 from gcc-3.4.x is preferable to gfortran. > As I said earlier, once gcc-4.0.1 is released (and so R builds with a > released version of gcc-4.x.y - 4.0.0 needs worarounds) I will take a > another look. So far, using gcc-3.4.4 is both faster and more accurate > that gcc-4.0.0. There are a few instances in which loess gives rather > different results with gfortran, but they are only visible by diffing > postscript files. > > I will look into converting blas.f to F77 (but not for this release). I have re-installed g77 and re-compiled from scratch with it. Unless the FC folks have backported gcc-3.4 updates to gcc-3.2, that update appears to not be imminent, as the FC devel tree (rawhide) is still at gcc-3.2. Best regards, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] write.table confused by rownames/colnames (PR#7941)
[EMAIL PROTECTED] wrote:
> Full_Name: Axel Rasche
> Version: 2.1.0
> OS: Win2000
> Submission from: (NULL) (141.14.21.81)
>
>
> Hi,
>
> write.table does not accept the second statement with
> .
> I do not see why this should not be possible.
>
> test = matrix(1:4, 2, 2, dimnames = list( c("a","b"), c("c","d") ))
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = NA, row.names = FALSE)
From my point of view one should not expect NA to work, but the help
page says a "logical" is allowed and gives a correpsonding "NA" example,
hence it is a bug, either in the help page or in the code.
I'd vote for changing the help and depreciating NA for
col.names/row.names, because I do not know what NA is expected to do and
therefore I could not provide any bugfix for the code ...
Uwe Ligges
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = NA)
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = TRUE, row.names = FALSE)
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = FALSE, row.names = FALSE)
>
> Thanks,
> Axel
>
> __
> 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
Re: [Rd] write.table confused by rownames/colnames (PR#7941)
It seems that you are the one who is confused: the help file says
By default there is no column name for a column of row names. If
'col.names = NA' a blank column name is added.
If there are no row names, there is no point in adding a blank column name
for them. So what did *you* think it would do?
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> Full_Name: Axel Rasche
> Version: 2.1.0
> OS: Win2000
> Submission from: (NULL) (141.14.21.81)
>
>
> write.table does not accept the second statement with
>.
> I do not see why this should not be possible.
>
> test = matrix(1:4, 2, 2, dimnames = list( c("a","b"), c("c","d") ))
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = NA, row.names = FALSE)
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = NA)
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = TRUE, row.names = FALSE)
> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
> col.names = FALSE, row.names = FALSE)
--
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] write.table confused by rownames/colnames (PR#7941)
Hello,
Alright, I did not look at it that way I admit. I built a matrix with
multiple row names (as a data.frame). Confusion started when exporting
this as a spread-sheet.
Now it all works fine.
Thanks and sorry for the false alarm,
Axel
Prof Brian Ripley wrote:
> It seems that you are the one who is confused: the help file says
>
> By default there is no column name for a column of row names. If
> 'col.names = NA' a blank column name is added.
>
> If there are no row names, there is no point in adding a blank column
> name for them. So what did *you* think it would do?
>
> On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
>
>> Full_Name: Axel Rasche
>> Version: 2.1.0
>> OS: Win2000
>> Submission from: (NULL) (141.14.21.81)
>>
>>
>> write.table does not accept the second statement with
>>.
>> I do not see why this should not be possible.
>>
>> test = matrix(1:4, 2, 2, dimnames = list( c("a","b"), c("c","d") ))
>> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
>> col.names = NA, row.names = FALSE)
>> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
>> col.names = NA)
>> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
>> col.names = TRUE, row.names = FALSE)
>> write.table(test, file = "test.txt", sep = "\t", quote = FALSE,
>> col.names = FALSE, row.names = FALSE)
>
>
>
--
***
Dipl. Math. ETH Axel Rasche
Max-Planck-Institute for Molecular Genetics
Department Lehrach (Vertebrate Genomics)
Ihnestrasse 63-73
D-14195 Berlin-Dahlem
GERMANY
Tel. ++49-30-8413-1289
Fax ++49-30-8413-1380
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] extra spaces before imag part when printing complex numbers (PR#7942)
Hello, When printing sequence of complex numbers, extra spaces are sometimes printed between real and imaginary part of each number. For example: ## R Version 2.1.1 beta (2005-06-13) [Debian unstable, i386] ## and R Version 2.1.0 [Debian unstable, i386] > print(c(1+1i, 10+1i, 100+1i)) # Ok [1] 1+1i 10+1i 100+1i > print(c(1+1i, 1-10i, 1+100i)) [1] 1+ 1i 1- 10i 1+100i ^^ ^ (extra spaces) The numbers of inserted spaces depends on the imaginary part which has the largest number of figures: > print(c(1+1i, 1+12i)) [1] 1+ 1i 1+12i ^ > print(c(1+1i, 1+123i)) [1] 1+ 1i 1+123i ^^ > print(c(1+1i, 1+1234i)) [1] 1+ 1i 1+1234i ^^^ Regards, -- Cyril __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7942) extra spaces before imag part when printing
This is intentional: it aligns the numbers. E.g. > options(width=12) > print(c(1+1i, 1-10i, 1+100i)) [1] 1+ 1i [2] 1- 10i [3] 1+100i Neat, eh? What made you think this was a bug? On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote: > Hello, > > When printing sequence of complex numbers, extra spaces > are sometimes printed between real and imaginary part of > each number. > > For example: > ## R Version 2.1.1 beta (2005-06-13) [Debian unstable, i386] > ## and R Version 2.1.0 [Debian unstable, i386] > >> print(c(1+1i, 10+1i, 100+1i)) # Ok > [1] 1+1i 10+1i 100+1i > >> print(c(1+1i, 1-10i, 1+100i)) > [1] 1+ 1i 1- 10i 1+100i > ^^ ^ > (extra spaces) > > > > The numbers of inserted spaces depends on the imaginary > part which has the largest number of figures: > >> print(c(1+1i, 1+12i)) > [1] 1+ 1i 1+12i > ^ > >> print(c(1+1i, 1+123i)) > [1] 1+ 1i 1+123i > ^^ > >> print(c(1+1i, 1+1234i)) > [1] 1+ 1i 1+1234i > ^^^ -- 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] italic (PR#7932)
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
>> Full_Name: G. Grothendieck
>> Version: R version 2.1.0, 2005-05-14
>> OS: Windows XP
>> Submission from: (NULL) (216.59.254.207)
>>
>>
>> This code:
>>
>>
>>> plot(1:10)
>>> text(5,5,lab=expression(italic(22*"33")))
>
> For mathematical non-character-string annotation a math font is used
> that does not support italic/bold/bolditalic/plain.
> It seems to be worth adding this information to ?plotmath, such as:
> "(only for characters, but not for math font)".
I don't think that is true: plotmath uses the same 5 fontfaces as any
other form of graph annotation. The reason was staring Grothendieck
in the face: the code is
static BBOX RenderNumber(SEXP expr, int draw, mathContext *mc,
R_GE_gcontext *gc, GEDevDesc *dd)
{
BBOX bbox;
FontType prevfont = SetFont(PlainFont, gc);
bbox = RenderStr(CHAR(asChar(expr)), draw, mc, gc, dd);
SetFont(prevfont, gc);
return bbox;
}
so it is by design. Numeric constants are always in PlainFont.
>> has the effect of italicizing 33 (which is a character string) but not 22
>> (which is not). I would have thought that both, not just 33, would be
>> italicized.
(We do ask people to actually do the thinking before posting a bug
report.)
--
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] italic (PR#7932)
On 6/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
>
> > [EMAIL PROTECTED] wrote:
> >
> >> Full_Name: G. Grothendieck
> >> Version: R version 2.1.0, 2005-05-14
> >> OS: Windows XP
> >> Submission from: (NULL) (216.59.254.207)
> >>
> >>
> >> This code:
> >>
> >>
> >>> plot(1:10)
> >>> text(5,5,lab=expression(italic(22*"33")))
> >
> > For mathematical non-character-string annotation a math font is used
> > that does not support italic/bold/bolditalic/plain.
> > It seems to be worth adding this information to ?plotmath, such as:
> > "(only for characters, but not for math font)".
>
> I don't think that is true: plotmath uses the same 5 fontfaces as any
> other form of graph annotation. The reason was staring Grothendieck
> in the face: the code is
>
> static BBOX RenderNumber(SEXP expr, int draw, mathContext *mc,
> R_GE_gcontext *gc, GEDevDesc *dd)
> {
> BBOX bbox;
> FontType prevfont = SetFont(PlainFont, gc);
> bbox = RenderStr(CHAR(asChar(expr)), draw, mc, gc, dd);
> SetFont(prevfont, gc);
> return bbox;
> }
>
> so it is by design. Numeric constants are always in PlainFont.
What is the rationale this?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling C from Fortran
Thanks for your reply.
Am I write if I say that the wrapper shoul be
double F77_SUB(mygammafn)(double *x) { return gammafn(*x); }
instead of
double F77_SUB(mygammafn)(double *x) { return gammafn(x); }
the first does not compile.
wrapper2.c: In function `mygammafn_':
wrapper2.c:6: error: incompatible type for argument 1 of `Rf_gammafn'
The second compiles and works fine.
But still, I find it very strange as the C function gammafn actually called
( as I can see from /R-2.1.0/src/nmath/gamma.c)
is not defined as
double gammafn(double *x)
but as
double gammafn(double x)
Am I missing something ?
Gilles
Le Mercredi 15 Juin 2005 17:06, vous avez écrit :
> I actually deleted a part of my reply, dealing with exactly that. Sorry!
> You need to declare the C wrapper to take a pointer to a double ("double
> *") rather than a double. C passes by value whereas Fortran passes by
> reference; in C you get this effect by passing a pointer to the value
> (which is also a value). So you want
>
> double F77_SUB(mygammafn)(double *x) { return gammafn(x); }
>
> That should work; if not let me know and I'll look more carefully at
> Fortran <-> C conventions.
>
> Reid Huntsinger
>
> -Original Message-
> From: Gilles GUILLOT [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 15, 2005 3:50 AM
> To: Huntsinger, Reid
> Subject: Re: [Rd] Calling C from Fortran
>
>
> Thanks Reid!
> And now if I want to call a C function with arguments,
> e.g. to compute the gamma function at x,
> my C wrapper is:
>
> #include
> #include
> void F77_SUB(rndstart)(void) { GetRNGstate(); }
> void F77_SUB(rndend)(void) { PutRNGstate(); }
> double F77_SUB(normrnd)(void) { return norm_rand(); }
> double F77_SUB(mygammafn)(double x) { return gammafn(x); }
>
> And my Fortran is:
> subroutine testit()
> implicit none
> double precision normrnd, x, y, mygammafn
> call rndstart()
> x = dabs(normrnd())
> write(*,*) 'x=',x
> call rndend()
>
> y = mygammafn(x)
> write(*,*) 'y=',y
> end
>
> And it does not work, all calls of testit return the same y value.
> What is incorrect in my files ?
>
>
> Gilles
>
>
>
>
>
> ---
>--- Notice: This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New
> Jersey, USA 08889), and/or its affiliates (which may be known outside the
> United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as
> Banyu) that may be confidential, proprietary copyrighted and/or legally
> privileged. It is intended solely for the use of the individual or entity
> named on this message. If you are not the intended recipient, and have
> received this message in error, please notify us immediately by reply
> e-mail and then delete it from your system.
> ---
>---
--
_
Gilles GUILLOT
INRA -Département Mathématiques et Informatique Appliquées
Unité Mixte de Recherche INRA - INAPG - ENGREF
Institut National Agronomique de Paris-Grignon
16, rue Claude Bernard
75231 Paris cedex 5 France
phone 33 1 44 08 18 42
fax 33 1 44 08 16 66
http://www.inapg.fr/ens_rech/mathinfo/personnel/guillot/welcome.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7942) extra spaces before imag part when printing complex numbers
Prof Brian Ripley wrote: > This is intentional: it aligns the numbers. E.g. > > >options(width=12) > >print(c(1+1i, 1-10i, 1+100i)) > [1] 1+ 1i > [2] 1- 10i > [3] 1+100i > > Neat, eh? > > What made you think this was a bug? Ah ok, I've misunderstood this feature probably perhaps because, at first sight, I found the display looks "strange" when some of the numbers have large imaginary parts as it tends to make the delimitation between columns of numbers less visible. E.g., > options(width=80) > print(rep(c(1+1i, 1-1i, 1+1000i), 8)) And if there's less than a line of numbers I find it's more natural to write : > print(c(1+1i, 1-1i, 1+1000i)) [1] 1+1i 1-1i 1+1000i instead of what is actually printed : [1] 1+ 1i 1- 1i 1+1000i Anyway, sorry this "bug" report. > On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote: > > >Hello, > > > >When printing sequence of complex numbers, extra spaces > >are sometimes printed between real and imaginary part of > >each number. > > > >For example: > >## R Version 2.1.1 beta (2005-06-13) [Debian unstable, i386] > >## and R Version 2.1.0 [Debian unstable, i386] > > > >>print(c(1+1i, 10+1i, 100+1i)) # Ok > >[1] 1+1i 10+1i 100+1i > > > >>print(c(1+1i, 1-10i, 1+100i)) > >[1] 1+ 1i 1- 10i 1+100i > > ^^ ^ > > (extra spaces) -- Cyril __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] documentation enhancement: Note in ?seek for Windows (PR#7943)
[I started a new bug report for this issue because it was not the
primary issue in the original discussion, which was PR#7899]
[EMAIL PROTECTED] wrote:
> Tony Plate wrote:
> [snip]
>>[EMAIL PROTECTED] wrote:
>>[snip]
>>>Note that ?seek currently tells us "The value returned by
>>>seek(where=NA) appears to be unreliable on Windows systems, at least
>>>for text files."
>>>It would be nice if this comment could be removed, of course
>>
>>
>>May the explanation could be given that this happens with text files
>>because Windows inserts extra characters at end-of-lines when reading
>>"text" mode files (but with binary files, things should be fine.) This
>>particular issue is documented in Microsoft Windows documentation (e.g.,
>>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
>>by searching on Google using the terms "fseek windows documentation").
>>Are there any known issues using seek with binary files under Windows?
>>If there are not, then the caveat could be made specific to text files
>>and all vagueness removed.
>
>
> Hmm, all I find (including your link) is Windows CE related ...
>
> Uwe Ligges
For the record, the documentation I pointed to is for Windows 2000 etc,
and is not just related to Windows CE (Uwe retracted that claim in a
private email).
So, the suggestion to refine the note in ?seek stands. Perhaps
src/library/base/man/seek.Rd could be changed as follows:
OLD:
#ifdef windows
The value returned by \code{seek(where=NA)} appears to be unreliable
on Windows systems, at least for text files. Clipboard connections
can seek too.
#endif
NEW:
#ifdef windows
The value returned by \code{seek()} is unreliable
on Windows systems for text files. This is because the Windows
file-I/O functions can insert extra characters at end-of-lines
when working with text mode files. Binary mode files should not
be affected by this issue. Clipboard connections can seek too.
#endif
Of course, if someone knows that the return value of seek() is
unreliable on Windows for binary files, this documentation change is
innappropriate (and then the documentation should probably be changed
from "appears to be unreliable, at least for text files" to "is
unreliable, for both binary and text files".
-- Tony Plate
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7943) documentation enhancement: Note in ?seek for
I think the proposed change is appropriate only if the return value is
*known* to be reliable for binary files.
I for one do not trust the writers of an OS whom have made such a serious
error in one mode (and many other errors elsewhere) not to have made one
in closely related code. Since it is not Open Source, we cannot find out.
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
> [I started a new bug report for this issue because it was not the
> primary issue in the original discussion, which was PR#7899]
>
> [EMAIL PROTECTED] wrote:
> > Tony Plate wrote:
> > [snip]
> >>[EMAIL PROTECTED] wrote:
> >>[snip]
> >>>Note that ?seek currently tells us "The value returned by
> >>>seek(where=NA) appears to be unreliable on Windows systems, at least
> >>>for text files."
> >>>It would be nice if this comment could be removed, of course
> >>
> >>
> >>May the explanation could be given that this happens with text files
> >>because Windows inserts extra characters at end-of-lines when reading
> >>"text" mode files (but with binary files, things should be fine.) This
> >>particular issue is documented in Microsoft Windows documentation (e.g.,
> >>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
> >>by searching on Google using the terms "fseek windows documentation").
> >>Are there any known issues using seek with binary files under Windows?
> >>If there are not, then the caveat could be made specific to text files
> >>and all vagueness removed.
> >
> >
> > Hmm, all I find (including your link) is Windows CE related ...
> >
> > Uwe Ligges
>
> For the record, the documentation I pointed to is for Windows 2000 etc,
> and is not just related to Windows CE (Uwe retracted that claim in a
> private email).
>
> So, the suggestion to refine the note in ?seek stands. Perhaps
> src/library/base/man/seek.Rd could be changed as follows:
>
> OLD:
>
> #ifdef windows
> The value returned by \code{seek(where=NA)} appears to be unreliable
> on Windows systems, at least for text files. Clipboard connections
> can seek too.
> #endif
>
> NEW:
>
> #ifdef windows
> The value returned by \code{seek()} is unreliable
> on Windows systems for text files. This is because the Windows
> file-I/O functions can insert extra characters at end-of-lines
> when working with text mode files. Binary mode files should not
> be affected by this issue. Clipboard connections can seek too.
> #endif
>
> Of course, if someone knows that the return value of seek() is
> unreliable on Windows for binary files, this documentation change is
> innappropriate (and then the documentation should probably be changed
> from "appears to be unreliable, at least for text files" to "is
> unreliable, for both binary and text files".
>
> -- Tony Plate
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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] (PR#7943) documentation enhancement: Note in ?seek for
Actually, there is a known issue: it is often wrong for binary files
opened in append mode, and we have caught by that too. So those writers
did make the sort of error I did not trust them not to make.
On Wed, 15 Jun 2005, Prof Brian Ripley wrote:
> I think the proposed change is appropriate only if the return value is
> *known* to be reliable for binary files.
>
> I for one do not trust the writers of an OS whom have made such a serious
> error in one mode (and many other errors elsewhere) not to have made one in
> closely related code. Since it is not Open Source, we cannot find out.
>
> On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
>
>> [I started a new bug report for this issue because it was not the
>> primary issue in the original discussion, which was PR#7899]
>>
>> [EMAIL PROTECTED] wrote:
>> > Tony Plate wrote:
>> > [snip]
>> >>[EMAIL PROTECTED] wrote:
>> >>[snip]
>> >>>Note that ?seek currently tells us "The value returned by
>> >>>seek(where=NA) appears to be unreliable on Windows systems, at least
>> >>>for text files."
>> >>>It would be nice if this comment could be removed, of course
>> >>
>> >>
>> >>May the explanation could be given that this happens with text files
>> >>because Windows inserts extra characters at end-of-lines when reading
>> >>"text" mode files (but with binary files, things should be fine.) This
>> >>particular issue is documented in Microsoft Windows documentation (e.g.,
>> >>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
>> >>by searching on Google using the terms "fseek windows documentation").
>> >>Are there any known issues using seek with binary files under Windows?
>> >>If there are not, then the caveat could be made specific to text files
>> >>and all vagueness removed.
>> >
>> >
>> > Hmm, all I find (including your link) is Windows CE related ...
>> >
>> > Uwe Ligges
>>
>> For the record, the documentation I pointed to is for Windows 2000 etc,
>> and is not just related to Windows CE (Uwe retracted that claim in a
>> private email).
>>
>> So, the suggestion to refine the note in ?seek stands. Perhaps
>> src/library/base/man/seek.Rd could be changed as follows:
>>
>> OLD:
>>
>> #ifdef windows
>> The value returned by \code{seek(where=NA)} appears to be unreliable
>> on Windows systems, at least for text files. Clipboard connections
>> can seek too.
>> #endif
>>
>> NEW:
>>
>> #ifdef windows
>> The value returned by \code{seek()} is unreliable
>> on Windows systems for text files. This is because the Windows
>> file-I/O functions can insert extra characters at end-of-lines
>> when working with text mode files. Binary mode files should not
>> be affected by this issue. Clipboard connections can seek too.
>> #endif
>>
>> Of course, if someone knows that the return value of seek() is
>> unreliable on Windows for binary files, this documentation change is
>> innappropriate (and then the documentation should probably be changed
>> from "appears to be unreliable, at least for text files" to "is
>> unreliable, for both binary and text files".
>>
>> -- Tony Plate
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> --
> 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
>
--
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] Calling C from Fortran
(Forgot to post.) Yes, that was a typo, and the reason is the same; the C
function expects a value rather than its address. That's why you can't use
it directly from Fortran (aside from naming issues) but it's fine in C.
Reid Huntsinger
-Original Message-
From: Gilles GUILLOT [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 15, 2005 11:50 AM
To: [EMAIL PROTECTED]
Cc: Huntsinger, Reid
Subject: Re: [Rd] Calling C from Fortran
Thanks for your reply.
Am I write if I say that the wrapper shoul be
double F77_SUB(mygammafn)(double *x) { return gammafn(*x); }
instead of
double F77_SUB(mygammafn)(double *x) { return gammafn(x); }
the first does not compile.
wrapper2.c: In function `mygammafn_':
wrapper2.c:6: error: incompatible type for argument 1 of `Rf_gammafn'
The second compiles and works fine.
But still, I find it very strange as the C function gammafn actually called
( as I can see from /R-2.1.0/src/nmath/gamma.c)
is not defined as
double gammafn(double *x)
but as
double gammafn(double x)
Am I missing something ?
Gilles
Le Mercredi 15 Juin 2005 17:06, vous avez écrit :
> I actually deleted a part of my reply, dealing with exactly that. Sorry!
> You need to declare the C wrapper to take a pointer to a double ("double
> *") rather than a double. C passes by value whereas Fortran passes by
> reference; in C you get this effect by passing a pointer to the value
> (which is also a value). So you want
>
> double F77_SUB(mygammafn)(double *x) { return gammafn(x); }
>
> That should work; if not let me know and I'll look more carefully at
> Fortran <-> C conventions.
>
> Reid Huntsinger
>
> -Original Message-
> From: Gilles GUILLOT [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 15, 2005 3:50 AM
> To: Huntsinger, Reid
> Subject: Re: [Rd] Calling C from Fortran
>
>
> Thanks Reid!
> And now if I want to call a C function with arguments,
> e.g. to compute the gamma function at x,
> my C wrapper is:
>
> #include
> #include
> void F77_SUB(rndstart)(void) { GetRNGstate(); }
> void F77_SUB(rndend)(void) { PutRNGstate(); }
> double F77_SUB(normrnd)(void) { return norm_rand(); }
> double F77_SUB(mygammafn)(double x) { return gammafn(x); }
>
> And my Fortran is:
> subroutine testit()
> implicit none
> double precision normrnd, x, y, mygammafn
> call rndstart()
> x = dabs(normrnd())
> write(*,*) 'x=',x
> call rndend()
>
> y = mygammafn(x)
> write(*,*) 'y=',y
> end
>
> And it does not work, all calls of testit return the same y value.
> What is incorrect in my files ?
>
>
> Gilles
>
>
>
>
>
>
---
>--- Notice: This e-mail message, together with any attachments, contains
> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New
> Jersey, USA 08889), and/or its affiliates (which may be known outside the
> United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as
> Banyu) that may be confidential, proprietary copyrighted and/or legally
> privileged. It is intended solely for the use of the individual or entity
> named on this message. If you are not the intended recipient, and have
> received this message in error, please notify us immediately by reply
> e-mail and then delete it from your system.
>
---
>---
--
_
Gilles GUILLOT
INRA -Département Mathématiques et Informatique Appliquées
Unité Mixte de Recherche INRA - INAPG - ENGREF
Institut National Agronomique de Paris-Grignon
16, rue Claude Bernard
75231 Paris cedex 5 France
phone 33 1 44 08 18 42
fax 33 1 44 08 16 66
http://www.inapg.fr/ens_rech/mathinfo/personnel/guillot/welcome.html
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7943) documentation enhancement: Note in ?seek for Windows
Fair enough. But for the benefit of the unfortunate souls having to
work in Windows, it would be nice if the documentation were as explicit
as possible about what is and is not known about particular issues
(while still being concise). How about the following:
NEW:
#ifdef windows
The value returned by \code{seek()} is known to be unreliable
on Windows systems for text mode files. The Windows documentation
states that the return values from Windows OS seek functions for
text mode files are unreliable (because the Windows file-I/O
functions can insert extra characters at end-of-lines when working
with text mode files.) Binary mode files should not be affected by
this particular issue, but there are known problems on Windows
systems with the reliability of the return value from \code{seek()}
for binary mode files opened in append mode. Clipboard connections
can seek too.
#endif
Tony Plate
Prof Brian Ripley wrote:
> I think the proposed change is appropriate only if the return value is
> *known* to be reliable for binary files.
>
> I for one do not trust the writers of an OS whom have made such a
> serious error in one mode (and many other errors elsewhere) not to have
> made one in closely related code. Since it is not Open Source, we
> cannot find out.
>
> On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
>
>> [I started a new bug report for this issue because it was not the
>> primary issue in the original discussion, which was PR#7899]
>>
>> [EMAIL PROTECTED] wrote:
>> > Tony Plate wrote:
>> > [snip]
>> >>[EMAIL PROTECTED] wrote:
>> >>[snip]
>> >>>Note that ?seek currently tells us "The value returned by
>> >>>seek(where=NA) appears to be unreliable on Windows systems, at least
>> >>>for text files."
>> >>>It would be nice if this comment could be removed, of course
>> >>
>> >>
>> >>May the explanation could be given that this happens with text files
>> >>because Windows inserts extra characters at end-of-lines when reading
>> >>"text" mode files (but with binary files, things should be fine.) This
>> >>particular issue is documented in Microsoft Windows documentation
>> (e.g.,
>> >>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
>> >>by searching on Google using the terms "fseek windows documentation").
>> >>Are there any known issues using seek with binary files under Windows?
>> >>If there are not, then the caveat could be made specific to text files
>> >>and all vagueness removed.
>> >
>> >
>> > Hmm, all I find (including your link) is Windows CE related ...
>> >
>> > Uwe Ligges
>>
>> For the record, the documentation I pointed to is for Windows 2000 etc,
>> and is not just related to Windows CE (Uwe retracted that claim in a
>> private email).
>>
>> So, the suggestion to refine the note in ?seek stands. Perhaps
>> src/library/base/man/seek.Rd could be changed as follows:
>>
>> OLD:
>>
>> #ifdef windows
>> The value returned by \code{seek(where=NA)} appears to be unreliable
>> on Windows systems, at least for text files. Clipboard connections
>> can seek too.
>> #endif
>>
>> NEW:
>>
>> #ifdef windows
>> The value returned by \code{seek()} is unreliable
>> on Windows systems for text files. This is because the Windows
>> file-I/O functions can insert extra characters at end-of-lines
>> when working with text mode files. Binary mode files should not
>> be affected by this issue. Clipboard connections can seek too.
>> #endif
>>
>> Of course, if someone knows that the return value of seek() is
>> unreliable on Windows for binary files, this documentation change is
>> innappropriate (and then the documentation should probably be changed
>> from "appears to be unreliable, at least for text files" to "is
>> unreliable, for both binary and text files".
>>
>> -- Tony Plate
>>
>> __
>> 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] \section{Windows}{...} instead of #ifdef windows ... #endif? (Was: Re: (PR#7943) documentation ...)
Just a comment, that probably applies to a lot more Rd files; when
trying to developer cross-platform R code, it is very useful to have
identical documentation whatever platform you are working on. That is,
I would prefer
\section{Windows-specific comments}{
...
}
rather than
#ifdef windows
...
#endif
This would make it possible to write more robust code (without looking
at the source docs).
/Henrik
[EMAIL PROTECTED] wrote:
> Fair enough. But for the benefit of the unfortunate souls having to
> work in Windows, it would be nice if the documentation were as explicit
> as possible about what is and is not known about particular issues
> (while still being concise). How about the following:
>
> NEW:
>
> #ifdef windows
>The value returned by \code{seek()} is known to be unreliable
>on Windows systems for text mode files. The Windows documentation
>states that the return values from Windows OS seek functions for
>text mode files are unreliable (because the Windows file-I/O
>functions can insert extra characters at end-of-lines when working
>with text mode files.) Binary mode files should not be affected by
>this particular issue, but there are known problems on Windows
>systems with the reliability of the return value from \code{seek()}
>for binary mode files opened in append mode. Clipboard connections
>can seek too.
> #endif
>
> Tony Plate
>
>
> Prof Brian Ripley wrote:
>
>>I think the proposed change is appropriate only if the return value is
>>*known* to be reliable for binary files.
>>
>>I for one do not trust the writers of an OS whom have made such a
>>serious error in one mode (and many other errors elsewhere) not to have
>>made one in closely related code. Since it is not Open Source, we
>>cannot find out.
>>
>>On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote:
>>
>>
>>>[I started a new bug report for this issue because it was not the
>>>primary issue in the original discussion, which was PR#7899]
>>>
>>>[EMAIL PROTECTED] wrote:
>>>
Tony Plate wrote:
[snip]
>[EMAIL PROTECTED] wrote:
>[snip]
>
>>Note that ?seek currently tells us "The value returned by
>>seek(where=NA) appears to be unreliable on Windows systems, at least
>>for text files."
>>It would be nice if this comment could be removed, of course
>
>
>May the explanation could be given that this happens with text files
>because Windows inserts extra characters at end-of-lines when reading
>"text" mode files (but with binary files, things should be fine.) This
>particular issue is documented in Microsoft Windows documentation
>>>
>>>(e.g.,
>>>
>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
>by searching on Google using the terms "fseek windows documentation").
>Are there any known issues using seek with binary files under Windows?
>If there are not, then the caveat could be made specific to text files
>and all vagueness removed.
Hmm, all I find (including your link) is Windows CE related ...
Uwe Ligges
>>>
>>>For the record, the documentation I pointed to is for Windows 2000 etc,
>>>and is not just related to Windows CE (Uwe retracted that claim in a
>>>private email).
>>>
>>>So, the suggestion to refine the note in ?seek stands. Perhaps
>>>src/library/base/man/seek.Rd could be changed as follows:
>>>
>>>OLD:
>>>
>>>#ifdef windows
>>> The value returned by \code{seek(where=NA)} appears to be unreliable
>>> on Windows systems, at least for text files. Clipboard connections
>>> can seek too.
>>>#endif
>>>
>>>NEW:
>>>
>>>#ifdef windows
>>> The value returned by \code{seek()} is unreliable
>>> on Windows systems for text files. This is because the Windows
>>> file-I/O functions can insert extra characters at end-of-lines
>>> when working with text mode files. Binary mode files should not
>>> be affected by this issue. Clipboard connections can seek too.
>>>#endif
>>>
>>>Of course, if someone knows that the return value of seek() is
>>>unreliable on Windows for binary files, this documentation change is
>>>innappropriate (and then the documentation should probably be changed
>>>from "appears to be unreliable, at least for text files" to "is
>>>unreliable, for both binary and text files".
>>>
>>>-- Tony Plate
>>>
>>>__
>>>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
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Eilig Geschaftsvorschlag (PR#7944)
Geschaftsvorschlag. Zuerst muß ich um Ihre Zuversicht in dieser verhandlung bitten,dies ist auf Grund seiner lage, als das sein total VERTRAULICH und Geheimnisvoll. Aber ich weiß,daß eine verhandlung dieses Ausmaßes irgendeinen ängstlich und besorgt machen wird,aber ich versichre Ihnen,daß alles am Ende des tages in ordnung sein wird. Wir haben uns entschieden Sie durch eine E-mail sendung,wegen der Dringlichkeit diese verhandlung zu erreichen,als wir davon zuverlassig von seiner schnelligkeit und vertraulichkeit überzeugt worden sind. Ich möchte mich nun vorstellen. Ich bin Herr Thomas Mandino(Rechnungprüfer bei der Imperial Bank von Süd Afrika). Ich kam zu ihrem kontakt in meiner persönlichen suche nach einer zuverlassigen und anstandige person,um eine sehr vertrauliche verhandlung zu erledigen,die,die übertragung von einem fremden Konto das maximale zuversicht erfordert. Der vorschlag:Ein Ausländische,verstorbener Ingenieur Menfred Becker, ein Diamante Unternehmer mit der Bundes Regierung von Süd Afrika. Er war bis seinem Tod vor drei jahren in einem Flugzeug absturz,als unternehmer bei der Regierung tatig. Herr Becker war unser kunde hier bei der Imperial Bank von Süd Afrika und hatte ein Konto guthaben von US$18,5 milliarde(Achtzehn milliarde,fünf hundert Tausend United States Dollar.)welches die Bank jetzt fraglos erwartet,durch seine verwandten das Sie sich melden,wenn Sie sich nicht melden wird alles zu einem Afrikanischen vertrauens fond für waffen und munitionsbesorgungen bei einer freiheitsbewegung hier in AfriKa gespendet. Leidenschaftliche wertvolle Anstrengungen werden durch die Imperial - Bank gemacht,um einen kontakt mit jemanden von der Becker familie oder verwandten zu bekommen.Es hat aber bis jetzt keinen Erfolg gegeben. Es ist wegen der wahrgenommen moglichkeit keinen verwandten der Becker zu finden(er hatte keine frau und kinder)daß das management der eine Anordnung für den fond als nicht zubehaupten deklariert werden,sollte, und dann zum vertrauens-fond für waffen und munition bersorgung ausgeben,die dem kurs vom krieg in Afrika gespendet wird. Um dieser negative Entwicklung abzuwenden,haben ich und einige meiner bewöhrten kollegen in der Bank beschlossen das Geld nach Ihre zustimmung zu überweisen und suchen jetzt Ihre Erlaubnis das Sie sich als verwandter des verstorbenen Ing.Manfred Becker deklarieren,damit der Fond in der höhe von USD$18,5m infolgendessen als der Nutznießer(Verwandter des Becker)auf Ihr Bank Konto überwiesen werden. Alle beurkundungen und Beweist die Ihnen ermöglichen diese Fonds zu behaupten werden wir zu Ihrer verfügung stellen,damit alles gut verläuft und wir versicheren Ihnen ein 100% Risiko freie Verwicklung. Ihr Anteil wäre 30% von der totalen Gange, während die restlichen 70% ist für mich und meine kollege. Wenn dieser vorschlag für Sie OK ist und Sie wünschen das vertrauen auszunutzen, das wir hoffen auf Ihnen und Ihrer Gesellschaft zu verleihen,dann senden sie mir netterweise sofort per meine personal E-mail Adresse,Ihre vertrauliche Telefonnummer, fax-nummer und Ihre vertraulicher E-mail,Anschrift, damit ich Ihnen die relevanten details dieser verhandlung senden kann. Danke in voraus. Mit freundlichen Grüße. Herr Thomas Mandino. Bitte schicken Sie Ihre Antwort an meinem Private Email:[EMAIL PROTECTED] Turmail.com Ucretsiz Eposta Servisi : http://www.turmail.com Gelismis Spam ve Virus Filtreleme Servisleri 100 Megabyte E-posta kotasi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Include File Guards
On Wed, 18 May 2005, Peter Dalgaard wrote: > Paul Roebuck <[EMAIL PROTECTED]> writes: > > > R 2.1.0/src/include from 2005/04/18 download > > > > Naming inconsistent for guards as well but that's pedantic. > > Simple convention: > > file > > #ifndef R_FOO_H > > file > > #ifndef R_EXT_BAR_H > > > > Missing guards: > > > > > > > > > > > > > > > > > > > > > > Illegal Guards (leading underscore): > > > > > > > > Thanks. The ones outside R_ext, except Rinternals.h, are not part of the > API, so it is not a bug that there are no guards - could still be a > good idea to have them of course. libextern.h explicitly says that you > shouldn't disallow including it more than once. So the ones with real > problems would be > > > > > > > > > > What's illegal about leading underscores, BTW? > I downloaded the R-patched for 2005/06/14 and noticed that the guards were never fixed. Should a bug report have been opened instead of simply noting them here? -- SIGSIG -- signature too long (core dumped) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Eilig Geschaftsvorschlag (PR#7945)
Geschaftsvorschlag. Zuerst muß ich um Ihre Zuversicht in dieser verhandlung bitten,dies ist auf Grund seiner lage, als das sein total VERTRAULICH und Geheimnisvoll. Aber ich weiß,daß eine verhandlung dieses Ausmaßes irgendeinen ängstlich und besorgt machen wird,aber ich versichre Ihnen,daß alles am Ende des tages in ordnung sein wird. Wir haben uns entschieden Sie durch eine E-mail sendung,wegen der Dringlichkeit diese verhandlung zu erreichen,als wir davon zuverlassig von seiner schnelligkeit und vertraulichkeit überzeugt worden sind. Ich möchte mich nun vorstellen. Ich bin Herr Thomas Mandino(Rechnungprüfer bei der Imperial Bank von Süd Afrika). Ich kam zu ihrem kontakt in meiner persönlichen suche nach einer zuverlassigen und anstandige person,um eine sehr vertrauliche verhandlung zu erledigen,die,die übertragung von einem fremden Konto das maximale zuversicht erfordert. Der vorschlag:Ein Ausländische,verstorbener Ingenieur Menfred Becker, ein Diamante Unternehmer mit der Bundes Regierung von Süd Afrika. Er war bis seinem Tod vor drei jahren in einem Flugzeug absturz,als unternehmer bei der Regierung tatig. Herr Becker war unser kunde hier bei der Imperial Bank von Süd Afrika und hatte ein Konto guthaben von US$18,5 milliarde(Achtzehn milliarde,fünf hundert Tausend United States Dollar.)welches die Bank jetzt fraglos erwartet,durch seine verwandten das Sie sich melden,wenn Sie sich nicht melden wird alles zu einem Afrikanischen vertrauens fond für waffen und munitionsbesorgungen bei einer freiheitsbewegung hier in AfriKa gespendet. Leidenschaftliche wertvolle Anstrengungen werden durch die Imperial - Bank gemacht,um einen kontakt mit jemanden von der Becker familie oder verwandten zu bekommen.Es hat aber bis jetzt keinen Erfolg gegeben. Es ist wegen der wahrgenommen moglichkeit keinen verwandten der Becker zu finden(er hatte keine frau und kinder)daß das management der eine Anordnung für den fond als nicht zubehaupten deklariert werden,sollte, und dann zum vertrauens-fond für waffen und munition bersorgung ausgeben,die dem kurs vom krieg in Afrika gespendet wird. Um dieser negative Entwicklung abzuwenden,haben ich und einige meiner bewöhrten kollegen in der Bank beschlossen das Geld nach Ihre zustimmung zu überweisen und suchen jetzt Ihre Erlaubnis das Sie sich als verwandter des verstorbenen Ing.Manfred Becker deklarieren,damit der Fond in der höhe von USD$18,5m infolgendessen als der Nutznießer(Verwandter des Becker)auf Ihr Bank Konto überwiesen werden. Alle beurkundungen und Beweist die Ihnen ermöglichen diese Fonds zu behaupten werden wir zu Ihrer verfügung stellen,damit alles gut verläuft und wir versicheren Ihnen ein 100% Risiko freie Verwicklung. Ihr Anteil wäre 30% von der totalen Gange, während die restlichen 70% ist für mich und meine kollege. Wenn dieser vorschlag für Sie OK ist und Sie wünschen das vertrauen auszunutzen, das wir hoffen auf Ihnen und Ihrer Gesellschaft zu verleihen,dann senden sie mir netterweise sofort per meine personal E-mail Adresse,Ihre vertrauliche Telefonnummer, fax-nummer und Ihre vertraulicher E-mail,Anschrift, damit ich Ihnen die relevanten details dieser verhandlung senden kann. Danke in voraus. Mit freundlichen Grüße. Herr Thomas Mandino. Bitte schicken Sie Ihre Antwort an meinem Private Email:[EMAIL PROTECTED] Turmail.com Ucretsiz Eposta Servisi : http://www.turmail.com Gelismis Spam ve Virus Filtreleme Servisleri 100 Megabyte E-posta kotasi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] a bug in glm.fit() (PR#7947)
glm.fit() gave me the same AIC's regardless of TRUE or FALSE intercept option. > myX <- as.matrix(1:10) > myY <- 3+5*myX > foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), > intercept=TRUE) > foo$aic [1] 38.94657 > foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), > intercept=FALSE) > foo$aic [1] 38.94657 > AIC(lm(myY~0+myX, data=data.frame(myY,myX))) [1] 38.94657 > AIC(lm(myY~1+myX, data=data.frame(myY,myX))) [1] -650.9808 -Luke __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a bug in glm.fit() (PR#7947)
What is the bug? This is the same model: the `intercept' term affects the null model, not the actual model. Just look at all the output. On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote: > glm.fit() gave me the same AIC's regardless of TRUE or FALSE intercept option. > >> myX <- as.matrix(1:10) >> myY <- 3+5*myX >> foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), >> intercept=TRUE) >> foo$aic > [1] 38.94657 >> foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), >> intercept=FALSE) >> foo$aic > [1] 38.94657 >> AIC(lm(myY~0+myX, data=data.frame(myY,myX))) > [1] 38.94657 >> AIC(lm(myY~1+myX, data=data.frame(myY,myX))) > [1] -650.9808 -- 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
