stopgap enhancement

[ea1d0bf8-c27a-4548-8cb7-de0b1d02441a]

Karl-Dieter Crisman commented about stopgaps that he would find it inappropriate, if everytime sage is restarted, a user will get warnings when using routines which return incorrect results; see discussion at https://github.com/sagemath/sage-prod/issues/17183

So one could imagine following enhancement:

• Show a stopgap only once per installation per user per sage-version

In case a user wants a different behaviour, stopgap could be made configurable e.g. in a way that a stopgap is shown in case of a hit once every time sage is executed.

Also I could imagine to warn greenhorns about bugs in CAS by showing at start a message that mathematical software may contain bugs leading to wrong results, with a link to Mathematically wrong answer list and to bug list

CC: @williamstein @roed314 @jbalakrishnan @kcrisman @nathanncohen

Component: PLEASE CHANGE

Issue created by migration from https://trac.sagemath.org/ticket/17754

[williamstein]

comment:1

some data points:

• In practice I have never once heard of any complaints from anybody about not being able to turn off a stopgap message. Never -- not once. So this isn't a problem in practice.

• If abs_integrate really is completely broken and full of bugs, then I would want a stopgap whenever it is first used in a session. Doesn't that make sense? And why are we using it if it is so broken -- it should require an explicit flag to use at all. Sage is supposed to default to correct answers unless you otherwise explicitly request otherwise, unlike say PARI which has the opposite design.

• We could nonetheless add a message to the stopgap output that says: "to hide this stopgap message so you don't see it anymore, type hide_stopgap('some-hash-of-message'). Then locally for that user (in ~/.sage) we could have a file ~/.sage/hide-stopgaps, with lines corresponding to hashes of stopgap messages. The stopgap function would load and consult this file before displaying a stopgap message. This gives each individual user very clear control over the stopgap functionality. To be even clearer, we could even just put hide_stopgap('name-of-stopgap') or even hide_stop('exact stopgap message'), rather than a hash, so the user can clearly see what they are ignoring by consulting ~/.sage/hide-stopgaps. I.e., no hashes at all.

[ea1d0bf8-c27a-4548-8cb7-de0b1d02441a]

comment:2

@William

Gee, calm down ;-). This is a half-baked enhancement suggestion, not criticism. .

add hide_stopgap('some-hash-of-message')

That would be fine right now. At a later time point when the stopgap list will be huge (no worries, I will work on that soon *g ) that might be no longer sufficient. .

In practice I have never once heard of any complaints from anybody about not being able to turn off a stopgap message. Never -- not once.

People usually do not complain, they work around issues. We have to acitvely ask for reports (as I had e.g. to for Singular bug 694 by Dino Lorenzini; or for #17697 - my office colleague dit hit it,...) .

Never -- not once. So this isn't a problem in practice.

now once : #17183 *g. If a feature is not perfect, users might not accept it (reread #17183). The question here is, if we should care or not. .

If abs_integrate really is completely broken and full of bugs, then I would want a stopgap whenever it is first used in a session. Doesn't that make sense?

Absolutely, that makes sense... for most of us. Why not add some tolerance for users/developers with a different point of view?

[jdemeyer]

Replying to @sagetrac-jakobkroeker:

• Show a stopgap only once per installation per user per sage-version

That would be pretty much pointless. It's so easy to miss a warning the first time. I think it would be essentially equivalent to removing stopgaps completely.

[jdemeyer]

comment:4

On a more technical note, for the Notebook you certainly don't want to do this. Showing a warning once would mean that only one notebook of one user would see the message.

[williamstein]

comment:5

Replying to @sagetrac-jakobkroeker:

Gee, calm down ;-). This is a half-baked enhancement suggestion, not criticism. .

Sorry -- I worry a huge amount about how to effectively decide to spend time. Mistakenly spending time on things that aren't big problems is a huge danger, so I'm particularly careful about it.

I'm worried not due to criticism but because this suggestion is dangerous as is... as Jereon says.

add hide_stopgap('some-hash-of-message')

That would be fine right now. At a later time point when the stopgap list will be huge (no worries, I will work on that soon *g ) that might be no longer sufficient. .

In practice I have never once heard of any complaints from anybody about not being able to turn off a stopgap message. Never -- not once.

People usually do not complain, they work around issues. We have to acitvely ask for reports (as I had e.g. to for Singular bug 694 by Dino Lorenzini; or for #17697 - my office colleague dit hit it,...) .

People complain a lot to me...

Absolutely, that makes sense... for most of us. Why not add some tolerance for users/developers with a different point of view?

I agree; that's why I also included some ideas for how to do this.

I think my suggested approach addresses jdmeyer's very valid concerns (which I also have). Instead of showing the message once, make the user have to very explicitly turn off the warning.

That said, I don't think this should be a high priority.

-- William

[ea1d0bf8-c27a-4548-8cb7-de0b1d02441a]

comment:6

That said, I don't think this should be a high priority.

Indeed. I opened the ticket as 'minor'.

[kcrisman]

comment:7

For the record, if I knew a way to do this easily for abs_integrate I would do it today. See #12371 - maybe #12371 comment:11 is the closest to something we could do. The problem is that it gives a lot of very good enhancements.

That is not really a comment about this ticket, but now you know where to look for that.

[ea1d0bf8-c27a-4548-8cb7-de0b1d02441a]

comment:8

See #12371

typo? I guess it should be #12731

[kcrisman]

comment:9

See #12371

typo? I guess it should be #12731

Yes, I was in a big hurry to just get that comment off, sorry. So the comment here as well.