[sage-devel] Coercion between quadratic fields fails (by default)

The following leads to a TypeError: sage: K2. = QuadraticField(2) sage: K3. = QuadraticField(3) sage: sqrt2 + sqrt3 Both of them are real embedded by default, so coercion should work (at least this is my opinion). This can be fixed by specifying that both of them are embedded into the algebr

Re: [sage-devel] Coercion for multi-variate polynomials

On 2018-06-12 17:24, John Cremona wrote: OK, but having an easy way to produce the above maps would be very helpful. Sure. They just wouldn't be *coercion* maps. Coercion maps should be used with care, since they are used automatically. For example, as a consequence of the bug in my previous

Re: [sage-devel] Coercion for multi-variate polynomials

On 12 June 2018 at 15:24, Jeroen Demeyer wrote: > Sometimes you start working on a ticket thinking "this is just a few hours > of work" when it turns out to be a huge can of worms... > > Coercion for multi-variate polynomials might fall in this category. There > are several strange things and bug

[sage-devel] Coercion for multi-variate polynomials

Sometimes you start working on a ticket thinking "this is just a few hours of work" when it turns out to be a huge can of worms... Coercion for multi-variate polynomials might fall in this category. There are several strange things and bugs. The best example so far: sage: R. = QQ[] sage: QQ["

[sage-devel] coercion cache in doctests not erased

Hi, a doctest in line 1051 of parent.pyx indirectly can influence the doctest in line 1514 which checks the coercion cache. While I could change the latter doctest, is there either 1) a way to completely erase that cache, or 2) a way to restart Sage doctesting within one file to get a fresh inst

Re: [sage-devel] Coercion about finite field extensions, again

This is now https://trac.sagemath.org/ticket/24195 I regard this behavior as a bug. -- 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 an email to sage-devel+unsubscr...@google

Re: [sage-devel] Coercion about finite field extensions, again

On Thursday, November 9, 2017 at 6:17:41 PM UTC+9, John Cremona wrote: > > On 9 November 2017 at 00:50, Kwankyu Lee > > wrote: > > Hi, > > > > From a discussion last year, I know that creation of finite fields with > > generator names is different from without generator names. But still the

Re: [sage-devel] Coercion about finite field extensions, again

On 9 November 2017 at 00:50, Kwankyu Lee wrote: > Hi, > > From a discussion last year, I know that creation of finite fields with > generator names is different from without generator names. But still the > following is counter-intuitive. > > sage: k=GF(4) > sage: K=k.extension(3, name='a') > sage

[sage-devel] Coercion about finite field extensions, again

Hi, >From a discussion last year, I know that creation of finite fields with generator names is different from without generator names. But still the following is counter-intuitive. sage: k=GF(4) sage: K=k.extension(3, name='a') sage: k.is_subring(K) False sage: L=k.extension(3) sage: k.is_subr

[sage-devel] coercion failure?

See https://trac.sagemath.org/ticket/21777 for a surprising (to me) relict of what appears to be coercion failure - I don't know who is around who is an expert in this and might be able to diagnose it, hopefully someone here is. -- You received this message because you are subscribed to the Go

Re: [sage-devel] Coercion to interfaces

On Sunday, July 24, 2016 at 2:38:44 PM UTC+1, vdelecroix wrote: > > On 24/07/16 05:13, Dima Pasechnik wrote: > > I believe that the work on libGAP interface might better wait for GAP > > folks to come up with their own libGAP. They refused to merge "our" > > libGAP, and they say they have thei

Re: [sage-devel] Coercion to interfaces

On Sun, Jul 24, 2016 at 6:38 AM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > On 24/07/16 05:13, Dima Pasechnik wrote: >> >> I believe that the work on libGAP interface might better wait for GAP >> folks to come up with their own libGAP. They refused to merge "our" >> libGAP, and they say

Re: [sage-devel] Coercion to interfaces

