I see. I must confess I'm not deeply familiar with Polys, and also haven't even used it much yet. This idea is infact very similar to Polys. Its just that I've been able to figure out a translation to the Matrix code, thus my excitement.
On May 30, 12:13 am, Tom Bachmann <e_mc...@web.de> wrote: > How is this at all different from what Polys does? I'm not saying it's > bad, I'm just not seeing your point. Basically what you call ground > types are called domains in polys, and they are in polys/domains ... I need usable types. For example, you mentioned that one usable type is DMF, and it is in poly/polyclasses. How many other such types exist and where ? > > As far as I understand, Poly is mostly a smart wrapper that figures out > what domains to use, and translates highlevel operations on polynomials > into low-level operations. > > So the Matrix class should not /use/ Poly instances, but parallel Poly > in the sense that it is a container, figuring out what domains to use, > and dispatching operation to low-level implementations. I see your point. > Again, I should have prefixed this by saying that Mateusz is the expert > and I'm just using polys a bit... > > On 29.05.2011 20:04, SherjilOzair wrote: > > > > > > > > > Why didn't anyone think of this before ?! > > > Q : What benefits does groundtypes give ? > > A : Operations are faster, as one does not have to type-check. Each > > groundtype has its own __add__, __mul__ installed, and global Add, Mul > > are avoided. The Matrix doesn't have to worry about the zero- > > equivalence. x belong to type MYTYPE for example, the question x == 0, > > should be solved by the groundtype and not by the Matrix class. > > > Q : So, all the elements have to be of the same groundtype ? How do > > you plan to do it ? > > A : Simple. Instead of sympify-ing the vals before putting it in the > > matrix, I typify them, typify being a variable function, which the > > user/caller will provide, like this A = Matrix(..., typify = sympify) > > or A = Matrix(..., typify = poly). The Matrix constructor would then > > use A[i,j] = typify(val). > > > Q : So the matrix just needs to have a typify function ? > > A : Well, It could have another variable which says "This Matrix > > belongs to the Poly domain !". But Its just for the user. The matrix > > doesn't need to know which domain it is in (there are exceptions, keep > > reading). The Matrix shouldn't care what A[6,5] and A[7,8] types are. > > When they need to be multiplied or added, A[6,5] * A[7,8] will > > automatically the right __mul__ and similarly for addition. > > > Q : That easy ?! :O > > A : No, this can only work for 'domain-preserving algorithms'. An > > algorithm which for example employs the division or the square root, > > shouldn't/wouldn't operate on Polys. It should return an Error, > > complaining about the bad groundtype. > > OR > > We could have type-conversion. For division-employing algorithms, we > > could convert the groundtype to RationalFunction, for squareroot- > > employing algorithms, we could convert to the Expr. > > > Q : So the user has to be smart enough to know why typify function to > > use for what ? > > A : Maybe or maybe not. We can always have automatic identification > > added in later. > > > Q : What do you need from Polys for this ? > > A : Basically, I need an exhaustive set of groundtypes which in > > essence have the fundamental operators coded along with __eq__ for the > > zero-equivalence check. If someone (mattpap ?) could help me compile a > > list of groundtypes which I can extract from Polys with description of > > each and what operations it supports and, equally important, what it > > does not suuport. > > > I may have used the terms 'ground type' to mean both 'ground domain' > > and 'ground type'. But I think my meaning is clear. > > > This is just a simple idea that came in my mind which made me think > > 'why not ?'. Did I leave out/forget anything ? What does this idea > > lack ? Am I completely wrong ? > > > I think, this idea is good enough to iterate over and build on, and > > would love to see the communities' modifications and suggestions. > > > Cheers, > > Sherjil Ozair -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
