[sage-devel] Re: possibly controversial question: "Can I create commercial software using SageMath?"

[Robert Dodier]

On 2016-08-20, Volker Braun  wrote:

> And, as you know, if there is any question about interpretation then
> the court will almost certainly side with the interpretations written
> previously by the FSF, so in practice the FSF's interpretation does
> matter.

I hadn't heard about that. Can you refer to some cases in which the
court relied on the FSF interpretation?

best,

Robert Dodier

-- 
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: daily WTF?

[Robert Dodier]

On 2016-08-20, Volker Braun  wrote:

> The many ways of implementing xor...
>
> Incidentally, if there is some global switch to return certificates instead 
> of booleans then the sum version is the correct one ;-)

I don't understand this point, but it sounds interesting. Can you
explain?

best

Robert Dodier

-- 
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: [Yet again] Sage's R vs system's R

[kcrisman]

 

>
> Make R optional?  (Nothing in Sage depends on it, except for the 
> interface to it, including Rpy2.) 
>
>
Gosh, R has been standard for*ever*, practically, and is often heavily 
advertised as a good reason to use Sage.  There are certainly many who have 
been using them together (as mentioned, obviously nowhere near the number 
of "pure" R users, but still we definitely get queries about this 
regularly) and of course optional=untested=broken all too often.  Take the 
Maple or Mathematica interfaces and their on-again, off-again nature... Is 
this only a Cygwin problem, or on other platforms?  I couldn't see anything 
about other problems on this thread. 

-- 
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: Iterators and KeyboardInterrupt

[VulK]

Hi All,
thank you very much for all the inputs!

> Breath-first search = Search & pray? ;-)
> 
> (Possibly infinite apnoea can't be healthy.)

/me fails
:)

> Well, one usually implements checkpoints for such things (continually
> saving state to optionally resume later if interrupted).

I am not sure what data to store nor if it is a good compromise, I will think
about this a little but I guess Sébastien gave me a way out of this.

