gmane.comp.lang.r.devel

Re: Curry: proposed new functional programming, er, function.

Hadley Wickham — 2012-05-25T21:23:59

Yup.  With a bit more infrastructure you could probably modify it so
that multiple curries collapsed into the equivalent single curry.


Yes, that was a really bad idea - not sure why I didn't see the
problems when I first wrote it.


I can see why that's useful at the language level, but I think it
would be confusing to do so in R.

Hadley

Re: equivalent to source() inside a package

Paul Gilbert — 2012-05-25T21:24:34

Is there a reason for not using a vignette or putting a file in the 
demo/  directory?  This seems like the sort of thing for which they are 
intended.

Paul

On 12-05-25 03:33 PM, Wei Hao wrote:

Re: Curry: proposed new functional programming, er, function.

Yike Lu — 2012-05-25T20:14:08

So here's the way I'm reading this:

Original:
curry_call is the function body you're constructing, which is itself 
just a one liner which calls the symbol FUN with the appropriate 
substitutions.

call("function", [...]) calls the "function" function, which itself 
takes 2 arguments: the list of formal args and the function body.
eval of this call returns the newly constructed function, which you 
assign to f. Then you assign the parent.frame() as the environment of f, 
except with the symbol FUN assigned as the original argument FUN.

However, upon looking at the debugger, I find that env$FUN<-FUN assigns 
FUN in Global Scope if Curry is called from the top level.
A nested Curry call then creates FUN=function(...) FUN([...]), a 
recursive infinite loop.

New:
The recursion is obviously removed now, but what's the new version do?

As far as I can tell, it returns  a structure like...

function(...){function(...) {original_function_body(curried_arg, ...=...)}}

Comparing and contrasting to the version in "f

equivalent to source() inside a package

Wei Hao — 2012-05-25T19:33:04

Hi all:

I'm working on a project that I have packaged for ease of
distribution. The different simulations in the package share code, so
obviously I have those parts organized as functions. Now, I want to
show people my code, but the structure with the internal functions
might be a little confusing to follow. One thing I tried was to have
the code of the functions as their own R files in the R/ folder, and
then using source() instead of calling the functions (with consistent
variable names and such) but this didn't work. The goal is for the
user to be able to see the entirety of the code in the interactive R
session, i.e. with a standard package implementation:

function (seed=5555)
{
    [stuff]
    a = internal_function1(data)
    [stuff]
}



I would like the user to see:

function (seed=5555)
{
    [stuff]
    tmp = apply(data,1,mean)
    a = sum(tmp) #or whatever, this is just an example
    [stuff]
}

where I can change those two lines in their own file, and have the
changes apply for all the simulatio

Re: Curry: proposed new functional programming, er, function.

Hadley Wickham — 2012-05-25T13:49:28

That's easily fixed:

Curry <- function(FUN, ...) {
  args <- match.call(expand.dots = FALSE)$...
  args$... <- as.name("...")

  env <- parent.frame()

  if (is.name(FUN)) {
    fname <- FUN
  } else if (is.character(FUN)) {
    fname <- as.name(FUN)
  } else if (is.function(FUN)){
    fname <- FUN
    # env$FUN <- FUN
  } else {
    stop("FUN not function or name of function")
  }
  curry_call <- as.call(c(list(fname), args))

  f <- eval(call("function", as.pairlist(alist(... = )), curry_call))
  environment(f) <- env
  f
}


Curry(Curry(foo,3),4)


I don't think that would be a good idea - there's a big difference
between a function with no arguments and the result of calling that
function.

Hadley

Re: columnames changes behaviour of formula

Joshua Wiley — 2012-05-25T04:52:07

P.S. It really is sloppy code to mix variables from the global
environment with those inside a data frame. I.e.:

coef(lm(d ~ -1 + (.)^2, data = x))

the only time I think it makes sense to have different objects for the
outcome and predictors are when for speed purposes, you are using a
low level function, such as lm.fit or fastLmPure from the RcppEigen
package.


On Thu, May 24, 2012 at 9:46 PM, Joshua Wiley <jwiley.psych< at >gmail.com> wrote:

Re: columnames changes behaviour of formula

Joshua Wiley — 2012-05-25T04:46:46

Hi Robin,

