Re: [Rd] FW: Bug in sum() with named data frame arguments

[Gregory Warnes]

I got an email error message when I attempted to send this from my work
account.  I have manually added it to the bug tracker, and am resending from
my personal account.

-G

On 12/12/05, Warnes, Gregory R <[EMAIL PROTECTED]> wrote:
>
>
>
> >  -Original Message-
> > From: Warnes, Gregory R
> > Sent: Monday, December 12, 2005 1:53 PM
> > To:   '[EMAIL PROTECTED]'
> > Subject:  Bug in sum() with named data frame arguments
> >
> >
> > Sum fails if it is passed a data frame argument with a name. It also
> generated different error messages depending on exactly how the data frame
> is passed in:
> >
> > > df <- data.frame(m1=1:2,m2=3:4)
> > > df
> >   m1 m2
> > 1  1  3
> > 2  2  4
> > > sum(df)  # succeeds
> > [1] 10
> > > sum(df=df)  # fails
> > Error in as.matrix(x) : argument "x" is missing, with no default
> > > sum(1,df=df) # fails, different error message
> > Error in sum(..., na.rm = na.rm) : invalid 'mode' of argument
> > > sum(df=df,1) # fails, different error message
> > Error in sum.default(..., na.rm = na.rm) :
> >   invalid 'mode' of argument
> > ## Note: no sum.default exists...
> >
> >
> > No similar problem exists for matrixes:
> >
> > > x <- as.matrix(df)
> > > sum(x)
> > [1] 10
> > > sum(df=x)
> > [1] 10
> > > sum(m1=x)
> > [1] 10
> > > sum(1,m1=x)
> > [1] 11
> > > sum(m1=x,1)
> > [1] 11
> > >
> >
> > The cause seems to be that the generic sum is defined as:
> >
> > > sum
> > function (..., na.rm = FALSE)
> > .Internal(sum(..., na.rm = na.rm))
> > 
> >
> > but the S3 methods are defined as
> >
> > > Summary.data.frame
> > function (x, ...)
> > {
> > x <- as.matrix(x)
> > if (!is.numeric(x) && !is.complex(x))
> > stop("only defined on a data frame with all numeric or complex
> variables")
> > NextMethod(.Generic)
> > }
> > 
> >
> > I suspect that the proper resolution of this bug is to change the base
> 'sum' method to provide a 1st argument named 'x', and to update the
> documentation.
> >
> > Note that the current implementation also failes when more than one data
> frame argument is supplied:
> >
> > > sum(y,y,y)
> > Error in sum.default(..., na.rm = na.rm) :
> >   invalid 'mode' of argument
> >
> > while the same thing with matrixes works fine:
> >
> > > sum(y,y,y)
> > Error in sum.default(..., na.rm = na.rm) :
> >   invalid 'mode' of argument
> >
> > -Greg
> >
> > Gregory R. Warnes, Ph.D.
> > Associate Director, Non-Clinical Statistics
> > Pfizer Global Research and Development
> >
>
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] status of Java & rJava?

[Gregory Warnes]

Hi Spencer, I'm also having problems getting rJava to work on Mac OS X.

-G

On Sat, Mar 28, 2020 at 4:19 PM Spencer Graves 
wrote:

> Hello, All:
>
>
>Is Java being deprecated for R?
>
>
>I ask, because I've been unable to get rJava 0.9-11 to work under
> either macOS 10.15 or Windows 10, and I can't get rJava 0.9-12 to
> install -- and my Ecfun package uses it:   I can't get "R CMD build
> Ecfun" to work on my Mac nor "R CMD check Ecfun_0.2-4" under Windows.
> Travis CI builds "https://github.com/sbgraves237/Ecfun"; just fine.
>
>
>The rJava maintainer, Simon Urbanek, has kindly responded to two
> of my three emails on this since 2020-03-20, but I've so far been unable
> to translate his suggestions into fixes for these problems.
>
>
>Should I remove rJava from Ecfun and see what breaks, then see if
> I can work around that?  Should I provide the error messages I get for
> rJava from "update.packages()" and / or library(rJava) on both machines,
> with sessionInfo() to this list or to Stack Exchange or Stack Overflow?
>
>
>Since I'm getting so many problems with rJava on under both macOS
> and Windows 10, that suggests to me that potential users could have
> similar problems, and I should try to remove rJava from Ecfun.
>
>
>What do you think?
>Thanks,
>Spencer Graves
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] (no) circular dependency