> Are you really getting benefit from storing the state (i.e., the actual
> iterator) on the parent itself? (I see you haven't made ClusterAlgebra
> UniqueRepresentation, so it's not an immediate bug to have it this way)
> Perhaps it's cleaner to hand out iterator objects that are kept track
> of in the relevant loop. That iterator would then just die whenever the
> frames of a KeyboardInterrupt exception are discarded and the flawed
> state wouldn't persist.

The main benefit I get from storing the iterator is that, if the user is
careful in calling the various functions with reasonable stopping points, the
code never has to start searching from scratch. For example currently

sage: A = ClusterAlgebra(['A',2,1])
sage: A.explore_to_depth(10)
sage: A.explore_to_depth(11)

effectively only traverses the tree once to depth 11. If I were not to store
the iterator then I would be traversing the tree twice. And unfortunately
this is expensive.

> Using "yield" is a convenient way of writing simple iterators, but it
> is in no way the only way of doing it. When you explicitly store state
> yourself it is much easier to define the right behaviour in the face of
> unexpected interrupts.

I never thought of this before.

> IMHO iterators must not have global state, which is really just a
> corollary to "global variables are bad". In particular, iterating twice
> simultaneously should work. With the exception of input iterators of
> course, but iterating over a tree doesn't consume it.

I agree in principle with the idea that "global variables are bad" but how do
you avoid to perform expensive computations multiple times?

> Do you know about
> sage: RecursivelyEnumeratedSet?

No and it looks extremely promising! Unfortunately the graph I have has
only a symmetric structure so it looks like I will not be able to use any
parallelization (unless there is some other wonder piece of code I know
nothing about!!!).

> I let you look whether KeyboardInterrupts works ok for your need, but
> consider including your tree iterator into these existing modules (I
> will be willing to review your code).

At this point I definitely intend to try RecursivelyEnumeratedSet; I'll keep
you posted on the outcome and hold you to the promise of a review!

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.

[sage-devel] Re: Iterators and KeyboardInterrupt

[Sébastien Labbé]

sage: RecursivelyEnumeratedSet?
>

See also

http://doc.sagemath.org/html/en/reference/structure/sage/sets/recursively_enumerated_set.html

If the structure of your set is a tree or forest, then you may be 
interested in using parallel computations on your structure provided by

http://doc.sagemath.org/html/en/reference/parallel/sage/parallel/map_reduce.html

which was merged into Sage this year and which is known enough I think.

I let you look whether KeyboardInterrupts works ok for your need, but 
consider including your tree iterator into these existing modules (I will 
be willing to review your code).

Sébastien

-- 
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: Iterators and KeyboardInterrupt

[Sébastien Labbé]

Do you know about

sage: RecursivelyEnumeratedSet?

-- 
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: Iterators and KeyboardInterrupt

[Volker Braun]

On Monday, August 22, 2016 at 8:27:28 PM UTC+2, Nils Bruin wrote:
>
> Iterators themselves are required to be "iterable", but in a strange way: 
> calling "iter" on an iterators gives you back an identical object! In 
> particular, if I is an iterator then calling next(I) and next(iter(I)) 
> should have exactly the same result (in both cases modifying the state of 
> I).
>

Yes, though thats not what I meant. I wanted to say that set(iter(X)) == 
set(iter(X)). Unless X is somehow being consumed in the iteration, like 
open(file).readlines(), that is, an input iterator. But a BFS most 
certainly does not consume the tree. 

-- 
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: Iterators and KeyboardInterrupt

[Nils Bruin]

On Monday, August 22, 2016 at 10:53:23 AM UTC-7, Volker Braun wrote:

> IMHO iterators must not have global state, which is really just a 
> corollary to "global variables are bad". In particular, iterating twice 
> simultaneously should work. With the exception of input iterators of 
> course, but iterating over a tree doesn't consume it.
>

Just to make sure we stay compatible with python terminology: iterators get 
consumed and have their state altered by calling "next" on them. Iterables 
are objects that can be iterated over, meaning that calling "iter" on them 
produces an iterator on which one can call "next".

Iterators themselves are required to be "iterable", but in a strange way: 
calling "iter" on an iterators gives you back an identical object! In 
particular, if I is an iterator then calling next(I) and next(iter(I)) 
should have exactly the same result (in both cases modifying the state of 
I).

-- 
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: Iterators and KeyboardInterrupt

[Volker Braun]

On Monday, August 22, 2016 at 6:12:50 PM UTC+2, Nils Bruin wrote:
>
> Perhaps it's cleaner to hand out iterator objects that are kept track of 
> in the relevant loop. That iterator would then just die whenever the frames 
> of a KeyboardInterrupt exception are discarded and the flawed state 
> wouldn't persist.
>

IMHO iterators must not have global state, which is really just a corollary 
to "global variables are bad". In particular, iterating twice 
simultaneously should work. With the exception of input iterators of 
course, but iterating over a tree doesn't consume it.

-- 
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: [sage-combinat-devel] Multiple versions of SageMath's documentation online

[Samuel Lelievre]

Le lundi 22 août 2016 16:53:56 UTC+2, Nicolas M. Thiery a écrit :
>
>Dear Samuel, Frédéric, Harald, 
>
> Sorry for the slow answer; I am just back from vacations. 
>
> Thanks Sam, Frédéric for the pings! 
>
> On Thu, Aug 11, 2016 at 10:46:08PM +0200, Samuel Lelièvre wrote: 
> >This post on sage-devel 
> >[1]
> https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ 
> >has a part (which I'm copying below for convenience) about 
> >SageMath's documentation at [2]combinat.sagemath.org/doc. 
> >Does anybody here have some insight about these questions? 
>
> >- Excerpt from the sage-devel post at 
> >[3]
> https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ 
> >2. SageMath's developer manual at [4]combinat.sagemath.org/doc/ 
> >reference 
> >This sage-devel thread 
> > 
> >  [5]https://groups.google.com/d/topic/sage-devel/cCGobP2AgwM/ 
> >discussion 
> >is concerned with the fact that another version of SageMath's 
> >reference manual also lives at 
> >  [6]http://combinat.sagemath.org/doc/reference 
> >and that (given the trouble we are having in getting Google to 
> properly 
> >index the documentation at [7]doc.sagemath.org), queries in Google 
> >search 
> >give search engine results at [8]combinat.sagemath.org/doc, rather 
> than 
> >at [9]doc.sagemath.org. 
> >In addition, it seems that the version of the documentation at 
> >[10]combinat.sagemath.org/doc corresponds to SageMath 6.3 
> >, while SageMath is now at 7.3. 
> >Combinat people, 
> >- is there a use for hosting SageMath's documentation at 
> >  [11]combinat.sagemath.org/doc and should it be updated to 7.3? 
> >- does this version have extra stuff from the combinat queue? 
> >- who is in charge? 
>
> - This documentation is compiled with an old Sage with the patches 
>   from the legacy Sage-Combinat queue applied. 
>
> - It was occasionally useful, as there are some thematic tutorials 
>   that have not yet been integrated into Sage. 
>

Yes, for instance
http://combinat.sagemath.org/doc/thematic_tutorials/demo-cython.html
which now gives "Not Found" due to the redirect.
 

> - The documentation cannot be updated to 7.3, as the patches don't 
>   apply anymore. 
>
> - It was hosted in the user directory of 
>   comb...@combinat.sagemath.org ; Anne, Florent and myself 
> have the 
>   ssh keys for that account. 
>
> I see that combinat.sagemath.org/doc is now redirected to the main 
> Sage documentation. Given the issues the old doc was causing with 
> google searches, I guess that's fair enough.
>

I guess once the Google indexing of doc.sagemath.org is solved,
we should probably remove this redirection.

It would be worth to open a Sage trac ticket dedicated
to moving the sage-combinat tutorials into Sage proper.

Samuel

-- 
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-combinat-devel] Multiple versions of SageMath's documentation online

[Samuel Lelievre]

Le lundi 22 août 2016 16:53:56 UTC+2, Nicolas M. Thiery a écrit :
>
>Dear Samuel, Frédéric, Harald, 
>
> Sorry for the slow answer; I am just back from vacations. 
>
> Thanks Sam, Frédéric for the pings! 
>
> On Thu, Aug 11, 2016 at 10:46:08PM +0200, Samuel Lelièvre wrote: 
> >This post on sage-devel 
> >[1]
> https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ 
> >has a part (which I'm copying below for convenience) about 
> >SageMath's documentation at [2]combinat.sagemath.org/doc. 
> >Does anybody here have some insight about these questions? 
>
> >- Excerpt from the sage-devel post at 
> >[3]
> https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ 
> >2. SageMath's developer manual at [4]combinat.sagemath.org/doc/ 
> >reference 
> >This sage-devel thread 
> > 
> >  [5]https://groups.google.com/d/topic/sage-devel/cCGobP2AgwM/ 
> >discussion 
> >is concerned with the fact that another version of SageMath's 
> >reference manual also lives at 
> >  [6]http://combinat.sagemath.org/doc/reference 
> >and that (given the trouble we are having in getting Google to 
> properly 
> >index the documentation at [7]doc.sagemath.org), queries in Google 
> >search 
> >give search engine results at [8]combinat.sagemath.org/doc, rather 
> than 
> >at [9]doc.sagemath.org. 
> >In addition, it seems that the version of the documentation at 
> >[10]combinat.sagemath.org/doc corresponds to SageMath 6.3 
> >, while SageMath is now at 7.3. 
> >Combinat people, 
> >- is there a use for hosting SageMath's documentation at 
> >  [11]combinat.sagemath.org/doc and should it be updated to 7.3? 
> >- does this version have extra stuff from the combinat queue? 
> >- who is in charge? 
>
> - This documentation is compiled with an old Sage with the patches 
>   from the legacy Sage-Combinat queue applied. 
>
> - It was occasionally useful, as there are some thematic tutorials 
>   that have not yet been integrated into Sage. 
>

Yes, for instance
http://combinat.sagemath.org/doc/thematic_tutorials/demo-cython.html
which now gives "Not Found" due to the redirect.
 

> - The documentation cannot be updated to 7.3, as the patches don't 
>   apply anymore. 
>
> - It was hosted in the user directory of 
>   comb...@combinat.sagemath.org ; Anne, Florent and myself 
> have the 
>   ssh keys for that account. 
>
> I see that combinat.sagemath.org/doc is now redirected to the main 
> Sage documentation. Given the issues the old doc was causing with 
> google searches, I guess that's fair enough.
>

I guess once the Google indexing of doc.sagemath.org is solved,
we should probably remove this redirection.

It would be worth to open a Sage trac ticket dedicated
to moving the sage-combinat tutorials into Sage proper.

Samuel

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Iterators and KeyboardInterrupt

[Nils Bruin]

On Monday, August 22, 2016 at 12:42:26 AM UTC-7, Salvatore Stella wrote:
>
> At the moment the init function of :class:`ClusterAlgebra` calls 
> :meth:`reset_exploring_iterator` that creates an instance of :meth:`seeds` 
> and 
> stores it in an internal var ``_sd_iter``. 


Are you really getting benefit from storing the state (i.e., the actual 
iterator) on the parent itself? (I see you haven't made ClusterAlgebra 
UniqueRepresentation, so it's not an immediate bug to have it this way)

Perhaps it's cleaner to hand out iterator objects that are kept track of in 
the relevant loop. That iterator would then just die whenever the frames of 
a KeyboardInterrupt exception are discarded and the flawed state wouldn't 
persist.

The iterator objects could even hold a reference to the ClusterAlgebra 
(they may well have to) and write back interesting finds that may benefit 
future computations back onto the ClusterAlgebra.

If you really need to store the iterator object on the ClusterAlgebra and 
you're finding it needs to be resilient in the face of KeyboardInterrupts 
(that is to say, be able to produce a "next" element after keyboard 
interruption), you could write your own iterator object and store that. An 
iterator object is an object that implements "__iter__" returning self and 
"next" returning the "next" element. See 
https://docs.python.org/2/library/stdtypes.html#iterator-types .

Using "yield" is a convenient way of writing simple iterators, but it is in 
no way the only way of doing it. When you explicitly store state yourself 
it is much easier to define the right behaviour in the face of unexpected 
interrupts.

 

> The methods that need to explore 
> the tree just call ``next`` on this iterator till they get the data they 
> are 
> looking for. This process is potentially never ending. For this reason the 
> user may specify a maximum depth at which to stop. 
>
> Since this iterator is computationally intense, it easy to imagine that 
> users will tend to start searching but change their mind in mid 
> computation 
> and send an interrupt. This, unfortunately, leaves ``_sd_iter`` in a 
> corrupted state and all future calls to it will result in a StopIteration. 
>
> At the moment we have a warning in the docstring of each method accessing 
> _sd_iter to explain that after sending a KeyboardInterrupt the user needs 
> to 
> call :meth:`reset_exploring_iterator`. Do you think we should instead 
> catch 
> the interrupt, reset the iterator and then raise it again like this? 
>
>
> @@ -1999,12 +1999,17 @@ class ClusterAlgebra(Parent): 
>  sage: len(A.g_vectors_so_far()) 
>  14 
>  """ 
> -while self._explored_depth <= depth: 
> -try: 
> -seed = next(self._sd_iter) 
> -self._explored_depth = seed.depth() 
> -except StopIteration: 
> -break 
> +try: 
> +while self._explored_depth <= depth: 
> +try: 
> +seed = next(self._sd_iter) 
> +self._explored_depth = seed.depth() 
> +except StopIteration: 
> +break 
> +except KeyboardInterrupt: 
> +print("Got a KeyboardInterrupt, cleaning up before 
> returning.") 
> +self.reset_exploring_iterator() 
> +raise KeyboardInterrupt 
>
> The advantage of this is that the user does not have to remember an extra 
> (unnatural?) step. The drawback is that he/she looses any customization 
> that 
> may have been made by a previous call to :meth:`reset_exploring_iterator`. 
>
>
> On a related topic. In the situation just described, the next exploration 
> will have to begin from the root of the tree resulting in a lot of wasted 
> effort. Is there any way around this? Sending a node of the tree back to 
> the 
> iterator does not seem useful because of the breath-first search. 
>
> 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.

[sage-devel] Re: Iterators and KeyboardInterrupt

[leif]

VulK wrote:
> Dear All,
> in a ticket (#21254) I recently created with Dylan Rupel I need to explore a
> (possibly) infinite n-regular tree in a breath-first search.

Breath-first search = Search & pray? ;-)

(Possibly infinite apnoea can't be healthy.)


> The way it is
> implemented right now is via iterators. I am writing to you to ask if there
> is a preferred way to deal with user interaction and KeyboardInterrupt.
> 
> At the moment the init function of :class:`ClusterAlgebra` calls
> :meth:`reset_exploring_iterator` that creates an instance of :meth:`seeds` and
> stores it in an internal var ``_sd_iter``. The methods that need to explore
> the tree just call ``next`` on this iterator till they get the data they are
> looking for. This process is potentially never ending. For this reason the
> user may specify a maximum depth at which to stop.
> 
> Since this iterator is computationally intense, it easy to imagine that
> users will tend to start searching but change their mind in mid computation
> and send an interrupt. This, unfortunately, leaves ``_sd_iter`` in a
> corrupted state and all future calls to it will result in a StopIteration.
> 
> At the moment we have a warning in the docstring of each method accessing
> _sd_iter to explain that after sending a KeyboardInterrupt the user needs to
> call :meth:`reset_exploring_iterator`. Do you think we should instead catch
> the interrupt, reset the iterator and then raise it again like this?
> 
> 
> @@ -1999,12 +1999,17 @@ class ClusterAlgebra(Parent):
>  sage: len(A.g_vectors_so_far())
>  14
>  """
> -while self._explored_depth <= depth:
> -try:
> -seed = next(self._sd_iter)
> -self._explored_depth = seed.depth()
> -except StopIteration:
> -break
> +try:
> +while self._explored_depth <= depth:
> +try:
> +seed = next(self._sd_iter)
> +self._explored_depth = seed.depth()
> +except StopIteration:
> +break
> +except KeyboardInterrupt:
> +print("Got a KeyboardInterrupt, cleaning up before returning.")
> +self.reset_exploring_iterator()
> +raise KeyboardInterrupt
> 
> The advantage of this is that the user does not have to remember an extra
> (unnatural?) step. The drawback is that he/she looses any customization that
> may have been made by a previous call to :meth:`reset_exploring_iterator`.
> 
> 
> On a related topic. In the situation just described, the next exploration
> will have to begin from the root of the tree resulting in a lot of wasted
> effort. Is there any way around this? Sending a node of the tree back to the
> iterator does not seem useful because of the breath-first search.

Well, one usually implements checkpoints for such things (continually
saving state to optionally resume later if interrupted).


-leif


-- 
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-combinat-devel] Re: Multiple versions of SageMath's documentation online

[leif]

Nicolas M. Thiery wrote:
> On Thu, Aug 11, 2016 at 10:46:08PM +0200, Samuel Lelièvre wrote:
>>(SNIP)
>>In addition, it seems that the version of the documentation at
>>[10]combinat.sagemath.org/doc corresponds to SageMath 6.3
>>, while SageMath is now at 7.3.
>>Combinat people,
>>- is there a use for hosting SageMath's documentation at
>>  [11]combinat.sagemath.org/doc and should it be updated to 7.3?
>>- does this version have extra stuff from the combinat queue?
>>- who is in charge?
> 
> - This documentation is compiled with an old Sage with the patches
>   from the legacy Sage-Combinat queue applied.
> 
> - It was occasionally useful, as there are some thematic tutorials
>   that have not yet been integrated into Sage.
> 
> - The documentation cannot be updated to 7.3, as the patches don't
>   apply anymore.
> 
> - It was hosted in the user directory of
>   combi...@combinat.sagemath.org; Anne, Florent and myself have the
>   ssh keys for that account.

Is public.gmane.org at all still up?

Samuel pointed me to [1] just yesterday.  (Gmane's web interface has
meanwhile gone, will perhaps return if others take over; luckily NNTP is
still there.)


-leif

[1] https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/


> I see that combinat.sagemath.org/doc is now redirected to the main
> Sage documentation. Given the issues the old doc was causing with
> google searches, I guess that's fair enough.
> 
> Cheers,
>   Nicolas
> --
> Nicolas M. Thiéry "Isil" 
> http://Nicolas.Thiery.name/


-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: [sage-combinat-devel] Multiple versions of SageMath's documentation online

[Nicolas M. Thiery]

Dear Samuel, Frédéric, Harald,

Sorry for the slow answer; I am just back from vacations.

Thanks Sam, Frédéric for the pings!

On Thu, Aug 11, 2016 at 10:46:08PM +0200, Samuel Lelièvre wrote:
>This post on sage-devel
>[1]https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ
>has a part (which I'm copying below for convenience) about
>SageMath's documentation at [2]combinat.sagemath.org/doc.
>Does anybody here have some insight about these questions?

>- Excerpt from the sage-devel post at
>[3]https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ
>2. SageMath's developer manual at [4]combinat.sagemath.org/doc/
>reference
>This sage-devel thread
> 
>  [5]https://groups.google.com/d/topic/sage-devel/cCGobP2AgwM/
>discussion
>is concerned with the fact that another version of SageMath's
>reference manual also lives at
>  [6]http://combinat.sagemath.org/doc/reference
>and that (given the trouble we are having in getting Google to properly
>index the documentation at [7]doc.sagemath.org), queries in Google
>search
>give search engine results at [8]combinat.sagemath.org/doc, rather than
>at [9]doc.sagemath.org.
>In addition, it seems that the version of the documentation at
>[10]combinat.sagemath.org/doc corresponds to SageMath 6.3
>, while SageMath is now at 7.3.
>Combinat people,
>- is there a use for hosting SageMath's documentation at
>  [11]combinat.sagemath.org/doc and should it be updated to 7.3?
>- does this version have extra stuff from the combinat queue?
>- who is in charge?

- This documentation is compiled with an old Sage with the patches
  from the legacy Sage-Combinat queue applied.

- It was occasionally useful, as there are some thematic tutorials
  that have not yet been integrated into Sage.

- The documentation cannot be updated to 7.3, as the patches don't
  apply anymore.

- It was hosted in the user directory of
  combi...@combinat.sagemath.org; Anne, Florent and myself have the
  ssh keys for that account.

I see that combinat.sagemath.org/doc is now redirected to the main
Sage documentation. Given the issues the old doc was causing with
google searches, I guess that's fair enough.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
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-combinat-devel] Multiple versions of SageMath's documentation online

[Nicolas M. Thiery]

Dear Samuel, Frédéric, Harald,

Sorry for the slow answer; I am just back from vacations.

Thanks Sam, Frédéric for the pings!

On Thu, Aug 11, 2016 at 10:46:08PM +0200, Samuel Lelièvre wrote:
>This post on sage-devel
>[1]https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ
>has a part (which I'm copying below for convenience) about
>SageMath's documentation at [2]combinat.sagemath.org/doc.
>Does anybody here have some insight about these questions?

>- Excerpt from the sage-devel post at
>[3]https://groups.google.com/d/msg/sage-devel/NJSAQTjhIWE/NWbqC8xOAQAJ
>2. SageMath's developer manual at [4]combinat.sagemath.org/doc/
>reference
>This sage-devel thread
> 
>  [5]https://groups.google.com/d/topic/sage-devel/cCGobP2AgwM/
>discussion
>is concerned with the fact that another version of SageMath's
>reference manual also lives at
>  [6]http://combinat.sagemath.org/doc/reference
>and that (given the trouble we are having in getting Google to properly
>index the documentation at [7]doc.sagemath.org), queries in Google
>search
>give search engine results at [8]combinat.sagemath.org/doc, rather than
>at [9]doc.sagemath.org.
>In addition, it seems that the version of the documentation at
>[10]combinat.sagemath.org/doc corresponds to SageMath 6.3
>, while SageMath is now at 7.3.
>Combinat people,
>- is there a use for hosting SageMath's documentation at
>  [11]combinat.sagemath.org/doc and should it be updated to 7.3?
>- does this version have extra stuff from the combinat queue?
>- who is in charge?

- This documentation is compiled with an old Sage with the patches
  from the legacy Sage-Combinat queue applied.

- It was occasionally useful, as there are some thematic tutorials
  that have not yet been integrated into Sage.

- The documentation cannot be updated to 7.3, as the patches don't
  apply anymore.

- It was hosted in the user directory of
  combi...@combinat.sagemath.org; Anne, Florent and myself have the
  ssh keys for that account.

I see that combinat.sagemath.org/doc is now redirected to the main
Sage documentation. Given the issues the old doc was causing with
google searches, I guess that's fair enough.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
http://Nicolas.Thiery.name/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-combinat-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-combinat-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-combinat-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: [Yet again] Sage's R vs system's R

[leif]

Emmanuel Charpentier wrote:
> From Trac#20523  :
> 
> Replying to [comment:9 tscrim]:
>> I get a failure trying to install this on Cygwin32 with
>> {{{
>> checking for lzma_version_number in -llzma... no
>> configure: error: "liblzma library and headers are required"
>> Error configuring R.
>> }}}
>> which is the same failure I had on #20190.
> 
> From the R 3.3.0 release notes
>  :
>  :
> 
> The previously included versions of zlib, bzip2, xz and PCRE have
> been removed, so suitable external (usually system) versions are
> required (see the ‘R Installation and Administration’ manual).
> 
> 
> So it's either :
> 
>   * add xz-tools (né lzma-utils) to the list of prerequisites for Sage
> (i. e. relying on system's liblzma) ;
>   * adding xz-tools (at least the lzma library) to sage (cluttering it
> with yet one more library to maintain) ;
>   * or relying on system's R through an interface that remains to be
> written...
> 
> 
> Pick your poison...

Make R optional?  (Nothing in Sage depends on it, except for the
interface to it, including Rpy2.)

xz is already an /optional/ Sage package; we'd also need PCRE (or make
it a prerequisite, just for R).  (I'd personally make xz standard
anyway, and recompress our upstream tarballs with it, probably even
dropping bzip2.)

In case we made R optional, we could re-include some stuff (such as
PCRE) into the "upstream" tarball as well; not sure if we should do so
if we keep R standard.


My 2ct,

-leif


-- 
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: Good news on the Windows/Cygwin front

[Emmanuel Charpentier]

Could you have a look at Trac#20523  
? This trivial update bangs on a missing dependency on Cygwin...

Le lundi 22 août 2016 11:19:38 UTC+2, Erik Bray a écrit :
>
> Hi all, 
>
> Here is the result of my latest run of `./sage -t -a` on Cygwin 64-bit: 
>
> $ ./sage -t -a 
> Running doctests with ID 2016-08-19-18-59-29-d5e4434f. 
> Git branch: cygwin 
> Using --optional=mpir,python2,sage 
> Doctesting entire Sage library. 
> Doctesting 3444 files. 
> ... 
> -- 
> sage -t --warn-long 68.0 src/sage/interfaces/expect.py  # 1 doctest failed 
> -- 
> Total time for all tests: 11840.1 seconds 
> cpu time: 8006.9 seconds 
> cumulative wall time: 10877.7 seconds 
>
>
> This is on a branch based on a somewhat old (maybe about a month) 
> version of the develop branch, plus all the fixes I've made so far for 
> Cygwin (not all of which have tickets yet). 
>
> The one failure is something of a fluke--I've actually *never* seen 
> that particular failure before this test run, and when I test that 
> module by itself it's passing.  Nevertheless it does bother me a 
> little bit and I want to try to reproduce the failure.  But it comes 
> as no surprise that there could still be semi-non-deterministic errors 
> in the pexpect interface. 
>
> Other than that, most things are working well.  I believe there are 
> still some --long tests that are failing, which I have not looked into 
> yet. But I don't think there are many. 
>
> Once I've confirmed that I can get all the tests (including the expect 
> one) running reliably my next major goal is to get a build-bot set up 
> for Cygwin.  This may be a bit challenging due to the unique 
> challenges of building Sage on Cygwin (namely, DLL rebasing), but not 
> impossible. 
>
> For further status reports on Windows I will be posting just to the 
> sage-windows group, so you can join that if you're interested in this 
> effort and ignore otherwise: 
> https://groups.google.com/forum/#!forum/sage-windows 
>
> There are also some tickets needing review for various Cygwin-related 
> issues: 
>
>
> https://trac.sagemath.org/query?status=needs_review=new=porting%3A+Cygwin=id=summary=status=type=priority=milestone=component=priority
>  
>
> Thanks, 
> Erik 
>

-- 
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: [Yet again] Sage's R vs system's R

[Emmanuel Charpentier]

>From Trac#20523  :

Replying to [comment:9 tscrim]:
> I get a failure trying to install this on Cygwin32 with
> {{{
> checking for lzma_version_number in -llzma... no
> configure: error: "liblzma library and headers are required"
> Error configuring R.
> }}}
> which is the same failure I had on #20190.

>From the R 3.3.0 release notes 
 :
 :

The previously included versions of zlib, bzip2, xz and PCRE have been 
> removed, so suitable external (usually system) versions are required (see 
> the ‘R Installation and Administration’ manual).
>

So it's either :

   - add xz-tools (né lzma-utils) to the list of prerequisites for Sage (i. 
   e. relying on system's liblzma) ;
   - adding xz-tools (at least the lzma library) to sage (cluttering it 
   with yet one more library to maintain) ;
   - or relying on system's R through an interface that remains to be 
   written...


Pick your poison...

-- 
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: Problem retrieving a (positively reviewed) ticket

[Erik Bray]

On Sun, Aug 21, 2016 at 8:14 PM, Dima Pasechnik  wrote:
>
>
> On Sunday, August 21, 2016 at 5:23:28 PM UTC+1, Volker Braun wrote:
>>
>> This should be fixed now
>>
> Thanks much, Volker!
> I installed usual ubuntu updates from standard debs, but as you pointed out
> to me there was a manual change
> in a config file that got overwritten... :-(
> We need to find a way to prevent these things in the future.

I haven't finished documenting all of the configuration yet, so that's my fault.

In the future it will be preferable to have a docker container that
rolls out the basic configuration, and disable Ubuntu updates, with
preference to rebuilding the container on top of updated base images.


>> On Sunday, August 21, 2016 at 12:15:05 AM UTC+2, Emmanuel Charpentier
>> wrote:
>>>
>>> I am finding myself unable to fetch the positively reviewed ticket
>>> TRAC#21135 :
>>>
>>> charpent@asus16-ec:/usr/local/sage-7$ git trac checkout 21135
>>> Loading ticket #21135...
>>> Checking out Trac #21135 remote branch public/21135 -> local branch
>>> t/21135/public/21135...
>>> Traceback (most recent call last):
>>>   File "/usr/local/bin/git-trac", line 18, in 
>>> cmdline.launch()
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/cmdline.py", line
>>> 215, in launch
>>> app.checkout(args.ticket_or_branch, args.branch_name)
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/app.py", line 116,
>>> in checkout
>>> self._checkout_ticket(int(ticket_or_branch), branch_name)
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/app.py", line 144,
>>> in _checkout_ticket
>>> self.repo.checkout_new_branch(ticket.branch, branch)
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/git_repository.py",
>>> line 136, in checkout_new_branch
>>> self.git.fetch('trac', remote)
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py",
>>> line 341, in meth
>>> return self.execute(git_cmd, *args, **kwds)
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py",
>>> line 328, in execute
>>> popen_stderr=subprocess.PIPE)
>>>   File "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py",
>>> line 263, in _run
>>> raise GitError(result)
>>> git_trac.git_error.GitError: git returned with non-zero exit code (128)
>>> when executing "git fetch trac public/21135"
>>> STDERR: fatal: Couldn't find remote ref public/21135
>>>
>>> I do not understand this error. This never happened to me before.
>>>
>>> Ideas ?
>>>
>>> --
>>> Emmanuel Charpentier
>
> --
> 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.

-- 
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: Dealing with libc math differences

[Erik Bray]

On Sat, Aug 20, 2016 at 3:47 PM, leif  wrote:
> Erik Bray wrote:
>> On Fri, Aug 19, 2016 at 11:00 AM, Erik Bray  wrote:
>>> On Wed, Aug 10, 2016 at 1:38 PM, Erik Bray  wrote:
 Hi all,

 Sorry if this has been discussed ad-infinitum before--I looked around
 a bit but didn't find a definitive answer.

 I have one (well at least one) test that's failing on Cygwin due to
 tiny difference in the last digit of the result of log(3).

 This leads to to several questions:

 1) Is it worth investigating the reason for the difference?
 2) Is it worth trying to provide a workaround for the difference?
 3) Or should the test just be updated to ignore the last couple digits
 of the result, and if so how (ellipses?)
