[sage-devel] Re: edit_module patch updated
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote: See: http://sagetrac.org/sage_trac/ticket/768 I have updated the attached patch to be clean against 2.8.8.1. When I checked the edit() command in sage 2.8.8.1, I realized it was really broken -- It doesn't work if EDITOR is unset in the environment. The patch attached to the trac ticket is supposed to fix that. I'm generally happy with this patch, though I don't agree with removing the bg option. Perhaps you're removing that functionality because your particular workflow is more rigid than mine. For example, I use emacs quite a lot, both in a console (especially when I login to other machines), but also as a popup separate application. When I use emacs in console mode, putting the editor in the background is very frusting, and doesn't work at all. When I use emacs as a separate popup application, it is very very frustrating if the console session freezes, since often the reason I'm popping up the editor is to create some examples in the console and paste them into the docstring of a function. In both cases the command name is exactly the same emacs. So please change the patch back to have the bg option. This is a lot like black on white versus white on black. Most people exclusively use one or the other mode, and it's impossible to know which from the application's point of view.So applications have to support both and make it easy to switch between generating colors for each. I often switch between using emacs and vi, both in window and console mode, and between black on white and white on black, depending on my mood, eye strain, computing I'm logged into, etc. So it needs to be easy to support changing modes. The bg= option to edit is 3 lines of code and does just that; it allows one to very easily override automatic defaults on a per-use basis. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Bug in permgroup.py ?
Dear all, I think that there is a bug in the module permgroup.py, at line 1226, the method conjugacy_classes_subgroups calls PermutationGroupElement; I think it should be PermutationGroup. Best regards, Biel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: random polynomial generation
On Oct 24, 5:45 am, didier deshommes [EMAIL PROTECTED] wrote: 2007/10/23, Steffen [EMAIL PROTECTED]: Exactly, thats one of two points. The maximum degree in every variable is (maximum total degree of resulting polynomial) / (number of varialbes of the polynomial). Thus for example GF(10007) ['x,y,z'].random_element(5,9) will be limited in every variable to degree 5/3 = 1 !!!. This is not what the upper definition says. The second point is about the number of coefficients that are set to 0. This might a point to argue about, but if I create a random polynomial with a (maximum number of terms to generate) then I expect that the 0 occurs with the same probability and thus as often as every other element. Thats why I am not happy if 20% or more of the parameters are 0. I filed out a bug report about those 2 issues: 1) Degrees can severely restricted. 2) The polynomials returned can be too sparse I plan to post a patch addressing your concerns (I can especially see how 1) can be annoying). Random poly generation will most likely be slower, so for now I'm planning to keep the current behavior around, even if it is not the default. didier Thanks, I will wait for didiers patch. If I then have any additional requirements I will implement them via an optional flag or smth similar. Steffen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
Michael, You wrote: dance(10) computes fine on sage.math (in about 6 hours under gdb), I am running dance(11) to see if it finishes [I guess you would like the result ;)]. Yes, sure! So, any chance you are running the computation on a 32 bit box and/or run out of memory/have highly fragmented memory after a long uptime? There is a long uptime, but I saw in the system console a steady line on 80% memory usage. I have to wait for the valgrind run to finish (which will take a long, long time), to say something definite, but I will look into it some more. Below the output from bt Thanks! Jaap sage: time dance(10) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208297792 (LWP 3914)] 0x0a6c2a64 in ?? () (gdb) bt #0 0x0a6c2a64 in ?? () #1 0x08087aa2 in PyObject_RichCompare (v=0x8f94f44, w=0x8f94f44, op=2) at Objects/object.c:914 #2 0x080c3862 in PyEval_EvalFrameEx (f=0xa7bb864, throwflag=0) at Python/ceval.c:3980 #3 0x0810b4ed in gen_send_ex (gen=0xa70a3ec, arg=0x16, exc=0) at Objects/genobject.c:82 #4 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bd5e4, throwflag=0) at Python/ceval.c:2164 #5 0x0810b4ed in gen_send_ex (gen=0xa70a32c, arg=0x16, exc=0) at Objects/genobject.c:82 #6 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bd15c, throwflag=0) at Python/ceval.c:2164 #7 0x0810b4ed in gen_send_ex (gen=0xa70a72c, arg=0x16, exc=0) at Objects/genobject.c:82 #8 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bc4fc, throwflag=0) at Python/ceval.c:2164 #9 0x0810b4ed in gen_send_ex (gen=0xa70a70c, arg=0x16, exc=0) at Objects/genobject.c:82 #10 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bea2c, throwflag=0) at Python/ceval.c:2164 #11 0x0810b4ed in gen_send_ex (gen=0xa70a6ec, arg=0x16, exc=0) at Objects/genobject.c:82 #12 0x080c00cd in PyEval_EvalFrameEx (f=0xa7be134, throwflag=0) at Python/ceval.c:2164 #13 0x0810b4ed in gen_send_ex (gen=0xa70a68c, arg=0x16, exc=0) at Objects/genobject.c:82 #14 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bf77c, throwflag=0) at Python/ceval.c:2164 #15 0x0810b4ed in gen_send_ex (gen=0xa70a6cc, arg=0x16, exc=0) at Objects/genobject.c:82 #16 0x080c00cd in PyEval_EvalFrameEx (f=0xa7be434, throwflag=0) at Python/ceval.c:2164 #17 0x0810b4ed in gen_send_ex (gen=0xa70aa2c, arg=0x16, exc=0) at Objects/genobject.c:82 #18 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bb9dc, throwflag=0) at Python/ceval.c:2164 #19 0x0810b4ed in gen_send_ex (gen=0xa70a66c, arg=0x16, exc=0) at Objects/genobject.c:82 #20 0x0805a213 in PyIter_Next (iter=0xa70a66c) at Objects/abstract.c:2375 #21 0x0121c5bd in __pyx_f_py_7matrix2_6Matrix_permanent (__pyx_v_self=0x9c37194, unused=0x0) at sage/matrix/matrix2.c:1633 #22 0x0805a277 in PyObject_Call (func=0x92c1a54, arg=0xb7f6d02c, kw=0x0) at Objects/abstract.c:1860 ---Type return to continue, or q return to quit--- #23 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xa71282c, arg=0xb7f6d02c, kw=0x0) at Python/ceval.c:3433 #24 0x0805a490 in PyObject_CallObject (o=0xa71282c, a=0x0) at Objects/abstract.c:1851 #25 0x0121b491 in __pyx_f_py_7matrix2_6Matrix_permanental_minor (__pyx_v_self=0x9c37fa4, __pyx_arg_k=0x8f94ee4) at sage/matrix/matrix2.c:2074 #26 0x0805a277 in PyObject_Call (func=0x92c1a54, arg=0x9186b4c, kw=0x0) at Objects/abstract.c:1860 #27 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xa70ab2c, arg=0x9186b4c, kw=0x0) at Python/ceval.c:3433 #28 0x0805a490 in PyObject_CallObject (o=0xa70ab2c, a=0x9186b4c) at Objects/abstract.c:1851 #29 0x01212462 in __pyx_f_py_7matrix2_6Matrix_rook_vector (__pyx_v_self=0x9c37fa4, __pyx_args=0xb7f6d02c, __pyx_kwds=0x0) at sage/matrix/matrix2.c:2399 #30 0x080c539c in PyEval_EvalFrameEx (f=0x9c58bf4, throwflag=0) at Python/ceval.c:3564 #31 0x080c57c5 in PyEval_EvalFrameEx (f=0x9c662b4, throwflag=0) at Python/ceval.c:3650 #32 0x080c65d5 in PyEval_EvalCodeEx (co=0x9c37068, globals=0xa7048ac, locals=0xa7048ac, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831 #33 0x080c6647 in PyEval_EvalCode (co=0x9c37068, globals=0xa7048ac, locals=0xa7048ac) at Python/ceval.c:494 #34 0x080bdc01 in builtin_eval (self=0x0, args=0xa70886c) at Python/bltinmodule.c:571 #35 0x080c539c in PyEval_EvalFrameEx (f=0x9ba3cbc, throwflag=0) at Python/ceval.c:3564 #36 0x080c65d5 in PyEval_EvalCodeEx (co=0x91c8338, globals=0x91bd1c4, locals=0x0, args=0x9c5af7c, argcount=2, kws=0x9c5af84, kwcount=0, defs=0x91dc6d8, defcount=1, closure=0x0) at Python/ceval.c:2831 #37 0x080c4a89 in PyEval_EvalFrameEx (f=0x9c5ae2c, throwflag=0) at Python/ceval.c:3660 #38 0x080c57c5 in PyEval_EvalFrameEx (f=0x9b8a354, throwflag=0) at Python/ceval.c:3650 #39 0x080c65d5 in PyEval_EvalCodeEx (co=0x9ae78d8, globals=0xa7048ac, locals=0xa7048ac, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2831 #40 0x080c5852 in PyEval_EvalFrameEx (f=0x9c5a61c, throwflag=0) at Python/ceval.c:494 ---Type return to continue,
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 24, 12:31 pm, Jaap Spies [EMAIL PROTECTED] wrote: Michael, Hello Jaap, You wrote: dance(10) computes fine on sage.math (in about 6 hours under gdb), I am running dance(11) to see if it finishes [I guess you would like the result ;)]. Yes, sure! Ok, should it finish I will send you the output. So, any chance you are running the computation on a 32 bit box and/or run out of memory/have highly fragmented memory after a long uptime? There is a long uptime, but I saw in the system console a steady line on 80% memory usage. Ok. I have to wait for the valgrind run to finish (which will take a long, long time), to say something definite, but I will look into it some more. Below the output from bt Thanks. Thanks! Jaap sage: time dance(10) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208297792 (LWP 3914)] 0x0a6c2a64 in ?? () (gdb) bt #0 0x0a6c2a64 in ?? () #1 0x08087aa2 in PyObject_RichCompare (v=0x8f94f44, w=0x8f94f44, op=2) at Objects/object.c:914 #2 0x080c3862 in PyEval_EvalFrameEx (f=0xa7bb864, throwflag=0) at Python/ceval.c:3980 #3 0x0810b4ed in gen_send_ex (gen=0xa70a3ec, arg=0x16, exc=0) at Objects/genobject.c:82 #4 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bd5e4, throwflag=0) at Python/ceval.c:2164 #5 0x0810b4ed in gen_send_ex (gen=0xa70a32c, arg=0x16, exc=0) at Objects/genobject.c:82 #6 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bd15c, throwflag=0) at Python/ceval.c:2164 #7 0x0810b4ed in gen_send_ex (gen=0xa70a72c, arg=0x16, exc=0) at Objects/genobject.c:82 #8 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bc4fc, throwflag=0) at Python/ceval.c:2164 #9 0x0810b4ed in gen_send_ex (gen=0xa70a70c, arg=0x16, exc=0) at Objects/genobject.c:82 #10 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bea2c, throwflag=0) at Python/ceval.c:2164 #11 0x0810b4ed in gen_send_ex (gen=0xa70a6ec, arg=0x16, exc=0) at Objects/genobject.c:82 #12 0x080c00cd in PyEval_EvalFrameEx (f=0xa7be134, throwflag=0) at Python/ceval.c:2164 #13 0x0810b4ed in gen_send_ex (gen=0xa70a68c, arg=0x16, exc=0) at Objects/genobject.c:82 #14 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bf77c, throwflag=0) at Python/ceval.c:2164 #15 0x0810b4ed in gen_send_ex (gen=0xa70a6cc, arg=0x16, exc=0) at Objects/genobject.c:82 #16 0x080c00cd in PyEval_EvalFrameEx (f=0xa7be434, throwflag=0) at Python/ceval.c:2164 #17 0x0810b4ed in gen_send_ex (gen=0xa70aa2c, arg=0x16, exc=0) at Objects/genobject.c:82 #18 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bb9dc, throwflag=0) at Python/ceval.c:2164 #19 0x0810b4ed in gen_send_ex (gen=0xa70a66c, arg=0x16, exc=0) at Objects/genobject.c:82 #20 0x0805a213 in PyIter_Next (iter=0xa70a66c) at Objects/abstract.c:2375 #21 0x0121c5bd in __pyx_f_py_7matrix2_6Matrix_permanent (__pyx_v_self=0x9c37194, unused=0x0) at sage/matrix/matrix2.c:1633 The above corresponds to the following lines in matrix2.pyx:279-281: tmp = [] for cols in lst: tmp.append(self.prod_of_row_sums(cols)) The crash itself happens when the tmp.append() fails. That indicates a problem with python's memory management and not an issue in the Sage code. I would expect python to throw some kind of allocation error, but since python uses pymalloc it usually asks for a large amount of memory to parcel out smaller chunks for the requests it receives. That could explain why despite having consumed roughly 80% of memory available the allocation fails. The other 20% might also be taken up to a large extent by the kernel and user space, so that makes a situation where you encounter a no more memory situation very likely. The matrix code in Sage does throw a RuntimeError when it fails to allocate memory, so I think it is off the hook for now. Because you run at about 80% memory consumption and have a large uptime I would suggest to do a reboot and see if the computation still fails; hopefully your heap fragmentation problem is gone due to the reboot and the computation will succeed. Depending on the version of Sage you last tried this with the memory footprint of Sage might have grown in relative terms so that the computation no longer succeeds with the amount of RAM you have, so another possibility would be to increase the amount of swap you have in that box. Adding more physical RAM will probably makes the problem go away, too. If anything pops up from the still running debug sessions I will let you know. Cheers, Michael #22 0x0805a277 in PyObject_Call (func=0x92c1a54, arg=0xb7f6d02c, kw=0x0) at Objects/abstract.c:1860 ---Type return to continue, or q return to quit--- #23 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xa71282c, arg=0xb7f6d02c, kw=0x0) at Python/ceval.c:3433 #24 0x0805a490 in PyObject_CallObject (o=0xa71282c, a=0x0) at Objects/abstract.c:1851 #25 0x0121b491 in __pyx_f_py_7matrix2_6Matrix_permanental_minor (__pyx_v_self=0x9c37fa4, __pyx_arg_k=0x8f94ee4) at
[sage-devel] Re: Bug in permgroup.py ?
Thank you for reporting this bug. This is now http://sagetrac.org/sage_trac/ticket/981 I'll try to work on it later today. On 10/24/07, Biel [EMAIL PROTECTED] wrote: Dear all, I think that there is a bug in the module permgroup.py, at line 1226, the method conjugacy_classes_subgroups calls PermutationGroupElement; I think it should be PermutationGroup. Best regards, Biel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
mabshoff wrote: #20 0x0805a213 in PyIter_Next (iter=0xa70a66c) at Objects/abstract.c:2375 #21 0x0121c5bd in __pyx_f_py_7matrix2_6Matrix_permanent (__pyx_v_self=0x9c37194, unused=0x0) at sage/matrix/matrix2.c:1633 The above corresponds to the following lines in matrix2.pyx:279-281: tmp = [] for cols in lst: tmp.append(self.prod_of_row_sums(cols)) The crash itself happens when the tmp.append() fails. That indicates a problem with python's memory management and not an issue in the Sage code. I would expect python to throw some kind of allocation error, but since python uses pymalloc it usually asks for a large amount of memory to parcel out smaller chunks for the requests it receives. That could explain why despite having consumed roughly 80% of memory available the allocation fails. The other 20% might also be taken up to a large extent by the kernel and user space, so that makes a situation where you encounter a no more memory situation very likely. The matrix code in Sage does throw a RuntimeError when it fails to allocate memory, so I think it is off the hook for now. Because you run at about 80% memory consumption and have a large uptime I would suggest to do a reboot and see if the computation still fails; hopefully your heap fragmentation problem is gone due to the reboot and the computation will succeed. Depending on the version of Sage you last tried this with the memory footprint of Sage might have grown in relative terms so that the computation no longer succeeds with the amount of RAM you have, so another possibility would be to increase the amount of swap you have in that box. Adding more physical RAM will probably makes the problem go away, too. I rebooted with no succes. Same error using 50-60% of 1 GB memory. Swap space is 5 GB. Jaap If anything pops up from the still running debug sessions I will let you know. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote:
The above corresponds to the following lines in matrix2.pyx:279-281:
tmp = []
for cols in lst:
tmp.append(self.prod_of_row_sums(cols))
The crash itself happens when the tmp.append() fails. That indicates a
It would perhaps be worth changing the code to
some_large_integer = 3**(10**5)
tmp = [some_large_integer]*len(lst)
for i in xrange(len(lst)):
tmp[i] = self.prod_of_row_sums(cols[i])
and see what happens. I mean, maybe the problem is in
prod_of_row_sums instead of append?
We really need to replicate this on another 32-bit machine.
By the way, could you remind me where dance is defined?
sage: search_src('dance')
[nothing]
sage:
problem with python's memory management and not an issue in the Sage
code. I would expect python to throw some kind of allocation error,
but since python uses pymalloc it usually asks for a large amount of
memory to parcel out smaller chunks for the requests it receives. That
could explain why despite having consumed roughly 80% of memory
available the allocation fails. The other 20% might also be taken up
to a large extent by the kernel and user space, so that makes a
situation where you encounter a no more memory situation very
likely. The matrix code in Sage does throw a RuntimeError when it
fails to allocate memory, so I think it is off the hook for now.
Because you run at about 80% memory consumption and have a large
uptime I would suggest to do a reboot and see if the computation still
fails; hopefully your heap fragmentation problem is gone due to the
reboot and the computation will succeed. Depending on the version of
Sage you last tried this with the memory footprint of Sage might have
grown in relative terms so that the computation no longer succeeds
with the amount of RAM you have, so another possibility would be to
increase the amount of swap you have in that box. Adding more physical
RAM will probably makes the problem go away, too.
I rebooted with no succes. Same error using 50-60% of 1 GB memory.
Swap space is 5 GB.
Jaap
If anything pops up from the still running debug sessions I will let
you know.
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: edit_module patch updated
OK, so this is caused by my lack of knowledge of how emacs operates.
Really, we are talking about two editors here, one a tty-application
and the other an X-windows application. They happen to be called by
the same command invocation, so there must be something in the
environment that decides which gets run (or at least in which mode it
gets run). Wouldn't it be nicer if sage would look at the environment
and predict the behaviour of emacs? Does emacs decide what to do based
on the DISPLAY variable? Does emacs always do that? How about people
that have an older, non-X-windows aware emacs?
I understand that the bg= hack is a quick way of getting the
configurability you want, but frankly, I would find it hard to explain
the existence of that option independent of the very particular usage
scenario you describe.
Jf we want sage to pop up the appropriate editor, the user should
not be required to give an extra option like that. In the model I
proposed (which clearly is inconvenient to you, so we need to see how
to wrap this), the solution would be to put into your init.sage
(basically following a suggestion Justin made):
if os.environ.haskey('DISPLAY'):
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
')
else:
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
So, if you're sure that this does for emacs what you want, we could
wrap this into the set_editor command instead of the bg= option.
Then the appropriate magic gets executed if either 'EDITOR=emacs' or
if set_editor('emacs'), and currently even if edit(..,
editor='emacs').
Guessing a user's configuration and preferences will stay hackish
guesswork. I'm happy to put some guesses into set_editor. Ultimately,
however, people should just put personal configuration stuff into
init.sage. (either that or every user patches sage.misc.edit_module
until it is an encyclopedia of editor invocation sequences)
Another solution would be two possible editor templates: emacs-fg
and emacs-bg.
On Oct 23, 11:03 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote:
See:
http://sagetrac.org/sage_trac/ticket/768
I have updated the attached patch to be clean against 2.8.8.1. When I
checked the edit() command in sage 2.8.8.1, I realized it was really
broken -- It doesn't work if EDITOR is unset in the environment. The
patch attached to the trac ticket is supposed to fix that.
I'm generally happy with this patch, though I don't agree with removing
the bg option. Perhaps you're removing that functionality because
your particular workflow is more rigid than mine. For example, I use
emacs quite a lot, both in a console (especially when I login to other
machines), but also as a popup separate application. When I use emacs
in console mode, putting the editor in the background is very frusting,
and doesn't work at all. When I use emacs as a separate popup application, it
is very very frustrating if the console session freezes, since often the
reason
I'm popping up the editor is to create some examples in the console and
paste them into the docstring of a function. In both cases the command
name is exactly the same emacs.
So please change the patch back to have the bg option.
This is a lot like black on white versus white on black. Most people
exclusively
use one or the other mode, and it's impossible to know which from the
application's point of view.So applications have to support both and make
it easy to switch between generating colors for each. I often switch between
using emacs and vi, both in window and console mode, and between black
on white and white on black, depending on my mood, eye strain, computing
I'm logged into, etc. So it needs to be easy to support changing modes.
The bg= option to edit is 3 lines of code and does just that; it allows one to
very easily override automatic defaults on a per-use basis.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Bug in permgroup.py ?
I posted a link to a patch at http://sagetrac.org/sage_trac/ticket/981 On 10/24/07, Biel [EMAIL PROTECTED] wrote: Dear all, I think that there is a bug in the module permgroup.py, at line 1226, the method conjugacy_classes_subgroups calls PermutationGroupElement; I think it should be PermutationGroup. Best regards, Biel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: edit_module patch updated
On 10/24/07, Nils Bruin [EMAIL PROTECTED] wrote:
I understand that the bg= hack is a quick way of getting the
configurability you want, but frankly, I would find it hard to explain
the existence of that option independent of the very particular usage
scenario you describe.
To you, since you don't use it, it is a very particular usage scenario.
To me it is the normal very common (for me at least) usage scenario.
Jf we want sage to pop up the appropriate editor, the user should
not be required to give an extra option like that.
I certainly don't propose that they have to give the extra option.
It is optional. There should still be the default proposal you implemented.
edit(.., bg=None)
does the default
edit(..., bg=True)
does the background = True mode,
edit(..., bg = False)
does the background = False mode.
In the model I
proposed (which clearly is inconvenient to you, so we need to see how
to wrap this), the solution would be to put into your init.sage
(basically following a suggestion Justin made):
if os.environ.haskey('DISPLAY'):
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
')
else:
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
So, if you're sure that this does for emacs what you want, we could
I'm sure that does *not* do what I want. When I login to my laptop
under Linux the DISPLAY environment variable is not even set, yet
emacs pops up in a window.When I login remotely to another machine
(or my laptop, from OS X), it can easily be that DISPLAY is not set.
I also have a similar issue with my office desktop, which I use both
remotely and when I'm actually in my office at the console.
wrap this into the set_editor command instead of the bg= option.
Then the appropriate magic gets executed if either 'EDITOR=emacs' or
if set_editor('emacs'), and currently even if edit(..,
editor='emacs').
Guessing a user's configuration and preferences will stay hackish
guesswork. I'm happy to put some guesses into set_editor. Ultimately,
however, people should just put personal configuration stuff into
init.sage. (either that or every user patches sage.misc.edit_module
^
That doesn't work for me, since in my usage the init.sage is the same
in both cases, and I often switch between both usage scenarios.
Another solution would be two possible editor templates: emacs-fg
and emacs-bg.
I just want to type
sage: edit(name)
and have it work. If it happens to be that a window pops up, and will
say to myself -- gee, I need this to be backgrounded so I can type
command still, and I'll instead do
sage; edit(name, bg=True).
Anyway, I can't see the problem with having that option, and your only
argument against it is that it is difficult to explain in the documentation.
-- William
On Oct 23, 11:03 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote:
See:
http://sagetrac.org/sage_trac/ticket/768
I have updated the attached patch to be clean against 2.8.8.1. When I
checked the edit() command in sage 2.8.8.1, I realized it was really
broken -- It doesn't work if EDITOR is unset in the environment. The
patch attached to the trac ticket is supposed to fix that.
I'm generally happy with this patch, though I don't agree with removing
the bg option. Perhaps you're removing that functionality because
your particular workflow is more rigid than mine. For example, I use
emacs quite a lot, both in a console (especially when I login to other
machines), but also as a popup separate application. When I use emacs
in console mode, putting the editor in the background is very frusting,
and doesn't work at all. When I use emacs as a separate popup application,
it
is very very frustrating if the console session freezes, since often the
reason
I'm popping up the editor is to create some examples in the console and
paste them into the docstring of a function. In both cases the command
name is exactly the same emacs.
So please change the patch back to have the bg option.
This is a lot like black on white versus white on black. Most people
exclusively
use one or the other mode, and it's impossible to know which from the
application's point of view.So applications have to support both and
make
it easy to switch between generating colors for each. I often switch
between
using emacs and vi, both in window and console mode, and between black
on white and white on black, depending on my mood, eye strain, computing
I'm logged into, etc. So it needs to be easy to support changing modes.
The bg= option to edit is 3 lines of code and does just that; it allows one
to
very easily override automatic defaults on a per-use basis.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
mabshoff wrote:
On Oct 24, 6:27 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote:
I am on that, I got a 32 bit build of 2.8.9.alpha0.
By the way, could you remind me where dance is defined?
sage: search_src('dance')
[nothing]
sage:
It is not in matrix2.pyx, It is on the bottom of my first message and heer
below.
It uses some functions/methods present in matrix2.pyx:
rook_vector, permanental_minor, prod_of_row_sums, permanent.
increase the amount of swap you have in that box. Adding more physical
RAM will probably makes the problem go away, too.
I rebooted with no succes. Same error using 50-60% of 1 GB memory.
Swap space is 5 GB.
Jaap
Ok, I will investigate on a 32 bit box then. Could you give us
distribution/gcc and so on please? It might be related to specific
compilers.
Linux paix 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386
GNU/Linux
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
Jaap
---
##
# Copyright (C) 2006 Jaap Spies, [EMAIL PROTECTED]
#
# Distributed under the terms of the GNU General Public License (GPL):
#
# http://www.gnu.org/licenses/
##
Usage from sage
sage: attach 'dancing.sage'
sage: dance(4)
h^4 - 2*h^3 + 9*h^2 - 8*h + 6
# use variable 'h' in the polynomial ring over the rationals
h = QQ['h'].gen()
def dance(m):
Generates the polynomial solutions of the Dancing School Problem
Based on a modification of theorem 7.2.1 from Brualdi and Ryser,
Combinatorial Matrix Theory.
See NAW 5/7 nr. 4 december 2006 p. 285
INPUT: integer m
OUTPUT: polynomial in 'h'
EXAMPLE:
sage: dance(4)
h^4 - 2*h^3 + 9*h^2 - 8*h + 6
AUTHOR: Jaap Spies (2006)
n = 2*m-2
M = MatrixSpace(ZZ, m, n)
A = M([0 for i in range(m*n)])
for i in range(m):
for j in range(n):
if i j or j i + n - m:
A[i,j] = 1
rv = A.rook_vector()
# print rv
s = sum([(-1)^k*rv[k]*falling_factorial(m+h-k, m-k) for k in range(m+1)])
print s
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.8
On 10/24/07, mabshoff [EMAIL PROTECTED] wrote: On my 2x3.0GHz Quad Xeon Mac, I got the following: Without the above, the build took ~71 minutes. With the above, both for -j6 and -j4, the build took ~54 minutes. I think we should look into parallel builds via SCons for the sage.spkg, because that one eats quite a lot of time. It would be very nice if sage-*.spkg, i.e., sage -ba could be done in parallel. The build is *entirely managed* by Python's distutils. Thus instead of thinking about SCons, you need to ask whether Python distutils or some drop-in-replacement for it allows for parallel builds. Incidentally, I think it is potentially starting to be a serious problem that so much code gets moved from .py to .pyx. Maybe sometimes this is done when it isn't really necessary, just to get a couple of functions to be pyx'd. If you want to experiment with having Sage actually build multiple packages at the same time, which could vastly speed things up since even the ./configure's will run in parallel, you can try the following. WARNING: I've tried this once a while ago and it did *not* work for me, and I didn't have time to debug all the problems, so it isn't supported -- you will have to fix things. That's why I've cc'd this message to sage-devel. 0. Start with a fresh Sage tarball. 1. Open the file SAGE_ROOT/spkg/install 2. Find the line time make -f standard/deps $1 and change it to time make -j 4 -f standard/deps $1 3. cd to SAGE_ROOT and type make. Watch lots of things happen at once, then something eventually go wrong, probably because of subtle dependencies that are appropriately described in SAGE_ROOT/standard/deps. I think theory, by modifying the makefile in SAGE_ROOT/standard/deps appropriately, one could make the above work. This would be very useful to a lot of people, actually, since it would speed up building sage on smp machines. I think the deps aren't complete, so that a single make process works, but once you do a -j4 things go wrong. We might want to be less ambitious and start with -j2. Sure. It would be very good to fix things so the deps are complete though. I mean, I *think* they are complete, and no of no case where they aren't, but evidently they aren't if the above make doesn't work. william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 24, 6:52 pm, Jaap Spies [EMAIL PROTECTED] wrote:
mabshoff wrote:
On Oct 24, 6:27 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote:
I am on that, I got a 32 bit build of 2.8.9.alpha0.
By the way, could you remind me where dance is defined?
sage: search_src('dance')
[nothing]
sage:
It is not in matrix2.pyx, It is on the bottom of my first message and heer
below.
It uses some functions/methods present in matrix2.pyx:
rook_vector, permanental_minor, prod_of_row_sums, permanent.
Yep, you are obviously right, sorry for the confusion.
increase the amount of swap you have in that box. Adding more physical
RAM will probably makes the problem go away, too.
I rebooted with no succes. Same error using 50-60% of 1 GB memory.
Swap space is 5 GB.
Jaap
Ok, I will investigate on a 32 bit box then. Could you give us
distribution/gcc and so on please? It might be related to specific
compilers.
Linux paix 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386
GNU/Linux
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
Great, I have
Linux localhost.localdomain 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 17:26:33
EDT 2007 i686 i686 i386 GNU/Linux
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
so I will apply the latest FC7 updates.
Jaap
Cheers,
Michael
---
##
# Copyright (C) 2006 Jaap Spies, [EMAIL PROTECTED]
#
# Distributed under the terms of the GNU General Public License (GPL):
#
# http://www.gnu.org/licenses/
##
Usage from sage
sage: attach 'dancing.sage'
sage: dance(4)
h^4 - 2*h^3 + 9*h^2 - 8*h + 6
# use variable 'h' in the polynomial ring over the rationals
h = QQ['h'].gen()
def dance(m):
Generates the polynomial solutions of the Dancing School Problem
Based on a modification of theorem 7.2.1 from Brualdi and Ryser,
Combinatorial Matrix Theory.
See NAW 5/7 nr. 4 december 2006 p. 285
INPUT: integer m
OUTPUT: polynomial in 'h'
EXAMPLE:
sage: dance(4)
h^4 - 2*h^3 + 9*h^2 - 8*h + 6
AUTHOR: Jaap Spies (2006)
n = 2*m-2
M = MatrixSpace(ZZ, m, n)
A = M([0 for i in range(m*n)])
for i in range(m):
for j in range(n):
if i j or j i + n - m:
A[i,j] = 1
rv = A.rook_vector()
# print rv
s = sum([(-1)^k*rv[k]*falling_factorial(m+h-k, m-k) for k in
range(m+1)])
print s
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote: It is not in matrix2.pyx, It is on the bottom of my first message and here below. It uses some functions/methods present in matrix2.pyx: rook_vector, permanental_minor, prod_of_row_sums, permanent. I think you should submit a patch to Sage so that this code gets included standard. It could go somewhere in the combinat directory. Is it a sloane sequences? It shouldn't be in sage.all by default, but should be easy for users to import. increase the amount of swap you have in that box. Adding more physical RAM will probably makes the problem go away, too. I rebooted with no succes. Same error using 50-60% of 1 GB memory. Swap space is 5 GB. Jaap Ok, I will investigate on a 32 bit box then. Could you give us distribution/gcc and so on please? It might be related to specific compilers. Linux paix 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386 GNU/Linux gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) Jaap --- ## # Copyright (C) 2006 Jaap Spies, [EMAIL PROTECTED] # # Distributed under the terms of the GNU General Public License (GPL): # # http://www.gnu.org/licenses/ ## Usage from sage sage: attach 'dancing.sage' sage: dance(4) h^4 - 2*h^3 + 9*h^2 - 8*h + 6 # use variable 'h' in the polynomial ring over the rationals h = QQ['h'].gen() def dance(m): Generates the polynomial solutions of the Dancing School Problem Based on a modification of theorem 7.2.1 from Brualdi and Ryser, Combinatorial Matrix Theory. See NAW 5/7 nr. 4 december 2006 p. 285 INPUT: integer m OUTPUT: polynomial in 'h' EXAMPLE: sage: dance(4) h^4 - 2*h^3 + 9*h^2 - 8*h + 6 AUTHOR: Jaap Spies (2006) n = 2*m-2 M = MatrixSpace(ZZ, m, n) A = M([0 for i in range(m*n)]) for i in range(m): for j in range(n): if i j or j i + n - m: A[i,j] = 1 rv = A.rook_vector() # print rv s = sum([(-1)^k*rv[k]*falling_factorial(m+h-k, m-k) for k in range(m+1)]) print s -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: edit_module patch updated
OK. Sounds like SAGE will *NOT* be able to read your mind, then. bg
option added back in
(can both be used to strip from and to add in to the default).
Ticket reopened.
Thank you for explaining why you need the bg option and why the
obvious workarounds don't work in your case.
The problem with the options in general is that they clutter the
interface and should be limited to the minimum. Their perceived need
often points to a design flaw. In this case it does too: we are
failing to predict what emacs is going to do. However, as you
describe, it seems too difficult to do so, so I'm happy putting it
back.
On Oct 24, 9:50 am, William Stein [EMAIL PROTECTED] wrote:
On 10/24/07, Nils Bruin [EMAIL PROTECTED] wrote:
I understand that the bg= hack is a quick way of getting the
configurability you want, but frankly, I would find it hard to explain
the existence of that option independent of the very particular usage
scenario you describe.
To you, since you don't use it, it is a very particular usage scenario.
To me it is the normal very common (for me at least) usage scenario.
Jf we want sage to pop up the appropriate editor, the user should
not be required to give an extra option like that.
I certainly don't propose that they have to give the extra option.
It is optional. There should still be the default proposal you implemented.
edit(.., bg=None)
does the default
edit(..., bg=True)
does the background = True mode,
edit(..., bg = False)
does the background = False mode.
In the model I
proposed (which clearly is inconvenient to you, so we need to see how
to wrap this), the solution would be to put into your init.sage
(basically following a suggestion Justin made):
if os.environ.haskey('DISPLAY'):
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
')
else:
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
So, if you're sure that this does for emacs what you want, we could
I'm sure that does *not* do what I want. When I login to my laptop
under Linux the DISPLAY environment variable is not even set, yet
emacs pops up in a window.When I login remotely to another machine
(or my laptop, from OS X), it can easily be that DISPLAY is not set.
I also have a similar issue with my office desktop, which I use both
remotely and when I'm actually in my office at the console.
wrap this into the set_editor command instead of the bg= option.
Then the appropriate magic gets executed if either 'EDITOR=emacs' or
if set_editor('emacs'), and currently even if edit(..,
editor='emacs').
Guessing a user's configuration and preferences will stay hackish
guesswork. I'm happy to put some guesses into set_editor. Ultimately,
however, people should just put personal configuration stuff into
init.sage. (either that or every user patches sage.misc.edit_module
^
That doesn't work for me, since in my usage the init.sage is the same
in both cases, and I often switch between both usage scenarios.
Another solution would be two possible editor templates: emacs-fg
and emacs-bg.
I just want to type
sage: edit(name)
and have it work. If it happens to be that a window pops up, and will
say to myself -- gee, I need this to be backgrounded so I can type
command still, and I'll instead do
sage; edit(name, bg=True).
Anyway, I can't see the problem with having that option, and your only
argument against it is that it is difficult to explain in the documentation.
-- William
On Oct 23, 11:03 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote:
See:
http://sagetrac.org/sage_trac/ticket/768
I have updated the attached patch to be clean against 2.8.8.1. When I
checked the edit() command in sage 2.8.8.1, I realized it was really
broken -- It doesn't work if EDITOR is unset in the environment. The
patch attached to the trac ticket is supposed to fix that.
I'm generally happy with this patch, though I don't agree with removing
the bg option. Perhaps you're removing that functionality because
your particular workflow is more rigid than mine. For example, I use
emacs quite a lot, both in a console (especially when I login to other
machines), but also as a popup separate application. When I use emacs
in console mode, putting the editor in the background is very frusting,
and doesn't work at all. When I use emacs as a separate popup
application, it
is very very frustrating if the console session freezes, since often the
reason
I'm popping up the editor is to create some examples in the console and
paste them into the docstring of a function. In both cases the command
name is exactly the same emacs.
So please change the patch back to have the bg option.
This is a lot like black on white versus white on black. Most people
exclusively
use one or the other mode,
[sage-devel] Re: edit_module patch updated
On Oct 24, 6:50 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/24/07, Nils Bruin [EMAIL PROTECTED] wrote:
I understand that the bg= hack is a quick way of getting the
configurability you want, but frankly, I would find it hard to explain
the existence of that option independent of the very particular usage
scenario you describe.
To you, since you don't use it, it is a very particular usage scenario.
To me it is the normal very common (for me at least) usage scenario.
Jf we want sage to pop up the appropriate editor, the user should
not be required to give an extra option like that.
I certainly don't propose that they have to give the extra option.
It is optional. There should still be the default proposal you implemented.
edit(.., bg=None)
does the default
edit(..., bg=True)
does the background = True mode,
edit(..., bg = False)
does the background = False mode.
In the model I
proposed (which clearly is inconvenient to you, so we need to see how
to wrap this), the solution would be to put into your init.sage
(basically following a suggestion Justin made):
if os.environ.haskey('DISPLAY'):
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
')
else:
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
So, if you're sure that this does for emacs what you want, we could
I'm sure that does *not* do what I want. When I login to my laptop
under Linux the DISPLAY environment variable is not even set, yet
emacs pops up in a window.When I login remotely to another machine
(or my laptop, from OS X), it can easily be that DISPLAY is not set.
I also have a similar issue with my office desktop, which I use both
remotely and when I'm actually in my office at the console.
wrap this into the set_editor command instead of the bg= option.
Then the appropriate magic gets executed if either 'EDITOR=emacs' or
if set_editor('emacs'), and currently even if edit(..,
editor='emacs').
Guessing a user's configuration and preferences will stay hackish
guesswork. I'm happy to put some guesses into set_editor. Ultimately,
however, people should just put personal configuration stuff into
init.sage. (either that or every user patches sage.misc.edit_module
^
That doesn't work for me, since in my usage the init.sage is the same
in both cases, and I often switch between both usage scenarios.
Another solution would be two possible editor templates: emacs-fg
and emacs-bg.
I just want to type
sage: edit(name)
and have it work. If it happens to be that a window pops up, and will
say to myself -- gee, I need this to be backgrounded so I can type
command still, and I'll instead do
sage; edit(name, bg=True).
Anyway, I can't see the problem with having that option, and your only
argument against it is that it is difficult to explain in the documentation.
-- William
On Oct 23, 11:03 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote:
See:
http://sagetrac.org/sage_trac/ticket/768
I have updated the attached patch to be clean against 2.8.8.1. When I
checked the edit() command in sage 2.8.8.1, I realized it was really
broken -- It doesn't work if EDITOR is unset in the environment. The
patch attached to the trac ticket is supposed to fix that.
I'm generally happy with this patch, though I don't agree with removing
the bg option. Perhaps you're removing that functionality because
your particular workflow is more rigid than mine. For example, I use
emacs quite a lot, both in a console (especially when I login to other
machines), but also as a popup separate application. When I use emacs
in console mode, putting the editor in the background is very frusting,
and doesn't work at all. When I use emacs as a separate popup
application, it
is very very frustrating if the console session freezes, since often the
reason
I'm popping up the editor is to create some examples in the console and
paste them into the docstring of a function. In both cases the command
name is exactly the same emacs.
So please change the patch back to have the bg option.
This is a lot like black on white versus white on black. Most people
exclusively
use one or the other mode, and it's impossible to know which from the
application's point of view.So applications have to support both and
make
it easy to switch between generating colors for each. I often switch
between
using emacs and vi, both in window and console mode, and between black
on white and white on black, depending on my mood, eye strain, computing
I'm logged into, etc. So it needs to be easy to support changing modes.
The bg= option to edit is 3 lines of code and does just that; it allows
one to
very easily override automatic defaults on a per-use basis.
-- William
Hello
[sage-devel] Re: Notices this month
On Oct 23, 9:52 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Our opinion piece Open Source Mathematical Software appeared in the Notices of the AMS this month: http://www.ams.org/notices/200710/ The link to the article is on the upper-right corner of the page. Thanks to everybody who helped with the article! This article is featured as a news picks item on Groklaw (http:// www.groklaw.net) right now. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
It would be interesting to see the number of visitors to sagemath.org who come from that pdf on ams. See http://www.apacheweek.com/features/logfiles and search for referrer On 10/24/07, cwitty [EMAIL PROTECTED] wrote: On Oct 23, 9:52 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Our opinion piece Open Source Mathematical Software appeared in the Notices of the AMS this month: http://www.ams.org/notices/200710/ The link to the article is on the upper-right corner of the page. Thanks to everybody who helped with the article! This article is featured as a news picks item on Groklaw (http:// www.groklaw.net) right now. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
I've implemented a function and hook to do this in the new version of
Cython, but I'm not sure how well it will work in practice on the
entire SAGE library. It will decref local variable and all, but then
if anything (e.g. other destructors) ever try and use any of the
module again it will crash with high probability (because the
expected variables will no longer be set).
- Robert
On Oct 17, 2007, at 9:20 PM, mabshoff wrote:
On Oct 18, 6:16 am, Robert Bradshaw [EMAIL PROTECTED]
wrote:
Hi Robert,
No cleanup function is ever generated, but atexit sounds perfect.
Good that you seem to agree with my analysis. I ran across it be sheer
accident while looking at some linker issue that roed asked me about.
I'm the obvious person to implement this,
Pretty much 100% what I just claimed in IRC, but cwitty might look at
it during Bug Day 4.
I'll see if I can find the time to do so soon.
Let's hope so.
- Robert
Cheers,
Michael
On Oct 17, 2007, at 9:04 PM, mabshoff wrote:
Hello,
for every module Cython generates runtime support code that is
place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyObject *__import__ = 0;
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
__import__ = PyObject_GetAttrString(__pyx_b, __import__);
if (!__import__)
goto bad;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
module = PyObject_CallFunction(__import__, ,
name, global_dict, empty_dict, list);
bad:
Py_XDECREF(empty_list);
Py_XDECREF(__import__);
Py_XDECREF(empty_dict);
return module;
}
In that function PyMODINIT_FUNC init$MODULENAME(void) we also call
__Pyx_ImportType quite often:
static PyTypeObject *__Pyx_ImportType(char *module_name, char
*class_name,
long size)
{
PyObject *py_module_name = 0;
PyObject *py_class_name = 0;
PyObject *py_name_list = 0;
PyObject *py_module = 0;
PyObject *result = 0;
py_module_name = PyString_FromString(module_name);
if (!py_module_name)
goto bad;
py_class_name = PyString_FromString(class_name);
if (!py_class_name)
goto bad;
py_name_list = PyList_New(1);
if (!py_name_list)
goto bad;
Py_INCREF(py_class_name);
if (PyList_SetItem(py_name_list, 0, py_class_name) 0)
goto bad;
py_module = __Pyx_Import(py_module_name, py_name_list);
if (!py_module)
goto bad;
result = PyObject_GetAttr(py_module, py_class_name);
if (!result)
goto bad;
if (!PyType_Check(result)) {
PyErr_Format(PyExc_TypeError,
%s.%s is not a type object,
module_name, class_name);
goto bad;
}
if (((PyTypeObject *)result)-tp_basicsize != size) {
PyErr_Format(PyExc_ValueError,
%s.%s does not appear to be the correct type object,
module_name, class_name);
goto bad;
}
goto done;
bad:
Py_XDECREF(result);
result = 0;
done:
Py_XDECREF(py_module_name);
Py_XDECREF(py_class_name);
Py_XDECREF(py_name_list);
return (PyTypeObject *)result;
}
As one can see certain PyObject have refcounts greater 0 when
initialization is successful. But I cannot find a cleanup function
that would decrease the reference count upon exit. Consequently
python's garbage collector never frees those dictionaries, which in
most cases doesn't matter because we are exiting python anyway [some
people claim that one shouldn't care about still reachable memory,
because cleaning it up the nice way just slows down the
termination of
a process because the system will reap the heap and stack
automatically]. But it pollutes the memcheck log, which is why I
care
about this.
The usual way to call those functions for each module would be to
register an atexit function, see
http://docs.python.org/lib/module-atexit.html
So if anybody want to write am autogenerated cleanup function for
Cython and register it via atexit that person would be very
welcome :)
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 24, 9:01 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Robert, I've implemented a function and hook to do this in the new version of Cython, Cool. but I'm not sure how well it will work in practice on the entire SAGE library. It will decref local variable and all, but then if anything (e.g. other destructors) ever try and use any of the module again it will crash with high probability (because the expected variables will no longer be set). Well, if it crashes upon exit I would consider that a bug and we can hopefully fix them. If you have an inofficial spkg I would really like to take it for a spin. - Robert Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
On Oct 24, 8:44 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Hello, I've noticed sometimes the public sage notebook is really, really slow, for instance when someone is running a lot of dsage or valgrind jobs. since you mention valgrind I would like to remark that I usually limit myself to one long term and one short term job on sage.math, so it wasn't me :) Perhaps it would be good to consider an intensive job blackout period for moments of potential big publicity so that the public notebook can provide a good impression. That is certainly a valid point. - Robert Cheers, Michael On Oct 24, 2007, at 11:20 AM, Timothy Clemans wrote: It would be interesting to see the number of visitors to sagemath.org who come from that pdf on ams. Seehttp://www.apacheweek.com/features/logfilesand search for referrer On 10/24/07, cwitty [EMAIL PROTECTED] wrote: On Oct 23, 9:52 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Our opinion piece Open Source Mathematical Software appeared in the Notices of the AMS this month: http://www.ams.org/notices/200710/ The link to the article is on the upper-right corner of the page. Thanks to everybody who helped with the article! This article is featured as a news picks item on Groklaw (http:// www.groklaw.net) right now. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Integrating SymPy with SAGE
The code is here: http://dakol.hopto.org/sympy-sage/ It was now merged in the main repository http://dakol.hopto.org/sympy/ you can get it by: hg clone http://dakol.hopto.org/sympy/ or simply use the spkg I made (see the track ticket). Ondrej BTW, Mercurial hgweb is really awesome. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
On 10/24/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 24, 8:44 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I've noticed sometimes the public sage notebook is really, really slow, for instance when someone is running a lot of dsage or valgrind jobs. since you mention valgrind I would like to remark that I usually limit myself to one long term and one short term job on sage.math, so it wasn't me :) Guilty :-). The slowdown I think you're referring to was actually me, running a big dsage job that involved computing Hecke operators needed to finish a paper. I bought sage.math using NSF money specifically to support my research program, so for better or worse, that work should take precedence over the public sage notebook servers. I have not received any money yet for hardware to support Sage notebook servers, and when I do I will use it to buy a machine dedicated to running them. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
On Oct 24, 2007, at 12:42 PM, mabshoff wrote: On Oct 24, 8:44 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Hello, I've noticed sometimes the public sage notebook is really, really slow, for instance when someone is running a lot of dsage or valgrind jobs. since you mention valgrind I would like to remark that I usually limit myself to one long term and one short term job on sage.math, so it wasn't me :) I only mentioned it because I would usually see a valgrind or two at 100% whenever I ran top. Sorry, not trying to point fingers... In retrospect, Timothy Clemans' email about sagenb.org vs. sagenb.com is probably what my issue was--that is really strange. Perhaps it would be good to consider an intensive job blackout period for moments of potential big publicity so that the public notebook can provide a good impression. That is certainly a valid point. - Robert Cheers, Michael On Oct 24, 2007, at 11:20 AM, Timothy Clemans wrote: It would be interesting to see the number of visitors to sagemath.org who come from that pdf on ams. Seehttp://www.apacheweek.com/features/logfilesand search for referrer On 10/24/07, cwitty [EMAIL PROTECTED] wrote: On Oct 23, 9:52 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Our opinion piece Open Source Mathematical Software appeared in the Notices of the AMS this month: http://www.ams.org/notices/200710/ The link to the article is on the upper-right corner of the page. Thanks to everybody who helped with the article! This article is featured as a news picks item on Groklaw (http:// www.groklaw.net) right now. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 24, 2007, at 12:39 PM, mabshoff wrote: On Oct 24, 9:01 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Robert, I've implemented a function and hook to do this in the new version of Cython, Cool. but I'm not sure how well it will work in practice on the entire SAGE library. It will decref local variable and all, but then if anything (e.g. other destructors) ever try and use any of the module again it will crash with high probability (because the expected variables will no longer be set). Well, if it crashes upon exit I would consider that a bug and we can hopefully fix them. There are three levels of cleanup--each more aggressive than the previous, but even the most basic level will potentially render any of the module-level functions unusable. Hopefully we can find the minimum set of things to decref so that the python interpreter can take care of the rest. If you have an inofficial spkg I would really like to take it for a spin. I'm hoping to have time to package it all up tonight and make sure SAGE still builds fine. If not, at the very least I'll post an unofficial package. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
William Stein wrote: my research program, so for better or worse, that work should take precedence over the public sage notebook servers. I have not received any money yet for hardware to support Sage notebook servers, and when I do I will use it to buy a machine dedicated to running them. How/where can I donate from here? Europe, The Netherlands. Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote: William Stein wrote: my research program, so for better or worse, that work should take precedence over the public sage notebook servers. I have not received any money yet for hardware to support Sage notebook servers, and when I do I will use it to buy a machine dedicated to running them. How/where can I donate from here? Europe, The Netherlands. You can make a tax-deductable donation over the web as follows: (1) Go to https://secure.gifts.washington.edu/as_mathematics/gift.asp?source_typ=2source=EAV (This is linked to from http://www.math.washington.edu/Development/giving.php at the UW math dept page.) (2) Click on Friends of Mathematics Fund, then click Continue (which is above the check boxes). (3) Fill out the form, and in the comments box write that 'the donation is for The SAGE Foundation' You should receive a receipt after you submit the form. If you have any trouble, let me know. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
On 10/24/07, William Stein [EMAIL PROTECTED] wrote: How/where can I donate from here? Europe, The Netherlands. You can also make a donation by check as follows: Check: please mail your check to: The University of Washington Foundation Box 358240 Seattle, Washington 98195-8240 Make your check payable to the University of Washington Foundation and indicate the fund you wish to support is SAGE on the check. Note that once I've received a total of $1000 in donations this way, the University of Washington will create a new separate discretionary account specifically for the Sage Foundation, and transfer the money there. -- William You can make a tax-deductable donation over the web as follows: (1) Go to https://secure.gifts.washington.edu/as_mathematics/gift.asp?source_typ=2source=EAV (This is linked to from http://www.math.washington.edu/Development/giving.php at the UW math dept page.) (2) Click on Friends of Mathematics Fund, then click Continue (which is above the check boxes). (3) Fill out the form, and in the comments box write that 'the donation is for The SAGE Foundation' You should receive a receipt after you submit the form. If you have any trouble, let me know. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
William Stein wrote: On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote: William Stein wrote: my research program, so for better or worse, that work should take precedence over the public sage notebook servers. I have not received any money yet for hardware to support Sage notebook servers, and when I do I will use it to buy a machine dedicated to running them. How/where can I donate from here? Europe, The Netherlands. You can make a tax-deductable donation over the web as follows: (1) Go to https://secure.gifts.washington.edu/as_mathematics/gift.asp?source_typ=2source=EAV (This is linked to from http://www.math.washington.edu/Development/giving.php at the UW math dept page.) (2) Click on Friends of Mathematics Fund, then click Continue (which is above the check boxes). (3) Fill out the form, and in the comments box write that 'the donation is for The SAGE Foundation' I seem to be forced to fill the boxes state and zip!? How could I not living in the US? You should receive a receipt after you submit the form. If you have any trouble, let me know. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Fwd: [sage-support] An interactive 2D/3D environment for SAGE
From: Ted Kosan [EMAIL PROTECTED] Date: Oct 24, 2007 2:01 PM Subject: [sage-support] An interactive 2D/3D environment for SAGE To: [EMAIL PROTECTED] For the past couple of months, I have been researching strategies for extending SAGE with an interactive 2D/3D environment that would be significantly more advanced than what current mathematics software provides. My vision is to be able to place the user into a 3D environment where they can interact with numerous rich mathematics objects that are floating around them in 3D space. So far, the best environment I have come up with is Croquet ( http://opencroquet.org ). Here is a video which shows the basics of how Croquet works: http://www.youtube.com/watch?v=oKi-fkyAtg8 And this video shows Croquet used in an amazing interactive session: http://www.youtube.com/watch?v=2LN5JRl8_sUeurl=http%3A%2F%2Fvideo%2Egreenbush%2Eus%2F%3Frandom%3D Anyway, what do people think about the idea of using Croquet as an interactive 2D/3D environment for SAGE? Ted --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] SAGE 2.8.9rc1
Dear all, the impossible is happening and I am announcing SAGE 2.8.9rc1 to the world. It is mainly a bugfix and small feature release. However, we now ship fpLLL by Damien Stehle and David Cade and thus SAGE's LLL is much faster and easier to use. Tickets Closed/Issues Resolved/Kittens Rescued: === 758 Use NTL directly in Z/nZ polynomials robertwb 837 RealNumber should have abs method cwitty 904 graphs: clique-testing jason 929 wrap fpLLL-2.0 malb 967 inplace operators for GF(p),GF(p^n) ... malb 282 add matrix() class to FiniteFields ... malb 968 graph_isom: memory management, legibility rlm 768 Open a method source in the editor of your choice nbruin 895 .inverse() method for matrices mhansen 898 ntl.GF2 malb 916 remove structure.sequence._combinations malb 963 singular attribut getting/setting malb 966 ntl.GF2X malb 970 ntl.GF2E malb 974 small memleak in nullspace.c in IML mabshoff 310 Debian testing version of mercurial ... cwitty 920 integrate doesn't handle divergent case correctly mhansen 921 Exception error for divergent integral looks bad mhansen 976 fpLLL fast early reduction segfaults malb/stehle 977 Schubert polynomials send 1 ... mhansen 978 bug in Sequence __str__ method was 982 abs(x) returns incorrect LaTex mhansen ... and some more were invalidated. Get It While Its Hot == The rc1 tarball is available at http://sage.math.washington.edu/home/malb/sage-2.8.9/sage-2.8.9.rc1.tar and really needs some testing. So please build and 'testall' it and report back what happens. Known Issues: == I've seen doctest failures in calculus/equations.py because Maxima doesn't produce the ascii-art representation of an equation. I'd be interested if others can reproduce and fix this issue. Have fun, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] sloccount of sage-2.8.9.rc1
Hello, I ran sloccount on the latest rc1 and here are the results: SLOCDirectory SLOC-by-Language (Sorted) 687172 python-2.5.1.p7 ansic=354375,python=315376,asm=6567,sh=3895,lisp=3683, perl=2520,objc=756 422885 scipy-20070817 cpp=120609,ansic=112030,python=10,fortran=80892, objc=424,sh=42 366515 lapack-20070723 fortran=366387,pascal=116,sh=12 289667 maxima-5.13.0 lisp=246582,fortran=14666,perl=14325,tcl=10222,sh=3386, ansic=471,python=8,awk=7 243569 matplotlib-0.90.0.p4 python=143836,cpp=86548,ansic=13166,sh=19 217702 singular-3-0-3-2-20071020 cpp=178602,ansic=22558,perl=5570,lisp=4063, sh=3454,yacc=1702,lex=1398,csh=189,python=163,sed=3 180146 gsl-1.9 ansic=177097,sh=3038,python=11 148822 gmp-4.2.1.p10 ansic=71142,asm=51587,cpp=13109,sh=9189,perl=3247, yacc=226,lisp=203,lex=95,fortran=24 146962 sage-2.8.9.rc1 python=137419,cpp=7261,ansic=2175,sh=107 138581 clisp-2.41.p8 lisp=74381,ansic=40568,sh=11561,fortran=6692,cpp=2660, objc=2481,perl=164,sed=55,python=19 136483 twisted-2.5.0.p8 python=134313,ansic=2132,sh=38 126094 numpy-20070816 ansic=74659,python=50778,fortran=248,cpp=197,sh=115, f90=97 122683 gap-4.4.10 ansic=116320,sh=3008,lisp=1804,perl=1545,awk=6 120578 pari-2.3.2.p3 ansic=114629,lisp=5173,sh=603,perl=153,python=20 99638 gnutls-1.6.3ansic=95992,sh=1956,cpp=1046,perl=628,sed=16 89269 freetype-2.1.10 ansic=75080,sh=8160,python=6029 85877 sqlite-3.3.17.p1 ansic=62811,tcl=19241,sh=2839,yacc=806,awk=180 78638 symmetrica-0.3.3 ansic=78621,sh=17 78227 ntl-5.4.1.p6ansic=78132,sh=95 71706 sympy-0.5.3 python=71703,sh=3 69131 cvxopt-0.8.2.p3 ansic=64322,python=4019,fortran=777,sh=11,awk=2 68472 linbox-20070915 cpp=67991,sh=475,sed=4,perl=2 56976 mpfr-2.3.0 ansic=51542,sh=5434 48014 moin-1.5.7 python=35148,java=10704,perl=1424,php=642,sh=96 43165 doc-2.8.9.rc1 perl=25684,python=14518,lisp=2427,sh=473,ansic=61, sed=2 42891 libpng-1.2.18 ansic=34404,sh=8482,cpp=5 42128 libgcrypt-1.2.4 ansic=29468,sh=8048,asm=4612 41945 mercurial-0.9.5 python=27386,sh=8300,tcl=3484,lisp=1411,ansic=1364 40831 gd-2.0.33.p5ansic=32741,sh=7625,perl=420,tcl=45 36865 zodb3-3.7.0 python=29676,ansic=7183,sh=6 35272 ecm-6.1.3 ansic=17313,asm=13213,sh=4085,python=661 33854 f2c-20070816ansic=33833,sh=21 32399 mwrank-20070913 cpp=30167,sh=2232 31381 flint-0.2.p4ansic=29483,cpp=1540,python=246,sh=112 30135 readline-5.2ansic=22060,perl=4105,sh=3970 24248 cython-0.9.6.7.a python=21236,ansic=3012 23341 quaddouble-2.2.p7 cpp=8526,sh=8387,fortran=6428 21954 networkx-0.35.1 python=21950,sh=4 21542 scons-0.97 python=21536,sh=6 18624 givaro-3.2.6.p1 cpp=10211,sh=8409,sed=4 18272 ipython-0.8.1.p1 python=17982,lisp=262,sh=28 16862 zlib-1.2.3.p2 ansic=8912,asm=3281,ada=1681,pascal=1089,cpp=1001, cs=879,sh=19 16070 blas-20070724 fortran=16057,sh=13 13989 palp-1.1ansic=13978,sh=11 13519 tachyon-0.98beta.p2 ansic=13445,sh=41,perl=33 12660 gfan-0.2.2.p1 cpp=12637,sh=23 11948 libgpg_error-1.5 sh=8126,ansic=3254,awk=428,lisp=140 10342 pycrypto-2.0.1.p1 ansic=7302,python=3036,sh=4 9769cddlib-094b ansic=9036,sh=733 8974iml-1.0.1.p7ansic=6155,sh=2819 8923libfplll-2.1-20071024 cpp=5437,sh=3486 8151lcalc-20070107 cpp=4580,ansic=3548,sh=23 6771mpfi-1.3.4-rc3.p8 ansic=3960,sh=2811 6037opencdk-0.5.9 ansic=5456,perl=465,sh=116 5912ipython1-20070130 python=5818,ansic=68,sh=26 5491pysqlite-2.3.3 ansic=3377,python=2106,sh=8 4242python_gnutls-1.1.1 python=4213,ansic=23,sh=6 3796sympow-1.018.1.p3 ansic=3367,sh=429 3766weave-0.4.9 python=3760,sh=6 3584sage_scripts-2.8.9.rc1 python=1869,sh=1714,lisp=1 3527gdmodule-0.56.p4 ansic=3316,python=198,sh=13 3015extcode-2.8.9.rc1 objc=2765,java=176,lisp=62,sh=12 2224flintqs-20070817 cpp=1574,ansic=623,sh=27 1975genus2reduction-0.3 ansic=1962,sh=13 1329pexpect-2.0.p1 python=1322,sh=7 900 termcap-1.3.1 ansic=857,sh=43 783 examples-2.8.9.rc1 python=719,sh=30,lisp=18,fortran=13,ansic=3 140 fortran-20070912 python=130,sh=10 25 elliptic_curves-0.1 sh=25 17 java3d-20070901 sh=17 2 conway_polynomials-0.2 sh=2 2 graphs-20070722 sh=2 Totals grouped by language (dominant language first): ansic: 1907386 (39.59%) python: 1186092 (24.62%) cpp: 553701 (11.49%) fortran: 492184 (10.22%) lisp:340210 (7.06%) sh: 138356 (2.87%) asm: 79260 (1.65%) perl: 60285 (1.25%) tcl: 32992 (0.68%) java: 10880 (0.23%) objc: 6426 (0.13%) yacc: 2734 (0.06%) ada: 1681 (0.03%) lex: 1493 (0.03%) pascal:1205 (0.03%) cs: 879 (0.02%) php:642 (0.01
[sage-devel] Re: random polynomial generation
I've attached a patch that takes care of 1) only and updated
http://sagetrac.org/sage_trac/ticket/980 . The individual degree
distribution is a little better:
{{{
sage: GF(10007)['x,y,q'].random_element(6,10)
-2005*x^6 + 2400*x^4*y^2 - 3609*x^3*y^3 + 488*x*y^5 - 3093*x^4*y*q +
3482*x*y*q^3 - 989*x^2*y*q - 3529*x*q^3 - 3957*x
}}}
But note that most of the time for the example at the beginning of the
thread, we still get 6,7 out of 9 terms most of the time. I still
don't think this is a bug: we are not creating a polynomial with 9
terms in it, but picking one with at most 9 terms.
{{{
sage: GF(10007)['x,y'].random_element(4,9)
797*x^4 - 439*x^2*y^2 - 1457*x*y^3 - 2348*y^4 - 1721*x^3 - 1885*x^2*y
- 1760*x*y^2 + 310*y
}}}
didier
2007/10/24, Steffen [EMAIL PROTECTED]:
On Oct 24, 5:45 am, didier deshommes [EMAIL PROTECTED] wrote:
2007/10/23, Steffen [EMAIL PROTECTED]:
Exactly, thats one of two points. The maximum degree in every variable
is (maximum total degree of resulting polynomial) / (number of
varialbes of the polynomial). Thus for example GF(10007)
['x,y,z'].random_element(5,9) will be limited in every variable to
degree 5/3 = 1 !!!. This is not what the upper definition says.
The second point is about the number of coefficients that are set to
0. This might a point to argue about, but if I create a random
polynomial with a (maximum number of terms to generate) then I expect
that the 0 occurs with the same probability and thus as often as every
other element. Thats why I am not happy if 20% or more of the
parameters are 0.
I filed out a bug report about those 2 issues:
1) Degrees can severely restricted.
2) The polynomials returned can be too sparse
I plan to post a patch addressing your concerns (I can especially see
how 1) can be annoying). Random poly generation will most likely be
slower, so for now I'm planning to keep the current behavior around,
even if it is not the default.
didier
Thanks, I will wait for didiers patch. If I then have any additional
requirements I will implement them via an optional flag or smth
similar.
Steffen
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
diff -r 1a19787af98d sage/rings/polynomial/multi_polynomial_ring_generic.pyx
--- a/sage/rings/polynomial/multi_polynomial_ring_generic.pyx Sun Oct 21
10:13:32 2007 -0700
+++ b/sage/rings/polynomial/multi_polynomial_ring_generic.pyx Wed Oct 24
18:23:14 2007 -0400
@@ -453,23 +453,31 @@ cdef class MPolynomialRing_generic(sage.
sage: R.random_element(41) # random
-4*x^6*y^4*z^4*a^6*b^3*c^6*d^5 + 1/2*x^4*y^3*z^5*a^4*c^5*d^6 -
5*x^3*z^3*a^6*b^4*c*d^5 + 10*x^2*y*z^5*a^4*b^2*c^3*d^4 - 5*x^3*y^5*z*b^2*c^5*d
-
+sage: f=ZZ['q,w,e,r,t,y'].random_element(degree=200,terms=19)
+sage: f.degree() = 200
+True
+
AUTHOR:
-- didier deshommes
-# General strategy:
-# generate n-tuples of numbers with each element in the tuple
-# not greater than (degree/n) so that the degree
-# (ie, the sum of the elements in the tuple) does not exceed
-# their total degree
-
+
n = self.__ngens # length of the n-tuple
-max_deg = int(degree/n) # max degree for each term
R = self.base_ring()
-# restrict exponents to positive integers only
-exponents = [ tuple([ZZ.random_element(0,max_deg+1) for _ in range(n)])
- for _ in range(terms) ]
+exponents = []
+for i in range(terms):
+exps = []
+deg = degree
+for i in range(n):
+exp = ZZ.random_element(0,deg+1)
+if exp = deg:
+exps.append(exp)
+deg -= exp
+else:
+exps.append(0)
+
+exponents.append(tuple(exps))
+
coeffs = []
for _ in range(terms):
c = R.random_element(*args,**kwds)
[sage-devel] Re: sloccount of sage-2.8.9.rc1
Sorry to reply to myself so quickly, but as Carl Witty pointed out I need to run the code with --multiproject. In addition we now count pxd, pxi and pyx as python. With those settings we do get slighly smaller number, but still very impressive results: SLOCDirectory SLOC-by-Language (Sorted) 687172 python-2.5.1.p7 ansic=354375,python=315376,asm=6567,sh=3895,lisp=3683, perl=2520,objc=756 424057 scipy-20070817 cpp=120609,ansic=112030,python=110060,fortran=80892, objc=424,sh=42 366515 lapack-20070723 fortran=366387,pascal=116,sh=12 289667 maxima-5.13.0 lisp=246582,fortran=14666,perl=14325,tcl=10222,sh=3386, ansic=471,python=8,awk=7 243569 matplotlib-0.90.0.p4 python=143836,cpp=86548,ansic=13166,sh=19 217702 singular-3-0-3-2-20071020 cpp=178602,ansic=22558,perl=5570,lisp=4063, sh=3454,yacc=1702,lex=1398,csh=189,python=163,sed=3 214448 sage-2.8.9.rc1 python=204905,cpp=7261,ansic=2175,sh=107 180146 gsl-1.9 ansic=177097,sh=3038,python=11 148822 gmp-4.2.1.p10 ansic=71142,asm=51587,cpp=13109,sh=9189,perl=3247, yacc=226,lisp=203,lex=95,fortran=24 138581 clisp-2.41.p8 lisp=74381,ansic=40568,sh=11561,fortran=6692,cpp=2660, objc=2481,perl=164,sed=55,python=19 136954 twisted-2.5.0.p8 python=134784,ansic=2132,sh=38 127343 numpy-20070816 ansic=74659,python=52027,fortran=248,cpp=197,sh=115, f90=97 122683 gap-4.4.10 ansic=116320,sh=3008,lisp=1804,perl=1545,awk=6 120578 pari-2.3.2.p3 ansic=114629,lisp=5173,sh=603,perl=153,python=20 99638 gnutls-1.6.3ansic=95992,sh=1956,cpp=1046,perl=628,sed=16 89269 freetype-2.1.10 ansic=75080,sh=8160,python=6029 85877 sqlite-3.3.17.p1 ansic=62811,tcl=19241,sh=2839,yacc=806,awk=180 78638 symmetrica-0.3.3 ansic=78621,sh=17 78227 ntl-5.4.1.p6ansic=78132,sh=95 71706 sympy-0.5.3 python=71703,sh=3 69131 cvxopt-0.8.2.p3 ansic=64322,python=4019,fortran=777,sh=11,awk=2 68472 linbox-20070915 cpp=67991,sh=475,sed=4,perl=2 56976 mpfr-2.3.0 ansic=51542,sh=5434 48014 moin-1.5.7 python=35148,java=10704,perl=1424,php=642,sh=96 43165 doc-2.8.9.rc1 perl=25684,python=14518,lisp=2427,sh=473,ansic=61, sed=2 42891 libpng-1.2.18 ansic=34404,sh=8482,cpp=5 42128 libgcrypt-1.2.4 ansic=29468,sh=8048,asm=4612 41945 mercurial-0.9.5 python=27386,sh=8300,tcl=3484,lisp=1411,ansic=1364 40831 gd-2.0.33.p5ansic=32741,sh=7625,perl=420,tcl=45 36865 zodb3-3.7.0 python=29676,ansic=7183,sh=6 35272 ecm-6.1.3 ansic=17313,asm=13213,sh=4085,python=661 33854 f2c-20070816ansic=33833,sh=21 32399 mwrank-20070913 cpp=30167,sh=2232 31381 flint-0.2.p4ansic=29483,cpp=1540,python=246,sh=112 30135 readline-5.2ansic=22060,perl=4105,sh=3970 24965 cython-0.9.6.7.a python=21953,ansic=3012 23341 quaddouble-2.2.p7 cpp=8526,sh=8387,fortran=6428 21954 networkx-0.35.1 python=21950,sh=4 21542 scons-0.97 python=21536,sh=6 18624 givaro-3.2.6.p1 cpp=10211,sh=8409,sed=4 18272 ipython-0.8.1.p1 python=17982,lisp=262,sh=28 16862 zlib-1.2.3.p2 ansic=8912,asm=3281,ada=1681,pascal=1089,cpp=1001, cs=879,sh=19 16070 blas-20070724 fortran=16057,sh=13 13989 palp-1.1ansic=13978,sh=11 13519 tachyon-0.98beta.p2 ansic=13445,sh=41,perl=33 12660 gfan-0.2.2.p1 cpp=12637,sh=23 11948 libgpg_error-1.5 sh=8126,ansic=3254,awk=428,lisp=140 10342 pycrypto-2.0.1.p1 ansic=7302,python=3036,sh=4 9769cddlib-094b ansic=9036,sh=733 8974iml-1.0.1.p7ansic=6155,sh=2819 8923libfplll-2.1-20071024 cpp=5437,sh=3486 8151lcalc-20070107 cpp=4580,ansic=3548,sh=23 6771mpfi-1.3.4-rc3.p8 ansic=3960,sh=2811 6037opencdk-0.5.9 ansic=5456,perl=465,sh=116 5912ipython1-20070130 python=5818,ansic=68,sh=26 5491pysqlite-2.3.3 ansic=3377,python=2106,sh=8 4242python_gnutls-1.1.1 python=4213,ansic=23,sh=6 3796sympow-1.018.1.p3 ansic=3367,sh=429 3766weave-0.4.9 python=3760,sh=6 3584sage_scripts-2.8.9.rc1 python=1869,sh=1714,lisp=1 3527gdmodule-0.56.p4 ansic=3316,python=198,sh=13 3015extcode-2.8.9.rc1 objc=2765,java=176,lisp=62,sh=12 2224flintqs-20070817 cpp=1574,ansic=623,sh=27 1975genus2reduction-0.3 ansic=1962,sh=13 1856examples-2.8.9.rc1 python=1792,sh=30,lisp=18,fortran=13,ansic=3 1329pexpect-2.0.p1 python=1322,sh=7 900 termcap-1.3.1 ansic=857,sh=43 140 fortran-20070912 python=130,sh=10 25 elliptic_curves-0.1 sh=25 17 java3d-20070901 sh=17 2 conway_polynomials-0.2 sh=2 2 graphs-20070722 sh=2 Totals grouped by language (dominant language first): ansic: 1907386 (39.01%) python: 1258260 (25.73%) cpp: 553701 (11.32%) fortran: 492184 (10.07%) lisp:340210 (6.96%) sh: 138356 (2.83%) asm: 79260 (1.62%) perl: 60285 (1.23%) tcl: 32992 (0.67%) java: 10880 (0.22%) objc
[sage-devel] Re: sloccount of sage-2.8.9.rc1
See http://sage.math.washington.edu/home/mabshoff/2.8.9.rc1-sloccount.html for a readable version of these tables. On 10/24/07, mabshoff [EMAIL PROTECTED] wrote: Sorry to reply to myself so quickly, but as Carl Witty pointed out I need to run the code with --multiproject. In addition we now count pxd, pxi and pyx as python. With those settings we do get slighly smaller number, but still very impressive results: SLOCDirectory SLOC-by-Language (Sorted) 687172 python-2.5.1.p7 ansic=354375,python=315376,asm=6567,sh=3895,lisp=3683, perl=2520,objc=756 424057 scipy-20070817 cpp=120609,ansic=112030,python=110060,fortran=80892, objc=424,sh=42 366515 lapack-20070723 fortran=366387,pascal=116,sh=12 289667 maxima-5.13.0 lisp=246582,fortran=14666,perl=14325,tcl=10222,sh=3386, ansic=471,python=8,awk=7 243569 matplotlib-0.90.0.p4 python=143836,cpp=86548,ansic=13166,sh=19 217702 singular-3-0-3-2-20071020 cpp=178602,ansic=22558,perl=5570,lisp=4063, sh=3454,yacc=1702,lex=1398,csh=189,python=163,sed=3 214448 sage-2.8.9.rc1 python=204905,cpp=7261,ansic=2175,sh=107 180146 gsl-1.9 ansic=177097,sh=3038,python=11 148822 gmp-4.2.1.p10 ansic=71142,asm=51587,cpp=13109,sh=9189,perl=3247, yacc=226,lisp=203,lex=95,fortran=24 138581 clisp-2.41.p8 lisp=74381,ansic=40568,sh=11561,fortran=6692,cpp=2660, objc=2481,perl=164,sed=55,python=19 136954 twisted-2.5.0.p8 python=134784,ansic=2132,sh=38 127343 numpy-20070816 ansic=74659,python=52027,fortran=248,cpp=197,sh=115, f90=97 122683 gap-4.4.10 ansic=116320,sh=3008,lisp=1804,perl=1545,awk=6 120578 pari-2.3.2.p3 ansic=114629,lisp=5173,sh=603,perl=153,python=20 99638 gnutls-1.6.3ansic=95992,sh=1956,cpp=1046,perl=628,sed=16 89269 freetype-2.1.10 ansic=75080,sh=8160,python=6029 85877 sqlite-3.3.17.p1 ansic=62811,tcl=19241,sh=2839,yacc=806,awk=180 78638 symmetrica-0.3.3 ansic=78621,sh=17 78227 ntl-5.4.1.p6ansic=78132,sh=95 71706 sympy-0.5.3 python=71703,sh=3 69131 cvxopt-0.8.2.p3 ansic=64322,python=4019,fortran=777,sh=11,awk=2 68472 linbox-20070915 cpp=67991,sh=475,sed=4,perl=2 56976 mpfr-2.3.0 ansic=51542,sh=5434 48014 moin-1.5.7 python=35148,java=10704,perl=1424,php=642,sh=96 43165 doc-2.8.9.rc1 perl=25684,python=14518,lisp=2427,sh=473,ansic=61, sed=2 42891 libpng-1.2.18 ansic=34404,sh=8482,cpp=5 42128 libgcrypt-1.2.4 ansic=29468,sh=8048,asm=4612 41945 mercurial-0.9.5 python=27386,sh=8300,tcl=3484,lisp=1411,ansic=1364 40831 gd-2.0.33.p5ansic=32741,sh=7625,perl=420,tcl=45 36865 zodb3-3.7.0 python=29676,ansic=7183,sh=6 35272 ecm-6.1.3 ansic=17313,asm=13213,sh=4085,python=661 33854 f2c-20070816ansic=33833,sh=21 32399 mwrank-20070913 cpp=30167,sh=2232 31381 flint-0.2.p4ansic=29483,cpp=1540,python=246,sh=112 30135 readline-5.2ansic=22060,perl=4105,sh=3970 24965 cython-0.9.6.7.a python=21953,ansic=3012 23341 quaddouble-2.2.p7 cpp=8526,sh=8387,fortran=6428 21954 networkx-0.35.1 python=21950,sh=4 21542 scons-0.97 python=21536,sh=6 18624 givaro-3.2.6.p1 cpp=10211,sh=8409,sed=4 18272 ipython-0.8.1.p1 python=17982,lisp=262,sh=28 16862 zlib-1.2.3.p2 ansic=8912,asm=3281,ada=1681,pascal=1089,cpp=1001, cs=879,sh=19 16070 blas-20070724 fortran=16057,sh=13 13989 palp-1.1ansic=13978,sh=11 13519 tachyon-0.98beta.p2 ansic=13445,sh=41,perl=33 12660 gfan-0.2.2.p1 cpp=12637,sh=23 11948 libgpg_error-1.5 sh=8126,ansic=3254,awk=428,lisp=140 10342 pycrypto-2.0.1.p1 ansic=7302,python=3036,sh=4 9769cddlib-094b ansic=9036,sh=733 8974iml-1.0.1.p7ansic=6155,sh=2819 8923libfplll-2.1-20071024 cpp=5437,sh=3486 8151lcalc-20070107 cpp=4580,ansic=3548,sh=23 6771mpfi-1.3.4-rc3.p8 ansic=3960,sh=2811 6037opencdk-0.5.9 ansic=5456,perl=465,sh=116 5912ipython1-20070130 python=5818,ansic=68,sh=26 5491pysqlite-2.3.3 ansic=3377,python=2106,sh=8 4242python_gnutls-1.1.1 python=4213,ansic=23,sh=6 3796sympow-1.018.1.p3 ansic=3367,sh=429 3766weave-0.4.9 python=3760,sh=6 3584sage_scripts-2.8.9.rc1 python=1869,sh=1714,lisp=1 3527gdmodule-0.56.p4 ansic=3316,python=198,sh=13 3015extcode-2.8.9.rc1 objc=2765,java=176,lisp=62,sh=12 2224flintqs-20070817 cpp=1574,ansic=623,sh=27 1975genus2reduction-0.3 ansic=1962,sh=13 1856examples-2.8.9.rc1 python=1792,sh=30,lisp=18,fortran=13,ansic=3 1329pexpect-2.0.p1 python=1322,sh=7 900 termcap-1.3.1 ansic=857,sh=43 140 fortran-20070912 python=130,sh=10 25 elliptic_curves-0.1 sh=25 17 java3d-20070901 sh=17 2 conway_polynomials-0.2 sh=2 2 graphs-20070722 sh=2 Totals grouped by language (dominant language first): ansic: 1907386
[sage-devel] Re: SAGE 2.8.9rc1
So far four issues have popped up:
1) sage-banner is zero bytes in size
2) On x86 linux we have the following failure:
[EMAIL PROTECTED] sage-2.8.9.rc1]$ ./sage -t devel/sage-main/sage/
rings/polynomial/multi_polynomial_ideal.py
sage -t devel/sage-main/sage/rings/polynomial/
multi_polynomial_ideal.py
**
File multi_polynomial_ideal.py, line 1078:
sage: V = I.variety(); V
Expected:
[{y: w^2 + 2, x: 2*w}, {y: w^2 + 2*w, x: 2*w + 2}, {y: w^2 + w, x:
2*w + 1}]
Got:
[{y: w^2 + w, x: 2*w + 1}, {y: w^2 + 2*w, x: 2*w + 2}, {y: w^2 +
2, x: 2*w}]
**
1 items had failures:
1 of 7 in __main__.example_27
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_multi_polynomial_ideal.py
[5.4 s]
exit code: 256
--
3) pretty printing in maxima is broken:
[EMAIL PROTECTED] sage-2.8.9.rc1]$ ./sage -t devel/sage-main/sage/
calculus/equations.py
sage -t devel/sage-main/sage/calculus/equations.py
**
File equations.py, line 12:
sage: print solve(qe, x)
Expected:
[
2
- sqrt(b - 4 a c) - b
x == --
2 a,
2
sqrt(b - 4 a c) - b
x ==
2 a
]
Got:
[x == (-sqrt(b^2 - 4*a*c) - b)/(2*a), x == (sqrt(b^2 - 4*a*c) - b)/
(2*a)]
**
1 items had failures:
1 of 22 in __main__.example_0
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_equations.py
[6.4 s]
exit code: 256
--
The following tests failed:
sage -t devel/sage-main/sage/calculus/equations.py
Total time for all tests: 6.5 seconds
[EMAIL PROTECTED] sage-2.8.9.rc1]$ ./sage -t devel/sage-main/sage/
schemes/elliptic_curves/ell_generic.py
sage -t devel/sage-main/sage/schemes/elliptic_curves/ell_generic.py
**
File ell_generic.py, line 249:
sage: print F.solve(y)
Expected:
[
3 2
- sqrt(4 x - 4 x - 40 x - 79) - 1
y == ---
2,
3 2
sqrt(4 x - 4 x - 40 x - 79) - 1
y == -
2
]
Got:
[y == (-sqrt(4*x^3 - 4*x^2 - 40*x - 79) - 1)/2, y == (sqrt(4*x^3 -
4*x^2 - 40*x - 79) - 1)/2]
**
1 items had failures:
1 of 21 in __main__.example_4
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_ell_generic.py
[5.2 s]
exit code: 256
--
The following tests failed:
sage -t devel/sage-main/sage/schemes/elliptic_curves/
ell_generic.py
Total time for all tests: 5.2 seconds
[EMAIL PROTECTED] sage-2.8.9.rc1]$
All issues have had tickets opened. If you find anything else please
let us know as soon as possible, bonus points for fixes ;)
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] An interactive 2D/3D environment for SAGE
*wow* Croquet is really really neat. I think we're at least another decade away from this sort of interface being workable, but I'd love it if somebody could prove me wrong. Anybody else read Otherland? On Wed, 24 Oct 2007, Timothy Clemans wrote: From: Ted Kosan [EMAIL PROTECTED] Date: Oct 24, 2007 2:01 PM Subject: [sage-support] An interactive 2D/3D environment for SAGE To: [EMAIL PROTECTED] For the past couple of months, I have been researching strategies for extending SAGE with an interactive 2D/3D environment that would be significantly more advanced than what current mathematics software provides. My vision is to be able to place the user into a 3D environment where they can interact with numerous rich mathematics objects that are floating around them in 3D space. So far, the best environment I have come up with is Croquet ( http://opencroquet.org ). Here is a video which shows the basics of how Croquet works: http://www.youtube.com/watch?v=oKi-fkyAtg8 And this video shows Croquet used in an amazing interactive session: http://www.youtube.com/watch?v=2LN5JRl8_sUeurl=http%3A%2F%2Fvideo%2Egreenbush%2Eus%2F%3Frandom%3D Anyway, what do people think about the idea of using Croquet as an interactive 2D/3D environment for SAGE? Ted --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] An interactive 2D/3D environment for SAGE
Timothy, the post you submitted was empty. You may want to resubmit it :-) Ted --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
