[sage-devel] Re: Is this a bug?
On Thursday, September 22, 2022 at 5:29:41 AM UTC+2 Travis Scrimshaw wrote: > No, it is not. The generic fraction field can only reduce something up to > a unit since the gcd is defined up to a unit. I agree it looks funny, but I > don't see a sensible way to code to get a negative sign in the numerator. > Rings could define canonical units where that makes sense. This is how Nemo does it, for example: http://nemocas.github.io/Nemo.jl/stable/fraction/ Fredrik -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1e75085b-c721-4ba5-9517-190e1a8fba23n%40googlegroups.com.
[sage-devel] Re: Is this a bug?
No, it is not. The generic fraction field can only reduce something up to a unit since the gcd is defined up to a unit. I agree it looks funny, but I don't see a sensible way to code to get a negative sign in the numerator. Compare with sage: ~F(-q+1) 1/(-q + 1) sage: ~F(q-1) 1/(q - 1) sage: -1 / F(-q+1) (-1)/(-q + 1) sage: -1 / F(q-1) (-1)/(q - 1) Of course, there are two distinct elements here, but which ones are the "correct" way to print stuff? Not to mention if we are doing something in a more general integral domain (or polynomials with a completely different implementation). Something could be done when the denominator is a unit not equal to one though. Possibly only in the printing however (i.e., not in the reduce() method and its internal representation) in order to reduce the amount of computations when manipulating such elements. Best, Travis On Wednesday, September 21, 2022 at 10:22:30 PM UTC+9 axio...@yahoo.de wrote: > sage: R. = QQ[] > sage: F = R.fraction_field() > sage: ~F(-1) > 1/(-1) > sage: 1/F(-1) > -1 > sage: R. = QQ[] > sage: F = R.fraction_field() > sage: ~F(-1) > -1 > -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/8b17a45a-c067-45b6-a2e5-5cbd80f8d6f6n%40googlegroups.com.
[sage-devel] Re: Is this a bug?
Thank you, that explains the behavior.
- Mihai
On Saturday, April 18, 2020 at 6:00:50 PM UTC+10, Markus Wageringel wrote:
>
> Am Donnerstag, 16. April 2020 13:39:39 UTC+2 schrieb Mihai:
>>
>> fn = diff(FN(x,n), x)
>> mean(n) = integral(fn(x, n), (x, 0, oo))
>>
>
> The main problem with this is that `fn` is just an expression, not a
> function of `(x, n)`. The call `fn(x, n)` switches the position of x and n,
> as apparently the arguments of the expression are listed in alphabetical
> order.
>
> sage: fn
> n*(1/(e^(-x) + 1))^(n - 1)*e^(-x)/(e^(-x) + 1)^2
> sage: fn.arguments()
> (n, x)
> sage: fn(x, n)
> x*(e^(-n) + 1)^(-x + 1)*e^(-n)/(e^(-n) + 1)^2
>
> With that in mind, replacing `fn(x, n)` by just `fn` in the integral leads
> to the output that Michael obtained, so apparently Sage (or Maxima) has
> difficulties to compute this integral symbolically for all n. However, if
> you replace n by an actual integer before integrating, you get better
> results:
>
> sage: F(x)=1/(1 + exp(-x))
> sage: FN(x,n) = F(x)**n
> sage: fn = diff(FN(x,n), x)
> sage: mean = lambda k: integral(fn.subs({n: k}), (x, 0, oo))
> sage: [mean(k) for k in (1..10)]
> [1/2, 3/4, 7/8, 15/16, 31/32, 63/64, 127/128, 255/256, 511/512, 1023/1024]
>
>
--
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...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/68ef06ea-bad4-4ef2-bc84-c0ae2b66937f%40googlegroups.com.
[sage-devel] Re: Is this a bug?
Am Donnerstag, 16. April 2020 13:39:39 UTC+2 schrieb Mihai:
>
> fn = diff(FN(x,n), x)
> mean(n) = integral(fn(x, n), (x, 0, oo))
>
The main problem with this is that `fn` is just an expression, not a
function of `(x, n)`. The call `fn(x, n)` switches the position of x and n,
as apparently the arguments of the expression are listed in alphabetical
order.
sage: fn
n*(1/(e^(-x) + 1))^(n - 1)*e^(-x)/(e^(-x) + 1)^2
sage: fn.arguments()
(n, x)
sage: fn(x, n)
x*(e^(-n) + 1)^(-x + 1)*e^(-n)/(e^(-n) + 1)^2
With that in mind, replacing `fn(x, n)` by just `fn` in the integral leads
to the output that Michael obtained, so apparently Sage (or Maxima) has
difficulties to compute this integral symbolically for all n. However, if
you replace n by an actual integer before integrating, you get better
results:
sage: F(x)=1/(1 + exp(-x))
sage: FN(x,n) = F(x)**n
sage: fn = diff(FN(x,n), x)
sage: mean = lambda k: integral(fn.subs({n: k}), (x, 0, oo))
sage: [mean(k) for k in (1..10)]
[1/2, 3/4, 7/8, 15/16, 31/32, 63/64, 127/128, 255/256, 511/512, 1023/1024]
--
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...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/1a316463-c289-48ec-881b-e48324117b15%40googlegroups.com.
[sage-devel] Re: Is this a bug or is it intended?
On Wednesday, October 2, 2013 1:07:21 PM UTC-7, mmarco wrote: > > I get it, thanks. > Actually, all the errors around failed conversions seem a little rough: sage: M=matrix([[1,2],[3,4]]) sage: QQ(M) TypeError: rational_reconstruction() takes exactly one argument (0 given) sage: QQ.convert_map_from(parent(M)) Conversion map: From: Full MatrixSpace of 2 by 2 dense matrices over Integer Ring To: Rational Field sage: QQ.convert_map_from(parent(M))(M) TypeError: rational_reconstruction() takes exactly one argument (0 given) sage: ZZ(M) TypeError: unable to coerce to an integer sage: ZZ.convert_map_from(parent(M)) Conversion map: From: Full MatrixSpace of 2 by 2 dense matrices over Integer Ring To: Integer Ring So it seems that `convert_map_from` always returns a "map". Of course, since it defines a conversion, it might only be a partial map. Indeed it is in the above cases: it just happens to fail on its entire domain. As you can see, the error message that arises is just completely dependent on the parent and may not indicate at all that no element in the domain will ever work. -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is this a bug or is it intended?
I get it, thanks. El miércoles, 2 de octubre de 2013 18:12:42 UTC+2, Nils Bruin escribió: > > Your example looks suspicious because you're calling _unset_embeddings and > then install an embedding. That's explicitly warned against in the > documentation. > > What you're finding is that QQbar.convert_map_from(F) returns a broken > map. That happens also if you don't try to register an embedding at allI > think *that* needs fixing, and I don't think that has anything to do with > coercions. > > In fact, if you install the embedding the way you're supposed to, the > conversion seems to pick it up: > > sage: F.=NumberField(a.minpoly(),embedding=a) > sage: QQbar(b) == a > True > -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is this a bug or is it intended?
Your example looks suspicious because you're calling _unset_embeddings and then install an embedding. That's explicitly warned against in the documentation. What you're finding is that QQbar.convert_map_from(F) returns a broken map. That happens also if you don't try to register an embedding at allI think *that* needs fixing, and I don't think that has anything to do with coercions. In fact, if you install the embedding the way you're supposed to, the conversion seems to pick it up: sage: F.=NumberField(a.minpoly(),embedding=a) sage: QQbar(b) == a True -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is this a bug in schemes?
On Feb 27, 12:06 pm, Simon King wrote: > On 2013-02-27, mmarco wrote: > > > Isn't the result supposed to be over the rationals? Or am i missing > > something? > > And: > > sage: S.category() > Category of sets The __init__ is not calling super().__init__ (or whatever the appropriate spelling is) -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is this a bug in schemes?
On 2013-02-27, mmarco wrote: > Isn't the result supposed to be over the rationals? Or am i missing > something? And: sage: S.category() Category of sets Isn't this supposed to be in the category of schemes over the rationals? Cheers, Simon -- 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...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is this a bug in multipoly _div_?
On 11/13/2012 04:48 AM, Nils Bruin wrote: On Nov 12, 10:07 am, P Purkayastha wrote: +inv = self.base_ring()(1)/self.base_ring()(right) It's probably more efficient to do: inv = self.base_ring().one()/self.base_ring()(right) since it completely avoids the coercion framework for constructing 1. Thanks. I have opened #13704 with this change. http://trac.sagemath.org/13704 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Is this a bug in multipoly _div_?
On Nov 12, 10:07 am, P Purkayastha wrote: > + inv = self.base_ring()(1)/self.base_ring()(right) It's probably more efficient to do: inv = self.base_ring().one()/self.base_ring()(right) since it completely avoids the coercion framework for constructing 1. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[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.=PolynomialRing(QQ) sage: S.=PolynomialRing(R) sage: x/S(2) 1/2*x That being said, I wasn't able to come up with an example that breaks with your change. So with a change this innocuous, I'll review it as a fix of this particular problem. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Is this a bug in multipoly _div_?
On 11/13/2012 02:07 AM, P Purkayastha wrote: On 11/13/2012 01:06 AM, Ben Hutz wrote: The following works sage: R.=PolynomialRing(QQ) sage: S.=PolynomialRing(R) sage: x/S(2) x/2 The following does not sage: R.=PolynomialRing(QQ) sage: S.=PolynomialRing(R) sage: x/S(2) Traceback (most recent call last): ... AttributeError: 'int' object has no attribute 'parent' Seems to me that if the first one works, then so should the second. I searched the trac server and couldn't come up with anything on this. Thanks, Ben There is a simple fix for this (I hope). --- a/sage/rings/polynomial/multi_polynomial_element.py +++ b/sage/rings/polynomial/multi_polynomial_element.py @@ -280,7 +280,7 @@ 53 bits of precision """ if right in self.base_ring(): - inv = 1/self.base_ring()(right) + inv = self.base_ring()(1)/self.base_ring()(right) return inv*self return self.parent().fraction_field()(self, right, coerce=False) If it looks right, then I can try and open a ticket. Oh. by the way, the command works after applying this ppatch: sage: sage: R.=PolynomialRing(QQ) sage: sage: S.=PolynomialRing(R) sage: sage: x/S(2) 1/2*x -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Is this a bug in multipoly _div_?
On 11/13/2012 01:06 AM, Ben Hutz wrote: The following works sage: R.=PolynomialRing(QQ) sage: S.=PolynomialRing(R) sage: x/S(2) x/2 The following does not sage: R.=PolynomialRing(QQ) sage: S.=PolynomialRing(R) sage: x/S(2) Traceback (most recent call last): ... AttributeError: 'int' object has no attribute 'parent' Seems to me that if the first one works, then so should the second. I searched the trac server and couldn't come up with anything on this. Thanks, Ben There is a simple fix for this (I hope). --- a/sage/rings/polynomial/multi_polynomial_element.py +++ b/sage/rings/polynomial/multi_polynomial_element.py @@ -280,7 +280,7 @@ 53 bits of precision """ if right in self.base_ring(): -inv = 1/self.base_ring()(right) +inv = self.base_ring()(1)/self.base_ring()(right) return inv*self return self.parent().fraction_field()(self, right, coerce=False) If it looks right, then I can try and open a ticket. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Is this a bug in multipoly _div_?
This is yet another inconsistency with multivariate vs. univariate polynomial rings. They are implemented differently, so its easy to fall into these traps. I don't have any better idea than hope that it gets ironed out over time... On Monday, November 12, 2012 12:06:29 PM UTC-5, Ben Hutz wrote: > > The following works > > sage: R.=PolynomialRing(QQ) > sage: S.=PolynomialRing(R) > sage: x/S(2) > x/2 > > The following does not > > sage: R.=PolynomialRing(QQ) > sage: S.=PolynomialRing(R) > sage: x/S(2) > Traceback (most recent call last): > ... > AttributeError: 'int' object has no attribute 'parent' > > Seems to me that if the first one works, then so should the second. I > searched the trac server and couldn't come up with anything on this. > > Thanks, > Ben > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Is this a bug in coercion?
On Thu, Apr 28, 2011 at 11:57 AM, kcrisman wrote:
>
>
> On Apr 28, 10:49 am, Maarten Derickx
> wrote:
>> I think that somewhere the factor with which you multiply is checked
>> for being -1,0 or 1 and that that causes the problem.
>> Here is at least an easier way to reproduce the problem
>>
>> sage: var('y')
>> y
>> sage: (y*(-3.0),y*(-2.0),y*(-1.0),y*0.0,y*1.0,y*2.0,y*3.0,y*4.0)
>> (-3.00*y, -2.00*y, -y, 0, y,
>> 2.00*y, 3.00*y, 4.00*y)
>> sage: 1.0==1
>> True
>
> Yes, but my question is whether it's a bug or a feature? Sorry for
> not being clear.
I think it really boils down to the fact that the symbolic ring
doesn't understand the notion of exact vs. inexact values. E.g.
sage: 3.0*x
3.00*x
sage: 2.0*x
2.00*x
sage: 3.0*x - 2.0*x
x
- Robert
--
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: Is this a bug in coercion?
On Apr 28, 10:49 am, Maarten Derickx
wrote:
> I think that somewhere the factor with which you multiply is checked
> for being -1,0 or 1 and that that causes the problem.
> Here is at least an easier way to reproduce the problem
>
> sage: var('y')
> y
> sage: (y*(-3.0),y*(-2.0),y*(-1.0),y*0.0,y*1.0,y*2.0,y*3.0,y*4.0)
> (-3.00*y, -2.00*y, -y, 0, y,
> 2.00*y, 3.00*y, 4.00*y)
> sage: 1.0==1
> True
Yes, but my question is whether it's a bug or a feature? Sorry for
not being clear.
- 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: Is this a bug in coercion?
I think that somewhere the factor with which you multiply is checked
for being -1,0 or 1 and that that causes the problem.
Here is at least an easier way to reproduce the problem
sage: var('y')
y
sage: (y*(-3.0),y*(-2.0),y*(-1.0),y*0.0,y*1.0,y*2.0,y*3.0,y*4.0)
(-3.00*y, -2.00*y, -y, 0, y,
2.00*y, 3.00*y, 4.00*y)
sage: 1.0==1
True
On Apr 28, 3:12 pm, kcrisman wrote:
> sage: var('y,z')
> (y, z)
> sage: x = 4/5*(4*y-3)*z-1/3
> sage: 1.0*x
> 4/5*(4*y - 3)*z - 1/3
> sage: 1.2*x
> 0.960*(4*y - 3)*z - 0.400
>
> I'm not familiar enough with the goals of that to be able to say for
> sure.
> Seehttp://ask.sagemath.org/question/525/numerical-approximation-for-expr...
> for background.
>
> - 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: Is this a bug?
On Oct 17, 1:00 pm, QuantumDream wrote:
> OK, so ,there is the plot_points option, but shouldn't the default
> value of the plot_point be a function of the range?
Maybe I'm wrong, but I don't think the range is nearly as important as
the type of function. Some functions won't require many plot points
even over a very large range (a line, for example) whereas others will
require many, many plot points even over a very small range (sin(1/x)
on [0,1], for example).
regards
john perry
> Anyway, it's not a big deal for me, but maybe for my Calc students :)
>
> Best,
> -M.
>
> On Oct 17, 12:51 pm, QuantumDream wrote:
>
> > I'm running Sage4.1.1 on a 32-bit Ubuntu 9.04 laptop w/ FF, and there
> > is a HUGE difference between the outputs of the following two
> > commands:
>
> > u = var('u')
> > parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0, 50))
>
> > vs.
>
> > u = var('u')
> > parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0, 100))
>
> > The first gives what is expected, a smooth helix on the surface of a
> > cone, but the 2nd one gives a highly coarse rendition of that curve.
> > See a pic
> > here:http://www.mediafire.com/imageview.php?quickkey=yeewzcnktix&thumb=5
>
> > Can anyone confirm this?
>
> > Best,
> > -M.
--~--~-~--~~~---~--~~
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: Is this a bug?
You have to use finer mesh / more points in such cases
u = var('u')
parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0,
100),plot_points=500,viewer='tachyon')
(I tested it with viewer tachyon since I do not have java on current
machine)
Hope this helps
Robert
On 17 říj, 20:00, QuantumDream wrote:
> OK, so ,there is the plot_points option, but shouldn't the default
> value of the plot_point be a function of the range?
> Anyway, it's not a big deal for me, but maybe for my Calc students :)
>
> Best,
> -M.
>
> On Oct 17, 12:51 pm, QuantumDream wrote:
>
> > I'm running Sage4.1.1 on a 32-bit Ubuntu 9.04 laptop w/ FF, and there
> > is a HUGE difference between the outputs of the following two
> > commands:
>
> > u = var('u')
> > parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0, 50))
>
> > vs.
>
> > u = var('u')
> > parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0, 100))
>
> > The first gives what is expected, a smooth helix on the surface of a
> > cone, but the 2nd one gives a highly coarse rendition of that curve.
> > See a pic
> > here:http://www.mediafire.com/imageview.php?quickkey=yeewzcnktix&thumb=5
>
> > Can anyone confirm this?
>
> > Best,
> > -M.
--~--~-~--~~~---~--~~
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: Is this a bug?
OK, so ,there is the plot_points option, but shouldn't the default
value of the plot_point be a function of the range?
Anyway, it's not a big deal for me, but maybe for my Calc students :)
Best,
-M.
On Oct 17, 12:51 pm, QuantumDream wrote:
> I'm running Sage4.1.1 on a 32-bit Ubuntu 9.04 laptop w/ FF, and there
> is a HUGE difference between the outputs of the following two
> commands:
>
> u = var('u')
> parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0, 50))
>
> vs.
>
> u = var('u')
> parametric_plot3d( (u*sin(u), u*cos(u), u), (u, 0, 100))
>
> The first gives what is expected, a smooth helix on the surface of a
> cone, but the 2nd one gives a highly coarse rendition of that curve.
> See a pic
> here:http://www.mediafire.com/imageview.php?quickkey=yeewzcnktix&thumb=5
>
> Can anyone confirm this?
>
> Best,
> -M.
--~--~-~--~~~---~--~~
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: Is this a bug?
On Apr 13, 2008, at 9:46 PM, William Stein wrote: > > On Sun, Apr 13, 2008 at 9:37 PM, <[EMAIL PROTECTED]> wrote: >> >> sage: Q. = QQ['x,y'] >> sage: R. = Q.quo(Q.ideal(x^2 + y^2 -1)) >> sage: X/2 >> >> - >> -- >> Traceback (most recent >> call last) >> >> /home/boothby/.sage/ in () >> >> /home/boothby/.sage/element.pyx in >> sage.structure.element.RingElement.__div__ (sage/structure/ >> element.c:9080)() >> >> /home/boothby/.sage/coerce.pyx in >> sage.structure.coerce.CoercionModel_cache_maps.bin_op_c (sage/ >> structure/coerce.c:5055)() >> >> /home/boothby/.sage/element.pyx in >> sage.structure.element.RingElement.__div__ (sage/structure/ >> element.c:9063)() >> >> /home/boothby/.sage/coerce.pxi in sage.structure.element._div_c >> (sage/structure/element.c:16174)() >> >> /home/boothby/sage/local/lib/python2.5/site-packages/sage/rings/ >> quotient_ring_element.py in _div_(self, right) >> 114 if not right.is_unit(): >> 115 raise ZeroDivisionError >> --> 116 raise NotImplementedError >> 117 >> 118 def __int__(self): >> >> : >> >> >> I'd understand if I were trying to divide by a non-unit, or even >> a unit polynomial. But I'm trying to divide by a unit in the base >> ring -- shouldn't that work? Is this a problem in the coercion >> model, or is it validly not implemented? >> > > It's simply not implemented. Implement it and post a patch :-) I would add that it needs to be implemented carefully--it will be easy to create infinite loops as division creates fraction-field elements, so you can't just invert and cast. > The source code for the function _div_ that is called is > > sage: X._div_?? > Source: > def _div_(self, right): > if not right.is_unit(): > raise ZeroDivisionError > raise NotImplementedError > > which does *not* presently try to invert right if it does happen to > be a unit > in the base ring. Why? Because it's not implemented yet. > Your best bet is to either implement better functionality > for computing in quotient rings or to type > > sage: X * (1/2) > 1/2*X > > By the way, looking at the file quotient_ring_element.py, I would > bring the doctest coverage to 100% before adding or subtracting > any code from that file. Right now coverage is a terrible 24%. > > -- william > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Is this a bug?
On Sun, Apr 13, 2008 at 9:37 PM, <[EMAIL PROTECTED]> wrote: > > sage: Q. = QQ['x,y'] > sage: R. = Q.quo(Q.ideal(x^2 + y^2 -1)) > sage: X/2 > --- > Traceback (most recent call last) > > /home/boothby/.sage/ in () > > /home/boothby/.sage/element.pyx in > sage.structure.element.RingElement.__div__ (sage/structure/element.c:9080)() > > /home/boothby/.sage/coerce.pyx in > sage.structure.coerce.CoercionModel_cache_maps.bin_op_c > (sage/structure/coerce.c:5055)() > > /home/boothby/.sage/element.pyx in > sage.structure.element.RingElement.__div__ (sage/structure/element.c:9063)() > > /home/boothby/.sage/coerce.pxi in sage.structure.element._div_c > (sage/structure/element.c:16174)() > > > /home/boothby/sage/local/lib/python2.5/site-packages/sage/rings/quotient_ring_element.py > in _div_(self, right) > 114 if not right.is_unit(): > 115 raise ZeroDivisionError > --> 116 raise NotImplementedError > 117 > 118 def __int__(self): > > : > > > I'd understand if I were trying to divide by a non-unit, or even a unit > polynomial. But I'm trying to divide by a unit in the base ring -- shouldn't > that work? Is this a problem in the coercion model, or is it validly not > implemented? > It's simply not implemented. Implement it and post a patch :-) The source code for the function _div_ that is called is sage: X._div_?? Source: def _div_(self, right): if not right.is_unit(): raise ZeroDivisionError raise NotImplementedError which does *not* presently try to invert right if it does happen to be a unit in the base ring. Why? Because it's not implemented yet. Your best bet is to either implement better functionality for computing in quotient rings or to type sage: X * (1/2) 1/2*X By the way, looking at the file quotient_ring_element.py, I would bring the doctest coverage to 100% before adding or subtracting any code from that file. Right now coverage is a terrible 24%. -- william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