On 24/07/16 05:13, Dima Pasechnik wrote: I believe that the work on libGAP interface might better wait for GAP folks to come up with their own libGAP. They refused to merge "our" libGAP, and they say they have their own version in the works, which they need to create a Jupyter kernel for GAP. I

[sage-devel] Coercion to interfaces

I believe that the work on libGAP interface might better wait for GAP folks to come up with their own libGAP. They refused to merge "our" libGAP, and they say they have their own version in the works, which they need to create a Jupyter kernel for GAP. Dima -- You received this message becau

[sage-devel] Coercion to interfaces

Hey all, On https://trac.sagemath.org/ticket/18266, Vincent and I are having a discussion about how much coercion an interface, GAP in this particular instance, should have. PARI currently has everything being able to coerce in. GAP currently only has select rings, but Vincent's proposal is t

Re: [sage-devel] Coercion between finite fields

On 2015-09-17 12:32, Jean-Pierre Flori wrote: Don't we have a random keyword as well? Not a random keyword, but a modulus="random" argument (there are several more algorithms to choose a modulus) -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] Coercion between finite fields

On Thursday, September 17, 2015 at 12:24:07 PM UTC+2, Jeroen Demeyer wrote: > > On 2015-09-17 11:56, Volker Braun wrote: > > Two comments: > > > > A) There is no such thing as "different finite fields of the same size > > with the same generator name" > > Of course there is: > > sage: GF(8,

Re: [sage-devel] Coercion between finite fields

On 2015-09-17 11:56, Volker Braun wrote: Two comments: A) There is no such thing as "different finite fields of the same size with the same generator name" Of course there is: sage: GF(8, 'a') is GF(8, 'a', modulus="adleman-lenstra") False -- You received this message because you are subscri

Re: [sage-devel] Coercion between finite fields

Two comments: A) There is no such thing as "different finite fields of the same size with the same generator name" sage: GF(4, 'a') is GF(4, 'a') True sage: GF(4, 'a') is GF(4, 'b') False There is no way to cast finite field elements to other finite field elements apart from the prime subfiel

Re: [sage-devel] Coercion between finite fields

> The question is really: is the map between representations of the same > finite field, which differ only in variable name, "canonical"? I would say that there is no big risk to do that, though I am not at all knowledgeable on those parts of the code. If it can be dangerous but can be detected, h

Re: [sage-devel] Coercion between finite fields

On 2015-09-16 16:43, Jean-Pierre Flori wrote: Hi, I guess one of the issue is that there is no canonical map between two different representations of the same finite field (so no coercion). The question is really: is the map between representations of the same finite field, which differ only

Re: [sage-devel] Coercion between finite fields

