Possible bug in Sage cell selector for default

[kcrisman]

At https://github.com/sagemath/sagecell/blob/master/interact_sagecell.py#L747 we see that the list of values in a selector essentially requires only the value, not the label.

But https://wiki.sagemath.org/interact/web#Arctic_sea_ice_extent_data_plot.2C_fetched_from_NSIDC seems to indicate that the default was allowed to be the tuple (value, label) in the past.

There are other problems with this interact (well, with MANY of them!) but wanted to ask whether this should be considered a bug or a documentation failure.  Maybe people haven't been using things in this way lately? (I mean using list of values with labels and then having explicit default as a tuple.)

[kcrisman]

On a related note, it seems that when an item in the selector is a zip, now that zips are not evaluated lists, then the zip is "used up" in the process of making the selector.  Compare the following:

longmonths = ['January','February','March','April','May','June','July','August','September','October','November','December']

L = list(zip(range(1,13),longmonths))

@interact

def iceplotter(month = selector(L, default = 4, label="Month")):

    print(month)

and 

longmonths = ['January','February','March','April','May','June','July','August','September','October','November','December']

L = zip(range(1,13),longmonths)

@interact

def iceplotter(month = selector(L, default = 4, label="Month")):

    print(month)

[kcrisman]

On a related note, it seems that when an item in the selector is a zip, now that zips are not evaluated lists, then the zip is "used up" in the process of making the selector.  Compare the following:

Also related: https://github.com/sagemath/sagecell/issues/533 but that one I was able to actually figure out what was going on; still, probably somehow related.

[Andrey Novoseltsev]

To claim/decide whether something is a bug and/or documentation failure, it would be nice to have some documented behavior... A loooong time ago when I was writing interacts myself, it was indeed quite frustrating to see discrepancies between SageNB and SageMathCell (and then CoCalc too). Documentation for all features also was not available.

With the current situation, I think it is desirable

1) not to break things that are working now

2) have consistency with Jupyter/CoCalc

3) follow some documentation (if things are consistent, no need for separate documentation from other systems)

Help in incremental achieving of these goals is surely appreciated - in the form of examples that behave differently as well as pull requests!

[kcrisman]

To claim/decide whether something is a bug and/or documentation failure, it would be nice to have some documented behavior... A loooong time ago when I was writing interacts myself, it was indeed quite frustrating to see discrepancies between SageNB and SageMathCell (and then CoCalc too). Documentation for all features also was not available.

Yes, you are sure right about that.  See https://groups.google.com/d/topic/sage-devel/y5v-BGJ5MjY/discussion - from SIX years ago.

In this case, it's documented in the sense that those interacts must have worked at some time - in fact, they must have worked with py2 Sage cell even!  I think it really is something about iterators/generators that changed.

 

With the current situation, I think it is desirable

1) not to break things that are working now

Absolutely.

 

2) have consistency with Jupyter/CoCalc

Unfortunately those two are not the same, though hopefully not terribly far apart.

3) follow some documentation (if things are consistent, no need for separate documentation from other systems)

I updated the https://wiki.sagemath.org/interact page with my best search for places where this is "documented".   The original sagenb stuff probably was supposed to be the default implementation at one time, but of course it doesn't have nested interacts and some other stuff, which I believe may not be properly documented anywhere - again, only in examples that work/worked.

 

Help in incremental achieving of these goals is surely appreciated - in the form of examples that behave differently as well as pull requests!

I will do my best!  That is what this thread was intended to (re)start. 

[kcrisman]

I am actually in the midst of collating this.  But one indication the doctests are not so helpful is this one, directly from the interact_compatibility.py.  If you change the (1..10) to [1..10], which makes a list and not a generator, it does fine.  Anyway, I am trying to make a good document that can serve as a "master reference" - really, all three APIs take directly from the original sagenb one pretty directly, except Sage cell and CoCalc have more functionality and Jupyter has a few differences (so far as I can tell as yet).  