>>>
>>> The difference in log(3) strikes again, but this time in a test where
>>> it's harder to just set a tolerance.  The test is for the algdep()
>>> method of ComplexDoubleElements:
>>> https://git.sagemath.org/sage.git/tree/src/sage/rings/complex_double.pyx#n2377
>>>
>>> Because of the way RDF(sqrt(3)) is calculated it uses log(3).  This
>>> results in a different numeric result for "z".  The test already has
>>> "abs tol 1e-16" for "z" which is fine, but the algorithm from PARI is
>>> sensitive to even that small difference and gives a totally different
>>> polynomial result:
>>>
>>> sage: z = (1/2)*(1 + RDF(sqrt(3)) *CDF.0); z
>>> 0.5 + 0.8660254037844386*I
>>> sage: p = z.algdep(5); p
>>> x^5 + x^2
>>> sage: z^5 + z^2
>>> -4.996003610813204e-16 - 2.220446049250313e-16*I
>>>
>>> So the answer isn't wrong--it's still a good approximation.  But the
>>> test expects:
>>>
>>> sage: z = (1/2)*(1 + RDF(sqrt(3)) *CDF.0); z
>>> 0.5 + 0.8660254037844387*I
>>> sage: p = z.algdep(5); p
>>> x^3 + 1
>>>
>>> Not really sure what the best course of action would be for this test
>>> then, other than to hard-code a value for z.
>>
>> To answer my own question, this is how I rewrote the test for now:
>>
>> 2389 sage: z = (1/2)*(1 + RDF(sqrt(3)) *CDF.0); z   # abs tol 
>> 1e-16
>> 2390 0.5 + 0.8660254037844387*I
>> 2391 sage: p = z.algdep(5); p  # random
>> 2392 x^3 + 1
>> 2393 sage: p.factor()
>> 2394 (x + 1) * ... (x^2 - x + 1)
>> 2395 sage: abs(z^2 - z + 1) < 1e-14
>> 2396 True
>>
>> This works out fine because the result I got still has (x^2 - x + 1)
>> as a factor.  It just has one additional factor of x^2.
>> I'm not too happy with marking the result of z.algdep() as "random"
>> though.  It's definitely deterministic, just sensitive.  I think the
>> doctest module maybe needs an "# ignore" flag that is effectively the
>> same as "# random" without the implication that the output is truly
>> random.  Just that the line should be run, but its output should not
>> be checked.
>
> At least add a comment why the '# random' is there, e.g. something like
> '# random -- exact output differs on Cygwin/depending on the precision
> of log()...' (perhaps with a trac ticket number).