Seems like the intended behavior to me.  From the docs:
"There are two special interpretations of '.' in a formula.  The usual
one is in the context of a 'data' argument of model fitting functions
and means 'all columns not otherwise in the formula' "

d is in the formula so the only column not in the formula is nd.  the
(.)^2 asks for all two way interactions, but with only one variable,
there are none.

What were you expecting?

Josh

On Thu, May 24, 2012 at 9:25 PM, robin hankin <hankin.robin< at >gmail.com> wrote:

columnames changes behaviour of formula

robin hankin — 2012-05-25T04:25:30

Hello. precompiled R-2.15.0, svn58871, macosx 10.7.4.


I have discovered that defining column names of a dataframe can alter the
behaviour of lm():


d <- c(4,7,6,4)
x <- data.frame(cbind(0:3,5:2))
coef(lm(d~ -1 + (.)^2,data=x))
   X1    X2 X1:X2
-1.77  0.83  1.25
R>
R>


OK, so far so good.  But change the column names of 'x' and the behaviour
changes:


colnames(x) <- c("d","nd")   # 'd' == 'death' and 'nd' == 'no death'
coef(lm(d~ -1 + (.)^2,data=x))
       nd
0.2962963



I am not sure if this is consistent with the special meaning of '.'
described under ?formula.

Is this the intended behaviour?

Re: Expected behaviour of is.unsorted?

Duncan Murdoch — 2012-05-24T18:42:52

I don't see why.  t(DF) is not a dataframe, so it will give surprising 
answers in a different way.  If people rely on using code in ways that 
are documented to give unexpected results, they deserve what they get.

I disagree.  I think it is most friendly to implement the function in 
the way it has been documented (even if it hasn't always been behaving 
as documented).

Duncan Murdoch

Re: modifying some package code

Simon Urbanek — 2012-05-24T18:14:08


I'm not sure what *is* your issue. nlms:::inner_perc_table is defined (automatically), so it just works. If you are re-using just the .C part of nlme somewhere else that you dyn-load manually then you can simply use "inner_perc_table" instead.

Cheers,
Simon

Re: Expected behaviour of is.unsorted?

Matthew Dowle — 2012-05-24T17:33:04

If user code or packages start to depend on is.unsorted(t(DF)) it would be
harder to change, no? Why provide something that is unsuitable and allow
that possibility to happen? It's more user friendly to return "not
implemented", "unsuitable", or the nicer message already in the C code,
than leave the door open for confusion and errors. Or in other words, it's
even more user friendly to return a warning or error to the user at the
prompt, than the user friendliness of writing in the help file that it's
unsuitable for data.frame.

Matthew

Re: modifying some package code

Charles Determan Jr — 2012-05-24T17:26:30

Simon,

Thank you for this valuable information.  However, you must forgive some
ignorance on my part.  If R-registerRoutines defines the native function,
how should I go about fixing this issue?  Would I copy the init.c to the
base package (where I have the new function)?

Thanks,
Charles

On Thu, May 24, 2012 at 11:58 AM, Simon Urbanek <simon.urbanek< at >r-project.org


[[alternative HTML version deleted]]

Re: modifying some package code

Simon Urbanek — 2012-05-24T16:58:15

On May 24, 2012, at 12:25 PM, Charles Determan Jr wrote:


The (unexported) object contains cached reference to the native function (see ?getNativeSymbolInfo) and is defined by R_registerRoutines in src/init.c. This is a typical optimization in R packages to avoid costly lookup of symbols and to provide check for native arguments.

Cheers,
Simon

modifying some package code

Charles Determan Jr — 2012-05-24T16:25:41

Greetings,

I am working on modifying some code from the nlme package.  I have had many
discussions on the mixed models mailing list and have been directed to
simply 'hack' the source code to have the degrees of freedom generated by
one function to use in the output of another function that doesn't generate
them.  My current holdup is an error regarding a .c file called
'inner_perc_table' called by the .C function.  The error states that the
object 'inner_perc_table' is not found.  My confusion lies in the fact that
when I run the original script, it recognizes the part just fine.  At no
point is the object defined and I cannot currently find such a code in the
package's source.  Perhaps someone here is familiar with the nlme package
and could assist me in some form.  If you need further information, please
ask as I don't know if there is a general answer for this type of question
or if you will need the actual code.

Regards,
Charles

[[alternative HTML version deleted]]

Re: Expected behaviour of is.unsorted?

