RE: [Rd] delay() has been deprecated for 2.1.0
Thanks-- Luke Tierney's reply below is very helpful. 'makeActiveBinding' is brilliant and I'm pretty sure I can make it do just what I want. One question though: my first experiment with it was this makeActiveBinding( 'myAB', function( x) if( missing( x)) get( 'myABguts', env=.GlobalEnv) else assign( 'myABguts', x, .GlobalEnv), .GlobalEnv) exists( 'myAB') which appeared to return absolutely nothing-- not even a missing or a null. The problem, of course, is that 'myABguts' doesn't exist yet; what seems to happen, though, is that the failure to 'get' causes a *messageless* error inside the active binding function. Is this intended? I did think that class(env$x) != evalq( class( x), env) was a bit weird, but because it was useful to me, I wan't going to complain. Of course it's entirely true that reliance on the undocumented is dangerous and entirely my liability-- but even ___documented___ features in R have been know to come go a bit :) . Nowadays I just expect to be buffetted by the winds of change every so often... Mark -Original Message- From: Luke Tierney [mailto:[EMAIL PROTECTED] Sent: Sat 12/03/2005 3:03 PM To: Bravington, Mark (CMIS, Hobart) Cc: [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: RE: [Rd] delay() has been deprecated for 2.1.0 On Sat, 12 Mar 2005 [EMAIL PROTECTED] wrote: Uh-oh... I've just written a bunch of code for 'mvbutils' using 'delay', and am worried by the statement that there should be no way to see a promise:... object in R. At present, it's possible to check whether 'x' is a promise via e.g. 'class( .GlobalEnv$x)'. This will be different to 'class( x)' if 'x' is a promise, regardless of whether the promise has or has not been forced yet. This can be very useful; my recent code relies on it to check whether certain objects have been changed since last being saved. [These certain objects are originally assigned as promises to load from individual files. Read-accessing the object keeps it as class 'promise', whereas write-access creates a non-promise. Thus I can tell whether the individual files need re-saving when the entire workspace is saved.] Relying on undocumented features when designing a package is not a good idea. In this case the feature of env$x returning a promise contradicts the documentation and is therefore a bug (the documentation says that env$x should behave like the corresponding get() expression, and that forcec promises and returns their values). The has-it-changed test has been very valuable to me in allowing fast handling of large collections of large objects (which is why I've been adding this functionality to 'mvbutils'); and apart from is-it-still-a-promise, I can't think of any other R-level way of testing whether an object has been modified. [If there is another way, please let me know!] Is there any chance of retaining *some* R-level way of checking whether an object is a promise, both pre-forcing and post-forcing? (Not necessarily via the 'class( env$x)' method, if that's deemed objectionable.) This would not be a good idea. The current behavior of leaving an evaluated promise in place is also not a documented feature as far as I can see. It is a convenient way of implementing lazy evaluation in an interpreter but it has drawbacks. One is the cost of the extra dereference. Another is the fact that these promises keep alive their environments that might otherwise be inaccessible and hence available for GC. These environments might in turn reference large data structures, keeping them alive. At this point it seems too complicated to deal with this in the interpreter, but a compiler might be able to prove that a promise can be safely discarded. (In fact a compiler might be able to prove that a promise is not needed in the first place). There are other possible approaches that you might use, such as active bindings (see the help for makeActiveBinding). If that won't do we can look into developing a suitable abstraction that we can implement and document in a way that does not tie the hands of the internal implementation. Best, luke Mark Bravington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] on behalf of Duncan Murdoch Sent: Sat 12/03/2005 3:05 AM To: r-devel@stat.math.ethz.ch Cc: Gregory Warnes; David Brahm; Torsten Hothorn; Nagiza F. Samatova Subject: [Rd] delay() has been deprecated for 2.1.0 After a bunch of
Re: [Rd] CRAN Task Views: ctv package available
Dirk Eddelbuettel wrote: Paul, On 11 March 2005 at 17:55, Paul Gilbert wrote: | Achim | ... | Other things that might be useful are various programming views, like | a Matlab view, and an SPSS view. | | | I'm not sure what you have in mind here, because I would think that this | amounts more to using the language in general than using certain | packages. | ... | | I guess I didn't see that this should only be about packages. It seems | you could put just about anything in the HTML page. A table like | | MatlabR translation | --- | eye(n) diag(1,n) |=- | etc | | might be useful to a lot of people converting from Matlab. I may have | the above wrong, but I do have a good start on a table like this in a | sed script somewhere, so if anyone volunteers to be the maintainer I can | help a bit. Recall that (at least some of) this exists already in Robin's page at http://cran.us.r-project.org/doc/contrib/R-and-octave-2.txt (using the .us mirror here, adapt at will) Dirk Dirk Thanks for point this out. It is certainly a better starting point than anything I have related to Matlab. I think this also underlines the bigger problem too. There is actually a very large amount of R documentation, but it is often hard for someone with a particular background to know were to start. Even though I now know this document exists, it seems a bit difficult to actually find it from CRAN. If I Google R and Octave I get it immediately, but it doesn't show up with R and Matlab. It seems to me that the view idea may provide a very good mechanism that will work even when you really don't know where to start. (BTW, this is an example, I don't really know much about Matlab.) Paul __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] delay() has been deprecated for 2.1.0
On Sat, 12 Mar 2005 [EMAIL PROTECTED] wrote: Thanks-- Luke Tierney's reply below is very helpful. 'makeActiveBinding' is brilliant and I'm pretty sure I can make it do just what I want. One question though: my first experiment with it was this makeActiveBinding( 'myAB', function( x) if( missing( x)) get( 'myABguts', env=.GlobalEnv) else assign( 'myABguts', x, .GlobalEnv), .GlobalEnv) exists( 'myAB') which appeared to return absolutely nothing-- not even a missing or a null. The problem, of course, is that 'myABguts' doesn't exist yet; what seems to happen, though, is that the failure to 'get' causes a *messageless* error inside the active binding function. Is this intended? What I get is this: makeActiveBinding( 'myAB', function( x) if( missing( x)) get( 'myABguts', env=.GlobalEnv) else assign( 'myABguts', x, .GlobalEnv), .GlobalEnv) NULL Warning message: saved workspaces with active bindings may not work properly when loaded ... exists( 'myAB') Error in get(x, envir, mode, inherits) : variable myABguts was not found [We might want to get rid of the warning message at this point.] Currently exists() for active bindings calls the value function even if mode is any. Given that fact and your implementation the message makes sense to me, and you get the same message if you try to access the variable: myAB Error in get(x, envir, mode, inherits) : variable myABguts was not found You probably should write your function a bit more defensively. For ordinary bindings that contain promises from delayed evaluation exists() does not evaluate the promise for mode any, but does for other modes of course. The behavior of exists() for active bindings is bug. A quick look at the code suggests that it will be a bit tricky to fix, so I'm not sure it will get done before 2.1.0. Best, luke I did think that class(env$x) != evalq( class( x), env) was a bit weird, but because it was useful to me, I wan't going to complain. Of course it's entirely true that reliance on the undocumented is dangerous and entirely my liability-- but even ___documented___ features in R have been know to come go a bit :) . Nowadays I just expect to be buffetted by the winds of change every so often... Mark -Original Message- From: Luke Tierney [mailto:[EMAIL PROTECTED] Sent: Sat 12/03/2005 3:03 PM To: Bravington, Mark (CMIS, Hobart) Cc: [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: RE: [Rd] delay() has been deprecated for 2.1.0 On Sat, 12 Mar 2005 [EMAIL PROTECTED] wrote: Uh-oh... I've just written a bunch of code for 'mvbutils' using 'delay', and am worried by the statement that there should be no way to see a promise:... object in R. At present, it's possible to check whether 'x' is a promise via e.g. 'class( .GlobalEnv$x)'. This will be different to 'class( x)' if 'x' is a promise, regardless of whether the promise has or has not been forced yet. This can be very useful; my recent code relies on it to check whether certain objects have been changed since last being saved. [These certain objects are originally assigned as promises to load from individual files. Read-accessing the object keeps it as class 'promise', whereas write-access creates a non-promise. Thus I can tell whether the individual files need re-saving when the entire workspace is saved.] Relying on undocumented features when designing a package is not a good idea. In this case the feature of env$x returning a promise contradicts the documentation and is therefore a bug (the documentation says that env$x should behave like the corresponding get() expression, and that forcec promises and returns their values). The has-it-changed test has been very valuable to me in allowing fast handling of large collections of large objects (which is why I've been adding this functionality to 'mvbutils'); and apart from is-it-still-a-promise, I can't think of any other R-level way of testing whether an object has been modified. [If there is another way, please let me know!] Is there any chance of retaining *some* R-level way of checking whether an object is a promise, both pre-forcing and post-forcing? (Not necessarily via the 'class( env$x)' method, if that's deemed objectionable.) This would not be a good idea. The current behavior of leaving an evaluated promise in place is also not a documented feature as far as I can see. It is a convenient way of implementing lazy evaluation in an interpreter but it has drawbacks. One is the cost of the extra dereference. Another is the fact that these promises keep alive their environments that might otherwise be inaccessible and hence available for
RE: [Rd] CRAN Task Views: ctv package available
On Sat, 12 Mar 2005, Gorjanc Gregor wrote: Hello! First of all congratulations for a nice approach to present R fields in more coherent way. When I started with R I was often frustrated with long list of packages, similarities between them, ... If I would take a slow approach (one thing at a time) things would be easier from the start, but usually one wants to know what a new program is capable of. This is esential if one wants really to switch to R. About ctv: Paul Gilbert wrote: For my own purposes the Econometrics view is just fine, but I do sometimes get questions about dse from people in fields that are different enough that they might not even know to look in Econometrics. A time series view might be useful even if it only said see also ... . Another approach to this might be to have sub-views so, for example, Econometrics and Control theory could both point to Time series. Achim Zeileis responded: Yes, that is, of course, an obvious idea but it requires more coordination between the different views, hence we've decided not to support hierarchically ordered views. Re: ControlTheory. If someone would raise his hand and provide a view for that, it would be great. It could, of course, link to the Econometrics view (and vice versa) but they wouldn't have a formally defined subset in a TimeSeries view. I think that there is a lot of fields where this views cover the same stuff. When I first read about ctv I thought it will be implemented more in somewhat hierarchical or kind of multiple way, since for example linear models come usefull in many different fields and some people might never look under Econometrics view as Paul stated. I realize that hierarchical/multiple is far from easy and I do not have any clear idea how to implement it, but it would probably easier to maintain larger set of views in such a way and it would be easier to generate new ones. Yes, the implementation would not be the main problem, but the maintenance. For hierarchical views, there needs to be much more communication and coordination between the maintainers of related views. My idea was to keep the work low for the maintainers...hoping that there would be more people volunteering to maintain a view related to their field of research or application. Z -- Lep pozdrav / With regards, Gregor GORJANC --- University of Ljubljana Biotechnical FacultyURI: http://www.bfro.uni-lj.si/MR/ggorjan Zootechnical Department mail: gregor.gorjanc at bfro.uni-lj.si Groblje 3 tel: +386 (0)1 72 17 861 SI-1230 Domzale fax: +386 (0)1 72 17 888 Slovenia, Europe __ 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
Re: [Rd] unexpected behaviour of expression(sum())
On Friday 11 March 2005 13:13, Marc Schwartz wrote: On Fri, 2005-03-11 at 17:17 +, Prof Brian Ripley wrote: I see you have both a scalable font (the first) and size-specfic fonts. My guess is that the scalable font is not encoded in the same way as the others: can you track down where it is coming from? Otherwise my list on FC3 is the same as yours (minus the duplicates, which are also puzzling). I have also just checked Exceed, which has the same list plus scalable fonts (and also has -adobe-symbol-0-0-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-0-0-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-sun-fontspecific which caused problems for 2.0.1 with getting bold symbols in some sizes, hence the second bug fix I mentioned). As a wild guess, do you have a font server as well as local fonts? I don't think so. My XF86Config-4 file has the line FontPathunix/:7100 # local font server but I don't see any font server package actually installed, and I get deepayan $ xfsinfo -server localhost:7100 xfsinfo: unable to open server localhost:7100 . I do have fontconfig (and a bunch of fonts all over the place), which may explain the duplicates. [...] Deepayan, which X server is being used? FC3 (fully updated) is using xorg 6.8.1 if that might make a difference. I'm using Debian testing, the version of X being 4.3.0.dfsg.1-10 (4.3.0 with some modifications). But this is not the issue, since things work fine on another Debian system with the same version of X. It turns out that the problem is with the gsfonts-x11 package. After removing it, I get the correct symbols (with a warning message): expr = expression(sum(x, 1, n)) plot(1, main = expr, type = n) text(1, 1, expr) Warning message: X11 used font size 8 when 9 was requested There's still a bug, but probably not in R. The only external indication I can get that something is wrong is when I compare $ xfd -fn -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific and $ xfd -fn -adobe-symbol-medium-r-normal--0-0-100-100-p-107-adobe-fontspecific The second one claims to display -urw-standard symbols l-medium-r-normal--17-120-100-100-p-89-adobe-fontspecific and in fact does *not* have the summation symbol. (Screenshots at http://www.stat.wisc.edu/~deepayan/R/xfd-fixed.png and http://www.stat.wisc.edu/~deepayan/R/xfd-scalable.png ). However, the file /usr/X11R6/lib/X11/fonts/Type1/fonts.dir has the line s05l.pfb -urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific which suggests that the actual font used is s05l.pfb, and a font editor shows that it does contain the summation symbol (U+2211). Deepayan __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Incorrect calculation of loop in R.2.0.1 (PR#7724)
Full_Name: Ms. Drakes Version: 2.01 OS: Windows XP Submission from: (NULL) (4.237.32.239) file=C:/glob.csv glob=read.csv(file,header=T) y=glob$Temperature z=max(y[1:40]) # this has a probability of exceedance of 1/41 # now you can check how this does in the 2nd sample - sum=0 for i = 41:100 if (zy[i]sum=sum+1 sum sum=sum/60 sum error: the loop i=41:100 does not work correctly, only if information after if is enclosed in parentheses __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incorrect calculation of loop in R.2.0.1 (PR#7724)
[EMAIL PROTECTED] writes: Full_Name: Ms. Drakes Version: 2.01 2.0.1, I guess- OS: Windows XP Submission from: (NULL) (4.237.32.239) file=C:/glob.csv glob=read.csv(file,header=T) y=glob$Temperature z=max(y[1:40]) # this has a probability of exceedance of 1/41 # now you can check how this does in the 2nd sample - sum=0 for i = 41:100 if (zy[i]sum=sum+1 That's not how you specify a for loop in R. Please read up on the syntax, e.g. in An Introduction to R sum sum=sum/60 sum error: the loop i=41:100 does not work correctly, only if information after if is enclosed in parentheses It is not a bug in R that your program does not work correctly. Please do not abuse the bug report system like that. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behaviour of expression(sum())
So my guess on scalable fonts was right. I suspect this is a problem in how the X server is using Type1 fonts, specifically in how it thinks they are encoded. This is why I asked about the locale: \summation is \345 in the Adobe symbol character set and \circleplus is \305 which is a u/case to l/case difference in Latin-1. I now recall Kurt had similar problems with gsfonts-x11 last August: Kurt has found a problem with the last two pages of demo(plotmath) on X11 (some symbols either wrong or missing completely). We found the issue seems to be that gsfonts-x11 has aliases -adobe-symbol-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific -urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific -urw-standard symbols l-regular-r-normal--0-0-0-0-p-0-adobe-fontspecific - urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific Any way to ensure that these fonts are not taken by us? I don't think so, for if I understand that the alias file is lying about encodings. We specifically added -adobe-symbol to overcome problems with abi symbol fonts at ETHZ, but if that package says the urw fonts in `standard symbols l' are in adobe symbol and they are not, you are in trouble. Brian On Sat, 12 Mar 2005, Deepayan Sarkar wrote: On Friday 11 March 2005 13:13, Marc Schwartz wrote: On Fri, 2005-03-11 at 17:17 +, Prof Brian Ripley wrote: I see you have both a scalable font (the first) and size-specfic fonts. My guess is that the scalable font is not encoded in the same way as the others: can you track down where it is coming from? Otherwise my list on FC3 is the same as yours (minus the duplicates, which are also puzzling). I have also just checked Exceed, which has the same list plus scalable fonts (and also has -adobe-symbol-0-0-normal--0-0-0-0-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-0-0-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-100-100-p-0-sun-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-adobe-fontspecific -adobe-symbol-0-0-normal--0-0-75-75-p-0-sun-fontspecific which caused problems for 2.0.1 with getting bold symbols in some sizes, hence the second bug fix I mentioned). As a wild guess, do you have a font server as well as local fonts? I don't think so. My XF86Config-4 file has the line FontPathunix/:7100 # local font server but I don't see any font server package actually installed, and I get deepayan $ xfsinfo -server localhost:7100 xfsinfo: unable to open server localhost:7100 . I do have fontconfig (and a bunch of fonts all over the place), which may explain the duplicates. [...] Deepayan, which X server is being used? FC3 (fully updated) is using xorg 6.8.1 if that might make a difference. I'm using Debian testing, the version of X being 4.3.0.dfsg.1-10 (4.3.0 with some modifications). But this is not the issue, since things work fine on another Debian system with the same version of X. It turns out that the problem is with the gsfonts-x11 package. After removing it, I get the correct symbols (with a warning message): expr = expression(sum(x, 1, n)) plot(1, main = expr, type = n) text(1, 1, expr) Warning message: X11 used font size 8 when 9 was requested There's still a bug, but probably not in R. The only external indication I can get that something is wrong is when I compare $ xfd -fn -adobe-symbol-medium-r-normal--20-140-100-100-p-107-adobe-fontspecific and $ xfd -fn -adobe-symbol-medium-r-normal--0-0-100-100-p-107-adobe-fontspecific The second one claims to display -urw-standard symbols l-medium-r-normal--17-120-100-100-p-89-adobe-fontspecific and in fact does *not* have the summation symbol. (Screenshots at http://www.stat.wisc.edu/~deepayan/R/xfd-fixed.png and http://www.stat.wisc.edu/~deepayan/R/xfd-scalable.png ). However, the file /usr/X11R6/lib/X11/fonts/Type1/fonts.dir has the line s05l.pfb -urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-adobe-fontspecific which suggests that the actual font used is s05l.pfb, and a font editor shows that it does contain the summation symbol (U+2211). Deepayan -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
