Re: [Rd] savePlot() no longer automatically adds an extension to the filename.
If asked, this user would agree with Simon, for the several reasons he stated. There is much to be said for consistency (across platforms and functions) and stability (across versions) in software. MHP Simon Urbanek wrote on 6/3/2008 10:36 PM: On Jun 3, 2008, at 8:40 PM, Duncan Murdoch wrote: On 03/06/2008 2:35 PM, Mike Prager wrote: S Ellison [EMAIL PROTECTED] wrote: Plaintive squeak: Why the change? Some OS's and desktops use the extension, so forgetting it causes trouble. The new default filename keeps a filetype (as before) but the user now has to type a filetype twice (once as the type, once as extension) to get the same effect fo rtheir own filenames. And the extension isn't then checked for consistency with valid file types, so it can be mistyped and saved with no warning. Hard to see the advantage of doing away with it... Just for the record. . . This change broke a *lot* of my code, including code used by others. Windows depends on file extensions. Fortunately, fixes using getRversion are not too difficult. Then you'll be happy to hear that Steve put together a patch and it's already committed, so it should make it into 2.7.1. The patch adds the extension if there's no dot in the name, leaves the filename as-is if it sees one. So this should be compatible with the majority of uses, only messing up cases where people really don't want an extension (now they'll have to add a dot at the end of their filename), or where they want an automatic one, but have another dot in the name. AFAICS the savePlot() behavior is now (as of r45830) inconsistent across platforms due to the patch (r458229). The inconsistency is IMHO a bad thing - you shouldn't expect the same function to behave differently across platforms. I'd strongly recommend against this change for several reasons: it changes the behavior of the function between 2.7.0 and 2.7.1, so that now you have to special-case three different versions (pre 2.7.0, 2.7.0 and 2.7.1), there is now no way to specify a file without a dot (which is quite common in non-Windows world) and the behavior is incompatible with other similar functions. I think the change of behavior in 2.7.0 was deliberate and in favor of consistency, because a filename specification should not be randomly mangled by the function (I have made that mistake myself before, so I know the pitfalls ;)). Extension is part of the filename, it's not a separate concept (also note that .foo is a valid filename that doesn't have an extension). The argument about typos is moot since you can always define functions like saveFoo - function(prefix) savePlot(filename = paste(prefix, foo, sep=.), type=foo) At any rate I don't see how this can realistically be part of 2.7.1 since it's not a bugfix and it changes the meaning of a function parameter. (And I usually don't mind disguising small features as bugfixes ;P) Whether the change in 2.7.0 could be done differently (e.g. using another parameter for a full file name) is a different story, but I suspect that it should have been discussed before the 2.7.0 release... Cheers, Simon [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] savePlot() no longer automatically adds an extension to the filename.
Simon Urbanek wrote: On Jun 3, 2008, at 8:40 PM, Duncan Murdoch wrote: On 03/06/2008 2:35 PM, Mike Prager wrote: S Ellison [EMAIL PROTECTED] wrote: Plaintive squeak: Why the change? Some OS's and desktops use the extension, so forgetting it causes trouble. The new default filename keeps a filetype (as before) but the user now has to type a filetype twice (once as the type, once as extension) to get the same effect fo rtheir own filenames. And the extension isn't then checked for consistency with valid file types, so it can be mistyped and saved with no warning. Hard to see the advantage of doing away with it... Just for the record. . . This change broke a *lot* of my code, including code used by others. Windows depends on file extensions. Fortunately, fixes using getRversion are not too difficult. Then you'll be happy to hear that Steve put together a patch and it's already committed, so it should make it into 2.7.1. The patch adds the extension if there's no dot in the name, leaves the filename as-is if it sees one. So this should be compatible with the majority of uses, only messing up cases where people really don't want an extension (now they'll have to add a dot at the end of their filename), or where they want an automatic one, but have another dot in the name. AFAICS the savePlot() behavior is now (as of r45830) inconsistent across platforms due to the patch (r458229). The inconsistency is IMHO a bad thing - you shouldn't expect the same function to behave differently across platforms. savePlot has been a Windows function for at least 4 years, defined in the grDevices/R/windows directory, and documented in the grDevices/man/windows directory. An incompatible X11 version was added in February 2008. So if compatibility across platforms is the goal, we should change the X11 version to match the Windows version, not vice versa. However, the convention of automatically adding an extension is a Windows convention, not a Unix convention. So I think that would be a bad change. This is a user interface issue, and it is reasonable to have differences in user interfaces across platforms. I'd strongly recommend against this change for several reasons: it changes the behavior of the function between 2.7.0 and 2.7.1, so that now you have to special-case three different versions (pre 2.7.0, 2.7.0 and 2.7.1), there is now no way to specify a file without a dot (which is quite common in non-Windows world) and the behavior is incompatible with other similar functions. I think the change of behavior in 2.7.0 was deliberate and in favor of consistency, because a filename specification should not be randomly mangled by the function (I have made that mistake myself before, so I know the pitfalls ;)). Extension is part of the filename, it's not a separate concept (also note that .foo is a valid filename that doesn't have an extension). The argument about typos is moot since you can always define functions like saveFoo - function(prefix) savePlot(filename = paste(prefix, foo, sep=.), type=foo) At any rate I don't see how this can realistically be part of 2.7.1 since it's not a bugfix and it changes the meaning of a function parameter. (And I usually don't mind disguising small features as bugfixes ;P) Whether the change in 2.7.0 could be done differently (e.g. using another parameter for a full file name) is a different story, but I suspect that it should have been discussed before the 2.7.0 release... I agree it should have been discussed earlier, but it wasn't. There are lots of precedents for behaviour changes between .0 and .1 releases, for the sake of back-compatibility. So I think Steve's change is appropriate, and I'm planning to leave it in. Duncan Murdoch Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] savePlot() no longer automatically adds an extension to the filename.
Gabor Grothendieck wrote: On Tue, Jun 3, 2008 at 10:36 PM, Simon Urbanek [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 8:40 PM, Duncan Murdoch wrote: On 03/06/2008 2:35 PM, Mike Prager wrote: S Ellison [EMAIL PROTECTED] wrote: Plaintive squeak: Why the change? Some OS's and desktops use the extension, so forgetting it causes trouble. The new default filename keeps a filetype (as before) but the user now has to type a filetype twice (once as the type, once as extension) to get the same effect fo rtheir own filenames. And the extension isn't then checked for consistency with valid file types, so it can be mistyped and saved with no warning. Hard to see the advantage of doing away with it... Just for the record. . . This change broke a *lot* of my code, including code used by others. Windows depends on file extensions. Fortunately, fixes using getRversion are not too difficult. Then you'll be happy to hear that Steve put together a patch and it's already committed, so it should make it into 2.7.1. The patch adds the extension if there's no dot in the name, leaves the filename as-is if it sees one. So this should be compatible with the majority of uses, only messing up cases where people really don't want an extension (now they'll have to add a dot at the end of their filename), or where they want an automatic one, but have another dot in the name. AFAICS the savePlot() behavior is now (as of r45830) inconsistent across platforms due to the patch (r458229). The inconsistency is IMHO a bad thing - you shouldn't expect the same function to behave differently across platforms. I'd strongly recommend against this change for several reasons: it changes the behavior of the function between 2.7.0 and 2.7.1, so that now you have to special-case three different versions (pre 2.7.0, 2.7.0 and 2.7.1), there is now no way to specify a file without a dot (which is quite common in non-Windows world) and the behavior is incompatible with other similar functions. I think the change of behavior in 2.7.0 was deliberate and in favor of consistency, because a filename specification should not be randomly mangled by the function (I have made that mistake myself before, so I know the pitfalls ;)). Extension is part of the filename, it's not a separate concept (also note that .foo is a valid filename that doesn't have an extension). The argument about typos is moot since you canf always define functions like saveFoo - function(prefix) savePlot(filename = paste(prefix, foo, sep=.), type=foo) At any rate I don't see how this can realistically be part of 2.7.1 since it's not a bugfix and it changes the meaning of a function parameter. (And I usually don't mind disguising small features as bugfixes ;P) Whether the change in 2.7.0 could be done differently (e.g. using another parameter for a full file name) is a different story, but I suspect that it should have been discussed before the 2.7.0 release... One way to fix this so that the filename is a complete name is to derive the default type from the filename rather than the default filename from the type. That is if type is not specified and the last four characters of the file name are .wmf, .jpg, ..., etc. then the type would be set to that. I think that would have been a better design when savePlot was introduced many years ago, but the goal here is to maintain back compatibility. It wouldn't help with that, because before February, savePlot got the type from the type arg, and modified the filename to match. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] significant digits (PR#9682)
Duncan Murdoch: The number 0.12345 is not exactly representable, but (I think) it is represented by something slightly closer to 0.1235 than to 0.1234. I like using formatC for checking such things. On my (Linux) system, I get: $ formatC(.12345,digits=50) [1] 0.12345417443857259058859199285507202148 So it looks as though Windows gets it right. -- Karl Ove Hufthammer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] savePlot() no longer automatically adds an extension to the filename.
Michael Prager [EMAIL PROTECTED] 06/04/08 4:28 AM
There is much to be said for consistency (across platforms and
functions) and stability (across versions) in software.
I could not agree more. But while consistency is an excellent reason
for making the patch consistent across platforms, it doesn't help decide
what the consistent behaviour should be. It is as strong an argument for
retaining the original behaviour at 2.6.x as for keeping a change.
As to filename extensions or their lack; in practice, RGui.exe addds a
defult Rdata extension on saving a workspace via the GUI, and so does
saving history, so we already have overwriteable default extensions for
those purposes even though the command line behaviour doesn't do that.
And it genuinely does help, which is my main motivation here.
The main advantage of the present patch is that it delivers _most_ of
the optional behaviours missing from both 2.6.2 and 2.7.0 without adding
an extra parameter. But it isn't the best that could be done. If there
is a platform-independent way of keeping the default extension-by-type
and allowing the option of removing it entirely (in other words, an
extra parameter to savePlot) I'd personally see that as a better way
forward than the present patch.
An alternative might be to keep the 2.7.0 savePlot and define a new
convenience function (SavePlot, say, or save.plot for extra dottiness)
which provides the wrapper. It would have impact on legacy code, but it
is a lot easier to change a function name throughout legacy code than to
change supplied parameters.
In the mean time, consistency arguments would indicate that the present
patch should be applied to all platforms if at all.
Steve E
***
This email and any attachments are confidential. Any use...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] savePlot() no longer automatically adds an extension to the filename.
Apologies; in my last post (below) I should have distinguished between
action on the current patch and suggested action for the future.
I bow to Duncan on the fate of the current patch, as he's managing it.
The suggestions of an extra savePlot parameter or a wrapper function
with extension default were suggestions for possible future tidying-up
in subsequent releases.
Steve E
S Ellison [EMAIL PROTECTED] 06/04/08 12:44 PM
Michael Prager [EMAIL PROTECTED] 06/04/08 4:28 AM
There is much to be said for consistency (across platforms and
functions) and stability (across versions) in software.
I could not agree more. But while consistency is an excellent reason
for making the patch consistent across platforms, it doesn't help decide
what the consistent behaviour should be. It is as strong an argument for
retaining the original behaviour at 2.6.x as for keeping a change.
As to filename extensions or their lack; in practice, RGui.exe addds a
defult Rdata extension on saving a workspace via the GUI, and so does
saving history, so we already have overwriteable default extensions for
those purposes even though the command line behaviour doesn't do that.
And it genuinely does help, which is my main motivation here.
The main advantage of the present patch is that it delivers _most_ of
the optional behaviours missing from both 2.6.2 and 2.7.0 without adding
an extra parameter. But it isn't the best that could be done. If there
is a platform-independent way of keeping the default extension-by-type
and allowing the option of removing it entirely (in other words, an
extra parameter to savePlot) I'd personally see that as a better way
forward than the present patch.
An alternative might be to keep the 2.7.0 savePlot and define a new
convenience function (SavePlot, say, or save.plot for extra dottiness)
which provides the wrapper. It would have impact on legacy code, but it
is a lot easier to change a function name throughout legacy code than to
change supplied parameters.
In the mean time, consistency arguments would indicate that the present
patch should be applied to all platforms if at all.
Steve E
***
This email and any attachments are confidential. Any use...{{dropped:16}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] significant digits (PR#9682)
That (and simpler, sprintf()) merely tell you about your OS's sprintf function. That is not required to accurately give a decimal representation of more than DECIMAL_DIG digits, and certainly not 50. The help for formatC does warn you about this. On my F8 system DECIMAL_DIG is mentioned in math.h but not defined there. (It is defined in the compiler, AFAICS -- SunStudio has it as 21, and gcc computes __DECIMAL_DIG__ also as 21.) The C99 standard says that it should be at least 10 and that 17 is appropriate for IEC60559 arithmetic. On Wed, 4 Jun 2008, Karl Ove Hufthammer wrote: Duncan Murdoch: The number 0.12345 is not exactly representable, but (I think) it is represented by something slightly closer to 0.1235 than to 0.1234. I like using formatC for checking such things. On my (Linux) system, I get: $ formatC(.12345,digits=50) [1] 0.12345417443857259058859199285507202148 So it looks as though Windows gets it right. -- Karl Ove Hufthammer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] An issue happens Embed R and redirt png file
I am a new R user and I have a question of embedding R to generate png On Debian, I installed R by source code. Now I want to embed R in an application which name is MyApp, and run the following syntax: png(filename=/tmp/Rplot%03d.png) example(rect) dev.off() Unfortunately I get the following error message: Error in X11(paste(png::, filename, sep = ), width, height, pointsize, : unable to start device PNG Calls: png In addition: Warning message: In png(filename = /tmp/test%03d.png) : unable to open connection to X11 display '' But I could run above syntax from R, and the result is correct, I can get two png files from /tmp/ folder. I try to respectively run same syntax(the syntax is: capabilities()[[png]]) under two modes, the result is different: In R the result is TRUE, but when MyApp embed R the result is FALSE Then I used bitmap(file=/tmp/test) when embed R in MyApp, but get another error message: Error in bitmap(file = /tmp/test) : sorry, 'gs' cannot be found Besides, I have installed xvfb. What I need do? Thanks -- View this message in context: http://www.nabble.com/An-issue-happens-Embed-R-and-redirt-png-file-tp17647871p17647871.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] permsn incorrect when x==m (library: prob) (PR#11571)
Full_Name: Obnoxious Version: 2.7.0 OS: Windows Submission from: (NULL) (121.223.77.238) Objective: Generate all permutations of the elements of x taken m at a time. Library: prob Function: permsn Issue: Does not appear to be working correctly when x==m. Example: libary(prob) permsn(2,1) i.e., x m #Gives the correct result of [,1] [,2] [1,]12 #Yet permsn(2,2) i.e., x==m #Gives the incorrect? result of [1] 1 2 #Shouldn't the result be [,1] [,2]??? [1]12??? [2]21??? #Workaround: permsn(3,2) i.e. permsn(x+1,m) [,1] [,2] [,3] [,4] [,5] [,6] [1,]121323 [2,]213132 #but then we have to remove the results with x==3 in them #hope that all makes sense Thankyou, Obby __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Enter key in data editor bombs program in MDI (PR#11579)
Full_Name: Michael H Version: 2.7 OS: Windows XP SP3 Submission from: (NULL) (74.74.76.1) When running R with the multiple document interface, pressing enter in the data editor causes the program to crash with the following command: Dataset - edit(as.data.frame(NULL)) This problem persists when using the fix command, such as fix(Dataset). Interestingly, the arrow keys and mouse work fine in navigating through the dataset. Also, this problem only occurs for me in MDI mode, not in SDI mode. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] permsn incorrect when x==m (library: prob) (PR#11571)
Dear Obby, Thanks. In the future, when you have a question about something that happens in a particular package, keep in mind that it is customary to contact the package maintainer (me), rather than file a bug report with the R developers. In that case, I would have alerted you that this problem has already been found and a fix was posted: please see http://tolstoy.newcastle.edu.au/R/e4/help/08/04/8178.html This will be included in the next release of prob, on which I am currently working. I expect it to be ready by August. Best, Jay On Wed, Jun 4, 2008 at 6:50 AM, [EMAIL PROTECTED] wrote: Full_Name: Obnoxious Version: 2.7.0 OS: Windows Submission from: (NULL) (121.223.77.238) Objective: Generate all permutations of the elements of x taken m at a time. Library: prob Function: permsn Issue: Does not appear to be working correctly when x==m. Example: libary(prob) permsn(2,1) i.e., x m #Gives the correct result of [,1] [,2] [1,]12 #Yet permsn(2,2) i.e., x==m #Gives the incorrect? result of [1] 1 2 #Shouldn't the result be [,1] [,2]??? [1]12??? [2]21??? #Workaround: permsn(3,2) i.e. permsn(x+1,m) [,1] [,2] [,3] [,4] [,5] [,6] [1,]121323 [2,]213132 #but then we have to remove the results with x==3 in them #hope that all makes sense Thankyou, Obby __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- *** G. Jay Kerns, Ph.D. Assistant Professor / Statistics Coordinator Department of Mathematics Statistics Youngstown State University Youngstown, OH 44555-0002 USA Office: 1035 Cushwa Hall Phone: (330) 941-3310 Office (voice mail) -3302 Department -3170 FAX E-mail: [EMAIL PROTECTED] http://www.cc.ysu.edu/~gjkerns/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enter key in data editor bombs program in MDI (PR#11579)
On 6/4/2008 9:05 AM, [EMAIL PROTECTED] wrote: Full_Name: Michael H Version: 2.7 Which 2.7? The 2.7.0 release? (sessionInfo() would be more specific.) I see a crash there, but not in R-patched. Please give it a try (it's downloadable from cran.r-project.org/bin/windows/base). Duncan Murdoch OS: Windows XP SP3 Submission from: (NULL) (74.74.76.1) When running R with the multiple document interface, pressing enter in the data editor causes the program to crash with the following command: Dataset - edit(as.data.frame(NULL)) This problem persists when using the fix command, such as fix(Dataset). Interestingly, the arrow keys and mouse work fine in navigating through the dataset. Also, this problem only occurs for me in MDI mode, not in SDI mode. __ 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] RSQLite bug fix for install with icc
Hi Mark, [the r-sig-db list might have been a better spot for this...] * On 2008-06-04 at 14:28 -0400 Mark Kimpel wrote: I encountered problems installing RSQLite, R-2.7.0, on RHEL4 using Intel 10.1 icc, My sysadmin helped me track down the problem and kindly forwarded me the fix, which corrected the problem. What follows is from the sysadmin. Mark I looked at the error, looks like there is a bug in the source code. I've attached a new tarball, hopefully fixed. I added #include sys/types.h immediately before #include unistd.h in RSQLite/src/RS-DBI.h I will see about making such a change. I suspect the correct fix is one that tweaks configure to determine where things are based on the current system (the current code is correct for gcc I believe). Anyhow, thanks for the report. I will try to have an update within a week. + seth -- Seth Falcon | http://userprimary.net/user/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Splus/R typedef for C equivalent of S integer
We've been working on making it easier to write packages that work in both R and Splus. One issue is that R and Splus use different internal representations of integers and this makes a difference on their 64-bit versions: R uses ints (32 bits on 32-bit and 64-bit versions of R) and Splus uses longs (32 bits on 32-bit Splus and 64 bits on 64-bit Splus). The obvious ways to deal with the difference are to use a typedef or a #define to map those to a common name. I think it would be handy to put this definition into R.h or some other R header file (Splus now has an R.h and other header files with the R names that we recommend for all package work.) Should this be a typedef or a #define? What should its name be? There is a file, RSCommon.h (from omegahat?), that I've seen in a few packages which uses a typedef, RSInt, for this. Repeated typedefs, even with the same definition, are illegal so putting typedef ... RSInt into R.h would break those packages. (C doesn't yet have an if-typedef-exists or untypedef construct, does it?) I like XXXinteger, since it refers to the R/Splus name of the class, integer, instead of the C-like name. Should the XXX prefix be RS or RSplus or S? I like typedefs since you can use them in the debugger. Should a typedef be accompanied by a #define XXXinteger_defined so one can write code that works on older versions of R or Splus without the typedef? I think R.h would be a good place for it, but I don't have strong feeling about that one. If we can come to a consensus on the name, typedef/#define, and which *.h file, I can put it into Splus. Bill Dunlap Insightful Corporation bill at insightful dot com All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Splus/R typedef for C equivalent of S integer
Bill, R's R.h already has typedef double Sfloat; typedef int Sint; #define SINT_MAX INT_MAX #define SINT_MIN INT_MIN for this purpose, and it is used in a lot of packages. It goes back a long way, and I don't remember its origins but 'S Programming' is one source. Brian On Wed, 4 Jun 2008, Bill Dunlap wrote: We've been working on making it easier to write packages that work in both R and Splus. One issue is that R and Splus use different internal representations of integers and this makes a difference on their 64-bit versions: R uses ints (32 bits on 32-bit and 64-bit versions of R) and Splus uses longs (32 bits on 32-bit Splus and 64 bits on 64-bit Splus). The obvious ways to deal with the difference are to use a typedef or a #define to map those to a common name. I think it would be handy to put this definition into R.h or some other R header file (Splus now has an R.h and other header files with the R names that we recommend for all package work.) Should this be a typedef or a #define? What should its name be? There is a file, RSCommon.h (from omegahat?), that I've seen in a few packages which uses a typedef, RSInt, for this. Repeated typedefs, even with the same definition, are illegal so putting typedef ... RSInt into R.h would break those packages. (C doesn't yet have an if-typedef-exists or untypedef construct, does it?) I like XXXinteger, since it refers to the R/Splus name of the class, integer, instead of the C-like name. Should the XXX prefix be RS or RSplus or S? I like typedefs since you can use them in the debugger. Should a typedef be accompanied by a #define XXXinteger_defined so one can write code that works on older versions of R or Splus without the typedef? I think R.h would be a good place for it, but I don't have strong feeling about that one. If we can come to a consensus on the name, typedef/#define, and which *.h file, I can put it into Splus. Bill Dunlap Insightful Corporation bill at insightful dot com All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Splus/R typedef for C equivalent of S integer
On Wed, 4 Jun 2008, Prof Brian Ripley wrote: Bill, R's R.h already has typedef double Sfloat; typedef int Sint; #define SINT_MAX INT_MAX #define SINT_MIN INT_MIN Whoops, I forgot the name and that I'd put it into Splus's R.h (and now in someing included by it) a while back. Quite a few R packages use it. I was looking through Writing R Extensions for mention of such a thing and didn't find it. Perhaps the 'int's in the examples in Chapter 5 could be changed to 'Sint's. A few packages (gee,lasso2,locfit,AnalyzeFMRI) used to typedef Sint (for R and Splus), but since you already have it in R we can go with it. In the current development version of Splus it has an associated #ifdef/#define so packages can avoid it if needed: #ifndef HAVE_SINT_TYPEDEF typedef long Sint ; /* C type for S language integer, is int in R */ #define HAVE_SINT_TYPEDEF #endif To make the packages even more portable with respect to int/long things, we need to encourage the use of casts when interfacing to non-S code. E.g., Sint x_zero = INTEGER(x)[0] ; Rprintf(First element of x is %ld\n, (long)x_zero); will print x[0] properly in R and Splus but Rprintf(First element of x is %d\n, x_zero); will not work properly in Splus. Thanks, Bill Bill Dunlap Insightful Corporation bill at insightful dot com 360-428-8146 All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] is() and S3 classes
The is() function begins with the following code:
cl - class(object)
if (length(cl) 1) {
if (is.na(match(cl[[1]], names(getClass(oldClass)@subclasses
return(class2 %in% cl)
As one can see, it uses S3 inheritance if the first element of the class
attribute is an oldClass. In R prior to 2.7, is() would check S4
inheritance if any (not just the first) classes named in the class attribute
were derived from oldClass.
It seems to me that S3 inheritance would imply that an R object is an
instance of oldClass if any of its classes are derived from oldClass.
Could the current behavior be changed, please?
Thanks,
Michael
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] is() and S3 classes
On Wed, Jun 4, 2008 at 8:05 PM, Michael Lawrence [EMAIL PROTECTED] wrote:
The is() function begins with the following code:
cl - class(object)
if (length(cl) 1) {
if (is.na(match(cl[[1]], names(getClass(oldClass)@subclasses
return(class2 %in% cl)
As one can see, it uses S3 inheritance if the first element of the class
attribute is an oldClass. In R prior to 2.7, is() would check S4
inheritance if any (not just the first) classes named in the class attribute
were derived from oldClass.
Sorry just checked and this is how it basically behaved pre R 2.7, so I
guess I withdraw my request ;)
It seems to me that S3 inheritance would imply that an R object is an
instance of oldClass if any of its classes are derived from oldClass.
Could the current behavior be changed, please?
Thanks,
Michael
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
