Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
If you're looking for a GUI toolkit that: 1. Is cross-platform, 2. Has a good collection of widgets that look good on all platforms, and 3. Is easy to work with from R then it is hopeless. There is no such toolkit. As one poster mentioned, most of the better GUI toolkits are very object-oriented, because that paradigm is a good fit for GUI programming. There are a few programming environments out there that do have nice GUI abilities, but they all use base languages that are not very R-like, and so the potential R GUI programmer is faced with having to use two very different languages for his creation. And even if that obstacle is surmounted, there remains the difficulty of trying to package up his work in such a way as to make it easily installed by others. Things are always breaking in the interfaces between R and whatever you're using. Trying to keep it all running and packaging it for deployment are thankless, gargantuan tasks. There is a better way, and that is to give up on R. Start over with a better programming environment, one that is object oriented, as flexible and dynamic as R, is cross platform, easy to program in, and has decent GUI facilities already. Then port the stuff in R that does statistical programming, and you have the best of all worlds. The environment I am thinking about is VisualWorks Smalltalk, which is free for noncommercial use. As a language, Smalltalk is both simpler and more powerful than R, and the VM it runs on is much faster than the R interpreter. It has superior garbage collection and the best IDE in the business. Callouts to C are just as easy as they are in R, but would likely not be needed as often due to the faster VM and much better programming facilities. Interfaces to various databases are possible, and the most powerful web toolkit (Seaside) is written in Smalltalk and runs under VisualWorks. There are a couple of other Smalltalk environments around that could also be considered. Squeak is an open source cross-platform Smalltalk that is not as fast as VisualWorks, but still must faster and more robust than the R interpreter. Smalltalk/X is another possibility, though it works only on Windows and Unix. Think about it. Once you have a basic math package that can handle matrix programming and various mathematical functions, building the various statistical modeling tools on top of them is not that hard. What makes S and R so much better than SAS is their programmability. Smalltalk is like that, only better. Jeff Hallman __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
>>>>> "K" == Kasper Daniel Hansen <[EMAIL PROTECTED]> writes: K> On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote: K> >> Think about it. Once you have a basic math package that can handle >> matrix >> programming and various mathematical functions, building the various >> statistical modeling tools on top of them is not that hard. What >> makes S and >> R so much better than SAS is their programmability. Smalltalk is >> like that, >> only better. >> >> >> Jeff Hallman K> I would claim that this quote kind of shows that you have no idea K> what you are talking about regarding good, debugged and trustworthy K> statistical procedures. Why do you think people are actually using R? Kasper, a few minutes spent Googling my name should disabuse you of the notion that I have no idea of what I'm talking about. But to answer your question: I think people are using R because it's readily available, with a lot of good stuff already built in. I am not suggesting that you tell undergraduate statistics students to write everything in Smalltalk, since the class libraries to support statistical programming in Smalltalk do not exist yet. What I am saying is that if you compare the languages themselves, along with their programming environments, Smalltalk is superior to R. What it lacks are class libraries implementing statistical procedures. I do maintain that those really are not that hard, once you have the matrix and math libraries. My experience with S and R goes way back to the days of blue book S version 3. S called out to C code to handle matrix and mathmetical stuff, but used S code itself to glue it all together in a somewhat object-oriented way. K> I could say "well, given an environment that could interface to C, K> building a GUI on top of that is not really that hard", but that K> would be incredible naive as well. Indeed it would be. But statistical programming is easier than that. Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
Walter Johnston <[EMAIL PROTECTED]> wrote on 10/20/2005 12:21:09 PM: > A couple of non-flame comments and a question - > > (1) I have used Smalltalk in various forms and recommend it > highly as an environment (try Squeak for a free implementation); > it is the origin of the model-view-controller paradigm for > interaction with a GUI. Tcl/Tk is also nice with its > event-driven model. > > (2) DON'T keep re-implementing the same statistical algorithms > all over the place! Putting together software that can be > trusted is non-trivial - if you want to add to the available > resources I applaud you for it, but ADDing is not simply > translating to another language (though, if the "old" language > is no longer available or supported there are good reasons to do > so. :-) I use a package to accomplish something and I need to > trust the output from that package. I don't look for a "swiss > army knife" but rather a package that does what I need and does > it well (though I prefer packages that have more functionality). > > (3) I like R because of the model which returns results in > "objects" (though, as a Smalltalker, I don't see much OO in the > language - maybe I missed something). I agree with you here, and that is the reason why I disagree somewhat with your second point. If you have C code that implements statistical algorithms and/or structures, and you want to use it in Smalltalk, it is usually a good idea to write wrapper classes that put an object-oriented face on the procedural code. This is particularly true if you hope to reuse the code. You want to make the interface look and feel like Smalltalk to reduce the cognitive dissonance of whoever is using the wrapped code. But as an experienced Smalltalker, I'm sure you already know this. > > (4) AI seemed to make more demonstrable progress when they > started separting the reasoning mechanism from the rules and > data (as in the old "expert systems"). > > And the question: > > Is there a "simple" way (e.g. some socket based mechanism) to > feed commands into R and retrieve the results of those commands? > This would require that I program the sequence of commands I > want to use (or a means to generate them) and then be able parse > the resulting structure - I understand. But it would also allow > separation of the computation, the "statistical reasoning", and > the UI into (potentially) separate units which would not even > need to be on the same machine to inter-operate. If there is a > reasonable way to do this, please tell me. > > Thanks. > > Walter Johnston A couple of my VisualWorks apps communicate via sockets with R. I am sending the code to Walter via private email. If anyone else wants it, just ask. Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)
>>>>> "b" == Byron Ellis <[EMAIL PROTECTED]> writes: b> On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote: >> If you're looking for a GUI toolkit that: >> >> 1. Is cross-platform, >> 2. Has a good collection of widgets that look good on all >> platforms, and >> 3. Is easy to work with from R >> >> then it is hopeless. There is no such toolkit. b> There is in fact such a toolkit. I'll give you a hint, its name ends b> in "step" and its heavily used under a different name by a company b> named after a fruit. It works quite well from R, doesn't require b> another language and frankly the binding between it and R was b> actually pretty pleasant as these things go. By my count it took 2727 b> lines of C and 411 lines of R to bind, a good half of which are b> technically unnecessary. Right now it probably doesn't run under b> Windows and Linux/BSD/Solaris/Your Favorite POSIX Compliant UNIX at b> the present time, but thats mostly because I don't care rather than b> because it can't. >> >> As one poster mentioned, most of the better GUI toolkits are very >> object-oriented, because that paradigm is a good fit for GUI >> programming. >> There are a few programming environments out there that do have >> nice GUI >> abilities, but they all use base languages that are not very R- >> like, and so >> the potential R GUI programmer is faced with having to use two very >> different >> languages for his creation. And even if that obstacle is >> surmounted, there b> This is only a problem because people seem to insist on using R's b> object system in a way that is not actually very compatible with R's. b> To misquote Robert at DSC, "their primary complaint about R is that b> its not Java." If you think about it for a moment, R's environment is b> actually quite well suited to GUI tasks because, well, because it has b> environments. Imagine drawing into a window (you're a plotting tool b> or something). Really, you're a function executing in an environment b> (oh ho!) that has access to certain system resources, in this case a b> canvas of a certain physical and logical dimension. Responding to b> events could take on a similar structure---you're really executing in b> an Event environment that has certain bound symbols. Obviously you b> get to keep your lexical environment so event handlers that need to b> share state can in the usual way. Its not particularly difficult and b> doesn't even need to involve objects in any real way, except as b> little stubby things with attributes you can modify or poll. This is interesting. However, I wonder how you can do GUI programming with the current R single event loop. If an event comes in while some other code is executing, do you interrupt, handle the event, and then resume? Would not R require major surgery to make it reentrant? What if I want to display a screen while continuing to do other stuff? It seems to me that R would need something like the S setReader/setMonitor stuff to run a GUI. >> remains the difficulty of trying to package up his work in such a >> way as to >> make it easily installed by others. Things are always breaking in the >> interfaces between R and whatever you're using. Trying to keep it >> all running >> and packaging it for deployment are thankless, gargantuan tasks. b> How is this different than releasing any piece of software? If your software is all done in a single environment that already handles cross-platform issues for you, it becomes much easier. As an example, I had Splus code that handled a lot of date arithmetic by calling C code. I had to use C because S6 is so slow. When I ported to R, I found that R was fast enough that I didn't need the C code. As a result, I no longer have to build a .so for Linux and a .dll for Windows. In fact, I never could get the .dll for Windows working. >> >> There is a better way, and that is to give up on R. Start over with >> a better programming environment, one that is object oriented, as >> flexible and >> dynamic as R, is cross platform, easy to program in, and has decent >> GUI >> facilities already. Then port the stuff in R that does statistical >> programming, and you have the best of all worlds. >> >> The environment I am thinking about is VisualWorks Smalltalk, which >> is free >> for noncommercial use. As a language, Smalltalk is both simpler
[Rd] Calling C functions with value parameters
One hassle I could do without is the necessity of writing C wrapper functions
like this:
void fameInit(int *status){
cfmini(status);
return;
}
when I want to call a library function (cfmini, in this case) that takes an
int argument. The .C interface only lets me pass a pointer to an int, rather
than the int itself.
Is there any chanch that .C could be enhanced to allow passing arguments by
value to the compiled code? It would make some of my stuff much simpler.
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling C functions with value parameters
replying to myself here, in lieu of replying to several others
jhall...@frb.gov (Jeffrey J. Hallman) writes:
> One hassle I could do without is the necessity of writing C wrapper functions
> like this:
>
> void fameInit(int *status){
> cfmini(status);
> return;
> }
>
> when I want to call a library function (cfmini, in this case) that takes an
> int argument. The .C interface only lets me pass a pointer to an int, rather
> than the int itself.
>
> Is there any chanch that .C could be enhanced to allow passing arguments by
> value to the compiled code? It would make some of my stuff much simpler.
Of course I realized right after I posted that my example was incorrect.
Since the cfmini() function takes a pointer to an int, all I needed was this:
status <- .C("cfmini", status = as.integer(0))$status
However, I do have functions where this can't be done, because the library
function being called takes one or more parameters by value, not by reference.
For example, I had to write this wrapper:
void fameCloseDatabase(int *status, int *key){
cfmcldb(status, *key);
return;
}
where the "key" argument to cfmcldb() is an int, not a pointer.
As you probably realize, cfmcldb() is not something I wrote: it's part of the
FAME Host Language Interface (chli) provided by Sungard, the vendor of the
FAME time series database.
My point, which I clearly did not make very well, since all of the replies so
far have missed it, is that if .C() could pass arguments by value as well as
by reference, I could write the fame package (an interface to the FAME
database) entirely in R, as I'd be able to call any of the chli functions
directly, without having to write C wrappers. This would make if much easier
to debug the package and get it working correctly on Windows, where I can't
seem to get it to compile correctly any more. I surely cannot be the only
package writer who has to interface to external libraries and would rather
write the interface in R than in C.
Do we not all see the virtues of doing almost everything in R itself, rather
than writing parts of the system in other languages and systems? Why else
would Ripley undertake all the recent work to parse .Rd files in R rather than
in Perl, and why do people work on things like gWidgets?
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extract/format/show for S4 objects
The tis package has the ti (TimeIndex) class that does what you want,
and I modestly think it's nicer than the zoo stuff.
As for S4 classes, there's a good reason many of us don't use them:
they're too inflexible and hard to program with. I wouldn't go there
unless I really had to.
Johann Hibschman writes:
> Hi all,
>
> I'm trying to make an integer-backed quarter (as in fraction of year)
> class, but I can't quite it to work. I want integer-backed so I don't
> have to worry about floating-point effects when doing math, and so that
> I can use it as in data.table.
>
> First of all, is there a good reference for this anywhere? All of the
> S4 tutorials that I've found have been too high-level, and I can't find
> any examples of implementing extract. In S3, I can use [.Date as my
> example, but I can't find the equivalent for S4.
>
> Second, is this misguided?
>
> Now for the details. Given this start:
>
> library(zoo) # borrowing yearqtr for output.
> setClass("iqtr", contains="integer")
> ## Create an iqtr object from a numeric date (e.g. 2000.5).
> iqtr <- function (x) {
> iq <- as.integer(floor((as.numeric(x) - 2000) * 4 + 0.0001))
> new("iqtr", iq)
> }
> setMethod("show", "iqtr4",
> function (object) {
> cat(format(yearqtr(as.numeric(x) * 0.25 + 2000)))
> })
>
>
> I have two issues:
>
> 1. Vectors of iqtrs do not display properly.
> They print, but they don't look like vectors.
>> iq <- iqtr(seq(2000, 2002, 0.25))
>> iq
>2000 Q2 2000 Q2 2000 Q3 2000 Q4 2001 Q2 2002 Q1>
>
> 2. Subsets do not stay in the class.
>> iq[1:2]
>> [1] 0 1
>
> Clearly, I'm just not understanding what's going on. Is there a guide
> for how to make printing, format, subsetting, etc., all work for S4
> classes?
>
> Thanks,
> Johann
>
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help with OS X (BSD) ps command
My fame package has a function that checks to see if a FAME SERVER process is
already running. On Linux, I can do this in one of two ways:
pid <- Sys.getpid()
user <- Sys.info()["user"]
cmd <- paste("pgrep -fU", user, "-P", pid, "'FAME SERVER'")
fameRunning <- as.logical(length(system(cmd, intern = T)))
or I can use
cmd <- paste("ps -ef | grep", user, "| grep", pid,
"| grep -v grep | grep -c 'FAME SERVER'")
fameRunning <- as.logical(as.numeric(system(cmd, intern = T)))
Mac OS X does not have pgrep, and being a BSD derivative, takes different
arguments for the 'ps' command. I don't have access to a BSD machine. Can
someone who does tell me the correct invocation of 'ps' to see if 'user' is
running a 'FAME SERVER' process with the R process as its parent process?
Please don't tell me how to get pgrep for OS X, as my objective here is to
stop the CRAN test machine from complaining about my invalid ps command.
While FAME is not officially supported on OS X, I am told that it can be made
to work there. Had I not heard this, of course, I could just answer FALSE for
OS X and be done with it.
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RPM support for package installation?
I feel your pain. At my workplace, the network administrators insist that
anything that is to be distributed across the network be packaged up in an
RPM. I have my own library of packages accessible to my section members, but
when I want to make something available to everyone, I have to create an RPM.
After many trials and tribulations, here is the rpm spec file I created for
Prof. Ripley's RODBC package. A few things to note:
1. R-2.4.0 was installed in /opt/r-2.4.0 by an RPM called R-arc
2. I create /opt/r-2.4.0/lib/R/src and unpack the source package there, so
my users can look at the original code if they want to.
3. The rpm does R CMD INSTALL pkg twice: once when it is installing the rpm,
and again in the post-install step. The reason for the second pass is to
insure that the help index files get rebuilt with all of the packages that
are installed in the production directory.
My other rpms are similar to this one. With that, here is the spec file:
--
Jeff
%define rversion 2.4.0
%define rtopdir /opt/r-%{rversion}
%define rhome %{rtopdir}/lib/R
%define rbin %{rhome}/bin/R
%define rSourcePackageDir %{rhome}/src
%define rBinaryPackageDir %{rhome}/library
%define arcrel 9
Name: R-rodbc-arc
Version: %{rversion}
Release: 1.1.REV.%{arcrel}
Summary: Package ODBC Interface for R
License: free
Requires: R-arc >= %{rversion}
Provides: R-rodbc
Group: Applications/Engineering
Source0: %{name}-%{version}.tar.gz
Buildroot: /tmp/%{name}-%{version}
%description
CRAN version 1.1-7 of RODBC, an ODBC interface for R.
%prep
%build
%install
[ "%{buildroot}" != "/" ] && rm -rf %{buildroot}
mkdir -p %{buildroot}%{rBinaryPackageDir}
mkdir -p %{buildroot}%{rSourcePackageDir}
mkdir -p %{buildroot}%{rhome}/doc/html/search
cd %{buildroot}%{rSourcePackageDir}
tar -xzf $RPM_SOURCE_DIR/%{name}-%{version}.tar.gz
%{rbin} CMD INSTALL -c -l %{buildroot}%{rBinaryPackageDir} RODBC
%files
%defattr(-, mathadm, appgrp)
%{rSourcePackageDir}/*
%{rBinaryPackageDir}/*
%clean
rm -rf %{buildroot}
%post
cd %{rSourcePackageDir}
pwd
%{rbin} CMD INSTALL -c RODBC
chown -R mathadm:appgrp %{rBinaryPackageDir}/RODBC
chown mathadm:appgrp %{rhome}/doc/html/packages.html
chown mathadm:appgrp %{rhome}/doc/html/search/index.txt
%preun
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to override functions in namespaces?
Prof Ripley,
Thanks to both you and Duncan Murdoch, who replied with similar advice.
Your suggestion to use get("askForString", pos = 1)() in my ssh()
function does what I want whether package B is attached or not.
Jeff
Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
br> On Mon, 12 Feb 2007, [EMAIL PROTECTED] wrote:
>> In package A I have askForString(), which asks the user for a string.
>> Also in package A I have defined ssh(), which calls askForString().
>>
>> Package B has package A as a prerequisite.
>>
>> In package B I redefine askForString() to take advantage of a nicer user
>> interface made available by B, namely the Emacs mini-buffer prompt.
>>
>> Packages B and A are both on the search path, with B ahead of A. If I
>> call askForString() at the command prompt, I get the version from B.
>> But the version used by ssh() depends on whether or not package A has a
>> namespace. If so, ssh() (defined in A) always uses the A version of
>> askForString(). How can I get ssh() to use the B version of
>> askForString()? Or am I going about this all wrong?
br> That is one of the main purposes of a namespace, but you can defeat it.
br> In the scenario you paint, B::askForString() should work (whether or not
B has
br> a namespace).
br> If (I am guessing) you want the version that would be gotten at the top
level
br> (the > prompt) whether or not B is in use, use
br> get("askForString", pos=1)().
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] fix() changes the class of mts objects
"Simone Giannerini" <[EMAIL PROTECTED]> writes: > My concern here is that users can be confused from the fact that if one has > a single time series fix() uses the default method of edit() and does not > change > its class > > > x <- ts(1:5) > > fix(x) > > class(x) > [1] "ts" > > whereas for mts objects edit.data.frame is used so that in my opinion it > might be worth to clarify it in the documentation. So write edit.ts() and submit it. -- Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] One for the wish list - var.default etc
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > On Wed, 9 May 2007, S Ellison wrote: > > > Brian, > > > >> If we make functions generic, we rely on package writers implementing > >> the documented semantics (and that is not easy to check). That was > >> deemed to be too easy to get wrong for var(). > > > > Hard to argue with a considered decision, but the alternative facing > > increasing numbers of package developers seems to me to be pretty bad > > too ... > > > > There are two ways a package developer can currently get a function > > tailored to their own new class. One is to rely on a generic function to > > launch their class-specific instance, and write only the class-specific > > instance. That may indeed be hard to check, though I would be inclined > > to think that is the package developer's problem, not the core team's. > > But it has (as far as I know today ...?) no wider impact. > > But it does: it gives the method privileged access, in this case to the > stats namespace, even allowing a user to change the default method > which namespaces to a very large extent protect against. > > If var is not generic, we can be sure that all uses within the stats > namespace and any namespace that imports it are of stats::var. That is > not something to give up lightly. No, but neither is the flexibility afforded by generics. What we have here is a false tradeoff between flexibility vs. the safety of locking stuff down. The tradeoff is false because unit tests are a better way to assure safety. If the major packages (like stats) had a suite of tests, a package developer could load his own package, run all the unit tests, and see if he broke something. If it turns out that he broke something that wasn't covered by the tests, he could create a new test for that and submit it somewhere, perhaps on the R Wiki. -- Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] aggregate.ts
aggregate.tis() in the fame package does what I think is the right thing:
> x2 <- tis(1:24, start = c(2000, 11), freq = 12)
> y2 <- aggregate(x2, nfreq = 4)
> x2
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2000 1 2
2001 3 4 5 6 7 8 9 10 11 12 13 14
2002 15 16 17 18 19 20 21 22 23 24
class: tis
> y2
Qtr1 Qtr2 Qtr3 Qtr4
2001 12 21 30 39
2002 48 57 66
class: tis
If you really want y2 to have an observation for 2000Q4, you can use
> convert(x2, tif = "quarterly", observed = "summed", ignore = T)
Qtr1 Qtr2 Qtr3 Qtr4
20004.03
2001 12.00 21.00 30.00 39.00
2002 48.00 57.00 66.00 71.225806
class: tis
Paul Gilbert <[EMAIL PROTECTED]> writes:
> I've been caught by this before, and complained before. It does not do
> what most people that work with economic time series would expect. (One
> might argue that not all time series are economic, but other time series
> don't usually fit with ts very well.) At the very least aggregate
> should issue a warning. Quarterly observations are for quarters of the
> year, so just arbitrarily grouping in 3 beginning with the first
> observation is *extremely* misleading, even if it is documented.
>
> [ BTW, there is a bug in the print method here (R-2.5.1 on Linux) :
> > y2 <- aggregate(x2, nfreq = 4)
> >
> > y2
> Error in rep.int("", start.pad) : invalid number of copies in rep.int()
> > traceback()
> 5: rep.int("", start.pad)
> 4: as.vector(data)
> 3: matrix(c(rep.int("", start.pad), format(x, ...), rep.int("",
>end.pad)), nc = fr.x, byrow = TRUE, dimnames = list(dn1,
>dn2))
> 2: print.ts(c(6L, 15L, 24L, 33L, 42L, 51L, 60L, 69L))
> 1: print(c(6L, 15L, 24L, 33L, 42L, 51L, 60L, 69L))
> ]
>
>
>
> >Currently, the "zoo" implementation allows this: Coercing back and forth
> >gives:
> > library("zoo")
> > z1 <- as.ts(aggregate(as.zoo(x1), as.yearqtr, sum))
> > z2 <- as.ts(aggregate(as.zoo(x2), as.yearqtr, sum))
> >
> >
> This is better, but still potentially misleading. I would prefer a
> default NA when only some of the observations are available for a
> quarter (and the syntax is a bit cumbersome for something one needs to
> do fairly often).
>
> Paul
>
> >where z1 is identical to y1, and z2 is what you probably want.
> >
> >hth,
> >Z
> >
> >__
> >[EMAIL PROTECTED] mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-help
> >PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> >and provide commented, minimal, self-contained, reproducible code.
> >
> >
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential inform...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wrong length of POSIXt vectors (PR#10507)
Duncan Murdoch <[EMAIL PROTECTED]> writes:
> One reason I don't want to work on this is because the appropriate
> action depends on what "length(x)" is intended to mean. Currently for
> POSIXlt objects, it gives the physical length of the underlying basic
> type (the list). This is the same behaviour as we have for matrices,
> data frames and every other object without a specific length method, so
> it's not outrageous.
>
> The proposed change is to have it return the logical length of the
> object, which also seems quite reasonable. I don't think matrices and
> data frames have a "logical length", so there would be no contradiction
> in those examples. The thing that worries me is that there are probably
> objects in packages where both logical length and physical length make
> sense but are different. I don't have any expectation that length(x) on
> those currently is consistent in which type of value it returns.
>
> If we were to decide that "length(x)" *always* meant logical length,
> then we would have a problem: matrices and data frames don't have a
> logical length, so we shouldn't be getting an answer there. Changing
> length(x) for those is not acceptable.
>
> On the other hand, if we decide that "length(x)" *always* means physical
> length, we don't need to do anything to the POSIXlt or matrices or data
> frames, but there may well be other kinds of objects out there that
> violate this rule.
>
> We could leave the meaning of length(x) ambiguous. If you want to know
> what it does for a POSIXlt object, you need to read the documentation or
> look at the source code. As a policy, this isn't particularly
> appealing, but I could probably live with it if someone else did the
> research and showed that current usage is ambiguous.
Physical length and logical length are, as you say, two different things. So
why not two functions? Keep length() for physical length, as it is now, and
maybe Length() for logical length. The latter could be defined as
Length <- function(x, ...) UseMethod("Length")
Length.default <- function(x, ...) length(x)
and then add methods for classes that want something else.
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] argument order for Math2 group functions in R 2.6.x (PR#10679)
You could always define your own signif() as
signif <- function(x, digits = 6){
base::signif(x, digits)
}
I do something like this for signif() and round() because economists don't
like the round-to-even convention R uses. My round() function, for example,
is:
round <- function(x, digits = 0, round.to.even = FALSE){
## Fixed to always round 0.5 to 1. The S "round to even" convention
## can be switched on via the round.to.even argument. -- JJH
xclass <- class(x)
if(is.matrix(x)){
digits <- rep(digits, length=ncol(x))
for(j in 1:ncol(x))
x[,j] <- round(x[,j], digits = digits[j], round.to.even = round.to.even)
}
else {
if(round.to.even)
return(base::round(x, digits))
ten.to.digits <- 10^digits
x <- trunc((x * ten.to.digits) + (sign(x[]) * 0.5))/ten.to.digits
}
class(x) <- xclass
return(x)
}
Sure, it's a lot slower. It still saves me several hours a year from not
having to explain what round-to-even does, and why my users should learn to
like it. They violently object to the idea that
1 + round(1.5) != round(1 + 1.5)
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assigning NULLs to elements of a list
>From your tone, I gather you don't much like this behavior, and I can see your point, as it not very intuitive that setting a list element to NULL deletes any existing element at that index. But is there a better way to delete an element from a list? Maybe there should be. Jeff Prof Brian Ripley <[EMAIL PROTECTED]> writes: >> I have just came across an (unexpected to me) behaviour of lists when >> assigning NULLs to list elements. I understand that a NULL is a valid R >> object, thus assigning a NULL to a list element should yield exactly the >> same result as assigning any other object. So I was surprised when >> assigning a NULL in fact removed the element from the list. Is this an >> intended behaviour? If so, does anybody know where is it documented and >> what is a good way around? > > Yes, it was apparently intended: R has long done this. > > x <- list(a=c(1L,2L), b=matrix(runif(4),2,2), c=LETTERS[1:3]) > x[2] <- list(NULL) > > is what I think you are intending. > > See e.g. the comment in subassign.c > > /* If "val" is NULL, this is an element deletion */ > /* if there is a match to "nlist" otherwise "x" */ > /* is unchanged. The attributes need adjustment. */ -- Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] postscript(colormodel = "cmyk") conversion is wrong
The conversion of RGB to CMYK takes place in PostScriptSetCol() starting at
line 2900 of R-2.7.0/src/library/grDevices/src/devPS.c
if(strcmp(mm, "cmyk") == 0) {
double c = 1.0-r, m=1.0-g, y=1.0-b, k=c;
k = fmin2(k, m);
k = fmin2(k, y);
if(k == 1.0) c = m = y = 0.0;
else {c /= (1.-k); m /= (1.-k); y /= (1.-k);}
r, g, and b have already been normalized to the range [0,1] before the
function was called, so this is almost right. The last line should actually
be something like
else { c = (c - k)/(1 - k); m = (m - k)/(1 - k); y = (y - k)/(1 - k);}
Here is some R code I wrote that does the conversion, so you can see what it's
supposed to be doing:
rgb2cmyk <- function(rgb){
## rgb is a vector of 3 numbers in the 0 to 255 range
## returns cmyk vector of 4 numbers in [0,1]
cmy <- 1 - rgb/255
names(cmy) <- c("c", "m", "y")
k <- min(min(min(1, cmy[1]), cmy[2]), cmy[3])
if(k == 1) c(cmy, k = 1)
else c(c(cmy - k)/(1-k), k = k)
}
--
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure.vars arg needed for install.packages
Currently, install.packages takes a 'configure.args' argument that adds a --configure-args to the eventual call to R CMD INSTALL. It does not, however, have a 'configure.vars' argument to similarly add the --configure-vars option to R CMD INSTALL, which seems to be an oversight. -- Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-2.2.0 format.default() loses matrix structure (PR#8696)
If argument big.mark is supplied. Like so: > version _ platform i686-redhat-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major2 minor2.0 year 2005 month10 day 06 svn rev 35749 language R > mat <- matrix(1:6, 3) > mat [,1] [,2] [1,]14 [2,]25 [3,]36 > format(mat) [,1] [,2] [1,] "1" "4" [2,] "2" "5" [3,] "3" "6" > format(mat, big.mark = ",") [1] "1" "2" "3" "4" "5" "6" > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk::tk_select.list has bad width (PR#9410)
Peter Dalgaard <[EMAIL PROTECTED]> wrote: pd> [EMAIL PROTECTED] wrote: >> The window put up by tcltk::tk_select.list appears to be of fixed width (20 >> chars), and is not wide enough to accomodate strings longer than 20 characters >> long. This can be easily fixed by setting the option "width = 0" in the calls >> to tklistbox(). Width = 0 tells tk to make the listbox just wide enough to >> accomodate the items contained in the list. >> >> pd> Hmm, maybe, but probably not unconditionally: What if someone puts in an item pd> that is supercalifragilisticexpialidosiously long? The listbox comes up as wide as my screen, but no wider. Seems like acceptable behavior to me. pd> You can already scroll sideways using the arrow keys. Yes, but the width of 20 is still a pain. I grew annoyed enough to track this down and fix it when I had a help document for 'lag()' in my local package as well as the one in the 'stats' package. When I entered ?lag at the R prompt, I'd get a menu offering me a choice of which document to show, but the strings identifying the choices were so truncated that it was difficult to know which one was which. 20 characters is just too few. Do you not agree that sending "width = 0" and letting Tk handle it automagically is better than what's in there now? Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [EMAIL PROTECTED]: dyn.load and function calls without 'PACKAGE' argument
I sent this to r-help and then realized it should really go to r-devel.
--- Begin Message ---
I'm writing a package that interfaces to the FAME database, via a
library of compiled C routines accessible through a Linux .so file. My
.onLoad() function loads the .so like this:
dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
and after that I also load my own fame.so via
library.dynam("fame", package = "fame")
The code in fame.so uses functions found in libjchli.so, making the
'local = F' argument in dyn.load() necessary. But since Fame symbols
are found in libjchli.so, which is NOT part of my package, I can't, for
example, do this:
.C("cfmfin", status = integer(1), PACKAGE = "fame")
since the PACKAGE argument tells R to look only in fame.so for symbols.
Instead, I have to do it without specifying 'PACKAGE', i.e.,
.C("cfmfin", status = integer(1))
This works, but 'R CMD check' complains:
"Foreign function calls without 'PACKAGE' argument:"
followed by a list of the functions called from libjchli.so.
Is there a way to make R CMD check happy here?
Jeff
--- End Message ---
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dyn.load and function calls without 'PACKAGE' argument
Duncan Temple Lang <[EMAIL PROTECTED]> wrote:
dtl> [EMAIL PROTECTED] wrote:
>> dyn.load("/opt/fame/timeiq/lib/linux_x86/libjchli.so", local = F)
>> library.dynam("fame", package = "fame")
>> The code in fame.so uses functions found in libjchli.so, making the
>> 'local = F' argument in dyn.load() necessary.
dtl> Well, that is one approach.
dtl> A more regular and in most senses "better" approach is to
dtl> have your fame.so link against libjchli.so when creating
dtl> the fame.so DLL/SO. Then you don't have to pollute the
dtl> global symbol table for the process with libjchli.so
dtl> and you can use the PACKAGE argument.
Will that work? Some of the functions in libjchli.so get called
directly via .C(). How would linking fame.so against libjchli.so help
when fame.so doesn't know what functions in libjchli.so I am going to
call? Perhaps I don't understand how linking works. Please feel free to
enlighten me.
dtl> That said, the PACKAGE argument is not necessary if you use
dtl> a NAMESPACE file for the package.
dtl> Load the fame.so with useDynLib() in the NAMESPACE file
dtl> and not library.dynam()
As I understand it, useDynLib(fame) is actually a directive that results
in fame.so being loaded via library.dynam(). I am using a NAMESPACE, so
I will try your advice and thank you for it.
dtl> And if you explicitly list the routines you want to use
dtl> in the useDynLib() call, you can refer to them as
dtl> .Call(foo, ...)
dtl> with no quotes, no PACKAGE and you will be able to handle
dtl> multiple versions and provide aliases for the routine names.
What if I don't explicitly list the routines? Many of the routines are
only compiled in for Unix, not Windows. Is there a way to use a
different useDynLib() directive depending on the operating system?
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Am I missing something about debugging?
Thoughts from a pro-Smalltalk bigot:
"Byron Ellis" <[EMAIL PROTECTED]> writes:
> While a Smalltalk-style debugger would be pretty awesome, I suspect
> R's semantics would make restartable exceptions pretty difficult and
> R's current implementation would make getting the continuation-like
> object you'd need pretty difficult, at least across the range of
> platforms supported by R.
>
> A solution, of course, would be to implement R's interpreter in
> Smalltalk as a domain-specific language. Vista Smalltalk apparently
> hosts a Lisp/Scheme interpreter and I know of at least one Lisp
> implementation for Squeak, which serve as pretty good starting points
> for an S-like language. :-)
I've programmed extensively in both Splus/R and Smalltalk, and I am much less
enamored of this idea than I used to be. R and Smalltalk are fundamentally
different and require different mindsets to write decent code. Here are some
of the differences:
1. Smalltalk objects are passed by reference, while R passes by value.
2. Smalltalk programs consist of messages sent to objects (receivers) and
assignments. R programs consist of function calls and assignments.
3. Smalltalk is single-inheritance and single-dispatch. R has multiple
inheritance and multiple dispatch.
4. The simplicity of the Smalltalk model is in part responsible for the
fantastic development tools. Single dispatch lets every method belong to a
particular class. In fact, everything in the system is an instance of some
class, including messages, methods, and even classes themselves. The
system browser essentially just browses (and lets you edit) classes, and
that's essentially all that you need. There are other browsers, but
they're really just different views into the same thing.
5. The style of programming is different. One example is how to implement a
computation with some inputs that have default values. In R, you would
write a function like this:
myFun <- function(arg1, arg2 = default2, arg3 = default3){
...
return(aComputedResult)
}
and call it any of these ways:
answer <- myFun(arg1 = 1)
answer <- myFun(arg1 = 1, arg2 = 2)
answer <- myFun(arg1 = 1, arg3 = 3)
answer <- myFun(arg1 = 1, arg2 = 2, arg3 = 3)
The naive way to do the same in Smalltalk uses 4 methods implemented in the
class of arg1. The one that does the actual computing looks like this:
myFunArg2: firstNumber arg3: secondNumber
^ aComputedResult "'^' is the return operator."
The other three methods are:
myFunArg2: aNumber
^ self myFunArg2: aNumber arg3: default3
myFunArg3: aNumber
^ self myFunArg2: default2 arg3: aNumber
myFun
^ self myFunArg2: default2 arg3: default3
and the four ways you can invoke these are:
answer := 1 myFun.
answer := 1 myFunArg2: 2.
answer := 1 myFunArg3: 3.
answer := 1 myFunArg2: 2 arg3: 3.
Compared to R this is kind of clunky, with a combinatoric explosion in the
number of methods as the number of arguments increases. To avoid that, an
experienced Smalltalker might instead create the class MyFunArgs to
implement the idea of "arguments for computing myFun". MyFunArgs would
have instance variables arg1, arg2 and arg3, and myFun would be invoked by
sending the message 'compute' to an instance of myFunArgs. MyFunArgs would
have an initialize method that set up the default values, so that
MyFunArgs arg1: aNumber
returned an instance with arg1 set to aNumber, arg2 set to default2, and
arg3 set to default3. Then you'd call it in one of these ways:
answer := (MyFunArgs arg1: 1) compute.
answer := ((MyFunArgs arg1: 1) arg2: 2) compute.
answer := ((MyFunArgs arg1: 1) arg3: 3) compute.
answer := ((MyFunArgs arg1: 1) arg2: 2; arg3: 3) compute.
For all of these reasons and more, R code does not translate cleanly to
Smalltalk, and even writing an R interpreter in Smalltalk does not really take
advantage of the Smalltalk way of programming.
On the other hand, Smalltalk is a very nice language, and with a bit of work
to set up the fundamental classes (e.g., Matrix, Vector, StatisticalModel,
etc...), a very nice data analysis environment could be created using it. The
virtues of such a system would be many. First and foremost is that, at the
level of 'computing on the language', Smalltalk is easy to understand, as it
really consists of only a few simple ideas consistently exploited to create a
sophisticated system. Second, there are free Smalltalk implementations that
can create complicated GUI applications much more easily than can be done in R
or Splus. Third, even the slowest Smalltalk interpreters are faster than the R
interpreter. Of course, in many cases this would not matter since R and
Smalltalk programmers alike can always call out to C or Fortran for
numerically intensive computations.
Jeff
__
R-devel@r-project.org maili
