[sage-devel] Re: issue with division in fraction field of univ poly

I'm not getting 0 with that code: sage: K. = Frac(QQ['a']) sage: P. = ProjectiveSpace(K, 1) sage: D2=-x^5 + (-3*a^2 + 7*a - 2)/a*x^4*y + (6*a^2 - 12*a + 4)/a*x^3*y^2 + (3*a^4 - 19*a^3 + 29*a^2 - 14*a + 2)/(a^2)*x^2*y^3 + (-8*a^4 + 30*a^3 - 37*a^2 + 18*a - 3)/(a^2)*x*y^4 + (4*a^4 - 12*a^3 +

[sage-devel] issue with division in fraction field of univ poly

In investigating an issue with dynatomic_polynomial in dynamical systems, I came across an odd issue with polynomials with fraction field coefficients. Here is the condensed version: K. = Frac(QQ['a']) P. = ProjectiveSpace(K, 1) D2=-x^5 + (-3*a^2 + 7*a - 2)/a*x^4*y + (6*a^2 - 12*a +

[sage-devel] Re: "TypeError: not a constant polynomial" when trying to fix `normalize_coordinates` in `projective_morphism.py`

The issue is with this line of the PR: denom = R.ideal(list(self)).absolute_norm().denominator() list(self) is a list of polynomials. You want the ideal of the coefficients of those polynomials. On Sunday, June 25, 2023 at 3:54:07 PM UTC-5 Jing Guo wrote: > Hello everyone, > > As it is

[sage-devel] sage-days 104: arithmetic dynamics

We are pleased to announce a sage-days workshop November 17-20, 2019 at Saint Louis University in Saint Louis MO, USA. The main focus is on functionality associated to the arithmetic of dynamical systems and related areas. We are fortunate to have funding via the National Science Foundation

[sage-devel] Re: Possible bug, weird base field change when working with polynomial rings

Actually, I think the issue here is that there isn't actually a division happening, rather, it *is* doing the unit check and inverse of unit calculation within numerator(); but still moves to the fractionfield. When numerator(), on the fractionfield element is called, eventually the function

[sage-devel] Re: need some help understanding QQbar behavior

On Saturday, January 27, 2018 at 7:47:23 AM UTC-6, Ben Hutz wrote: > > I'm trying to track down a rational point failure. Here is a simple > reproduction > > this way gives an error that the point is not on the scheme (doesn't > satisfy the equations) > P.<x,y,z,w>=Projective

[sage-devel] need some help understanding QQbar behavior

I'm trying to track down a rational point failure. Here is a simple reproduction this way gives an error that the point is not on the scheme (doesn't satisfy the equations) P.=ProjectiveSpace(QQ,3) X=P.subscheme([-7/4*z-w, x-7/4*z, -3/4*x+y-9/16*z+3/4*w])

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

On Friday, September 8, 2017 at 12:37:46 PM UTC-5, David Roe wrote: > > > > On Fri, Sep 8, 2017 at 11:54 AM, Ben Hutz <bn4...@gmail.com > > wrote: > > Since the consensus is that P(0) etc. is too ambiguous a choice, that is >> now #23806. >> > > I

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

affine patches being the same in memory is #23807 On Friday, September 8, 2017 at 8:21:15 AM UTC-5, Ben Hutz wrote: > > Thanks for the additional responses. > > The non-equality of the hash functions is enough to convince me that P(0) > == 0 is not worth the "convenience"

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

Thanks for the additional responses. The non-equality of the hash functions is enough to convince me that P(0) == 0 is not worth the "convenience" of this type of coercion. However, just to point out another inconsistency. It seems that coercion is currently violating this hash equality in

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

happened here. What is the argument that makes PP(0) == 0 bad? If PP(0) is allowed, I don't see how PP(0) == 0 is particularly worse. On Thursday, September 7, 2017 at 3:16:56 PM UTC-5, Nils Bruin wrote: > > On Thursday, September 7, 2017 at 12:10:40 PM UTC-7, Ben Hutz wrote: >> >

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

On Thursday, September 7, 2017 at 1:16:12 PM UTC-5, David Roe wrote: > > > > On Thu, Sep 7, 2017 at 2:00 PM, Ben Hutz <bn4...@gmail.com > > wrote: > > Once you construct P(0), both a and P(0) are in the same parent, so there > are no coercions involved in the

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

