Hi Mitesh!
On 30 Jul., 00:14, Mitesh Patel <qed...@gmail.com> wrote:
> > ... Objects of the same type can have very
> > different parents, and theoretically objects of different types can
>
> Could you please give an example? Do you mean that for a given parent
> an element could be implemented with FLINT or Singular, say?
>
> > have the same parent.
It's a bit off topic, but since you ask...
"Same type, different parent" is obvious:
sage: type(GF(2)(1))
<type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'>
sage: type(GF(3)(1))
<type 'sage.rings.finite_rings.integer_mod.IntegerMod_int'>
The parents are not only different, there is even no coercion map
available. Hence, one has
sage: GF(3)(1) == GF(2)(1)
False
"Same parent, different type":
Well, I said "theoretically". Any parent (obeying the category
framework) should have a fixed element class.
One shouldn't do it. But if one really wants, it is no problem to mess
things up, and one should be aware of the possibility.
sage: R.<x,y,z> = GF(3)[]
sage: from sage.rings.polynomial.multi_polynomial_element import
MPolynomial_polydict
sage: type(x)
<type
'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular'>
sage: fake_x = MPolynomial_polydict(R,{(1,0,0):1}); fake_x
x
sage: type(fake_x)
<class
'sage.rings.polynomial.multi_polynomial_element.MPolynomial_polydict'>
sage: fake_x.parent() is x.parent()
True
The example shows that one can construct objects of different type
with the same parent. But it also shows that it usually is a bad idea:
sage: x == fake_x # arguable
False
Worse is the other way around:
sage: fake_x == x
Traeback (most recent call last):
...
AttributeError:
'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular'
object has no attribute '_MPolynomial_element__element'
Ouch! Shouldn't comparison in Python never result in an exception?
The worst is:
sage: x+fake_x
------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).
------------------------------------------------------------
I guess this is since, when adding elements, it is only tested that
both summands have the same parent. If it is the case, then _add_ is
called. There, one can assume that both arguments have the same parent
(which is guaranteed), and usually it is implicitly assumed that they
also have the same type (which is not guaranteed, but usually true).
This may seem like a theoretical construction. But, if I remember
correctly, recently at Sage Days 24 in Linz, someone had a problem
where essentially the same mess (same parent, different type) happened
in reality.
So, don't try this at home...
Cheers,
Simon
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org
