[sage-devel] Re: RFC: correct way to deal with particular methods

[Nils Bruin]

On Sunday, November 6, 2016 at 3:12:38 PM UTC-8, Salvatore Stella wrote:
>
> {{{ 
> if n == 2 and m == 0: 
> self.greedy_element = MethodType(greedy_element, self, self.__class__) 
> }}} 
>
> This has at least one drawback: the documentation produced by Sphinx looks 
> weird because these methods appears as functions outside the scope of the 
> class. Furthermore is not very readable and subsequently harder to debug. 
>

Why not just make a subclass for the n==2, m==0 case and put the methods 
there?
Just make sure that your parent class knows which class to instantiate for 
its elements. 

Having implemented this one may be interested in calling `change_me` on the 
> entries of a list. Sometime such a list may not be specified explicitly 
> but 
> might be computed from some description or from some other data. In short 
> one 
> would like to preparse the input of `change_me` before calling the 
> original 
> functions. Now this preparsing is identical for both classes. To avoid 
> duplicated code we made a wrapper that takes care of the preparsing and we 
> used it in both classes. So far so good. The problems starts when writing 
> the 
> documentation for this setup. Right now each `change_me` only has the 
> documentation regarding the integer input. All the other possibilities are 
> in 
> the documentation of the wrapper. Moreover the wrapper changes on the fly 
> the 
> documentation of `change_me` to add the relevant extra possibilities and 
> make 
> them available from the inline help. 
>

This again sounds like a scenario that fits perfectly in a class hierarchy 
with inheritance:
Implement your wrapper in an appropriate superclass and let it dispatch to 
"change_me" on the object it is acting on.
 
For documentation: just document the "wrapper" appropriately: put 
everything there that a user needs. I fail to see from what you describe 
why your wrapper needs to "change on the fly". That sounds like something 
that is best avoided.


-- 
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.

[sage-devel] RFC: correct way to deal with particular methods

[VulK]

Dear all,
I am writing to you to ask your opinion on the best way to address two issues 
that were raised during the review of #21254. People are quite unhappy on how 
these are addressed right now so I figured it would be better to ask for 
opinions on how to best implement them.



The first question is about which is the correct way to implement methods 
that are not always defined.


We are implementing an algebra `ClusterAlgebra` that is defined from some 
integer matrix. When this matrix has precisely two columns then the algebra 
has certain special elements and we want to create a method to construct 
them. In all the other cases these elements do not make any mathematical 
sense.


Rather than having these methods check for this condition every time they are 
invoked, and still be listed among the methods defined (say through `dir`), 
we opted for defining them outside of the class and then add them "manually" 
when __init__ is run.  The relevant code is something like:


{{{
if n == 2 and m == 0:
   self.greedy_element = MethodType(greedy_element, self, self.__class__)
}}}

This has at least one drawback: the documentation produced by Sphinx looks 
weird because these methods appears as functions outside the scope of the 
class. Furthermore is not very readable and subsequently harder to debug.


The same issue happens also at the level of `ClusterAlgebraElement` (the 
elements of `ClusterAlgebra`).


Which is the standard way to proceed here? Is there a way to define method 
conditionally (maybe using a wrapper)? Alternatively, is it possible to 
always define these methods but mask them unless some condition is satisfied?



The second problem is a little more involved, I will try to give you a souped 
up version here.


Suppose you are building two classes `MyClassA` and `MyClassS`. They are 
quite different classes but they both have a method `change_me` that morally 
performs the same operation on each. Of course the implementations of the two
`change_me` are quite different as well. In both cases the input of 
`change_me` is an integer. 

Having implemented this one may be interested in calling `change_me` on the 
entries of a list. Sometime such a list may not be specified explicitly but 
might be computed from some description or from some other data. In short one 
would like to preparse the input of `change_me` before calling the original 
functions. Now this preparsing is identical for both classes. To avoid 
duplicated code we made a wrapper that takes care of the preparsing and we 
used it in both classes. So far so good. The problems starts when writing the 
documentation for this setup. Right now each `change_me` only has the 
documentation regarding the integer input. All the other possibilities are in 
the documentation of the wrapper. Moreover the wrapper changes on the fly the 
documentation of `change_me` to add the relevant extra possibilities and make 
them available from the inline help. 

Now this is clearly an hack which saves on code redundancy at the price of a 
possible nightmarish maintenance. Is there a more streamlined solution?


The relevant functions are `ClusterAlgebraSeed.mutate` and 
`ClusterAlgebra.mutate_initial`; the wrapper is `_mutation_parse`.



Any comment is welcome.
Thanks
S.

--
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.

Re: [sage-devel] Re: Testing corner cases