. You'd be surprised at how often in Sage the shorthand of leaving of the last coordinate occurs. But, yes, it is just a shorthand and is used in the __init__() for point. On Thursday, September 7, 2017 at 12:53:05 PM UTC-5, David Roe wrote: > > > > On Thu, Sep 7, 2017 at 1:46 PM, B

Re: [sage-devel] _richcmp_ versus __eq__ for scheme points

r: BUG in coercion model, no element constructor for 'sage.schemes.projective.projective_space.ProjectiveSpace_rational_field_with_category'> > > David > > On Thu, Sep 7, 2017 at 1:11 PM, Ben Hutz <bn4...@gmail.com > > wrote: > >> I'm working on implementing coercion for scheme points and had a questio

[sage-devel] _richcmp_ versus __eq__ for scheme points

I'm working on implementing coercion for scheme points and had a question about how comparison is done. As an explicit example consider the following point P.= ProjectiveSpace (QQ ,1) a=P(0) in particular, the integer 0 is coerced into the projective point (0:1). For comparisons it

Re: [sage-devel] Where should binary form reduction live?

ok, we could put it there. The binary qf version is called reduced_form() so we could call this one reduced_form() as well, which has the benefit of avoiding the naming conflict. On Thursday, August 11, 2016 at 2:41:10 PM UTC-5, John Cremona wrote: > > On 11 August 2016 at 20:36, Ben Hut

Re: [sage-devel] Where should binary form reduction live?

? On Thursday, August 11, 2016 at 2:26:27 PM UTC-5, John Cremona wrote: > > On 11 August 2016 at 20:03, Ben Hutz <bn4...@gmail.com > > wrote: > > Yes we see that the quadratic form folder contains all the quadratic > > implementations. inside that there is some specific

Re: [sage-devel] Where should binary form reduction live?

Yes we see that the quadratic form folder contains all the quadratic implementations. inside that there is some specific functionality for binary quadratic forms (binary_qf.py). However, Lauren's function is for binary forms of *any* degree. As such, it doesn't really belong under the

Re: [sage-devel] quotient rings, mpolynomial rings, and monomial_divides

: {{{ A.<x,y,z> = PolynomialRing(GF(17)) A.monomial_quotient(y,x^2*y) x^1048574*y^1048575*z^1048575 }}} On Tuesday, March 1, 2016 at 11:27:17 AM UTC-6, Ben Hutz wrote: > > ok. I can do that later this week. > > On Tuesday, March 1, 2016 at 11:22:04 AM UTC-6, David Roe wrote: >

Re: [sage-devel] quotient rings, mpolynomial rings, and monomial_divides

ok. I can do that later this week. On Tuesday, March 1, 2016 at 11:22:04 AM UTC-6, David Roe wrote: > > The only reason that monomial_divides is unimplemented there is that > nobody has done it yet. :-) > David > > On Tue, Mar 1, 2016 at 12:20 PM, Ben Hutz <bn4...@gmail.co

[sage-devel] Re: SageMath has been accepted as an GSoC 2016 mentor org

That's great. I added a project to the project page awhile ago, but this is to confirm I'll be able to mentor that project. I don't see how to join the SageMath organization. So just let me know what I need to do. Thanks. On Monday, February 29, 2016 at 2:39:36 PM UTC-6, Harald Schilly wrote:

Re: [sage-devel] quotient rings, mpolynomial rings, and monomial_divides