Already done one better: https://trac.sagemath.org/ticket/21292
(added you to CC if you're interested but feel free to remove
otherwise)

> If there are more instances, we may consider '# optional -- cygwin' or
> whatever (analogous to '# 32-bit' and '# 64-bit').

Yes, having platform specific tests could be nice.  I keep thinking of
adding something to this effect, but so far I've been able to avoid
the need, which I think is good.  But if it comes to it, this will be
nice to have.  If such a thing is implemented I think it should use
the existing (draft, but long in use in the wild) standard for
Environment Markers: https://www.python.org/dev/peps/pep-0496/

Best,
Erik

-- 
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] Good news on the Windows/Cygwin front

[Erik Bray]

Hi all,

Here is the result of my latest run of `./sage -t -a` on Cygwin 64-bit:

$ ./sage -t -a
Running doctests with ID 2016-08-19-18-59-29-d5e4434f.
Git branch: cygwin
Using --optional=mpir,python2,sage
Doctesting entire Sage library.
Doctesting 3444 files.
...
--
sage -t --warn-long 68.0 src/sage/interfaces/expect.py  # 1 doctest failed
--
Total time for all tests: 11840.1 seconds
cpu time: 8006.9 seconds
cumulative wall time: 10877.7 seconds


This is on a branch based on a somewhat old (maybe about a month)
version of the develop branch, plus all the fixes I've made so far for
Cygwin (not all of which have tickets yet).

