On 11/06/2018 20:04, Nils Bruin wrote:
On Monday, June 11, 2018 at 10:30:42 AM UTC-7, David Roe wrote:
The standard that I would propose is the following:
1. If R has been constructed as a localization (namely, if the
construction() method returns some kind of localization functor) then the
res
On Monday, June 11, 2018 at 8:04:56 PM UTC+2, Nils Bruin wrote:
>
> You are introducing some non-commutativity into the coercion graph that
> way, though.
>
I think that settles it: The parent of a / b must only depend on the
parents of a and b, since that is cached by the coercion system. Other
On 2018-06-12 09:24, Vincent Delecroix wrote:
Note that the ring of integers does not follow this rule since a//b
also returns something in the field but we might want to change that
See https://trac.sagemath.org/ticket/23971 for that
--
You received this message because you are subscribed to
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["
On 2018-05-25 10:00, Travis Scrimshaw wrote:
I believe the matrix and permutation groups are quite old code, so
UniqueRepresentation may not have been available at that time. The
permutation group code does need updating; in particular, it is still an
old-style parent:
See https://trac.sagemath
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
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
On Tuesday, June 12, 2018 at 7:24:45 AM UTC-7, Jeroen Demeyer wrote:
>
> I'd like to say that the following should be coercions:
> R -> R[x,y]
> R[x] -> R[x,y]
> R[y] -> R[x,y]
> R[x][y] -> R[x,y]
>
> But not the following:
> R[x,y] -> R[x][y]
> R[x,y] -> R[y,x]
> R[x,y][z] -> R[x][y,z]
>
Hi!
We are talking about rings that mathematically are multivariate
polynomial rings over a commutative ring R. So, R[x,y], R[y,x], R[x][y],
R[y][x], PolynomialRing(R,['x','y'],'lex'), PolynomialRing(R,['x','y'],
'degrevlex'),...
About conversions: They can basically be anything. But:
i) There
On 2018-06-12 23:07, Simon King wrote:
And now think about quotients of polynomial rings. Let A,B have the same
variable names in the same positions, but let the monomial orderings be
different. Let I be an ideal in A and J the corresponding ideal in B.
So, if we say that there is a name and posi
On Tuesday, June 12, 2018 at 2:09:53 PM UTC-7, Simon King wrote:
>
>
> Problem:
> It is currently possible to create the polynomial ring R[x][x]
> (hence, x occurs twice). If "x" has two different meanings in the
> same ring, the notion "name preserving map" makes no sense. I believe
> it shoul
On 2018-06-12, Jeroen Demeyer wrote:
>> However,
>> these iterated polynomial ring constructions are quite inefficient.
>
> True, but I don't see that as an argument to have no coercion.
It is, if the absence of a direct coercion triggers the construction of
a pushout that uses a more efficient i
12 matches
Mail list logo
