R devel - Mar 2010 - Bug reporting system inquiry plus a bug report related to sort

Is the bug-reporting system working okay? Two days ago, I submitted
the following bug report via email to r-bugs at r-project.org. I didn't
see a confirmation, and it didn't see it at
http://bugs.r-project.org/. Now, http://bugs.r-project.org/ seems to
be down.

Anyway, here's the bug report related to sort.list and sort(...,
index.return = TRUE) with na.last = NA


I think that both sort.list(x, na.last = NA) and sort(x, na.last = NA,
index.return = TRUE)$ix give incorrect answers with na.last. With
na.last, both of these return answers equivalent to
sort.list(na.omit(x)), and I think they should be the equivalent of
order(x, na.last=NA) as follows.
> x <- c(1L, 6L, NA, 2L)
> order(x, na.last = NA) # right
[1] 1 4 2
> sort.list(x, na.last = NA, method = "radix") # wrong, I think
[1] 1 3 2
> sort.list(x, na.last = NA, method = "quick") # wrong
[1] 1 3 2
> sort(x, na.last = NA, index.return = TRUE)$ix # wrong
[1] 1 3 2

I've included a patch for the "radix" and "shell"
methods of
sort.list. The sort and "quick" method of sort.list (which uses sort)
look more challenging. With the patch, I get:
> sort.list(x, na.last = NA, method = "radix") # good
[1] 1 4 2
> sort.list(x, na.last = NA, method = "shell") # good
[1] 1 4 2
> sort.list(x, na.last = NA, method = "quick") # still bad
[1] 1 3 2

By the way, having the radix sort is great. It's really fast for factors.

- Tom

Tom Short
Electric Power Research Institute (EPRI)


> sessionInfo()
R version 2.10.1 (2009-12-14)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

On Mar 4, 2010, at 9:29 AM, Tom Short wrote:
> Is the bug-reporting system working okay? Two days ago, I submitted
> the following bug report via email to r-bugs at r-project.org. I didn't
> see a confirmation, and it didn't see it at
> http://bugs.r-project.org/. Now, http://bugs.r-project.org/ seems to
> be down.
> 
> Anyway, here's the bug report related to sort.list and sort(...,
> index.return = TRUE) with na.last = NA
> 
> 
> I think that both sort.list(x, na.last = NA) and sort(x, na.last = NA,
> index.return = TRUE)$ix give incorrect answers with na.last. With
> na.last, both of these return answers equivalent to
> sort.list(na.omit(x)), and I think they should be the equivalent of
> order(x, na.last=NA) as follows.
> 
>> x <- c(1L, 6L, NA, 2L)
>> order(x, na.last = NA) # right
> [1] 1 4 2
>> sort.list(x, na.last = NA, method = "radix") # wrong, I think
> [1] 1 3 2
>> sort.list(x, na.last = NA, method = "quick") # wrong
> [1] 1 3 2
>> sort(x, na.last = NA, index.return = TRUE)$ix # wrong
> [1] 1 3 2
> 
> I've included a patch for the "radix" and "shell"
methods of
> sort.list. The sort and "quick" method of sort.list (which uses
sort)
> look more challenging. With the patch, I get:
> 
>> sort.list(x, na.last = NA, method = "radix") # good
> [1] 1 4 2
>> sort.list(x, na.last = NA, method = "shell") # good
> [1] 1 4 2
>> sort.list(x, na.last = NA, method = "quick") # still bad
> [1] 1 3 2
> 
> By the way, having the radix sort is great. It's really fast for
factors.
> 
> - Tom
> 
> Tom Short
> Electric Power Research Institute (EPRI)
> 
> 
> 
>> sessionInfo()
> R version 2.10.1 (2009-12-14)
> i386-pc-mingw32
> 
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
> 
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base

Tom, 

See this recent follow up posting from Peter:

  http://tolstoy.newcastle.edu.au/R/e9/devel/10/02/0375.html

There has been talk over the years of moving to Bugzilla, but I am not clear on
present status.

Perhaps the link on the main R Project page needs to be removed or better,
updated to a link with a status update on the R bug reporting process. Of
course, that does not help folks using bug.report(), which presumably needs to
be updated as well.

HTH,

Marc Schwartz

On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote:
  