[Gregory Warnes]

A third possibility, which I use in my gtools and gdata packages, is to use 
soft-links to create a copy of the relevant functions from one package in the 
other.  I make sure these functions are *not* exported, so no conflicts are 
created, and the use of soft-links mean the code never gets out of sync.

-Greg

--  
Change your thoughts and you change the world.
--Dr. Norman Vincent Peale

> On Apr 8, 2016, at 11:37 AM, Gabriel Becker  wrote:
> 
> Another, perhaps slightly off the wall reframing of the 3-package
> possibility:
> 
> Have packages B, a, and UserFacingA, as follows
> 
> *a* contains all the functionality in your A package that
> *does not depend on B*
> *B* *imports from* *a* and is essentially unchanged
> *UserFacingA* *Depends* on *a* and *imports from* *B*, it implements all
> functionality from your package A that *does depend on* *B*, and gets the
> rest from package *a*
> 
> Users, then would only ever install or load B and UserFacingA. They
> wouldn't need to care much,if at all, about package a.
> 
> ~G
> 
> On Fri, Apr 8, 2016 at 7:36 AM, Dmitri Popavenko > wrote:
> 
>> Thanks all, I don't know either (for the moment).
>> It's all in the design phase still. Generally, I would also like to keep
>> specific functions in specific packages, if at all possible.
>> 
>> On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo > wrote:
>> 
>>> Well, I'm not saying that Dmitri _should_ do it. I merely mention it as
>> an
>>> option that I think is worth thinking about -- it is easy to overlook the
>>> obvious :-). Since we have no further info on the package's structure we
>>> can't be sure..
>>> 
>>> 
>>> 
>>> 
>>> Op vr 8 apr. 2016 om 13:59 schreef Adrian Dușa :
>>> 
 Hi Mark,
 
 Uhm... sometimes this is not always possible.
 For example I have a package QCA which produces truth tables (all
 combinations of presence / absence of causal conditions), and it uses
>> the
 venn package to draw a Venn diagram.
 It is debatable if one should assimilate the "venn" package into the QCA
 package (other people might want Venn diagrams but not necessarily the
 other QCA functions).
 
 On the other hand, the package venn would like to use the QCA package to
 demonstrate its abilities to plot Venn diagrams based on truth tables
 produced by the QCA package. Both have very different purposes, yet both
 use functions from each other.
 
 So I'm with Bill Dunlap here that several smaller packages are
>> preferable
 to one larger one, but on the other hand I can't separate those
>> functions
 into a third package: the truth table production is very specific to the
 QCA package, while plotting Venn diagrams is very specific to the venn
 package. I don't see how to separate those functions from their main
 packages and create a third one that each would depend on.
 
 This is just an example, there could be others as well, reason for which
 I am (still) looking for a solution to:
 - preserve the current functionalities in packages A and B (to follow
 Dmitri's original post)
 - be able to use functions from each other
 - yet avoid circular dependency
 
 I hope this explains it,
 Adrian
 
 
 On Thu, Apr 7, 2016 at 11:36 PM, Mark van der Loo <
 mark.vander...@gmail.com> wrote:
 
> At the risk of stating the over-obvious: there's also the option of
> creating just a single package containing all functions. None of the
> functions that create the interdependencies need to be exported that
>> way.
> 
> Btw, his question is probably better at home at the r-package-devel
>> list.
> 
> 
> Best,
> 
> M
> 
> 
> 
> 
> On Thu, Apr 7, 2016, 22:24 Dmitri Popavenko <
>> dmitri.popave...@gmail.com>
> wrote:
> 
>> Hi Thierry,
>> 
>> Thanks for that, the trouble is functions are package specific so
>> moving
>> from one package to another could be a solution, but I would rather
>> save
>> that as a last resort.
>> 
>> As mentioned, creating a package C with all the common functions could
>> also
>> be an option, but this strategy quickly inflates the number of
>> packages
>> on
>> CRAN. If no other option is possible, that could be the way but I was
>> still
>> thinking about a more direct solution if possible.
>> 
>> Best,
>> Dmitri
>> 
>> On Thu, Apr 7, 2016 at 3:47 PM, Thierry Onkelinx <
>> thierry.onkel...@inbo.be>
>> wrote:
>> 
>>> Dear Dmitri,
>>> 
>>> If it's only a small number of functions then move them the relevant
>>> functions for A to B so that B works without A. Then Import these
>> functions
>>> from B in A. Hence A depends on B but B is independent of A.
>>> 
>>> It is requires to move a lot of functions than you better create a
>> package
>>> C with all the common functions. Then A and B im

Re: [Rd] .Internal(quit(...)): system call failed: Cannot allocate memory

[Gregory Warnes]

Try explicitly deleting large data objects by calling `rm`, then `gc`.


On Mon, Nov 23, 2020 at 6:15 AM Tomas Kalibera 
wrote:

> On 11/21/20 6:51 PM, Jan Gorecki wrote:
> > Dear R-developers,
> >
> > Some of the more fat scripts (50+ GB mem used by R) that I am running,
> > when they finish they do quit with q("no", status=0)
> > Quite often it happens that there is an extra stderr output produced
> > at the very end which looks like this:
> >
> > Warning message:
> > In .Internal(quit(save, status, runLast)) :
> >system call failed: Cannot allocate memory
> >
> > Is there any way to avoid this kind of warnings? I am using stderr
> > output for detecting failures in scripts and this warning is a false
> > positive of a failure.
> >
> > Maybe quit function could wait little bit longer trying to allocate
> > before it raises this warning?
>
> If you see this warning, some call to system() or system2() or similar,
> which executes an external program, failed to even run a shell to run
> that external program, because there was not enough memory. You should
> be able to find out where it happens by checking the exit status of
> system().
>
> Tomas
>
>
> >
> > Best regards,
> > Jan Gorecki
> >
> > __
> > 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
>
-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] New pipe operator

