I think Matthew wanted to delay this discussion until the end of the
summer, but I'd like to start it now while it is fresh on my mind. I
am currently writing the expression manipulation part of the new
tutorial (http://docs.sympy.org/tutorial/tutorial/manipulation.html),
and this issue is central
I've added my thoughts to the wiki. I'm double posting them here. These
follow Aaron's opinion section which is definitely worth a read.
### Matthew
I mostly prefer 1
- Small point but while it's fresh in your mind, `MatrixSymbol('x', 1,
2).args` can't be () easily. This is because the expres
I will add this to the wiki later. My only issue with option 3 is when
dealing with objects that need both an id/name/handle and some sympifiable
information (like unspecified number of dimensions). The MatrixSymbol is
good example.
One way around this is to implement BasicString but this will end
> Somewhat related, why should we use Integer(1) and not int(1)?
>
These create little sympy-landmines if you have to remember which things
give ints and which give Integers. e.g. Rational(2,3).q and
multiplicity(2,12) are ints so you have to be careful how you use them. If
all Integers are stored
This might have been so before the abstract base classes and the numeric
tower implemented in 2.5 or 2.6, but now Python itself has a definite
interface for checking any object whether it is complex number, real,
rational or integer.
I think the correctTM solution would be to use the build-in nume
>
> This might have been so before the abstract base classes and the numeric
> tower implemented in 2.5 or 2.6, but now Python itself has a definite
> interface for checking any object whether it is complex number, real,
> rational or integer.
>
But we support unlimited precision reals, too. If we
mpmath also supports abstract base classes. So we need just to test
`isinstance(obj, AppropriateAbstractBaseClass)`.
The idea is not to go for only python types, rather just use them where
appropriate (int instead of Integer for instance, as Integer does not bring
anything besides performance degr
There can be issues when multiplying python float and mpmath float, but
these issues exist now as well. And it is mpmath's job to take care of
them, not ours. For instance, the horrible mess for precision tracking in
evalf has no place in sympy. It is something that can be done in mpmath.
That has
2013/5/21 Stefan Krastanov
> mpmath also supports abstract base classes. So we need just to test
> `isinstance(obj, AppropriateAbstractBaseClass)`.
>
> The idea is not to go for only python types, rather just use them where
> appropriate (int instead of Integer for instance, as Integer does not b
> There can be issues when multiplying python float and mpmath float, but
>> these issues exist now as well. And it is mpmath's job to take care of
>> them, not ours. For instance, the horrible mess for precision tracking in
>> evalf has no place in sympy. It is something that can be done in mpmat
Correction to one of my previous mails:
> I think this is an argument in favor of option 3 - the ability to reuse
what python already provides, whether strings for names or base classes for
numbers.
This should have been "option 1".
On 21 May 2013 12:29, Matthew Rocklin wrote:
>
> There can
On Tue, May 21, 2013 at 4:13 AM, Ronan Lamy wrote:
> 2013/5/21 Stefan Krastanov
>>
>> mpmath also supports abstract base classes. So we need just to test
>> `isinstance(obj, AppropriateAbstractBaseClass)`.
>>
>> The idea is not to go for only python types, rather just use them where
>> appropriat
Thanks for responding. I think most of what I want to say is in
response to Matthew, but let me just mention that I agree with Ronan.
Integer is very different from int. Aside from the obvious difference
with division, every attribute and method of the classes it inherits
from are avaialble on it,
Concerning using Symbol where a name is necessary, I just wanted to know
how far I should take the idea.
For instance in the category module last year there was a lot of discussion
about the basic objects, whether they should be symbols or not, etc. If we
were refactoring this module right now, wh
What were the specific examples?
Aaron Meurer
On Tue, May 21, 2013 at 10:27 AM, Stefan Krastanov
wrote:
> Concerning using Symbol where a name is necessary, I just wanted to know how
> far I should take the idea.
>
> For instance in the category module last year there was a lot of discussion
> a
If I remember correctly one of the examples was just a named object. Not a
number, not something that can have meaningful assumptions on it, nor
something that needs any new methods. Not a complex number which is what
Symbol represents usually.
On 21 May 2013 19:55, Aaron Meurer wrote:
> What w
2013/5/21 Aaron Meurer
> Thanks for responding. I think most of what I want to say is in
> response to Matthew, but let me just mention that I agree with Ronan.
> Integer is very different from int. Aside from the obvious difference
> with division, every attribute and method of the classes it in
Ronan, with your suggestion, what if for some reason I want
`MatrixSymbol('A', 2, 2)` and `MatrixSymbol('A', 3, 3)`? What is the way to
approach this? Maybe it is just bad style to create different
"named+additional info" objects with the same name, but I do not see a
clear reason why not.
And bac
2013/5/22 Stefan Krastanov
> Ronan, with your suggestion, what if for some reason I want
> `MatrixSymbol('A', 2, 2)` and `MatrixSymbol('A', 3, 3)`?
>
Then you just create the 2 objects. I don't see why it would cause any
problem besides the printing confusion.
> What is the way to approach thi
Sorry, I was traveling and away from the computer for a while.
> So my recommendation here goes back to using Symbol as the first
> argument of MatrixSymbol. Also, the class should clearly not subclass
> from Symbol in this case (I don't remember if it already does).
MatrixSymbol does not subc
>> I suspect these people are falling into the trap of seeing the
>> simplicity of the option 1 invariant over the option 3 invariant,
>> without noticing that it really leads to more complicated code.
>
> I am clearly one of those nutheads. From their perspective it's a reasonable
> assumption t
OK, sorry for not following this for a few days. I was busy moving to Austin.
A few points:
- I like Ronan's idea of putting the info in the func. This is the
whole reason that we use expr.func instead of type(expr), so that we
can potentially make non-class head objects. This idea also opens
On Sat, May 25, 2013 at 4:38 PM, Aaron Meurer wrote:
> OK, sorry for not following this for a few days. I was busy moving to
> Austin.
>
> A few points:
>
> - I like Ronan's idea of putting the info in the func. This is the
> whole reason that we use expr.func instead of type(expr), so that we
>
Well this discussion got buried, but I still do care about it. We
should talk at SciPy too (if we have time between all the other stuff
we should talk about).
On Sun, May 26, 2013 at 8:50 AM, Matthew Rocklin wrote:
>
>
>
> On Sat, May 25, 2013 at 4:38 PM, Aaron Meurer wrote:
>>
>> OK, sorry for
24 matches
Mail list logo
