mvngu's profile - activity

Use the built-in Python command itertools.combinations:

sage: import itertools
sage: L = [1..5]; L
[1, 2, 3, 4, 5]
sage: for s in itertools.combinations(L, 3):
....:     print s
....:     
(1, 2, 3)
(1, 2, 4)
(1, 2, 5)
(1, 3, 4)
(1, 3, 5)
(1, 4, 5)
(2, 3, 4)
(2, 3, 5)
(2, 4, 5)
(3, 4, 5)

I sometimes use the trace() function in Sage for a quick debugging job.

I can't understand, why this is still broken because since a few months this problem is reported.

The relevant bug report is in this sage-support thread, which also lists the relevant bug tracking tickets. The long delay from when a bug is first reported to the time the bug is fixed depends on many factors. But the delay is often a result of finding someone willing to volunteer to fix the bug and another person to volunteer their time to review the bug fix. Fortunately, the relevant tickets (#9394 and #9834) have received positive reviews. This means that you can most likely expect the fix to be in Sage 4.6.

Maybe this might help:

sage: L = [[1,2,3,4], [3,5,6,7], [7,8,9,10], [1,2,3,4]]
sage: seen = []
sage: for e in L:
....:     if e in seen:
....:         continue
....:     seen.append(e)
....:     
sage: seen
[[1, 2, 3, 4], [3, 5, 6, 7], [7, 8, 9, 10]]

You can use a brute-force search by defining your own custom function. This option doesn't assume that elements in your list are unique. Your lists can contain duplicate elements if you want.

sage: def is_sublist(shortlist, longlist):
....:     for e in shortlist:
....:         if not (e in longlist):
....:             return False
....:     return True
....: 
sage: L = [2, 5, 23]
sage: P = primes_first_n(20); P
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71]
sage: is_sublist(L, P)
True
sage: L + [23]
[2, 5, 23, 23]
sage: is_sublist(L + [23], P)
True
sage: L.append(next_prime(P[-1])); L
[2, 5, 23, 73]
sage: is_sublist(L, P)
False
sage: is_sublist(L + [23], P)
False

Alternatively, you can use the built-in functions itertools.imap and all. The function itertools.imap is efficient when your lists are large, e.g. having hundreds or even hundreds of thousands of elements. This second option doesn't care if your lists have duplicate elements.

sage: import itertools
sage: L = [2, 5, 23]
sage: P = primes_first_n(20); P
[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71]
sage: L + [23]
[2, 5, 23, 23]
sage: all(itertools.imap(lambda x: x in P, L))
True
sage: all(itertools.imap(lambda x: x in P, L + [23]))
True
sage: L.append(next_prime(P[-1])); L
[2, 5, 23, 73]
sage: all(itertools.imap(lambda x: x in P, L))
False
sage: all(itertools.imap(lambda x: x in P, L + [23]))
False

Or, as Mitesh Patel said, you could use set. This third approach assumes that the elements in each list are unique, i.e. each list doesn't contain duplicate elements.

sage: L = [2, 5, 23]
sage: P = set(primes_first_n(20))
sage: set(L)
set([2, 5, 23])
sage: set(L).issubset(P)
True
sage: set(L + [23])
set([2, 5, 23])
sage: set(L + [23]).issubset(P)
True
sage: L.append(111); L
[2, 5, 23, 111]
sage: set(L)
set([2, 111, 5, 23])
sage: set(L + [111])
set([2, 111, 5, 23])
sage: set(L + [111]).issubset(P)
False
sage: set(L).issubset(P)
False

Now if one looks for a 'remove', he may also be interested in other list related commands like - 'append','clear','add',etc. Is there any scope of bring this modifications in help-files in near future?

That's a very excellent idea. Yes, work is being done to make the Sage standard documentation more helpful to both beginning and advanced users. In the case of suggestion for related commands, see for example ticket #8825. The Sage documentation is mostly written by users like you who know what sort of commands are related and which are useful for basic, intermediate and advanced usage. If you would like to contribute suggestions for related commands or suggestions to improve the documentation, we love to hear them.

Would it be possible to include the build logs for the "good" builds. Even when my builds are successful, there are generally a lot of scary looking messages in them. It would be nice to be able to compare them to a build that one of the developers was satisfied with.

Yes, it's possible. People who report build and test results need to be reminded of this. I have added a reminder in the build/test wiki page for Sage 4.5.3.

How about putting the date/time at the very beginning and very end of each log -- so it's easy to get an idea of the build time on various machines.

That's a good idea. I have implemented that in my custom build script. The relevant code block is:

