Kelvin Li's profile - activity

One option is to pass the directory argument to the notebook function on every startup:

sage: notebook(directory="/path/to/sagenb/data")

On the command-line, this would be:

$ sage --notebook "directory=/path/to/sagenb/data"

Note that Sage will add a ".sagenb" extension (if not present) to the given directory name and use that as the actual notebook data directory. So the above example would actually use (or create, if non-existent) the directory "/path/to/sagenb/data.sagenb".

Note that this is different from the ".sage" directory, which is located at "~/.sage" by default. To change this, set the "DOT_SAGE" environment variable. If you set this variable without passing the notebook directory argument above, the notebook files will appear in "${DOT_SAGE}/sage_notebook.sagenb".

Try:

sage: notebook(require_login=False)

at a Sage prompt, or:

$ sage --notebook require_login=False

from a terminal. This is behavior documented in the docstring:

sage: notebook?

See the third item under the "EXAMPLES" section.

Dear all,

I have problems to call scipy.ndimage.binary_opening. Code, output and error messages in sage are as follows...

SAGE:

from numpy import *
import scipy.ndimage
import matplotlib.image
import matplotlib.pyplot
img=matplotlib.image.imread(DATA+'NbW-STEM.png')
type(img)
print "Image dtype: %s"%(img.dtype)
print "Image size: %6d"%(img.size)
print "Image shape: %3dx%3d"%(img.shape[0],img.shape[1])
print "Max value %1.2f at pixel %6d"%(img.max(),img.argmax())
print "Min value %1.2f at pixel %6d"%(img.min(),img.argmin())
print "Variance: %1.5f\nStandard deviation: %1.5f"%(img.var(),img.std())

OUTPUT:

Image dtype: float32
Image size: 261075
Image shape: 295x295
Max value 1.00 at pixel 226320
Min value 0.00 at pixel  17109
Variance: 0.02580
Standard deviation: 0.16062

SAGE:

BWatoms=img>0.62
BWatoms=scipy.ndimage.binary_opening(BWatoms,structure=ones((2,2)))

ERROR MESSAGE:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

  File "_sage_input_27.py", line 10, in <module>
    exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("QldhdG9tcz1pbWc+MC42MgpCV2F0b21zPXNjaXB5Lm5kaW1hZ2UuYmluYXJ5X29wZW5pbmcoQldhdG9tcyxzdHJ1Y3R1cmU9b25lcygoMiwyKSkp"),globals())+"\\n"); execfile(os.path.abspath("___code___.py"))

  File "", line 1, in <module>

  File "/tmp/tmpaXpo0G/___code___.py", line 4, in <module>
    exec compile(u'BWatoms=scipy.ndimage.binary_opening(BWatoms,structure=ones((_sage_const_2 ,_sage_const_2 )))

  File "", line 1, in <module>

  File "/home/ottom/Documents/sage_build/sage-4.6.1/local/lib/python2.6/site-packages/scipy/ndimage/morphology.py", line 646, in binary_opening
    origin)

  File "/home/ottom/Documents/sage_build/sage-4.6.1/local/lib/python2.6/site-packages/scipy/ndimage/morphology.py", line 394, in binary_erosion
    output, border_value, origin, 0, brute_force)

  File "/home/ottom/Documents/sage_build/sage-4.6.1/local/lib/python2.6/site-packages/scipy/ndimage/morphology.py", line 229, in _binary_erosion
    raise RuntimeError, 'structure rank must equal input rank'

RuntimeError: structure rank must equal input rank

This code was also tested on the sage-online server (alpha), which failed as well. The code worked fine with Enthought 6.2-2 (pylab-mode). Any suggestions are welcome.

All the best

Otto

Another option is the sage.plot.plot3d.tachyon.Tachyon interface (which is imported into the global namespace by default). Basically, you create a Tachyon scene instance, setup the contents of the scene, then render. Here is a slightly modified example from the Tachyon docstring:

sage: t = Tachyon(xres=512,yres=512, camera_center=(3,0.3,0), look_at=(0,0,0), updir=(0,0,1))
sage: t.light((4,3,2), 0.2, (1,1,1))
sage: t.texture('t0', ambient=0.1, diffuse=0.9, specular=0.5, opacity=1.0, color=(1.0,0,0))
sage: t.texture('t1', ambient=0.1, diffuse=0.9, specular=0.3, opacity=1.0, color=(0,1.0,0))
sage: t.texture('t2', ambient=0.2,diffuse=0.7, specular=0.5, opacity=0.7, color=(0,0,1.0))
sage: k=0
sage: for i in srange(-1,1,0.05):
...    k += 1
...    t.sphere((i,i^2-0.5,i^3), 0.1, 't%s'%(k%3))
...
sage: t.show()

