Re: [Rd] Bug in rank with utf8?
2015-08-13 8:39 GMT-05:00 Hadley Wickham : > x <- "\u0663" > y <- 3 > > x == y > # FALSE > rank(c(x, y)) > # c(1.5, 1.5) > also interesting, and confusing to me: > x == y [1] FALSE > x > y [1] FALSE > x < y [1] FALSE > With some slight changes: > x <- "\u0663" > y <- "3" > xy <- c(x,y) > rank(xy); [1] 1.5 1.5 > Sys.getlocale(); [1] "LC_CTYPE=en_US.UTF8;LC_NUMERIC=C;LC_TIME=en_US.UTF8;LC_COLLATE=en_US.UTF8;LC_MONETARY=en_US.UTF8;LC_MESSAGES=en_US.UTF8;LC_PAPER=en_US.UTF8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF8;LC_IDENTIFICATION=C" > Sys.setlocale(category="LC_COLLATE", locale="C"); [1] "C" > rank(xy); [1] 2 1 > > -- > http://had.co.nz/ > > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in rank with utf8?
Once again again, I did not read the Subject correctly. I switched away from UTF8 in my second test. On Thu, Aug 13, 2015 at 9:01 AM, John McKown wrote: > 2015-08-13 8:39 GMT-05:00 Hadley Wickham : > >> x <- "\u0663" >> y <- 3 >> >> x == y >> # FALSE >> rank(c(x, y)) >> # c(1.5, 1.5) >> > > also interesting, and confusing to me: > > > x == y > [1] FALSE > > x > y > [1] FALSE > > x < y > [1] FALSE > > > > With some slight changes: > > > x <- "\u0663" > > y <- "3" > > xy <- c(x,y) > > rank(xy); > [1] 1.5 1.5 > > Sys.getlocale(); > [1] > "LC_CTYPE=en_US.UTF8;LC_NUMERIC=C;LC_TIME=en_US.UTF8;LC_COLLATE=en_US.UTF8;LC_MONETARY=en_US.UTF8;LC_MESSAGES=en_US.UTF8;LC_PAPER=en_US.UTF8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF8;LC_IDENTIFICATION=C" > > Sys.setlocale(category="LC_COLLATE", locale="C"); > [1] "C" > > rank(xy); > [1] 2 1 > > > > > >> -- >> http://had.co.nz/ >> >> > -- > > Schrodinger's backup: The condition of any backup is unknown until a > restore is attempted. > > Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. > > He's about as useful as a wax frying pan. > > 10 to the 12th power microphones = 1 Megaphone > > Maranatha! <>< > John McKown > -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Different results for tan(pi/2) and tanpi(1/2)
On Fri, Sep 9, 2016 at 12:24 PM, Hans W Borchers wrote: > As the subject line says, we get different results for tan(pi/2) and > tanpi(1/2), though this should not be the case: > > > tan(pi/2) > [1] 1.633124e+16 > > > tanpi(1/2) > [1] NaN > Warning message: > In tanpi(1/2) : NaNs produced > > By redefining tanpi with sinpi and cospi, we can get closer: > > > tanpi <- function(x) sinpi(x) / cospi(x) > > > tanpi(c(0, 1/2, 1, 3/2, 2)) > [1]0 Inf0 -Inf0 > > Hans Werner > > > When I do a ?tanpi, I see the following: ‘tanpi(0.5)’ is ‘NaN’. Similarly for other inputs with fractional part ‘0.5’. I don't know why this is, but apparently the function is working as documented. Whether that is correct or not is not for me to say. -- Unix: Some say the learning curve is steep, but you only have to climb it once. -- Karl Lehenbauer Unicode: http://xkcd.com/1726/ Maranatha! <>< John McKown [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] More than one package document with the same name
On Tue, Aug 5, 2014 at 5:47 PM, Davison, Jerry wrote:
> Hi,
>
> I sent this to the Bioconductor mailing list (q.v.), replies recommended this
> forum. Here it is:
> A suggestion. Typically a package provides documentation of two types, one or
> more vignettes and a reference manual; and they have the same file name,
> PackageName.pdf. When downloaded some file name manipulation is required, or
> accept PackageName(1).pdf.
>
> I suggest the documents be given different names, for example the reference
> manual could be named PackageNameRefMan.pdf. Package checking could enforce
> the rule.
> Jerry
>
Sounds like you want to put all the pdf files in a single directory. I
like that too. I cheat. I run Linux. I have a ~/Documents/R-pdfs in
which I keep "symlinks" to all the pdf files. And I do it similar to
the way that you indicate. I make the name of the pdf be
${enclosing_directory}_${original_pdf_name.pdf}. I do something like:
cd ~/Documents/R-pdf
find /usr/lib64/R -name '*.pdf'|\
while read i;do
file=${i##*/};
dir=${i%%/doc/*.pdf};
package=${dir##*/};
ln -s "$i" "${package}_${file}";
done
Above won't work if anything has a blank in it. Windows people tend to
do this. Most UNIX people are better trained.
It would be nice if the packagers did this. But the above works for
me. On Linux and other UNIX like systems. Won't work for the poor,
benighted Windows people. But I think something similar is possible.
But I don't know Windows well enough.
Maranatha! <><
John McKown
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN binary, but no source
On Thu, Mar 19, 2015 at 10:46 AM, Gábor Csárdi wrote: > Hi All, > > this is a CRAN question, so I am sorry if this is not the appropriate forum. > > I noticed that there is at least one CRAN package that has a binary (OSX > Mavericks) for a version, that does not have any source package on CRAN. Or > at least I am unable to locate it. The package is Rglpk: > http://cran.r-project.org/web/packages/Rglpk/index.html I went there and say a source package: Downloads: Reference manual:Rglpk.pdf Package source:Rglpk_0.6-0.tar.gz <<>> Windows binaries:r-devel: Rglpk_0.6-0.zip, r-release: Rglpk_0.6-0.zip, r-oldrel: Rglpk_0.6-0.zip OS X Snow Leopard binaries:r-release: Rglpk_0.6-0.tgz, r-oldrel: Rglpk_0.6-0.tgz OS X Mavericks binaries:r-release: Rglpk_0.5-2.tgz Old sources:Rglpk archive Or: http://cran.r-project.org/src/contrib/Rglpk_0.6-0.tar.gz > > It offers a binary for 0.5-2, but there is no 0.5-2 source package > anywhere. Is this simply a mistake, or it is OK to have binary-only > packages on CRAN? > > Thanks much, Best, > Gabor > > [[alternative HTML version deleted]] Please, no HTML, per forum rules. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN binary, but no source
On Thu, Mar 19, 2015 at 10:54 AM, John McKown wrote: > On Thu, Mar 19, 2015 at 10:46 AM, Gábor Csárdi wrote: >> Hi All, >> >> this is a CRAN question, so I am sorry if this is not the appropriate forum. >> >> I noticed that there is at least one CRAN package that has a binary (OSX >> Mavericks) for a version, that does not have any source package on CRAN. Or >> at least I am unable to locate it. The package is Rglpk: >> http://cran.r-project.org/web/packages/Rglpk/index.html > > I went there and say a source package: > > > > Downloads: > > Reference manual:Rglpk.pdf > Package source:Rglpk_0.6-0.tar.gz <<>> > Windows binaries:r-devel: Rglpk_0.6-0.zip, r-release: Rglpk_0.6-0.zip, > r-oldrel: Rglpk_0.6-0.zip > OS X Snow Leopard binaries:r-release: Rglpk_0.6-0.tgz, r-oldrel: > Rglpk_0.6-0.tgz > OS X Mavericks binaries:r-release: Rglpk_0.5-2.tgz > Old sources:Rglpk archive > > > Or: http://cran.r-project.org/src/contrib/Rglpk_0.6-0.tar.gz > >> >> It offers a binary for 0.5-2, but there is no 0.5-2 source package >> anywhere. Is this simply a mistake, or it is OK to have binary-only >> packages on CRAN? OOPS, I saw the 0.6 package source, not 0.5. My mistake. Why not recompile? Do you require 0.5 for some reason? I would guess that CRAN requires only the _current_ source, not _every_ source. And http://cran.r-project.org/src/contrib/Archive/Rglpk/ only has the source archived for 0.4-1 >> >> Thanks much, Best, >> Gabor -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] F77_CALL/NAME problem
On Wed, Mar 25, 2015 at 4:44 AM, bstr wrote:
> Dear R-devel,
>
> I am trying to use Fortran DGESV subroutine into C. Here it is the relevant
> part of the C file I am currently writing
>
> #include
> #include
> #include
> #include
>
> void F77_NAME(DGESV)( int*, int*, double*, int*, int*, double*, int*, int*);
>
> void solve( int *p, double *A, double *Ainv)
> {
> ...
> F77_CALL(DGESV)(p, p, Ain, p, ipiv, Bin, p, &info);
> }
Try lower case.
void F77_NAME(dgesv)( int*, int*, double*, int*, int*, double*, int*, int*);
void solve( int *p, double *A, double *Ainv)
{
...
F77_CALL(dgesv)(p, p, Ain, p, ipiv, Bin, p, &info);
}
The lapack.so file has a name "dgesv_" in it, not DGESV_.
>
> In order to create the ".so" file to load in R I downloaded the dgesv.f file
> as well as the dependencies (dgetf2.f dgetrf.f dgetrs.f dlaswp.f). As I was
> used to I ran in a terminal
>
> R CMD COMPILE *.f
> R CMD SHLIB MY_C_FILE.c *.o
>
> to get the MY_C_FILE.so file. However, when I try to load it in a R session
> I get the following error message "undefined symbol: DGESV_". Similar errors
> are occurring with some other (old) C files that I was used to use a couple
> of years ago. In this connection I have to say that those file were working
> under an older linux version (I guess ubuntu 12.04 LTS rather than the
> current one which is 14.04 LTS).
>
> Best Regards,
>
> N. Lunardon
--
If you sent twitter messages while exploring, are you on a textpedition?
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
