[Rd] Closed-source non-free ParallelR ?
Dear R-devel, REvolution appear to be offering ParallelR only when bundled with their R Enterprise edition. As such it appears to be non-free and closed source. http://www.revolution-computing.com/products/parallel-r.php Since R is GPL and not LGPL, is this a breach of the GPL ? Below is the "GPL and ParallelR" thread from their R forum. mdowle > It appears that ParallelR (packages foreach and iterators) is only available bundled with the Enterprise edition. Since R is GPL, and ParallelR is derived from R, should ParallelR not also be GPL? Regards, Matthew revolution > Hello Matthew, ParallelR consists of both proprietary and GPL packages. The randomForest and snow libraries GPL licensed, whereas the other libraries we include have a commercial license(including 'foreach' and 'iterators'). Stephen Weller revolution > I wanted to expand on Stephen's reply. ParallelR is a suite of R packages, and it is well established that packages can be under a difference license than R itself (i.e. not the GPL). For example, package MCE is licensed under BSD, RColorBrewer is licensed under Apache, most of Bioconductor is under the Artistic license and some are under completely unique licenses (e.g. mclust). REvolution Computing developed all of the code in ParallelR (except for the bundled GPL packages Stephen mentions), and we decided to release it under our own license in REvolution R Enterprise. That said, we do already release components of parallelR, such as the underlying engine, Networkspaces (also written by REvolution Computing) under an open source licence. Also, we are likely to release some other components including foreach and iterators, to CRAN soon. David Smith Director of Community, REvolution Computing mdowle > The examples you give (MCE, RColorBrewer, Bioconductor) are all available for free including the source code. Their licenses have been approved by the FSF. Free software and open source are the terms of work derived from GPL licensed software. REvolution's packages 'foreach' and 'iterators' are neither free or open source. Can you provide a precedent for proprietary closed-source packages for R ? Is your policy approved by the FSF ? I don't object to REvolution. I am a fan of you making money from training courses, consultancy, support and binaries. These are all permitted by the GPL. However the GPL does not allow you to distribute work derived from R which is either closed source or non-free. R is GPL, not LGPL. The above is my personal understanding. I am now posting to r-devel to check, feel free to join the public debate there. Regards, Matthew [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] build-aux missing in 2.9.0 packages (PR#13668)
Full_Name: Michael Spiegel Version: 2.9.0 OS: linux Submission from: (NULL) (128.143.137.189) I think something was changed in the handling of the build-aux directory when installing R packages. The directory is no longer copied into the installation directory. I believe it was not on the list "approved" directories that are copied into the install directory, so perhaps the better location for build-aux is actually in inst/build-aux. However, when I try that then inst/build-aux is NOT copied into the installation directory. If I try renaming inst/build-aux to any other name (inst/config-aux), then the directory is copied over. It appears as if build-aux is not special enough to be copied over to the installation directory, but too special for it to live in the /inst directory. A consistent strategy is preferable. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
> On Tue, 21 Apr 2009 21:16:59 -0500, > Kevin W (KW) wrote: > The printing of the locale information from sessionInfo is not very tidy. > Using toLatex(sessionInfo) pretty much guarantees "badness" from breaking > the margin boundary (though my version of TeX no longer reports such > errors). A random example is here: > http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf > I find the locale information unnecessary and right now I hack this with > si = sessionInfo() > si$locale = "US" > toLatex(si) > I would like to be able to do something a bit cleaner, for example > sessionInfo(locale=FALSE) > For what it's worth, I don't think that early versions of sessionInfo > printed information about the locale. It went in on 2006-05-26, so it's bben there for some time now. > Discussion welcome. I agree that it doesn't look nice in latex documents, but it is very handy in bug reports. Are there any objections if we add a locale argument to the toLatex() method and let that default to FALSE? Best, Fritz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
Friedrich Leisch wrote: On Tue, 21 Apr 2009 21:16:59 -0500, Kevin W (KW) wrote: > The printing of the locale information from sessionInfo is not very tidy. > Using toLatex(sessionInfo) pretty much guarantees "badness" from breaking > the margin boundary (though my version of TeX no longer reports such > errors). A random example is here: > http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf > I find the locale information unnecessary and right now I hack this with > si = sessionInfo() > si$locale = "US" > toLatex(si) > I would like to be able to do something a bit cleaner, for example > sessionInfo(locale=FALSE) > For what it's worth, I don't think that early versions of sessionInfo > printed information about the locale. It went in on 2006-05-26, so it's bben there for some time now. > Discussion welcome. I agree that it doesn't look nice in latex documents, but it is very handy in bug reports. Are there any objections if we add a locale argument to the toLatex() method and let that default to FALSE? No objection although I would not be against letting it default to TRUE to preserve current behaviour. One improvement in the locale information that would make the LaTeX look much nicer would be to add a space after the separator, i.e. item1; item2; item3 instead of item1;item2;item3 That is for me more important than having the option to include locale info or not as without such a change I found no way to prevent the locale information to run into the margin (and off the page) of the resulting LaTeX document and that is esthetically much more displeasing than the mere presence of the locale information. Best, Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
> "TobiasV" == Tobias Verbeke > on Wed, 22 Apr 2009 09:57:30 +0200 writes: TobiasV> Friedrich Leisch wrote: >>> On Tue, 21 Apr 2009 21:16:59 -0500, >>> Kevin W (KW) wrote: >> >> > The printing of the locale information from sessionInfo is not very tidy. >> > Using toLatex(sessionInfo) pretty much guarantees "badness" from breaking >> > the margin boundary (though my version of TeX no longer reports such >> > errors). A random example is here: >> > http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf >> >> > I find the locale information unnecessary and right now I hack this with >> > si = sessionInfo() >> > si$locale = "US" >> > toLatex(si) >> >> > I would like to be able to do something a bit cleaner, for example >> > sessionInfo(locale=FALSE) >> >> > For what it's worth, I don't think that early versions of sessionInfo >> > printed information about the locale. >> >> It went in on 2006-05-26, so it's bben there for some time now. >> >> >> > Discussion welcome. >> >> I agree that it doesn't look nice in latex documents, but it is very >> handy in bug reports. >> >> Are there any objections if we add a locale argument to the toLatex() >> method and let that default to FALSE? TobiasV> No objection although I would not be against TobiasV> letting it default to TRUE to preserve current behaviour. I agree with setting the default to keep the current behavior. As Fritz mentioned, there situations where the locale (information) is of quite some importance. As we know that Sweave is used in quite a few circumstances with automatic report generation, of which in *some* cases the locale may also matter (and is desired to be visible), I think we should not change the default behavior lightly (apart from the extra spaces, see below). TobiasV> One improvement in the locale information that would make the LaTeX look TobiasV> much nicer would be to add a space after the separator, i.e. TobiasV> item1; item2; item3 TobiasV> instead of TobiasV> item1;item2;item3 TobiasV> That is for me more important than having the TobiasV> option to include locale info or not I agree very much; and indeed, adding the space after ";" is trivial to achieve in the next version of toLatex()'s "sessionInfo" method, as well. Martin TobiasV> as without such a change I found no way to prevent the locale TobiasV> information to run into the margin (and off the TobiasV> page) of the resulting LaTeX document and that is TobiasV> esthetically much more displeasing than the mere TobiasV> presence of the locale information. TobiasV> Best, TobiasV> Tobias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Installation fails (PR#13669)
Full_Name: Dieter Kadelka Version: 2.9.0 OS: Linux Submission from: (NULL) (129.13.115.98) Hallo, my system is Linux mspcka3 2.6.5-7.276-default #1 Mon Jul 24 10:45:31 UTC 2006 i686 GNU/Linux with gcc-4.3.3 Installation of R-2.9.0 fails, R-2.8.1 is o.k. After configure make I get ... WARNING: ignoring environment value of R_HOME >>> Building/Updating help pages for package 'tcltk' Formats: text html latex example TclInterface texthtmllatex example TkCommandstexthtmllatex example TkWidgetcmds texthtmllatex example TkWidgets texthtmllatex example tclServiceModetexthtmllatex example tcltk-defunct texthtmllatex tcltk-package texthtmllatex tkProgressBar texthtmllatex example tkStartGUItexthtmllatex tk_choose.dir texthtmllatex example tk_choose.files texthtmllatex example tk_messageBox texthtmllatex tk_select.listtexthtmllatex tkpager texthtmllatex make[2]: Leaving directory `/install/R/R-2.9.0/src/library' make[1]: Leaving directory `/install/R/R-2.9.0/src/library' make[1]: Entering directory `/install/R/R-2.9.0/src/library/Recommended' make[2]: Entering directory `/install/R/R-2.9.0/src/library/Recommended' begin installing recommended package VR WARNING: ignoring environment value of R_HOME sh: Zeile 2: `python2.4': Ist kein gültiger Bezeichner. make[2]: *** [VR.ts] Fehler 1 make[2]: Leaving directory `/install/R/R-2.9.0/src/library/Recommended' make[1]: *** [recommended-packages] Fehler 2 make[1]: Leaving directory `/install/R/R-2.9.0/src/library/Recommended' make: *** [stamp-recommended] Fehler 2 Invoking in bin ./R CMD config I get (depending on the environment) either a segfault or WARNING: ignoring environment value of R_HOME sh: Zeile 2: `python2.4': Ist kein gültiger Bezeichner. I tried the last R-patch, no difference. I don't whether this problem is specific to my system or a general problem. Thanks Dieter Kadelka __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Clarification for options(OutDec)
The documentation for the OutDec option says that it should be a
'one-character string'; yet, if I try a unicode character, it doesn't seem
to work. Are unicode chars not counted as one-character?
This is within the mac GUI, but I also see this on linux boxes.
> x <- '\u00B7'
> nchar(x)
[1] 1
> options(OutDec=x)
Error in options(OutDec = x) : invalid value for 'OutDec'
I don't think I've changed anything with my LANG settings, but here it
is anyway:
> Sys.getenv('LANG')
LANG
"en_GB.UTF-8"
> version
_
platform i386-apple-darwin8.11.1
arch i386
os darwin8.11.1
system i386, darwin8.11.1
status
major 2
minor 9.0
year 2009
month 04
day17
svn rev48333
language R
version.string R version 2.9.0 (2009-04-17)
Stephen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Installation fails (PR#13669)
dieter.kade...@stoch.uni-karlsruhe.de wrote:
> Hallo,
> my system is
>
> Linux mspcka3 2.6.5-7.276-default #1 Mon Jul 24 10:45:31 UTC 2006 i686
> GNU/Linux
> with gcc-4.3.3
Which distribution? (A 2.5 year old kernel suggests Debian, but...)
> Installation of R-2.9.0 fails, R-2.8.1 is o.k.
> begin installing recommended package VR
> WARNING: ignoring environment value of R_HOME
> sh: Zeile 2: `python2.4': Ist kein gültiger Bezeichner.
Why is R_HOME set in your environment, and how did python get into this?
You could check your set of environment variables ("env" command) for
anything python-related.
>
> Invoking in bin
> ./R CMD config
> I get (depending on the environment) either a segfault or
>
> WARNING: ignoring environment value of R_HOME
> sh: Zeile 2: `python2.4': Ist kein gültiger Bezeichner.
>
> I tried the last R-patch, no difference.
>
> I don't whether this problem is specific to my system or a general problem.
Probably mainly local to your system, but could be something fixable in
R if we forgot to control the PATH settings or suchlike.
--
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
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Clarification for options(OutDec)
On Wed, 22 Apr 2009, Stephen Eglen wrote:
The documentation for the OutDec option says that it should be a
'one-character string'; yet, if I try a unicode character, it doesn't seem
to work. Are unicode chars not counted as one-character?
Correct, it has to be a single byte (and the comment dates from
before UTF-8 was suported).
This is within the mac GUI, but I also see this on linux boxes.
x <- '\u00B7'
nchar(x)
[1] 1
options(OutDec=x)
Error in options(OutDec = x) : invalid value for 'OutDec'
I don't think I've changed anything with my LANG settings, but here it
is anyway:
Sys.getenv('LANG')
LANG
"en_GB.UTF-8"
version
_
platform i386-apple-darwin8.11.1
arch i386
os darwin8.11.1
system i386, darwin8.11.1
status
major 2
minor 9.0
year 2009
month 04
day17
svn rev48333
language R
version.string R version 2.9.0 (2009-04-17)
Stephen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
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] reversing xlim, ylim in smoothScatter
Hello, I have found that in smoothScatter it is not possible to reverse the axes plotted (R version 2.9.0) . It appears that this arises from the hard coding of xlim and ylim in smoothscatter.R in the lines : x <- x[ xlim[1] <= x[,1] & x[,1] <=xlim[2], ] (line number 25) and x <- x[ ylim[1] <= x[,2] & x[,2] <= ylim[2], ] (line number 31) This results in a x being NA if ylim[1] > ylim[2] which results in an error on executing map <- grDevices:::.smoothScatterCalcDensity(x, nbin, bandwidth) To counter this problem, I replaced the above two lines by : x <-x [min(xlim) <= x[,1] & x[,1] <= max(xlim), ] and x <- x[min(ylim) <= x[,2] & x[,2] <= max(ylim), ] and now smoothscatter reverses axes properly if xlim and/or ylim are provided with reversed ranges. I am wondering if this would break something somewhere else or if there is a better way to reverse the axes. (I am a newbie in R programming although I have been using R for some astronomical plots and computations etc...) Thanks in advance for your comments! Shashi -- Shashikiran Ganesh http://www.prl.res.in/~shashi http://cosmicdiary.org/blogs/shashikiran_ganesh/ Registered linux user number: 39542 (http://counter.li.org) Now surf faster and smarter ! Check out the new Firefox 3 - Yahoo! Edition http://downloads.yahoo.com/in/firefox/ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] bug when subtracting decimals?
On Apr 22, 2009, at 4:49 AM, Martin Maechler wrote:
"MS" == Marc Schwartz
on Tue, 21 Apr 2009 08:06:46 -0500 writes:
MS> It does look like R's behavior has changed since then. Using:
MS> R version 2.9.0 Patched (2009-04-18 r48348)
MS> on OSX:
MS> # This first example has changed.
MS> # Prior result was 414.94
print(4.145 * 100 + 0.5, digits = 20)
MS> [1] 415
formatC(4.145 * 100 + 0.5, format = "E", digits = 20)
MS> [1] "4.14943157E+02"
print(0.5 - 0.4 - 0.1, digits = 20)
MS> [1] -2.77555756156289e-17
formatC(0.5 - 0.4 - 0.1, format = "E", digits = 20)
MS> [1] "-2.77555756156289135106E-17"
MS> What is interesting is that:
4.145 * 100 + 0.5 == 415
MS> [1] FALSE
(4.145 * 100 + 0.5) - 415
MS> [1] -5.684342e-14
all.equal(4.145 * 100 + 0.5, 415, 0)
MS> [1] "Mean relative difference: 1.369721e-16"
MS> So it would appear that in the first R example above, the
print()
MS> function has changed in a material fashion.
Yes ((though not with *my* vote...)).
However, be aware that such calculations *are* platform
dependent, and IIUC, you are now using OS X wheras you've used
another platform previously, so some of the differences you see
may not be from changes in R, but from changes in the platform
you use.
Back to the topic of print():
Actually, also format() has changed similarly to my
chagrin.
In older versions of R, you could ask it to give "too many" digits,
but now it gives "too few" even for maximal 'digits'.
{There is a good reason - which I don't recall - for the new behavior}
With as.character() it was worse (in older R versions): it gave
sometimes too little digits, sometimes too many, whereas now it
is at least consistently giving "too little".
But the effect is that in ch <- as.character(x) ,
ch may contain duplicated entries even for unique x,
e.g., for x <- c(1, 1 + 4e-16)
BTW, one alternative to {"my"} formatC() is sprintf(),
and if you are really interested: The latest changes (in 2.10.0 R-
devel),
ensuring unique factor levels actually now make use of
sprintf("%.17g", .)
instead of as.character(.) exactly in order to ensure that
different numbers map to different strings necessarily.
BTW, we are way off topic for R-help, being in R-devel realm,
but as this thread has started here, we may keep it...
Martin Maechler, ETH Zurich
Thanks for replying Martin.
While I appreciate your comment above, I am moving to r-devel given
the content. I agree that we are getting into low level subject matter.
FWIW, I grabbed my dusty old Dell laptop running Fedora 10 out of the
closet and booted it up.
I get the same behavior as above there with R 2.8.1 patched.
So this would suggest that it it not an OS issue, but indeed a change
in R.
I did try to build R 1.7.1 (the version used in the prior examples
almost 6 years ago) on OSX, but it would appear that things have
changed sufficiently in the intervening time frame as to preclude a
successful build. I suspect much of the issue may be that Apple moved
to Intel CPU's only about 4 years ago, so perhaps the configuration of
older versions of R on OSX for Intel would require much work which is
not worth it here. I would of course defer to others with more in-
depth knowledge on that point.
I did not see anything in any of the *NEWS files, but the help for
print() does reference:
Warning
Using too large a value of digits may lead to representation errors in
the calculation of the number of significant digits and the decimal
representation: these are likely for digits >= 16, and these possible
errors are taken into account in assessing the numher of significant
digits to be printed in that case.
Whereas earlier versions of R might have printed further digits for
digits >= 16 on some platforms, they were not necessarily reliable.
While I don't want to re-visit what from your comments appears to be a
sensitive subject, I do want to point out that this new behavior
arguably masks aspects of the original subject matter of the thread
from users. It also results in inconsistent behavior when compared to
the output of the other floating point comparisons I used, which
suggest that the result of the operation is not an integer, which will
serve to further confuse folks.
Is there some reasonable compromise to be had here such that
consistent and predictable behavior is possible in this realm,
especially given how frequently this fundamental subject comes up?
We of course don't need examples as complicated as the one above and
can use the more common:
> print(0.5 - 0.4, 20)
[1] 0.1
> 0.5 - 0.4 == 0.1
[1] FALSE
> all.equal(0.5 - 0.4, 0.1, 0)
[1] "Mean relative difference: 2.775558e-16"
So arguably, we are talking about boundary situations here.
Thanks Martin!
Marc
__
R-devel@r-project.org mailing list
https://stat.et
Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)
> "vQ" == Wacek Kusnierczyk
> on Tue, 21 Apr 2009 13:05:11 +0200 (CEST) writes:
vQ> Full_Name: Wacek Kusnierczyk
vQ> Version: 2.10.0 r48365
vQ> OS: Ubuntu 8.04 Linux 32bit
vQ> Submission from: (NULL) (129.241.110.141)
vQ> sprintf has a documented limit on strings included in the output using
the
vQ> format '%s'. It appears that there is a limit on the length of strings
included
vQ> with, e.g., the format '%d' beyond which surprising things happen
(output
vQ> modified for conciseness):
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1] 9000 9801
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1] 9000 9801 10602
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1] 9000 9801 10602 11403
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1] 9000 9801 10602 11403 12204
vQ> ...
vQ> Note that not only more than one '1' is included in the output, but
also that
vQ> the same functional expression (no side effects used beyond the
interface) gives
vQ> different results on each execution. Analogous behaviour can be
observed with
vQ> '%nd' where n > 8200.
vQ> The actual output above is consistent across separate sessions.
vQ> With sufficiently large field width values, R segfaults:
vQ> sprintf('%*d', 10^5, 1)
vQ> # *** caught segfault ***
vQ> # address 0xbfcfc000, cause 'memory not mapped'
vQ> # Segmentation fault
Thank you, Wacek.
That's all ``interesting'' ... unfortunately,
my version of 'man 3 sprintf' contains
>> BUGS
>>Because sprintf() and vsprintf() assume an arbitrarily
>>long string, callers must be careful not to overflow the
>>actual space; this is often impossible to assure. Note
>>that the length of the strings produced is
>>locale-dependent and difficult to predict. Use
>>snprintf() and vsnprintf() instead (or asprintf() and vasprintf).
(note the "impossible" part above)
and we haven't used snprintf() yet, probably because it
requires the C99 C standard, and AFAIK, we have only relatively
recently started to more or less rely on C99 in the R sources.
More precisely, I see that some windows-only code relies on
snprintf() being available whereas in at least on non-Windows
section, I read /* we cannot assume snprintf here */
Now such platform dependency issues and corresponding configure
settings I do typically leave to other R-corers with a much
wider overview about platforms and their compilers and C libraries.
BTW,
1) sprintf("%n %g", 1,1) also seg.faults
2) Did you have a true use case where the 8192 limit was an
undesirable limit?
Martin
vQ> sessionInfo()
vQ> # R version 2.10.0 Under development (unstable) (2009-04-20 r48365)
vQ> # i686-pc-linux-gnu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
I'm Pat Shields, one of the software engineers working on ParallelR. I just wanted to make two points: no R code or previously gpl'd code can be found in any of the non-gpl packages in ParallelR. I'm sure that the phrase "derived works" is a legally subtle one, but all these packages include are R and occasionally python scripts (as well as the standard text documentation). If these are derived works, doesn't that mean that any R code is also, by extension, required to be GPL'd? If not, is it including these scripts in a package that forces the use of the GPL? Also, I'm confused about your dimissal of the MCE example. If that code was a derivative work of R, how could it swap a GPL license for the BSD? I didn't think such a switch was possible. If it was, I'd imagine a lot more use of it, as a quick front project could make GPL software into BSD software after which all changes could go on behind closed doors. On Tue, Apr 21, 2009 at 7:38 PM, Matthew Dowle wrote: > Dear R-devel, > > REvolution appear to be offering ParallelR only when bundled with their R > Enterprise edition. As such it appears to be non-free and closed source. >http://www.revolution-computing.com/products/parallel-r.php > > Since R is GPL and not LGPL, is this a breach of the GPL ? > > Below is the "GPL and ParallelR" thread from their R forum. > > mdowle > It appears that ParallelR (packages foreach and iterators) is > only available bundled with the Enterprise edition. Since R is GPL, and > ParallelR is derived from R, should ParallelR not also be GPL? Regards, > Matthew > > revolution > Hello Matthew, ParallelR consists of both proprietary and GPL > packages. The randomForest and snow libraries GPL licensed, whereas the > other libraries we include have a commercial license(including 'foreach' and > 'iterators'). Stephen Weller > > revolution > I wanted to expand on Stephen's reply. ParallelR is a suite of > R packages, and it is well established that packages can be under a > difference license than R itself (i.e. not the GPL). For example, package > MCE is licensed under BSD, RColorBrewer is licensed under Apache, most of > Bioconductor is under the Artistic license and some are under completely > unique licenses (e.g. mclust). REvolution Computing developed all of the > code in ParallelR (except for the bundled GPL packages Stephen mentions), > and we decided to release it under our own license in REvolution R > Enterprise. > That said, we do already release components of parallelR, such as the > underlying engine, Networkspaces (also written by REvolution Computing) > under an open source licence. Also, we are likely to release some other > components including foreach and iterators, to CRAN soon. > David Smith > Director of Community, REvolution Computing > > mdowle > The examples you give (MCE, RColorBrewer, Bioconductor) are all > available for free including the source code. Their licenses have been > approved by the FSF. Free software and open source are the terms of work > derived from GPL licensed software. REvolution's packages 'foreach' and > 'iterators' are neither free or open source. Can you provide a precedent > for proprietary closed-source packages for R ? Is your policy approved by > the FSF ? > I don't object to REvolution. I am a fan of you making money from training > courses, consultancy, support and binaries. These are all permitted by the > GPL. However the GPL does not allow you to distribute work derived from R > which is either closed source or non-free. > R is GPL, not LGPL. > The above is my personal understanding. I am now posting to r-devel to > check, feel free to join the public debate there. > > Regards, Matthew > >[[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Pat Shields Software Engineer REvolution Computing One Century Tower | 265 Church Street, Suite 1006 New Haven, CT 06510 P: 203-777-7442 x250 | www.revolution-computing.com Check out our upcoming events schedule at www.revolution-computing.com/events [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
Patrick made all the points that I was going to make (thanks, Patrick), but I wanted to reinforce one point that may be the source of the confusion: ParallelR is not a modified version of R: ParallelR is a suite of ordinary R packages that run on top of the R engine like any other package. The R code and Python code in these packages were written entirely by REvolution Computing staff (including Patrick), and do not contain any code (derived or otherwise) from the R project. In retrospect, the name ParallelR may be somewhat confusing in this sense... # David Smith On Wed, Apr 22, 2009 at 7:40 AM, Patrick Shields wrote: > I'm Pat Shields, one of the software engineers working on ParallelR. I just > wanted to make two points: no R code or previously gpl'd code can be found > in any of the non-gpl packages in ParallelR. I'm sure that the phrase > "derived works" is a legally subtle one, but all these packages include are > R and occasionally python scripts (as well as the standard text > documentation). If these are derived works, doesn't that mean that any R > code is also, by extension, required to be GPL'd? If not, is it including > these scripts in a package that forces the use of the GPL? > > Also, I'm confused about your dimissal of the MCE example. If that code was > a derivative work of R, how could it swap a GPL license for the BSD? I > didn't think such a switch was possible. If it was, I'd imagine a lot more > use of it, as a quick front project could make GPL software into BSD > software after which all changes could go on behind closed doors. > > On Tue, Apr 21, 2009 at 7:38 PM, Matthew Dowle wrote: > >> Dear R-devel, >> >> REvolution appear to be offering ParallelR only when bundled with their R >> Enterprise edition. As such it appears to be non-free and closed source. >> http://www.revolution-computing.com/products/parallel-r.php >> >> Since R is GPL and not LGPL, is this a breach of the GPL ? >> >> Below is the "GPL and ParallelR" thread from their R forum. >> >> mdowle > It appears that ParallelR (packages foreach and iterators) is >> only available bundled with the Enterprise edition. Since R is GPL, and >> ParallelR is derived from R, should ParallelR not also be GPL? Regards, >> Matthew >> >> revolution > Hello Matthew, ParallelR consists of both proprietary and GPL >> packages. The randomForest and snow libraries GPL licensed, whereas the >> other libraries we include have a commercial license(including 'foreach' and >> 'iterators'). Stephen Weller >> >> revolution > I wanted to expand on Stephen's reply. ParallelR is a suite of >> R packages, and it is well established that packages can be under a >> difference license than R itself (i.e. not the GPL). For example, package >> MCE is licensed under BSD, RColorBrewer is licensed under Apache, most of >> Bioconductor is under the Artistic license and some are under completely >> unique licenses (e.g. mclust). REvolution Computing developed all of the >> code in ParallelR (except for the bundled GPL packages Stephen mentions), >> and we decided to release it under our own license in REvolution R >> Enterprise. >> That said, we do already release components of parallelR, such as the >> underlying engine, Networkspaces (also written by REvolution Computing) >> under an open source licence. Also, we are likely to release some other >> components including foreach and iterators, to CRAN soon. >> David Smith >> Director of Community, REvolution Computing >> >> mdowle > The examples you give (MCE, RColorBrewer, Bioconductor) are all >> available for free including the source code. Their licenses have been >> approved by the FSF. Free software and open source are the terms of work >> derived from GPL licensed software. REvolution's packages 'foreach' and >> 'iterators' are neither free or open source. Can you provide a precedent >> for proprietary closed-source packages for R ? Is your policy approved by >> the FSF ? >> I don't object to REvolution. I am a fan of you making money from training >> courses, consultancy, support and binaries. These are all permitted by the >> GPL. However the GPL does not allow you to distribute work derived from R >> which is either closed source or non-free. >> R is GPL, not LGPL. >> The above is my personal understanding. I am now posting to r-devel to >> check, feel free to join the public debate there. >> >> Regards, Matthew >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > > -- > Pat Shields > Software Engineer > REvolution Computing > One Century Tower | 265 Church Street, Suite 1006 > New Haven, CT 06510 > P: 203-777-7442 x250 | www.revolution-computing.com > > Check out our upcoming events schedule at > www.revolution-computing.com/events > > [[alternative HTML version deleted]] > > __ > R
[Rd] arima
Hi, I have a suggestion for the fonction arima and arima0. I think you should not call the constant an intercept because it creates confusion. It is not really an intercept but a mean. For an AR(1) the intercept mu should be defined as: X(t)=mu + phi X(t-1) + e(t) What you call intercept mu is rather defined as (X(t)-mu) = phi (X(t-1)-mu)) + e(t) which is not a common way to define an intercept. There is an error in the fGarch's predict() because of that. I think you should just be more explicit. thank you Pierre Chaussé economics department UQÀM __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] make fails when using with-x=no on linux CentOS 5.3 (PR#13670)
Full_Name: Nicolas Delhomme
Version: 2.9.0
OS: Linux CentOS release 5.3 kernel 2.6.18-128.el5 arch x86_64
Submission from: (NULL) (194.94.44.4)
Hi,
The commands I used to compile R2.9.0 on CentOS
./compile --with-x=no
make
This fails with the following message:
make[2]: Leaving directory `/home/delhomme/R-2.9.0/src/modules/vfonts'
make[1]: Leaving directory `/home/delhomme/R-2.9.0/src/modules/vfonts'
make[1]: Entering directory `/home/delhomme'
make[1]: *** No rule to make target `R'. Stop.
make[1]: Leaving directory `/home/delhomme'
make: *** [R] Error 1
What happens is the following:
In the Makefile located in the src/modules directory, there's a check for
R_MODULES (l.17-18)
## R_MODULES is X11 (or not)
MODULES = $(R_MODULES) internet lapack vfonts
This works fine, R_MODULES being defined and equal to an empty string.
Then in the R target (l.26-30)
R: Makefile make.internet make.lapack make.vfonts
@for d in "$(R_MODULES)"; do \
(cd $${d} && $(MAKE) $@) || exit 1; \
done
the R_MODULES is used again and since it is an empty string, it results in
doing
cd && make R, which means going to the home directory and executes the R target
of the Makefile there. Humm... since there's no makefile in my home dir, this
obviously breaks everything up.
The fix for that is to test wether R_MODULES is not an empty string. The
following corrects the problem:
R: Makefile make.internet make.lapack make.vfonts
@if test "$(R_MODULES)" != ""; then \
for d in "$(R_MODULES)"; do \
(cd $${d} && $(MAKE) $@) || exit 1; \
done; \
fi
Best,
Nicolas Delhomme
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
> Also, I'm confused about your dimissal of the MCE example. If that code was > a derivative work of R, how could it swap a GPL license for the BSD? I > didn't think such a switch was possible. If it was, I'd imagine a lot more > use of it, as a quick front project could make GPL software into BSD > software after which all changes could go on behind closed doors. And there are certainly many existing R packages with non-free/non-open licenses: http://cran.r-project.org/web/packages/ff/LICENSE http://cran.r-project.org/web/packages/minpack.lm/LICENSE http://cran.r-project.org/web/packages/rngwell19937/LICENSE http://cran.r-project.org/web/packages/SDDA/LICENSE ... Found with http://www.google.com/search?q=site:cran.r-project.org+cran+%22file+license%22 Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reversing xlim, ylim in smoothScatter
> "SG" == Shashikiran Ganesh > on Wed, 22 Apr 2009 17:16:09 +0530 (IST) writes: SG> Hello, SG> I have found that in smoothScatter it is not possible to reverse the axes plotted (R version 2.9.0) . It appears that this arises from the hard coding of xlim and ylim in smoothscatter.R in the lines : SG> x <- x[ xlim[1] <= x[,1] & x[,1] <=xlim[2], ] (line number 25) SG> and SG> x <- x[ ylim[1] <= x[,2] & x[,2] <= ylim[2], ] (line number 31) SG> This results in a x being NA if ylim[1] > ylim[2] which results in an error on executing SG> map <- grDevices:::.smoothScatterCalcDensity(x, nbin, bandwidth) SG> To counter this problem, I replaced the above two lines by : SG> x <-x [min(xlim) <= x[,1] & x[,1] <= max(xlim), ] SG> and SG> x <- x[min(ylim) <= x[,2] & x[,2] <= max(ylim), ] SG> and now smoothscatter reverses axes properly if xlim and/or ylim are provided with reversed ranges. SG> I am wondering if this would break something somewhere else or if there is a better way to reverse the axes. (I am a newbie in R programming although I have been using R for some astronomical plots and computations etc...) No, I don't think your proposed change could create problems, but to the contrary, I'd declare it as a simple bug fix, so it will be part of the next versions of R, thank you very much! Martin Maechler, ETH Zurich SG> Thanks in advance for your comments! SG> Shashi SG> -- SG> Shashikiran Ganesh SG> http://www.prl.res.in/~shashi SG> http://cosmicdiary.org/blogs/shashikiran_ganesh/ SG> Registered linux user number: 39542 (http://counter.li.org) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'is.integer' (PR#13671)
Full_Name: Mauricio Version: 2.9.0 (2009-04-17) OS: i486-pc-linux-gnu Submission from: (NULL) (193.205.203.3) This is a very simple function that seems not to be working, according to the definition given by '?is.integer'. I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't find any related message. The possible problem is: > is.integer(1) [1] FALSE and 1 is obviously an integer value. I would really appreciate if you could clarify if this is really a bug or not. Thanks in advance, Mauricio > version _ platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 9.0 year 2009 month 04 day17 svn rev48333 language R version.string R version 2.9.0 (2009-04-17) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'is.integer' (PR#13671)
On Wed, Apr 22, 2009 at 10:45 AM, wrote: > Full_Name: Mauricio > Version: 2.9.0 (2009-04-17) > OS: i486-pc-linux-gnu > Submission from: (NULL) (193.205.203.3) > > > This is a very simple function that seems not to be working, according to the > definition given by '?is.integer'. > > I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't > find any related message. > > The possible problem is: > > >> is.integer(1) > [1] FALSE > > and 1 is obviously an integer value. > Actually it's not: > typeof(1) [1] "double" So the command does work as the help describes. From ?is.integer() "is.integer returns TRUE or FALSE depending on whether its argument is of integer type or not, unless it is a factor when it returns FALSE." In the HTML help "type" is a link to the typeof() function. HTH Peter > > I would really appreciate if you could clarify if this is really a bug or not. > > Thanks in advance, > > Mauricio > >> version > _ > platform i486-pc-linux-gnu > arch i486 > os linux-gnu > system i486, linux-gnu > status > major 2 > minor 9.0 > year 2009 > month 04 > day 17 > svn rev 48333 > language R > version.string R version 2.9.0 (2009-04-17) > > __ > 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] 'is.integer' (PR#13671)
On Wed, 22 Apr 2009, hzambran.newsgro...@gmail.com wrote: Full_Name: Mauricio Version: 2.9.0 (2009-04-17) OS: i486-pc-linux-gnu Submission from: (NULL) (193.205.203.3) This is a very simple function that seems not to be working, according to the definition given by '?is.integer'. I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't find any related message. The possible problem is: is.integer(1) [1] FALSE and 1 is obviously an integer value. Obvious? You must know something I do not, as the protagonist of Zen and the Art of Motorcylce Maintenance would have pointed out. And if you do then it is not really obvious. is.double(1) [1] TRUE 1L _is_ an integer. is.integer(1L) [1] TRUE So this is not a bug. Please see the FAQ for advise on not posting non-bugs. Chuck I would really appreciate if you could clarify if this is really a bug or not. Thanks in advance, Mauricio version _ platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 9.0 year 2009 month 04 day17 svn rev48333 language R version.string R version 2.9.0 (2009-04-17) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:cbe...@tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo
This is a better way, it does two things
a) enclose the itemize environment in a flushleft environment - this
gives us much better line breaks for the verb.
b) does a replace of ";" with ";| \verb|" so that each "component" of
the locale gets enclosed in its own \verb command, which allows latex
to produce line breaks (since I am using gsub, I do gsub(";", ";| \\\
\verb", object$locale))
Below is a proposed utils:::toLatex.sessionInfo
I think it might make sense to have a locale argument, but I would
argue that the default ought to be TRUE.
Kasper
function (object, ...)
{
opkgver <- sapply(object$otherPkgs, function(x) x$Version)
nspkgver <- sapply(object$loadedOnly, function(x) x$Version)
z <- c("\\begin{flushleft}", "\\begin{itemize}", paste(" \\item
", object$R.version$version.string,
", \\verb|", object$R.version$platform, "|", sep = ""),
paste(" \\item Locale: \\verb|", gsub(";", ";| verb|",
object$locale), "|",
sep = ""), strwrap(paste("\\item Base packages:",
paste(sort(object$basePkgs), collapse = ", ")), indent = 2,
exdent = 4))
if (length(opkgver)) {
opkgver <- opkgver[sort(names(opkgver))]
z <- c(z, strwrap(paste(" \\item Other packages: ",
paste(names(opkgver), opkgver, sep = "~", collapse = ",
")),
indent = 2, exdent = 4))
}
if (length(nspkgver)) {
nspkgver <- nspkgver[sort(names(nspkgver))]
z <- c(z, strwrap(paste(" \\item Loaded via a namespace (and
not attached): ",
paste(names(nspkgver), nspkgver, sep = "~", collapse = ",
")),
indent = 2, exdent = 4))
}
z <- c(z, "\\end{itemize}", "\\end{flushleft}")
class(z) <- "Latex"
z
}
On Apr 22, 2009, at 1:50 , Martin Maechler wrote:
"TobiasV" == Tobias Verbeke
on Wed, 22 Apr 2009 09:57:30 +0200 writes:
TobiasV> Friedrich Leisch wrote:
On Tue, 21 Apr 2009 21:16:59 -0500,
Kevin W (KW) wrote:
The printing of the locale information from sessionInfo is not
very tidy.
Using toLatex(sessionInfo) pretty much guarantees "badness" from
breaking
the margin boundary (though my version of TeX no longer reports
such
errors). A random example is here:
http://cran.r-project.org/web/packages/Matrix/vignettes/Design-issues.pdf
I find the locale information unnecessary and right now I hack
this with
si = sessionInfo()
si$locale = "US"
toLatex(si)
I would like to be able to do something a bit cleaner, for example
sessionInfo(locale=FALSE)
For what it's worth, I don't think that early versions of
sessionInfo
printed information about the locale.
It went in on 2006-05-26, so it's bben there for some time now.
Discussion welcome.
I agree that it doesn't look nice in latex documents, but it is very
handy in bug reports.
Are there any objections if we add a locale argument to the
toLatex()
method and let that default to FALSE?
TobiasV> No objection although I would not be against
TobiasV> letting it default to TRUE to preserve current behaviour.
I agree with setting the default to keep the current behavior.
As Fritz mentioned, there situations where the locale
(information) is of quite some importance. As we know that
Sweave is used in quite a few circumstances with automatic
report generation, of which in *some* cases the locale may also
matter (and is desired to be visible),
I think we should not change the default behavior lightly
(apart from the extra spaces, see below).
TobiasV> One improvement in the locale information that would
make the LaTeX look
TobiasV> much nicer would be to add a space after the separator,
i.e.
TobiasV> item1; item2; item3
TobiasV> instead of
TobiasV> item1;item2;item3
TobiasV> That is for me more important than having the
TobiasV> option to include locale info or not
I agree very much; and indeed, adding the space after ";" is
trivial to achieve in the next version of toLatex()'s
"sessionInfo" method, as well.
Martin
TobiasV> as without such a change I found no way to prevent the
locale
TobiasV> information to run into the margin (and off the
TobiasV> page) of the resulting LaTeX document and that is
TobiasV> esthetically much more displeasing than the mere
TobiasV> presence of the locale information.
TobiasV> Best,
TobiasV> Tobias
__
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] wishlist: change default for units in print.object_size
I would like the default for units in print.object_size to be changed from "b" to "auto". Since this is just for the print method, it should not change any computations. Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'is.integer' (PR#13671)
> typeof(1) [1] "double" 1 is obviously *not* an integer value. Best, Josh -- http://quantemplation.blogspot.com http://www.fosstrading.com On Wed, Apr 22, 2009 at 12:45 PM, wrote: > Full_Name: Mauricio > Version: 2.9.0 (2009-04-17) > OS: i486-pc-linux-gnu > Submission from: (NULL) (193.205.203.3) > > > This is a very simple function that seems not to be working, according to the > definition given by '?is.integer'. > > I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't > find any related message. > > The possible problem is: > > >> is.integer(1) > [1] FALSE > > and 1 is obviously an integer value. > > > I would really appreciate if you could clarify if this is really a bug or not. > > Thanks in advance, > > Mauricio > >> version > _ > platform i486-pc-linux-gnu > arch i486 > os linux-gnu > system i486, linux-gnu > status > major 2 > minor 9.0 > year 2009 > month 04 > day 17 > svn rev 48333 > language R > version.string R version 2.9.0 (2009-04-17) > > __ > 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] 'is.integer' (PR#13671)
To the best of my knowledge this is not a bug. According to FAQ 3.3.3 "Numeric constants with no fractional and exponent (i.e., only integer) part are taken as integer in S-Plus 6.x or later, but as double in R." You can see it by invoking >storage.mode(1) [1] "double" Hence, if you really want to have integers, you need to use as.integer i.e. > storage.mode(as.integer(1)) [1] "integer" Cheers, Mathieu Le mercredi 22 avril 2009 à 19:45 +0200, hzambran.newsgro...@gmail.com a écrit : > Full_Name: Mauricio > Version: 2.9.0 (2009-04-17) > OS: i486-pc-linux-gnu > Submission from: (NULL) (193.205.203.3) > > > This is a very simple function that seems not to be working, according to the > definition given by '?is.integer'. > > I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't > find any related message. > > The possible problem is: > > > > is.integer(1) > [1] FALSE > > and 1 is obviously an integer value. > > > I would really appreciate if you could clarify if this is really a bug or not. > > Thanks in advance, > > Mauricio > > > version >_ > platform i486-pc-linux-gnu > arch i486 > os linux-gnu > system i486, linux-gnu > status > major 2 > minor 9.0 > year 2009 > month 04 > day17 > svn rev48333 > language R > version.string R version 2.9.0 (2009-04-17) > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'is.integer' (PR#13671)
Dear R experts, You are being a bit harsh on this user. He simply doesn't understand the distinction between "object of type integer" and "integer-valued object", which is actually fairly subtle. On Wed, Apr 22, 2009 at 1:45 PM, wrote: > This is a very simple function that seems not to be working, according to the > definition given by '?is.integer'. ... >> is.integer(1) > [1] FALSE > > and 1 is obviously an integer value. The is.integer function is correctly documented to check whether objects are of *type* integer, thus: is.integer( 1L ) => TRUE In R, objects of type integer are only created with literals of the form 999L; as the output of some functions when the input is integral (e.g. sort, unique, rev, ...); as the output of some functions which return index values or differences of index values (which, grep, rle, ...); and the output of a few other functions in certain cases (seq). Most numbers in R are floating-point numbers (type double), and determining whether their value is integral is rather subtle. For example, consider the vector 1+1000^-(1:6). In floating-point arithmetic, the first 5 values are distinguishable from the integer 1, but the 6th is not, though of course the *mathematical* number 1+1000^-6 is not integral. Now consider 1e40, which has the property that floor(x)==x==ceiling(x), which you might think characterizes an integer; but it also has the property that x+1 == x. Similarly for 1/3 * 1e40. In other words, it is really a rather subtle question whether a floating-point number "represents" an integer -s __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'is.integer' (PR#13671)
is.integer() is one of those functions with a name that can be confusing -- it looks at the underlying storage type of its argument (e.g., integer, floating point, character, etc.) not at the value stored in the argument. So, the type of behavior you see is this: > is.integer(1) [1] FALSE > is.integer(as.integer(1)) [1] TRUE > is.integer(as.integer(1) * 1.0) [1] FALSE > is.integer(as.integer(NA)) [1] TRUE > Careful reading of ?is.integer does tell you this, but I wouldn't accuse that help page of making such information blatantly obvious to new users of R. To test whether a value is an integer value, you can so something like this: > is.wholenumber <- function(x, tolerance = .Machine$double.eps^0.5) return(abs(x - round(x)) < tolerance) > is.wholenumber(1) [1] TRUE > is.wholenumber(seq(1,5,by=0.5)) [1] TRUE FALSE TRUE FALSE TRUE FALSE TRUE FALSE TRUE > The 'tolerance' part is to allow for minor deviations that might be due to floating point representation issues, e.g., on my computer 1/49 * 49 does not result in a value that is exactly equal to 1: > 1/49 * 49 - 1 [1] -1.110223e-16 > is.wholenumber(1/49 * 49) [1] TRUE > is.wholenumber(1/49 * 49, tol=0) [1] FALSE > -- Tony Plate hzambran.newsgro...@gmail.com wrote: Full_Name: Mauricio Version: 2.9.0 (2009-04-17) OS: i486-pc-linux-gnu Submission from: (NULL) (193.205.203.3) This is a very simple function that seems not to be working, according to the definition given by '?is.integer'. I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't find any related message. The possible problem is: is.integer(1) [1] FALSE and 1 is obviously an integer value. I would really appreciate if you could clarify if this is really a bug or not. Thanks in advance, Mauricio version _ platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major 2 minor 9.0 year 2009 month 04 day17 svn rev48333 language R version.string R version 2.9.0 (2009-04-17) __ 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
