[Rd] Potential bugs in table dnn

[Martin Maechler]

>>>>> SOEIRO Thomas 
>>>>>     on Wed, 13 Oct 2021 11:12:09 +0000 writes:

    > Inline comments below in the previous message I'm not 100%
    > sure if the current behavior is intended or not. If not,
    > here is a patch (which I can submit on R Bugzilla if
    > appropriate):

Excuse us for not replying earlier, Thomas, but yes, there is a
buglet in generating dimnames when creating table() objects,
but I think *not* in the behaviour you want to change
because that *is* partly purposeful and not a bug (in code).

Rather it's incomplete documentation which currently does not
cover that case ... and I see your proposed patch also tries to
address the issue of "too terse" documentation.

The only bug I see is that here,

  R> table(warpbreaks[3])

   L  M  H 
  18 18 18 
  R> 

the automatic dnn's (= [d]im[n]ames' [n]ames) are not taken as
in the (>= 2)-dim case,

  R> table(warpbreaks[-1])
      tension
  wool L M H
     A 9 9 9
     B 9 9 9
  R>

However, I definitely would not want to see anything different
than what we see now for

  R> table(FOOBAR = warpbreaks[-1])
      tension
  wool L M H
     A 9 9 9
     B 9 9 9
  R>

where indeed, the FOOBAR should be *kept* disregarded
(as it should in  table(FOOBAR = warpbreaks[3])  once we fix the
 1D --- {1-argument with own dimnames} case)

and of course, this should also stay as is, undisputedly:

  R> table(POISSON_7 = rpois(100, 7))
  POISSON_7
   2  3  4  5  6  7  8  9 10 11 12 13 14 
   4  5 14 16 20  8  8 13  1  5  3  2  1 
  R>

I'm fine if you move this to R bugzilla  {where it remains more
easily findable in say 1 year's time}.

Thank you for the report and diagnosis so far!
Martin