Le samedi 07 mai 2011 à 17:28 +0100, Tom Bachmann a écrit : > On 06.05.2011 17:32, Ronan Lamy wrote: > >> Notice that every element that we ever compute with belongs to some > >> algebra. > > > > Here's our fundamental disagreement, I think. Objects aren't > > intrinsically part of an algebra, they happen to belong to some set over > > which some algebraic structure is defined and used. > > > > My point is that without being part of an "algebra" (or whatever we call > it), what does an operation on objects even *mean*, let alone how the > result is represented?
And what does an "algebra" mean without its elements? People knew that 2 + 2 = 4 before Dedekind told them. Also, if I understand correctly what you're saying, you're going further than Integer(1) != Rational(1), you're implying IntegerRing(1) != IntegerAdditiveGroup(1). > Yes in principle objects are part of sets on which algebraic structures > are (or can be) defined, but for a computer program it is not really > relevant what objects "are", what is relevant is how they are > represented and manipulated. What manipulations are possible is > essentially what I described as "to what algebra does this belong". And > in particular the representation should be chosen in such a way that the > desired manipulations can be done in an efficient fashion. What objects are is relevant to a computer. The concepts of integer and floating point number and their operations are embedded in the physical structure of every CPU. Anyway, you're confusing the problem domain we're modelling (mathematics) with the actual code that models it. In Python, the thing that tells how objects are represented and manipulated is called a class. Algebras have different properties from classes and are things that should be modelled in sympy, so they have to be Python objects. > We are drifting away from assumptions here, but I would argue that in > sympy currently there are about three algebras. They are not being > properly identified as such, and they have no standardised way of > "talking to each other", which makes some things cumbersome. Here they are > > o The "calculus" algebra (Add/Mul etc), > o the matrix algebra, > o the polynomial algebras. I'm not sure how your vision of algebras relates to the current code, but there are more kinds of objects than that. You're forgetting sets, booleans, the various kinds of quantum objects, ... The "calculus algebra" is basically Expr and all its subclasses. > > Right now the first is meant to encompass everything, but a) it even > doesn't now, b) in the long-term this seems even more unlikely and c) in > any case an all-encompassing algebra can hardly be very efficient for > non-all-encompassing tasks. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