. On Monday, February 29, 2016 at 2:25:45 PM UTC-6, David Roe wrote: > > > > On Mon, Feb 29, 2016 at 9:19 AM, Ben Hutz <bn4...@gmail.com > > wrote: > >> I was exploring some quotient ring operations and came across the >> following: >> >> {{{ >

Re: [sage-devel] quotient rings, mpolynomial rings, and monomial_divides

: > > On 29 February 2016 at 14:19, Ben Hutz <bn4...@gmail.com > > wrote: > > I was exploring some quotient ring operations and came across the > following: > > > > {{{ > > R.=QQ[] > > K.=NumberField(y^3 + 2*y - 2401) > > k.=K.qu

[sage-devel] quotient rings, mpolynomial rings, and monomial_divides

I was exploring some quotient ring operations and came across the following: {{{ R.=QQ[] K.=NumberField(y^3 + 2*y - 2401) k.=K.quo(K.prime_factors(7)[1]) R.=PolynomialRing(k) R.monomial_divides(y,x^3*y) Error }}} {{{ R.=QQ[] K.=NumberField(y^3 + 2*y - 2401)

[sage-devel] Re: advice needed for what to do in subscheme polynomial morphism initialization

I've now gone ahead and implemented a preliminary solution( http://trac.sagemath.org/ticket/20018). This had a slight effect on elliptic_curve/jacobian.py and toric/variety.py, so please take a look and provide feedback. The particularities are described in the ticket. Thanks, Ben -- You

[sage-devel] advice needed for what to do in subscheme polynomial morphism initialization

I'm working on an issue with initialization of affine and projective morphisms over subschemes (Trac #20018). In looking at this I've uncovered a sticky issue that I'm not sure what the right fix is. Essentially, over a subscheme the coordinate ring is a quotient ring. Thus, when initializing

[sage-devel] OSX 10.6.8 needed to test #17907

Ticket #17386 implemented a naive rational point search algorithm for subschemes using the enumeration of points of bounded height in number fields from #15389. However, #15389 is precision sensitive and one of the examples in #17386 failed on OSX 10.6.8 (in addition to an error in height

[sage-devel] Re: weil restriction for affine schemes as a functor?

This is now #17729 On Monday, February 2, 2015 at 8:59:33 PM UTC-5, Ben Hutz wrote: I'm interested in implementing Weil restriction (restriction of scalars) for affine schemes. I see from #5569, that there is an implementation for ideals. I'd like to extend this to affine schemes/points

Re: [sage-devel] weil restriction for affine schemes as a functor?

)? John On 3 February 2015 at 01:59, Ben Hutz bn4...@gmail.com javascript: wrote: I'm interested in implementing Weil restriction (restriction of scalars) for affine schemes. I see from #5569, that there is an implementation for ideals. I'd like to extend this to affine schemes/points

Re: [sage-devel] weil restriction for affine schemes as a functor?

thanks. On Tuesday, February 3, 2015 at 8:09:45 AM UTC-5, John Cremona wrote: On 3 February 2015 at 13:00, Ben Hutz bn4...@gmail.com javascript: wrote: I'm not a member yet of those groups, so my cross-post attempt failed. If you could do so that would be appreciated. Done -- and I

Re: [sage-devel] weil restriction for affine schemes as a functor?

trying again to cross-post On Tuesday, February 3, 2015 at 4:03:22 AM UTC-5, John Cremona wrote: This would be great to have. Why don't you cross-post to sage-nt (and perhaps also sage-algebra)? John On 3 February 2015 at 01:59, Ben Hutz bn4...@gmail.com javascript: wrote: I'm

[sage-devel] weil restriction for affine schemes as a functor?

I'm interested in implementing Weil restriction (restriction of scalars) for affine schemes. I see from #5569, that there is an implementation for ideals. I'd like to extend this to affine schemes/points/morphisms. There is also an aborted attempt of Weil restriction for projective models of

[sage-devel] Re: help with merge conflict resolution

. On Sunday, January 25, 2015 at 12:12:34 PM UTC-5, Ben Hutz wrote: Yes, my master does have the lastest develop on it. There is a ticket closed between beta5 and beta6 that conflicts with 17067. So the old master merges fine in any case. OK. I'll reset and commit via git and see if that fixes

[sage-devel] Re: help with merge conflict resolution

-to-date). So you are not doing what you think you are doing at one point. Post the commands that you are using with their full output. On Sunday, January 25, 2015 at 4:08:27 PM UTC+1, Ben Hutz wrote: I'm working on #17067 to fix a merge conflict. I have fixed a number of merge

[sage-devel] Re: help with merge conflict resolution

mergetool # fix git commit If you then try to git merge develop again you'll see that git does nothing. On Sunday, January 25, 2015 at 5:19:20 PM UTC+1, Ben Hutz wrote: Here are the commands and output. You can see after I complete the commit, I try to merge again, and the conflicts

[sage-devel] help with merge conflict resolution

I'm working on #17067 to fix a merge conflict. I have fixed a number of merge conflicts in the past with no issues, but every once in awhile I run into the issues I'm having with 17067. I figured it is time to figure out what I'm doing wrong here. - I merge in the lastest beta to my ticket -

[sage-devel] in IntegralDomains() issues

I came across the following {{{ R.x = ZZ[] S.t = R.quo(x^2+5) S in IntegralDomains() False }}} and even simpler {{{ R=Zmod(5) R in IntegralDomains() False }}} This is related to https://groups.google.com/forum/#!topic/sage-algebra/6C3XkkLfllw but I couldn't find what ticket it is associated

[sage-devel] Re: in IntegralDomains() issues

Thanks. I've reviewed #17450 and opened #17453 for the integer mod rings. On Saturday, December 6, 2014 11:39:21 AM UTC-5, Travis Scrimshaw wrote: Hey Ben, I came across the following {{{ R.x = ZZ[] S.t = R.quo(x^2+5) S in IntegralDomains() False }}} This was an easy fix since we

[sage-devel] possible issue with DiGraph in interval fields

I was experimenting with the perperiodic cyclegraph code and came across something with the ComplexIntervalField. Just to get some interesting points I computed the QQ-rational preperiodic points for a function and simply moved them around with change_ring() and recreated the associated

Re: [sage-devel] Re: possible issue with DiGraph in interval fields

Yes, I agree the hash should be different as the points are not exactly the same interval. However, in trying to explore the interval comparison this also may have exposed a bug in the equality check for projective points. Since the CIF is returning False for == and != the __eq__ check for

Re: [sage-devel] Re: possible issue with DiGraph in interval fields

Yes, Nathan I see, that may also be an issue. However, in looking further into my particular example, it *shouldn't* be returning that those projective points are ==. I opened a bug (#17429) and will fix it soon. On Monday, December 1, 2014 1:54:28 PM UTC-5, Nathann Cohen wrote: With that in

[sage-devel] help with QQbar conversion to complex number

I'm having trouble with getting a complex approximation to a QQbar number. We're working with symmetric polynomials of multipliers of periodic points, so the numbers generated are complicated and the failure occurs fairly far along in the computation, so the code to generate the error is a

Re: [sage-devel] help with QQbar conversion to complex number

Thanks Vincent. I can give that a try. We did try to approximate earlier with CC and the errors were compounding too much (we do a bunch more stuff after this), but maybe approximating the roots with CIF will do a better job. It sounds like the recursion depth error is actually expected for

Re: [sage-devel] help with QQbar conversion to complex number

applying d) will have a bunch of repeat values, but there will be some minor precision differences. We need to remove those duplicates. On Monday, November 24, 2014 2:54:24 PM UTC-5, Ben Hutz wrote: Thanks Vincent. I can give that a try. We did try to approximate earlier with CC and the errors were

[sage-devel] affine_patch and projective_embedding

I'm working on Trac:16838 to clean up/fix the affine_patch and projective_embedding functionality. It is all reasonably straight forward so far, but there was an existing behavior that I've come across that I'd like to change, so I'm checking in here to see if there is a particular reason why

[sage-devel] Re: affine_patch and projective_embedding

The current code takes an integer as coordinate input and uses the associated affine space - projective space embedding and changes the defining polynomials of the subscheme appropriately. I'm not proposing changing how that works. I'm proposing allowing the input of the ambient projective

[sage-devel] Re: help with save/load

Yes, I have done that and what appears to be happening is that the first time __setstate__ is called it is called with (parent,dict1) where parent is the projective space and dict1 is the attributes of point 1. The second time it calls __setstate__(dict1,dict2) instead of (parent,dict2). This

[sage-devel] Re: help with save/load

, Ben Hutz wrote: I'm working on points and morphisms of projective space with #15780 and I've come across an issue that is related to save/load. So, I've been experimenting try to see what works and what doesn't and I've come to the conclusion that I don't really know how it works. Here

[sage-devel] help with save/load

I'm working on points and morphisms of projective space with #15780 and I've come across an issue that is related to save/load. So, I've been experimenting try to see what works and what doesn't and I've come to the conclusion that I don't really know how it works. Here are two examples, one

Re: [sage-devel] Error when using fast_callable with PowerSeriesRing element

to (type,value) if there was no parent. But thought that the simpler (type,value) is probably sufficient. On Tuesday, April 1, 2014 12:52:27 PM UTC-4, Ben Hutz wrote: Adjusting the constant cache sounds like a much more appealing solution to our particular problem, as we are having trouble

Re: [sage-devel] Error when using fast_callable with PowerSeriesRing element

Actually, it seems that _coerce_map_from works just fine allowing you to send an integer into the power series ring. What is broken is recognizing that the powerseries element is an integer even though T(1)==1 returns true. I've been looking around at __init__ in the Integer class

Re: [sage-devel] Error when using fast_callable with PowerSeriesRing element

Bruin wrote: On Tuesday, April 1, 2014 7:27:26 AM UTC-7, Ben Hutz wrote: Actually, it seems that _coerce_map_from works just fine allowing you to send an integer into the power series ring. What is broken is recognizing that the powerseries element is an integer even though T(1)==1 returns

Re: [sage-devel] Error when using fast_callable with PowerSeriesRing element

I've spent some time looking through the fast_callable.pyx file and here is what I think the issue is. The expression builder keeps track of the 'constants' it has come across so far in a dictionary. When it gets to a new power (or constant) it first checks if it is in the dictionary and uses

[sage-devel] Re: parallel_iter leaving child processes

will kill left-over process. Though I agree with you that it is better to not crap into the living room in the first place. On Monday, March 17, 2014 8:28:40 PM UTC-4, Ben Hutz wrote: Just wanted a sanity check from someone more familiar with the parallel code. I'm reviewing #15966

[sage-devel] parallel_iter leaving child processes

Just wanted a sanity check from someone more familiar with the parallel code. I'm reviewing #15966 and the change is basically to clean up the child processes used for parallelization. As far as I could tell no one is calling this anywhere in the code base (until we are in #15920) so perhaps

Re: [sage-devel] sage5.11 long test errors

yes, that is where I had started the tests. I ran a couple of the individual files after backing out a directory and they both passed. I'll rerun the full test again from there. Thanks. -- You received this message because you are subscribed to the Google Groups sage-devel group. To

[sage-devel] Re: sage5.11 long test errors

/python2.7/site-packages/sage/doctest/sources.py, line 236, in _create_doctests self._init() AttributeError: 'FileDocTestSource' object has no attribute '_init' On Friday, August 16, 2013 6:06:16 PM UTC-4, Ben Hutz wrote: I went to install sage 5.11 on my Ubunutu 12.04 64bit system and it seems

[sage-devel] sage5.11 long test errors

I went to install sage 5.11 on my Ubunutu 12.04 64bit system and it seems to have built fine, but the long test gives me the following failures sage -t --long __init__.pyc # AttributeError in doctesting framework sage -t --long env.pyc # AttributeError in doctesting framework sage -t --long

[sage-devel] sage-days ?52? arithmetic and complex dynamics

there (general topics of number theory and algebraic varieties). Anyone interested in these topics is encourage to attend and we have some funding for travel and lodging. See the wiki page or send me an e-mail if you have any questions. Sincerely, Ben Hutz -- You received this message because

[sage-devel] Re: Does anyone use SAGE_LOAD_ATTACH_PATH?

I have used it in the past, but not for anything essential. As long as there was support for a search path, that would be fine for me. On Tuesday, May 14, 2013 4:49:06 AM UTC-5, Volker Braun wrote: The plan would still be to support a search path, just not look at (undocumented) shell

[sage-devel] plugin,startup_modules failure

I'm trying to fix a plug-in failure for #14217 and I can't seem to find any information on what the error is. Below is the diff from the plug-in. The only thing that I can see is that it is not listing projective.projective_rational_point as a new module generic.rational_points as removed and

[sage-devel] Re: plugin,startup_modules failure

is great for code maintainability but hurts startup time. Especially if you refactor code you should switch to lazy imports if possible. On Monday, May 13, 2013 2:27:32 PM UTC+1, Ben Hutz wrote: I'm trying to fix a plug-in failure for #14217 and I can't seem to find any information on what

[sage-devel] _test_enough_doctests() miss count?

I just rebased trac #14217 http://trac.sagemath.org/sage_trac/ticket/14217for sage.5.10.beta1, but I'm having an issue with the doctest in sage/doctest/source.py for the function _test_enough_doctests() It is also getting: There are 4 tests in sage/schemes/projective/projective_point.py

Re: [sage-devel] _test_enough_doctests() miss count?

being run, feel free to add There are 4 tests in sage/schemes/projective/projective_point.py that are not being run to the expected output of _test_enough_doctests. David On Mon, May 6, 2013 at 6:06 PM, Ben Hutz bn4...@gmail.com javascript:wrote: I just rebased trac #14217http

Re: [sage-devel] _test_enough_doctests() miss count?

It seems the newline character \ was causing them to be skipped. So, this is all good now. On Monday, May 6, 2013 9:20:40 PM UTC-6, Ben Hutz wrote: Thanks that helped. Actually, it does appear that four tests are not being run, but I'm not sure why. Is it because the class code is just

[sage-devel] Re: matrix multiplication weird coercion

hmm. I just tried this again on my desktop (OSX 10.8) with sage 5.8. Here the patches fail to apply on a clean clone. for the psuedo-conway patch I get: failed to synchronize metadata for sage/rings/finite_rings/constructor.py If I forge on regardless with the other two, then I get the same

[sage-devel] Re: matrix multiplication weird coercion

The patches apply just fine on my Ubuntu system, but I'm still getting the same results N=matrix(QQ,[[1,1],[0,1]]) T=matrix(GF(7),[[1,1],[0,1]]) L=N*T L,L.parent() ([0 0] [0 0], Full MatrixSpace of 2 by 2 dense matrices over Ring of integers modulo 1) Just to be clear I applied the three

[sage-devel] Re: matrix multiplication weird coercion

Never mind. Apparently, my .patch files didn't download correctly. After grabbing new versions, this *is* fixed in #8335 for me. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send

[sage-devel] matrix multiplication weird coercion

I came across some behavior with matrix multiplication that doesn't seem very intuitive to me. N=matrix(QQ,[[1,1],[0,1]]) T=matrix(GF(7),[[1,1],[0,1]]) L=N*T L,L.parent() produces ([0 0] [0 0], Full MatrixSpace of 2 by 2 dense matrices over Ring of integers modulo 1) I tried to search for

Re: [sage-devel] Re: matrix multiplication weird coercion

Nope. With the three patches in #8335, I'm still getting the same behavior on sage 5.8. Could you double check me on that? If there isn't anywhere else that this is fixed in, I can open a separate bug. On Tuesday, April 9, 2013 5:54:55 PM UTC-4, David Roe wrote: I think this issue is

[sage-devel] Re: register_unpickle_override help requested

Ok, I've tried that and tracked down the problem. Apparently the files I removed from schemes/generic/ are still showing up in /sage-5.8/local/lib/python2.7/site-packages/sage/schemes/generic so it is having conflicting imports for the projective point class. The files were removed with 'hg

[sage-devel] Re: register_unpickle_override help requested

, March 20, 2013 4:22:37 PM UTC+1, Ben Hutz wrote: Ok, I've tried that and tracked down the problem. Apparently the files I removed from schemes/generic/ are still showing up in /sage-5.8/local/lib/python2.7/site-packages/sage/schemes/generic so it is having conflicting imports

[sage-devel] register_unpickle_override help requested

I had a patch for 5.7 that reorganizes some of the scheme code (#14217) and it worked fine there. When I rebased it for 5.8 today, I am having a register_unpickle_override failure(). At least that is what I assume is failing. I unfortunately, know almost nothing about unpickleing. I would

[sage-devel] Re: splitting dynamics functionality in morphism.py into separate files

I took a quick look at 8335 and it doesn't look like there would be any conflict in the changesets. On Monday, March 4, 2013 4:29:08 AM UTC-5, Jean-Pierre Flori wrote: On Sunday, March 3, 2013 7:57:11 PM UTC+1, Ben Hutz wrote: As some of you are aware the (arithmetic) dynamical systems

[sage-devel] splitting dynamics functionality in morphism.py into separate files

for a significant amount of dynamics functionality. But, as this proposal is more than just implementing a couple functions, I am seeking the input/experience of sage-devel. I look forward to your input. Sincerely, Ben Hutz -- You received this message because you are subscribed to the Google

[sage-devel] .subs for fraction field of polynomials over QQbar

I seem to be getting a weird result when I use .subs over QQbar: R.x,y,c=PolynomialRing(QQbar,3) Y=(x^4*y + 2*c*x^2*y^3 - x*y^4 + (c^2 + c)*y^5)/(x^2*y - x*y^2 +c*y^3) fm=[x^2 + c*y^2, y^2] W1=Y.subs({x:fm[0],y:fm[1]}) Yn=Y.numerator().subs({x:fm[0],y:fm[1]})

[sage-devel] Re: .subs for fraction field of polynomials over QQbar

Thanks! This does explain what I was seeing, I forgot that the new variables for the fraction field ring may really be new, so as you say, the substitution wasn't being done. I have no problem using call() in what I was doing, but I couldn't figure out the behavior of .subs. -- You received

[sage-devel] Re: sage5.5 build error 10.8.2

Thanks. It succeeded after I forced a rebuild on python. On Wednesday, January 9, 2013 3:26:07 PM UTC-5, Volker Braun wrote: You need to rebuild from scratch, the real error was during the Python compilation. On Wednesday, January 9, 2013 8:13:46 PM UTC, Ben Hutz wrote: This doesn't work

[sage-devel] sage5.5 build error 10.8.2

I am on OSX 10.8.2 and just installed the new Xcode 4.5.2 I had the same problem with mercurial as encountered in https://groups.google.com/forum/?fromgroups=#!searchin/sage-devel/10.8$20build$20cython/sage-devel/kfXamuej_Gs/kLUoIxrQnYMJ and the suggested fix worked. Now it has failed to build

[sage-devel] Re: sage5.5 build error 10.8.2

Palmieri wrote: On Wednesday, January 9, 2013 10:45:32 AM UTC-8, Ben Hutz wrote: I am on OSX 10.8.2 and just installed the new Xcode 4.5.2 I had the same problem with mercurial as encountered in https://groups.google.com/forum/?fromgroups=#!searchin/sage-devel/10.8$20build$20cython/sage

[sage-devel] Re: sage5.5 build error 10.8.2

=-DOS_OBJECT_USE_OBJC=0 export CFLAGS make On Wednesday, January 9, 2013 6:45:32 PM UTC, Ben Hutz wrote: I am on OSX 10.8.2 and just installed the new Xcode 4.5.2 I had the same problem with mercurial as encountered in https://groups.google.com/forum/?fromgroups=#!searchin/sage-devel

[sage-devel] Re: Possible bug in polynomial .reduce()

This was a cross post, but I didn't realize the original discuss wouldn't be included. The discussion is at https://groups.google.com/forum/?fromgroups=#!topic/sage-support/Ar7z2b5cOic and, at its simplest, is that R.y1,y2=PolynomialRing(Qp(5) ,2, order='lex') G=[y1^2 + y2^2, y1*y2 + y2^2,

[sage-devel] Is this a bug in multipoly _div_?

The following works sage: R.t=PolynomialRing(QQ) sage: S.x=PolynomialRing(R) sage: x/S(2) x/2 The following does not sage: R.t=PolynomialRing(QQ) sage: S.x,y=PolynomialRing(R) sage: x/S(2) Traceback (most recent call last): ... AttributeError: 'int' object has no attribute 'parent'

[sage-devel] Re: Is this a bug in multipoly _div_?

That seems like it fixes the symptoms, but I'm not sure if it is the source of the problem. For example, the following already works without the fix. sage: R.s,t=PolynomialRing(QQ) sage: S.x,y=PolynomialRing(R) sage: x/S(2) 1/2*x That being said, I wasn't able to come up with an example

[sage-devel] dynamics on projective space

I've written some experimental patches see (http://wiki.sagemath.org/dynamics/ArithmeticAndComplex) on moving functionality for dynamics on projective spaces into sage. When I finished I had a thought that I'd like to gather some comments on from more experienced sage developers. I've

[sage-devel] Re: patch 'failed to synchronize metadata'

It was created with hg export. I just copied out the portion for the relevant file to post (the whole patch is on trac #13120). I thought from Volker's comment that the diff ... was the metadata. Based on your comment, that seems to not be the case. What portion of the patch is the metadata

[sage-devel] Re: patch 'failed to synchronize metadata'

Yes, is was the mail program that wrapped those lines. The whole patch is quite long, so I think a link to it is better http://trac.sagemath.org/sage_trac/ticket/13130 As it is only this one machine that seems to be giving this error, the md5 idea is a good suggestion. -- -- To post to

[sage-devel] Re: patch 'failed to synchronize metadata'

ok, thanks. I'll see what the md5 result is. -- -- 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:

[sage-devel] patch 'failed to synchronize metadata'

I have someone testing one of my patches and hg qpush -v returned the error failed to synchronize metadata for sage/schemes/elliptic_curves/ell_point.py I have no idea what might cause this and couldn't find any old topics about it. What might cause a failure like this and/or how could I

[sage-devel] Re: patch 'failed to synchronize metadata'

I don't think I'm copying or moving the file. Below is the info from the .patch file for ell_point.py. Also, there is only one machine that is getting this error. diff --git a/sage/schemes/elliptic_curves/ell_point.py b/sage/schemes/elliptic_curves/ell_point.py ---

[sage-devel] Re: polynomial resultant problem

an enhancement. On Mar 26, 7:45 pm, Nils Bruin nbr...@sfu.ca wrote: On Mar 25, 6:52 pm, Ben Hutz bn4...@gmail.com wrote: According to the documentation, f.resultant(g) should be computing f.resultant(g,parent(f)), which is exactly m.determinant(). If you want to compute the resultant of the two

[sage-devel] Re: seg fault in ideal containment

Sounds good. Thanks. On Mar 26, 1:34 am, Simon King simon.k...@uni-jena.de wrote: On 2012-03-26, Simon King simon.k...@uni-jena.de wrote: So, it is a bug, and I am about to open a trac ticket for it. It ishttp://trac.sagemath.org/sage_trac/ticket/12748 Cheers, Simon -- To post to this

[sage-devel] Re: .coefficient() inconsistency

opps, I should have read the docs on that one. On Mar 26, 1:14 am, Simon King simon.k...@uni-jena.de wrote: Hi Ben, On 2012-03-26, Ben Hutz bn4...@gmail.com wrote: In working with polynomials R.x,y=PolynomialRing(ZZ) F=x^2*y-2*x^2-x print F.coefficients()[0].parent() print

[sage-devel] Re: All known bugs in Sage silently producing wrong answers

I'd like to add the resultant problem I posted to sage-devel yesterday. It sounds like it is an actual bug, but not filed. When my trac account gets approved I'll file a bug for it. On Mar 21, 2:56 pm, William Stein wst...@gmail.com wrote: Hi Proud Sage Developers, At the current Sage

[sage-devel] is_PrimeField error

Hi all, I'm fairly new to sage and have been developing some tools for arithmetic dynamics over projective and affine spaces this semester. I met william stein last week and am starting to get actually set-up to get involved in Sage. First things first is to post the (potential) bugs I've come

[sage-devel] .coefficient() inconsistency

In working with polynomials R.x,y=PolynomialRing(ZZ) F=x^2*y-2*x^2-x print F.coefficients()[0].parent() print F.coefficient({x:2,y:1}).parent() The first returns the base ring (ZZ) and the second the multivariable polynomial ring. I can definitely see that since you could call

[sage-devel] polynomial resultant problem

The resultant of two homogeneous polynomials can return an incorrect value: R.x,y=PolynomialRing(ZZ) f=6*x^2 + x*y + y^2 g=y^2 print f.resultant(g) m=matrix([[6,1,1,0],[0,6,1,1],[0,0,1,0],[0,0,0,1]]) m.determinant() notice that the coefficient of the f.resultant(g) does not match the integer

[sage-devel] symmetric polynomial decomposition problem

There are two parts to this: First is that a constant term (e[]) cannot be expanded R.x,y=PolynomialRing(QQ) g=x+y+1 Sym = SymmetricFunctions(QQ) e=Sym.e() #elementary symmetric functions m = Sym.m() gm=m.from_polynomial(g) e(gm).expand(2) ValueError: max() arg is an empty sequence

[sage-devel] Re: is_PrimeField error

to practice your new developer skills by opening a ticket and submitting a patch?  I'll review it David On Mon, Mar 26, 2012 at 02:41, Ben Hutz bn4...@gmail.com wrote: Hi all,  I'm fairly new to sage and have been developing some tools for arithmetic dynamics over projective

[sage-devel] seg fault in ideal containment

I almost forgot about my 5th one: a seg fault. I'm running 'Sage Version 4.8, Release Date: 2012-01-20' on an intel processor on Ubuntu 11.10 R.x0=PolynomialRing(ZZ,1) F=x0^4-2*x0^2-x0 R.x0,y0,z0,x1,y1,z1,a0,a1,a2,a3,a4,a5,a6,a7,a8=PolynomialRing(QQ,order=TermOrder('degrevlex', 6) +

  1   2   >