[Jori Mäntysalo]

On Sun, 6 Nov 2016, Jakob Kroeker wrote:

But, If you catched issues for non-corner cases, the challenge is often 
to find a minimal/simple failing example, which is often necessary for 
successful debugging.


True, but I don't see any easy solution to this. As an example, about two 
years ago I found bugs in Singular 3, but no failing polynomial of less 
than four variables and the polynomials where at least few lines long when 
written out.


Should have a list of corner cases? I don't know if that would be easy 
to do or not, something like modulename._cornercases() or so.


I would expect that you will need corner cases per function and per data
type (graph, Ideal, prime number...)


Yes, that would be good. But for example Sage should never halt on simple 
f(0), not for any built-in f. This could be tested automatically.


I recommend that you continue test sage library functions which you use 
in your own research projects, or functions where you already found bugs 
or expect that they are improperly coded.



But probably you should not do that, you may get unpleasantly surprised...


:=)

Of course this kind of testing found only bugs that are not dangerous. You 
won't get a wrong result from stack trace.


--
Jori Mäntysalo

[sage-devel] Singular "share" files

[Dima Pasechnik]

+1

-- 
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.

Re: [sage-devel] Re: Testing corner cases

[Jakob Kroeker]

> I would also add a crosstesting several functions with known identity. 

Good idea. 


>Well, my "trivialcase-tester" is just those few lines of code. But as you 
> can see from https://trac.sagemath.org/ticket/21741 

 
, it found quite many 
> error from graphs.

That is not surprising for me. Maybe it is surprising for non-testers ;-)

My code to catch bugs in Singular for groebner basis in Polynomial rings 
over integers was something like:

randomIdeal = generateRandomIdeal();
groebnerBase = groebner(randomIdeal );
groebnerBaseOnceAgain = groebner(groebnerBase);
checkResultEquivalence (groebnerBase, groebnerBaseOnceAgain);

But, If you catched issues for non-corner cases, the challenge is often to 
find a minimal/simple failing example,
which is often necessary for successful debugging.

>Should have a list of corner cases? I don't know if that would be easy to 
>do or not, something like modulename._cornercases() or so. 

I would expect that you will need corner cases per function and per data 
type (graph, Ideal, prime number...)

>In matrices I did not found that many errors, but I 
>only tested integer matrices. 

I recommend that you continue test sage library functions which you use in 
your own research projects,
or functions where you already found bugs or expect that they are 
improperly coded.

But probably you should not do that, you may get unpleasantly surprised...



Am Montag, 31. Oktober 2016 10:31:56 UTC+1 schrieb Jori Mäntysalo:
>
> On Mon, 31 Oct 2016, Jakob Kroeker wrote: 
>
> > So you have a mind of a tester? That's good to  know.  
>
> Well, my "trivialcase-tester" is just those few lines of code. But as you 
> can see from https://trac.sagemath.org/ticket/21741 , it found quite many 
> error from graphs. In matrices I did not found that many errors, but I 
> only tested integer matrices. 
>
> Should have a list of corner cases? I don't know if that would be easy to 
> do or not, something like modulename._cornercases() or so. 
>
> > In general I think it would be good to have a random testing framework  
> > together with a testbot in sage. 
>
> Yes, could be useful. 
>
> > Maybe you are also interested in the slides from my presentation about 
> bug hunting and bug preventing 
> > on 
> > https://wiki.sagemath.org/days66 
>
> Good slides. 
>
> I would also add a crosstesting several functions with known identity. For 
> example 
>
> len(list(Posets(4))) == len([g for g in digraphs(4) if 
> g.is_directed_acyclic() and g.is_transitively_reduced()]) 
>
> (I.e. a poset can be seen as just a special case for directed graph.) 
>
> or 
>
> Posets.RandomPoset(10, 0.1).order_ideals_lattice().is_modular() 
>
> (Every order ideal lattice is a distributive lattice and every 
> distributive lattice is modular.) 
>
> etc. 
>
> -- 
> Jori Mäntysalo

-- 
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.

[sage-devel] Re: Singular "share" files

[Jakob Kroeker]

Will we have to repackage Singular each time we want to upgrade/get the 
recent patched release?

I think we should stop repackaging Singular. 
If there are some general issues with packaging, we should solve them 
upstream.


Jakob

Am Mittwoch, 2. November 2016 16:19:47 UTC+1 schrieb Jean-Pierre Flori:
>
> Dear all,
>
> We currently repackage singular so merge the source code and help files 
> into a single archive (and renaming directories).
> Should we stop doing so by creating a "singular_share" package for the 
> latter files?
>
> Best,
> JPF
>

-- 
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.