[Gregory Warnes]

If we’re being mathematically pedantic, the “pipe” operator is actually
function composition.

That being said, pipes are a simple and well-known idiom. While being less
than mathematically exact, it seems a reasonable   label for the (very
useful) behavior.

On Sat, Dec 5, 2020 at 9:43 PM Abby Spurdle  wrote:

> > This is a good addition
>
> I can't understand why so many people are calling this a "pipe".
> Pipes connect processes, via their I/O streams.
> Arguably, a more general interpretation would include sockets and files.
>
> https://en.wikipedia.org/wiki/Pipeline_(Unix)
> https://en.wikipedia.org/wiki/Named_pipe
> https://en.wikipedia.org/wiki/Anonymous_pipe
>
> As far as I can tell, the magrittr-like operators are functions (not
> pipes), with nonstandard syntax.
> This is not consistent with R's original design philosophy, building
> on C, Lisp and S, along with lots of *important* math and stats.
>
> It's possible that some parties are interested in creating a kind of
> "data pipeline".
> I'm interested in this myself, and I think we could discuss this more.
> But I'm not convinced the magrittr-like operators help to achieve this
> goal.
> Which, in my opinion, would require one to model programs as directed
> graphs, along with some degree of asynchronous input.
>
> Presumably, these operators will be added to R anyway, and (almost) no
> one will listen to me.
>
> So, I would like to make one suggestion:
> Is it possible for these operators to *not* be named:
> The R Pipe
> The S Pipe
> Or anything with a similar meaning.
>
> Maybe tidy pipe, or something else that links it to its proponents?
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [External] Re: New pipe operator

[Gregory Warnes]

My vote is for the consistency of function calls always having parentheses,
including in pipes.  Making them optional only saves two keystrokes, but
will add yet another inconsistency to confuse or trip folks up.

As for the new anonymous function syntax, I would prefer something more
human friendly, perhaps provide “fun” as a shortcut for “function”,
enabling:

DF <- "myfile.csv" %>%
readLines() |>
fun(x) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', x) |>
fun(x) read.csv(text = x)|>
   mutate(
across(2:3,
  fun(col) lapply(col,
   fun(x) eval(parse(text = x))
  )
)
   )

which seems much easier to read and understand, at the cost of only a few
extra characters.

-G

On Mon, Dec 7, 2020 at 11:21 AM Gabor Grothendieck 
wrote:

