11

In this question a bug in Mathematica's TableView was reported, which was subsequently confirmed by the community and tagged by belisarius with the tag.

TableView is a strange beast, with WRI being very secretive about it. As far as I know it came in the open because it was used somewhere in a presentation of a WRI employee and its revelation was probably unintended. It is known to be rather crash-prone, so its use should not be advocated too much (though I personally would love to have such a feature once stable).

The question I have is whether or not the tag should be reserved for bugs in the official, documented function set or that bugs in undocumented functions qualify as well.

I'll provide a few answers for voting. Feel free to add your own.

10
  • 2
    Also: Do we know if anybody at Wolfram support is aware of our bugs tag? Commented Jun 4, 2014 at 12:51
  • I suppose some of them will. We have a long list of WRI employees visiting this site, many since its inception. Commented Jun 4, 2014 at 12:57
  • @SjoerdC.deVries moreover I think that bug-in-verification would be nice idea too. I'm waiting for a reply to my reports for about 4 months without any sign of progress.
    – Kuba
    Commented Jun 5, 2014 at 11:29
  • @Kuba Make sure you mention your license number when you send emails to support ...
    – Szabolcs
    Commented Jun 5, 2014 at 13:43
  • The problem with calling something a bug is that it has a rather negative connotation. A bug is a clearly bad thing that should be fixed ASAP. If some experimental feature or proof of concept function happens to be (invisibly) part of the kernel, and it doesn't work perfectly, that's not a bad thing. It was probably never meant to be seen or used by end users. It will possibly never be released in its current form. Maybe it's just a proof of concept that will be rewritten from scratch if they ever decide to include it. I think it's unfair to label these as bugs.
    – Szabolcs
    Commented Jun 5, 2014 at 13:47
  • @Szabolcs Well, I did and after 2 weeks got an answer that it was forwarded to the dev team as something more complicated :) But I understand they have V10 releasing time now so I'm patient :)
    – Kuba
    Commented Jun 5, 2014 at 13:50
  • Version 5 had some undocumented semi-broken rotatable 3D graphics. What was finally included in v6 was completely different. Did v5 have a bug? Internal`Deflatten crashes if given the wrong parameters. I can imagine how someone really needed this functionality to implement builtin functions, but since he might be the only one using this undocumented and invisible function, he didn't implement error checking. Is that a bad thing, a bug? After people stared using Deflatten here, ArrayReshape was included as a polished & documented almost-equivalent with a different name.
    – Szabolcs
    Commented Jun 5, 2014 at 13:51
  • We also have private, non-user-visible functions inside MATLink that can be used to crash the system or corrupt its state internally. I would be rather annoyed if someone told me that MATLink is buggy just because he tried using those functions (never meant for end users) and broke something.
    – Szabolcs
    Commented Jun 5, 2014 at 13:53
  • 1
    @Szabolcs I agree with your point that it's impossible to assign a problem with an undocumented feature as a bug or not, because there is no corresponding specification describing the correct behaviour. But, let's face it, a lot of the time the documented functions have the same problem, and documentation/community review of potential bugs on this site is useful to us all as users. I wouldn't take the word "bug" as such a negative thing as you suggest, given that we already aren't taking it too literally nor demanding that WRI do anything about bugs we find. In your example you would deny ... Commented Jun 11, 2014 at 1:13
  • 1
    @Szabolcs that the complained about behavior was in fact a bug, and you'd be right to do so, because some usage is outside of the specification. But since in Mathematica pretty much all user-facing behavior is defined by convention rather than specification and users have been conditioned to expect consistency, the character of a bug is a bit different. WRI doesn't have to accept our definition or specific instances. We could come up with more technically correct tag names, certainly, but "bugs" is IMO probably good enough as long as we all know what it means for undocumented functions. Commented Jun 11, 2014 at 1:17

3 Answers 3

12

People will be using undocumented features no matter the risks involved. Bug reports are particular useful as a guide through a potential minefield. Using the tag is great as long as the tag is present as well. Since the 'undocumented' status may be temporary it is a good idea to tag with the appropriate tags too.

1
  • 1
    version tags are also important so we can see how many versions a bug perpetuates without being fixed. Commented Jun 8, 2014 at 21:54
3

Undocumented features are undocumented for a reason. You may use them, but you proceed at your own risk, and you probably cannot bother support@wolfram with any connected problems that may occur.

Accordingly, our list should only contain bugs in the official documentation, as it would be rather unfair towards WRI to complain about things they don't intend you to use.

2
  • I would add to this that questions about undocumented features, whether about bugs or not, should be tagged with the tag undocumented.
    – m_goldberg
    Commented Jun 4, 2014 at 13:19
  • @SjoerdC.deVries Rereading my (now deleted) comment I found it a bit harsh. Please accept my apologies. Commented Jun 14, 2014 at 6:29
2

Reporting bugs for undocumented features is OK, but we need a dedicated tag for it. Some suggestions are: , .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .