bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Changed keywords from none to sandpile
Closed bc92013b-9220-40da-a45f-06c52942e68d closed 9 years ago
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Changed keywords from none to sandpile
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Author: David Perkinson
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Revisions to sandpiles to be posted soon.
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Branch: u/dperkinson/sandpile_revisions
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Attachment: summary_of_revisions.txt
Summary of revisions
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago New commits:
9e022d8 | Revisions to sandpiles |
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Commit: 9e022d8
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Description changed:
---
+++
@@ -1 +1,67 @@
+Summary of sandpile.py changes from version 2.3 to 2.4
+June 11, 2015
+1. Eliminated dependence on 4ti2, substituing the use of Polyhedron methods. Thus, no optional packages are necessary.
+2. Fixed bug in Sandpile.__init__ so that now multigraphs are handled correctly.
+3. Created `sandpiles` to handle examples of Sandpiles in analogy with `graphs`, `simplicial_complexes`, and `polytopes`. In the process, we implemented a much faster way of producing the sandpile grid graph.
+4. Added support for open and closed sandpile Markov chains.
+5. Added support for Weierstrass points.
+6. Implemented the Cori-Le Borgne algorithm for computing ranks of divisors on complete graphs.
+
+NEW METHODS
+Sandpile
+* avalanche_polynomial -- the avalance polynomial
+* genus -- genus of the sandpile graph (undirected case only)
+* group_gens -- minimal set of generators for the sandpile group
+* help -- list of Sandpile-specific methods
+* jacobian_representatives -- representatives for elements of the Jacobian group
+* markov_chain -- open and closed sandpile Markov chain
+* picard_representatives -- representatives for elements of the Picard group
+* smith_form -- Smith normal from for transpose of the Laplacian
+* stable_configs -- iterator for all stable configurations
+* stationary_density -- the stationary density for the closed sandpile Markov chain
+* tutte_polynomial -- Tutte polynomial of underlying graph (undirected case only)
+
+SandpileConfig
+* burst_size -- statistic for sandpile Markov chain
+* help -- list of SandpileConfig methods
+
+SandpileDivisor
+* help -- list of SandpileDivisor methods
+* is_linearly_equivalent -- Is the divisor linearly equivalent to a given divisor?
+* is_q_reduced -- Is the divisor q-reduced (q=sink)
+* is_weierstrass_pt -- Is the given vertex a Weierstrass pt for the divisor?
+* polytope -- polytope determining the complete linear system
+* polytope_integer_pts -- integer points inside the divisor's polytope
+* q_reduced -- linearly equiv. q-reduced divisor
+* rank -- the rank of the divisor
+* simulate_threshold -- simulate closed sandpile Markov chain until threshold
+* stabilize -- stabilize, if possible
+* weierstrass_gap_seq -- the Weierstrass gap sequence for the given vertex
+* weierstrass_pts -- all Weierstrass points (vertices) for the divisor
+* weierstrass_rank_seq -- the rank sequence at a Weierstrass point
+
+DEPRECATED
+* SandpileDivisor.linear_system -- uses 4ti2. Replaced by SandpileDivisor.polytope.
+* SandpileDivisor.r_of_D -- uses 4ti2. Replaced by SandpileDivisor.rank.
+* sandlib method -- replaced by `sandpiles`
+* complete_sandpile -- replaced by sandpiles.Complete
+* grid_sandpile -- replaced by sandpiles.Grid
+* triangle_sandpile -- Not used much. Will still be able to import.
+* aztec_sandpile -- Not used much. Will still be able to import.
+* random_digraph -- Duplicates methods from graphs and digraphs, more or less.
+* random_DAG -- Not used much. Will still be able to import.
+* random_tree -- Duplicates method from graphs and digraphs, more or less.
+* glue_graphs -- Not used much. Will still be able to import.
+* admissible_partitions -- Not used much. Will still be able to import.
+* firing_vector -- Replaced by SandpileDivisor.is_linearly_equivalent.
+* min_cycles -- Not used much. Will still be able to import.
+
+MINOR CHANGES
+* The `sink` argument to Sandpile.__init__ now defaults to the first vertex.
+* A SandpileConfig or SandpileDivisor may now be multiplied by an integer.
+* Sped up `__add__` method for SandpileConfig and SandpileDivisor.
+* Enhanced string representation of a Sandpile (via `_repr_` and the `name` method).
+* Recurrents for complete graphs and cycle graphs are computed more quickly.
+* The stabilization code for SandpilConfig has been made more efficient.
+* Added optional probability distribution arguments to `add_random` methods.Description changed:
---
+++
@@ -1,7 +1,7 @@
Summary of sandpile.py changes from version 2.3 to 2.4
June 11, 2015
-1. Eliminated dependence on 4ti2, substituing the use of Polyhedron methods. Thus, no optional packages are necessary.
+1. Eliminated dependence on 4ti2, substituting the use of Polyhedron methods. Thus, no optional packages are necessary.
2. Fixed bug in Sandpile.__init__ so that now multigraphs are handled correctly.
3. Created `sandpiles` to handle examples of Sandpiles in analogy with `graphs`, `simplicial_complexes`, and `polytopes`. In the process, we implemented a much faster way of producing the sandpile grid graph.
4. Added support for open and closed sandpile Markov chains.
@@ -26,7 +26,7 @@
* burst_size -- statistic for sandpile Markov chain
* help -- list of SandpileConfig methods
-SandpileDivisor
+SandpileDivisor
* help -- list of SandpileDivisor methods
* is_linearly_equivalent -- Is the divisor linearly equivalent to a given divisor?
* is_q_reduced -- Is the divisor q-reduced (q=sink)Description changed:
---
+++
@@ -9,7 +9,8 @@
6. Implemented the Cori-Le Borgne algorithm for computing ranks of divisors on complete graphs.
NEW METHODS
-Sandpile
+
+**Sandpile**
* avalanche_polynomial -- the avalance polynomial
* genus -- genus of the sandpile graph (undirected case only)
* group_gens -- minimal set of generators for the sandpile group
@@ -22,11 +23,11 @@
* stationary_density -- the stationary density for the closed sandpile Markov chain
* tutte_polynomial -- Tutte polynomial of underlying graph (undirected case only)
-SandpileConfig
+**SandpileConfig**
* burst_size -- statistic for sandpile Markov chain
* help -- list of SandpileConfig methods
-SandpileDivisor
+**SandpileDivisor**
* help -- list of SandpileDivisor methods
* is_linearly_equivalent -- Is the divisor linearly equivalent to a given divisor?
* is_q_reduced -- Is the divisor q-reduced (q=sink)Description changed:
Description changed:
---
+++
@@ -64,5 +64,5 @@
* Sped up `__add__` method for SandpileConfig and SandpileDivisor.
* Enhanced string representation of a Sandpile (via `_repr_` and the `name` method).
* Recurrents for complete graphs and cycle graphs are computed more quickly.
-* The stabilization code for SandpilConfig has been made more efficient.
+* The stabilization code for SandpileConfig has been made more efficient.
* Added optional probability distribution arguments to `add_random` methods.
jdemeyer
commented
9 years ago Doctest formatting is incorrect:
Sandpiles can be created from Graphs and DiGraphs.
sage: g = DiGraph({0:{1:2,2:4}, 1:{1:3,2:1}, 2:{1:7}}, weighted=True)should be
Sandpiles can be created from Graphs and DiGraphs::
sage: g = DiGraph({0:{1:2,2:4}, 1:{1:3,2:1}, 2:{1:7}}, weighted=True)(and there are a few more formatting errors like this)
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
1c2361f | Revised doctest formatting. |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago 
videlec
commented
9 years ago Hello,
From the patchbot
Building reference manual, first pass.
Warning: Missing title for sage.misc.six
Error building the documentation.
Traceback (most recent call last):
File "/home/vincent/sage_patchbot/src/doc/common/builder.py", line 1626, in <module>
getattr(get_builder(name), type)()
File "/home/vincent/sage_patchbot/src/doc/common/builder.py", line 292, in _wrapper
getattr(get_builder(document), 'inventory')(*args, **kwds)
File "/home/vincent/sage_patchbot/src/doc/common/builder.py", line 503, in _wrapper
x.get(99999)
File "/home/vincent/sage_patchbot/local/lib/python/multiprocessing/pool.py", line 558, in get
raise self._value
OSError: [dynamics ] /home/vincent/sage_patchbot/local/lib/python2.7/site-packages/sage/sandpiles/sandpile.py:docstring of sage.sandpiles.sandpile:8: ERROR: Unexpected indentation.
make: *** [doc-html] Error 1
('Apply', '--', 6, 'seconds')
Traceback (most recent call last):
File "/home/vincent/sage_patchbot/local/bin/patchbot/patchbot.py", line 871, in test_a_ticket
do_or_die("$MAKE")
File "/home/vincent/sage_patchbot/local/bin/patchbot/util.py", line 143, in do_or_die
raise exn_class("{} {}".format(res, cmd))
Exception: 512 $MAKE
2015-06-11 19:01:41 +0200
(25, 'seconds')If you see something red or yellow on the patchbot little ball (on the right top of the ticket description) then something is bad. You can then click on it to see what it is.
tscrim
commented
9 years ago Some quick comments:
INPUT: and OUTPUT: blocks if there is no input or output.INPUT: blocks like this:INPUT:
- ``foo`` -- the bar
- ``param`` -- (default: 5) an integer we do something with that is typically
the value 5, mainly I'm blabbing on to make this a longer line
- ``opt`` -- (optional) some optional argumentclass Foo(object):.help() method. It can be very painful to manage this by hand... NOTE::
This is a note. Everything should be one level further indented than before... WARNING::[NameOfReference]_.bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago How does one run patchbot and view the errors? (The only testing tool I have been using is sage -t, which showed that all tests passed.)
tscrim
commented
9 years ago As Vincent said:
If you see something red or yellow on the patchbot little ball (on the right top of the ticket description) then something is bad. You can then click on it to see what it is.
It's located next to the opened/last modifed data. Once you click the red circle, you should look at the (short) log for the patchbot data. Once the documentation builds (you should check this, the easiest way to do so is run make docbuild from the $SAGE_ROOT directory or sage -docbuild all html from anywhere) and push those changes, a patchbot will (eventually) come around and test the branch on this ticket again.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
9b10bf5 | Revised docstring. Automated help methods. |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago I have just pushed changes in response to the (very helpful) comments above. The INPUT sections of the docstrings are all standardized now, as are the NOTE, WARNING, etc., sections. SandpileExamples has the "new-class" style. The help functions are now automated rather than hard-wired, as advised.
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
tscrim
commented
9 years ago Replying to @sagetrac-dperkinson:
I have just pushed changes in response to the (very helpful) comments above. The INPUT sections of the docstrings are all standardized now, as are the NOTE, WARNING, etc., sections.
SandpileExampleshas the "new-class" style. The help functions are now automated rather than hard-wired, as advised.
Looks good. This could potentially be used as a model for other parts of Sage.
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Replying to @tscrim:
Replying to @sagetrac-dperkinson:
I have just pushed changes in response to the (very helpful) comments above. The INPUT sections of the docstrings are all standardized now, as are the NOTE, WARNING, etc., sections.
SandpileExampleshas the "new-class" style. The help functions are now automated rather than hard-wired, as advised.Looks good. This could potentially be used as a model for other parts of Sage.
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
Just to be completely clear: suppose, for example, that I have a docstring with None listed under INPUT and integer listed under OUTPUT. Then I should remove the INPUT section, leaving the OUTPUT section, right?
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
I am new to git, so I could use some guidance here. I have been working in a directory called git-trac-command. The output from "git branch" shows two branches: master and t/18618/sandpile_revisions, with an asterisk next to the latter. After my initial git push command, I have modified files in another, separate, copy of sage. When I done making and testing the revisions, I copy the relevant modified files (sandpile.py, examples.py, etc.) to git-trac-command/src/sage/sandpiles. I then run ./sage -br, git add NEW FILES, git commit, and git trac push.
What is the sequence of commands I should enter to resolve the current conflict? Also, what should I have done originally to have avoided the conflict?
Thanks very much for your time and advice!
tscrim
commented
9 years ago Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
Just to be completely clear: suppose, for example, that I have a docstring with None listed under INPUT and integer listed under OUTPUT. Then I should remove the INPUT section, leaving the OUTPUT section, right?
Yes, that is correct.
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
I am new to git, so I could use some guidance here. I have been working in a directory called git-trac-command. The output from "git branch" shows two branches:
masterandt/18618/sandpile_revisions, with an asterisk next to the latter. After my initial git push command, I have modified files in another, separate, copy of sage. When I done making and testing the revisions, I copy the relevant modified files (sandpile.py, examples.py, etc.) to git-trac-command/src/sage/sandpiles. I then run./sage -br,git add NEW FILES,git commit, andgit trac push.What is the sequence of commands I should enter to resolve the current conflict? Also, what should I have done originally to have avoided the conflict?
Thanks very much for your time and advice!
What you'll need to do is the following:
$ git fetch <remote_name> develop:develop
$ git checkout t/18618/sandpile_revisions # If you aren't already in that branch
$ git merge develop
Do the rebasing
$ git commit
$ make # In the $SAGE_ROOT directory. This will take a *long* time
$ git trac pushwhere <remote_name> is likely origin (possibly trac).
For rebuilding Sage with the make, you might want to do these beforehand to help speed it up:
$ make doc-clean
$ export SAGE_NUM_THREADS=n
$ export MAKE='make -jn'
$ export SAGE_PARALLEL_SPKG_BUILDwhere n is the number of processors on your computer. If it happens to fail during the doc-building part at the end, don't worry about it.
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
Just to be completely clear: suppose, for example, that I have a docstring with None listed under INPUT and integer listed under OUTPUT. Then I should remove the INPUT section, leaving the OUTPUT section, right?
Yes, that is correct.
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
I am new to git, so I could use some guidance here. I have been working in a directory called git-trac-command. The output from "git branch" shows two branches:
masterandt/18618/sandpile_revisions, with an asterisk next to the latter. After my initial git push command, I have modified files in another, separate, copy of sage. When I done making and testing the revisions, I copy the relevant modified files (sandpile.py, examples.py, etc.) to git-trac-command/src/sage/sandpiles. I then run./sage -br,git add NEW FILES,git commit, andgit trac push.What is the sequence of commands I should enter to resolve the current conflict? Also, what should I have done originally to have avoided the conflict?
Thanks very much for your time and advice!
What you'll need to do is the following:
$ git fetch <remote_name> develop:develop $ git checkout t/18618/sandpile_revisions # If you aren't already in that branch $ git merge develop Do the rebasing $ git commit $ make # In the $SAGE_ROOT directory. This will take a *long* time $ git trac pushwhere
<remote_name>is likelyorigin(possiblytrac).
Running "git merge develop" leads to the error:
Automatic merge failed; fix conflicts and then commit the result.
For rebuilding Sage with the
make, you might want to do these beforehand to help speed it up:$ make doc-clean $ export SAGE_NUM_THREADS=n $ export MAKE='make -jn' $ export SAGE_PARALLEL_SPKG_BUILDwhere
nis the number of processors on your computer. If it happens to fail during the doc-building part at the end, don't worry about it.
tscrim
commented
9 years ago That was what I expected. You need to handle the rebase. You will have to go and edit the file and look for <<<<<< and then ===== and then >>>>>> (or something like that), these are the merge conflicts. You'll then make the files how you want them to be. You can also try git mergetool, but IMO the default mergetool isn't that good.
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
Just to be completely clear: suppose, for example, that I have a docstring with None listed under INPUT and integer listed under OUTPUT. Then I should remove the INPUT section, leaving the OUTPUT section, right?
Yes, that is correct.
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
I am new to git, so I could use some guidance here. I have been working in a directory called git-trac-command. The output from "git branch" shows two branches:
masterandt/18618/sandpile_revisions, with an asterisk next to the latter. After my initial git push command, I have modified files in another, separate, copy of sage. When I done making and testing the revisions, I copy the relevant modified files (sandpile.py, examples.py, etc.) to git-trac-command/src/sage/sandpiles. I then run./sage -br,git add NEW FILES,git commit, andgit trac push.What is the sequence of commands I should enter to resolve the current conflict? Also, what should I have done originally to have avoided the conflict?
Thanks very much for your time and advice!
What you'll need to do is the following:
$ git fetch <remote_name> develop:develop $ git checkout t/18618/sandpile_revisions # If you aren't already in that branch $ git merge develop Do the rebasing $ git commit $ make # In the $SAGE_ROOT directory. This will take a *long* time $ git trac pushwhere
<remote_name>is likelyorigin(possiblytrac).Running "git merge develop" leads to the error:
Automatic merge failed; fix conflicts and then commit the result.
For rebuilding Sage with the
make, you might want to do these beforehand to help speed it up:$ make doc-clean $ export SAGE_NUM_THREADS=n $ export MAKE='make -jn' $ export SAGE_PARALLEL_SPKG_BUILDwhere
nis the number of processors on your computer. If it happens to fail during the doc-building part at the end, don't worry about it.
Oops. Entered "make doc clean" by accident. Advice?
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Replying to @sagetrac-dperkinson:
Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
Just to be completely clear: suppose, for example, that I have a docstring with None listed under INPUT and integer listed under OUTPUT. Then I should remove the INPUT section, leaving the OUTPUT section, right?
Yes, that is correct.
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
I am new to git, so I could use some guidance here. I have been working in a directory called git-trac-command. The output from "git branch" shows two branches:
masterandt/18618/sandpile_revisions, with an asterisk next to the latter. After my initial git push command, I have modified files in another, separate, copy of sage. When I done making and testing the revisions, I copy the relevant modified files (sandpile.py, examples.py, etc.) to git-trac-command/src/sage/sandpiles. I then run./sage -br,git add NEW FILES,git commit, andgit trac push.What is the sequence of commands I should enter to resolve the current conflict? Also, what should I have done originally to have avoided the conflict?
Thanks very much for your time and advice!
What you'll need to do is the following:
$ git fetch <remote_name> develop:develop $ git checkout t/18618/sandpile_revisions # If you aren't already in that branch $ git merge develop Do the rebasing $ git commit $ make # In the $SAGE_ROOT directory. This will take a *long* time $ git trac pushwhere
<remote_name>is likelyorigin(possiblytrac).Running "git merge develop" leads to the error:
Automatic merge failed; fix conflicts and then commit the result.
For rebuilding Sage with the
make, you might want to do these beforehand to help speed it up:$ make doc-clean $ export SAGE_NUM_THREADS=n $ export MAKE='make -jn' $ export SAGE_PARALLEL_SPKG_BUILDwhere
nis the number of processors on your computer. If it happens to fail during the doc-building part at the end, don't worry about it.Oops. Entered "make doc clean" by accident. Advice?
I just hit ctrl-C, then entered "make distclean" and proceeded as suggested above. Hope that works. Thanks again for your help.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
481dd23 | fixed conflict |
bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Replying to @sagetrac-dperkinson:
Replying to @sagetrac-dperkinson:
Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Replying to @tscrim:
Replying to @sagetrac-dperkinson:
Should I remove every instance of INPUT for which there is no input (None) and, separately, every instance of OUTPUT for which there is no output (None)? The documentation for developers at sagemath.org states that every function must have an INPUT and OUTPUT statement, and further that this "is not optional".
tries to put politics aside These add clutter to the docstring and are a very good exception to the rule. So yes, please remove them.
Just to be completely clear: suppose, for example, that I have a docstring with None listed under INPUT and integer listed under OUTPUT. Then I should remove the INPUT section, leaving the OUTPUT section, right?
Yes, that is correct.
At any rate, for this new version, with my local version of Sage, all tests passed for "sage -t", and the html and pdf documentation built without problems.
However there is currently a merge conflict with the latest beta. So you'll need to rebase it.
I am new to git, so I could use some guidance here. I have been working in a directory called git-trac-command. The output from "git branch" shows two branches:
masterandt/18618/sandpile_revisions, with an asterisk next to the latter. After my initial git push command, I have modified files in another, separate, copy of sage. When I done making and testing the revisions, I copy the relevant modified files (sandpile.py, examples.py, etc.) to git-trac-command/src/sage/sandpiles. I then run./sage -br,git add NEW FILES,git commit, andgit trac push.What is the sequence of commands I should enter to resolve the current conflict? Also, what should I have done originally to have avoided the conflict?
Thanks very much for your time and advice!
What you'll need to do is the following:
$ git fetch <remote_name> develop:develop $ git checkout t/18618/sandpile_revisions # If you aren't already in that branch $ git merge develop Do the rebasing $ git commit $ make # In the $SAGE_ROOT directory. This will take a *long* time $ git trac pushwhere
<remote_name>is likelyorigin(possiblytrac).Running "git merge develop" leads to the error:
Automatic merge failed; fix conflicts and then commit the result.
For rebuilding Sage with the
make, you might want to do these beforehand to help speed it up:$ make doc-clean $ export SAGE_NUM_THREADS=n $ export MAKE='make -jn' $ export SAGE_PARALLEL_SPKG_BUILDwhere
nis the number of processors on your computer. If it happens to fail during the doc-building part at the end, don't worry about it.Oops. Entered "make doc clean" by accident. Advice?
I just hit ctrl-C, then entered "make distclean" and proceeded as suggested above. Hope that works. Thanks again for your help.
Done. Hope that worked.
tscrim
commented
9 years ago Yes, that worked. Next is to fix the doctests as noted by the patchbot.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
fc12fc2 | Made the sandpiles thematic tutorial and sandpiles version 2.4 play well together. |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Description changed:
---
+++
@@ -51,7 +51,6 @@
* triangle_sandpile -- Not used much. Will still be able to import.
* aztec_sandpile -- Not used much. Will still be able to import.
* random_digraph -- Duplicates methods from graphs and digraphs, more or less.
-* random_DAG -- Not used much. Will still be able to import.
* random_tree -- Duplicates method from graphs and digraphs, more or less.
* glue_graphs -- Not used much. Will still be able to import.
* admissible_partitions -- Not used much. Will still be able to import.The function random_DAG is used elsewhere in sage (sage/graphs/graph_decompositions/vertex_separation.pyx). So I will hold off deprecating it. It might be a good idea to add random_DAG to the graph examples, e.g., graphs.random_DAG.
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago 7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
ce36ebe | Remove "INPUT: None" and "OUTPUT: None" in docstrings. |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
01df8d1 | Added SandpileDivisor.weierstrass_div method. |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Description changed:
---
+++
@@ -38,6 +38,7 @@
* rank -- the rank of the divisor
* simulate_threshold -- simulate closed sandpile Markov chain until threshold
* stabilize -- stabilize, if possible
+* weierstrass_div -- the Weierstrass divisor
* weierstrass_gap_seq -- the Weierstrass gap sequence for the given vertex
* weierstrass_pts -- all Weierstrass points (vertices) for the divisor
* weierstrass_rank_seq -- the rank sequence at a Weierstrass pointBranch pushed to git repo; I updated commit sha1. New commits:
543a7b1 | Lazy-importing sandpiles (from sandpiles.examples) |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago Branch pushed to git repo; I updated commit sha1. New commits:
1852ccc | Updated a few left-over old-style continuation markers. |
7ed8c4ca-6d56-4ae9-953a-41e42b4ed313
commented
9 years ago bc92013b-9220-40da-a45f-06c52942e68d
commented
9 years ago Reviewer: Qiaoyu Yang, Kaui Yu
dimpase
commented
9 years ago Please set up a git branch on trac to review, so that one can get changes in out git fetch/git merge.
dimpase
commented
9 years ago oops, sorry, it's OK, in fact.
dimpase
commented
9 years ago for some reason I have the following conflict when I try to merge the changes into Sage 6.8.beta8:
<<<<<<< HEAD
processed_g = {}
for k in g.keys():
temp = {}
for vertex in g[k]:
temp[vertex] = 1
processed_g[k] = temp
g = processed_g
elif isinstance(g, Graph):
processed_g = {}
for v in g.vertices():
edges = {}
for n in g.neighbors(v):
if (isinstance(g.edge_label(v,n), int)
and g.edge_label(v,n) >= 0):
edges[n] = g.edge_label(v,n)
else:
edges[n] = 1
processed_g[v] = edges
g = processed_g
elif isinstance(g, DiGraph):
processed_g = {}
for v in g.vertices():
edges = {}
for n in g.neighbors_out(v):
if (isinstance(g.edge_label(v,n), int)
and g.edge_label(v,n) >= 0):
edges[n] = g.edge_label(v,n)
else:
edges[n] = 1
processed_g[v] = edges
=======
processed_g = {i:dict(Counter(g[i])) for i in g}
>>>>>>> trac/u/dperkinson/sandpile_revisionsin src/sage/sandpiles/sandpile.py; i.e. you want to replace everything between <<<<< HEAD and ========
with the stuff after ======. Is this correct?
(It would be great if you do the rebase yourself, but if you don't know how, please say so).
Summary of sandpile.py changes from version 2.3 to 2.4 June 11, 2015
sandpilesto handle examples of Sandpiles in analogy withgraphs,simplicial_complexes, andpolytopes. In the process, we implemented a much faster way of producing the sandpile grid graph.NEW METHODS
Sandpile
SandpileConfig
SandpileDivisor
DEPRECATED
sandpilesMINOR CHANGES
sinkargument to Sandpile.init now defaults to the first vertex.__add__method for SandpileConfig and SandpileDivisor._repr_and thenamemethod).add_randommethods.Component: graph theory
Keywords: sandpile
Author: David Perkinson
Branch:
249b647Reviewer: Qiaoyu Yang, Kaui Yu
Issue created by migration from https://trac.sagemath.org/ticket/18618