Re: [Rd] round() ignores missing arguments if it is used inside another function where some arguments are missing.
On Nov 19, 2011, at 04:35 , Henrik Bengtsson wrote: > On Fri, Nov 18, 2011 at 9:34 AM, Kevin R. Coombes > wrote: >> You can also see the odd behavior without wrapping round in another >> function: >> >>> round(100.1, digits=) >> [1] 100 > > Hmm... is there a reason for why the parser accepts that construct? Yes. See e.g. help(alist) for actual usage. It can also be used to pass empty arguments to FUN in apply-constructs: a <- matrix(1:12, 3, 4) f <- function(i, j) a[i,j] lapply(1:4, f, i=) > Some example: > >> parse(text="f(a=)") > expression(f(a=)) > >> parse(text="f[a=]") > expression(f[a=]) > >> parse(text="(a=)") > Error in parse.default(text = "(a=)") : :1:4: unexpected ')' > 1: (a=) > > /Henrik > >> >> On 11/18/2011 10:19 AM, Joris Meys wrote: >>> >>> On Fri, Nov 18, 2011 at 5:10 PM, Gavin Simpson >>> wrote: round is indicated to not evaluate its arguments. I don't follow the C code well enough to know if it should be catching the missing argument further on - it must be because it is falling back to the default, but the above explains that the not evaluating arguments is intended. G >>> >>> So if I understand it right, the y argument is not evaluated in the >>> fun2 function but deeper in the C code. that explains the lack of the >>> error message, thanks! I keep on learning every day. >>> Cheers >>> >>> Joris >>> >> >> __ >> 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 -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with new srcref warnings in R 2.14 (development)
Dear R developers,
Print method for function now tries to open the source file associated
with srcref of the function.
It outputs only the warning, if file cannot be open, and forgets to
print the function definition.
Example:
eval(parse(text = "tf <- function(a){
b <- a^4
b
}", srcfile = srcfile("xxx@17")))
> tf
Warning message:
In file(srcfile$filename, open = "rt", encoding = encoding) :
cannot open file 'xxx@17': No such file or directory
First, the function definition is not printed and I assume it's a bug.
Second, the warning might not be appropriate.
For example ESS with the latest ess-tracebug
(http://code.google.com/p/ess-tracebug/) inserts srcref into the
function on the fly.
Srcfile is of the form file_name@index where index is used to find the
function definition afterwards.
This is useful for two reasons:
-- the visual debugger knows about the reference and jumps through
the function even if the file was not sourced
-- any typos/errors in the code are reported by R with the source
reference, so that the editor can automatically jump to the error
location.
Can please an option to suppress the warnings or even better suppress
the srcfile validity checks be implemented?
Thanks,
Vitalie.
sessionInfo()
R Under development (unstable) (2011-11-15 r57665)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
LC_TIME=en_US.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows binaries: Version and revision strings show "(2006-00-00 r00000)"
On Fri, 2011-11-18 at 15:30 -0800, Henrik Bengtsson wrote: > Also, "r0" is listed as the revision on: > > http://cran.r-project.org/bin/windows/base/rdevel.html > http://cran.r-project.org/bin/windows/base/rpatched.html > I see these as 2011-11-18 r0 and as built by Duncan Murdoch, who is on the r-devel list. > -- Brian G. Peterson __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [OctDev] Non-free packages in CRAN
Where is the "like" button when you need it? Joris Meys wrote: 2011/11/18 Jordi Gutiérrez Hermoso: I don't see how MOSEK is making free software stronger. It's not encouraging the usage of more free software. It's encouraging the use of MOSEK. MOSEK should not be endorsed by an organisation that is supposed to promote free software. If these really are your views and they're representative of the R project, then the solution seems to be to make R stop calling itself part of the GNU project. I hope it doesn't do this. - Jordi G. H. I'm not going into the discussion about which license represents what. I hate politics and ideological discussions because of all the blabla. I'm a statistician. I work with facts. Fact : Simon is not the R-project, the R-core or the R community. He's one guy, and a pretty smart one that is. Fact : At my department several people use R only because they have access to non-GPL programs through R: because they can load Excel and SPSS files if they have to, connect to SQLServer and Access, ... Fact : They often don't use Octave for exactly the same reason: They don't have access to the tools they need. They're using Matlab instead. We do have SPlus on the servers too. Guess how many people are using that... Fact : I get paid for statistical advice. I pay for a hammer. I pay for a bike. If I have to pay for a tool I need on my computer, I pay for it. If there's a free alternative that can get me as far, I use that one and support their community with a gift if I care enough about the tool. Which reminds me... Fact : If I see too many quasi-religious statements, tool goes out and I leave the building. You're not doing your cause a favor here. Cheers Joris Being religious about free software never helped the cause. And by __ 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] strange behavior from cex="*"
On 18.11.2011 10:14, Patrick Burns wrote:
Someone ambitious could find problems like
this using random input testing like I talked
about at useR last summer.
http://www.burns-stat.com/pages/Present/random_input_test_annotated.pdf
Testing graphics would be more labor intensive
than the testing I do, but you could think of it
as a video game.
See also the graphicsQC package.
Uwe
On 17/11/2011 00:29, Duncan Murdoch wrote:
On 11-11-16 5:26 PM, Ben Bolker wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11-11-16 05:18 PM, peter dalgaard wrote:
>>
>> On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
>>
>>> Someone inquired on StackOverflow about apparently non-deterministic
>>> graphics behaviour in R. I noticed that they were using cex="*" and
>>> discovered some potentially weird behavior.
>>
>> It can be reproduced much more simply (well, not the hang, but bad
>> enough):
>>
>> In a plain R application console (OSX Snow Leopard),
>>
>> for (i in 1:100) plot(1:10,cex="*")
>>
>> will _sometimes_ show big circles, indicating random data being
>> picked up.
>>
>> The "cex" is by definition numeric, so you can't expect to be able to
>> pass a character string, but the code should check.
>
> Looks (?) like the check could go in FixupCex (which already tests for
> isReal, isInteger, and isLogical) in src/main/plot.c , unless there
is a
> wish to catch it earlier/in R code.
Yes, that's where the check was missed. I'll fix it. The other
parameters appear to have been checked properly.
> It's mildly surprising to me that people can continue to find odd
> cases like this after more than 10 years (and imagine how many
> cumulative hours of R use ...) [I'm assuming that this hole has been
> present for a log time: I don't have the patience to do the SVN
> archaeology to find out how long.]
So now you can prove me wrong about the other parameters...
Duncan Murdoch
>
>>
>>>
>>> On repeated runs of the same code I can get different PNGs. If I set
>>> the number of runs high enough, I seem to be able to get R to hang.
>>> If I do a single version plotting to an interactive graphics window I
>>> can get the point sizes to jump around as I resize the window
(someone
>>> reported being able to reproduce that behaviour in the Windows GUI
>>> as well).
>>>
>>> This is clearly a user error, but non-deterministic behaviour (and
>>> hanging) are a little disturbing.
>>>
>>> I haven't had a chance yet to try to dig in and see what's happening
>>> but thought I would report to see if anyone else could
reproduce/figure
>>> it out.
>>>
>>> Ben Bolker
>>>
>>>
>>>
>>> ## n<- 100 ## hangs R
>>>
>>> n<- 33
>>>
>>> fn<- paste("tmp",seq(n),"png",sep=".")
>>> for (i in seq(n)) {
>>> png(fn[i])
>>> plot(1:10,1:10,cex="*");
>>> dev.off()
>>> }
>>>
>>> ff<- subset(file.info(fn),select=size)
>>> ff<- ff[!duplicated(ff$size),,drop=FALSE]
>>> table(ff$size)
>>> require(png)
>>> pngs<- lapply(rownames(ff),readPNG)
>>>
>>> png.to.img<- function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
>>> nrow=dim(x)[1],ncol=dim(x)[2])
>>>
>>> imgs<- lapply(pngs,png.to.img)
>>>
>>> par(mfrow=c(2,2))
>>> lapply(imgs,function(x) {
>>> plot(0:1,0:1,type="n",ann=FALSE,axes=FALSE)
>>> rasterImage(x,0,0,1,1)
>>> })
>>>
>>> #
>>>
sessionInfo()
>>> R Under development (unstable) (2011-10-06 r57181)
>>> Platform: i686-pc-linux-gnu (32-bit)
>>>
>>> attached base packages:
>>> [1] stats graphics grDevices utils datasets methods base
>>>
>>> other attached packages:
>>> [1] glmmADMB_0.6.5 MASS_7.3-14 png_0.1-3
>>>
>>> loaded via a namespace (and not attached):
>>> [1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102 tools_2.15.0
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOxDiKAAoJED2whTVMEyK9ThoIAIjyMpzZqsjUpJVbAb9K8IrL
> LbSFh8zb+cZb90ABkFwJaZ2FNTKCjPrUzOYzxxHuU9AY0bdPQGbIm2hvQfzcuMlc
> urS/ILIMzZEFSYkqkj0mWI9SADyJ+W0YeN/t3EuWy8nZqUkYQZ8M0GsuXjhtUL/i
> hVJU0uuIWCOCHpeI3SQKoxviTE6MQFRXXWhCAJx01h8ee/5UQ5GSGB7Er2Zilld3
> 0sLI6dmoF7gbeYqz33MaEpQ7geJoW3tfnVbQWUlF86+jGGv5trIqWYIp33OYIxMO
> u2YUq51vB+4uIRPFJ4Oyr+nJF0Z9NH4IJBipp/bF6wQ5u6JdXFqKTPeQ1V6m5qk=
> =YajM
> -END PGP SIGNATURE-
>
> __
> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
