[R] bug checking

[Parlamis Franklin]

Thanks all for following up.  I'll consider the bug "filed."

I should note for the record that if 'col="red"' is replaced in my  
code by 'col.main="red"' the x axis is still made red.

I'll use the workaround for now (for which thanks).  Even with little  
things like this, plotting from the command line in R is orders  
better than dragging a bunch of frames around an Excel window.

On Oct 11, 2005, at 6:34 PM, Marc Schwartz wrote:

> Thanks for the code and the clarifications, including the PDF file.
>
> Yes, I can replicate the behavior here (R 2.2.0 on FC4) and I am  
> cc:ing
> Kurt Hornik, who ported chron to R and is the chron package  
> maintainer.
>
> It appears that the "culprit" is the argument 'col = "red"', which
> towards the end of plot.times() is used as follows:
>
> ...
>     else if (x.times)
>         axis.times(1, x, simplify = simplify, labels = TRUE,
>             adj = adj, col = col, cex = cex, font = font,
>             las = las, lab = lab, mgp = mgp, tcl = tcl)
> ...
>
> Thus, if the 'x' data is of class 'times', the above code is used and
> the color of the axis line and tick marks are set to "red" as per the
> 'col' argument to axis(), which axis.times() ultimately calls.
>
> This results in the behavior that you are seeing, where both the plot
> symbols/lines and the axis are colored the same.
>
> This does sound like a bug and Kurt can comment better on this.
>
> HTH,
>
> Marc Schwartz
>
>
> On Tue, 2005-10-11 at 18:02 -1000, Parlamis Franklin wrote:
>
>> ## Code was long, so I simplified it by creating vectors from scratch
>> so it would run as is.  Putative "bug" is still evidenced on the x  
>> axis
>>
>> discount.factors.dates <- seq.dates(from="09/30/2005",  
>> to="09/30/2035")
>> rates<-seq(4.4, 5.2, by=0.0025);
>> plot(discount.factors.dates[1:length(rates)], rates,
>>       pch=18, las=1, bty="n",
>>       col="red", col.main="red",
>>       xlab="Date", ylab="Rate",
>>       ylim=c(min(rates)-(max(rates)-min(rates))/10,max(rates)+(max
>> (rates)-min(rates))/10))
>>
>> ## This is the output:
>>
>> ## Hopefully you all see the red x axis.
>>
>> ## I am running R Cocoa GUI 1.1.2 with R 2.1.1 framework on a dual
>> proc 2.7 Ghz Power Mac.  A Quartz device is opened when 'plot' is
>> called.  X11User and X11SDK are installed on t he computer, as well
>> as xCode 2.1 (in case that's relevant).
>>
>>
>> On Oct 11, 2005, at 4:47 PM, Marc Schwartz wrote:
>>
>>
>>> On Tue, 2005-10-11 at 16:07 -1000, Parlamis Franklin wrote:
>>>
>>>
>>>> I have observed the following behavior, wondering if it is a bug
>>>> before I submit a report.
>>>>
>>>> I am using the plot function with call:  plot(X, Y,
>>>> col="red", . . . ) where X is an object that inherits from classes
>>>> 'dates' and 'times' (created with the 'dates' function from package
>>>> 'chron') and y is a numeric vector.  The color red is applied to  
>>>> the
>>>> area from the first to the last tick mark on the x axis (even if I
>>>> don't set col="red" and only set, say col.main="red").
>>>>
>>>> If instead of feeding the function X, I feed it unclass(X) or
>>>> as.vector(X) the red color is not applied to the area between the
>>>> first and last ticks on the x axis.
>>>>
>>>> Is this a bug, or just a consequence of there not being a plot  
>>>> method
>>>> for the class I am trying to feed the function?
>>>>
>>>> Franklin Parlamis
>>>>
>>>>
>>>
>>> As per the Posting Guide, it would be immensely helpful in the  
>>> attempt
>>> to help you, if you would provide the exact code you are using and
>>> some
>>> sample data here, so that we can exactly replicate what you are
>>> experiencing.
>>>
>>> Lacking that, it would be difficult to assist as we can only  
>>> guess. It
>>> does sound like there is an _appropriate_ change in the plot method
>>> behavior as a direct consequence of your modifying the class of the
>>> argument(s), which is of course how methods are dispatched. Thus,  
>>> if I
>>> were to guess, this is not a bug.
>>>
>>> I would however, certainly recommend that you submit an example
>>> here to
>>> confirm the behavior, before you post a bug report, as that would
>>> avoid
>>> a more energetic response.
>>>
>>> Marc Schwartz
>>>
>>>
>>>
>>>
>>
>>
>
>