Re: [sage-combinat-devel] Re: Bug with the has_coerce_map_from method
Ok I understand what you're saying but this is not obvious from the documentation which says : Return True if there is a natural map from S to self. Otherwise, return False. There is nothing in this sentence that says that the function is actually changing something and stopping you from registering coertions ! Also, there is still a problem. This beahviour may not be a bug but it's causing me issues. Look at the example I attached, The behavious is as follows : - I create the morphism - I register the morphism (ok, no error) - I use the morphism (this is actually moving the coercion to stage 2) - I register again the morphims : I got an error (still normal from what you say) Only, this may look silly on the example but this is exactly what I was doing on my program which is creating morphism dynamically : and that is why I tried to use has_coerce_map because I needed to know if the morphism was already there. So, if has_coerce_map is not the method I need, what should I do ? Should I launch the coercion anyway and catch the error ? It seems a bit heavy and a method only checking would seem usefull. Also, the name of has_coerce_map_from is also wrong, If it's actually doing something, it should be called look_for_coercion or something like that. This name (and the doc) says it's a checking method not an active method. Regards Viviane 2010/7/10 Nicolas M. Thiery nicolas.thi...@u-psud.fr: Hi Viviane, On Sat, Jul 10, 2010 at 12:04:06PM +0200, Viviane Pons wrote: What you describe is indeed what should happen but it's not the problem i'm encountering. My problem is that the function which is checking if the corecion is registered changes the way the system react. Let me build just a bit on Andrey's answer. The point is that has_coerce_map_from does not *check* if there is a coercion registered; it asks the coercion model to *discover* whether there is a coercion, either registered or obtained by transitivity (if you have suggestions for improving the documentation of has_coerce_map_from to clear this ambiguity, a patch is welcome!) Then, there are two stages in the life of a parent: - In stage I you can register coercions, and reregister them as much as you want (say if you find out that you have a better way of doing a coercion). Any coercion discovery, including using has_coerce_map_from, triggers the switch from stage I to stage II. - In stage II you can only register coercions between two parents when no coercion registration or discovery occurred between those before. This rule is for safety, to ensure that all cached information is consistent. One could think of weakening this rule a bit, but care must be taken. For information: the relevant code is in sage.structure.parent, in register_coercion, around line 1356. Point taken: the error message is ambiguous; when it says morphism already discovered, it does not mean that the discovery was actually successful. Do you think morphism already looked up would be clearer? If yes, maybe the coercion documentation should be updated as well to use look up rather than discover. This is quiet annoying, because, by doing things right, you shoul always check if a morphim is registered before registering it ! register_coercion is officially responsible for this check, so you do not need to worry about it. By the way, you can simplify: sage: module = Module1() sage: mor = module.to_module2_morphism() sage: codomain = mor.codomain() sage: sage: codomain.has_coerce_map_from(module) False sage: codomain.register_coercion(mor) to: sage: module = Module1() sage: mor = module.to_module2_morphism() sage: mor.register_as_coercion() Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. sage: attach Documents/sage/exemple_bug_coerc.py sage: module1 = Module1() sage: module2 = Module2() sage: mor = module1.to_module2_morphism() sage: mor.register_as_coercion() sage: module2( module1.an_element() ) B[0] + 2*B[1] + 3*B[2] sage: mor.register_as_coercion() ---
Re: [sage-combinat-devel] Re: Bug with the has_coerce_map_from method
On Mon, Jul 12, 2010 at 11:28:41AM +0200, Viviane Pons wrote: Ok I understand what you're saying but this is not obvious from the documentation which says : Return True if there is a natural map from S to self. Otherwise, return False. There is nothing in this sentence that says that the function is actually changing something and stopping you from registering coertions ! Note that the name of the function is not has_registered_coerce_map_from. So it is clear that the coercion still has to do something non trivial. But yes, the documentation could be improved. Patch welcome! Also, there is still a problem. This beahviour may not be a bug but it's causing me issues. Look at the example I attached, The behavious is as follows : - I create the morphism - I register the morphism (ok, no error) - I use the morphism (this is actually moving the coercion to stage 2) - I register again the morphims : I got an error (still normal from what you say) Only, this may look silly on the example but this is exactly what I was doing on my program which is creating morphism dynamically : and that is why I tried to use has_coerce_map because I needed to know if the morphism was already there. So, if has_coerce_map is not the method I need, what should I do ? Should I launch the coercion anyway and catch the error ? It seems a bit heavy and a method only checking would seem usefull. Also, the name of has_coerce_map_from is also wrong, If it's actually doing something, it should be called look_for_coercion or something like that. This name (and the doc) says it's a checking method not an active method. If this feature is really useful, then you could add an accessor self.has_registered_coerce_map_from(domain) in parent.pyx to lookup if domain is already in self._coerce_from_hash. Though even that would not work perfectly, since self._coerce_from_hash contains both registered and discovered coercion maps. Now do you really need this feature? We never had a need for it. Isn't it possible to setup the initialization of your parents so that it is guaranteed that the coercion is registered exactly once? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Root lattices friends
Hi Viviane! On Mon, Jul 12, 2010 at 12:14:50PM +0200, Viviane Pons wrote: I'm working on root sytem friends on the patch I'm developing for multivariate polynomials : trac_6629_abstract_ring_of_multivariate_polynomials_with_several_bases_vp.patch root system are used to index polynomials a bit as in Nicolas Borie's code but seen as a polynomial ring basis. For example, there are morphisms to change this group-attached polynomials to non groups polynomials indexed by relative integer vectors. Divided difference are defined as a morphism and I will use them to create the shubert basis. If you want me to send you sample codes and example, let me know Thanks for the notice! Functionality-wise, my changes should be backward compatible, so there should be no conflict there. I am glad to see you are making progress. It's still in progress and there are no tests yet (so you won't see it if you break it). You did run your code to try it, right? Don't waste this energy: copy paste those attempts as doctests while you run them; for just a bit more work that will give you a good basis for the test suite. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-devel] Do not close tickets
I'd just like to remind everyone: Only the release manager should close tickets. Tim Dumol has closed #7379, even though there was a sage library patch there which needed to be merged. This is causing 4.5.rc0 to fail in much worse ways than it should. If you close tickets yourself you may be publicly shamed on sage-devel! You have been warned!!! -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
I'm copying my reply to the Sage 4.5.rc0 thread: Sorry! I was last informed that I could close notebook tickets that are merged in a SageNB release. Since you closed #9430 (SageNB 0.8.1) and said that it was merged in 4.5.rc0, I assumed that the Sage library patch at #7379 was merged as well, since the ticket description at #9430 notes that #7379 is to be merged with #9430. On Mon, Jul 12, 2010 at 3:58 PM, Robert Miller r...@rlmiller.org wrote: I'd just like to remind everyone: Only the release manager should close tickets. Tim Dumol has closed #7379, even though there was a sage library patch there which needed to be merged. This is causing 4.5.rc0 to fail in much worse ways than it should. If you close tickets yourself you may be publicly shamed on sage-devel! You have been warned!!! -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- Tim Joseph Dumol tim (at) timdumol (dot) com http://timdumol.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
On Mon, Jul 12, 2010 at 10:01 AM, Tim Joseph Dumol t...@timdumol.com wrote: I'm copying my reply to the Sage 4.5.rc0 thread: Sorry! I was last informed that I could close notebook tickets that are merged in a SageNB release. This would be a good reason for us to setup a separate trac server for the notebook. It's tempting. There's probably also a way to make it so http://trac.sagemath.org/sage_notebook is a trac just for the notebook. Since you closed #9430 (SageNB 0.8.1) and said that it was merged in 4.5.rc0, I assumed that the Sage library patch at #7379 was merged as well, since the ticket description at #9430 notes that #7379 is to be merged with #9430. On Mon, Jul 12, 2010 at 3:58 PM, Robert Miller r...@rlmiller.org wrote: I'd just like to remind everyone: Only the release manager should close tickets. Tim Dumol has closed #7379, even though there was a sage library patch there which needed to be merged. This is causing 4.5.rc0 to fail in much worse ways than it should. If you close tickets yourself you may be publicly shamed on sage-devel! You have been warned!!! -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- Tim Joseph Dumol tim (at) timdumol (dot) com http://timdumol.com -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
This would be a good reason for us to setup a separate trac server for the notebook. I was thinking the same exact thing! +1 -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] random_element conflicts
On Mon, Jul 12, 2010 at 1:45 AM, Niles Johnson nil...@gmail.com wrote: Hello all, I noticed some varying definitions of random_element for ZZ, QQ, and RR (and probably other rings). This causes misleading documentation (whch doctests don't catch, because the output is random!) and, for power series rings over RR, an error. My initial thought was to just open a ticket for power series over RR and fix that bug, but once I started looking at the different definitions of random_element, I wasn't sure what would be best. Ideas? Details below. best, Niles First, note the different arguments expected by random_element for ZZ, QQ, and RR: Definition: ZZ.random_element(self, x=None, y=None, distribution=None) Source: def random_element(self, x=None, y=None, distribution=None): r Return a random integer. ZZ.random_element() return an integer using the default distribution described below ZZ.random_element(n) return an integer uniformly distributed between 0 and n-1, inclusive. ZZ.random_element(min, max) return an integer uniformly distributed between min and max-1, inclusive. Definition: QQ.random_element(self, num_bound=None, den_bound=None, distribution=None) Source: def random_element(self, num_bound=None, den_bound=None, distribution=None): here: numerator is between -num_bound and num_bound+1, denominator is between 1 and den_bound+1 if num_bound is supplied, den_bound defaults to equal num_bound Definition: RR.random_element(self, min=-1, max=1, distribution=None) Source: def random_element(self, min=-1, max=1, distribution=None): Returns a uniformly distributed random number between min and max (default -1 to 1). Now here is how random_element is implemented for polynomial rings. The docstring makes no substantial promises, and hence no lies: sage: PZ = PolynomialRing(ZZ,'v') sage: PQ = PolynomialRing(QQ,'v') Definition: PQ.random_element(self, degree=2, *args, **kwds) Source: def random_element(self, degree=2, *args, **kwds): r Return a random polynomial. INPUT: - ``degree`` - Integer with degree (default: 2) or a tuple of integers with minimum and maximum degrees - ``*args, **kwds`` - Passed on to the ``random_element`` method for the base ring sage: PQ.random_element(5) -4*v^4 - 1/44*v^3 - 5/2*v^2 - 1/5*v + 1 sage: PZ.random_element(5,100) # coefficients all positive 6*v^5 + 57*v^4 + 79*v^3 + 95*v^2 + 69*v + 13 sage: PQ.random_element(5,100) 39/22*v^5 - 15/4*v^4 - 43/98*v^3 + 30/71*v^2 - 47/54*v - 37/83 sage: PR.random_element(5,100) 44.7199850245856*v^5 + 51.5361019677145*v^4 + 28.8884279668796*v^3 + 20.5640533623856*v^2 + 92.6606456093422*v + 27.7377902950395 And here's what we have for power series rings: sage: SQ = PowerSeriesRing(QQ,'v') sage: SR = PowerSeriesRing(RR,'v') Definition: SQ.random_element(self, prec, bound=None) You should fix that, just as you planned to do. I think it's the way it is for historical reasons, since there was a time when the rings only had one implementation of random_element. Change things to be like with polynomial rings. -- William Source: def random_element(self, prec, bound=None): r Return a random power series. INPUT: - ``prec`` - an integer - ``bound`` - an integer (default: None, which tries to spread choice across ring, if implemented) sage: SQ.random_element(5) 1/2*v + 1/2*v^2 - 1/6*v^3 + 2*v^4 + O(v^5) sage: SQ.random_element(5,100) # docstring promises coefficients are uniformly distributed between -100 and 100 -7/3 + 5/8*v + 37/60*v^2 + 33/8*v^3 + 77/89*v^4 + O(v^5) sage: SR.random_element(5) # broken Traceback (most recent call last): ... TypeError: unsupported operand type(s) for -: 'int' and 'NoneType' sage: SR.random_element(5,100) # works, but not as indicated by documentation 95.2417086255616 + 13.9139610613937*v + 45.3045671712598*v^2 + 94.5179368088424*v^3 + 80.5135466443438*v^4 + O(v^5) sage: SR.random_element(5,100) 88.5832192873596 + 4.57768492583799*v + 28.1830520242686*v^2 + 53.1959782753104*v^3 + 17.2203119065628*v^4 + O(v^5) sage: SR.random_element(5,100) 98.9397896920050 + 50.3734868594305*v + 3.45686853617011*v^2 + 15.0639985942490*v^3 + 9.04148241799453*v^4 + O(v^5) sage: SR.random_element(5,100) 20.7895461898698 + 79.4963437949055*v + 72.6510673159177*v^2 + 52.7149245489294*v^3 + 79.5260956048129*v^4 + O(v^5) sage: SR.random_element(5,-100) -63.5408783894400 - 49.8386015442635*v - 78.7058878043647*v^2 - 46.1262189039151*v^3 - 53.2891372935381*v^4 + O(v^5) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more
Re: [sage-devel] Do not close tickets
On 12 July 2010 08:58, Robert Miller r...@rlmiller.org wrote: I'd just like to remind everyone: Only the release manager should close tickets. Tim Dumol has closed #7379, even though there was a sage library patch there which needed to be merged. This is causing 4.5.rc0 to fail in much worse ways than it should. If you close tickets yourself you may be publicly shamed on sage-devel! You have been warned!!! -- Robert L. Miller http://www.rlmiller.org/ Strange, because only a few weeks ago I asked someone to close a ticket and William responded with this below. http://groups.google.co.uk/group/sage-devel/browse_thread/thread/6779afed2bb7622a/05b81c29bf13ddf8?lnk=gstq=close+tickets#05b81c29bf13ddf8 So you and William are interpreting this differently. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
On 12 July 2010 09:05, William Stein wst...@gmail.com wrote: http://trac.sagemath.org/sage_notebook is a trac just for the notebook. It's a broken link for me. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
So you and William are interpreting this differently. Dave, I think you'll find that William and I have the same opinion about closing tickets -- you're unfortunately trying to absolutely generalize what I'm saying. You haven't caused any trouble by closing tickets, but it is very easy for many people to do so. Every rule has its exceptions, but the case in point is not a valid exception. -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
On Mon, Jul 12, 2010 at 10:47 AM, David Kirkby david.kir...@onetel.net wrote: On 12 July 2010 09:05, William Stein wst...@gmail.com wrote: http://trac.sagemath.org/sage_notebook is a trac just for the notebook. It's a broken link for me. It was a hypothetical link for everyone. Dave -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Do not close tickets
Hi Robert and William, What does closing a ticket mean? Is it the same as providing a resolution such as fixed, wontfix, duplicate? Or is closing the ticket something that comes *after* providing a resolution? If providing resolution and closing is the same, then I recently closed a ticket out of ignorance. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Do not close tickets
On Mon, Jul 12, 2010 at 12:15 PM, Simon King simon.k...@nuigalway.ie wrote: Hi Robert and William, What does closing a ticket mean? Is it the same as providing a resolution such as fixed, wontfix, duplicate? Or is closing the ticket something that comes *after* providing a resolution? If providing resolution and closing is the same, then I recently closed a ticket out of ignorance. They are indeed the same. Which ticket was it? Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- Robert L. Miller http://www.rlmiller.org/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Do not remove output of interact if auto_update=False
Dear sage-devel this is continuation of http://groups.google.cz/group/sage-support/browse_thread/thread/527f12e3b859bbb3/203fca703ceb1741 I would like to modify interact so that changing the input of interact with auto_update=False does NOT remove the output computed for previous data from the screen. Can you give me a few pointers what should be changed? Is the corresponding code in main sage library, or in sage-notebook? I was not able to find the related piece of code. Thank you very much. Robert Marik -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Do not close tickets
This would be a good reason for us to setup a separate trac server for the notebook. It's tempting. There's probably also a way to make it so http://trac.sagemath.org/sage_notebook is a trac just for the notebook. However, at the very least one would want to have intense integration between this and Sage's trac. What if something at this new Trac needed to include a Sage library patch that affected someone who doesn't develop on the notebook? Also, I see the potential for even more balkanization when it comes to the notebook. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Scheme extends Parent
Hi all,
I'm getting a bit confused about Parent objects and why
sage.schemes.generic.scheme.Scheme extends Parent.
Schemes are not really containers of anything, right? Calling
S.an_element() currently gives a NotImplementedError for most schemes,
and TestSuite(S).run() will give lots of failures for almost every
kind of scheme.
ProjectiveSpace does implement an_element, but that gives elements of
the coordinate ring instead of elements of the projective space
itself.
To make things even more confusing, the documentation for
sage.structure.parent.Parent.an_element() says Parent structures that
are should override _an_element_() instead. What does Parent
structures that are mean? When is a parent structure?
Thanks,
Marco
{{{
sage: Q.X,Y,Z = QQ[]
sage: P = ProjectiveSpace(Q)
sage: e = P.an_element(); e
X
sage: e.parent()
Multivariate Polynomial Ring in X, Y, Z over Rational Field
sage: S = Curve(X^2-Y^2+Z^2)
sage: S.an_element()
NotImplementedError: please implement _an_element_ for Projective
Curve over Rational Field defined by X^2 - Y^2 + Z^2
}}}
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Scheme extends Parent
On Monday, July 12, 2010, Marco Streng marco.str...@gmail.com wrote:
Hi all,
I'm getting a bit confused about Parent objects and why
sage.schemes.generic.scheme.Scheme extends Parent.
Schemes are not really containers of anything, right?
A scheme is by definition a locally ring topological space. Thus a scheme is:
- a set of points (prime ideals in case of an affine scheme)
- a topology (locally the zariski topology)
- a sheaf if rings
Calling
S.an_element() currently gives a NotImplementedError for most schemes,
and TestSuite(S).run() will give lots of failures for almost every
kind of scheme.
ProjectiveSpace does implement an_element, but that gives elements of
the coordinate ring instead of elements of the projective space
itself.
Why elements in quotes? Coordinate ring elements is a bug.
To make things even more confusing, the documentation for
sage.structure.parent.Parent.an_element() says Parent structures that
are should override _an_element_() instead. What does Parent
structures that are mean? When is a parent structure?
Thanks,
Marco
{{{
sage: Q.X,Y,Z = QQ[]
sage: P = ProjectiveSpace(Q)
sage: e = P.an_element(); e
X
sage: e.parent()
Multivariate Polynomial Ring in X, Y, Z over Rational Field
sage: S = Curve(X^2-Y^2+Z^2)
sage: S.an_element()
NotImplementedError: please implement _an_element_ for Projective
Curve over Rational Field defined by X^2 - Y^2 + Z^2
}}}
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Scheme extends Parent
On Jul 12, 10:20 am, Marco Streng marco.str...@gmail.com wrote:
Hi all,
I'm getting a bit confused about Parent objects and why
sage.schemes.generic.scheme.Scheme extends Parent.
Schemes are not really containers of anything, right? Calling
S.an_element() currently gives a NotImplementedError for most schemes,
and TestSuite(S).run() will give lots of failures for almost every
kind of scheme.
ProjectiveSpace does implement an_element, but that gives elements of
the coordinate ring instead of elements of the projective space
itself.
To make things even more confusing, the documentation for
sage.structure.parent.Parent.an_element() says Parent structures that
are should override _an_element_() instead. What does Parent
structures that are mean? When is a parent structure?
Thanks,
Marco
{{{
sage: Q.X,Y,Z = QQ[]
sage: P = ProjectiveSpace(Q)
sage: e = P.an_element(); e
X
sage: e.parent()
Multivariate Polynomial Ring in X, Y, Z over Rational Field
sage: S = Curve(X^2-Y^2+Z^2)
sage: S.an_element()
NotImplementedError: please implement _an_element_ for Projective
Curve over Rational Field defined by X^2 - Y^2 + Z^2
}}}
I was the one who switched schemes to Parent instead of Parent_old and
I definitely did notice that TestSuite does not run on them and in
general there are some confusing points. However I was not able to
completely fix everything and in particular not even all components
of the schemes framework are derived from new style classes. I would
argue that schemes are containers of their points, so there is nothing
wrong in deriving them from Parent, but the way how it is done may
require fixing and modification. If someone wants to do it, I beg
doing it after inclusion of all tickets upto #9245 because: 1) it may
be a bit difficult to rebase all patches in that sequence; 2) these
tickets add more complicated and more documented and doctested
ambient spaces and schemes, so it would be nice to have them in to
test the changes.
Thank you,
Andrey
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Do not close tickets
On Monday, July 12, 2010, kcrisman kcris...@gmail.com wrote: This would be a good reason for us to setup a separate trac server for the notebook. It's tempting. There's probably also a way to make it so http://trac.sagemath.org/sage_notebook is a trac just for the notebook. However, at the very least one would want to have intense integration between this and Sage's trac. What if something at this new Trac needed to include a Sage library patch that affected someone who doesn't develop on the notebook? Also, I see the potential for even more balkanization when it comes to the notebook. Separating the notebook from sage is by far the best chance we have to reduce the number of different competing notebook projects. The less tight the integration with sage the better for this - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Scheme extends Parent
On 12 jul, 18:54, William Stein wst...@gmail.com wrote: On Monday, July 12, 2010, Marco Streng marco.str...@gmail.com wrote: Hi all, I'm getting a bit confused about Parent objects and why sage.schemes.generic.scheme.Scheme extends Parent. Schemes are not really containers of anything, right? A scheme is by definition a locally ring topological space. Thus a scheme is: - a set of points (prime ideals in case of an affine scheme) - a topology (locally the zariski topology) - a sheaf if rings Calling S.an_element() currently gives a NotImplementedError for most schemes, and TestSuite(S).run() will give lots of failures for almost every kind of scheme. ProjectiveSpace does implement an_element, but that gives elements of the coordinate ring instead of elements of the projective space itself. Why elements in quotes? Coordinate ring elements is a bug. In quotes because I don't call them elements but points (or elements) of the underlying topological space. Variety extends Scheme, but for me an element of a variety sound like a rational point or a geometric point, but not a scheme-theoretic point. Anyway, I'm fine with elements of a Sage Scheme meaning points of the topological space. I'm still confused about the following though: To make things even more confusing, the documentation for sage.structure.parent.Parent.an_element() says Parent structures that are should override _an_element_() instead. What does Parent structures that are mean? When is a parent structure? Thanks, Marco -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] complementary problem
If G is a graph and A = G.am() is its adjacency matrix and B = G.complement().am() is the adjacency matrix of its complement, then A+B should be a 01- matrix. The code below shows that sage does not always share this viewpoint. Cheers Chris # ## -- ## | Sage Version 4.4.4, Release Date: 2010-06-23 | ## | Type notebook() for the GUI, and license() for information.| ## -- ## sage: load whine.sage ## sage: mcl = McL() ## sage: A = mcl.am() ## sage: B = mcl.complement().am() ## sage: A.fcp() ## ## These are what they should be ## ## (x - 112) * (x + 28)^22 * (x - 2)^252 ## sage: B.fcp() ## (x - 162) * (x - 27)^22 * (x + 3)^252 ## ## Here's the problem: C should be a 01-matrix (in fact it should be J- I) ## ## sage: C = A+B ## sage: max(C[0].list()) ## 2 ## ## If use mcl.relabel() before computing A and B, there are no problems. So its the ## complicated vertices that are causing the problem, I expect. ## ## Here's the content of whine.sage: ## def switch(G,sub): H = G.copy() rest = Set(H.vertices()).difference(Set(sub)) for u in sub: for v in rest: if H.has_edge(u,v): H.delete_edge(u,v) else: H.add_edge(u,v) return H def McL(): C = ExtendedBinaryGolayCode() D = C.punctured([0]) words = [ Set(it.support()) for it in D if hamming_weight(it)==7] MG = Graph( [words, lambda a,b: len(a.intersection(b))==1]) MM = MG.copy() MM.add_vertices([0..22]) edges = [ (i,a) for i in [0..22] for a in words if i not in a] MM.add_edges( edges) McL = switch( MM, MM[0]) McL.delete_vertex(0) return McL -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Randomised testing against Mathematica
I realize this thread is 4 months old, but let me respond to this one technical question: On Thu, Mar 4, 2010 at 2:10 AM, Simon King simon.k...@nuigalway.ie wrote: Hi! On Mar 4, 8:24 am, Robert Bradshaw rober...@math.washington.edu wrote: I believe there is also some randomized testing that is done in the category code that takes random elements and verifies they have the correct properties (e.g. commutativity, associativity, etc.) that has exposed some bugs. One technical question about randomised doc tests: Perhaps I remember incorrectly; but isn't it the case that the random seed is initialised to a fixed value when one runs the doc tests? Hence, isn't that type of random test only repeating the same computation? But I agree that random (I mean *really* random) consistency test suit would be a good thing to have! It's true that by default, random testing in a doctest won't really be random. However, there is also a framework (a design pattern and a little bit of supporting code) for doing truly random testing in doctests; see sage/misc/random_testing.py . (I just counted it up; by my estimate, random_testing.py is 10% useful code and 90% documentation/comments/doctests.) This only has two users in Sage currently (homology/tests.py and rings/tests.py); in particular, the category testing code that Robert mentioned does not use it, but could. Carl -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: complementary problem
I think there lies the problem :
sage: mcl_v = mcl.vertices()
sage: mclc_v = mcl.complement().vertices()
sage: mcl_v == mclc.v
False
So they are not equal. Do they contain the same elements ?
sage: Set(mcl_v) == Set(mclc_v)
True
So it seems... But then, what does THAT mean ?
sage: sorted(mclc_v) == sorted(mcl_v)
False
Anyway :
sage: (i for i in xrange(len(mclc_v)) if mcl_v[i] != mclc_v[i]).next()
30
sage: mcl_v[30]
{16, 1, 2, 17, 8, 11, 14}
sage: mclc_v[30]
{0, 17, 2, 22, 6, 8, 15}
Actually, I tried to first build the union of mcl and its complement,
which was indeed a clique. Besides, when ones builds copies of mcl and
its complement using the adjacency matrices, the graphs are isomorphic
to what they should be. I suspected something wrong with the order in
which the vertices are sorted, which would mean that the coordinate
(i,j) do not represent the same pair of vertices in both matrices.
This seems indeed to be the case, but I really do not like this
difference between the two sorted ouputs
Would you have any idea, Robert? :-/
Nathann
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Do not close tickets
On Jul 12, 12:59 pm, William Stein wst...@gmail.com wrote: On Monday, July 12, 2010, kcrisman kcris...@gmail.com wrote: This would be a good reason for us to setup a separate trac server for the notebook. It's tempting. There's probably also a way to make it so http://trac.sagemath.org/sage_notebook is a trac just for the notebook. However, at the very least one would want to have intense integration between this and Sage's trac. What if something at this new Trac needed to include a Sage library patch that affected someone who doesn't develop on the notebook? Also, I see the potential for even more balkanization when it comes to the notebook. Separating the notebook from sage is by far the best chance we have to reduce the number of different competing notebook projects. The less tight the integration with sage the better for this True, but that doesn't address the problem of how to deal with sagenb patches that require complementary sage library patches, especially for non-notebook developers who would find it difficult to wait several months for a new spkg if there was something they needed (don't ask me for a specific example, I'm just raising a hypothetical here). - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Ubuntu 10.04, JMOL, Java
I finally got a chance to test this on a clean 64-bit Ubuntu 10.04 (lucid) install. I began by apt-get'ing the icedtea6-plugin, which pulls in a lot of other packages such as the OpenJDK version of Java. A simple 3d plot would not render in JMOL in the notebook, though the black square did have a JMOL logo in one corner, so there was some progress. Sun/Oracle version is in the Canonical partner repository. So I remove'd the packages I'd just installed and at a command-line: sudo add-apt-repository deb http://archive.canonical.com/ lucid partner sudo apt-get update sudo apt-get install sun-java6-bin sun-java6-jre sun-java6-plugin sun- java6-fonts After this, the 3d plot worked fine with JMOL. If you've been trying other things, the following commands (or variants) might be useful/ needed: pre-intall:sudo apt-get autoremove openjdk-6-jre post-install: sudo update-java-alternatives -s java-6-sun Rob -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
