Dan Drake's profile - activity

Well, my answer doesn't use Sage, but: your equation is equivalent to cosh(2x) == 1. The hyperbolic cosine function (cosh) has a global minimum at 0, so there's only one real solution: zero.

Other things that can help you figure this out: plot exp(2x) + exp(-2x) and see what it looks like. Show that the derivative is positive for all positive x, and negative for all negative x, and use that to prove that the function has a global minimum at 0, so that the original equation can only have one solution.

There's also "sage -f" (the "f" stands for "force"), which works just like "sage -i" but will install the spkg even if the same (or a later) version is already installed.

This is very useful when you're working on a spkg and making little changes, or if someone gives you a modified spkg with the same version.

Also, if you are not working with the notebook, you can use Python's subprocess module and any command-line sound player: just define the done() function as above as something like subprocess.call(['ogg123', 'path/to/file'])

That is a *fantastic* "I'm finished" sound. Way better than some lame old beep. :)

As a companion to the "what's broken" question, what features should we add here?

As a start, it would be nice if there was some mechanism for auto-linking trac ticket numbers. Other auto-link ideas:

• strings like "sage-support" auto-linked like this: sage-support
• auto-link for modules, like maybe sage.groups.perm_gps

As a start, check out the @parallel decorator, and the @fork decorator (which I think is not yet in Sage; it was briefly merged on the way to 4.5.2, and then pulled because of doctest failures); see #9501 and #9631.

This question seems a bit vague. Can you give an example in which xrange fails, but a preallocated list works? What's the error that using xrange gives?

I stopped developing for Sage largely because reviewers wanted me to use Mercurial queues.

I don't know about the reviewers you worked with, but when I'm reviewing tickets, I only care about what kind of patches are posted -- I don't care how they were created. A clean diff, ticket number in the commit message, proper username...that's what I want.

Is there a way to accomplish what Mercurial queues does without the learning curve?

Right now, probably not. But I did find that once I figured out queues, it was the most natural and easy way to work. Take a copy of Sage, qimport a patch, test it, pop and delete it -- and my copy of Sage is just like it started. Things get a bit more complicated with the sage-combinat stuff, since they have a huge queue and use guards and all that -- but you can ignore that stuff.

It sounds like much of your confusion would be cleared if you could sit down with someone and have them show you things -- or maybe a good chat on IRC with a shared screen session. Read the Mercurial book and ask questions. I think you can understand queues without too much trouble.

Before answering the question "What are some key points that the FAQ for this ask.sagemath.org site should make?", we need to know exactly what this site is for. Do we want questions about how to compute things with Sage or other software? Do we want questions about installing and basic usage of Sage? Do we want questions about design, improvement, bugfixes in Sage?

Having a well-defined focus will certainly improve the usefulness of this site. I would like to see the relationship between this and the mailing lists explained/decided.

We might also develop some guidelines about the questions that are asked. It seems like a question such as "Should we support 32-bit FreeBSD?" would not be ideal for this venue; a question such as "I have a bunch of data in format X, how do I load that into Sage, interpret it as Y, and then compute Z?" seems much better.