Travis Scrimshaw wrote: > For the record, I am that reviewer. > > > As a huge part of Arpit Merchant's GSoC project on Gabidulin codes, > > we've been working on Xavier Caruso's old patch implementing skew > > polynomial rings, #13215. > > > > While everyone involved has considered the code and math > carefully, it > > is my opinion that the design could still be subject to (mild) > changes > > in the near future, so I suggested that the code be merged but with > > the @experimental warning on. This arose in part because I very > recently > > was made aware that there are multiple conflicting notions of > evaluation > > of skew polynomials, and the current patch supports only one. I > imagine > > that other, similar things could crop up. > > As a compromise, wouldn't it be sufficient (and appropriate anyway) to > place warnings (.. WARNING:) in the module and/or class descriptions? > (There don't seem to be any yet.) > > I can hardly imagine anyone would base his/her code on it without > reading the documentation (or just the docstrings in the code). > > > I see that as doing essentially the exact same thing with the only > difference that a warning message is not displayed when the > functionality is first called. So I'm not convinced this would be a fair > compromise.
Well, depends on /what/ you write there... At least mentioning the different notions of skew polynomial evaluation (and that currently only one, and which, is implemented) shouldn't hurt. And you could clearly state what aspects of the interface are probably subject to change, and also which aren't. (You both still have to agree on the latter though, but my impression is this isn't really the point where your opinions completely diverge.) -leif > > One reviewer is strongly opposed to adding @experimental to the > module. > > He would accept adding it on __call__ due to the aforementioned > example, > > but not to simply constructing the skew polynomial ring. It seems we > > fundamentally disagree on what valid use-cases are for @experimental. > > > > So we bring it to sage-devel for arbitration. Essentially, my > point of > > view is that when a new structure is added to Sage, and one has mild > > doubts that certain details could change, then the @experimental > > decorator can/should be added. But the code can still be merged, > even if > > the addition of @experimental reveals less than fool-hardy > conviction in > > the design. The reviewer argues against this because the code is > useless > > for building upon if one cannot trust the API. > > > > (Perhaps the reviewer would like to argue his stance more clearly > than I > > can.) > > As Johan stated, my viewpoint is because you are not promising a stable > API with the @experimental, anyone who wants to develop code based upon > @experimental code either are requiring you, who put in the > @experimental. to also fix their code should the API change or have > their code be silently broken (say, for lack of a specific doctest). So > by marking everything as experimental, you're effectively saying you > should not build upon this. > > There is also another issue: when does the code stop becoming > @experimental and who decides? > > From [Johan's] last post on the ticket, I think we might also have a > slight disagreement on the definition of mild too. Mild to me would be > changing some method or parameter names, whereas any behavioral change > would not be. > > Best, > Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