The key here is the first line--the arguments camera_center, look_at, and updir, which are quite self-explanatory.

The only problem with this mechanism is that you must directly use Tachyon's methods to construct objects instead of Sage's usual plotting interfaces. (Graphics3d, plot3d, parametric_plot3d, etc.)

I have just managed to install ubuntu and then sage a few days ago. Therefore I am an absolute beginner.

When I was using sage, due to external power issues, the computer suddenly switched off and after that, I am unable to open sage notebook. Its showing an error.

----------------------------------------------------------------------
| Sage Version 4.6.2, Release Date: 2011-02-25                       |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: notebook()
The notebook files are stored in: sage_notebook.sagenb
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)

/home/bhavanishankar/.sage/<ipython console> in <module>()

/home/bhavanishankar/Applications/sage-4.6.2-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux/devel/sagenb/sagenb/notebook/notebook_object.pyc in __call__(self, *args, **kwds)
    215     """
    216     def __call__(self, *args, **kwds):
--> 217         return self.notebook(*args, **kwds)
    218 
    219     notebook = run_notebook.notebook_twisted

/home/bhavanishankar/Applications/sage-4.6.2-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux/devel/sagenb/sagenb/notebook/run_notebook.pyc in notebook_twisted(self, directory, port, interface, address, port_tries, secure, reset, accounts, require_login, server_pool, ulimit, timeout, open_viewer, sagetex_path, start_path, fork, quiet, subnets)
    403     if open_viewer:
    404         "Open viewer automatically isn't fully implemented.  You have to manually open your web browser to the above URL."
--> 405     return run(port, subnets)
    406 
    407 

/home/bhavanishankar/Applications/sage-4.6.2-linux-64bit-ubuntu_10.04.1_lts-x86_64-Linux/devel/sagenb/sagenb/notebook/run_notebook.pyc in run(port, subnets)
    366                 checkPID(pidfile)
    367             except SystemExit as e:
--> 368                 pid = int(open(pidfile).read())
    369                 if str(e).startswith('Another twistd server is running,'):
    370                     sys.exit("""\

ValueError: invalid literal for int() with base 10: ''

hmm. I thought AskSage used to automatically link Trac tickets...

From my very limited knowledge, I think the parts you are using are quite stable. Have fun porting!

I am not sure whether your overall goal is worth pursuing. From the surface, it looks like MyFunc is becoming a clone of sage.symbolic.expression.Expression. Additionally, Sage has a deprecation policy: old code must be supported for at least twelve months with deprecation warnings before Sage can break it. For most purposes, I suggest keeping Sage up to date and continually testing whether your code is using a deprecated interface.

Just for reference, your example can be done in Sage as follows:

Using a symbolic function:

sage: func(x) = function('func', x)
sage: func
x |--> func(x)
sage: func(3)
func(3)
sage: func.differentiate(x)
x |--> D[0](func)(x)
sage: func.differentiate(x)(3)
D[0](func)(3)

Using a concrete function:

sage: func(x) = sinh(x) * sqrt(x)
sage: func
x |--> sqrt(x)*sinh(x)
sage: func(3)
sqrt(3)*sinh(3)
sage: RR(func(3))
17.3514683581443
sage: func.differentiate(x)
x |--> sqrt(x)*cosh(x) + 1/2*sinh(x)/sqrt(x)
sage: RR(func.differentiate(x)(3))
20.3296134831414

As far as I know, the above functionality has been around for a while without any changes, so I would not be too concerned about the stability of Sage's interface.

Thank you everyone for your answers! I wish I could favorite all of them. :-) Since I am just starting out and don't have any mega-refactoring ideas (yet), I don't feel that basing off of the latest pre-release is a bother at all. If spending a little more of my time saves 10 other peoples' time, I think it is a good trade off. :-)

Maybe I will open a ticket to fix the Developer's Guide!

UPDATE: This is now #11420

I think the goal is to have patches based on the latest version possible, but not to make this a barrier to people working on patches. Here are some more expanded comments, based on my limited experience:

Personally, I would develop patches based on stable releases of Sage. Sometimes alphas or release candidates have some test failures that are known to the release manager and will have to be resolved before the final release; these could be potentially confusing as a developer if your patch is working on a related component, since it may be difficult to tell which failures are caused by known issues, and which are caused by bugs in your patch. But there may be good reasons in some circumstances to base your patch on a pre-release version (e.g. it fixes something relevant to your patch). In the end, I think this is up to the developer.