It would be interesting to know where such a document should live!  I'm not sure.

sage: @interact
	... def _(R=selector([ZZ,QQ,GF(17),RDF,RR]), n=(1..10)):
	... M = random_matrix(R, n)
	... show(M)
	... show(matrix_plot(M,cmap='Oranges'))
	... f = M.charpoly()
	... print(f)
	<html>...

[Andrey Novoseltsev]

Going back to defaults as tuples - neither CoCalc nor Jupyter allow it and again - interact code in SageMathCell did not change in logic since 2014. So there is no reason to behave differently now...

[Andrey Novoseltsev]

This one works now without explicit conversion to a list (it is done internally).

[Andrey Novoseltsev]

This one will take some more tracing. There are checks when something is a list/tuple and then there are checks of elements of such things, both break with iterators. Thank you for uncovering these places!

[kcrisman]

On Saturday, June 6, 2020 at 12:02:57 AM UTC-4, Andrey Novoseltsev wrote:

Going back to defaults as tuples - neither CoCalc nor Jupyter allow it and again - interact code in SageMathCell did not change in logic since 2014. So there is no reason to behave differently now...

Okay, that is fine - really there was some ambiguity as to what the default should be, I think. 

[kcrisman]

This one works now without explicit conversion to a list (it is done internally).

Great - if you can put a commit link here for reference for people other than you and me that would be great :-) 

[kcrisman]

On Saturday, June 6, 2020 at 12:24:44 AM UTC-4, Andrey Novoseltsev wrote:

This one will take some more tracing. There are checks when something is a list/tuple and then there are checks of elements of such things, both break with iterators. Thank you for uncovering these places!

Well, glad we had all those interacts which we could uncover them with!  And many thanks for the maintenance.  This is not an obvious Py3 change since many things work the same, but I think there probably also in Sage proper were a lot of places where it implicitly assumed it was not a generator - but it is easier to check a test suite in Sage for those than it is to do so for interacts. 

[Andrey Novoseltsev]

https://github.com/sagemath/sagecell/commit/ccf18894d4c5a4974ebbbf3e0ea6a5926c22ab1d

[Andrey Novoseltsev]

I've fiddled a bit with automatic controls for different types:

https://github.com/sagemath/sagecell/commit/6612cabb355699638b033567fc1cb1cdf7a7c43a

I dislike the distinction in behaviour between tuples/lists/generators, especially when it is dependent on length, but tried to keep the logic that presumably used to work at some point. Namely:

- range used to return a list, so I treat it as a list

- there was treatment for GeneratorType and 1..10 now returns generator (which is a different thing, not sure if it was the case before), so I treat it the same way as Generator type.

Check the behaviour on this code:

@interact
def f(n=range(2,7)):
    @interact
    def g(a=range(n), b=list(range(n)), c=(0..n), d=tuple(range(n))):
        print(a, b, c, d)

[kcrisman]

On Sunday, June 7, 2020 at 5:17:24 PM UTC-4, Andrey Novoseltsev wrote:

I've fiddled a bit with automatic controls for different types:

https://github.com/sagemath/sagecell/commit/6612cabb355699638b033567fc1cb1cdf7a7c43a

I dislike the distinction in behaviour between tuples/lists/generators, especially when it is dependent on length, but tried to keep the logic that presumably used to work at some point.

Thanks.  Yeah, maybe in retrospect things should have had to be explicit selectors or ranges, but it is SO convenient ...

 

Namely:

- range used to return a list, so I treat it as a list

- there was treatment for GeneratorType and 1..10 now returns generator (which is a different thing, not sure if it was the case before), so I treat it the same way as Generator type.

The fact that [1..10] and (1..10) return different things is good, in my opinion (based on previous behavior).

 

Check the behaviour on this code:

@interact
def f(n=range(2,7)):
    @interact
    def g(a=range(n), b=list(range(n)), c=(0..n), d=tuple(range(n))):
        print(a, b, c, d)

I still love that we have nested interacts; I've used them far too little!