Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Peter Dalgaard wrote: Paul Murrell <[EMAIL PROTECTED]> writes: I think the ideal would be to set padj automatically for multi-line text as well as single-line text (the current behaviour tries to set padj automatically for single-line text; it's just not very good at it :). But whatever first step is good; then we can more easily discuss actual behaviour and code examples. A somewhat uninformed conjecture: You'll need to look at the TeXbook again. Think of it like this: A single line of text forms a box that has a top, a bottom, and a baseline, and you can align on either or on some fraction between top and bottom. Multiple lines form a box too, but you need a way to specify whether the baseline of the entire box is defined by the top or the bottom line inside of it. In addition, you need to specify alignment inside the box. Basically, we need a more structured approach than a bunch of options that change meaning depending on the setting of other options. I think we already have that (more or less), and we don't want to re-implement TeX, I hope (in this case I'm the wrong person given my capabilities ;-)). There is a top and a bottom and the bottom line defined as a baseline. Then we have (speaking about mtext() now) "adj" that controls the right/left adjustment in reading direction. What we do not have is adjustment in the perpendicular reading direction - it's simply a fixed value that can only be controlled using "at". All the stuff does not change meaning depending on other options, only the defaults are sometimes changing (in order not be be completely ugly). My aim is (a) to provide the missing argument and (b) to set more sensible defaults than that one we already have. It's not that easy doing it without breaking code. Uwe __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function bug (PR#7199)
Its there so people can be lazy and say s= instead of sb=. That sort of thing happens all the time in interactive environments. However, I'd hardly call it obfuscating---it doesn't reverse a known practice within the language domain, though its activity is apparently somewhat surprising. No worse than the effects of lexical scoping. Also, if people don't read the manual, how are they to learn the language? Its like saying you should make Scheme's macro syntax understandable at first glance. Unfortunately, the result is C's macro syntax (it you can call it that). On Aug 24, 2004, at 3:34 PM, Peter Kleiweg wrote: Prof Brian Ripley schreef: This is _not_ a bug. Please read `R Language Manual', section 4.3.2 Found it, without section numbers. I read it, and I can't think why anyone would come up with such a scheme. It goes against all practices in other programming languages. It is obfuscating. It's like designing a language where 'if' actually means 'unless', just so you can chide some more people for not reading the manual. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel --- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Paul Murrell <[EMAIL PROTECTED]> writes: > > I think the ideal would be to set padj automatically for multi-line > text as well as single-line text (the current behaviour tries to set > padj automatically for single-line text; it's just not very good at > it :). > But whatever first step is good; then we can more easily discuss > actual behaviour and code examples. A somewhat uninformed conjecture: You'll need to look at the TeXbook again. Think of it like this: A single line of text forms a box that has a top, a bottom, and a baseline, and you can align on either or on some fraction between top and bottom. Multiple lines form a box too, but you need a way to specify whether the baseline of the entire box is defined by the top or the bottom line inside of it. In addition, you need to specify alignment inside the box. Basically, we need a more structured approach than a bunch of options that change meaning depending on the setting of other options. -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7199) function bug
Peter Kleiweg <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] schreef: > > > This is a misunderstanding, I think, not a bug. R is using partial > > matching and the `2', since it is not named, is being sent through the > > `...'. > > That is not very sensible behaviour, and it certainly doesn't > explain why 2 is set equal to 3. It isn't. The arguments are switched around. Like plot(1,x=0) plots a point at (0,1), a fact that is sometimes used in connection with the apply()-family of functions. Given that we allow partial matching, this effect is pretty much unavoidable. However, the partial matching is probably a feature regretted by its designer for reasons of examples like this. Trying to remove the feature from the language at this stage is going to be pretty painful! -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Hi
Uwe Ligges wrote:
Paul Murrell wrote:
Hi
Uwe Ligges wrote:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Dear all,
Our quite basic function mtext() does wrong adjustments in some
parameter
configurations. This gets obvious when using multi line texts:
There is no
way to properly adjust text perpendicular to axis 2, for example.
Best
Jens Oehlschlägel
m <- matrix(1:9, 3)
colnames(m) <- c("several\nlines", "several\nlines", "several\nlines")
par(mfrow=c(2,2))
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="las=0
adj=0.5 is
fine")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="las=0
adj=1 is
different")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=1)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="las=1
adj=0.5 is
NOT fine")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="at las=1,
adj=1
works the wrong direction", sub="no way to get adj=c(1, 0.5) with
las=1 (or
2)")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=1)
par(mfrow=c(1,1))
Left / right adjustemnt seems to be perfectly OK.
The thing that matters is centering "several lines" to the specified
("at=") location.
In fact, mtext() is not centering but bottom-aligning by adding a
negative distance that looks OK for one line in the default font
size, but not in most other cases.
Hence this is the same as Paul Murrell's PR#1659 ("mtext() alignment
of perpendicular text"). Fixing this, and/or improving mtext()'s
"adj" argument to accept 2 dimensions is desirable, but might be not
that easy... I'll take a look during the next days, but nothing
promised.
Uwe Ligges
Having looked into the code, there are three possible solution (all with
some drawbacks) I can see. Well, the current argument "adj" becomes
"xadj" in the C sources (graphics.c, GMtext), and "yadj" is set to 0.
Hence the ugly hard coded LineBias of 0.3.
Solutions
=
1: Hardcode "yadj" to 0.5 and remove all those 0.3 biases. Looks good
for axes, but it might break some code --> bad.
On the other hand, GMMathText has hardcoded yadj=0.5. Is there a
problem with some special devices? Or any other reason not to center
stuff using "adj=0.5"?
2: Allow the typical 2-value adj, take the first as xadj, the second one
as yadj. This might break some code, because currently adj of
arbitrary length (!=0) is allowed and recycled.
3: Invent an argument "padj" for mtext() that represents adjustment
*p*erpendicular to the text direction and gets mapped to "yadj" in
GMtext. In that case the hardcoded 0.3 bias mentioned above can be
removed. The question is whether to set the default to 0.5 (will still
break code, but easily to fix by setting padj to 0).
I'd like to propose the third solution and would be happy to provide a
patch of GMText, including corresponding patches to GMMathText, as
well as mtext(), title() and axis() (and their inderlying do_*
components).
Are there any objections? Any reasons not to do it?
It hurts my head to think about this stuff. There are so many
combinations to worry about:
(i) The las setting
(ii) The axis (bottom, left, top, right)
(iii) Whether adj has been specified
(iv) Whether the text is multi-line
I think mtext() does ok as long as adj is not specified and the text
is single-line.
Unfortunately it does *not* (using axis() here for simplicity):
plot(1:10)
axis(3, cex.axis=5, las=2)
Good point :)
I would suggest addressing the multi-line problem for unspecified adj
as a first step. And I will definitely not mourn the passing of the
0.3 constant. Setting yadj to 0.5 is not enough though because that
doesn't make sense for multi-line text that is parallel to an axis (in
that case, yadj should probably be 0 for axis 2 and 3 and 1 for axis 1
and 4; did I mention that there are lots of combinations to worry
about?).
I think most of the stuff is already quite pretty.
The point is whether we are going to distinguish cases for
(p)adj={0,0.5,1} automatically or not. If the latter, we can omit
several of the cases mentioned above in (i)-(iv).
I think - as the first step - we should set the default to center (note
that text() does so as well), and let the user change padj for
multi-line text as required.
I think the ideal would be to set padj automatically for multi-line text
as well as single-line text (the current behaviour tries to set padj
automatically for single-line text; it's just not very good at it :).
But whatever first step is good; then we can more easily discuss actual
behaviour and code examples.
I'll try to provide a collection of patches as a proposal within, say,
two weeks.
Great (modulo version scheduling issues discussed elsewhere).
Thanks Uwe!
Paul
For user-specified adj, I agree that a 2-value adj is not a good
solution (adj is assumed to be horizo
Re: [Rd] License of Mathlib
Dear Prof Ripley Thank you for this clarification. Best regards Christian Stratowa Prof Brian D Ripley wrote: On Tue, 24 Aug 2004, cstrato wrote: Dear R-Developers I have a question regarding the license of Mathlib: Is the license GPL or LGPL? I am confused, since the file "nmath.h" mentions GPL in the header, while the file "Rmath.h0.in" mentions LGPL in the header. More importantly, the C code of the functions is under GPL. It is only the public header files (and nmath.h is private) that have LGPL in them. See the file COPYRIGHTS (which you seem not to be aware of). __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
Prof Brian Ripley schreef: > > > This is _not_ a bug. Please read `R Language Manual', section 4.3.2 Found it, without section numbers. I read it, and I can't think why anyone would come up with such a scheme. It goes against all practices in other programming languages. It is obfuscating. It's like designing a language where 'if' actually means 'unless', just so you can chide some more people for not reading the manual. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
> From: Prof Brian Ripley > > On Tue, 24 Aug 2004, Peter Kleiweg wrote: > > > Liaw, Andy schreef: > > > > > This is _not_ a bug. Please read `R Language Manual', > section 4.3.2 > > > > I don't have the `R Language Manual'. Is it explained somewhere > > in the docs that come with R? > > Amongst the docs that come with R is the `R Language > Definition' manual. Maybe it would be a good idea to make the menu entries under Help/Manuals in Rgui on Windows correspond to the actual titles of the manuals? Best, Andy > File doc/manual/R-lang.texi, before processing. People are > quoting the > section numbers in the HTML/PDF conversion. > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > > __ > [EMAIL PROTECTED] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to correct problems with classes in namespaces
Prof Brian Ripley wrote:
>
> John,
>
> Looks like several packages are failing to dump or load with messages like
> (SparseM)
>
> Error in warning("Undefined slot classes in definition of \"",
> [EMAIL PROTECTED], :
> Object "classDef" not found
>
> So far I have seen this with SparseM, dynamicGraph (and hence deal and
> gRbase). Should that be `ClassDef'?
It should. Thanks.
> And is this a new error detected?
You mean a new test? Yes, there's a sufficient chance of a typo-- that
the user didn't really mean to insert an undefined class as a slot --
that a warning (not an errorr) seems desirable. (S3 classes are fine as
slots, but unless setOldClass is used they can't be verified.)
John
>
> Brian
>
> On Tue, 24 Aug 2004, John Chambers wrote:
>
> > An extensive set of changes to the methods package has been committed
> > today to allow non-exported classes from packages with namespaces (and
> > some related fixes in dealing with generic functions from namespaces as
> > well).
> >
> > The namespace mechanism requires packages to export any class
> > definitions that are part of the API. Unfortunately, NOT exporting
> > classes has never really worked.
> >
> > The problem was essentially that computations such as method dispatch
> > used the character-string name of a class, with no information about
> > where that class came from. For non-exported classes, this caused many
> > computations down the line to fail. Related problems came from not
> > using the generic function objects and the class definition objects.
> >
> > The modified code passes the usual check and check-devel tests, plus
> > some tests for dealing with private classes, but if you have packages
> > that use methods extensively, please try these with the current r-devel
> > as soon as possible.
> >
> > John
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
--
John M. Chambers [EMAIL PROTECTED]
Bell Labs, Lucent Technologiesoffice: (908)582-2681
700 Mountain Avenue, Room 2C-282 fax:(908)582-3340
Murray Hill, NJ 07974web: http://www.cs.bell-labs.com/~jmc
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
On Tue, 24 Aug 2004, Peter Kleiweg wrote: > Liaw, Andy schreef: > > > This is _not_ a bug. Please read `R Language Manual', section 4.3.2 > > I don't have the `R Language Manual'. Is it explained somewhere > in the docs that come with R? Amongst the docs that come with R is the `R Language Definition' manual. File doc/manual/R-lang.texi, before processing. People are quoting the section numbers in the HTML/PDF conversion. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7199) function bug
[EMAIL PROTECTED] schreef: > This is a misunderstanding, I think, not a bug. R is using partial > matching and the `2', since it is not named, is being sent through the > `...'. That is not very sensible behaviour, and it certainly doesn't explain why 2 is set equal to 3. -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
> I don't have the `R Language Manual'. Is it explained somewhere > in the docs that come with R? See: /doc/manual/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
typo in R-lang (was RE: [Rd] function bug (PR#7199))
BTW, there's a small typo in section 4.1.2 of that manual. `A an argument
that is ...' should be `An argument that is ...'.
Andy
> From: Liaw, Andy
>
> This is _not_ a bug. Please read `R Language Manual',
> section 4.3.2 (as
> well as the R FAQ on what constitute a bug).
>
> Andy
>
> > From: [EMAIL PROTECTED]
> >
> > The following code prints [1] 2, as it should
> >
> > temp<-function(ab,...){
> > print(ab)
> > }
> > temp(2,s=3)
> >
> > However, this code prints [1] 3:
> >
> > temp<-function(sb,...){
> > print(sb)
> > }
> > temp(2,s=3)
> >
> > It should still print [1] 2. It appears
> > that if a variable in ... begins with the same letter as
> > another variable,
> > the value in the variable in ... overwrites the value in the
> > variable with
> > the same first letter.
> >
> > I didn't see this bug reported elsewhere.
> >
> > Richard Morey
> >
> > --
> > Richard Morey
> > Graduate Research Assistant, Cognition and Neuroscience
> > University of Missouri-Columbia
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
Liaw, Andy schreef: > This is _not_ a bug. Please read `R Language Manual', section 4.3.2 I don't have the `R Language Manual'. Is it explained somewhere in the docs that come with R? -- Peter Kleiweg http://www.let.rug.nl/~kleiweg/ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License of Mathlib
On Tue, 24 Aug 2004, cstrato wrote: > Dear R-Developers > > I have a question regarding the license of Mathlib: > Is the license GPL or LGPL? > > I am confused, since the file "nmath.h" mentions GPL in the header, > while the file "Rmath.h0.in" mentions LGPL in the header. More importantly, the C code of the functions is under GPL. It is only the public header files (and nmath.h is private) that have LGPL in them. See the file COPYRIGHTS (which you seem not to be aware of). -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
I think you mean
`I apologize for wasting your time by sending the same incorrect idea to
both R-help and R-bugs without doing my homework.'
It is *not* OK for those who have to clear up after you.
On Tue, 24 Aug 2004, Richard Morey wrote:
> Ok, thanks.
>
> On Tue, 24 Aug 2004, Liaw, Andy wrote:
>
> > This is _not_ a bug. Please read `R Language Manual', section 4.3.2 (as
> > well as the R FAQ on what constitute a bug).
> >
> > Andy
> >
> > > From: [EMAIL PROTECTED]
> > >
> > > The following code prints [1] 2, as it should
> > >
> > > temp<-function(ab,...){
> > > print(ab)
> > > }
> > > temp(2,s=3)
> > >
> > > However, this code prints [1] 3:
> > >
> > > temp<-function(sb,...){
> > > print(sb)
> > > }
> > > temp(2,s=3)
> > >
> > > It should still print [1] 2. It appears
> > > that if a variable in ... begins with the same letter as
> > > another variable,
> > > the value in the variable in ... overwrites the value in the
> > > variable with
> > > the same first letter.
> > >
> > > I didn't see this bug reported elsewhere.
> > >
> > > Richard Morey
> > >
> > > --
> > > Richard Morey
> > > Graduate Research Assistant, Cognition and Neuroscience
> > > University of Missouri-Columbia
> > >
> > > __
> > > [EMAIL PROTECTED] mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> > >
> >
> >
> > --
> > Notice: This e-mail message, together with any attachments, contains information
> > of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889),
> > and/or its affiliates (which may be known outside the United States as Merck
> > Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be
> > confidential, proprietary copyrighted and/or legally privileged. It is intended
> > solely for the use of the individual or entity named on this message. If you are
> > not the intended recipient, and have received this message in error, please notify
> > us immediately by reply e-mail and then delete it from your system.
> > --
> >
>
> --
> Richard Morey
> Graduate Research Assistant, Cognition and Neuroscience
> University of Missouri-Columbia
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
Ok, thanks.
On Tue, 24 Aug 2004, Liaw, Andy wrote:
> This is _not_ a bug. Please read `R Language Manual', section 4.3.2 (as
> well as the R FAQ on what constitute a bug).
>
> Andy
>
> > From: [EMAIL PROTECTED]
> >
> > The following code prints [1] 2, as it should
> >
> > temp<-function(ab,...){
> > print(ab)
> > }
> > temp(2,s=3)
> >
> > However, this code prints [1] 3:
> >
> > temp<-function(sb,...){
> > print(sb)
> > }
> > temp(2,s=3)
> >
> > It should still print [1] 2. It appears
> > that if a variable in ... begins with the same letter as
> > another variable,
> > the value in the variable in ... overwrites the value in the
> > variable with
> > the same first letter.
> >
> > I didn't see this bug reported elsewhere.
> >
> > Richard Morey
> >
> > --
> > Richard Morey
> > Graduate Research Assistant, Cognition and Neuroscience
> > University of Missouri-Columbia
> >
> > __
> > [EMAIL PROTECTED] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
>
> --
> Notice: This e-mail message, together with any attachments, contains information of
> Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889),
> and/or its affiliates (which may be known outside the United States as Merck Frosst,
> Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be confidential,
> proprietary copyrighted and/or legally privileged. It is intended solely for the use
> of the individual or entity named on this message. If you are not the intended
> recipient, and have received this message in error, please notify us immediately by
> reply e-mail and then delete it from your system.
> --
>
--
Richard Morey
Graduate Research Assistant, Cognition and Neuroscience
University of Missouri-Columbia
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] function bug (PR#7199)
This is _not_ a bug. Please read `R Language Manual', section 4.3.2 (as
well as the R FAQ on what constitute a bug).
Andy
> From: [EMAIL PROTECTED]
>
> The following code prints [1] 2, as it should
>
> temp<-function(ab,...){
> print(ab)
> }
> temp(2,s=3)
>
> However, this code prints [1] 3:
>
> temp<-function(sb,...){
> print(sb)
> }
> temp(2,s=3)
>
> It should still print [1] 2. It appears
> that if a variable in ... begins with the same letter as
> another variable,
> the value in the variable in ... overwrites the value in the
> variable with
> the same first letter.
>
> I didn't see this bug reported elsewhere.
>
> Richard Morey
>
> --
> Richard Morey
> Graduate Research Assistant, Cognition and Neuroscience
> University of Missouri-Columbia
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#7199) function bug
This is a misunderstanding, I think, not a bug. R is using partial
matching and the `2', since it is not named, is being sent through the
`...'.
-roger
[EMAIL PROTECTED] wrote:
> output of R.version
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status
> major1
> minor9.1
> year 2004
> month06
> day 21
> language R
>
> The following code prints [1] 2, as it should
>
> temp<-function(ab,...){
> print(ab)
> }
> temp(2,s=3)
>
> However, this code prints [1] 3:
>
> temp<-function(sb,...){
> print(sb)
> }
> temp(2,s=3)
>
> It should still print [1] 2. It appears
> that if a variable in ... begins with the same letter as another variable,
> the value in the variable in ... overwrites the value in the variable with
> the same first letter.
>
> I didn't see this bug reported elsewhere.
>
> Richard Morey
>
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] function bug (PR#7199)
output of R.version
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major1
minor9.1
year 2004
month06
day 21
language R
The following code prints [1] 2, as it should
temp<-function(ab,...){
print(ab)
}
temp(2,s=3)
However, this code prints [1] 3:
temp<-function(sb,...){
print(sb)
}
temp(2,s=3)
It should still print [1] 2. It appears
that if a variable in ... begins with the same letter as another variable,
the value in the variable in ... overwrites the value in the variable with
the same first letter.
I didn't see this bug reported elsewhere.
Richard Morey
--
Richard Morey
Graduate Research Assistant, Cognition and Neuroscience
University of Missouri-Columbia
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] License of Mathlib
Dear R-Developers I have a question regarding the license of Mathlib: Is the license GPL or LGPL? I am confused, since the file "nmath.h" mentions GPL in the header, while the file "Rmath.h0.in" mentions LGPL in the header. Best regards Christian _._._._._._._._._._._._._._._._ C.h.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a A.u.s.t.r.i.a _._._._._._._._._._._._._._._._ __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to correct problems with classes in namespaces
John,
Looks like several packages are failing to dump or load with messages like
(SparseM)
Error in warning("Undefined slot classes in definition of \"",
[EMAIL PROTECTED], :
Object "classDef" not found
So far I have seen this with SparseM, dynamicGraph (and hence deal and
gRbase). Should that be `ClassDef'? And is this a new error detected?
Brian
On Tue, 24 Aug 2004, John Chambers wrote:
> An extensive set of changes to the methods package has been committed
> today to allow non-exported classes from packages with namespaces (and
> some related fixes in dealing with generic functions from namespaces as
> well).
>
> The namespace mechanism requires packages to export any class
> definitions that are part of the API. Unfortunately, NOT exporting
> classes has never really worked.
>
> The problem was essentially that computations such as method dispatch
> used the character-string name of a class, with no information about
> where that class came from. For non-exported classes, this caused many
> computations down the line to fail. Related problems came from not
> using the generic function objects and the class definition objects.
>
> The modified code passes the usual check and check-devel tests, plus
> some tests for dealing with private classes, but if you have packages
> that use methods extensively, please try these with the current r-devel
> as soon as possible.
>
> John
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] error when unsubscribe (PR#7198)
R-bugs is not a mailing list: have you sent this to the wrong place?
On Tue, 24 Aug 2004 [EMAIL PROTECTED] wrote:
> Full_Name: Huan Huang
> Version: 1.9.1
> OS: Win NT
> Submission from: (NULL) (155.140.122.227)
>
>
> Traceback:
>
> Traceback (most recent call last):
> File "/scratch/local/app/mailman-sfs/2.1.5/scripts/driver", line 87, in
> run_main
> main()
> File "/scratch/local/app/mailman-sfs/2.1.5/Mailman/Cgi/options.py", line 91,
> in main
> language = cgidata.getvalue('language')
> File "/scratch/local/app/python/2.3/lib/python2.3/cgi.py", line 560, in
> getvalue
> if key in self:
> File "/scratch/local/app/python/2.3/lib/python2.3/cgi.py", line 611, in
> __contains__
> raise TypeError, "not indexable"
> TypeError: not indexable
>
>
>
>
>
>
>
> Python information:
> Variable Value
> sys.version 2.3 (#1, Oct 16 2003, 05:04:34) [GCC 3.2.2 20030222 (Red Hat Linux
> 3.2.2-5)]
> sys.executable /scratch/local/app/python/current/bin/python
> sys.prefix /scratch/local/app/python/current
> sys.exec_prefix /scratch/local/app/python/current
> sys.path /scratch/local/app/python/current
> sys.platform linux2
>
>
>
>
>
>
> Environment variables:
> Variable Value
> force_response_1_0 1
> SSL_SERVER_I_DN_OU Department of Mathematics
> SSL_CIPHER_EXPORT false
> SSL_SERVER_S_DN_Email [EMAIL PROTECTED]
> SERVER_SOFTWARE Apache/2.0.48 (Unix)
> SSL_VERSION_INTERFACE mod_ssl/2.0.48
> SCRIPT_NAME /mailman/options
> SSL_SERVER_A_KEY rsaEncryption
> SSL_SERVER_S_DN_ST Switzerland
> SERVER_SIGNATURE Apache/2.0.48 (Unix) Server at stat.ethz.ch Port 443
> REQUEST_METHOD POST
> PATH_INFO /r-help
> SERVER_PROTOCOL HTTP/1.1
> SSL_SERVER_S_DN /C=CH/ST=Switzerland/L=Zurich/O=ETH Zurich/OU=Seminar for
> Statistics/CN=stat.ethz.ch/[EMAIL PROTECTED]
> SSL_CIPHER RC4-MD5
> SSL_SERVER_V_START Jan 9 12:56:05 2004 GMT
> SSL_SESSION_ID 210587E0DB04D2F7DAF67D64B4E9DDBA2F059B4E0671DD165F319D9EB1BB2057
>
> CONTENT_LENGTH 83
> SSL_CLIENT_VERIFY NONE
> SSL_SERVER_I_DN_ST Switzerland
> SSL_SERVER_S_DN_O ETH Zurich
> HTTP_REFERER https://stat.ethz.ch/mailman/listinfo/r-help,
> https://stat.ethz.ch/mailman/listinfo/r-help
> SERVER_NAME stat.ethz.ch
> REMOTE_ADDR 155.140.122.227
> SSL_CIPHER_ALGKEYSIZE 128
> SSL_SERVER_I_DN /C=CH/ST=Switzerland/L=Zurich/O=ETH Zurich/OU=Department of
> Mathematics/CN=ISG D-MATH/[EMAIL PROTECTED]
> SSL_SERVER_I_DN_C CH
> SSL_SERVER_M_VERSION 1
> SSL_SERVER_I_DN_O ETH Zurich
> SERVER_ADDR 129.132.148.136
> DOCUMENT_ROOT /var/www/vhosts/sfs/htdocs
> SSL_SERVER_S_DN_OU Seminar for Statistics
> SERVER_PORT 443
> SSL_SERVER_I_DN_Email [EMAIL PROTECTED]
> SSL_VERSION_LIBRARY OpenSSL/0.9.7a
> PYTHONPATH /scratch/local/app/mailman-sfs/2.1.5
> SCRIPT_FILENAME /var/www/vhosts/sfs/mailman/options
> SERVER_ADMIN [EMAIL PROTECTED]
> SCRIPT_URI https://stat.ethz.ch/mailman/options/r-help
> SSL_SERVER_A_SIG md5WithRSAEncryption
> SSL_SERVER_S_DN_L Zurich
> HTTP_HOST stat.ethz.ch
> SCRIPT_URL /mailman/options/r-help
> HTTPS on
> SSL_SERVER_I_DN_L Zurich
> HTTP_CONNECTION Keep-Alive
> PATH_TRANSLATED /var/www/vhosts/sfs/htdocs/r-help
> HTTP_CACHE_CONTROL no-cache
> SSL_SERVER_S_DN_C CH
> REQUEST_URI /mailman/options/r-help
> HTTP_ACCEPT application/vnd.ms-excel, application/msword,
> application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg,
> image/pjpeg, */*
> SSL_SERVER_M_SERIAL 13
> SSL_SERVER_S_DN_CN stat.ethz.ch
> HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; H010818; (R1
> 1.3))
> nokeepalive 1
> GATEWAY_INTERFACE CGI/1.1
> SSL_PROTOCOL SSLv3
> REMOTE_PORT 39557
> HTTP_ACCEPT_LANGUAGE en-gb, en-gb
> HTTP_ACCEPT_ENCODING gzip, deflate, gzip, deflate
> ssl_unclean_shutdown 1
> SSL_SERVER_V_END Jan 6 12:56:05 2014 GMT
> CONTENT_TYPE application/x-www-form-urlencoded,
> application/x-www-form-urlencoded
> SSL_SERVER_I_DN_CN ISG D-MATH
> QUERY_STRING
> SSL_CIPHER_USEKEYSIZE 128
> downgrade_1_0 1
> UNIQUE_ID pOtOOYGElIIAAAlOUt0D
>
> __
> [EMAIL PROTECTED] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changes to correct problems with classes in namespaces
An extensive set of changes to the methods package has been committed today to allow non-exported classes from packages with namespaces (and some related fixes in dealing with generic functions from namespaces as well). The namespace mechanism requires packages to export any class definitions that are part of the API. Unfortunately, NOT exporting classes has never really worked. The problem was essentially that computations such as method dispatch used the character-string name of a class, with no information about where that class came from. For non-exported classes, this caused many computations down the line to fail. Related problems came from not using the generic function objects and the class definition objects. The modified code passes the usual check and check-devel tests, plus some tests for dealing with private classes, but if you have packages that use methods extensively, please try these with the current r-devel as soon as possible. John -- John M. Chambers [EMAIL PROTECTED] Bell Labs, Lucent Technologiesoffice: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax:(908)582-3340 Murray Hill, NJ 07974web: http://www.cs.bell-labs.com/~jmc __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] error when unsubscribe (PR#7198)
Full_Name: Huan Huang
Version: 1.9.1
OS: Win NT
Submission from: (NULL) (155.140.122.227)
Traceback:
Traceback (most recent call last):
File "/scratch/local/app/mailman-sfs/2.1.5/scripts/driver", line 87, in
run_main
main()
File "/scratch/local/app/mailman-sfs/2.1.5/Mailman/Cgi/options.py", line 91,
in main
language = cgidata.getvalue('language')
File "/scratch/local/app/python/2.3/lib/python2.3/cgi.py", line 560, in
getvalue
if key in self:
File "/scratch/local/app/python/2.3/lib/python2.3/cgi.py", line 611, in
__contains__
raise TypeError, "not indexable"
TypeError: not indexable
Python information:
Variable Value
sys.version 2.3 (#1, Oct 16 2003, 05:04:34) [GCC 3.2.2 20030222 (Red Hat Linux
3.2.2-5)]
sys.executable /scratch/local/app/python/current/bin/python
sys.prefix /scratch/local/app/python/current
sys.exec_prefix /scratch/local/app/python/current
sys.path /scratch/local/app/python/current
sys.platform linux2
Environment variables:
Variable Value
force_response_1_0 1
SSL_SERVER_I_DN_OU Department of Mathematics
SSL_CIPHER_EXPORT false
SSL_SERVER_S_DN_Email [EMAIL PROTECTED]
SERVER_SOFTWARE Apache/2.0.48 (Unix)
SSL_VERSION_INTERFACE mod_ssl/2.0.48
SCRIPT_NAME /mailman/options
SSL_SERVER_A_KEY rsaEncryption
SSL_SERVER_S_DN_ST Switzerland
SERVER_SIGNATURE Apache/2.0.48 (Unix) Server at stat.ethz.ch Port 443
REQUEST_METHOD POST
PATH_INFO /r-help
SERVER_PROTOCOL HTTP/1.1
SSL_SERVER_S_DN /C=CH/ST=Switzerland/L=Zurich/O=ETH Zurich/OU=Seminar for
Statistics/CN=stat.ethz.ch/[EMAIL PROTECTED]
SSL_CIPHER RC4-MD5
SSL_SERVER_V_START Jan 9 12:56:05 2004 GMT
SSL_SESSION_ID 210587E0DB04D2F7DAF67D64B4E9DDBA2F059B4E0671DD165F319D9EB1BB2057
CONTENT_LENGTH 83
SSL_CLIENT_VERIFY NONE
SSL_SERVER_I_DN_ST Switzerland
SSL_SERVER_S_DN_O ETH Zurich
HTTP_REFERER https://stat.ethz.ch/mailman/listinfo/r-help,
https://stat.ethz.ch/mailman/listinfo/r-help
SERVER_NAME stat.ethz.ch
REMOTE_ADDR 155.140.122.227
SSL_CIPHER_ALGKEYSIZE 128
SSL_SERVER_I_DN /C=CH/ST=Switzerland/L=Zurich/O=ETH Zurich/OU=Department of
Mathematics/CN=ISG D-MATH/[EMAIL PROTECTED]
SSL_SERVER_I_DN_C CH
SSL_SERVER_M_VERSION 1
SSL_SERVER_I_DN_O ETH Zurich
SERVER_ADDR 129.132.148.136
DOCUMENT_ROOT /var/www/vhosts/sfs/htdocs
SSL_SERVER_S_DN_OU Seminar for Statistics
SERVER_PORT 443
SSL_SERVER_I_DN_Email [EMAIL PROTECTED]
SSL_VERSION_LIBRARY OpenSSL/0.9.7a
PYTHONPATH /scratch/local/app/mailman-sfs/2.1.5
SCRIPT_FILENAME /var/www/vhosts/sfs/mailman/options
SERVER_ADMIN [EMAIL PROTECTED]
SCRIPT_URI https://stat.ethz.ch/mailman/options/r-help
SSL_SERVER_A_SIG md5WithRSAEncryption
SSL_SERVER_S_DN_L Zurich
HTTP_HOST stat.ethz.ch
SCRIPT_URL /mailman/options/r-help
HTTPS on
SSL_SERVER_I_DN_L Zurich
HTTP_CONNECTION Keep-Alive
PATH_TRANSLATED /var/www/vhosts/sfs/htdocs/r-help
HTTP_CACHE_CONTROL no-cache
SSL_SERVER_S_DN_C CH
REQUEST_URI /mailman/options/r-help
HTTP_ACCEPT application/vnd.ms-excel, application/msword,
application/vnd.ms-powerpoint, image/gif, image/x-xbitmap, image/jpeg,
image/pjpeg, */*
SSL_SERVER_M_SERIAL 13
SSL_SERVER_S_DN_CN stat.ethz.ch
HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; H010818; (R1
1.3))
nokeepalive 1
GATEWAY_INTERFACE CGI/1.1
SSL_PROTOCOL SSLv3
REMOTE_PORT 39557
HTTP_ACCEPT_LANGUAGE en-gb, en-gb
HTTP_ACCEPT_ENCODING gzip, deflate, gzip, deflate
ssl_unclean_shutdown 1
SSL_SERVER_V_END Jan 6 12:56:05 2014 GMT
CONTENT_TYPE application/x-www-form-urlencoded,
application/x-www-form-urlencoded
SSL_SERVER_I_DN_CN ISG D-MATH
QUERY_STRING
SSL_CIPHER_USEKEYSIZE 128
downgrade_1_0 1
UNIQUE_ID pOtOOYGElIIAAAlOUt0D
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Need help debugging R.
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > You need one of > > 1) gctorture(TRUE) > > 2) Run under valgrind to look for memory overruns. > > and patience. If it segfaults under gctorture you will probably see the > real culprit via gdb. > > I would try under R-devel, as quite a few memory problems have been > plugged there. Or at least under R-patched (ditto, but not quite all > those in R-devel). Other tricks: record the gc_count value at the crash and set a break conditional on that value, before stack corruption sets in. Or break at the previous value, and then set the gctorture switch. Once you figure out which memory location has inconsistent data, set a hardware watchpoint on it. Might take quite a bit of stamina, in additeon to the patience... -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Need help debugging R.
You need one of 1) gctorture(TRUE) 2) Run under valgrind to look for memory overruns. and patience. If it segfaults under gctorture you will probably see the real culprit via gdb. I would try under R-devel, as quite a few memory problems have been plugged there. Or at least under R-patched (ditto, but not quite all those in R-devel). On Tue, 24 Aug 2004, Samuelson, Frank* wrote: > > I originally posted this to R-help, but here is probably a better place. > > I have a rather complex routine which works great in R. > Then I bootstrap it. After running a few minutes it typically segfaults, > though it happens very randomly. > This happens w/ 1.9.0 and 1.9.1 on Fedora1 and a Scyld (RH7.3) system. > Traces always point back to routines in src/main/memory.c, though often > not the same routines. > > Now for the strangeness: > It's never the same routines that appear in the trace. > The trace gives sequential routine names that aren't called > by previous routines. Almost none of the variable names print in gdb. > > I've even tried turning optimizations all the way off > and setting -g3 and I get the same problems. > > Are there any important things I should know about debugging R > that I'm not doing? Is this just total memory corruption? > > > For what it's worth a sample trace below: > (gdb) where > #0 0x00a22096 in _int_free () from /lib/tls/libc.so.6 > #1 0x00a2101b in free () from /lib/tls/libc.so.6 > #2 0x080d632a in R_SetPPSize () > #3 0x080d7d13 in do_regFinaliz () > #4 0x080d9503 in do_gctime () > #5 0x080d8fcb in Rf_allocVector () > #6 0x080a9f7f in Rf_duplicate () > #7 0x080aa18c in Rf_duplicate () > #8 0x080b7b28 in R_execMethod () > #9 0x080b8a0f in do_function () > #10 0x080b8bf9 in do_function () > #11 0x080b70b7 in Rf_eval () > #12 0x080b87a5 in do_begin () > #13 0x080b70b7 in Rf_eval () > #14 0x080b80b1 in do_for () > #15 0x080b70b7 in Rf_eval () > #16 0x080b87a5 in do_begin () > #17 0x080b70b7 in Rf_eval () > #18 0x080b70b7 in Rf_eval () > #19 0x080b87a5 in do_begin () > #20 0x080b70b7 in Rf_eval () > #21 0x080b73c3 in Rf_applyClosure () > #22 0x080e03b4 in do_internal () > #23 0x080e0b37 in Rf_usemethod () > #24 0x080b9f34 in Rf_DispatchOrEval () > #25 0x0813b48b in do_subset () > #26 0x09fe39f0 in ?? () > #27 0x081d620b in _length_code () > #28 0x0be7aa5c in ?? () > #29 0x0c05a050 in ?? () > #30 0xbff046a8 in ?? () > > __ > [EMAIL PROTECTED] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Need help debugging R.
I originally posted this to R-help, but here is probably a better place. I have a rather complex routine which works great in R. Then I bootstrap it. After running a few minutes it typically segfaults, though it happens very randomly. This happens w/ 1.9.0 and 1.9.1 on Fedora1 and a Scyld (RH7.3) system. Traces always point back to routines in src/main/memory.c, though often not the same routines. Now for the strangeness: It's never the same routines that appear in the trace. The trace gives sequential routine names that aren't called by previous routines. Almost none of the variable names print in gdb. I've even tried turning optimizations all the way off and setting -g3 and I get the same problems. Are there any important things I should know about debugging R that I'm not doing? Is this just total memory corruption? For what it's worth a sample trace below: (gdb) where #0 0x00a22096 in _int_free () from /lib/tls/libc.so.6 #1 0x00a2101b in free () from /lib/tls/libc.so.6 #2 0x080d632a in R_SetPPSize () #3 0x080d7d13 in do_regFinaliz () #4 0x080d9503 in do_gctime () #5 0x080d8fcb in Rf_allocVector () #6 0x080a9f7f in Rf_duplicate () #7 0x080aa18c in Rf_duplicate () #8 0x080b7b28 in R_execMethod () #9 0x080b8a0f in do_function () #10 0x080b8bf9 in do_function () #11 0x080b70b7 in Rf_eval () #12 0x080b87a5 in do_begin () #13 0x080b70b7 in Rf_eval () #14 0x080b80b1 in do_for () #15 0x080b70b7 in Rf_eval () #16 0x080b87a5 in do_begin () #17 0x080b70b7 in Rf_eval () #18 0x080b70b7 in Rf_eval () #19 0x080b87a5 in do_begin () #20 0x080b70b7 in Rf_eval () #21 0x080b73c3 in Rf_applyClosure () #22 0x080e03b4 in do_internal () #23 0x080e0b37 in Rf_usemethod () #24 0x080b9f34 in Rf_DispatchOrEval () #25 0x0813b48b in do_subset () #26 0x09fe39f0 in ?? () #27 0x081d620b in _length_code () #28 0x0be7aa5c in ?? () #29 0x0c05a050 in ?? () #30 0xbff046a8 in ?? () __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] replacement functions and lists (PR#7196)
A couple of incorrect range chacks, now fixed thank you. On Tue, 24 Aug 2004 [EMAIL PROTECTED] wrote: > Full_Name: David Meyer > Version: 2.0.0 > OS: linux > Submission from: (NULL) (137.208.224.32) > > > l = list() > l[[2:3]] = 1 > > segfaults at least since 1.8.1 > > __ > [EMAIL PROTECTED] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] replacement functions and lists (PR#7196)
Full_Name: David Meyer Version: 2.0.0 OS: linux Submission from: (NULL) (137.208.224.32) l = list() l[[2:3]] = 1 segfaults at least since 1.8.1 __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] additional examples for R-intro.texi (PR#7195)
Here are some patches to expand some of the examples in R-intro.texi.
--
Brian Gough
Network Theory Ltd,
Publishing the R Reference Manuals --- http://www.network-theory.co.uk/R/
--- R-intro.texi~ Tue Aug 24 11:21:37 2004
+++ R-intro.texiTue Aug 24 11:21:37 2004
@@ -6288,6 +6288,21 @@
use
@example
+> help(package = "@var{name}")
[EMAIL PROTECTED] example
+
+A complete list of the user-level objects in a package can be displayed
+using the command
+
[EMAIL PROTECTED]
+> ls("package:@var{name}")
[EMAIL PROTECTED] example
+
+For example, @code{ls("package:base")} displays all the base package
+commands. Alternatively, if you have a web-browser available, you can
+use
+
[EMAIL PROTECTED]
> help.start()
@end example
--- R-intro.texi~ Tue Aug 24 11:21:37 2004
+++ R-intro.texiTue Aug 24 11:21:37 2004
@@ -5019,6 +5019,31 @@
After the fitting, @code{out$minimum} is the SSE, and
@code{out$estimates} are the least squares estimates of the parameters.
+
[EMAIL PROTECTED]
+> out
+$minimum
+[1] 1195.449
+
+$estimate
+[1] 212.68384222 0.06412146
+
+$gradient
+[1] -0.0001535012 0.0934206673
+
+$hessian
+[,1][,2]
+[1,]11.94725 -7661.319
+[2,] -7661.31875 8039421.153
+
+$code
+[1] 3
+
+$iterations
+[1] 26
[EMAIL PROTECTED] example
+
+
To obtain the approximate standard errors (SE) of the estimates we do:
@example
@@ -5032,7 +5057,7 @@
@example
> plot(x, y)
> xfit <- seq(.02, 1.1, .05)
-> yfit <- 212.68384222 * xfit/(0.06412146 + xfit)
+> yfit <- out$estimate[1] * xfit/(out$estimate[2] + xfit)
> lines(spline(xfit, yfit))
@end example
--- R-intro.texi~ Tue Aug 24 11:21:38 2004
+++ R-intro.texiTue Aug 24 11:21:38 2004
@@ -3307,8 +3307,8 @@
@R{} is an expression language in the sense that its only command type
is a function or expression which returns a result. Even an assignment
is an expression whose result is the value assigned, and it may be used
-wherever any expression may be used; in particular multiple assignments
-are possible.
+wherever any expression may be used; in particular, multiple assignments
+such as @code{x <- y <- z <- 0} are possible.
Commands may be grouped together in braces, @[EMAIL PROTECTED]@var{expr_1};
@[EMAIL PROTECTED]; @[EMAIL PROTECTED], in which case the value of the group
--- R-intro.texi~ Tue Aug 24 11:21:38 2004
+++ R-intro.texiTue Aug 24 11:21:38 2004
@@ -2021,9 +2021,8 @@
@example
> solve(A,b)
@end example
-
@noindent
-solves the system, returning @code{x} (up to some accuracy loss).
+solves the system @math{A x = b}, returning @code{x} (up to some accuracy loss).
Note that in linear algebra, formally
@[EMAIL PROTECTED] = @strong{A}^{-1} @strong{b}, @code{x = [EMAIL PROTECTED]@} %*% b}}
where
--- R-intro.texi~ Tue Aug 24 11:21:39 2004
+++ R-intro.texiTue Aug 24 11:21:39 2004
@@ -413,7 +413,21 @@
@findex help.search
The @code{help.search} command allows searching for help in various
-ways: try @code{?help.search} for details and examples.
+ways:
+
[EMAIL PROTECTED]
+> help.search("linear models")
+Help files with alias or title matching `linear models',
+type `help(FOO, package = PKG)' to inspect entry `FOO(PKG) TITLE':
+
+glm(base) Fitting Generalized Linear Models
+lm(base)Fitting Linear Models
+lm.fit(base)Fitter Functions for Linear Models
+loglin(base)Fitting Log-Linear Models
+.. ...
[EMAIL PROTECTED] example
[EMAIL PROTECTED]
+Use the command @code{?help.search} for further details and examples.
The examples on a help topic can normally be run by
--- R-intro.texi~ Tue Aug 24 11:21:39 2004
+++ R-intro.texiTue Aug 24 11:21:39 2004
@@ -3966,17 +3966,27 @@
@}
)
@}
[EMAIL PROTECTED] example
+The function can then be used as follows:
-ross <- open.account(100)
-robert <- open.account(200)
[EMAIL PROTECTED]
+> ross <- open.account(100)
+> robert <- open.account(200)
-ross$withdraw(30)
-ross$balance()
-robert$balance()
+> ross$withdraw(30)
+30 withdrawn. Your balance is 70
+> ross$balance()
+Your balance is 70
+> robert$balance()
+Your balance is 200
-ross$deposit(50)
-ross$balance()
-ross$withdraw(500)
+> ross$deposit(50)
+50 deposited. Your balance is 120
+> ross$balance()
+Your balance is 120
+> ross$withdraw(500)
+Error in ross$withdraw(500) : You don't have that
+ much money!
@end example
@node Customizing the environment, Object orientation, Scope, Writing your own
functions
--- R-intro.texi~ Tue Aug 24 11:21:39 2004
+++ R-intro.texiTue Aug 24 11:21:39 2004
@@ -3848,6 +3848,17 @@
fun1(f, a, b, fa, fb, a0, eps, lim, fun1)
@}
@end example
[EMAIL PROTECTED]
+The following test cases demonstrate the use of this function:
+
[EMAIL PROTECTED]
+> area(sqrt,0,1)
+0.557
+> testfn <- function(x) 1/(1+x^2)
+> area(testfn, 0, 100)
+1.560808
[EMAIL PROTECTED] example
+
@menu
* Scope::
__
Re: [Rd] idea for "virtual matrix/array" class
Thomas Lumley wrote:
On Mon, 23 Aug 2004, Tony Plate wrote:
One idea I was thinking about was to have a new class of object that
referred to data in a file on disk, and which had all the standard methods
of matrices and arrays, i.e., subsetting ("["), dim, dimnames, etc.
This is what RPgSql does with proxy dataframes and what I did (read-only)
for netCDF access. It's a good idea if you have a data format for which
random access is fairly fast. I'm not sure that the standard serialized
binary format satisfies this. Fixed-format text files would work, but
free-format ones wouldn't -- seek() only helps when you can work out where
to seek without reading all the data.
Just to join in on the 'done it' threads here, this is what my Rmap
package does with DBF files (they are the database component of ESRI
Shapefile maps). I use the dbf library from shapelib to access a DBF
file just like a data frame.
My dbf objects keep track of selected rows and columns, from the
database file, so its possible to do:
db1 = db[1:10,]
and db1 is still a proxy object to the same DBF file as db, but with
attributes that tell it that it only has rows 1 to 10 in it. If you
really want a data frame, you just as.data.frame() it.
If you wanted to do this sort of thing for space-saving reasons you'd
have to be very careful, since for some operations R might slurp it all
into memory.
Baz
http://www.maths.lancs.ac.uk/Software/Rmap/
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] mtext adj= wrong with several las= (PR#7188)
Paul Murrell wrote:
Hi
Uwe Ligges wrote:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Dear all,
Our quite basic function mtext() does wrong adjustments in some
parameter
configurations. This gets obvious when using multi line texts: There
is no
way to properly adjust text perpendicular to axis 2, for example.
Best
Jens Oehlschlägel
m <- matrix(1:9, 3)
colnames(m) <- c("several\nlines", "several\nlines", "several\nlines")
par(mfrow=c(2,2))
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="las=0
adj=0.5 is
fine")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="las=0
adj=1 is
different")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=0,
adj=1)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="las=1
adj=0.5 is
NOT fine")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=0.5)
barplot(m, horiz=TRUE, axes=FALSE, axisnames=FALSE, main="at las=1,
adj=1
works the wrong direction", sub="no way to get adj=c(1, 0.5) with
las=1 (or
2)")
mtext(colnames(m), 2, at=seq(0.5+0.2, by=1+0.2, length=3), las=1,
adj=1)
par(mfrow=c(1,1))
Left / right adjustemnt seems to be perfectly OK.
The thing that matters is centering "several lines" to the specified
("at=") location.
In fact, mtext() is not centering but bottom-aligning by adding a
negative distance that looks OK for one line in the default font
size, but not in most other cases.
Hence this is the same as Paul Murrell's PR#1659 ("mtext() alignment
of perpendicular text"). Fixing this, and/or improving mtext()'s
"adj" argument to accept 2 dimensions is desirable, but might be not
that easy... I'll take a look during the next days, but nothing
promised.
Uwe Ligges
Having looked into the code, there are three possible solution (all with
some drawbacks) I can see. Well, the current argument "adj" becomes
"xadj" in the C sources (graphics.c, GMtext), and "yadj" is set to 0.
Hence the ugly hard coded LineBias of 0.3.
Solutions
=
1: Hardcode "yadj" to 0.5 and remove all those 0.3 biases. Looks good
for axes, but it might break some code --> bad.
On the other hand, GMMathText has hardcoded yadj=0.5. Is there a
problem with some special devices? Or any other reason not to center
stuff using "adj=0.5"?
2: Allow the typical 2-value adj, take the first as xadj, the second one
as yadj. This might break some code, because currently adj of
arbitrary length (!=0) is allowed and recycled.
3: Invent an argument "padj" for mtext() that represents adjustment
*p*erpendicular to the text direction and gets mapped to "yadj" in
GMtext. In that case the hardcoded 0.3 bias mentioned above can be
removed. The question is whether to set the default to 0.5 (will still
break code, but easily to fix by setting padj to 0).
I'd like to propose the third solution and would be happy to provide a
patch of GMText, including corresponding patches to GMMathText, as
well as mtext(), title() and axis() (and their inderlying do_*
components).
Are there any objections? Any reasons not to do it?
It hurts my head to think about this stuff. There are so many
combinations to worry about:
(i) The las setting
(ii) The axis (bottom, left, top, right)
(iii) Whether adj has been specified
(iv) Whether the text is multi-line
I think mtext() does ok as long as adj is not specified and the text is
single-line.
Unfortunately it does *not* (using axis() here for simplicity):
plot(1:10)
axis(3, cex.axis=5, las=2)
I would suggest addressing the multi-line problem for unspecified adj as
a first step. And I will definitely not mourn the passing of the 0.3
constant. Setting yadj to 0.5 is not enough though because that doesn't
make sense for multi-line text that is parallel to an axis (in that
case, yadj should probably be 0 for axis 2 and 3 and 1 for axis 1 and 4;
did I mention that there are lots of combinations to worry about?).
I think most of the stuff is already quite pretty.
The point is whether we are going to distinguish cases for
(p)adj={0,0.5,1} automatically or not. If the latter, we can omit
several of the cases mentioned above in (i)-(iv).
I think - as the first step - we should set the default to center (note
that text() does so as well), and let the user change padj for
multi-line text as required.
I'll try to provide a collection of patches as a proposal within, say,
two weeks.
Uwe
For user-specified adj, I agree that a 2-value adj is not a good
solution (adj is assumed to be horizontal adjustment) so maybe a padj
would be best to allow user control of vertical alignment.
>
Paul
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
