Re: [Rd] Windows/7706 (PR#7889)
[EMAIL PROTECTED] wrote: With 2.1 on Windows XP SP2 (32 bit) I also get no title in a png plot, so I can reproduce this bug. R is installed from pre-built binary. No title appears when I run this: png(foo.png) plot(1:10, main = foo) dev.off() The jpeg device behaves as expected: jpeg(foo.jpg) plot(1:10, main = foo) dev.off() Thoughts on this? It looks like http://r-bugs.biostat.ku.dk/cgi-bin/R/Windows?id=7706 Cheers, -Andy R version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major2 minor1.0 year 2005 month04 day 18 language R I can't reproduce this bug (work as expected) on my system: Windows XP SP2 US with: version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major2 minor1.0 year 2005 month04 day 18 language R So, similar config as yours???!!! Best, Philippe Grosjean __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Internationalizing the Rcmdr package?
Hello John and Peter (and all), Yes, it is probably better to use the same method as R uses, with po files and gettext(). We are currently translating R in French and it takes one hour or two to figure out how to do these translations with, let's say, poedit. We would not like to deal with different exotic translation files for different additonal packages. I volunteer to translate RCmdr in French. You know it will be very useful for my students. You are certainly better to ask Brian Ripley directly for details on how to implement this. However, may I suggest you first look at the code and the ./po subdirectory of base and recommended packages of the R 2.1.x version (for instance, source of base, graphics, or packages in the VR bundle -class, MASS, nnet spatial-) to get an idea of changes introduced for internationalization. Best, Philippe ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Pentagone (3D08) ( ( ( ( (Academie Universitaire Wallonie-Bruxelles ) ) ) ) ) 8, av du Champ de Mars, 7000 Mons, Belgium ( ( ( ( ( ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.30.54 ( ( ( ( (email: [EMAIL PROTECTED] ) ) ) ) ) ( ( ( ( (web: http://www.umh.ac.be/~econum ) ) ) ) ) http://www.sciviews.org ( ( ( ( ( .. Peter Dalgaard wrote: John Fox [EMAIL PROTECTED] writes: Dear R-devel list members, I'm considering adding support for other languages than English to the Rcmdr package. I understand that the use of Tcl/Tk by the Rcmdr package means I won't be able to make full use of the internationalization facilities in R 2.1.0. I'm interested, therefore, in whether the following, more limited, strategy (which bears some similarity to the internationalization facilities in R) seems reasonable or whether there's a better approach. As well, I'm interested in whether the proposed approach is sufficiently flexible to be worthwhile -- does it cover enough languages? It would be simple for me to provide a file of messages, labels, and other text used by the Rcmdr, organizing this file with one message per line. A copy of the file, named, e.g., messages.francais, could contain translations into another language (e.g, French). Setting options(Rcmdr=list(language=francais)) would then activate translation when the Rcmdr starts up, reading the messages file into a data frame, treating the English text as row names. The messages could be handled by a function, say Text(), which would return English or translated text, as appropriate. Some experimentation shows that message retrieval by this scheme is essentially instantaneous even when there are several thousand relatively long messages in the data frame. Offhand, I think you're better off latching on to an existing mechanism. Tcl has something known as msgcat, which appears to be similar to GNU gettext (and there are conversion tools), or perhaps you could interface to gettext itself (we do have the gettext() function at the R level). Two tricky bits: (A) shortcut keys, which need to be coordinated to menu items (Accept/Break/Cancel translates to Accepter/Afbryd/Annuller in Danish - if you're a little malicious, anyway) (B) What is the general mechanism for extending message catalogs by an R package? Brian may well have thought of this stuff already. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with limmaGUI (PR#7877)
Hello, The first error message is the kind of error that appears due to some changes in grep() and the like in R 2.1.0 and when they are used to test some string issued from Tcl (limmaGUI uses tcltk, isn't it?) I have the same kind of errors with SciViews and have to adjust the code to make it fully compatible with R 2.1.0. I would recommend to contact the package maintainer and ask for an update for version 2.1.0 of R. In the meantime, you should continue to use R 2.0.1 with limmaGUI, if you really need the GUI. Best, Philippe Grosjean ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Pentagone (3D08) ( ( ( ( (Academie Universitaire Wallonie-Bruxelles ) ) ) ) ) 8, av du Champ de Mars, 7000 Mons, Belgium ( ( ( ( ( ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.30.54 ( ( ( ( (email: [EMAIL PROTECTED] ) ) ) ) ) ( ( ( ( (web: http://www.umh.ac.be/~econum ) ) ) ) ) http://www.sciviews.org ( ( ( ( ( .. [EMAIL PROTECTED] wrote: Full_Name: Edoardo Giacopuzzi Version: 2.0.1 OS: Windows XP Home Submission from: (NULL) (80.181.65.157) I have some problem with this new version of R GUI. I've used limmaGUI package with an older version of R and it works perfectlly, but now with the last version R 2.0.1.0 two error boxs appear every time I try to launch this package: 1. Error in list.files(path, pattern, all.files, full.names, recursive): regular expressione 'pattern' not valid 2. Error in try(expr, TRUE): oggetto source.files not found The package correctly load the grapich interface anyway, but I've experimented some problems when I try to load my .gpr files for analysis: the program often crash! Thanks. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] French translation of R
Hello all, I have just started a translation of R into French. Any help from the French-speaking part of the R community would be very appreciated (translation, or proof-reading)! Best, Philippe Grosjean ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Pentagone (3D08) ( ( ( ( (Academie Universitaire Wallonie-Bruxelles ) ) ) ) ) 8, av du Champ de Mars, 7000 Mons, Belgium ( ( ( ( ( ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.30.54 ( ( ( ( (email: [EMAIL PROTECTED] ) ) ) ) ) ( ( ( ( (web: http://www.umh.ac.be/~econum ) ) ) ) ) http://www.sciviews.org ( ( ( ( ( .. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Different package versions on CRAN?
Hello, I am making changes to some of my packages that are exposed in CRAN. Some changes make them incompatible with previous R versions [and I use Depends: R (= 2.1.0)]. I suspect that, as soon as I will upload this new version to CRAN, it will replace the old one _everywhere_? However, the previous version of these packages remains perfectly usable with R 1.9.X or 2.0.X. So, will this break the binaries in /windows/contrib/1.9|2.0, or will the latest valid binaries of my packages remain there, not updated? To put it another way, for a package Mypack with version 1.0-1 compatible with all R versions, when I upload Mypack version 2.0-0 compatible only with R 2.1.0, what will be the result on CRAN regarding Windows binaires? 1°) /windows/contrib/2.1/Mypack_2.0-0.zip /windows/contrib/2.0/Mypack_1.0-1.zip # Not updated /windows/contrib/1.9/ # Idem for all other subdirs or 2°) /windows/contrib/2.1/Mypack_2.0-0.zip ??? error ??? because CRAN tries to update the package for other subdirectories and encounters Depends: R (= 2.1.0) ??? Thanks, Philippe ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Pentagone (3D08) ( ( ( ( (Academie Universitaire Wallonie-Bruxelles ) ) ) ) ) 8, av du Champ de Mars, 7000 Mons, Belgium ( ( ( ( ( ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.30.54 ( ( ( ( (email: [EMAIL PROTECTED] ) ) ) ) ) ( ( ( ( (web: http://www.umh.ac.be/~econum ) ) ) ) ) http://www.sciviews.org ( ( ( ( ( .. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Custom installer [was: Version names]
Hello, The discussion about version names leads me to the following question (sorry, I change the message title): Is it possible to enforce the user to select an option during R installation? For instance, I want R to be installed with the registry entry option set up and, let's say, with tcltk files installed. How do I ensure this? Well, under Windows, Inno Setup that is used as the installer is plenty of resources for that! You have lots of command line arguments, including /SAVEINF and LOADINF/ that use a custom information file about the options. Then, you can run the setup silently with /SP-, /SILENT or /VERYSILENT from the command line, thus, from a batch script. Ultimately, it is possible to write an installer that will install R with several options, with additional packages, etc... very easily without having to rebuid the original R installer. You need both the rw.exe installer (about 23Mb), and your custom installer (let's say with a couple of additional packages, weighting a few hundreds of kb) downloaded in the same directory. You run your custom installer, which in turn installs R silently with the right options (it even can detect if R is already installed or not). There is a real interest for this approach for projects like R Commander, or SciViews-R. Indeed, it targets beginners and installation should be as straigthforward as possible. Currently, you have to (1) install R (2) with specific options, (3) install additional packages, and (4) switch Rgui in SDI mode under Windows... before you can start working in R Commander or SciViews-R. Definitely too many tasks for a beginner! So, I will experiment a little bit with Inno Setup in this direction and intend to propose a web page about this topic, for Windows. Now, my two questions: 1) Does anyone has some experience using Inno Setup this way? 2) How to solve the problem of custom installation this way under Linux/Unix? [with a batch script, I presume, but does somebody have a skeleton for that: installing R with specific options + several additional packages at once]. Thanks, Philippe Grosjean ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons-Hainaut University, Pentagone ( ( ( ( (Academie Universitaire Wallonie-Bruxelles ) ) ) ) ) 6, av du Champ de Mars, 7000 Mons, Belgium ( ( ( ( ( ) ) ) ) ) phone: + 32.65.37.34.97, fax: + 32.65.37.33.12 ( ( ( ( (email: [EMAIL PROTECTED] ) ) ) ) ) ( ( ( ( (web: http://www.umh.ac.be/~econum ) ) ) ) ) .. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabor Grothendieck Sent: Monday, November 29, 2004 3:12 AM To: [EMAIL PROTECTED] Subject: Re: [Rd] Version names Gabor Grothendieck ggrothendieck at myway.com writes: Simon Urbanek simon.urbanek at math.uni-augsburg.de writes: : If all you want to do is to determine the current (most recently : installed) R version, then all it takes is two lines of C code [just : read one registry entry] - and it's at least as portable across Windows : systems as a batch script, but far more flexible. (There may even be a : way to get that info w/o coding at all - I'm not sure whether regedit : has any batch mode or something ...). I don't think regedit has a batch mode. e.g. regedit /? does not give help. I looked into a bit more and some of this information is actually in the FAQ: 2.15 Does R use the Registry? Not itself. The installers set some entries to allow uninstallation. In addition (by default, but this can be de-selected) they set a Registry key LOCAL_MACHINE\Software\R-core\R giving the version and install path. Again, this is not used by R itself, but it will be used by the DCOM interface (http://cran.r-project.org/other-software.html). Finally, a file association for extension .RData is set in the Registry. You can add the Registry entries by running RSetReg.exe in the bin folder, and remove them by running this with argument /U. Note that the settings are all per machine and not per user, and that this neither sets up nor removes the file associations. Also it seems that one uses reg.exe rather than regedit.exe from batch files so putting all this together we get the following Windows XP batch statement to get the current path to the rw folder. It puts the path into the Rrw variable: for /f tokens=2* %%a in ( 'reg query hklm\software\r-core\r /v InstallPath') do set Rrw=%%b The bad news is that this is not 100% guaranteed to work since, as mentioned above, the user can deselect modification of the registry during installation but its certainly more than sufficient
RE: [Rd] Lazy loading - importance of NAMESPACE
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Prof
Brian Ripley
Sent: Sunday, October 17, 2004 7:11 PM
To: Philippe Grosjean
Cc: [EMAIL PROTECTED]
Subject: Re: [Rd] Lazy loading - importance of NAMESPACE
I think you are leaping to a conclusion from a single
example. Lots of things have changed in 2.0.0 and you are
repeatedly attributing symptoms to lazy loading without any
real evidence.
I have tested several hundred examples with and without lazy
loading, and I have seen no dramatic changes caused by lazy
loading. I have seen dramatic changes caused by the way the
DESCRIPTION file is interpreted, and I did stress the
importance of getting that right.
This is because I changed nothing in DESCRIPTION between the two, in my
case. But you are right, I don't have your experience, and I barely
understand the new loading mechanism... thus the reason of several messages
I send to r-help, recently.
I attributed this to lazy loading because it is the major change from R
1.9.1 to R 2.0.0... But again, you are right that other changes were
introduced.
It remains that, without namespace, my package loaded about 30 times slower
than with it. It would be interesting to know why, don't you think so?
Best,
Philippe Grosjean
On Sun, 17 Oct 2004, Philippe Grosjean wrote:
Hello all,
Following a question in r-help, where I was wondering why my large
package with lots of Depends: did load so slowly (almost
30 sec in
lazy loading in R 2.0.0 under Win XP, for 3.4 sec in R 1.9.1 on the
same machine), I discovered that a correct namespace changes
everything: with the namespace added, loading of my package
drops to
circa 1 sec, which is more that three times faster than in R 1.9.1
without lazy loading,... and about 30 times faster than
without the namespace in R 2.0.0!
You are not comparing like with like, AFAICS. In 1.9.1 you
were not loading all the dependent packages. In 2.0.0 you
were. If you add a NAMESPACE, nothing changed. If you
replace Depends: by Imports: you don't need to initialize all
the dependent packages, and that may well save you a lot of
time (for example there is no search for and cacheing of S4 methods).
But none of this has anything whatsoever to do with lazy loading!
First of all, congratulation for implementing lazy loading!
Second, I look in the documentation, and in the Brian
Ripley's article
in R News 2/2004, and I found nowhere a place where the
importance of
namespace is stressed for lazy loading (although Brian
Ripley explains
in several places differences in lazy loading with and without
namespace). I think it is something important and, unless I
miss it in
the documentation, it would be useful to tell somewhere that a
namespace is strongly recommended in conjonction with lazy
loading...
Finally, a question:
From R News 2/2004 p. 30: a 'Imports:' field for packages whose
namespaces
are used but do not need to be attached. OK, functions in these
namespaces are available to me, without attaching the package.
They are not. They are available to functions in your
package's namespace.
Now, if I need to attach
these packages at a later time because I will use some of their
functions from the command line, then, is this package
referred twice
(once in my package environment, once attached to the
search path)? If
yes, what is the drawback in term of ressources and speed
('Imports'
versus 'Depends', both in loading, and in use of such a package)?
That makes no sense to me. A package should be named in
either Imports or Depends and not both. For you to access
it, you need to call library(). That does not load another
copy of the namespace, and the total amount of work is
essentially the same as if you called library() on it before
your own package (which is what Depends; will do). Does that
answer the question you mean to ask?
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] tkStartGUI fails under RW1091 (PR#7101)
Peter, I think it should be possible to find a different solution to completelly replace the R console by a Tcl/Tk console. The basic idea is to redirect inputs and outputs of the R console in Rgui (SDI mode), and then hide R console itself, thus without touching to the event loop(s). There are some parts of such an implementation in John Fox's Rcmdr (redirection of output to a Tcl/Tk window), and for the input (it is the way SciViews-R communicates with external programs, but in this case, it is the Tcl/Tk window that is hidden, not the original R console). Indeed, I just reworked some code in the air for a simple code editor in tcltk (you present it in your R-news paper about tcltk, isn't it). Moreover, under Windows, the program that spawns a console can specify different channels for input, output and error before spawning the console (this works with Rterm only, of course). I use this in the SciViews R plug. Indeed, R is driven by the R plug in --ess mode by redirecting input, output and error to pipes. Under Windows NT/2000/XP, it is possible to specify named pipes. Those are very convenient, because they can be handled as files, including through the net. However, Windows 9X/Me/Millenium can only connect to existing named pipes, but cannot create new ones. So, a solution that works with any Windows platform should not use names pipes. This is a different approach we could use. However, in this case, the solution would be Windows-specific, I imagine. So, it means we would end up with a different mechanisms under Unix/Linux, and under Windows. Please, note that in both solutions, I have code capable to interrupt calculation in R. I think this is a required feature, but it is not easy to implement with all mechanisms. I plan to replace totally my Visual Basic code by platform-independent code in SciViews in the future. Using a Tcl/Tk console window may be a solution, so I *may* further develop the concept. However, I am still looking at potentially interesting alternatives, like James Wettenhall's wxPython, or some improved Tcl/Tk solution based on your tcltk package, supplemented with Tile and other supplemental widgets (I find the basic Tk widgets too limited to implement the GUI I want to build with them). Best, Philippe ...?})) ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean \ ___ ) \/ECO\ ( Numerical Ecology of Aquatic Systems /\___/ ) Mons-Hainaut University, Pentagone / ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium /NUM\/ ) \___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12 \ ) email: [EMAIL PROTECTED] ) ) ) ) ) SciViews project coordinator (http://www.sciviews.org) ( ( ( ( ( ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Dalgaard Sent: Monday, 26 July, 2004 07:26 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Rd] tkStartGUI fails under RW1091 (PR#7101) [EMAIL PROTECTED] writes: library(tcltk) tkStartGUI() Error in .C(RTcl_ActivateConsole, PACKAGE = tcltk) : C function name not in DLL for package tcltk Yes. The source code for that function sits inside #ifndef Win32, so it's hardly a bug, except that the documentation might be clearer (or the R wrapper could throw a more explicit error). The whole thing is quite experimental, on Unix too -- really just a proof of concept thing at present. The fundamental issue is that the way Tk takes over R's event loop involves redefining ptr_R_ReadConsole and friends. This is quite Unix-specific and the relevant declarations are lifted from src/unix/devUI.h. I don't know what the equivalent would be on Windows (a platform I use reluctantly myself), and I kind of suspect that it can only work from Rterm, not Rgui. Contributions from knowledgeable Windows programmers would be welcome. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Copyright issues question
OK, thank you for those precisions on JGR license... For me, the more code will be GPL, the better! Have a nice day, Philippe -Original Message- From: Simon Urbanek [mailto:[EMAIL PROTECTED] Sent: Sunday, 20 June, 2004 04:03 To: Philippe Grosjean Cc: [EMAIL PROTECTED]@stat.math.ethz.ch Subject: Re: [Rd] Copyright issues question On Jun 16, 2004, at 12:08 PM, Philippe Grosjean wrote: P.S.: I am also concerned about JGR, because it is also not GPL. Any comment? All C code in JGR is GPL. Tha Java parts talking to R directly (JavaGD, Rengine) are, too. From what you posted here this seems to be sufficient. As of the other Java code, well, that is a good question - I guess we have two purely practical reasons for not-GPLing it ATM: one is that we have to check whether we're allowed to do so and the other is that we still want to incorporate some major changes until the official release (I'm not that much worried about the GUI itself but the other parts). I'm sure the licensing issue will be sorted out before the official release. A side note: with xGD and a slightly modifiied JRI it is possible to use *any* (incl. commercial) application with R as backend (as it's even now legally possible with Rserve), so I don't think this is an issue anyway (at least for JGR). Cheers, Simon __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Copyright issues question
Thanks all for your answer, As the maintainer of the R GUI Projects web page I will continue to place a link to all software that do not obviously enfringes GPL, that is, RExcel, RxlCommander or JGR. Best, Philippe Grosjean __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Copyright issues question
Eric Lecoutre [EMAIL PROTECTED] writes: What sort of exact problems can we expect to have? Should we consider to propose this as Open Source and not GPL? Do we have to obtain the agreement of the R Core Team? Thomas Lumley answered: It might also be worth pointing out that the R Core Team's agreement is neither necessary nor sufficient. The GPL permits whatever it permits, and R as it stands is covered by the GPL, rather than by what the developers would like on a case-by-case basis. -thomas OK, that is probably true. However, in GPL 2, you have: 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. I think I must clarify the context here. I already think about copyright aspects since a while, as the maintainer of the R GUI Projects web site. Indeed, I think several programs violate GPL, because they place a different (G)UI on top of R, and claim for a different, incompatible license. Recently, I have reworked a little bit the R GUI Projects web site in such a way that I eliminated links, and send mails to authors of obviously offending programs, namely, Brodgar and Statistical Lab. You find no link to these programs any more in R GUI Projects. I hope thay will resolve the conflicts as soon as possible. However, there are other programs whose status is not clear for me. I think that GUIs and Plugins are derivatives and the contaminent character of GPL applies to them. The following quote from the document pointed by Peter Dalgaard, reinforces my conviction (http://www.soberit.hut.fi/~msvalima/gpl_derivative.pdf, p. 12): 4.4 Plug-Ins and Device Drivers Consider next a situation where one develops a plug-in or device driver to a program under GPL. Is such a plug-in a derivative work of the main program and, hence, under GPL? FSF FAQ answers with an interpretation criteria based on substance and form. It states: If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single pro- gram, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL . Of course, it is lawyers that decide, not me, or us!!! However, I am wondering if the status of any plugin extension to commercial software like Excel with GPL programs is valid. I think about RxlCommander, but also, RExcel. In a sense, these programs are totally against the GPL philosophy. Basically, we provide to a commercial software (Microsoft Excel), new functionnalities that derive from a GPL work (R). It is clear that, if people at Microsoft developped these plugins, they would be havily blamed. Now, if someone else write and distribute them... what does it changes? The result is still the same: to use GPL software (R) to provide additionnal features to a commercial software (Microsoft Excel), and the later could possibly benefit from these additionnal features to reinforce its dominancy (let's consider the speculative situation where R versus Excel plugins are so much appreciated and used that they have a siginificant impact in the future). This is potentially a serious breach in the GPL philosophy that allows, indirectly, to reuse features from a GPL program to supplement a commercial one. Philosophically speaking, I am against such a practice. However, this is, and should remain my own opinion... Now, what about legal aspects here? Best, Philippe Grosjean P.S.: I am also concerned about JGR, because it is also not GPL. Any comment? ...?})) ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean \ ___ ) \/ECO\ ( Numerical Ecology of Aquatic Systems /\___/ ) Mons-Hainaut University, Pentagone / ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium /NUM\/ ) \___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12 \ ) email: [EMAIL PROTECTED] ) ) ) ) ) SciViews project coordinator (http://www.sciviews.org) ( ( ( ( ( ... __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] SciViews package for a GUI layer in R?
Hello, R-help got the first annonce of SciViews-R [An alpha version (unstable, still in development) of SciViews-R can be downloaded from http://www.sciviews.org/SciViews-R. See also screenshots at http://www.sciviews.org/software/rconsole.htm, etc.] We think it should be nice if the various GUI projects for R adopted some common (or similar) features that would be intercompatible between these projects. One way to do that is through a R package that implements those common features in pure R code. The SciViews package is a preliminary attempt in this direction. We also propose some extensions that are useful for GUIs: look at copy, export, view and report functions, for instance. A manual explain it in more details (ftp://ftp.umh.ac.be/pub/ftp_econum/Manual.pdf). Any comments? Best, Philippe Grosjean ...°})) ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean \ ___ ) \/ECO\ ( Numerical Ecology of Aquatic Systems /\___/ ) Mons-Hainaut University, Pentagone / ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium /NUM\/ ) \___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12 \ ) email: [EMAIL PROTECTED] ) ) ) ) ) SciViews project coordinator (http://www.sciviews.org) ( ( ( ( ( ... __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Script editor for Windows GUI
Chris Jackson wrote: I've been using the graphapp stuff that's already there, which is out of date, and not very tidy or flexible, but it does this (simple) job. CodeMax sounds nice for code editing, but wouldn't there be a problem with using proprietary tools to develop R? I see they allow you to freely redistribute the DLL with an application you develop using it. But anyone who wanted to hack on the resulting application would need to buy a licence, so I wouldn't see R developers accepting this. Oooops! They change the license!!! Indeed, I use a derivation of CodeMax v. 2, which is called CodeSense (http://www.ticz.com/homes/users/nlewis/). The license of both CodeMax v. 2 and CodeSense state royalty-free license both for development and applications (with CodeSense, it is also explicitly stated that the code source of the control can be used, modified and redistributed royalty-free). Here is an extract of the license of CodeSense 2.22 which derives from CodeMax 2: [...] CodeMax License Agreement This is a legal agreement between you, the end user, and WinMain Software. By using this software, you are agreeing to accept ownership of this product and to be bound by the terms of this agreement. WinMain Software License for CodeMax: Grant of License. WinMain Software grants a limited, non-exclusive license to use unlimited copies of the custom control called CodeMax for the purpose of developing applications for the Windows environment. Runtime Distribution License. WinMain Software grants you a royalty-free right to distribute copies of the runtime dynamic link libraries for use with applications you have developed using CodeMax. [...] I wonder what happens there. I suppose CodeSense, which still keeps this royalty-free license would be the way to go... but a discussion with its developer with certainly be worthwhile. What I know be experience: CodeMax or CodeSense saves your days, if not weeks of development because it is neat, efficient and feature-rich. Best, Philippe ...°})) ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean \ ___ ) \/ECO\ ( Numerical Ecology of Aquatic Systems /\___/ ) Mons-Hainaut University, Pentagone / ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium /NUM\/ ) \___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12 \ ) email: [EMAIL PROTECTED] ) ) ) ) ) SciViews project coordinator (http://www.sciviews.org) ( ( ( ( ( ... __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Power (^) 10x slower in R since version 1.7.1... What next?
Did the MingGW folks consider the simple solution of simply rounding the
return result when the inputs are integers?
-G
It seems this is the problem, rounding... because some fast algorithms
return wrong integers, but acceptable reals (given the precision). Also, it
seems that most of the decrease in performance is due to checking of
overflow and so on. Recent Intel processors (and certainly many others)
provide fast instructions for some usual mathematical functions, but they
are not used in MingW (any more), because they do not meet standards for
precision and error checking (note that I am not a specialist at all, that
is my understanding after searching on the net about it).
So, as I understand, it is possible to compute much much faster, but with
less security than in the current MingW version. However, people at MingW
priviledge precise and secure calculation at the expense of performance (to
meet standards).
There are certainly a few occasions in statistics (where the highest
precision in calculation often does not matter) when faster, but less
precise algorithms would be better... That is why I dream about a fastmath
R package to propose a faster alternative to ^, exp(), cos(),... When there
a factor ten in speed increase for ^, this is probably worthwhile. However,
this can only be a dream for me, since I cannot do it myself. I wonder if
someone else would be interested. In this case, http://www.willus.com/mingw/
could be probably a starting point.
Best,
Philippe Grosjean
-Original Message-
From: Philippe Grosjean [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 10:50 AM
To: [EMAIL PROTECTED]
Subject: [Rd] Power (^) 10x slower in R since version 1.7.1... What
next?
OK, I have made a little search about this problem that
apparently occurs
only on Windows platform... (but I am sure most of you are
already aware of
it): the slow down is due to the adoption of a different
algorithm for pow
in mingw 3.x. This is motivated by some other changes in
mingw. Here is a
quote of Danny Smith that did this change:
When mingw changed default FPU settings from 53-bit mantissa
to 64 bit mantisa, the dll-provided pow function no longer
returned integral values when both operands were integral.
Now, I don't
think that is a requiremnet of the standard but every other pow
implementation I looked at did that. So I changed to a well-tested
pow function (from the Cepehes math library) that did. As
you found out
it is expensive.
I have written another pow function that use exp2 and log2 library
functions
rather than the polynomial expansion used by Cephes package.
It seems to
be
accurarte enough (except when the result of pow is near 1.0 (eg,
pow(1.1, 0.9))
and is as fast as the msvcrt.dll version. I still need to
tweak for cass
near range boundaries.
The other alternative is to write a wrapper for the wrapper
for the dll
pow,
to fix up the special cases when both args are integral.
That doesn't add
to
much overhead.
Danny
Since pow is much, much slower in mingw 3.x than in mingw
2.x, other people
started to search for a solution. I found this interesting enough:
http://www.willus.com/mingw/ (look at Some Fast Math
Functions at the end
of the page).
Thus here, there are two possibilities: to match the
standards and provide
full-proof math functions, like it is done in current mingw (and in R,
consequently)... but sacrificing speed. Or, to rely to online
assembler that
uses Pentium or Athlon fast calculation potentials (but with
less checking
of errors) like Willus proposes.
I think at this point, it should be the user's choice. So, R
should propose
both and should allow to switch from one to the other easily. Any
suggestion? (one idea: make a fastmath package that would
provide faster,
but less error-proof ^, exp(), cos(), sin(),... functions).
Unfortunately, I
am not fluent enough in C and assembler to do it myself.
Best,
Philippe Grosjean
...](({°...°}))..
.
) ) ) ) )
( ( ( ( ( Dr. Philippe Grosjean
) ) ) ) )
( ( ( ( ( LOV, UMR 7093
) ) ) ) ) Station Zoologique
( ( ( ( ( Observatoire Océanologique
) ) ) ) ) BP 28
( ( ( ( ( 06234 Villefranche sur mer cedex
) ) ) ) ) France
( ( ( ( (
) ) ) ) ) tel: +33.4.93.76.38.16, fax: +33.4.93.76.38.34
( ( ( ( (
) ) ) ) ) e-mail: [EMAIL PROTECTED]
( ( ( ( ( SciViews project coordinator (http://www.sciviews.org)
) ) ) ) )
..
.
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Power (^) 10x slower in R since version 1.7.1... What next? [Windows platform]
Prof Brian Ripley wrote: Your subject line is seriously misleading: this is not `in R' but rather in the pre-compiled binary of R on one OS (Windows) against one particular runtime (which was actually changed long before R 1.7.1). OK, I have not tested on other platforms... However, this is also in R as a consequence, as soon as R is compiled against the slower routines [in Windows only] You could not do this by an `R package': that cannot change the runtime code in use. You (or someone else) could build R against an alternative runtime library system, but it might be easier to use a better OS. I compile my own version of R 1.8.0 against MingW 2.0.1 for this reason... and I really agree with you: it might be easier to use a better OS. However, you should first convince the hundreds of people I target with my R code. Those are biologists, ecologists, oceanographers,... and most of them use Windows, not Linux/Unix. So, I am forced to use Windows myself. I have yet to see any real statistics application in which this made any noticeable difference. With modern processors one is talking about 10x faster than a few milliseconds unless the datasets are going to take many seconds even to load into R. If you have such an application (a real example where ^ takes more than say 20% of the total time of the statistical analysis, and the total time is minutes) please share it. Here it is: I am working with very large datasets of zooplankton, containing among others, results from image analyses on each individual. It is very common in biology to transform/recode/calculate (or whatever you call it) raw data according to precalibrated allometric relationships. Those have the general form of Huxley's equation: y = a.x^b Now, you see what I mean: I have to transform about 17 measurements this way for each individual in my multi-million entries dataset (note that I do not compute the whole dataset at once), before using methods like LDA, learning vector quantization (actually, your code from the VR bundle), or random forest. In this case, especially with lda or lvq, which are pretty fast, it really makes the difference in term of minutes in my PIV 2.8 Ghz with 1 Gb memory... and Windows XP. OK, I can understand that the R-core team does not have time to waste on this problem, especially because they use a better OS. However, I know a lot of people (the ones that will use my code to analyze their own zooplankton series) that would benefit my own faster-MingW 2.0-compiled R 1.8.0 Windows version, or a better solution. So what? Do I have to distribute it myself? Do I have to spot this problem in my benchmark test at http://www.sciviews.org/other/benchmark.htm (25.7 sec for the whole test with R 1.8.0 from CRAN against 11.9 sec for R 1.8.0 compiled with MingW 2.0.1 under Windows on the same computer)? I have not updated it since R version 1.7.0 to avoid publishing such a bad result. And I have not posted my own compiled R version online, because it is neither a good practice, nor a good solution... I am looking for a better solution. Best, Philippe Grosjean __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Power (^) 10x slower in R since version 1.7.1... What next? [Windows platform]
Prof Brian Ripley wrote: Why not use exp(y*log(x)) if it is adequate for your purposes? It is faster under Windows. I will try... Thank you for your advice. There really is no value in using millions of cases in LVQ or LDA or, I suspect, random forests. But a difference of a few minutes means that this is well under 20% of the total time unless your statistical analysis is very much speedier than mine. No, sorry, the millions of cases are predictions made according to a training set build around circa 2,000 items. I have a prediction rate with a method that combines lvq, lda and random forest of about 5,000 items / sec, which is, roughly, 3 to 4 minutes for 1,000,000 items plus the time to load the dataset, it is a little bit less than 9 minutes... but more than the double with that slow ^. Ok, what is 10 minutes in a lifetime ;-) On Tue, 18 Nov 2003, Philippe Grosjean wrote: Prof Brian Ripley wrote: Your subject line is seriously misleading: this is not `in R' but rather in the pre-compiled binary of R on one OS (Windows) against one particular runtime (which was actually changed long before R 1.7.1). OK, I have not tested on other platforms... However, this is also in R as a consequence, as soon as R is compiled against the slower routines [in Windows only] You could not do this by an `R package': that cannot change the runtime code in use. You (or someone else) could build R against an alternative runtime library system, but it might be easier to use a better OS. I compile my own version of R 1.8.0 against MingW 2.0.1 for this reason... and I really agree with you: it might be easier to use a better OS. However, you should first convince the hundreds of people I target with my R code. Those are biologists, ecologists, oceanographers,... and most of them use Windows, not Linux/Unix. So, I am forced to use Windows myself. I have yet to see any real statistics application in which this made any noticeable difference. With modern processors one is talking about 10x faster than a few milliseconds unless the datasets are going to take many seconds even to load into R. If you have such an application (a real example where ^ takes more than say 20% of the total time of the statistical analysis, and the total time is minutes) please share it. Here it is: I am working with very large datasets of zooplankton, containing among others, results from image analyses on each individual. It is very common in biology to transform/recode/calculate (or whatever you call it) raw data according to precalibrated allometric relationships. Those have the general form of Huxley's equation: y = a.x^b Now, you see what I mean: I have to transform about 17 measurements this way for each individual in my multi-million entries dataset (note that I do not compute the whole dataset at once), before using methods like LDA, learning vector quantization (actually, your code from the VR bundle), or random forest. In this case, especially with lda or lvq, which are pretty fast, it really makes the difference in term of minutes in my PIV 2.8 Ghz with 1 Gb memory... and Windows XP. OK, I can understand that the R-core team does not have time to waste on this problem, especially because they use a better OS. However, I know a lot of people (the ones that will use my code to analyze their own zooplankton series) that would benefit my own faster-MingW 2.0-compiled R 1.8.0 Windows version, or a better solution. So what? Do I have to distribute it myself? Do I have to spot this problem in my benchmark test at http://www.sciviews.org/other/benchmark.htm (25.7 sec for the whole test with R 1.8.0 from CRAN against 11.9 sec for R 1.8.0 compiled with MingW 2.0.1 under Windows on the same computer)? I have not updated it since R version 1.7.0 to avoid publishing such a bad result. And I have not posted my own compiled R version online, because it is neither a good practice, nor a good solution... I am looking for a better solution. Best, Philippe Grosjean -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Power (^) 10x slower in R since version 1.7.1... What next?[Windows platform]
Prof. Brian Ripley wrote: Why not use exp(y*log(x)) if it is adequate for your purposes? It is faster under Windows. With the CRAN version of R 1.8.0 under Win Xp: system.time(exp(3.45*log(runif(100 [1] 1.30 0.06 1.49 NA NA system.time(runif(100)^3.45) [1] 7.14 0.03 7.20 NA NA With R compiled using MingW 2.0.1 on the same machine: system.time(exp(3.45*log(runif(100 [1] 1.31 0.02 1.35 NA NA system.time(runif(100)^3.45) [1] 1.04 0.00 1.04 NA NA OK, this is fine for me. I define: %^% - function(a, b) return(exp(b*log(a))) which I use as a substitute for ^ to make sure performance does not drop too much under Windows with the current CRAN version of R in my application. Thanks, Philippe Grosjean __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] Power (^) 10x slower in R since version 1.7.1... What next?
OK, I have made a little search about this problem that apparently occurs
only on Windows platform... (but I am sure most of you are already aware of
it): the slow down is due to the adoption of a different algorithm for pow
in mingw 3.x. This is motivated by some other changes in mingw. Here is a
quote of Danny Smith that did this change:
When mingw changed default FPU settings from 53-bit mantissa
to 64 bit mantisa, the dll-provided pow function no longer
returned integral values when both operands were integral. Now, I don't
think that is a requiremnet of the standard but every other pow
implementation I looked at did that. So I changed to a well-tested
pow function (from the Cepehes math library) that did. As you found out
it is expensive.
I have written another pow function that use exp2 and log2 library
functions
rather than the polynomial expansion used by Cephes package. It seems to
be
accurarte enough (except when the result of pow is near 1.0 (eg,
pow(1.1, 0.9))
and is as fast as the msvcrt.dll version. I still need to tweak for cass
near range boundaries.
The other alternative is to write a wrapper for the wrapper for the dll
pow,
to fix up the special cases when both args are integral. That doesn't add
to
much overhead.
Danny
Since pow is much, much slower in mingw 3.x than in mingw 2.x, other people
started to search for a solution. I found this interesting enough:
http://www.willus.com/mingw/ (look at Some Fast Math Functions at the end
of the page).
Thus here, there are two possibilities: to match the standards and provide
full-proof math functions, like it is done in current mingw (and in R,
consequently)... but sacrificing speed. Or, to rely to online assembler that
uses Pentium or Athlon fast calculation potentials (but with less checking
of errors) like Willus proposes.
I think at this point, it should be the user's choice. So, R should propose
both and should allow to switch from one to the other easily. Any
suggestion? (one idea: make a fastmath package that would provide faster,
but less error-proof ^, exp(), cos(), sin(),... functions). Unfortunately, I
am not fluent enough in C and assembler to do it myself.
Best,
Philippe Grosjean
...](({°...°}))...
) ) ) ) )
( ( ( ( ( Dr. Philippe Grosjean
) ) ) ) )
( ( ( ( ( LOV, UMR 7093
) ) ) ) ) Station Zoologique
( ( ( ( ( Observatoire Océanologique
) ) ) ) ) BP 28
( ( ( ( ( 06234 Villefranche sur mer cedex
) ) ) ) ) France
( ( ( ( (
) ) ) ) ) tel: +33.4.93.76.38.16, fax: +33.4.93.76.38.34
( ( ( ( (
) ) ) ) ) e-mail: [EMAIL PROTECTED]
( ( ( ( ( SciViews project coordinator (http://www.sciviews.org)
) ) ) ) )
...
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] RE: [R] ^ operation much slower in R 1.7.1 than in R 1.7.0 ???
OK. Now I have compiled R 1.7.1 myself on my Windows XP pro computer with
the recommended tools and MingW 2.0.0-3.
Here is what I got:
a - abs(matrix(rnorm(800*800)/2, ncol=800, nrow=800))
system.time(b - a^1000)[3]
R 1.7.0: 1.00 sec
R 1.7.1 (from CRAN): 4.59 sec
R 1.7.1 (custom) : 0.99 sec
phi - 1.6180339887498949
a - floor(runif(75)*1000)
system.time(b - (phi^a - (-phi)^(-a))/sqrt(5))[3]
R 1.7.0: 0.90 sec
R 1.7.1 (from CRAN): 11.80 sec
R 1.7.1 (custom) : 1.08 sec
It seems thus that the problem originates in the Windows compilation of the
CRAN version of R 1.7.1. We will wait Duncan Murdoch for some more
explanation. I cannot place the custom rw1071.exe on my web site because it
is too large (almost 22 Mb). For the moment, you should recompile from
source by yourself to get top speed in R 1.7.1.
Best,
Philippe Grosjean
...](({°...°}))...
) ) ) ) )
( ( ( ( ( Dr. Philippe Grosjean
) ) ) ) )
( ( ( ( ( LOV, UMR 7093
) ) ) ) ) Station Zoologique
( ( ( ( ( Observatoire Océanologique
) ) ) ) ) BP 28
( ( ( ( ( 06234 Villefranche sur mer cedex
) ) ) ) ) France
( ( ( ( (
) ) ) ) ) tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
) ) ) ) ) e-mail: [EMAIL PROTECTED]
( ( ( ( ( SciViews project coordinator (http://www.sciviews.org)
) ) ) ) )
...
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] RE: [R] ^ operation much slower in R 1.7.1 than in R 1.7.0???
All R versions from 1.0 to 1.7.0 did a similar job here (of course, the computer and OS matters, but considering relative results). And suddenly 1.7.1 is 5 to 10 times slower than all previous versions! This is not just a question of 10 sec. I am not the kind of people to say, booarf! What's those 10 sec in my life? I am the kind of people to ask questions when such thing happens. OK, I did not checked for accuracy (and I hope 'make check-all' did some test for me). I do not know about this miraculous new algorithm that is so accurate that it is worth performing the calculation 5 to 10 times slower than the previous one. Sorry for my ignorance. Philippe Grosjean -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: mardi 5 aout 2003 1:07 To: Philippe Grosjean Cc: [EMAIL PROTECTED] Subject: RE: [Rd] RE: [R] ^ operation much slower in R 1.7.1 than in R 1.7.0 ??? On Tue, 5 Aug 2003, Philippe Grosjean wrote: OK. Now I have compiled R 1.7.1 myself on my Windows XP pro computer with the recommended tools and MingW 2.0.0-3. Here is what I got: a - abs(matrix(rnorm(800*800)/2, ncol=800, nrow=800)) system.time(b - a^1000)[3] R 1.7.0: 1.00 sec R 1.7.1 (from CRAN): 4.59 sec R 1.7.1 (custom) : 0.99 sec phi - 1.6180339887498949 a - floor(runif(75)*1000) system.time(b - (phi^a - (-phi)^(-a))/sqrt(5))[3] R 1.7.0: 0.90 sec R 1.7.1 (from CRAN): 11.80 sec R 1.7.1 (custom) : 1.08 sec It seems thus that the problem originates in the Windows compilation of the For whom is this a `problem'? A lot more than 10 secs has been spent on this thread. CRAN version of R 1.7.1. We will wait Duncan Murdoch for some more explanation. I cannot place the custom rw1071.exe on my web site because it is too large (almost 22 Mb). For the moment, you should recompile from source by yourself to get top speed in R 1.7.1. *On this one operation*: we don't know that others may be faster or more accurate on the CRAN version, nor how different chips compare. You too have not told us exactly what setup you used, and FWIW when I compile 1.7.0 myself I get the slow speed (using MinGW 3.0.0 rc3). I suspect the difference is due to the use of a later version of mingw-runtime, and that the later routines are slower but more accurate. (Looks like mingw-runtime-2.2 used pow from msvcrt.dll, and -2.4/-3.0 have their own: 2002-10-07 Danny Smith [EMAIL PROTECTED] * mingwex/math/pow.c: New file. He presumably had good reasons for doing that.) Your conclusion seems unsubstantiated by your evidence. Something like `if you are using Windows and ^ dominates the timings of your code, you may want to try re-compiling using mingw-runtime-2.2' seems the only valid conclusion. -- 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 __ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
[Rd] RE: [R] ^ operation much slower in R 1.7.1 than in R 1.7.0 ???
I propose to move this thread to R-devel...
Prof. Brian Ripley wrote:
And are you able to give an explanation? For example, did you compile
each under the same compiler system?
I just noticed that behaviour yesterday, and had not much time yet to
investigate it. I compiled 1.7.0 myself (but compared with the binary
provided on CRAN; no changes). I used the 1.7.1 binary provided on CRAN. I
know these binaries are not supported, so we (Windows users) will have to
look at that by ourselve. Indeed yes, I'll first compile 1.7.1 with the same
compiler I used for 1.7.0.
I doubt if this is worth R-core's time to pursue, so over to interested
users to find an explanation and fix.
OK. But I was wondering if people at R-core team, especially those who
worked on Windows specific aspects, would have in mind some changes they did
between 1.7.0 and 1.7.1 than can cause this. Since these changes are mainly
corrections of bugs, the list is hopefully not so long... and it could help
a lot to have these hints. Thanks very much.
Best,
Philippe Grosjean
...](({?...?}))...
) ) ) ) )
( ( ( ( ( Dr. Philippe Grosjean
) ) ) ) )
( ( ( ( ( LOV, UMR 7093
) ) ) ) ) Station Zoologique
( ( ( ( ( Observatoire Oceanologique
) ) ) ) ) BP 28
( ( ( ( ( 06234 Villefranche sur mer cedex
) ) ) ) ) France
( ( ( ( (
) ) ) ) ) tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
) ) ) ) ) e-mail: [EMAIL PROTECTED]
( ( ( ( ( SciViews project coordinator (http://www.sciviews.org)
) ) ) ) )
...
On Mon, 4 Aug 2003, James MacDonald wrote:
I get similar results as Philippe on WinXP (1.33 GHz laptop, 512 Mb
RAM).
R 1.7.1
2.86 sec
7.82 sec
R 1.7.0
0.64 sec
1.64 sec
Jim
James W. MacDonald
Affymetrix and cDNA Microarray Core
University of Michigan Cancer Center
1500 E. Medical Center Drive
7410 CCGC
Ann Arbor MI 48109
734-647-5623
Peter Dalgaard BSA [EMAIL PROTECTED] 08/04/03 11:30AM
Philippe Grosjean [EMAIL PROTECTED] writes:
I do not understand what happens here (under Win XP):
a - abs(matrix(rnorm(800*800)/2, ncol=800, nrow=800))
system.time(b - a^1000)[3]
took about 1 sec on my computer with R 1.7.0 and it takes now 4.59
sec with
R 1.7.1
Similarly,
phi - 1.6180339887498949
a - floor(runif(75)*1000)
system.time(b - (phi^a - (-phi)^(-a))/sqrt(5))[3]
took about 0.9 sec with R 1.7.0, and it takes 11.8 sec (!!!) in R
1.7.1.
Are there some changes made between 1.7.0 and 1.7.1 that could cause
such a
large difference in time to do such simple computations???
Hmm, on linux, I get approx 0.31 for the first example with 1.7.0,
1.7.1, r-patched, and r-devel. Similarly, I get 0.8 for the second ex.
in all four cases.
--
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
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-help
__
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Re: [R] Who to decide what a generic function should look like?
Henrik Bengtsson wrote:
For me a generic function should be fully generic in the sense that
there are no requirements of arguments agreement (and therefore it
should not be documented as a reply to Smyth's thread).
Duncan Murdoch answered:
I don't agree. A generic function has a meaning. Often that meaning
is expressed in terms of certain arguments. If a user of an unknown
object knows that it supports the generic, they have a right to expect
it to behave according to the standard meaning of the generic.
I agree with both of you. I mean, a generic function has a meaning, and
probably some associated arguments... but it should apply to various
situations where very different arguments could be required. The strength of
generic functions is to tailor a specific action to the context. For
instance, the user wants to get the best plot for an object... even if he
does not know what the best plot is for it, he just call plot(object) and
get the result!
To obtain that, one need a certain liberty in defining the plot() generic
function. Thus, the ... argument is critical here. I dont know much about
S4/methods (I still use old system), but I am pretty happy with this
implementation of generic functions in S-PLUS / R.
Best,
Philippe Grosjean
...](({?...?}))...
) ) ) ) )
( ( ( ( ( Dr. Philippe Grosjean
) ) ) ) )
( ( ( ( ( LOV, UMR 7093
) ) ) ) ) Station Zoologique
( ( ( ( ( Observatoire Oceanologique
) ) ) ) ) BP 28
( ( ( ( ( 06234 Villefranche sur mer cedex
) ) ) ) ) France
( ( ( ( (
) ) ) ) ) tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
) ) ) ) ) e-mail: [EMAIL PROTECTED]
( ( ( ( ( SciViews project coordinator (http://www.sciviews.org)
) ) ) ) )
...
__
[EMAIL PROTECTED] mailing list
http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Undocumented bahavior of as.integer() (PR#2430)
The problem is that it can lead to bugs in code using X[y] with y being a
vector of doubles, and these bugs are very difficult to track. It is teach
to R users that they do not need to bother too much about the storage mode.
For instance, in the 'Introduction to R' manual, p.8:
For most purposes the user will not be concerned if the numbers in a
numeric vector are integers, reals or even complex. Internally calculations
are done as double precision real numbers, or double precision complex
numbers if the input data are complex.
This is correct: for _most_ purposes. A language that manages type
conversion automatically is nice, but it is fair also to place warnings
where there are exceptions to those _most_ purposes. That is why I
consider a warning is required... An example to illustrate it should be
useful too (but perhaps more useful in Extract.Rd than in as.integer.Rd).
Something like:
ind - 10 * 73.1 + (10 * seq(14)) - 76)
ind
mat - seq(1420)
submat1 - mat[ind]# NOT what I expected
submat2 - mat[round(ind)] # much better
which is derived from Tom Blackwell's example discussed on R-help a few days
ago.
Best,
Philippe
-Original Message-
From: Martin Maechler [mailto:[EMAIL PROTECTED]]
Sent: mercredi 8 janvier 2003 11:50
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Rd] Undocumented bahavior of as.integer() (PR#2430)
PhGr == Philippe Grosjean [EMAIL PROTECTED]
on Wed, 8 Jan 2003 11:24:40 +0100 (MET) writes:
PhGr as.integer() truncates doubles toward zero, as Splus
PhGr does (at least v. 6.1 under Windows does). Thus:
(fortunately this is not OS dependent!)
look - (10 * seq(14)) - 76
10 * (73.1 + look)
PhGr[1] 71 171 271 371 491 586 681 791 886 981 1101 1201 1301
1401
as.integer(10 * (73.1 + look))
PhGr[1] 70 170 270 370 490 586 681 791 886 981 1101 1201 1301
1401
PhGr ... It is not documented in R! I propose appending the following
to
PhGr as.integer.Rd:
I agree the doc should mention it.
I disagree with the warning section.
In R, our code really just uses something like
int asInt(double x) { return x; }
which makes use of C's implicit casting.
I know looked in Kernighan Ritchie (2nd Ed.; {3rd Ed would be better})
and found (p.197)
A6.3 Integer and Floating
When a value of floating type is converted to integral type,
the fractional part is discarded. ...
Hence this is (fortunately!) part of the C standard.
But I really think any decent programming language would do it
like that (many would not allow implicit coercion though..).
That's the reason I think the warning is not necessary; I'd
rather mention it by the way.
PhGr \section{ WARNING }{ During coercion of doubles, real
PhGr numbers are not rounded but truncated (the closest
PhGr integer towards zero is returned). Attributes are
PhGr deleted.}
PhGr And I suggest adding the previous exemple in the
PhGr corresponding section in as.integer.Rd. Moreover, the
PhGr subset operation [] uses as.integer() and
PhGr consequently, can suffer from the same syndrome. A
PhGr WARNING section in Extract.Rd would be welcome too.
suffer and syndrome are not appropriate here IMHO.
Martin Maechler [EMAIL PROTECTED]http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228
__
[EMAIL PROTECTED] mailing list
http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] rounding errors in max.col()
Prof. Brian Ripley wrote: Do read the help page: Ties are broken at random. The determination of ``tie'' assumes that the entries are probabilities. and then don't blame your tools when you misuse them Yes, I did read this. So, I know why items are randomly selected in case of `ties'. But then, I reformulate the question: what are the criteria for deciding two values are `ties' in max.col? I know, the answer is certainly somewhere (at least in the code), however, if someone knows it, it would help save time. Thanks, Philippe Grosjean On Thu, 2 Jan 2003, Philippe Grosjean wrote: I suppose this is a general behavior with external function calls, so I do not post (yet) a specific bug report. Could someone explain this? a - rep(1, 20) + rnorm(20, mean=0.1, sd=0.0001) b - embed(a, 3) # I want to know where the item in column 2 is greated than both col 1 and 3 (peak) test1 - max.col(b) == 2 # ... or I could use a less optimal code test2 - apply(b, 1, max) == b[, 2] any(test1 != test2) # both are equivalent # but when numbers are very close a - rep(1, 20) + rnorm(20, mean=0.001, sd=0.001) b - embed(a, 3) test1 - max.col(b) == 2 test2 - apply(b, 1, max) == b[, 2] any(test1 != test2) # tests are now DIFFERENT! # Indeed, test2 is correct, and test1 suffers from wrong calculations due probably to rounding errors in max.col() No, to max.col working as documented. [Large waste of bandwidth deleted] -- 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 __ [EMAIL PROTECTED] mailing list http://www.stat.math.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