> On Mon, Dec 7, 2020 at 10:11 AM  wrote:
> > Or, keeping dplyr but with R-devel pipe and function shorthand:
> >
> > DF <- "myfile.csv" %>%
> > readLines() |>
> > \(.) gsub(r'{(c\(.*?\)|integer\(0\))}', r'{"\1"}', .) |>
> > \(.) read.csv(text = .) |>
> > mutate(across(2:3, \(col) lapply(col, \(x) eval(parse(text = x)
> >
> > Using named arguments to redirect to the implicit first does work,
> > also in magrittr, but for me at least it is the kind of thing I would
> > probably regret a month later when trying to figure out the code.
>
> The gsub issue suggests that if one were to start afresh
> that the arguments to gsub (and many other R functions)
> should be rearranged.  Of course, that is precisely what
> the tidyverse did.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] anonymous functions

[Gregory Warnes]

Thanks for expressing this eloquently. I heartily agree.

On Mon, Dec 7, 2020 at 12:04 PM Therneau, Terry M., Ph.D. via R-devel <
r-devel@r-project.org> wrote:

> “The shorthand form \(x) x + 1 is parsed as function(x) x + 1. It may be
> helpful in making
> code containing simple function expressions more readable.”
>
> Color me unimpressed.
> Over the decades I've seen several "who can write the shortest code"
> threads: in Fortran,
> in C, in Splus, ...   The same old idea that "short" is a synonym for
> either elegant,
> readable, or efficient is now being recylced in the tidyverse.   The truth
> is that "short"
> is actually an antonym for all of these things, at least for anyone else
> reading the code;
> or for the original coder 30-60 minutes after the "clever" lines were
> written.  Minimal
> use of the spacebar and/or the return key isn't usually held up as a goal,
> but creeps into
> many practiioner's code as well.
>
> People are excited by replacing "function(" with "\("?  Really?   Are
> people typing code
> with their thumbs?
> I am ambivalent about pipes: I think it is a great concept, but too many
> of my colleagues
> think that using pipes = no need for any comments.
>
> As time goes on, I find my goal is to make my code less compact and more
> readable.  Every
> bug fix or new feature in the survival package now adds more lines of
> comments or other
> documentation than lines of code.  If I have to puzzle out what a line
> does, what about
> the poor sod who inherits the maintainance?
>
>
> --
> Terry M Therneau, PhD
> Department of Health Science Research
> Mayo Clinic
> thern...@mayo.edu
>
> "TERR-ree THUR-noh"
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] the pipe |> and line breaks in pipelines

[Gregory Warnes]

Many languages allow a final backslash (“\”) character to allow an
expression to span multiple lines, and I’ve often wished for this in R,
particularly to allow me to put  `else` on a separate line at the
top-level. It would also allow alignment of infix operators like the new
pipe operator `|>` at the start of a line, which I would heartily endorse.

On Wed, Dec 9, 2020 at 3:58 PM Ben Bolker  wrote:

>Definitely support the idea that if this kind of trickery is going to
> happen that it be confined to some particular IDE/environment or some
> particular submission protocol. I don't want it to happen in my ESS
> session please ... I'd rather deal with the parentheses.
>
> On 12/9/20 3:45 PM, Timothy Goodman wrote:
> > Regarding special treatment for |>, isn't it getting special treatment
> > anyway, because it's implemented as a syntax transformation from x |>
> f(y)
> > to f(x, y), rather than as an operator?
> >
> > That said, the point about wanting a block of code submitted line-by-line
> > to work the same as a block of code submittedr d all at once is a fair
> one.
> > Maybe the better solution would be if there were a way to say "Submit the
> > selected code as a single expression, ignoring line-breaks".  Then I
> could
> > run any number of lines with pipes at the start and no special character
> at
> > the end, and have it treated as a single pipeline.  I suppose that'd need
> > to be a feature offered by the erred environment (RStudio's RNotebooks
> in my
> > case).  I could wrap my pipelines in parentheses (to make the "pipes at
> > start of line" syntax valid R code), and then could use the hypothetical
> > "submit selected code ignoring line-breaks" feature when running just the
> > first part of the pipeline -- i.e., selecting full lines, but starting
> > after the opening paren so as not to need to insert a closing paren.
> >
> > - Tim
> >
> > On Wed, Dec 9, 2020 at 12:12 PM Duncan Murdoch  >
> > wrote:
> >
> >> On 09/12/2020 2:33 p.m., Timothy Goodman wrote:
> >>> If I type my_data_frame_1 and press Enter (or Ctrl+Enter to execute the
> >>> command in the Notebook environment I'm using) I certainly *would*
> >>> expect R to treat it as a complete statement.
> >>>
> >>> But what I'm talking about is a different case, where I highlight a
> >>> multi-line statement in my notebook:
> >>>
> >>>   my_data_frame1
> >>>   |> filter(some_conditions_1)
> >>>
> >>> and then press Ctrl+Enter.
> >>
> >> I don't think I'd like it if parsing changed between passing one line at
> >> a time and passing a block of lines.  I'd like to be able to highlight a
> >> few lines and pass those, then type one, then highlight some more and
> >> pass those:  and have it act as though I just passed the whole combined
> >> block, or typed everything one line at a time.
> >>
> >>
> >> Or, I suppose the equivalent would be to run
> >>> an R script containing those two lines of code, or to run a multi-line
> >>> statement like that from the console (which in RStudio I can do by
> >>> pressing Shift+Enter between the lines.)
> >>>
> >>> In those cases, R could either (1) Give an error message [the current
> >>> behavior], or (2) understand that the first line is meant to be piped
> to
> >>> the second.  The second option would be significantly more useful, and
> >>> is almost certainly what the user intended.
> >>>
> >>> (For what it's worth, there are some languages, such as Javascript,
> that
> >>> consider the first token of the next line when determining if the
> >>> previous line was complete.  JavaScript's rules around this are overly
> >>> complicated, but a rule like "a pipe following a line break is treated
> >>> as continuing the previous line" would be much simpler.  And while it
> >>> might be objectionable to treat the operator %>% different from other
> >>> operators, the addition of |>, which isn't truly an operator at all,
> >>> seems like the right time to consider it.)
> >>
> >> I think this would be hard to implement with R's current parser, but
> >> possible.  I think it could be done by distinguishing between EOL
> >> markers within a block of text and "end of block" marks.  If it applied
> >> only to the |> operator it would be *really* ugly.
> >>
> >> My strongest objection to it is the one at the top, though.  If I have a
> >> block of lines sitting in my editor that I just finished executing, with
> >> the cursor pointing at the next line, I'd like to know that it didn't
> >> matter whether the lines were passed one at a time, as a block, or some
> >> combination of those.
> >>
> >> Duncan Murdoch
> >>
> >>>
> >>> -Tim
> >>>
> >>> On Wed, Dec 9, 2020 at 3:12 AM Duncan Murdoch <
> murdoch.dun...@gmail.com
> >>> > wrote:
> >>>
> >>>  The requirement for operators at the end of the line comes from
> the
> >>>  interactive nature of R.  If you type
> >>>
> >>>my_data_frame_1
> >>>
> >>>  how could R know that you are not done, a

Re: [Rd] [External] Re: 1954 from NA

[Gregory Warnes]

As a side note, for floating point values, the IEEE 754 standard provides for a 
large set of NaN values, making it possible to have multiple types of NAs for 
floating point values...

Sent from my iPad

> On May 25, 2021, at 3:03 PM, Avi Gross via R-devel  
> wrote:
> 
> That helps get more understanding of what you want to do, Adrian. Getting 
> anyone to switch is always a challenge but changing R enough to tempt them 
> may be a bigger challenge. His is an old story. I was the first adopter for 
> C++ in my area and at first had to have my code be built with an all C 
> project making me reinvent some wheels so the same “make” system knew how to 
> build the two compatibly and link them. Of course, they all eventually had to 
> join me in a later release but I had moved forward by then.
> 
> 
> 
> I have changed (or more accurately added) lots of languages in my life and 
> continue to do so. The biggest challenge is not to just adapt and use it 
> similarly to the previous ones already mastered but to understand WHY someone 
> designed the language this way and what kind of idioms are common and useful 
> even if that means a new way of thinking. But, of course, any “older” 
> language has evolved and often drifted in multiple directions. Many now 
> borrow heavily from others even when the philosophy is different and often 
> the results are not pretty. Making major changes in R might have serious 
> impacts on existing programs including just by making them fail as they run 
> out of memory.
> 
> 
> 
> If you look at R, there is plenty you can do in base R, sometimes by standing 
> on your head. Yet you see package after package coming along that offers not 
> just new things but sometimes a reworking and even remodeling of old things. 
> R has a base graphics system I now rarely use and another called lattice I 
> have no reason to use again because I can do so much quite easily in ggplot. 
> Similarly, the evolving tidyverse group of packages approaches things from an 
> interesting direction to the point where many people mainly use it and not 
> base R. So if they were to teach a class in how to gather your data and 
> analyze it and draw pretty pictures, the students might walk away thinking 
> they had learned R but actually have learned these packages.
> 
> 
> 
> Your scenario seems related to a common scenario of how we can have values 
> that signal beyond some range in an out-of-band manner. Years ago we had 
> functions in languages like C that would return a -1 on failure when only 
> non-negative results were otherwise possible. That can work fine but fails in 
> cases when any possible value in the range can be returned. We have languages 
> that deal with this kind of thing using error handling constructs like 
> exceptions.  Sometimes you bundle up multiple items into a structure and 
> return that with one element of the structure holding some kind of return 
> status and another holding the payload. A variation on this theme, as in 
> languages like GO is to have function that return multiple values with one of 
> them containing nil on success and an error structure on failure.
> 
> 
> 
> The situation we have here that seems to be of concern to you is that you 
> would like each item in a structure to have attributes that are recognized 
> and propagated as it is being processed. Older languages tended not to even 
> have a concept so basic types simply existed and two instances of the number 
> 5 might even be the same underlying one or two strings with the same contents 
> and so on. You could of course play the game of making a struct, as mentioned 
> above, but then you needed your own code to do all the handling as nothing 
> else knew it contained multiple items and which ones had which purpose.
> 
> 
> 
> R did add generalized attributes and some are fairly well integrated or at 
> least partially. “Names” were discussed as not being easy to keep around. 
> Factors used their own tagging method that seems to work fairly well but 
> probably not everywhere. But what you want may be more general and not built 
> on similar foundations.
> 
> 
> 
> I look at languages like Python that are arguably more object-oriented now 
> than R is and in some ways can be extended better, albeit not in others. If I 
> wanted to create an object to hold the number 5 and I add methods to the 
> object that allow it to participate in various ways with other objects using 
> the hidden payload but also sometimes using the hidden payload, then I might 
> pair it with the string “five” but also with dozens of other strings for the 
> word representing 5 in many languages. So I might have it act like a number 
> in numerical situations and like text when someone is using it in writing a 
> novel in any of many languages.
> 
> 
> 
> You seem to want to have the original text visible that gives a reason 
> something is missing (or something like that) but have the software TREAT it 
> like it is m

[Rd] zapsmall(x) for scalar x

[Gregory Warnes]

I was quite suprised to discover that applying `zapsmall` to a scalar value has 
no apparent effect.  For example: 

> y <- 2.220446e-16
> zapsmall(y,)
[1] 2.2204e-16

I was expecting zapsmall(x)` to act like

> round(y, digits=getOption('digits'))
[1] 0

Looking at the current source code, indicates that `zapsmall` is expecting a 
vector:

zapsmall <-
function (x, digits = getOption("digits")) 
{
if (length(digits) == 0L) 
stop("invalid 'digits'")
if (all(ina <- is.na(x))) 
return(x)
mx <- max(abs(x[!ina]))
round(x, digits = if (mx > 0) max(0L, digits - as.numeric(log10(mx))) else 
digits)
}

If `x` is a non-zero scalar, zapsmall will never perform rounding.

The man page simply states:
zapsmall determines a digits argument dr for calling round(x, digits = dr) such 
that values close to zero (compared with the maximal absolute value) are 
‘zapped’, i.e., replaced by 0.

and doesn’t provide any details about how ‘close to zero’ is defined. 

Perhaps handling the special when `x` is a scalar (or only contains a single 
non-NA value)  would make sense:

zapsmall <-
function (x, digits = getOption("digits")) 
{
if (length(digits) == 0L) 
stop("invalid 'digits'")
if (all(ina <- is.na(x))) 
return(x)
mx <- max(abs(x[!ina]))
round(x, digits = if (mx > 0 && (length(x)-sum(ina))>1 ) max(0L, digits - 
as.numeric(log10(mx))) else digits)
}

Yielding:

> y <- 2.220446e-16
> zapsmall(y)
[1] 0

Another edge case would be when all of the non-na values are the same:

> y <- 2.220446e-16
> zapsmall(c(y,y))
[1] 2.220446e-16 2.220446e-16

Thoughts?


Gregory R. Warnes, Ph.D.
g...@warnes.net
Eternity is a long time, take a friend!



[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Add first() and last() to utils?

[Gregory Warnes]

Hi all,

I've been using first() and last() for some time instead of x[1] and
x[length(x)] for vectors, and I gradually added methods for lists,
matrices, and data.frames.

In preparing the next release of the 'gdata' package (2.16.1) I settled on
these definitions, which harness the existing methods for head() and tail():

# Simply call 'first' or 'last' with a different default value for 'n'.
first <- function(x, n=1, ...) head(x, n=n, ...)
last  <- function(x, n=1, ...) tail(x, n=n, ...)


This works nicely, but Brian noted that packages 'data.table' and 'xts'
also provide functions/S3 methods for head() and/or tail().

Would it make sense to add these definitions to package 'utils' to make
them generally available?

-Greg

-- 
"Whereas true religion and good morals are the only solid foundations of
public liberty and happiness . . . it is hereby earnestly recommended to
the several States to take the most effectual measures for the
encouragement thereof." Continental Congress, 1778

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] Error loading libraries in MAC

[Gregory Warnes]

I have received a number of reports of problems with recent unversal  
Mac packages from CRAN when used with R 2.4.1.  Has something in the  
build script changed?

-G


On Apr 18, 2007, at 4:49PM , Mayte Suarez-Farinas wrote:

> Hi I just installed the gmodels package
> and the installation was successful but when I was trying to load the
> library I got an error (see below).
> Interesting, yesterday I wrote to the maintainer of RSQLite apckage
> because I got the same error.
> Does somebody knows what is going on ??
>
> thanks,
> Mayte
>
>
> library(gmodels)
> Error in dyn.load(x, as.logical(local), as.logical(now)) :
>   unable to load shared library '/Library/Frameworks/R.framework/
> Versions/2.4/Resources/library/gtools/libs/i386/gtools.so':
>dlopen(/Library/Frameworks/R.framework/Versions/2.4/Resources/
> library/gtools/libs/i386/gtools.so, 6): Library not loaded: /usr/
> local/gcc4.0/i686-apple-darwin8/lib/libgcc_s.1.0.dylib
>Referenced from: /Library/Frameworks/R.framework/Versions/2.4/
> Resources/library/gtools/libs/i386/gtools.so
>Reason: image not found
> Error: package/namespace load failed for 'gmodels'
>
> R.Version()
> $platform
> [1] "i386-apple-darwin8.8.1"
>
> $arch
> [1] "i386"
>
> $os
> [1] "darwin8.8.1"
>
> $system
> [1] "i386, darwin8.8.1"
>
> $status
> [1] ""
>
> $major
> [1] "2"
>
> $minor
> [1] "4.1"
>
> $year
> [1] "2006"
>
> $month
> [1] "12"
>
> $day
> [1] "18"
>
> $`svn rev`
> [1] "40228"
>
> $language
> [1] "R"
>
> $version.string
> [1] "R version 2.4.1 (2006-12-18)"
>
>>
>
> __
> [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.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [Rpy] error in building rpy in linux power-pc[sec=unclassified]

[Gregory Warnes]

Hello Mohar,

This question is outside of the RPy scope.  It looks like the type of  
question that should be posed to the R-devel mailing list:

[EMAIL PROTECTED]


-Greg

On Jun 20, 2007, at 8:25PM , Mohar Chattopadhyay wrote:

> Dear all,
>
> I have encountered errors in compiling R-2.5.0 and R-2.4.0 in a  
> linux machine (power-pc). I can successfully build it from the  
> source code if I do not use the '--enable-R-shlib' option while  
> executing the './configure' command as mentioned in rpy  
> documentation. Using the `--enable-R-shlib' option the configure  
> step is executed properly but the `make' crashes with the following  
> error message:
>
> Rdynload.o(.text+0x1246): In function `GetFullDLLPath':
> /home/mxc/R-2.5.0/src/main/Rdynload.c:850: additional relocation  
> overflows omitted from the output
> collect2: ld returned 1 exit status
> make[3]: *** [libR.so] Error 1
> make[3]: Leaving directory `/home/mxc/R-2.5.0/src/main'
> make[2]: *** [R] Error 2
> make[2]: Leaving directory `/home/mxc/R-2.5.0/src/main'
> make[1]: *** [R] Error 1
> make[1]: Leaving directory `/home/mxc/R-2.5.0/src'
> make: *** [R] Error 1
> Right now I am using an older version of R, R-2.1.0 which did not  
> produce any error during the `build' and `install' stage, however,  
> the recent versions have some problem. R-2.5.0 installs and builds  
> fine on its own. Any insight to this problem will be hugely  
> appreciated.
>
> Regards,
>
> Mohar Chattopadhyay
> -- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> 


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] errors in loading packages (PR#9839)

[Gregory Warnes]

Another way of answering the question:  The gmodels and gregmisc  
package both depend on the gtools package.  Either install that  
first, or tell R to install all dependencies.  From the command line:

install.packages(..., depends=TRUE)

or the equivalent checkbox in the UI.

-G

On Aug 10, 2007, at 1:02AM , Ken Beath wrote:

> On 10/08/2007, at 5:14 AM, [EMAIL PROTECTED] wrote:
>
>> Full_Name: Peter Wickham
>> Version: 2.4.1
>> OS: Mac 10.4.10
>> Submission from: (NULL) (209.59.87.136)
>>
>>
>> Attempted to load "gdata" and "gregmisc" packages after using
>> installing via
>> Package Installer in R. Both load attempts resulted in the
>> following message:
>> "Error in loadNamespace(i[[1]], c(lib.loc, .libPaths())) :  there
>> is no package
>> called 'gtools'". There is no mention of failure in the Mac OSX
>> check summary
>> for packages. Another package "waveslim" installed and loaded
>> properly (apart
>> from the R topic "AR1").
>
> Either use the installer to download gtools etc or check the Install
> Dependencies box and they will all be automatically downloaded.
>
>> I might also mention that I am still using R 2.4.1 tather than R
>> 2.5.1 as I
>> received warning messages in red
>>  R[244] and R[451] "tossing reply message sequence 1 on" when
>> downloading the
>> latest version of R.
>>
>>
>
> This isn't a problem, it still works, there might be a development
> version where it is fixed. For Mac related problems there is a
> special list at https://stat.ethz.ch/mailman/listinfo/r-sig-mac Check
> the archives for discussion of this problem.
>
> Ken
>
> __
> 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] Interactiveness

[Gregory Warnes]

You might also find many of the tools provided in the 'session'  
package helpful for interacting with R in this way.

'session' package description:

Utility functions for interacting with R processes from external  
programs. This package includes functions to save and restore session  
information (including loaded packages, and attached data objects),  
as well as functions to evaluate strings containing R commands and  
return the printed results or an execution transcript.

-Greg


On Dec 11, 2007, at 1:18PM , Tony Plate wrote:

> Bjarni Juliusson wrote:
>> Prof Brian Ripley wrote:
>>
>>> On Tue, 11 Dec 2007, Bjarni Juliusson wrote:
>>>
 I'm developing R integration for a project called Bioclipse at  
 Uppsala
 University. The current implementation works by simply forking  
 an R and
 sending it text (with some substitutions on it) down a pipe,  
 getting the
 printed output back up another pipe. This of course works fine,  
 except
 it runs into one problem: R finds a pipe on its stdin and  
 decides to be
 "non-interactive", which means that as soon as the user makes a  
 typo and
 causes an error, R exits.

>>> Actually, not so.  The default error handler for non-interactive  
>>> use is
>>> to do that, but you can change it.
>>>
>>
>> Could you perhaps just point me in the right direction here? I really
>> have no idea how to do this.
>>
> Specify a non-NULL error handler by doing something like this:
>> options(error=dump.frames)
> See ?options (look for "error") and ?stop for more details.
>
> -- Tony Plate
>
>> Also, what exactly does non-interactive mode imply, besides this  
>> default
>> error handling behaviour?
>>
>>
 I checked the source, and it's a couple of isatty()'s in the two  
 files
 named system.c that are doing it. They are of course intended to  
 be a
 feature, but in this case it causes us trouble. Would it be  
 possible to
 get a command line switch to control this behaviour? I'm not  
 sure pseudo
 terminals can be used portably, or can they?

>>> They can, and are e.g. by ESS (except on Windows, where there is  
>>> already
>>> a switch).  I think you need to look a bit more carefully at what  
>>> other
>>> projects do.
>>>
>>
>> It needs to be portable to Windows. I'll look into this  
>> possibility next.
>>
>> Didn't mean to ask before I had done my homework. Thanks for your  
>> help!
>>
>>
>> Bjarni
>>
>
> __
> 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