[sage-devel] Re: coercing of log(2)*1.0
On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 2, 2008, at 12:55 PM, William Stein wrote: On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish [EMAIL PROTECTED] wrote: -1. First, everything cwitty said is correct. More on this below. Second, if we start using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going through the coercion system which was designed to be elegant instead of fast, so this becomes insanely slow for any serious use. The coercion system is designed to be elegant *and* fast. Writing something like 1 + sqrt(2) is going to require the coercion system no matter what we do, as is 1 + sqrt(2) + 1/2. Computing QQ(sqrt(2), sqrt (3)) may take a millisecond or two, but after that coercion into it from ether ring will be fast. As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Finally, this is going to require serious code duplication from symbolics, so I'm not sure what the big gain is over just using symbolics to do this in the first place. Number field element work completely differently than symbolics, I see little if any code duplication. Fair enough. Also, cwitty pointed out that sage: sum([sqrt(p) for p in prime_range(1000)]) works fine in Sage now, but with your (and my) proposal, it would be impossible, since it would require constructing a ring of integers of a number field of degree 2^168.. This is the biggest argument against such a proposal, and I'm not quite sure how best to handle this. One would have to implement large number fields over sparse polynomials, and only lazily compute the ring of integers. Or, as John Cremona suggested, train users. None of the above are ideal. I would like to give my motivation for not having sqrt(2) be in SR: 1) Speed. I know you're working very hard to make symbolics much, much faster than they currently are, but I still don't think it'll be able to compete in this very specialized domain. Currently: sage: timeit(((1+sqrt(2))^100).expand()) 5 loops, best of 3: 52.9 ms per loop sage: timeit(((1+sqrt(2)+sqrt(3))^50).expand()) 5 loops, best of 3: 579 ms per loop sage: sym_a = sqrt(2) + sqrt(3) sage: timeit(((1+sym_a)^50).expand()) 5 loops, best of 3: 576 ms per loop Compared to sage: K.a = NumberField(x^2-2) sage: timeit(((1+a)^100)) 625 loops, best of 3: 48.4 µs per loop sage: K.a = NumberField(x^4 - 10*x^2 + 1) sage: timeit(((1+a)^50)) 625 loops, best of 3: 138 µs per loop That's over three orders of magnitude faster (and it's *not* due to pexpect/interface overhead as the actual input and output are relatively small). Making arithmetic involving a couple of radicals fast should probably be the most important, especially as one starts making structures over them. Symbolics isn't going to approach number field speed. I think we can do much better then maxima, but its not going to be that much better (maybe if we encapsulate number fields as a special case in SR) 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. 3) The coercion system works best when things start as high up the tree as they can, and the Symbolic Ring is like the big black hole at the bottom that sucks everything in (and makes it slow). There is a coercion from ZZ[sqrt(2)] (with embedding) to SR, but not the other way around, and even trying to cast the other way is problematic. I'd rather that matrix([1, 1/2, 0, sqrt(2)]) land in a matrix space over the a number field (rather than over SR), and ZZ['x'].gen() + sqrt(2) be an actual polynomial in x. Also, the SR, though very useful, somehow seems less rigorous (I'm sure that this is improving). When coercion is faster we can consider changing this. My definition of fast is 10 cycles if the parents are the same, no dictionary lookups if one parent is in the other for all common cases, otherwise reasonablely quick pure Cython code. New and old coercion fail these tests of sufficiently quick, and I'm not waiting to finish symbolics until they do pass those tests. My alternative option is lets throw in a flag, defaults to off (current behavior) that lets you turn on sqrt/powers as in
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 12:09 AM, Gary Furnish wrote: On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 2, 2008, at 12:55 PM, William Stein wrote: On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish [EMAIL PROTECTED] wrote: -1. First, everything cwitty said is correct. More on this below. Second, if we start using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going through the coercion system which was designed to be elegant instead of fast, so this becomes insanely slow for any serious use. The coercion system is designed to be elegant *and* fast. Writing something like 1 + sqrt(2) is going to require the coercion system no matter what we do, as is 1 + sqrt(2) + 1/2. Computing QQ(sqrt(2), sqrt (3)) may take a millisecond or two, but after that coercion into it from ether ring will be fast. As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Not sure what you mean by MI here, could you explain. In any case, just because coercion isn't as fast as it could be doesn't mean that it's not written for speed and much faster than it used to be. Of course there's room for improvement, but right now the focus is trying to finish the new system (which isn't really that new compared to the change made a year ago) in place. Finally, this is going to require serious code duplication from symbolics, so I'm not sure what the big gain is over just using symbolics to do this in the first place. Number field element work completely differently than symbolics, I see little if any code duplication. Fair enough. Also, cwitty pointed out that sage: sum([sqrt(p) for p in prime_range(1000)]) works fine in Sage now, but with your (and my) proposal, it would be impossible, since it would require constructing a ring of integers of a number field of degree 2^168.. This is the biggest argument against such a proposal, and I'm not quite sure how best to handle this. One would have to implement large number fields over sparse polynomials, and only lazily compute the ring of integers. Or, as John Cremona suggested, train users. None of the above are ideal. I would like to give my motivation for not having sqrt(2) be in SR: 1) Speed. I know you're working very hard to make symbolics much, much faster than they currently are, but I still don't think it'll be able to compete in this very specialized domain. Currently: sage: timeit(((1+sqrt(2))^100).expand()) 5 loops, best of 3: 52.9 ms per loop sage: timeit(((1+sqrt(2)+sqrt(3))^50).expand()) 5 loops, best of 3: 579 ms per loop sage: sym_a = sqrt(2) + sqrt(3) sage: timeit(((1+sym_a)^50).expand()) 5 loops, best of 3: 576 ms per loop Compared to sage: K.a = NumberField(x^2-2) sage: timeit(((1+a)^100)) 625 loops, best of 3: 48.4 µs per loop sage: K.a = NumberField(x^4 - 10*x^2 + 1) sage: timeit(((1+a)^50)) 625 loops, best of 3: 138 µs per loop That's over three orders of magnitude faster (and it's *not* due to pexpect/interface overhead as the actual input and output are relatively small). Making arithmetic involving a couple of radicals fast should probably be the most important, especially as one starts making structures over them. Symbolics isn't going to approach number field speed. I think we can do much better then maxima, but its not going to be that much better (maybe if we encapsulate number fields as a special case in SR) I'd rather have them be a number field elements (with all the methods, etc) over providing a wrapping in SR. Otherwise one ends up with something like pari, where everything just sits in the same parent. 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. OK, this is a valid point, though the non-calculus portions (and emphasis) of Sage are (relatively) more significant. Sage is not a CAS, that is just one (important) piece of it. Maple does 1/(1+I); 1/2 - 1/2 I at least. Looking to the M's for ideas is good, but they should not always dictate how we do things--none but Magma has the concept of parents/elements, and Sage uses a very OO model which
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 1:37 AM, John Cremona wrote: MI = Multiple Inheritance? That's the only thing I can think of, but there isn't any of that in the coercion model... - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
MI = Multiple Inheritance? 2008/6/3 Robert Bradshaw [EMAIL PROTECTED]: On Jun 3, 2008, at 12:09 AM, Gary Furnish wrote: On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 2, 2008, at 12:55 PM, William Stein wrote: On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish [EMAIL PROTECTED] wrote: -1. First, everything cwitty said is correct. More on this below. Second, if we start using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going through the coercion system which was designed to be elegant instead of fast, so this becomes insanely slow for any serious use. The coercion system is designed to be elegant *and* fast. Writing something like 1 + sqrt(2) is going to require the coercion system no matter what we do, as is 1 + sqrt(2) + 1/2. Computing QQ(sqrt(2), sqrt (3)) may take a millisecond or two, but after that coercion into it from ether ring will be fast. As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Not sure what you mean by MI here, could you explain. In any case, just because coercion isn't as fast as it could be doesn't mean that it's not written for speed and much faster than it used to be. Of course there's room for improvement, but right now the focus is trying to finish the new system (which isn't really that new compared to the change made a year ago) in place. Finally, this is going to require serious code duplication from symbolics, so I'm not sure what the big gain is over just using symbolics to do this in the first place. Number field element work completely differently than symbolics, I see little if any code duplication. Fair enough. Also, cwitty pointed out that sage: sum([sqrt(p) for p in prime_range(1000)]) works fine in Sage now, but with your (and my) proposal, it would be impossible, since it would require constructing a ring of integers of a number field of degree 2^168.. This is the biggest argument against such a proposal, and I'm not quite sure how best to handle this. One would have to implement large number fields over sparse polynomials, and only lazily compute the ring of integers. Or, as John Cremona suggested, train users. None of the above are ideal. I would like to give my motivation for not having sqrt(2) be in SR: 1) Speed. I know you're working very hard to make symbolics much, much faster than they currently are, but I still don't think it'll be able to compete in this very specialized domain. Currently: sage: timeit(((1+sqrt(2))^100).expand()) 5 loops, best of 3: 52.9 ms per loop sage: timeit(((1+sqrt(2)+sqrt(3))^50).expand()) 5 loops, best of 3: 579 ms per loop sage: sym_a = sqrt(2) + sqrt(3) sage: timeit(((1+sym_a)^50).expand()) 5 loops, best of 3: 576 ms per loop Compared to sage: K.a = NumberField(x^2-2) sage: timeit(((1+a)^100)) 625 loops, best of 3: 48.4 µs per loop sage: K.a = NumberField(x^4 - 10*x^2 + 1) sage: timeit(((1+a)^50)) 625 loops, best of 3: 138 µs per loop That's over three orders of magnitude faster (and it's *not* due to pexpect/interface overhead as the actual input and output are relatively small). Making arithmetic involving a couple of radicals fast should probably be the most important, especially as one starts making structures over them. Symbolics isn't going to approach number field speed. I think we can do much better then maxima, but its not going to be that much better (maybe if we encapsulate number fields as a special case in SR) I'd rather have them be a number field elements (with all the methods, etc) over providing a wrapping in SR. Otherwise one ends up with something like pari, where everything just sits in the same parent. 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. OK, this is a valid point, though the non-calculus portions (and emphasis) of Sage are (relatively) more significant. Sage is not a CAS, that is just one (important) piece of it. Maple does 1/(1+I); 1/2 - 1/2 I at least. Looking to the M's for ideas is good, but they should not always dictate how we do things--none but Magma has the
[sage-devel] Re: coercing of sqrt(2)
Maple does 1/(1+I); 1/2 - 1/2 I Axiom does 1/(1+%i) 1 -- 1 + %i which is of type Fraction Complex Integer, that is a fraction whose numerator and denominator are of type Complex(Integer). You can ask Axiom to place the result in a different type: 1/(1+%i)::Complex Fraction Integer 1 1 - - - %i 2 2 and the type is Complex Fraction Integer, that is a Complex number whose real and imaginary components are Fraction(Integer). The simple form depends on what is canonical for the type. Tim --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] notebook('', secure=true) not working
Hello, Fyi, it seems that the example from sage: notebook? for running your own sage server does not seem to be working. Any insight would be appreciated. Usability suggestions: May I humbly suggest that the use case of I want to run a sage notebook (perhaps remotely) be given higher visibility, for example in the readme, perhaps as its own script, and as a third line when running ./sage in text mode. Thank you, Mats INPUT: sage: notebook(address='', secure=True) RESULT: The notebook files are stored in: /home/mats/.sage//sage_notebook In order to use an SECURE encrypted notebook, you must first run notebook.setup(). Now running notebook.setup() Using dsage certificates. --- ImportError Traceback (most recent call last) /home/mats/.sage/ipython console in module() /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/notebook_object.py in __call__(self, *args, **kwds) 141 142 def __call__(self, *args, **kwds): -- 143 return self.notebook(*args, **kwds) 144 145 notebook = run_notebook.notebook_twisted /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/run_notebook.py in notebook_twisted(self, directory, port, address, port_tries, secure, reset, accounts, require_login, server_pool, ulimit, timeout, open_viewer, sagetex_path, start_path, fork, quiet) 269 if open_viewer: 270 Open viewer automatically isn't fully implemented. You have to manually open your web browser to the above URL. -- 271 return run(port) 272 273 /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/run_notebook.py in run(port) 141 print In order to use an SECURE encrypted notebook, you must first run notebook.setup(). 142 print Now running notebook.setup() -- 143 notebook_setup() 144 if not os.path.exists(private_pem) or not os.path.exists(public_pem): 145 print Failed to setup notebook. Please try notebook.setup() again manually. /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/run_notebook.py in notebook_setup(self) 37 dsage = os.path.join(DOT_SAGE, 'dsage') 38 import sage.dsage.all --- 39 sage.dsage.all.dsage.setup() 40 shutil.copyfile(dsage + '/cacert.pem', private_pem) 41 shutil.copyfile(dsage + '/pubcert.pem', public_pem) /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/dsage/dsage.py in setup(self, template) 312 313 -- 314 from sage.dsage.scripts.dsage_setup import setup 315 setup(template=template) 316 ImportError: No module named dsage_setup --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
I haven't tried it before, but I sneaked a peek and tried to extract the most important information from the website. * The program seems to take a discretized vector field as input, and creates images from these. * Its functionality seems to be - to plot pretty arrows that have a width, size and colour, and are curved along the vector field; - to plot ellipses, which have something to with how much space there would be between arrows. - has two placement strategies for the arrows: 1. hedgehog: the arrows are placed on a regular rectangular grid; 2. adaptive: the arrows are placed with a molecular dynamics (Lennard-Jones) simulation of their bounding ellipses. - to make animations of these * It is a command line tool. * The output is in PostScript. * The input can be SAG : a simpel ASCII grid; GRD2: a pair of GMT(1) grd (netCDF) files representing the components of the vector field; GFS : a simulation file from the Gerris flow solver. * As for now, the license is GPLv3, but one can contact the author for other licensing. * There are Debian libraries for various architectures that can be obtained by - Downloading the deb from http://sview01.wiredworkplace.net/pub/vfplot/debian/pool - Adding deb http://sview01.wiredworkplace.net/pub/vfplot/debian/ testing main to your sources.list. * It is written in C. * It seems to be quite portable, as the program should compile on any modern POSIX operating system with a C99 compiler and there are binaries for quite some architectures. * It reached version 1.0 on Sunday. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
Georg Muntingh wrote: I haven't tried it before, but I sneaked a peek and tried to extract the most important information from the website. * The program seems to take a discretized vector field as input, and creates images from these. * Its functionality seems to be - to plot pretty arrows that have a width, size and colour, and are curved along the vector field; - to plot ellipses, which have something to with how much space there would be between arrows. - has two placement strategies for the arrows: 1. hedgehog: the arrows are placed on a regular rectangular grid; 2. adaptive: the arrows are placed with a molecular dynamics (Lennard-Jones) simulation of their bounding ellipses. - to make animations of these * It is a command line tool. * The output is in PostScript. which can be converted to SVG, PDF and other vector formats with standard tools. The files are small, typically a few tens of kilobytes. * The input can be SAG : a simpel ASCII grid; GRD2: a pair of GMT(1) grd (netCDF) files representing the components of the vector field; GFS : a simulation file from the Gerris flow solver. See: http://gfs.sourceforge.net/wiki/index.php/Main_Page 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
I think it looks pretty neat. It is surprisingly hard to get decent vector field plots for many differential equation examples. I will try to give it a try if I have time. -M. Hampton On Jun 3, 7:19 am, Jaap Spies [EMAIL PROTECTED] wrote: Georg Muntingh wrote: I haven't tried it before, but I sneaked a peek and tried to extract the most important information from the website. * The program seems to take a discretized vector field as input, and creates images from these. * Its functionality seems to be - to plot pretty arrows that have a width, size and colour, and are curved along the vector field; - to plot ellipses, which have something to with how much space there would be between arrows. - has two placement strategies for the arrows: 1. hedgehog: the arrows are placed on a regular rectangular grid; 2. adaptive: the arrows are placed with a molecular dynamics (Lennard-Jones) simulation of their bounding ellipses. - to make animations of these * It is a command line tool. * The output is in PostScript. which can be converted to SVG, PDF and other vector formats with standard tools. The files are small, typically a few tens of kilobytes. * The input can be SAG : a simpel ASCII grid; GRD2: a pair of GMT(1) grd (netCDF) files representing the components of the vector field; GFS : a simulation file from the Gerris flow solver. See:http://gfs.sourceforge.net/wiki/index.php/Main_Page 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Maxima] [sage-devel] Re: Maxima license GPL v.3 or later?
On 6/3/08, Jaime Villate [EMAIL PROTECTED] wrote: so we can continue to develop Maxima as his original author intended to? I will point out that current developers are on much firmer ground if they consider what Bill Schelter did, as opposed to what he was thinking. FWIW Robert Dodier --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
On Tue, Jun 3, 2008 at 6:42 AM, mhampton [EMAIL PROTECTED] wrote: I think it looks pretty neat. It is surprisingly hard to get decent vector field plots for many differential equation examples. I will try to give it a try if I have time. -M. Hampton From Bill Casselman, author of PiScript http://www.math.ubc.ca/~cass/piscript/docs/piscript.html which will likely go into sage at some point: William Stein wrote: Check out this thread. Note that it involves a program that plots using postscript (?) Bill Casselman wrote: It would be pretty easy to add a few routines in PiScript that would do this, too. The current version has outline-able quad-curve arrows. I write from Berlin. if you look at the manual pi.pdf on the page http://www.math.ubc.ca/~cass/piscript/docs/piscript.html you'll see things have changed a lot recently. Quad arrows are on p. 9. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 2:34 AM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 12:09 AM, Gary Furnish wrote: On Mon, Jun 2, 2008 at 11:41 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 2, 2008, at 12:55 PM, William Stein wrote: On Mon, Jun 2, 2008 at 12:53 PM, Gary Furnish [EMAIL PROTECTED] wrote: -1. First, everything cwitty said is correct. More on this below. Second, if we start using ZZ[sqrt(2)] and ZZ[sqrt(3)], then sqrt(2)+sqrt(3) requires going through the coercion system which was designed to be elegant instead of fast, so this becomes insanely slow for any serious use. The coercion system is designed to be elegant *and* fast. Writing something like 1 + sqrt(2) is going to require the coercion system no matter what we do, as is 1 + sqrt(2) + 1/2. Computing QQ(sqrt(2), sqrt (3)) may take a millisecond or two, but after that coercion into it from ether ring will be fast. As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Not sure what you mean by MI here, could you explain. In any case, just because coercion isn't as fast as it could be doesn't mean that it's not written for speed and much faster than it used to be. Of course there's room for improvement, but right now the focus is trying to finish the new system (which isn't really that new compared to the change made a year ago) in place. Sets, and in particular a bunch of the category functionality (homset) get used in coercion, and use MI, making them impossible to cythonize. Finally, this is going to require serious code duplication from symbolics, so I'm not sure what the big gain is over just using symbolics to do this in the first place. Number field element work completely differently than symbolics, I see little if any code duplication. Fair enough. Also, cwitty pointed out that sage: sum([sqrt(p) for p in prime_range(1000)]) works fine in Sage now, but with your (and my) proposal, it would be impossible, since it would require constructing a ring of integers of a number field of degree 2^168.. This is the biggest argument against such a proposal, and I'm not quite sure how best to handle this. One would have to implement large number fields over sparse polynomials, and only lazily compute the ring of integers. Or, as John Cremona suggested, train users. None of the above are ideal. I would like to give my motivation for not having sqrt(2) be in SR: 1) Speed. I know you're working very hard to make symbolics much, much faster than they currently are, but I still don't think it'll be able to compete in this very specialized domain. Currently: sage: timeit(((1+sqrt(2))^100).expand()) 5 loops, best of 3: 52.9 ms per loop sage: timeit(((1+sqrt(2)+sqrt(3))^50).expand()) 5 loops, best of 3: 579 ms per loop sage: sym_a = sqrt(2) + sqrt(3) sage: timeit(((1+sym_a)^50).expand()) 5 loops, best of 3: 576 ms per loop Compared to sage: K.a = NumberField(x^2-2) sage: timeit(((1+a)^100)) 625 loops, best of 3: 48.4 µs per loop sage: K.a = NumberField(x^4 - 10*x^2 + 1) sage: timeit(((1+a)^50)) 625 loops, best of 3: 138 µs per loop That's over three orders of magnitude faster (and it's *not* due to pexpect/interface overhead as the actual input and output are relatively small). Making arithmetic involving a couple of radicals fast should probably be the most important, especially as one starts making structures over them. Symbolics isn't going to approach number field speed. I think we can do much better then maxima, but its not going to be that much better (maybe if we encapsulate number fields as a special case in SR) I'd rather have them be a number field elements (with all the methods, etc) over providing a wrapping in SR. Otherwise one ends up with something like pari, where everything just sits in the same parent. 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. OK, this is a valid point, though the non-calculus portions (and emphasis) of Sage are (relatively) more significant. Sage is not a CAS, that is just one (important) piece of it. Maple does 1/(1+I);
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 7:13 AM, Gary Furnish [EMAIL PROTECTED] wrote: The average calculus student coming from maple is not going to understand why he can't perform a sum of the sqrt of some primes. If we are to be a viable alternative for non-research mathematicians we can't run off and implement things that drastically change the complexity of simple operations. Let me take a moment to totally hijack this thread and say that I think we should drastically change the complexity of simple operations... for the better :-) There's just a *shocking* number of simple operations out there in Maple/Mathematica, etc., which we can and should do much faster in Sage. OK, back to the thread... -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Solaris, libSingular, 1/y and coercion
On Sunday 01 June 2008, mabshoff wrote:
sage: P.x,y=QQ[]
sage: 1/x
More debugging data:
-bash-3.00$ ./sage -gdb
--
| SAGE Version 3.0.1, Release Date: 2008-05-04 |
| Type notebook() for the GUI, and license() for information.|
--
/home/mabshoff/sage-3.0.1-sparc/local/bin/sage-gdb-pythonstartup
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as sparc-sun-solaris2.10...
warning: Lowest section in /lib/libdl.so.1 is .hash at 00b4
Python 2.5.2 (r252:60911, May 29 2008, 21:38:45)
[GCC 4.3.0] on sunos5
Type help, copyright, credits or license for more information.
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074
warning: Lowest section in /lib/libintl.so.1 is .dynamic at 0074
--
| SAGE Version 3.0.1, Release Date: 2008-05-04 |
| Type notebook() for the GUI, and license() for information.|
--
sage: sage: P.x,y=QQ[]
sage: sage: 1/x
Program received signal SIGSEGV, Segmentation fault.
0xf9de7c08 in nlPower (x=0xfa298018, exp=-97976296, u=0x0) at longrat.cc:948
948 *u=(number)omAllocBin(rnumber_bin);
Current language: auto; currently c++
(gdb) bt
#0 0xf9de7c08 in nlPower (x=0xfa298018, exp=-97976296, u=0x0) at
longrat.cc:948
#1 0xfaa91cb4 in
__pyx_f_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular__cmp_c_impl
(__pyx_v_left=0x3180d00, __pyx_v_right=0x3180ad0)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:11201
#2 0xfdf1a9ec in __pyx_f_4sage_9structure_7element_7Element__richcmp_c_impl (
__pyx_v_left=0x3180d00, __pyx_v_right=0x3180ad0, __pyx_v_op=2)
at sage/structure/element.c:4700
#3 0xfdf19d24 in __pyx_f_4sage_9structure_7element_7Element__richcmp
(__pyx_v_left=0x3180d00,
__pyx_v_right=0x3180ad0, __pyx_v_op=2) at sage/structure/element.c:4469
#4 0xfaa8d19c in
__pyx_pf_4sage_5rings_10polynomial_28multi_polynomial_libsingular_23MPolynomial_libsingular___richcmp__
(__pyx_v_left=0x3180d00, __pyx_v_right=0x3180ad0, __pyx_v_op=2)
at sage/rings/polynomial/multi_polynomial_libsingular.cpp:11015
...
(gdb) print *__pyx_v_r
$4 = {idroot = 0x81, order = 0xfa292024, block0 = 0xfa292030, block1 =
0xfa29203c,
parameter = 0x0, minpoly = 0x0, minideal = 0x0, wvhdl = 0xfa292018, names =
0xfa28e018,
options = 100663424, ordsgn = 0xfa292054, typ = 0xfa2840a8, qideal = 0x0,
VarOffset = 0xfa292048, firstwv = 0x0, PolyBin = 0xfa22d618, ch = 0, ref =
0, float_len = 0,
float_len2 = 0, N = 2, P = 0, OrdSgn = 1, firstBlockEnds = 2, VectorOut = 0,
ShortOut = 0,
CanShortOut = 1, LexOrder = 0, MixedOrder = 0, ComponentOrder = -1,
ExpL_Size = 3,
CmpL_Size = 3, VarL_Size = 1, BitsPerExp = 16, ExpPerLong = 2, pCompIndex =
2, pOrdIndex = 0,
OrdSize = 1, VarL_LowIndex = 1, MinExpPerLong = 2, NegWeightL_Size = 0,
NegWeightL_Offset = 0x0, VarL_Offset = 0xfa28e030, bitmask = 65535, divmask
= 65537,
p_Procs = 0xfa286098, pFDeg = 0xf9e2d988 pDeg(spolyrec*, sip_sring*),
pLDeg = 0xf9e2e388 pLDegb(spolyrec*, int*, sip_sring*),
pFDegOrig = 0xf9e2d988 pDeg(spolyrec*, sip_sring*),
pLDegOrig = 0xf9e2e388 pLDegb(spolyrec*, int*, sip_sring*),
p_Setm = 0xf9e2d734 p_Setm_TotalDegree(spolyrec*, sip_sring*), cf =
0xfa294018,
algring = 0x0, nc = 0x0}
(gdb) print *__pyx_v_r-cf
$5 = {next = 0x0, npPrimeM = 0, npPminus1M = 0, npExpTable = 0x0,
npLogTable = 0xf9de32e8,
nMult = 0xf9de497c nlSub(snumber*, snumber*),
nSub = 0xf9de59f8 nlAdd(snumber*, snumber*),
nAdd = 0xf9de8e28 nlDiv(snumber*, snumber*),
nDiv = 0xf9de7f10 nlIntDiv(snumber*, snumber*),
nIntDiv = 0xf9de9524 nlIntMod(snumber*, snumber*),
nIntMod = 0xf9de8640 nlExactDiv(snumber*, snumber*),
nExactDiv = 0xf9de244c nlNew(snumber**),
nNew = 0xf9de289c nlInit(int),
nInit = 0xf9e25894 ndPar(int),
nPar = 0xf9e2591c ndParDeg(snumber*),
nParDeg = 0xf9de2280 nlSize(snumber*),
nSize = 0xf9de794c nlInt(snumber*),
nInt = 0xf9de2a5c nlNeg(snumber*),
nNeg = 0xf9de89b8 nlInvers(snumber*),
nInvers = 0xf9de27cc nlCopy(snumber*),
nCopy = 0xf9e25a58 nd_Copy(snumber*, sip_sring*),
cfCopy = 0xf9de27cc nlCopy(snumber*),
nRePart = 0xf9e258d8 ndReturn0(snumber*),
nImPart = 0xf9dea6e0 nlWrite(snumber*),
nWrite = 0xf9deaab0 nlRead(char const*, snumber**),
nRead = 0xf9de6c7c nlNormalize(snumber*),
nNormalize = 0xf9de4a34 nlGreater(snumber*, snumber*),
nGreater = 0xf9de5e38 nlEqual(snumber*,
[sage-devel] Re: notebook('', secure=true) not working
Apparently this bug is well-known; I got the fix from some kind folks at http://groups.google.com/group/sage-support/browse_thread/thread/a2adf91fd234a548 , for anyone else who is interested. Best wishes, Mats On Jun 3, 8:24 am, Mats [EMAIL PROTECTED] wrote: Hello, Fyi, it seems that the example from sage: notebook? for running your own sage server does not seem to be working. Any insight would be appreciated. Usability suggestions: May I humbly suggest that the use case of I want to run a sage notebook (perhaps remotely) be given higher visibility, for example in the readme, perhaps as its own script, and as a third line when running ./sage in text mode. Thank you, Mats INPUT: sage: notebook(address='', secure=True) RESULT: The notebook files are stored in: /home/mats/.sage//sage_notebook In order to use an SECURE encrypted notebook, you must first run notebook.setup(). Now running notebook.setup() Using dsage certificates. --- ImportError Traceback (most recent call last) /home/mats/.sage/ipython console in module() /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/notebook_object.py in __call__(self, *args, **kwds) 141 142 def __call__(self, *args, **kwds): -- 143 return self.notebook(*args, **kwds) 144 145 notebook = run_notebook.notebook_twisted /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/run_notebook.py in notebook_twisted(self, directory, port, address, port_tries, secure, reset, accounts, require_login, server_pool, ulimit, timeout, open_viewer, sagetex_path, start_path, fork, quiet) 269 if open_viewer: 270 Open viewer automatically isn't fully implemented. You have to manually open your web browser to the above URL. -- 271 return run(port) 272 273 /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/run_notebook.py in run(port) 141 print In order to use an SECURE encrypted notebook, you must first run notebook.setup(). 142 print Now running notebook.setup() -- 143 notebook_setup() 144 if not os.path.exists(private_pem) or not os.path.exists(public_pem): 145 print Failed to setup notebook. Please try notebook.setup() again manually. /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/server/notebook/run_notebook.py in notebook_setup(self) 37 dsage = os.path.join(DOT_SAGE, 'dsage') 38 import sage.dsage.all --- 39 sage.dsage.all.dsage.setup() 40 shutil.copyfile(dsage + '/cacert.pem', private_pem) 41 shutil.copyfile(dsage + '/pubcert.pem', public_pem) /home/mats/install/sage-3.0.2-suse-x86_64-bit-x86_64-Linux/local/lib/ python2.5/site-packages/sage/dsage/dsage.py in setup(self, template) 312 313 -- 314 from sage.dsage.scripts.dsage_setup import setup 315 setup(template=template) 316 ImportError: No module named dsage_setup --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Solaris, libSingular, 1/y and coercion
Malb rocks: [18:30] malb mabshoff|afk : actually in structs.h of Singular there is this logic: [18:31] malb #elif defined(SunOS_5) [18:31] malb // #define HAVE_GENERIC_ADD [18:31] malb #define HAVE_MULT_MOD [18:31] malb #ifdef HAVE_MULT_MOD [18:31] malb #define HAVE_DIV_MOD [18:31] malb #endif [18:34] cwitty wstein, malb: it does look like there are functions in gd.h that can create PNG images in memory [18:34] malb really, cool [18:34] malb compressed and stuff? [18:35] cwitty It looks like you can do anything with a memory buffer that you can do with a file. [18:35] malb which function? [18:36] cwitty gdNewDynamicCtxEx, or gdNewSSCtx [18:42] malb actually gdImagePngPtr might do the job [18:46] malb yep that's it actually [18:47] schilly wow, google finally fixed their discuss-group-rss bugs... so i finally switched to the feeds i originally wanted to use on the new page .. great ;) [18:49] malb mabshoff|afk as a TEST ONLY I've commented that out in your singular spkg and building it now [18:50] malb I have to commute home now, so you might want to try it out [18:51] mabshoff|afk hi malb [18:51] mabshoff|afk w00t [18:51] malb well we don't know yet [18:51] mabshoff|afk Well, it looks promising at least ;) [18:51] malb there must be (a) a reason why this define is there [18:51] malb (b) why it fails, since it doesn't make sense that it is once defined and once not [18:51] mabshoff|afk Well, if it should not blow up instantly I am willing [18:52] mabshoff|afk to get vanilla Singular + test suite and compile and run it with [18:52] mabshoff|afk that patch applied. [18:52] malb maybe SunOS_5 is not always defined? [18:52] mabshoff|afk Well, Singular works on that box and IIRC it is actually set via -D during compile [18:52] mabshoff|afk I.e. it is like their arch flag [18:53] mabshoff|afk maybe on Cygwin it is something similar? [18:53] mabshoff|afk the whole mmap vs. system=malloc might also be a fix. [18:53] malb mhh, maybe [18:53] *** You are now known as mabshoff. [18:53] malb gotta go [18:53] mabshoff np With that fix he alludes to 1/y works ;). I am off to build 3.0.3.alphaX on x86-64 Solaris ;) 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 7:13 AM, Gary Furnish wrote: As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Not sure what you mean by MI here, could you explain. In any case, just because coercion isn't as fast as it could be doesn't mean that it's not written for speed and much faster than it used to be. Of course there's room for improvement, but right now the focus is trying to finish the new system (which isn't really that new compared to the change made a year ago) in place. Sets, and in particular a bunch of the category functionality (homset) get used in coercion, and use MI, making them impossible to cythonize. Ah, yes. Homsets. They're not used anywhere in the critical path though. (If so, that should be fixed.) 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. OK, this is a valid point, though the non-calculus portions (and emphasis) of Sage are (relatively) more significant. Sage is not a CAS, that is just one (important) piece of it. Maple does 1/(1+I); 1/2 - 1/2 I I somewhat ignored (1/1+i) (I agree there is an obvious simplification), but (x+1)^2 shouldn't get simplified under any circumstances. This has (little) do with speed (for this small of exponent) and everything to do with being consistent with the high degree cases and keeping expressions uncluttered. I agree that (x+1)^2 shouldn't get simplified, but for me this has a very different feel than (1+I)^2 or (1+sqrt(2))^2. at least. Looking to the M's for ideas is good, but they should not always dictate how we do things--none but Magma has the concept of parents/elements, and Sage uses a very OO model which differs from all of them. Why doesn't it make sense for Mathematica/Maple? I think it's because they view simplification (or even deciding to simplify) as expensive. 3) The coercion system works best when things start as high up the tree as they can, and the Symbolic Ring is like the big black hole at the bottom that sucks everything in (and makes it slow). There is a coercion from ZZ[sqrt(2)] (with embedding) to SR, but not the other way around, and even trying to cast the other way is problematic. I'd rather that matrix([1, 1/2, 0, sqrt(2)]) land in a matrix space over the a number field (rather than over SR), and ZZ['x'].gen() + sqrt(2) be an actual polynomial in x. Also, the SR, though very useful, somehow seems less rigorous (I'm sure that this is improving). When coercion is faster we can consider changing this. Coercion speed is irrelevant to the issues I mentioned here... and as coercion+number fields is *currently* faster than what you could hope to get with SR (the examples above all involve coercion) it wouldn't help your case either. Only for the sqrt case, and I'm willing to work with that (provided that for endusers, sum(sqrt(p)) behaves as expected. n-th root would have a similar speed increase, but other than those two cases I don't see one wanting algebraic extensions (short of explicitly making a number field). My definition of fast is 10 cycles if the parents are the same, Python semantics tie our hands a bit here, but I think we're about as close as we can get. no dictionary lookups if one parent is in the other for all common cases, Would this mean hard-coding all common paths? Currently there is a single dictionary lookup for common cases (and not a Python dict). Common cases should be no more then a virtual call and a few if statements away (and not a bunch of virtual calls either. They cost performance too. No more then one should be necessary for the common case (the code to handle this can probably go in the addition/multiplication handlers)). Then if that fails we can take the cached dict lookup route. Make the common case fast at the expense of the uncommon case. I am -1 for hard-coding knowledge and logic about ZZ, QQ, RR, RDF, CC, CDF, ... into the coercion model. otherwise reasonablely quick pure Cython code. Yes, it should be fast, but only has to be done once and then it's cached. Of course the code specific to the
[sage-devel] bug: jsmath doesn't like modeshift
Fyi, a bug report severity: unimportant Not sure if this is a jsmath bug or a firefox bug... I'm using Linux and remapped caps_lock to be modeshift, and modeshift +k to be the down arrow. When autocompleting, hitting modeshift will cancel the autocomplete box, when in fact I just want to hit modeshift- k to select an autocompletion. --Mats --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Tue, Jun 3, 2008 at 3:09 AM, Gary Furnish [EMAIL PROTECTED] wrote: snip Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. Hmm, I must say from using maple on expressions like this, I found the answers that it gave were completely pointless at times, and I was forced to run expand and simplify many times, and use many tricks to get the answer in the most simplified form. At times, the easiest way was to evaluate the expressions, and then use LLL to get the expression back. Admittedly I am a number theorist, although at the time when I was using maple extensively, I was still in undergrad. When I started using MAGMA, the learning curve seemed considerably higher, but completely worth the trouble for algebraic expressions. The current proposal by Robert seems to be the best of both world for my taste. (And I agree with him that a lot of it is a matter of taste.) As an aside, one of my gripes teaching calculus is that the students don't simplify expressions like sqrt(2)sqrt(3) or 1/(1+i), and I would prefer if SAGE doesn't contribute to such atrocity. :) Soroosh --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
William Stein wrote: On Tue, Jun 3, 2008 at 6:42 AM, mhampton [EMAIL PROTECTED] wrote: I think it looks pretty neat. It is surprisingly hard to get decent vector field plots for many differential equation examples. I will try to give it a try if I have time. -M. Hampton From Bill Casselman, author of PiScript http://www.math.ubc.ca/~cass/piscript/docs/piscript.html which will likely go into sage at some point: William Stein wrote: Check out this thread. Note that it involves a program that plots using postscript (?) Note that this program has limited scope: The vfplot program plots only arrows, it will not be a general purpose plotting program 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 12:11 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote: I think we had a discussion on irc about how homsets still got used for determining the result of something in parent1 op something in parent2 (maybe it was with someone else?) I sure hope not. If so, that needs to change (but I'm pretty sure it isn't). Well allegedly there is some function that computes what parent something is in if you have parent1 op parentt2 that is new in this system (but I can't find said function). Allegedly said function has to use Homsets, so performance is going to be horrible(and this makes sense, because its what I have to use now). I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out. That sounds much better, though I'm still not a fan. Sure, its kindof ugly, but it will give us the performance we need, and I don't see a better way to allow us to use coercions all over the place without having performance drop to 0. On Tue, Jun 3, 2008 at 11:48 AM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 7:13 AM, Gary Furnish wrote: As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Not sure what you mean by MI here, could you explain. In any case, just because coercion isn't as fast as it could be doesn't mean that it's not written for speed and much faster than it used to be. Of course there's room for improvement, but right now the focus is trying to finish the new system (which isn't really that new compared to the change made a year ago) in place. Sets, and in particular a bunch of the category functionality (homset) get used in coercion, and use MI, making them impossible to cythonize. Ah, yes. Homsets. They're not used anywhere in the critical path though. (If so, that should be fixed.) 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. OK, this is a valid point, though the non-calculus portions (and emphasis) of Sage are (relatively) more significant. Sage is not a CAS, that is just one (important) piece of it. Maple does 1/(1+I); 1/2 - 1/2 I I somewhat ignored (1/1+i) (I agree there is an obvious simplification), but (x+1)^2 shouldn't get simplified under any circumstances. This has (little) do with speed (for this small of exponent) and everything to do with being consistent with the high degree cases and keeping expressions uncluttered. I agree that (x+1)^2 shouldn't get simplified, but for me this has a very different feel than (1+I)^2 or (1+sqrt(2))^2. at least. Looking to the M's for ideas is good, but they should not always dictate how we do things--none but Magma has the concept of parents/elements, and Sage uses a very OO model which differs from all of them. Why doesn't it make sense for Mathematica/Maple? I think it's because they view simplification (or even deciding to simplify) as expensive. 3) The coercion system works best when things start as high up the tree as they can, and the Symbolic Ring is like the big black hole at the bottom that sucks everything in (and makes it slow). There is a coercion from ZZ[sqrt(2)] (with embedding) to SR, but not the other way around, and even trying to cast the other way is problematic. I'd rather that matrix([1, 1/2, 0, sqrt(2)]) land in a matrix space over the a number field (rather than over SR), and ZZ['x'].gen() + sqrt(2) be an actual polynomial in x. Also, the SR, though very useful, somehow seems less rigorous (I'm sure that this is improving). When coercion is faster we can consider changing this. Coercion speed is irrelevant to the issues I mentioned here... and as coercion+number fields is *currently* faster than what you could hope to get with SR (the examples above
[sage-devel] Re: coercing of log(2)*1.0
When I personally use Mathematica etc, I often don't expand expressions x^20+20*x^19+. doesn't tell me much about where an expression comes from. (x+5)^20 tells me a bunch. Expanding expressions generally causes information loss for many calculus and physics problems and going overboard can be bad (although this isn't an issue for number theory). Furthermore sqrt(2)sqrt(3) is not necessarily equal to sqrt(6), so not simplifying there is appropriate in most circumstances. On Tue, Jun 3, 2008 at 11:28 AM, Soroosh Yazdani [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 3:09 AM, Gary Furnish [EMAIL PROTECTED] wrote: snip Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. Hmm, I must say from using maple on expressions like this, I found the answers that it gave were completely pointless at times, and I was forced to run expand and simplify many times, and use many tricks to get the answer in the most simplified form. At times, the easiest way was to evaluate the expressions, and then use LLL to get the expression back. Admittedly I am a number theorist, although at the time when I was using maple extensively, I was still in undergrad. When I started using MAGMA, the learning curve seemed considerably higher, but completely worth the trouble for algebraic expressions. The current proposal by Robert seems to be the best of both world for my taste. (And I agree with him that a lot of it is a matter of taste.) As an aside, one of my gripes teaching calculus is that the students don't simplify expressions like sqrt(2)sqrt(3) or 1/(1+i), and I would prefer if SAGE doesn't contribute to such atrocity. :) Soroosh --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote: I think we had a discussion on irc about how homsets still got used for determining the result of something in parent1 op something in parent2 (maybe it was with someone else?) I sure hope not. If so, that needs to change (but I'm pretty sure it isn't). I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out. That sounds much better, though I'm still not a fan. On Tue, Jun 3, 2008 at 11:48 AM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 7:13 AM, Gary Furnish wrote: As long as there are classes in pure python that use MI on the critical path that symbolics has to use, the argument that coercion was written to be fast makes no sense to me. Not sure what you mean by MI here, could you explain. In any case, just because coercion isn't as fast as it could be doesn't mean that it's not written for speed and much faster than it used to be. Of course there's room for improvement, but right now the focus is trying to finish the new system (which isn't really that new compared to the change made a year ago) in place. Sets, and in particular a bunch of the category functionality (homset) get used in coercion, and use MI, making them impossible to cythonize. Ah, yes. Homsets. They're not used anywhere in the critical path though. (If so, that should be fixed.) 2) I personally don't like having to sprinkle the expand and and/or simplify all over the place. Now I don't think symbolics should be expanded automatically, but stuff like (1+sqrt(2))^2 should be or 1/(1 +i). It's like just getting the question back. (I guess I'm revealing my bias that I don't think of it as living in SR, but rather a number field...) On that note, I can't even figure out how to do simplify (sqrt(2)-3)/(sqrt(2)-1) in the symbolics...as opposed to sage: K.sqrt2 = NumberField(x^2-2) sage: (sqrt2-3)/(sqrt2-1) -2*sqrt2 - 1 sage: 1/(sqrt2-1) sqrt2 + 1 Your going to have a hard time convincing me that the default behavior in Mathematica and Maple is wrong. This makes sense for number theory but not for people using calculus. OK, this is a valid point, though the non-calculus portions (and emphasis) of Sage are (relatively) more significant. Sage is not a CAS, that is just one (important) piece of it. Maple does 1/(1+I); 1/2 - 1/2 I I somewhat ignored (1/1+i) (I agree there is an obvious simplification), but (x+1)^2 shouldn't get simplified under any circumstances. This has (little) do with speed (for this small of exponent) and everything to do with being consistent with the high degree cases and keeping expressions uncluttered. I agree that (x+1)^2 shouldn't get simplified, but for me this has a very different feel than (1+I)^2 or (1+sqrt(2))^2. at least. Looking to the M's for ideas is good, but they should not always dictate how we do things--none but Magma has the concept of parents/elements, and Sage uses a very OO model which differs from all of them. Why doesn't it make sense for Mathematica/Maple? I think it's because they view simplification (or even deciding to simplify) as expensive. 3) The coercion system works best when things start as high up the tree as they can, and the Symbolic Ring is like the big black hole at the bottom that sucks everything in (and makes it slow). There is a coercion from ZZ[sqrt(2)] (with embedding) to SR, but not the other way around, and even trying to cast the other way is problematic. I'd rather that matrix([1, 1/2, 0, sqrt(2)]) land in a matrix space over the a number field (rather than over SR), and ZZ['x'].gen() + sqrt(2) be an actual polynomial in x. Also, the SR, though very useful, somehow seems less rigorous (I'm sure that this is improving). When coercion is faster we can consider changing this. Coercion speed is irrelevant to the issues I mentioned here... and as coercion+number fields is *currently* faster than what you could hope to get with SR (the examples above all involve coercion) it wouldn't help your case either. Only for the sqrt case, and I'm willing to work with that (provided that for endusers, sum(sqrt(p)) behaves as expected. n-th root would have a similar speed increase, but other than those two cases I don't see one wanting algebraic extensions (short of explicitly making a number field). My definition of fast is 10 cycles if the parents are the same, Python semantics tie our hands a bit here, but I think we're about as close as we can get. no dictionary lookups if one parent is in the other for all common cases, Would this mean hard-coding all common paths? Currently there is a single dictionary lookup for common
[sage-devel] Re: coercing of log(2)*1.0
On 31 Mai, 15:59, William Stein [EMAIL PROTECTED] wrote: At a bare minimum there is never a canonical (automatic) coercion from elements of R to elements of S unless that coercion is defined (as a homomorphism) on all of R. I dont want to be heretical by why is it so important that coercion is totally defined? Considering all the current discussion, I get the impression that allowing partial coercion would solve much of the arising problems nearly without effort. SR can be easily partially coerced to any number system. Just try to evaluate the SR term in that number system. Either it succeeds for example log(2) or sqrt(2) directly translates to RR by log(RR(2)) and sqrt(RR(2)) or it fails, for example RR(x) or RR(1)/RR(0). While sqrt(RR(-2)) is somehow mixed, depending on the sign of the argument sqrt returns either something of a complex or a real field. Which is quite desirable. So that means if one would try to coerce from SR to RR it can happen that the result is a CC, what however would perfectly fit, i.e. would perfectly be what one expects when one writes: sqrt(-2)*1.0. I hope everyone agrees that the above two (but at least the above first) paragraph(s) is what one would expect/desire. Then for coercion would only matter the exactness of a structure and the subset relation. The general rule would be: If there one structure is less exact then coerce to this structure. If we have two structures with equal exactness coerce to the substructure if possible, in doubt coerce to the superstructure. This would also solve the performance and representation issue. As long as no coercing takes places just compute in whatever Ring you want. But if it comes to coercion/evaluation/decision it may take somewhat longer (what also would be what I expect). --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: vfplot
I just checked out PiScript, and I think it would be a powerful backend for this kind of, and many other, functionality. I created an example picture with PiScript that one can find at http://folk.uio.no/georgmu/Superformula.eps and http://folk.uio.no/georgmu/Superformula.py . Of course as Marshall remarked this means that one should still implement an algorithm that determines where to draw arrows that will give a decent plot, which has already been done in vfplot. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: On Tue, Jun 3, 2008 at 12:11 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote: I think we had a discussion on irc about how homsets still got used for determining the result of something in parent1 op something in parent2 (maybe it was with someone else?) I sure hope not. If so, that needs to change (but I'm pretty sure it isn't). Well allegedly there is some function that computes what parent something is in if you have parent1 op parentt2 that is new in this system (but I can't find said function). Allegedly said function has to use Homsets, so performance is going to be horrible(and this makes sense, because its what I have to use now). When a new morphism is created it needs a parent, which is a Homset that may be looked up/created at that time. This is probably what you are talking about. However, this is a single (tiny) constant overhead over the entire runtime of Sage. I'm sure this could be further optimized, but creating all the homsets ZZ - QQ - RR - CC, etc. will be done long before any symbolic code gets hit. I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out. That sounds much better, though I'm still not a fan. Sure, its kindof ugly, but it will give us the performance we need, and I don't see a better way to allow us to use coercions all over the place without having performance drop to 0. One may be able to eek out a bit more performance by doing this, but it's not as if performance is awful in the current model. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of log(2)*1.0
On Jun 3, 2008, at 12:22 PM, Henryk Trappmann wrote: On 31 Mai, 15:59, William Stein [EMAIL PROTECTED] wrote: At a bare minimum there is never a canonical (automatic) coercion from elements of R to elements of S unless that coercion is defined (as a homomorphism) on all of R. I dont want to be heretical by why is it so important that coercion is totally defined? Considering all the current discussion, I get the impression that allowing partial coercion would solve much of the arising problems nearly without effort. SR can be easily partially coerced to any number system. Just try to evaluate the SR term in that number system. Either it succeeds for example log(2) or sqrt(2) directly translates to RR by log(RR(2)) and sqrt(RR(2)) or it fails, for example RR(x) or RR(1)/RR(0). While sqrt(RR(-2)) is somehow mixed, depending on the sign of the argument sqrt returns either something of a complex or a real field. Which is quite desirable. So that means if one would try to coerce from SR to RR it can happen that the result is a CC, what however would perfectly fit, i.e. would perfectly be what one expects when one writes: sqrt(-2)*1.0. I hope everyone agrees that the above two (but at least the above first) paragraph(s) is what one would expect/desire. Then for coercion would only matter the exactness of a structure and the subset relation. The general rule would be: If there one structure is less exact then coerce to this structure. If we have two structures with equal exactness coerce to the substructure if possible, in doubt coerce to the superstructure. This would also solve the performance and representation issue. As long as no coercing takes places just compute in whatever Ring you want. But if it comes to coercion/evaluation/decision it may take somewhat longer (what also would be what I expect). This is a good question, and has been extensively discussed before, but I will try and justify it a bit here. In Sage there are two kinds of conversions from one ring to another: casting and coercion. If I have an element a in S, and I want to view it as an element in R, I can write R(a). This should work whenever it's possible to make sense of a in R. Coercion, on the other hand, is implicit and thus should be fairly conservative. To reduce ambiguity, it should also go exactly one direction (unless, perhaps, there is a canonical isomorphism). It makes more sense for there to be a coercion RR - SR than the other way around, so that when one writes sqrt(x) * 2.4 it tries to give a result in SR rather than an error due to failure to give a result in RR. I'm not sure how allowing partial coercions would help the situation. The problems are (1) given a and b in different rings, how to quickly find a' and b' so that a' + b' makes sense and dispatch to that operation and (2) whether or not sqrt(2) should start out as a SR object, or something more specific the same way integers and rationals do, and then coerced down to SR if need be. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 4:48 PM, Robert Bradshaw wrote: On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: ... I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. Absolutely! :-) BTW, where can I read more about these categorical concepts that are currently built-in or planned for Sage? Regards, Bill Page. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 2:45 PM, Bill Page [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 4:48 PM, Robert Bradshaw wrote: On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: ... I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. Absolutely! :-) BTW, where can I read more about these categorical concepts that are currently built-in or planned for Sage? This is very relevant: http://wiki.sagemath.org/days7/coercion 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: On Tue, Jun 3, 2008 at 12:11 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 11:06 AM, Gary Furnish wrote: I think we had a discussion on irc about how homsets still got used for determining the result of something in parent1 op something in parent2 (maybe it was with someone else?) I sure hope not. If so, that needs to change (but I'm pretty sure it isn't). Well allegedly there is some function that computes what parent something is in if you have parent1 op parentt2 that is new in this system (but I can't find said function). Allegedly said function has to use Homsets, so performance is going to be horrible(and this makes sense, because its what I have to use now). When a new morphism is created it needs a parent, which is a Homset that may be looked up/created at that time. This is probably what you are talking about. However, this is a single (tiny) constant overhead over the entire runtime of Sage. I'm sure this could be further optimized, but creating all the homsets ZZ - QQ - RR - CC, etc. will be done long before any symbolic code gets hit. This is not what I'm talking about. What I'm talking about is you can't access members of homset without leaving cython and using python. I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. No, I consider categories to be good. I consider bad implementations of categories to be bad. Implementations that make extensive use of MI and are thus impossible to cythonize or access without py dict lookups are not good implementations of categories. If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), I would be significantly less upset with it then I am now where people tell me that if I need more speed I'm out of luck. I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out. That sounds much better, though I'm still not a fan. Sure, its kindof ugly, but it will give us the performance we need, and I don't see a better way to allow us to use coercions all over the place without having performance drop to 0. One may be able to eek out a bit more performance by doing this, but it's not as if performance is awful in the current model. For the things you do. There is no code that pushes the coercion system anywhere near as much as symbolics in Sage does. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 3:08 PM, Gary Furnish wrote: On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: When a new morphism is created it needs a parent, which is a Homset that may be looked up/created at that time. This is probably what you are talking about. However, this is a single (tiny) constant overhead over the entire runtime of Sage. I'm sure this could be further optimized, but creating all the homsets ZZ - QQ - RR - CC, etc. will be done long before any symbolic code gets hit. This is not what I'm talking about. What I'm talking about is you can't access members of homset without leaving cython and using python. Of course homsets could be optimized, but once created they aren't used in the coercion itself. I don't know why you'd need to access the members of homset unless you were doing some very high-level programming. The domain and codomain are cdef attributes of Morphisms, which are in Cython (and that took a fair amount of work as they was a lot of MI going on with them until a year ago). I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. No, I consider categories to be good. I consider bad implementations of categories to be bad. Implementations that make extensive use of MI and are thus impossible to cythonize or access without py dict lookups are not good implementations of categories. That depends on what they are being used for, but categories lend themselves very naturally to multiple inheritance because of what they are mathematically. I understand wanting, .e.g., arithmetic to be super fast, but I don't see the gain in hacks/code duplication to strip out multiple inheritance from and cythonize categories. Python is a beautiful language, but it comes with a cost (e.g. dict lookups). Other than initial homset creation, what would be faster (for you) if homsets and categories were written in Cython? If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), The critical path for doing arithmetic between elements is 100% pure Cython code. The path for discovering coercions has Python in it, but until (if ever) all Parents are re-written in Cython this isn't going to be fully optimal anyways. And it only happens once (compared to the old model where it happened every single time a coercion was needed). Of course, much of the discover part could and should be optimized. But right now we've already got enough on our plate trying to get the changes we have pushed through. (Any help on this front would be greatly appreciated.) I would be significantly less upset with it then I am now where people tell me that if I need more speed I'm out of luck. That's not the message I'm trying to send--I'm sure there's room for improvement (though I have a strong distaste for hard-coding special cases in all over the place). I don't think make everything Cython is going to solve the problem... I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out. That sounds much better, though I'm still not a fan. Sure, its kindof ugly, but it will give us the performance we need, and I don't see a better way to allow us to use coercions all over the place without having performance drop to 0. One may be able to eek out a bit more performance by doing this, but it's not as if performance is awful in the current model. For the things you do. There is no code that pushes the coercion system anywhere near as much as symbolics in Sage does. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
One may be able to eek out a bit more performance by doing this, but it's not as if performance is awful in the current model. For the things you do. There is no code that pushes the coercion system anywhere near as much as symbolics in Sage does. Please explain why the symbolics code is any more taxing on the coercion system than the existing code. Nick --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: more licensing discussion - Blender
I have a small grant this summer to work on 3D visualization of geometric-algebraic objects (e.g. Groebner fans), and I have decided to learn the basics of Blender. Its amazingly small and very python friendly, so hopefully I can get some experience interfacing with it with Sage. -M. Hampton On May 30 2007, 12:18 am, William Stein [EMAIL PROTECTED] wrote: On 5/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Man, typed faster than I read. There's no free lunch. Or polytopes. Regardless, YafRay is more promising than I originally thought. If only we could get John Stone to work with the YafRay people. His parallelism round objects with their beautiful textures meshes... My impression is that YafRay also has extensive support for parallelism. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: more licensing discussion - Blender
I would like to learn a bit about Blender too. If you have a book you'd recommend, please let me know. On Tue, Jun 3, 2008 at 7:28 PM, Marshall Hampton [EMAIL PROTECTED] wrote: I have a small grant this summer to work on 3D visualization of geometric-algebraic objects (e.g. Groebner fans), and I have decided to learn the basics of Blender. Its amazingly small and very python friendly, so hopefully I can get some experience interfacing with it with Sage. -M. Hampton On May 30 2007, 12:18 am, William Stein [EMAIL PROTECTED] wrote: On 5/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Man, typed faster than I read. There's no free lunch. Or polytopes. Regardless, YafRay is more promising than I originally thought. If only we could get John Stone to work with the YafRay people. His parallelism round objects with their beautiful textures meshes... My impression is that YafRay also has extensive support for parallelism. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 4:39 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 3:08 PM, Gary Furnish wrote: On Tue, Jun 3, 2008 at 2:48 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: When a new morphism is created it needs a parent, which is a Homset that may be looked up/created at that time. This is probably what you are talking about. However, this is a single (tiny) constant overhead over the entire runtime of Sage. I'm sure this could be further optimized, but creating all the homsets ZZ - QQ - RR - CC, etc. will be done long before any symbolic code gets hit. This is not what I'm talking about. What I'm talking about is you can't access members of homset without leaving cython and using python. Of course homsets could be optimized, but once created they aren't used in the coercion itself. I don't know why you'd need to access the members of homset unless you were doing some very high-level programming. The domain and codomain are cdef attributes of Morphisms, which are in Cython (and that took a fair amount of work as they was a lot of MI going on with them until a year ago). I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. No, I consider categories to be good. I consider bad implementations of categories to be bad. Implementations that make extensive use of MI and are thus impossible to cythonize or access without py dict lookups are not good implementations of categories. That depends on what they are being used for, but categories lend themselves very naturally to multiple inheritance because of what they are mathematically. I understand wanting, .e.g., arithmetic to be super fast, but I don't see the gain in hacks/code duplication to strip out multiple inheritance from and cythonize categories. Python is a beautiful language, but it comes with a cost (e.g. dict lookups). Other than initial homset creation, what would be faster (for you) if homsets and categories were written in Cython? If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), The critical path for doing arithmetic between elements is 100% pure Cython code. The path for discovering coercions has Python in it, but until (if ever) all Parents are re-written in Cython this isn't going to be fully optimal anyways. And it only happens once (compared to the old model where it happened every single time a coercion was needed). But I don't have elements, I have variables that represent elements. Maybe the solution here is to run an_element on each parent and then multiply them (and in fact I do this as a last case resort) and then get the parent of the result, but this is a pretty bad way to do things as it requires construction of elements during coercion. Furthermore, this isn't even implemented in some classes, the default is written in python, etc. Even if those issues were dealt with, having to multiply two elements to figure out where the result is a bad design. Of course, much of the discover part could and should be optimized. But right now we've already got enough on our plate trying to get the changes we have pushed through. (Any help on this front would be greatly appreciated.) I would be significantly less upset with it then I am now where people tell me that if I need more speed I'm out of luck. That's not the message I'm trying to send--I'm sure there's room for improvement (though I have a strong distaste for hard-coding special cases in all over the place). I don't think make everything Cython is going to solve the problem... No but special cases/writing my own fast coercion code seems to work significantly better then trying to use your system. This is definitely a bad situation, because we shouldn't need another set of coercion codes that deal with the cases where the main coercion code is too slow. Either coercion has to be designed to be fast, or symbolics is going to have to reach into the innards of the coercion framework to make it possible to deal with quickly. It would be even better if we could have symbolicring over RR or symbolicring over ZZ or what not, but this is 100% impossible unless the coercion framework is done 100% in cython, with special cases, with speed as a top priority instead of beauty. I'm also -1 for hard-coding knowledge and logic about ZZ,QQ, etc into the coercion model. I am +1 for hardcoding it into the elements of say, ZZ,QQ,RR and then having them call the coercion model only if those hardcodes can't figure the situation out. That sounds much better, though I'm still not a fan. Sure, its kindof ugly, but it will give us the performance we need, and I don't see a better way to allow us to use coercions all over the place without having
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 5:48 PM, William Stein wrote: On Tue, Jun 3, 2008 at 2:45 PM, Bill Page wrote: On Tue, Jun 3, 2008 at 4:48 PM, Robert Bradshaw wrote: On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: ... I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. Absolutely! :-) BTW, where can I read more about these categorical concepts that are currently built-in or planned for Sage? This is very relevant: http://wiki.sagemath.org/days7/coercion Thanks for the reference. No mention of homsets here. :-( Only one mention in /days7/coercion/todo ... But reading this makes me feel a little, well ah, light-headed. At best it seems like something very hastily grafted-on to the design. Is this part of Sage about which you would like comments and more discussion? Or is there more information somewhere that I am missing? I am afraid that there is not much here that category theorists are likely to find interesting. I have many many questions, but mostly I wonder what the overall intention of this construction really is in Sage? Is it only relevant to coercion? How does it related to the concept of parent - which seems equally ill-defined to me? What is the relationship to inheritance in Python? Is the intention to give all mathematical objects defined in Sage some categorical structure? What about categories themselves as mathematical structures - e.g. a category is a kind of directed graph with additional structure? Regards, Bill Page. --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 4, 12:39 am, Robert Bradshaw [EMAIL PROTECTED] wrote: SNIP Hi, If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), The critical path for doing arithmetic between elements is 100% pure Cython code. The path for discovering coercions has Python in it, but until (if ever) all Parents are re-written in Cython this isn't going to be fully optimal anyways. And it only happens once (compared to the old model where it happened every single time a coercion was needed). Of course, much of the discover part could and should be optimized. But right now we've already got enough on our plate trying to get the changes we have pushed through. (Any help on this front would be greatly appreciated.) I have to side with Robert here. Symbolics is not going to get merged before the coercion rewrite since the coercion rewrite has been going on much longer and there is substantial effort in there that is also highly desired by the sage-combinat people for example. Once coercion is in [hopefully around Dev1] it is desired to improve the existing code [I am not qualified to speculate here what can and will be done in that regard] and I am sure that Robert, Gary and everybody else interested will find some time during Dev1 to sit down and look at the code together to come up with a workable solution. Sage is about incremental improvements and we should remember: The perfect is the enemy of the good ;) I know very, very well that Gary is very serious about performance and that what he considers fast is way beyond the normal expectation. His effort to achieve this is beyond what most people would consider reasonable and I am very glad he is working on Symbolics ;) So let's not get into an intense discussion here and now since that will not resolve any problem. SNIP 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: more licensing discussion - Blender
Its funny you ask - I'm something of a book addict, so my first thought was to buy some books on blender. But (as with Sage!) there really is plenty of documentation and tutorials on the web. You just have to wade in and start doing them, and it takes time. I'm not sure there is a whole lot out there on the sort of python scripting I want to do, but whatever is out there is probably online. If anyone out there thinks that there is a useful book on blender (especially if it has some content relating to python), please weigh in. -M. Hampton On Jun 3, 6:32 pm, David Joyner [EMAIL PROTECTED] wrote: I would like to learn a bit about Blender too. If you have a book you'd recommend, please let me know. On Tue, Jun 3, 2008 at 7:28 PM, Marshall Hampton [EMAIL PROTECTED] wrote: I have a small grant this summer to work on 3D visualization of geometric-algebraic objects (e.g. Groebner fans), and I have decided to learn the basics of Blender. Its amazingly small and very python friendly, so hopefully I can get some experience interfacing with it with Sage. -M. Hampton On May 30 2007, 12:18 am, William Stein [EMAIL PROTECTED] wrote: On 5/29/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Man, typed faster than I read. There's no free lunch. Or polytopes. Regardless, YafRay is more promising than I originally thought. If only we could get John Stone to work with the YafRay people. His parallelism round objects with their beautiful textures meshes... My impression is that YafRay also has extensive support for parallelism. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: more licensing discussion - Blender
On Tue, Jun 3, 2008 at 4:28 PM, Marshall Hampton [EMAIL PROTECTED] wrote: I have a small grant this summer to work on 3D visualization of geometric-algebraic objects (e.g. Groebner fans), and I have decided to learn the basics of Blender. Its amazingly small and very python friendly, so hopefully I can get some experience interfacing with it with Sage. Hi, I'm just curious why you call Blender Amazingly small? I looked into blender a lot for Sage, when we were looking very hard for a suitable 3d rendering system. It's not amazingy small in my opinion. It's source distribution is so big it would be bigger than anything else in Sage. I'm not knocking blender at all -- it's a great program. I'm just curious what you meant. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 4:36 PM, Gary Furnish wrote: That depends on what they are being used for, but categories lend themselves very naturally to multiple inheritance because of what they are mathematically. I understand wanting, .e.g., arithmetic to be super fast, but I don't see the gain in hacks/code duplication to strip out multiple inheritance from and cythonize categories. Python is a beautiful language, but it comes with a cost (e.g. dict lookups). Other than initial homset creation, what would be faster (for you) if homsets and categories were written in Cython? If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), The critical path for doing arithmetic between elements is 100% pure Cython code. The path for discovering coercions has Python in it, but until (if ever) all Parents are re-written in Cython this isn't going to be fully optimal anyways. And it only happens once (compared to the old model where it happened every single time a coercion was needed). But I don't have elements, I have variables that represent elements. Maybe the solution here is to run an_element on each parent and then multiply them (and in fact I do this as a last case resort) and then get the parent of the result, but this is a pretty bad way to do things as it requires construction of elements during coercion. Furthermore, this isn't even implemented in some classes, the default is written in python, etc. Even if those issues were dealt with, having to multiply two elements to figure out where the result is a bad design. Ah, yes. We talked about this before, and I implemented the analyse and explain functions which carefully avoid all Python: http://cython.org/coercion/hgwebdir.cgi/sage-coerce/rev/1a5c8ccfd0df Of course, much of the discover part could and should be optimized. But right now we've already got enough on our plate trying to get the changes we have pushed through. (Any help on this front would be greatly appreciated.) I would be significantly less upset with it then I am now where people tell me that if I need more speed I'm out of luck. That's not the message I'm trying to send--I'm sure there's room for improvement (though I have a strong distaste for hard-coding special cases in all over the place). I don't think make everything Cython is going to solve the problem... No but special cases/writing my own fast coercion code seems to work significantly better then trying to use your system. Writing a huge number of special cases is almost always going to be faster, not doubt about it. The Sage coercion code needs to be extremely generic as it handles all kinds of objects (and I'm excited to have symbolics that respect this). This is definitely a bad situation, because we shouldn't need another set of coercion codes that deal with the cases where the main coercion code is too slow. Yes. Either coercion has to be designed to be fast, or symbolics is going to have to reach into the innards of the coercion framework to make it possible to deal with quickly. It would be even better if we could have symbolicring over RR or symbolicring over ZZ or what not, but this is 100% impossible unless the coercion framework is done 100% in cython, with special cases, with speed as a top priority instead of beauty. Would it be 95% possible if it's 95% written in Cython, with only a 5% performance hit :-). The best balance I see is you can hard code ZZ/RR/... for speed if you want (you're worried about virtual function calls anyways), and then call off to coercion in the generic cases. You're going to have to do this a bit anyways, as the coercion model doesn't handle stuff like where is the sin(x) if x is in R? which is handled via the normal OO sense based on the type of x (and may depend on x). To help with collaboration, what you want out of the coercion model is, given R and S (and an operation op), what will be the result of op between elements of R and S, and you want this to be as fast as possible (e.g. 100% Cython, no homsets, ...). - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Tue, Jun 3, 2008 at 7:21 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jun 3, 2008, at 4:36 PM, Gary Furnish wrote: That depends on what they are being used for, but categories lend themselves very naturally to multiple inheritance because of what they are mathematically. I understand wanting, .e.g., arithmetic to be super fast, but I don't see the gain in hacks/code duplication to strip out multiple inheritance from and cythonize categories. Python is a beautiful language, but it comes with a cost (e.g. dict lookups). Other than initial homset creation, what would be faster (for you) if homsets and categories were written in Cython? If coercion was implemented with 100% pure Cython code (with an eye for speed where it is needed), The critical path for doing arithmetic between elements is 100% pure Cython code. The path for discovering coercions has Python in it, but until (if ever) all Parents are re-written in Cython this isn't going to be fully optimal anyways. And it only happens once (compared to the old model where it happened every single time a coercion was needed). But I don't have elements, I have variables that represent elements. Maybe the solution here is to run an_element on each parent and then multiply them (and in fact I do this as a last case resort) and then get the parent of the result, but this is a pretty bad way to do things as it requires construction of elements during coercion. Furthermore, this isn't even implemented in some classes, the default is written in python, etc. Even if those issues were dealt with, having to multiply two elements to figure out where the result is a bad design. Ah, yes. We talked about this before, and I implemented the analyse and explain functions which carefully avoid all Python: http://cython.org/coercion/hgwebdir.cgi/sage-coerce/rev/1a5c8ccfd0df Of course, much of the discover part could and should be optimized. But right now we've already got enough on our plate trying to get the changes we have pushed through. (Any help on this front would be greatly appreciated.) I would be significantly less upset with it then I am now where people tell me that if I need more speed I'm out of luck. That's not the message I'm trying to send--I'm sure there's room for improvement (though I have a strong distaste for hard-coding special cases in all over the place). I don't think make everything Cython is going to solve the problem... No but special cases/writing my own fast coercion code seems to work significantly better then trying to use your system. Writing a huge number of special cases is almost always going to be faster, not doubt about it. The Sage coercion code needs to be extremely generic as it handles all kinds of objects (and I'm excited to have symbolics that respect this). This is definitely a bad situation, because we shouldn't need another set of coercion codes that deal with the cases where the main coercion code is too slow. Yes. Either coercion has to be designed to be fast, or symbolics is going to have to reach into the innards of the coercion framework to make it possible to deal with quickly. It would be even better if we could have symbolicring over RR or symbolicring over ZZ or what not, but this is 100% impossible unless the coercion framework is done 100% in cython, with special cases, with speed as a top priority instead of beauty. Would it be 95% possible if it's 95% written in Cython, with only a 5% performance hit :-). The best balance I see is you can hard code ZZ/RR/... for speed if you want (you're worried about virtual function calls anyways), and then call off to coercion in the generic cases. You're going to have to do this a bit anyways, as the coercion model doesn't handle stuff like where is the sin(x) if x is in R? which is handled via the normal OO sense based on the type of x (and may depend on x). To help with collaboration, what you want out of the coercion model is, given R and S (and an operation op), what will be the result of op between elements of R and S, and you want this to be as fast as possible (e.g. 100% Cython, no homsets, ...). Correct - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: more licensing discussion - Blender
I meant in comparison to its commercial competitors, like Autodesk's 3d studio max, which are roughly 2GB (I'm not sure exactly). The binary is much smaller than those programs. As a component of Sage, it would be big, so its probably destined to be an optional spkg at most. But I think its very impressive considering all it does - much more than just rendering. -Marshall On Jun 3, 7:56 pm, William Stein [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 4:28 PM, Marshall Hampton [EMAIL PROTECTED] wrote: I have a small grant this summer to work on 3D visualization of geometric-algebraic objects (e.g. Groebner fans), and I have decided to learn the basics of Blender. Its amazingly small and very python friendly, so hopefully I can get some experience interfacing with it with Sage. Hi, I'm just curious why you call Blender Amazingly small? I looked into blender a lot for Sage, when we were looking very hard for a suitable 3d rendering system. It's not amazingy small in my opinion. It's source distribution is so big it would be bigger than anything else in Sage. I'm not knocking blender at all -- it's a great program. I'm just curious what you meant. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 4:50 PM, Bill Page wrote: On Tue, Jun 3, 2008 at 5:48 PM, William Stein wrote: On Tue, Jun 3, 2008 at 2:45 PM, Bill Page wrote: On Tue, Jun 3, 2008 at 4:48 PM, Robert Bradshaw wrote: On Jun 3, 2008, at 11:17 AM, Gary Furnish wrote: ... I consider homsets to be a gigantic flaw in coercion that absolutely have to be fixed for me to consider using more of the coercion system in symbolics. Ironically, other people see it as a plus that coercion has been given a more categorical founding. Absolutely! :-) BTW, where can I read more about these categorical concepts that are currently built-in or planned for Sage? This is very relevant: http://wiki.sagemath.org/days7/coercion Thanks for the reference. No mention of homsets here. :-( Only one mention in /days7/coercion/todo ... But reading this makes me feel a little, well ah, light-headed. At best it seems like something very hastily grafted-on to the design. Is this part of Sage about which you would like comments and more discussion? Or is there more information somewhere that I am missing? The discussion on that page is (unfortunately) best understood by someone who already is fairly familiar with Sage. It will also probably be re-written/cleaned up now that it has been implemented... I am afraid that there is not much here that category theorists are likely to find interesting. I have many many questions, but mostly I wonder what the overall intention of this construction really is in Sage? Is it only relevant to coercion? The interesting coercion stuff (in my opinion) was all done last June, and much of the work outlined here is trying to unify the API and make things more consistent across all of Sage (though there is more than just that). How does it related to the concept of parent - which seems equally ill-defined to me? A Parent is an Object in the category of Sets, though in the context of coercion one usually assumes one can some kind of arithmetic (binary operations) on their elements. What is the relationship to inheritance in Python? Is the intention to give all mathematical objects defined in Sage some categorical structure? What about categories themselves as mathematical structures - e.g. a category is a kind of directed graph with additional structure? A big push of this model is to divorce the relationship between inheritance (which primarily has to do with implementation) and mathematical categorization. This will allow categories to play a larger role (though work in that area can be done after the merge as it is not disruptive). For example, Z/nZ[x] is implemented the same whether or not p is a prime, but the category it lives in (and hence the methods one can do on it) vary. As another example, matrix spaces are algebras iff they are square, but one doesn't want to have a special class for square matrices over insert optimized type here. Generic algorithms can be put on the categories such that if g is in category C, and C has a method x, then g.x() will work. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 10:04 PM, Robert Bradshaw wrote: How does it related to the concept of parent - which seems equally ill-defined to me? A Parent is an Object in the category of Sets, huh? Don't you mean to say something more like a parent is an object of a concrete category, i.e. a category C with a faithful functor f : C - Set, such that the elements (as understood by Sage) of the parent P are exactly the elements of f(P)? though in the context of coercion one usually assumes one can some kind of arithmetic (binary operations) on their elements. david --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: coercing of sqrt(2)
On Jun 3, 2008, at 7:11 PM, David Harvey wrote: On Jun 3, 2008, at 10:04 PM, Robert Bradshaw wrote: How does it related to the concept of parent - which seems equally ill-defined to me? A Parent is an Object in the category of Sets, huh? Don't you mean to say something more like a parent is an object of a concrete category, i.e. a category C with a faithful functor f : C - Set, such that the elements (as understood by Sage) of the parent P are exactly the elements of f(P)? Yes, that is a much more precise (and correct) explanation of what I meant. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Lattice Boltzmann method
Is there a Sage package for LB method modeling? -- Owen --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Solaris porting porting progress report on Sage 3.0.x
Hello folks, with malb's libSingular fix we are down from 120+ segfaults to about 100 doctest failures, none of them segfaults. While that does not look like much of an improvement nearly all of those errors are caused by the following few issues: * notebook: /dev/random's entropy too low? - hangs/slow startup? * GBasis computed with Singular has some pexpect hangs - maybe already fixed in 3.0.1+? * sage.matrix.matrix_integer_dense.Matrix_integer_dense._rational_echelon_via_solve friends [saturation and so on] hang - LinBox at fault here? * small randgen issues - reported to cwitty * lcalc wasn't compiled since I was too lazy to build libiberty; I also had a working lcalc binary on some other box, but was too lazy to copy it over ;) * I compiled Maxima with sbcl-0.9.11 and Maxima 5.13.0 passes its test suite without any problem. But there are dozens of doctest failures below caused by Maxima segfaulting. I have sbcl-1.0.17 installed, but when building that some modules did not build and consequently Maxima did not build with that sbcl release [something about missing SIGKILL]. The plan now is to get 3.0.3 building on a x86-64 Solaris box since I have Maxima 5.15.0 + clisp 2.45.0 working on there and can dump sbcl from the Sparc box. We also merged some Singular pexpect fix into 3.0.1, so what we are seeing here is another Singular+pexpect bug. I am sure William will track that one down. Cheers, Michael Below are some some examples to demonstrate the quality of some of the issues we need to fix. Compared to the segfault hell we had up until yesterday I would call this an improvement: : ### sage -t devel/sage/sage/libs/ntl/ntl_mat_ZZ.pyx File /home/mabshoff/sage-3.0.1-sparc/tmp/ntl_mat_ZZ.py, line 356: sage: ntl.mat_ZZ(4,4,[ ZZ.random_element() for _ in range(16) ]).determinant() Expected: 678 Got: 0 ### sage -t devel/sage/sage/ext/fast_eval.pyx ** File /home/mabshoff/sage-3.0.1-sparc/tmp/fast_eval.py, line 825: sage: f(1) Expected: 2.7182818284590451 Got: 2.7182818284590455 ** ### sage: get_memory_usage() --- type 'exceptions.NotImplementedError' Traceback (most recent call last) /home/mabshoff/sage-3.0.1-sparc/ipython console in module() /home/mabshoff/sage-3.0.1-sparc/local/lib/python2.5/site-packages/sage/ misc/getusage.py in get_memory_usage(t) 59 return top().split()[-1] 60 else: --- 61 raise NotImplementedError, memory usage not implemented on platform %s%U 62 63 type 'exceptions.NotImplementedError': memory usage not implemented on platform sunos sage: ### The current list of doctest failures: sage -t -verbose devel/sage/sage/calculus/calculus.py sage -t -verbose devel/sage/sage/calculus/desolvers.py sage -t -verbose devel/sage/sage/calculus/functional.py sage -t -verbose devel/sage/sage/calculus/tests.py sage -t -verbose devel/sage/sage/calculus/wester.py sage -t -verbose devel/sage/sage/combinat/partition.py sage -t -verbose devel/sage/sage/combinat/ schubert_polynomial.py sage -t -verbose devel/sage/sage/crypto/mq/ mpolynomialsystem.py sage -t -verbose devel/sage/sage/crypto/mq/sbox.py sage -t -verbose devel/sage/sage/crypto/mq/sr.py sage -t -verbose devel/sage/sage/dsage/tests/testdoc.py sage -t -verbose devel/sage/sage/dsage/web/web_server.py sage -t -verbose devel/sage/sage/functions/functions.py sage -t -verbose devel/sage/sage/functions/orthogonal_polys.py sage -t -verbose devel/sage/sage/functions/piecewise.py sage -t -verbose devel/sage/sage/functions/special.py sage -t -verbose devel/sage/sage/geometry/lattice_polytope.py sage -t -verbose devel/sage/sage/groups/matrix_gps/ matrix_group_element.py sage -t -verbose devel/sage/sage/groups/matrix_gps/ matrix_group_morphism.py sage -t -verbose devel/sage/sage/gsl/interpolation.pyx sage -t -verbose devel/sage/sage/interfaces/maxima.py sage -t -verbose devel/sage/sage/interfaces/singular.py sage -t -verbose devel/sage/sage/lfunctions/lcalc.py sage -t -verbose devel/sage/sage/libs/pari/gen.pyx sage -t -verbose devel/sage/sage/libs/symmetrica/sb.pxi sage -t -verbose devel/sage/sage/libs/symmetrica/sc.pxi sage -t -verbose devel/sage/sage/matrix/matrix0.pyx sage -t -verbose devel/sage/sage/matrix/matrix2.pyx sage -t -verbose devel/sage/sage/matrix/
