Hi Bill, On 2015-10-01, 'Bill Hart' via sage-devel <sage-devel@googlegroups.com> wrote: > One reason is that it easily leads to functions that are not > type-consistent. You can quite easily write functions whose output type > depends on the values, rather than the types of the inputs. This completely > screws with type inference and Jit compilation, though Julia does allow it.
That's one of the reasons why people love the category framework in Sage and why people hate the category framework in Sage: sage: M1 = MatrixSpace(ZZ, 3) sage: M2 = MatrixSpace(QQ, 3) sage: M3 = MatrixSpace(QQ, 3, 4) sage: type(M1) == type(M2) False sage: type(M2) == type(M3) False sage: M4 = MatrixSpace(Frac(QQ['x']), 3, 4) sage: type(M4) == type(M3) True sage: type(M1).__base__ == type(M2).__base__ == type(M3).__base__ == type(M4).__base__ True The reason for the above surprising behaviour: If a parent P uses the category framework (as it is supposed to), then its Python class is overridden by a dynamically created class that takes into account a Python class that is assigned to the category in which P lives (yes, Python allows that). Here, we have: sage: M1.category() Category of infinite algebras over (euclidean domains and infinite enumerated sets) sage: M2.category() Category of infinite algebras over quotient fields sage: M3.category() Category of infinite vector spaces over quotient fields sage: M4.category() Category of infinite vector spaces over quotient fields And that explains the above findings. Of course, all four matrix spaces above are instances of sage.matrix.matrix_space.MatrixSpace Best regards, 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. For more options, visit https://groups.google.com/d/optout.