>> If it is "doable", then indeed it would solve my problem and (to me) >> does not seem to induce any tricky behaviour. > > In this case: > > sage: [x.polynomial() for x in K1] > [0, a, a^2, a + 1, a^2 + a, a^2 + a + 1, a^2 + 1, 1] > sage: [K2(x.polynomial()) for x in K1] > [0, b, b^2, b + 1, b^2

Re: [sage-devel] Coercion between finite fields

On 16 September 2015 at 15:52, Nathann Cohen wrote: > Hello, > >> In your case it is slightly more specific as it might be the case that K1 >> and K2 are constructed in the same exact way (expect for the string 'a' and >> 'b') so we could just decide to send "a" onto "b", but I'm not sure it is

Re: [sage-devel] Coercion between finite fields

Hello, > In your case it is slightly more specific as it might be the case that K1 and > K2 are constructed in the same exact way (expect for the string 'a' and 'b') > so we could just decide to send "a" onto "b", but I'm not sure it is very > helpful to define an exception in this case. If it

Re: [sage-devel] Coercion between finite fields

Hi, I guess one of the issue is that there is no canonical map between two different representations of the same finite field (so no coercion). In your case it is slightly more specific as it might be the case that K1 and K2 are constructed in the same exact way (expect for the string 'a' and '

Re: [sage-devel] Coercion between finite fields

> > GF(4) is not a subfield of GF(8). > Oh. Right. Actually, the problem with my code happened when both finite fields were equal, and I wrote this message without thinking. sage: K1 = GF(8,'a') sage: K2 = GF(8,'b') sage: K2(K1(1)) TypeError: unable to coerce from a finite fiel

Re: [sage-devel] Coercion between finite fields

GF(4) is not a subfield of GF(8). John On 16 September 2015 at 10:16, Nathann Cohen wrote: > Hello everybody, > > I am rather ignorant of Sage matters when it comes to finite fields. I have > been playing with matrices for a while, working around a bug that I did not > understand. It is now solv

[sage-devel] Coercion between finite fields

Hello everybody, I am rather ignorant of Sage matters when it comes to finite fields. I have been playing with matrices for a while, working around a bug that I did not understand. It is now solved, but here is what it boils down to: sage: K1 = GF(4,'w') sage: K2 = GF(8,'x') sage: K2(

[sage-devel] coercion of objects embedded in symbolic expressions

Hello, a long standing issue is sage: bool(pihttp://trac.sagemath.org/ticket/12967 at which I'm having a naive stab (because it interferes with #14801). Maybe I can learn something? In the ticket the problem has been said having to do with Pynac, but I don't think so. It would all work nicely if,

Re: [sage-devel] coercion issue

Interesting. It seems the problem is that cm.discover_action(GF(5), ZZ, operator.div) tries to look for a right action on of cm.discover_action(GF(5), Frac(ZZ), operator.mul) which doesn't exist as there are no coercions between GF(5) and QQ. I posted a patch to http://trac.sagemath.or

Re: [sage-devel] coercion issue

Hi Set x=GF(5)['x'].gen() I dunno if this helps but here is an explanation why one gets a different behavior for x/7 than cm.bin_op(x,7,operator.div): If you do "x/7" then I think it calls __div__ from polynomial_element (Polynomial class): try: if not isinstance(right, Element) or right.pa

Re: [sage-devel] coercion issue

2015-02-05 21:38 UTC+01:00, John Cremona : > If you ask for operator.mul instead of operator.div then you get the > poly ring. Is that it, perhaps? Nope. I want to get rid of many hacks in rings/polynomial. In order to do that I need the div operation to be correctly handled by the coercion (or p

Re: [sage-devel] coercion issue

If you ask for operator.mul instead of operator.div then you get the poly ring. Is that it, perhaps? John On 5 February 2015 at 18:48, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > sage: cm = sage.structure.element.get_coercion_model() > sage: cm.explain(GF(5)['x'], ZZ, operator.div) >

[sage-devel] coercion issue

sage: cm = sage.structure.element.get_coercion_model() sage: cm.explain(GF(5)['x'], ZZ, operator.div) Coercion on right operand via Composite map: From: Integer Ring To: Univariate Polynomial Ring in x over Finite Field of size 5 Defn: Natural morphism: From:

[sage-devel] Coercion after _eval_() of symbolic functions (#17130)

Could somebody who knows about numerical evaluation of symbolic functions please have a look at #17130. The problem is that there is some coercion going on *after* calling _eval_(). Look at the difference between the following two (the second has false precision): sage: bessel_Y._eval_(RealF

[sage-devel] Coercion proposal: compatible parents

Hello, Consider the following Sage session: sage: a = RR(-1) sage: b = 1.0001 sage: a + b 0.000 sage: a._add_(b) 1.03397576569128e-24 Here, the coercion model makes the output less precise than what is possible: a + b first reduces the precision of b, rounding t

[sage-devel] Coercion model not allowing coercions to be registered

Hey everyone, Currently we have the following behavior in Sage. This is okay: sage: SGA4 = SymmetricGroupAlgebra(QQ, 4) sage: SGA3 = SymmetricGroupAlgebra(QQ, 3) sage: lift = SGA4.module_morphism(lambda x: SGA3.zero(), codomain=SGA3) sage: SGA3.register_coercion(lift) Now startup a new sessio

Re: [sage-devel] Coercion problem ?

Salut Aladin ! Words currently do not fit well with category... (for example they do not inherit from parent). But there is #12224 that I hope to finish at Sage days 57. By the way do you plan to come ? For your problem, a stupid strategy of the conversion mechanism in Sage from X to Y is to ask

Re: [sage-devel] Coercion problem ?

> sage: W([1,2]) in ZZ > --- > NotImplementedError Traceback (most recent call last) > in () > > 1 W([Integer(1),Integer(2)]) in ZZ > [...] > > NotImplementedError: please implement _an_element_ for W

[sage-devel] Coercion problem ?

Hello everyone, here is a bug that is maybe related to coercion system to Integers in sage: sage: W = Words(4) sage: W([1,2]) word: 12 sage: W([1,2]) in QQ False sage: W([1,2]) in ZZ --- NotImplementedError

[sage-devel] Coercion ticket; link from reference manual to thematic tutorial?

Hi! This post has two purposes, namely an ad and a question. (1) I'd like to make coercion experts aware of #14711, where we are working on fixing yet another memory leak of the coercion system. Without #14711, sage: for D in xrange(2,2**30): : QuadraticField(-D); : would q

Re: [sage-devel] coercion ZZ, QQ and quadratic number field

Thanks for your answer. Le vendredi 10 mai 2013 22:15:37 UTC+2, David Roe a écrit : > > You can do: > > sage: K.=QuadraticField(2) > sage: K.register_coercion(K.coerce_map_from(QQ) * QQ.coerce_map_from(ZZ)) > > For even more speed you can write your own custom Cython coercion from ZZ > to K. > T

Re: [sage-devel] coercion ZZ, QQ and quadratic number field

You can do: sage: K.=QuadraticField(2) sage: K.register_coercion(K.coerce_map_from(QQ) * QQ.coerce_map_from(ZZ)) For even more speed you can write your own custom Cython coercion from ZZ to K. David On Fri, May 10, 2013 at 12:59 PM, vdelecroix <20100.delecr...@gmail.com>wrote: > Hi, > > Let K

[sage-devel] coercion ZZ, QQ and quadratic number field

Hi, Let K be a quadratic number field (let say K = QuadraticField(2)). There are "natural morphisms" implemented in Cython from ZZ to QQ and from QQ to K. There is also an other way, somewhat more direct, to go from ZZ to K. But at the end it is 10 times faster to go the first way and Sage does no

[sage-devel] coercion and subclasses

Jim Heffron pointed out this problem with vector space morphisms: sage: h = linear_transformation(RR^2, RR^2, matrix(RR, [[0, 1], [2, 3]])) sage: h*3 #works fine Vector space morphism represented by the matrix: [0.000 3.00] [ 6.00 9.00] Domain: Ve

[sage-devel] coercion from NumberField to ComplexIntervalField

Hi, The question [1] from ask.sagemath.org seems to be related to a coercion bug. I copy/paste the example here {{{ sage: K2. =NumberField(x^3 - 2, 's2', embedding=CC(-0.63,1.09)) sage: CIF.coerce_map_from(K) Composite map: From: Number Field in s2 with defining polynomial x^3 - 2 To: Comple

Re: [sage-devel] coercion vs conversion between polynomial rings

This is a bug in the __call__ method of multivariate polynomial rings, which doesn't respect user-defined coercions. The offending lines are 805-813 in sage/rings/polynomial/multi_polynomial_libsingular.pyx: if isinstance(element, MPolynomial_libsingular) and element.parent() is not self

[sage-devel] coercion vs conversion between polynomial rings

I think that the following behavior is wrong. sage: K=QQ['t,s'] sage: L=QQ['t0,t1,s0,s1'] sage: L.inject_variables() Defining t0, t1, s0, s1 sage: Hom(K,L)([t0+t1,s0]).register_as_coercion() sage: L.coerce_map_from(K) Ring morphism: From: Multivariate Polynomial Ring in t, s over Rational F

Re: [sage-devel] Coercion, __mul__, and infinite recursion

But the parents I'm trying to implement (polyhedra over a base ring with fixed ambient dimension) aren't an algebra. In my case, the category is class PolyhedralSets(Category_over_base_ring): def __init__(self, R): Category_over_base_ring.__init__(self, R, 'Polyhedra') def

Re: [sage-devel] Coercion, __mul__, and infinite recursion

Hi Volker, On Sun, Sep 04, 2011 at 01:10:56PM -0700, Volker Braun wrote: > I'm trying to implement actions for a custom class and I'm tripping over > this apparently old bug http://trac.sagemath.org/sage_trac/ticket/8928. > Example from the ticket: > > sage: class MyRing2(CombinatorialFre

[sage-devel] Coercion, __mul__, and infinite recursion

I'm trying to implement actions for a custom class and I'm tripping over this apparently old bug http://trac.sagemath.org/sage_trac/ticket/8928. Example from the ticket: sage: class MyRing2(CombinatorialFreeModule): ... def __init__(self): ... R = QQ ... category = (Mod

[sage-devel] Coercion issue: is this a bug?

Hello, I'm not sure if I should open a ticket on the following issue, or if this is just a case of "Error Between Keyboard And Chair". Here is a simplified version of what happened. I had parents A and B and map phi between them, as follows: sage: A = CombinatorialFreeModule(ZZ,[1,2,3],prefix='X

Re: [sage-devel] Coercion between polynomial rings

mmarco a écrit : Dealing with polynomial ringsi found something that seems incorrect sage: R=QQ['x','y'] sage: S=QQ['x']['y'] Shouldn't there be natural coercions from rings like QQ[x,y][z] or QQ[x][y][z] to QQ[x,y,z] and vice-versa? One easy way to coerce is Domain("the-expression")

[sage-devel] Coercion between polynomial rings

Dealing with polynomial ringsi found something that seems incorrect sage: R=QQ['x','y'] sage: S=QQ['x']['y'] sage: R.has_coerce_map_from(S) True sage: S.has_coerce_map_from(R) False Even if both rings are naturally isomorphic. Moreover, the .polynomial(y) method gives preciselly the natural map f

Re: [sage-devel] Coercion of inexact fields

On May 14, 2010, at 6:18 AM, Simon King wrote: Hi! I thought that when considering inexact fields (p-adic or real), a coercion map should always be from higher precision to lower precision. For reals, this holds true: sage: F1 = RealField(prec=20) sage: F2 = RealField(prec=40) sage: F1.has_

[sage-devel] Coercion of inexact fields

Hi! I thought that when considering inexact fields (p-adic or real), a coercion map should always be from higher precision to lower precision. For reals, this holds true: sage: F1 = RealField(prec=20) sage: F2 = RealField(prec=40) sage: F1.has_coerce_map_from(F2) True sage: F2.has_coerc

Re: [sage-devel] coercion model question

On Apr 20, 2010, at 5:35 PM, Jason Grout wrote: Hi all, In sage/devel/symbolic/ring.pyx, I find this in the SymbolicRing.__init__: self._populate_coercion_lists_(convert_method_name='_symbolic_') Later on, I find this in SymbolicRing._element_constructor_: elif hasattr(x,

[sage-devel] coercion model question

Hi all, In sage/devel/symbolic/ring.pyx, I find this in the SymbolicRing.__init__: self._populate_coercion_lists_(convert_method_name='_symbolic_') Later on, I find this in SymbolicRing._element_constructor_: elif hasattr(x, '_symbolic_'): return x._symbolic_(self)

Re: [sage-devel] coercion, categories, and slow code

On Dec 1, 2009, at 10:02 AM, Martin Albrecht wrote: > Hi there, > > the following code is really, really really (REALLY!) slow: > > sage: IP = InfinitePolynomialRing(QQ) > sage: x = IP.gen() > sage: x1 = x[1] > sage: %time 1/2*x1 > CPU times: user 0.86 s, sys: 0.00 s, total: 0.86 s > W

[sage-devel] coercion, categories, and slow code

Hi there, the following code is really, really really (REALLY!) slow: sage: IP = InfinitePolynomialRing(QQ) sage: x = IP.gen() sage: x1 = x[1] sage: %time 1/2*x1 CPU times: user 0.86 s, sys: 0.00 s, total: 0.86 s Wall time: 0.87 s 1/2*x1 Alright, so that was slow. Let's try somet

[sage-devel] coercion error: calling functions with vector inputs

I was looking at how to make my calc 3 calculations easier to understand by calling a multivariable function with a vector input. I ended up with a coercion error. I'm not that familiar with how to work with the coercion system. Would it be easy to make the call "f(r)" work below? Thanks,

[sage-devel] Coercion...

Hi there, I'm having trouble with coercion in sage 4.2... The following (reduced) example works with sage 4.1.2 and breaks with sage 4.2. Here is the error: File "", line 1, in bla = Essai(); bla###line 11: sage: bla = Essai(); bla File "/home/averell/.sage/tmp/wr

[sage-devel] Coercion to Integer.

Hi there, I'm writing a parent whose elements contain an attribute called value which is an Integer. I'd like to have a coercion to the integer. So I wrote the following in the __init__ method of my parent mor = Hom(self, IntegerRing())(lambda z: z.value) mor.register_as_co

[sage-devel] coercion in the developer's guide

Right now, the coercion section of Developer's guide starts off by saying **September 2008:** Much of this material is out of date. We are working on a revised version. (The relevant ticket is .) Now that we have a very nice coercion section

[sage-devel] coercion of polynomials with integer coefficients

Hello, I would like to take a create a function that takes a polynomial over the integers and returns its roots in ZZ mod p for p a prime. I want to assume the polynomial is globally defined but the prime is the argument. Here is what I have in mind but can't quite get the types right. x = var(

[sage-devel] coercion issue?

Is this a bug? sage: version() 'Sage Version 3.4.2, Release Date: 2009-05-05' sage: S. = PolynomialRing(Integers(14641)) sage: f = 1 + 9581*t sage: R = PolynomialRing(Integers(1331), "t") sage: ff = f.change_ring(R) sage: ff 264*t + 1 sage: type(f) sage: type(ff) sage: ff[0] 264*t + 1 sage: f[0

[sage-devel] Coercion, was: element of integermod is element of integer?

"Nicolas M. Thiery" writes: > > > Do you foresee any occasion to meet physically all three of us? > > > > Well, at least two of us are at FPSAC 09 at RISC. > > > > (I love all these abbreviations, it feels so french :-) > > :-) > > > (3) The interpreter makes a heuristic choice which signatu

[sage-devel] Coercion naming question

I'm glad the coercion model is starting to get discussed, implemented, and used by other people. Before it gets to popular, I would like to propose an api change. Currently, if A has an action on B (where B is not an A-module) one implements either a._l_action_ or b._r_action_. This is beca

[sage-devel] Coercion and exception handling

Dear Sage devels, dear Robert, >From #sage-devel: -- 00:54 < hivert> So one more day lost because of this #(&$%#^%$^*%#$ bug !!! I'm heading to bed. 00:55 < hivert> I'm wondering when I'll manage to add something

[sage-devel] coercion bug?

I don't know if the following error is in the vector code or the coercion system. It says it is a bug in coercion... -- | Sage Version 3.4.alpha0, Release Date: 2009-02-24 | | Type notebook() for the GUI, and

[sage-devel] Coercion documentation

I have written up extensive documentation on the coercion model at http://wiki.sagemath.org/coercion . If you find coercion baffling, confusing, or unuseful, this is especially for you. I am sure there is lots of room for improvement, as what may be obvious to me can be far from obvious to

[sage-devel] coercion of variables

Hi folks, In the process of dealing with http://trac.sagemath.org/sage_trac/ticket/4246 , I ran into some issues involving coercion of variables. I quickly realized that I don't really know what the desired behavior should be, hence this post. On one hand, William gave a very compelling example

[sage-devel] Coercion from relative to absolute number fields

Is there supposed to be a canonical coercion map between a relative number field and its associated absolute field? At present (at least, in Sage 3.1.2), there doesn't seem to be: sage: K1. = NumberField(x^3 - 2) sage: R. = PolynomialRing(K1).gen() sage: K2. = K1.extension(y^2 - a) sage: K2abs =

[sage-devel] Coercion merge, 3.0.6, 3.1 and 3.1.1

Hello folks, due to the ssmod and the gfe2 bug in Sage we really want to have a stable release out by Wednesday when William gives his talk at ISSAC. Since we don't want to cut it too short that means that I just moved all but the above two tickets to 3.1.1. Any new ticket should be a real blocke

[sage-devel] Coercion update

Some of you may be wondering how the new coercion model is coming along. After a heroic effort by many people at Dev Days 1, and a little followup work, we managed to merge the coercion branch into 3.0.3 and got all doctests to pass with the exception of /modular and /schemes/generic. It h

[sage-devel] Coercion issue between sparse and dense polynomial rings

Consider the following Sage run, from Sage 3.0.3: sage: x1 = PolynomialRing(ZZ, 'x').gen() sage: x2 = PolynomialRing(ZZ, 'x', sparse=True).gen() sage: (x1+x2).parent() Univariate Polynomial Ring in x over Integer Ring sage: (x2+x1).parent() Univariate Polynomial Ring in x over Integer Ring where

[sage-devel] coercion

Hi, Patch up for pickle jar: http://trac.sagemath.org/sage_trac/ticket/3482 -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To

[sage-devel] Coercion

Hey, If you want to log onto sage-devel, I'm working on coercion and had a few things to talk about. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For mor

[sage-devel] coercion and monoids

Hello, I'm having trouble implementing arithmetic for BooleanMonomials, which are elements of a monoid. Multiplication of BooleanMonomials work fine using the coercion model, but the following doesn't work, since there is no coercion from ZZ to BooleanMonomialMonoid. sage: P. = BooleanPolynomia

[sage-devel] Coercion trouble

Hi folks, I run into some coercion trouble when I reduce a fourier coefficient of a cusp form modulo a prime ideal. (See below.) Any idea how I can avoid this? Regards, Ifti === sage: M = ModularSymbols(77, 2) sage: s = M.cuspidal_subspace().new_subspace() sage: N = s.decomposition() sage:

[sage-devel] Coercion bug

Here is another coercion bug (or at least an inconsistency). Perhaps it is not worth fixing, given that everything is going to change. Anyway consider sage: W=NumberField(z^2+1,'s') sage: WXY.=W[] sage: a=WXY(0) sage: W(a) --

[sage-devel] Coercion and categories in SAGE

In the course of thinking about coercion for p-adic rings, fields and extensions, I've had some ideas about a different kind of coercion model to use for SAGE. It would fit into the existing coercion model, though I can see it motivating changes to the existing model. SAGE currently does quite we

[sage-devel] Coercion in multivariable polynomial rings

I sent this a little while ago but it didn't seem to go through... sorry if it appears twice. What do people think of having a canonical map between multivariate polynomial rings when one's variables are a subset of the other's? What about a subset in the same order? What about an initial subset