The one failure is something of a fluke--I've actually *never* seen
that particular failure before this test run, and when I test that
module by itself it's passing.  Nevertheless it does bother me a
little bit and I want to try to reproduce the failure.  But it comes
as no surprise that there could still be semi-non-deterministic errors
in the pexpect interface.

Other than that, most things are working well.  I believe there are
still some --long tests that are failing, which I have not looked into
yet. But I don't think there are many.

Once I've confirmed that I can get all the tests (including the expect
one) running reliably my next major goal is to get a build-bot set up
for Cygwin.  This may be a bit challenging due to the unique
challenges of building Sage on Cygwin (namely, DLL rebasing), but not
impossible.

For further status reports on Windows I will be posting just to the
sage-windows group, so you can join that if you're interested in this
effort and ignore otherwise:
https://groups.google.com/forum/#!forum/sage-windows

There are also some tickets needing review for various Cygwin-related issues:

https://trac.sagemath.org/query?status=needs_review=new=porting%3A+Cygwin=id=summary=status=type=priority=milestone=component=priority

Thanks,
Erik

-- 
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] Iterators and KeyboardInterrupt

[VulK]

Dear All,
in a ticket (#21254) I recently created with Dylan Rupel I need to explore a
(possibly) infinite n-regular tree in a breath-first search. The way it is
implemented right now is via iterators. I am writing to you to ask if there
is a preferred way to deal with user interaction and KeyboardInterrupt.

At the moment the init function of :class:`ClusterAlgebra` calls
:meth:`reset_exploring_iterator` that creates an instance of :meth:`seeds` and
stores it in an internal var ``_sd_iter``. The methods that need to explore
the tree just call ``next`` on this iterator till they get the data they are
looking for. This process is potentially never ending. For this reason the
user may specify a maximum depth at which to stop.

Since this iterator is computationally intense, it easy to imagine that
users will tend to start searching but change their mind in mid computation
and send an interrupt. This, unfortunately, leaves ``_sd_iter`` in a
corrupted state and all future calls to it will result in a StopIteration.

At the moment we have a warning in the docstring of each method accessing
_sd_iter to explain that after sending a KeyboardInterrupt the user needs to
call :meth:`reset_exploring_iterator`. Do you think we should instead catch
the interrupt, reset the iterator and then raise it again like this?


@@ -1999,12 +1999,17 @@ class ClusterAlgebra(Parent):
 sage: len(A.g_vectors_so_far())
 14
 """
-while self._explored_depth <= depth:
-try:
-seed = next(self._sd_iter)
-self._explored_depth = seed.depth()
-except StopIteration:
-break
+try:
+while self._explored_depth <= depth:
+try:
+seed = next(self._sd_iter)
+self._explored_depth = seed.depth()
+except StopIteration:
+break
+except KeyboardInterrupt:
+print("Got a KeyboardInterrupt, cleaning up before returning.")
+self.reset_exploring_iterator()
+raise KeyboardInterrupt

The advantage of this is that the user does not have to remember an extra
(unnatural?) step. The drawback is that he/she looses any customization that
may have been made by a previous call to :meth:`reset_exploring_iterator`.


On a related topic. In the situation just described, the next exploration
will have to begin from the root of the tree resulting in a lot of wasted
effort. Is there any way around this? Sending a node of the tree back to the
iterator does not seem useful because of the breath-first search.

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.