Re: [Rd] Typo [Was: Rd and guillemots]
On Fri, 16 Sep 2005 [EMAIL PROTECTED] wrote:
On 16-Sep-05 Duncan Murdoch wrote:
[...]
This seems to happen in Rdconv.pm, around here:
## avoid conversion to guillemots
$c =~ s/<>/>\{\}>/;
The name of the "continental" quotation mark « is "guillemet".
The R Development Core Team must have had some bird on the brain
at the time ...
I don't think any authority agrees with Ted here. There are two
characters, left and right. Collectively it seems agreed they are called
guillemets, but the issue is over the names of the single characters, and
the character shown is the left guillem[eo]t.
Adobe says these are left and right guillemot. It seems that the
majority opinion does not agree, but there is a substantial usage
following Adobe.
I had already changed the R source code, so please Ted and others follow
the advice in the posting guide and
*** check the current sources before posting alleged bugs ***
--
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__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typo [Was: Rd and guillemots]
On 17-Sep-05 Prof Brian Ripley wrote:
> On Fri, 16 Sep 2005 [EMAIL PROTECTED] wrote:
>
>> On 16-Sep-05 Duncan Murdoch wrote:
>>> [...]
>>> This seems to happen in Rdconv.pm, around here:
>>>
>>> ## avoid conversion to guillemots
>>> $c =~ s/<>> $c =~ s/>>/>\{\}>/;
>>
>> The name of the "continental" quotation mark « is "guillemet".
>>
>> The R Development Core Team must have had some bird on the brain
>> at the time ...
>
> I don't think any authority agrees with Ted here. There are two
> characters, left and right.
Agreed I only gave one instance. Either « or » is a guillemet.
As to "any authority", it depends what you mean by "authority".
1. Take any good French dictionary (e.g. Collins "Robert").
Look up [Fr]"guillemet": --> [En]"quotation mark, inverted comma".
Look up [En]"quotation mark": --> [Fr]"guillemet".
There is a phrase "entre guillemets": --> "in quotation marks"
or "in quotes", and vice versa.
Look up [Fr]"guillemot": --> [En]"guillemot" and vice versa.
2. Take a good book on printing/typographical matters, e.g. "The
Chicago Manual of Style" which is very comprehensive.
Index: "guillemets" [the entry is in the plural]: -> 9.22-26
"Small angle marks called guillemets («») are used for quotation
marks ..."
Index: "guillemot": --> nothing found.
It's not as straightforward as that, however! In French, "guillemet"
is in fact used generically for "quotation mark" and, typographically,
includes not only the marks « and » we are talking bout, but also
the marks used for similar purposes in "non-continental" typography.
So the opening double quote `` (e.g. in Times Roman) and closing ''
(sorry, can't make these marks in email) are also "guillemets".
Indeed we have [note the singular] "guillemet anglais ouvrant" (``),
"guillemet anglais fermant" (''), as well as "guillemet français
ouvrant" («), "guillemet français fermant (»); not to mention the
fact that a "guillemet français" e.g. « consists of two "chevrons"
and one can also have a "chevron ouvrant" consisting of just one
of these (can't do this either) which is also called a "guillemet
français simple ouvrant" (in PostScript "guilsingleft"), etc. And
there is (as in Courier font) the guillemet dactylographique
= typewriter quotation mark ("). And lots of other variants.
Rather than sink in the morass of French-speaking usage, we might
be better off referring to an authority closer to the sort of usage
that concerns us, So I've had a look at the Unicode Standard,
specifically
http://www.unicode.org/Public/UNIDATA/NamesList.txt
where one can find
00ABLEFT-POINTING DOUBLE ANGLE QUOTATION MARK
= LEFT POINTING GUILLEMET
= chevrons (in typography)
* usually opening, sometimes closing
00BBRIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
= RIGHT POINTING GUILLEMET
* usually closing, sometimes opening
2039SINGLE LEFT-POINTING ANGLE QUOTATION MARK
= LEFT POINTING SINGLE GUILLEMET
* usually opening, sometimes closing
203ASINGLE RIGHT-POINTING ANGLE QUOTATION MARK
= RIGHT POINTING SINGLE GUILLEMET
* usually closing, sometimes opening
but no guillemots!
> Collectively it seems agreed they are called guillemets, but the
> issue is over the names of the single characters, and the character
> shown is the left guillem[eo]t.
See above ...
> Adobe says these are left and right guillemot. It seems that the
> majority opinion does not agree, but there is a substantial usage
> following Adobe.
That is certainly a matter of fact! And it is certainly thus in
Adobe's PostScript Language Reference Manual (see e.g. Standard
Roman Character Set in Appendix E, "Standard Character Sets and
Encoding Vectors"). So that is what must be used when invoking
them in PostScript. However, I am firmly of the view that Adobe
made an error when they gave these things the names "guillemotleft"
and "guillemotright".
> I had already changed the R source code, so please Ted and others
> follow the advice in the posting guide and
>
> *** check the current sources before posting alleged bugs ***
Easier said than done ... However, I apologise!
Nevertheless, apart from the issue of a possible "R bug", I think
it is worth putting the record straight on the general issue of
nomenclature.
Best wishes to all,
Ted.
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 17-Sep-05 Time: 10:51:17
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] loadings() generic in R alpha
> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
> on Fri, 16 Sep 2005 14:04:37 -0400 writes:
PaulG> Brian Ok, lets leave this for now. When does the
PaulG> development cycle start for the next version that
PaulG> would allow making a function generic?
Almost immediately after 2.2.0 is released.
PaulG> Paul
PaulG> Prof Brian D Ripley wrote:
>> On Fri, 16 Sep 2005, Paul Gilbert wrote:
>>
>>
>>
>>> Brian
>>>
>>> It would help if I understood general principles. I
>>> thought one would want a case for NOT making functions
>>> generic, rather than a case for making them
>>> generic. Hopefully a case for why generics and methods
>>> are useful will not be necessary.
>>>
>>>
>> Making things generic
>>
>> 1) adds runtime cost
>>
>> 2) essentially fixes the signature for all time
>>
>> 3) needs the return value sufficiently well defined that
>> all current uses will not be broken by a new method.
>> (This was not a problem with e.g. as.ts as everone knows
>> the result should be a "ts" object. But I think it is a
>> problem with acf and loadings.)
>>
>> I would for example be unhappy with your definition of
>> loadings() as it has no ... argument (and S-PLUS has one
>> in its loadings() generic).
>>
>> So cases are necessary. I am pretty sure that we have in
>> the past agreed that making a function generic is a Grand
>> Feature, and we are in GFF.
>>
>>
>>
>>
>>> The situation with loadings() is that I construct
>>> objects where the loadings are in a list within a list,
>>> so the simple definition in stats does not work:
>>>
>>> loadings function (x) x$loadings >> namespace:stats>
>>>
>>> Basically this definition restricts the way in which
>>> objects can be constructed, so I would like it replaced
>>> by
>>>
>>> loadings <- function (x) UseMethod("loadings")
>>> loadings.default <- function (x) x$loadings
>>>
>>> There may be a reason for adding a ... argument, but I
>>> have been using this generic and methods for it in my
>>> own work for a fairly long time now and have not
>>> discovered one. The change seems rather trivial, I have
>>> tested it extensively with my own code, and there is a
>>> fairly complete test suite in place for checking changes
>>> to R, so it seems reasonable to me that this should be
>>> considered as a change that is possible in an alpha
>>> release. It would also be fairly easy to back out of if
>>> there are problems.
>>>
>>> The reason for needing acf generic is the same, so that
>>> it can be use with more complicated objects that I
>>> construct. However, I see here that there are
>>> potentially more difficult problems, because the
>>> ... argument to the current acf (which one would want as
>>> the default method) is passed to plot.acf. Here I can
>>> clearly see the reason for wanting to start
>>> consideration of this at an earlier point in the
>>> development cycle.
>>>
>>> Best, Paul
>>>
>>> Prof Brian Ripley wrote:
>>>
>>>
>>>
On Thu, 15 Sep 2005, Paul Gilbert wrote (in two
separate messages)
> Could loadings() in R-2.2.0 please be made generic?
>
>
> Could acf() in R-2.2.0 please be made generic?
>
>
I think it is too late in the process for this (and
especially for acf). In particular, it could have
knock-on consequences for packages and recommended
packages are scheduled to be all fixed in stone by next
Weds.
To consider making such functions generic we would need
- a case - discussion of what the arguments of the
generic should be and what is to be specified about the
return value.
Perhaps you could raise these again with specific
proposals early in the developement cycle for 2.3.0.
(We have been a little too casual about speciying what
generic functions should return in the past, and have
got bitten as a result. For example, can it be assumed
that loadings() returns a matrix?)
PaulG> __
PaulG> R-devel@r-project.org mailing list
PaulG> 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] plot(): new behavior in R-2.2.0 alpha
> "Wst" == Werner Stahel <[EMAIL PROTECTED]>
> on Fri, 16 Sep 2005 09:37:02 +0200 writes:
Wst> Dear Martin, dear Johns Thanks for including me into
Wst> your discussion.
Wst> I am a strong supporter of "Residuals vs. Hii"
>>> One remaining problem I'd like to address is the
>>> "balanced AOV" situation, ...
Wst> In order to keep the plots consistent, I suggest to
Wst> draw a histogram. Other alternatives will or can be
Wst> interesting in the general case and therefore are not a
Wst> suitable substitute for this plot.
hmm, but all other 3 default plots have
(standardized / sqrt) residuals on the y-axis.
I'd very much like to keep that for any forth plot.
So would we want a horizontal histogram? And do we really want
a histogram when we've already got the QQ plot?
We need a decent proposal for a 4th plot
{instead of R_i vs h_ii , when h_ii are constant}
REAL SOON NOW since it's feature
freeze on Monday.
Of course the current state can be declared a bug and still be
fixed but that was not the intention...
Also, there are now at least 2 book authors among R-core (and
more book authors more generally!) in whose books there are
pictures with the "old-default" 4th plot.
So I'd like to have convincing reasons for ``deprecating'' all
the plot.lm() pictures in the published books.
At the moment, I'd still go for
R_i vs i
or sqrt|R_i| vs i -- possibly with type = 'h'
which could be used to "check" an important kind of "temporal"
auto-correlation.
the latter, because in a 2 x 2 plot arrangement, this gives the
same y-axis as default plot 3.
Wst>
Wst> Back to currently available methods:
Wst> John Maindonald discusses different contours. I like
Wst> the implementation I get currently in R-devel: contours
Wst> of Cook's distances, since they are popular and we can
Wst> then argue that the plot of D_i vs. i is no more
Wst> needed.
what about John's proposal of different contour levels than
c(0.5, 1) -- note that these *have* been added as arguments to
plot.lm() a user could modify.
Wst> For most plots, I like to see a smoother along with the
Wst> points. I suggest to add the option to include
Wst> smoothers, not only as an argument to plot.lm, but even
Wst> as an option(). I have heared of the intense
Wst> discussions about options(). With Martin, we arrived
Wst> at the conclusion that options() should never influence
Wst> calculations and results, but is suitable to adjust
Wst> outputs (numerical: digits=, graphical: smooth=) to the
Wst> user's taste.
{and John Fox agreed, `in general'}
That could be a possibility, for 2.2.0 only applied to
plot.lm() in any case, where plot.lm() would get a new argument
add.smooth = getOption("plot.add.smooth")
What do people think about the name?
it would ``stick with us'' -- so we better choose it well..
>>> (4) Are there other diagnostics that ought to be
>>> included in stats? (perhaps in a function other than
>>> plot.lm(), which risks being overloaded). One strong
>>> claiment is vif() (variance inflation factor),
...
...
...
Wst> As we focus on plots, my plot method includes the
Wst> option (default) to add smooths for 20 simulated
Wst> datasets (according to the fitted model).
this and others are really nice.
However not for R 2.2.x in any case.
I agree that one should rather provide `single-plot'
functions and have plot.lm() just call a few of them; instead of
having things all part of plot.lm().
There's the slight advantage that you can guarantee some
consistence (e.g. in the definition of "standardized residuals")
and save some computations when have everything in one function,
but consistency should be possible otherwise as well...
Anyway this is for 2.3.0 or later.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] looks in liblapack.a not liblapack.so
I can't compile R-alpha on AMD 64. Rather than include a 1400 line script I have put it on the web http://www.stat.umn.edu/~charlie/typescript.txt way down near the bottom it fails building lapack.so gcc -shared -L/usr/local/lib64 -o lapack.so Lapack.lo-llapack -lblas -lg2c -lm -lgcc_s /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/liblapack.a(dgecon.i): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/liblapack.a: could not read symbols: Bad value The 'recompile with -fPIC' is bullsh*t. The problem is that is is looking in /usr/lib64/liblapack.a rather than /usr/lib64/liblapack.so.3 both of which exist. Some searching for this error message on Google shows a lot of questions about this problem but no solution that I found other than rm /usr/lib64/liblapack.a which I don't consider a solution. It will link with the .so as the bottom of the script shows snowbank$ cd src/modules/lapack snowbank$ gcc -shared -o lapack.so Lapack.lo -llapack -lblas -lg2c -lm -lgcc_s /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/liblapack.a(dgecon.i): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/../../../../lib64/liblapack.a: could not read symbols: Bad value collect2: ld returned 1 exit status snowbank$ gcc -shared -o lapack.so Lapack.lo /usr/lib64/liblapack.so.3 -lblas -l g2c -lm -lgcc_s No problems with the second link. So what do I do? liblapack.so is there. I've linked other (non-R) programs to it. So it SHOULD work with R. Either I can't read (possible) or the solution to this isn't in the gcc info pages. System (more info in typescript). AMD 64 SuSE linux 9.3 GCC 3.3.5 I also observed the same problem with R-2.1.1 but didn't get around to debugging it until today. It occurred to me that /usr/local/lib/liblapack.so.3 which is 32 bit (because right now we are running only one R on both 32 and 64 bit and that's where the 32 bit R finds it's shared libraries), but I don't think that's the problem. Well maybe it is. How do I tell configure NOT to add /user/local ? -- Charles Geyer Professor, School of Statistics University of Minnesota [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plot(): new behavior in R-2.2.0 alpha
Martin -
Thanks for your efforts in initiating and managing this
discussion.
As for the issue of deprecating the plot.lm() pictures in
the published books, surely this will have great benefits
for the authors. It will help them to sell the new editions
of their books that will in due course appear replete with
the new plots!
For 2.2.0, I have nothing more to add to the comments
others have made, I hope we can in due course agree,
as a minimum, to put some version of John Fox's vif(),
and something akin to Werner Stahl's smooths for up to
20 simulated data sets, into 2.3.0
John Maindonald.
On 18 Sep 2005, at 1:29 AM, Martin Maechler wrote:
>> "Wst" == Werner Stahel <[EMAIL PROTECTED]>
>> on Fri, 16 Sep 2005 09:37:02 +0200 writes:
>>
>
> Wst> Dear Martin, dear Johns Thanks for including me into
> Wst> your discussion.
>
> Wst> I am a strong supporter of "Residuals vs. Hii"
>
>
One remaining problem I'd like to address is the
"balanced AOV" situation, ...
>
> Wst> In order to keep the plots consistent, I suggest to
> Wst> draw a histogram. Other alternatives will or can be
> Wst> interesting in the general case and therefore are not a
> Wst> suitable substitute for this plot.
>
> hmm, but all other 3 default plots have
> (standardized / sqrt) residuals on the y-axis.
> I'd very much like to keep that for any forth plot.
> So would we want a horizontal histogram? And do we really want
> a histogram when we've already got the QQ plot?
>
> We need a decent proposal for a 4th plot
> {instead of R_i vs h_ii , when h_ii are constant}
> REAL SOON NOW since it's feature
> freeze on Monday.
> Of course the current state can be declared a bug and still be
> fixed but that was not the intention...
>
> Also, there are now at least 2 book authors among R-core (and
> more book authors more generally!) in whose books there are
> pictures with the "old-default" 4th plot.
> So I'd like to have convincing reasons for ``deprecating'' all
> the plot.lm() pictures in the published books.
>
> At the moment, I'd still go for
>
> R_i vs i
> or sqrt|R_i| vs i -- possibly with type = 'h'
>
> which could be used to "check" an important kind of "temporal"
> auto-correlation.
>
> the latter, because in a 2 x 2 plot arrangement, this gives the
> same y-axis as default plot 3.
>
> Wst>
>
> Wst> Back to currently available methods:
>
> Wst> John Maindonald discusses different contours. I like
> Wst> the implementation I get currently in R-devel: contours
> Wst> of Cook's distances, since they are popular and we can
> Wst> then argue that the plot of D_i vs. i is no more
> Wst> needed.
>
> what about John's proposal of different contour levels than
> c(0.5, 1) -- note that these *have* been added as arguments to
> plot.lm() a user could modify.
>
> Wst> For most plots, I like to see a smoother along with the
> Wst> points. I suggest to add the option to include
> Wst> smoothers, not only as an argument to plot.lm, but even
> Wst> as an option(). I have heared of the intense
> Wst> discussions about options(). With Martin, we arrived
> Wst> at the conclusion that options() should never influence
> Wst> calculations and results, but is suitable to adjust
> Wst> outputs (numerical: digits=, graphical: smooth=) to the
> Wst> user's taste.
>
> {and John Fox agreed, `in general'}
>
> That could be a possibility, for 2.2.0 only applied to
> plot.lm() in any case, where plot.lm() would get a new argument
>
> add.smooth = getOption("plot.add.smooth")
>
> What do people think about the name?
> it would ``stick with us'' -- so we better choose it well..
>
>
(4) Are there other diagnostics that ought to be
included in stats? (perhaps in a function other than
plot.lm(), which risks being overloaded). One strong
claiment is vif() (variance inflation factor),
>
>...
>...
>...
>
>
> Wst> As we focus on plots, my plot method includes the
> Wst> option (default) to add smooths for 20 simulated
> Wst> datasets (according to the fitted model).
>
> this and others are really nice.
>
> However not for R 2.2.x in any case.
>
> I agree that one should rather provide `single-plot'
> functions and have plot.lm() just call a few of them; instead of
> having things all part of plot.lm().
> There's the slight advantage that you can guarantee some
> consistence (e.g. in the definition of "standardized residuals")
> and save some computations when have everything in one function,
> but consistency should be possible otherwise as well...
> Anyway this is for 2.3.0 or later.
>
> Martin
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