> There has been talk over the years of moving to Bugzilla, but I am not
clear on present status.
IMHO Bugzilla is too challenging for normal users/human beeings (even
developers are often not able to extract the info they need). So JIRA
(http://www.atlassian.com/software/jira/) might be a much better choice -
usually it is not a problem to ask for and get a license for free for
OpenSource projects ...

Regards,
jel.
-- 
Otto-von-Guericke University     http://www.cs.uni-magdeburg.de/
Department of Computer Science   Geb. 29 R 027, Universitaetsplatz 2
39106 Magdeburg, Germany         Tel: +49 391 67 12768

On Mar 4, 2010, at 10:10 AM, Jens Elkner wrote:
> On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote:
> 
>> There has been talk over the years of moving to Bugzilla, but I am not
clear on present status.
> 
> IMHO Bugzilla is too challenging for normal users/human beeings (even
> developers are often not able to extract the info they need). So JIRA
> (http://www.atlassian.com/software/jira/) might be a much better choice -
> usually it is not a problem to ask for and get a license for free for
> OpenSource projects ...
Jira was discussed a couple of years ago:

  http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html

I presume that the disposition towards non-FOSS platforms remains.

FWIW, the company that I work for uses Bugzilla (and SVN) on RHEL for our own
internal development and bug/issue reporting processes. We have both clients and
employees using our Bugzilla platform.

The key to having a successful result is not the software, but that the end
users and developers can interact with a base of information that enables
productive conversation. That places a certain burden on those reporting the
bugs/issues to understand both when and how to report bugs, including providing
sufficient information on the platform, versions, code and data to reliably
reproduce the issue observed.

As we frequently see on both R-Help and R-Devel, in my mind, that is the
limiting characteristic. With bug.report(), we still have issues and that is
arguably independent of the host bug management system.

I would argue that if there was a somewhat bigger hurdle in place to bug
reporting that compelled folks to post to R-Help first, before filing a formal
bug report, that this would not be a bad outcome. Whatever the host system may
be, a member of R Core will still need to manually process the report, adding to
their overhead. Reducing the number of false positives would be helpful.

Marc

Just to calm the discussion a bit - we already have decided to go with  
Bugzilla, we created tools for the import of old PRs and the new bug  
system is up and running in a test phase. The current downtime is not  
directly related to that - the cause is being investigated.

Cheers,
Simon


On Mar 4, 2010, at 11:58 , Marc Schwartz wrote:
>
> On Mar 4, 2010, at 10:10 AM, Jens Elkner wrote:
>
>> On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote:
>>
>>> There has been talk over the years of moving to Bugzilla, but I am
>>> not clear on present status.
>>
>> IMHO Bugzilla is too challenging for normal users/human beeings (even
>> developers are often not able to extract the info they need). So JIRA
>> (http://www.atlassian.com/software/jira/) might be a much better  
>> choice -
>> usually it is not a problem to ask for and get a license for free for
>> OpenSource projects ...
>
> Jira was discussed a couple of years ago:
>
>  http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html
>
> I presume that the disposition towards non-FOSS platforms remains.
>
> FWIW, the company that I work for uses Bugzilla (and SVN) on RHEL  
> for our own internal development and bug/issue reporting processes.  
> We have both clients and employees using our Bugzilla platform.
>
> The key to having a successful result is not the software, but that  
> the end users and developers can interact with a base of information  
> that enables productive conversation. That places a certain burden  
> on those reporting the bugs/issues to understand both when and how  
> to report bugs, including providing sufficient information on the  
> platform, versions, code and data to reliably reproduce the issue  
> observed.
>
> As we frequently see on both R-Help and R-Devel, in my mind, that is  
> the limiting characteristic. With bug.report(), we still have issues  
> and that is arguably independent of the host bug management system.
>
> I would argue that if there was a somewhat bigger hurdle in place to  
> bug reporting that compelled folks to post to R-Help first, before  
> filing a formal bug report, that this would not be a bad outcome.  
> Whatever the host system may be, a member of R Core will still need  
> to manually process the report, adding to their overhead. Reducing  
> the number of false positives would be helpful.
>
> Marc
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

Thanks for the update and your work on this Simon.

Regards,

Marc

On Mar 4, 2010, at 11:36 AM, Simon Urbanek wrote:
> Just to calm the discussion a bit - we already have decided to go with
Bugzilla, we created tools for the import of old PRs and the new bug system is
up and running in a test phase. The current downtime is not directly related to
that - the cause is being investigated.
> 
> Cheers,
> Simon
> 
> 
> On Mar 4, 2010, at 11:58 , Marc Schwartz wrote:
> 
>> 
>> On Mar 4, 2010, at 10:10 AM, Jens Elkner wrote:
>> 
>>> On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote:
>>> 
>>>> There has been talk over the years of moving to Bugzilla, but I
am not clear on present status.
>>> 
>>> IMHO Bugzilla is too challenging for normal users/human beeings
(even
>>> developers are often not able to extract the info they need). So
JIRA
>>> (http://www.atlassian.com/software/jira/) might be a much better
choice -
>>> usually it is not a problem to ask for and get a license for free
for
>>> OpenSource projects ...
>> 
>> Jira was discussed a couple of years ago:
>> 
>> http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html
>> 
>> I presume that the disposition towards non-FOSS platforms remains.
>> 
>> FWIW, the company that I work for uses Bugzilla (and SVN) on RHEL for
our own internal development and bug/issue reporting processes. We have both
clients and employees using our Bugzilla platform.
>> 
>> The key to having a successful result is not the software, but that the
end users and developers can interact with a base of information that enables
productive conversation. That places a certain burden on those reporting the
bugs/issues to understand both when and how to report bugs, including providing
sufficient information on the platform, versions, code and data to reliably
reproduce the issue observed.
>> 
>> As we frequently see on both R-Help and R-Devel, in my mind, that is
the limiting characteristic. With bug.report(), we still have issues and that is
arguably independent of the host bug management system.
>> 
>> I would argue that if there was a somewhat bigger hurdle in place to
bug reporting that compelled folks to post to R-Help first, before filing a
formal bug report, that this would not be a bad outcome. Whatever the host
system may be, a member of R Core will still need to manually process the
report, adding to their overhead. Reducing the number of false positives would
be helpful.
>> 
>> Marc