As for developing with older stable releases, patches have to apply to the latest stable release in order to be finally included in a new release. Sometimes patches simply apply without problems to later releases, and then nothing has to be done. But if they don't, these problems definitely have to be fixed. I think most patch authors would be happy to have you rebase their patches -- I certainly would!

However, for the purposes of actually solving the programming or mathematical problems relevant to the patch, one doesn't have to necessarily work with the latest release of Sage. Since rebasing is usually a straightforward task, the real value in a developer's work is in writing the initial patch. Get something that works correctly in some version of Sage, and then make sure it works with the latest stable release. Of course the greater the gap between the version you develop with and the latest version, the more difficult the rebasing will be, but working two or three point releases behind the latest probably isn't a big deal.

Update: As @kcrisman points out, having a patch apply successfully to the latest stable release is necessary---but not sufficient---for the patch to be included in Sage. The patch must also apply to the latest pre-release, and not conflict with other patches to be merged in the next (pre-)release. He is right (of course!) to point out that testing against the latest pre-release is the best way to be sure your patch is ready to be merged.

However, motivation to test on the latest pre-release should be tempered by the understanding that the review process will probably take longer than expected (several pre-releases, and maybe several stable releases), and (as far as I know) binaries for pre-release versions are only available for the machines at the University of Washington. A person without access to these would have to build each pre-release from source just to test the patch. This can be tedious and time consuming, depending on one's resources, so I wouldn't necessarily recommend it for everyone.

I would actually disagree (respectfully) with Niles, in a subtle way.

1. First, develop on whatever version of Sage you have. Don't waste time downloading or building if you have an idea!

2. But once you are at the point to think about committing it, then it is worth going to the sage-release Google group and finding the latest alpha or release candidate and making sure that your patch at least applies to that. It is not correct to say that each patch builds on the released version; each alpha is based on the released version, but there are still patches that need to be rebased on other patches. There is certainly no 'back-basing' as in the update to the question.

   This is annoying, I agree, but is worth doing. Many (most?) patches won't conflict, but it's worth knowing ahead of time; at least for me, rebasing is a long and tedious business.

3. Once one gets developing a fair amount, one will know where to look for "usual suspect" tickets or authors. Doing occasional searches in (say) symbolics will give you a sense of whether any symbolics patches are about to be merged, so that if you are going to do something in symbolics, you can be ready to base off of patch X with your patch Y.

I see that alphas and release candidates come out a lot faster than "released" versions of Sage. Should development patches be based on these pre-releases or on the current release? Furthermore, if I spot a patch on Trac that is based on an older version of Sage, should I go ahead and re-base the patch?

Notably, I have not found a clear answer in the Developer's Guide.

UPDATE: When producing the next stable, are the patches which are based on pre-releases "back-rebased" to the current stable? If so, is this a reason at all to favor basing on the current stable, rather than on the latest pre-release?

Unless someone comes up with a better answer, you might want to try building from source. I'm not sure what the problem is here.

From my understanding, Ask Sage is meant to be a Question & Answer site, whereas sage-support is discussion-oriented. The questions on Ask Sage should be of general interest to the Sage community. However, questions should be rather specific. Your original question was really a giant collection of questions.

This is a big topic that cannot be appropriately addressed in a single Q&A entry, or on a single Sage Wiki page. The key to getting a specific answer is to detail your real use case(s), rather than listing a bunch of hypothetical ones. The two Ask Sage questions (which you mentioned) illustrate this point.

If you are looking for general guidance about pros/cons of different hardware specifications and various computer setups, unfortunately Ask Sage is not the appropriate place for your questions. There are many other forums, websites, and even books on this broader subject.

Generally speaking, there will be performance overheads when running in virtual machines (VMware, VirtualBox, etc). Also, Sage currently does not work on Cygwin. The ideal, most efficient, and easiest-to-manage setup is to simply run Sage on Linux on bare hardware, without virtual machines or Windows or Cygwin.

what happened to the original question?!

There is a rather old sage-devel discussion talking about implicit symbolic variable creation (http://groups.google.com/group/sage-devel/browse_thread/thread/f1286e92d4d2ce83/bfc0b357f3635435). But I don't think this exists in Sage, currently.

Calling simplify is a hack:

sage: f(x) = ceil(sqrt(2*x) - 1/2)
sage: [0 .. f(3).simplify()]
[0, 1, 2]

Good observation about the bounds on n and k. Trying your computation caused my VM to run out of memory... but I only gave it 256 MB. :-)