Duncan Murdoch — 2012-05-24T15:25:33

I don't see why saying this function is unsuitable for dataframes 
implies that it will never be made suitable for dataframes.

The fix handles the case is.unsorted was designed for:  it checks 
whether x[1] < x[2] < x[3] etc., which it doesn't currently do properly 
for non-atomic objects.

Duncan Murdoch

Re: Expected behaviour of is.unsorted?

Matthew Dowle — 2012-05-24T15:10:07

But that leaves the door open to confusion later, whilst closing the door
to a better solution: making is.unsorted() work by column for data.frame;
i.e., making is.unsorted _suitable_ for data.frame. If you just do the
quick fix for .gtn result you can never go back. If making is.unsorted(DF)
work by column is too hard for now, then leaving the door open would be
better by returning the error message already in the C code: "only atomic
vectors can be tested to be sorted". That would be a better quick fix
since it leaves options for the future.

Re: Expected behaviour of is.unsorted?

Duncan Murdoch — 2012-05-24T13:57:29

Okay, I'm going to fix the handling of .gtn results, and document the 
unsuitability of this
function for dataframes and arrays.

Duncan Murdoch

Re: Expected behaviour of is.unsorted?

Matthew Dowle — 2012-05-24T13:15:32

that's in
expectation
the .gtn

Because then is.unsorted(DF) would work, but go by row, which you guessed above 
wasn't intended and isn't sensible. But once it worked in that way, users might 
start to depend on it; e.g., by writing is.unsorted(t(DF)). If I came 
along in future and suggested that was inefficient and wouldn't it be more 
natural and efficient if is.unsorted(DF) went by column, returning the same as 
with(DF,is.unsorted(order(a,b))) but implemented efficiently, you would fear 
that user code now depended on it going by row and say it was too late. I'd 
persist and highlight that it didn't seem in keeping with the spirit of 
is.unsorted()'s speed since it short circuits on the first unsorted item, which 
is why we love it. You'd reply that's not documented. Which it isn't. And that 
would be the end of that.

Re: New S3 methods for optional package

Jon Olav Skoien — 2012-05-24T13:00:48

Dear Prof. Ripley,
Thanks a lot for your answers!
See inline comments below.

On 24-May-12 12:01, Prof Brian Ripley wrote:

Replacing require with requireNamespace does not seem to work for this 
case, it fails with the error:
Error: object 'estimateParameters' not found whilst loading namespace 
'intamap'
This comes from registerS3methods which cannot find the generic 
estimateParameters from parent.env of B (rtop). Is this because 
loadNamespace does not attach the namespace to the search path?


I really hoped that would not be necessary, but you are probably right 
that it is the only solution if I want to get rid of the note. The 
disadvantage is then that I have to clutter the package repository of 
CRAN with one more package, which only purpose is to load two other 
packages. For me that does not appear as a better solution than having a 
package with a note and use of a function that is not intended. But then 
I am also not sure how much extra work my current solution would give 
the CRAN-maintainers

Re: Expected behaviour of is.unsorted?

Duncan Murdoch — 2012-05-24T12:20:23

I would guess that it was never intended to be used this way.  It is 
intended for to test x[1] < x[2] < x[3] ... for objects where this is a 
sensible calculation; it isn't really sensible for dataframes.


I don't follow the last sentence.  If the .gtn call needs to be negated, 
why would you want to go back?

Duncan Murdoch

Re: Expected behaviour of is.unsorted?

Matthew Dowle — 2012-05-24T11:39:10

Thanks. Yes you're right. So is.unsorted() on a data.frame is trying to tell us 
if there exists any unsorted row, it seems.

  a b
1 1 1               # this row is sorted
2 3 3               # this row is sorted
3 5 5               # this row is sorted
[1] TRUE
[1] FALSE
  a b
1 1 1               # this row is sorted
2 3 2               # this row isn't sorted
3 5 5               # this row is sorted
[1] FALSE
[1] FALSE

Since it seems to have a bug anyway (and if so, can't be correct in anyone's 
use of it), could either is.unsorted on a data.frame return the error that's in 
the C code already: "only atomic vectors can be tested to be sorted", for 
safety and to lessen confusion, or be changed to return the natural expectation 
proposed above? The easiest quick fix would be to negate the result of the .gtn 
call of course, but then you could never go back.

Matthew