before="$(date +%s)"
make
after="$(date +%s)"
elapsed_seconds="$(expr $after - $before)"
echo Elapsed time: $(date -d "1970-01-01 $elapsed_seconds sec" +%H:%M:%S) >> install.log

There are a number of Fedora 12 machines (skynet?) -- I'm curious if these are going to be upgraded when Fedora 12 reaches "end of life" (in November?)

We, even William Stein, don't have control over the SkyNet build farm, nor do we have control over the GCC Compile Farm. Both are not owned by the Sage project.

You could try this:

[mvngu@sage sage-4.5.3]$ echo $DOT_SAGE
/dev/shm/mvngu/dot_sage
[mvngu@sage sage-4.5.3]$ ./sage
----------------------------------------------------------------------
| Sage Version 4.5.3, Release Date: 2010-09-04                       |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: os.path.isdir(os.getenv("DOT_SAGE"))
True

Try making Veusz a contributed spkg first for your personal use. It is conceivable that over time, a large group of Sage users find Veusz useful for their own work. Then with a little more work, it's possible to migrate Veusz to the status of an optional spkg.

You can find Cython under the site-packages/ directory of the version of Python that is shipped with Sage. For example:

[mvngu@sage sage-4.5.3.alpha2]$ ls local/lib/python/site-packages/Cython
CodeWriter.py   Debugging.pyc  __init__.pyc  Shadow.pyc        TestUtils.py
CodeWriter.pyc  Distutils      Plex          StringIOTree.py   TestUtils.pyc
Compiler        Includes       Runtime       StringIOTree.pyc  Utils.py
Debugging.py    __init__.py    Shadow.py     Tests             Utils.pyc

You have three choices in how you can include Veusz in Sage: as a standard package, as an optional spkg, or as a contributed (formerly known as experimental) spkg. A contributed spkg doesn't need to be run through the rigorous testing and quality assurance that optional and standard spkg's go through. You assume all responsibility with respect to a contributed spkg: for testing that spkg, how well it integrates with Sage, etc. The Sage project takes no active role in maintaining a contributed spkg. It is up to you to maintain it.

An optional spkg needs to pass a number of hurdles before it can be accepted. But the greatest hurdles of all rest with standard spkg's. The Sage project hosts these three types of packages.

In your version of Sage, try to determine whether or not it is a source or binary distribution. What do you get if you do these? $ file cython-0.12.1.spkg $ du -sh cython-0.12.1.spkg In a source distribution, the size of the cython spkg should be few kilobytes.

In a source distribution of Sage, you also get the source of all standard packages in Sage. Standard packages reside under SAGE_ROOT/spkg/standard. You should be able to uncompress each spkg using tar and bunzip2, then hunt around an uncompressed spkg for the documentation of that upstream package. For example, here is a way to read the documentation of Cython:

[mvngu@sage mvngu]$ ls
dot_sage  sage-4.5.3.alpha2
[mvngu@sage mvngu]$ cd sage-4.5.3.alpha2/spkg/standard/
[mvngu@sage standard]$ tar -jxf cython-0.12.1.spkg 
[mvngu@sage standard]$ cd cython-0.12.1/src/Doc/
[mvngu@sage Doc]$ ls
About.html            FAQ.html    overview.html  sharing.html
extension_types.html  index.html  primes.c       special_methods.html

Once uncompressed, you could also read the source of the upstream package.

The contributor howto is required reading for any new contributor. You should at least be familiar with that howto.

You could try running the doctest with the verbose option:

sage -t -verbose devel/sage-trac/sage/combinat/sf/hall_littlewood.py 2>&1 | tee -a doctest.log

Then look through the log file to find where the doctest timed out.

You could install parallel Python using your Sage installation and then use functionalities of parallel Python to run some computation that exploits a multi-core system.

• search_*
• tutorial()

Is there an index

There is no such index of algorithms implemented in Sage.

or an easy way to search for this? An example of this is the Berlekamp-Zassenhaus algorithm for factorising polynomials over integers.

You could use the search functions search_def, search_doc, or search_src to search through the Sage source tree. When someone implements an algorithm or interfaces to an algorithm from a Sage package, the name of the algorithm should be mentioned in the docstring of the relevant module, class, method, or function. For the Berlekamp-Zassenhaus algorithm, I got this

sage: search_src("Berlekamp-Zassenhau")
rings/polynomial/polynomial_element.pyx:2656:        ## NTL uses the Berlekamp-Zassenhaus method with van Hoeij's improvements.

That should tell you where to start looking, specifically in the file sage/rings/polynomial/polynomial_element.pyx around line 2656.