Hello,
On Wed, Apr 4, 2012 at 10:26 PM, Mateusz Paprocki wrote:
>
> I'm joining this discussion a little late, but let me clarify a few things.
> If you look into the source code of polys, you'll see that sometimes I use
> a*b (+, - (both), *, **), and sometimes domain.op(a, b) (e.g. QQ.quo(a, b)
Therefore, if a ring is unital by definition, I maintain that no
inheritance should be introduced between Ring and Ideal.
I concur.
--
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 unsub
On Thu, Apr 5, 2012 at 2:04 AM, Aaron Meurer wrote:
>
> So an ideal class structure would represent this. CommutativeRing
> would derive from Ring, but not all subclasses of Ring would be
> subclasses of CommutativeRing.
Totally right.
> It may make sense to have Ring derive
> from Ideal. If y
On Thu, Apr 5, 2012 at 1:20 AM, Tom Bachmann wrote:
>
> In my background "ring" is synonymous with commutative unital ring. As far
> as I know there is quite a large body of mathematics (mainly related to
> representation theory) devoted to the study of non-commutative rings as
> well.
Yeah, I ca
On Thu, Apr 5, 2012 at 1:13 AM, Aaron Meurer wrote:
>> I'm not sure I see your point here; indeed, an ideal of ring with a
>> multiplicative unit need not necessarily include the unit, but this
>> doesn't make it less of a ring.
>
> Yes it does. It makes it not a ring at all. A ring is a set wit
On Wed, Apr 4, 2012 at 4:20 PM, Tom Bachmann wrote:
> On 04.04.2012 23:13, Aaron Meurer wrote:
>>>
>>> I'm not sure I see your point here; indeed, an ideal of ring with a
>>> multiplicative unit need not necessarily include the unit, but this
>>> doesn't make it less of a ring.
>>
>>
>> Yes it doe
On 04.04.2012 23:13, Aaron Meurer wrote:
I'm not sure I see your point here; indeed, an ideal of ring with a
multiplicative unit need not necessarily include the unit, but this
doesn't make it less of a ring.
Yes it does. It makes it not a ring at all. A ring is a set with two
binary operatio
> I'm not sure I see your point here; indeed, an ideal of ring with a
> multiplicative unit need not necessarily include the unit, but this
> doesn't make it less of a ring.
Yes it does. It makes it not a ring at all. A ring is a set with two
binary operations, + and *, *with the properties* tha
On Wed, Apr 4, 2012 at 10:19 PM, Tom Bachmann wrote:
>>> I don't think that makes sense. Ideals have no natural multiplicative
>>> unit,
>>> whereas a type of ring I tend to think of has (admittedly, this may
>>> sometimes be relaxed).
>>
>>
>> I'm not sure I see your point here; indeed, an ideal
On Wed, Apr 4, 2012 at 10:15 PM, Tom Bachmann wrote:
>> For example, instead of running compute_groebner_basis([generator1,
>> generator2, generator3]), I suggest writing
>> GroebnerBasis(Ideal([generator1, generator2, generator3)).
>>
>
> I'd suggest my_ring.ideal(generator1, generator2, generato
Hi,
On 4 April 2012 14:03, Sergiu Ivanov wrote:
> On Tue, Apr 3, 2012 at 10:01 PM, Joachim Durchholz
> wrote:
> > Am 03.04.2012 20:30, schrieb Sergiu Ivanov:
> >
> > This discussion has gotten somewhat circular, and no single posting has
> > addressed all points and put them into perspective.
>
I don't think that makes sense. Ideals have no natural multiplicative unit,
whereas a type of ring I tend to think of has (admittedly, this may
sometimes be relaxed).
I'm not sure I see your point here; indeed, an ideal of ring with a
multiplicative unit need not necessarily include the unit, bu
For example, instead of running compute_groebner_basis([generator1,
generator2, generator3]), I suggest writing
GroebnerBasis(Ideal([generator1, generator2, generator3)).
I'd suggest my_ring.ideal(generator1, generator2, generator3).groebner()
:-). But obviously I agree to the idea.
--
You r
On Tue, Apr 3, 2012 at 10:01 PM, Joachim Durchholz wrote:
> Am 03.04.2012 20:30, schrieb Sergiu Ivanov:
>
> This discussion has gotten somewhat circular, and no single posting has
> addressed all points and put them into perspective.
> So that's my other proposal: write up all proposals, enumerate
On Wed, Apr 4, 2012 at 12:41 PM, Tom Bachmann wrote:
>> Well, I actually had in mind to base my implementation of the Groebner
>> walk off these classes, this is why I was so eager about discussing
>> the topic.
>>
>
> I think this is the part which I really don't understand. Groebner basis
> code
On Wed, Apr 4, 2012 at 12:50 AM, Tom Bachmann wrote:
>> Tom, I think I understand your points, but I'd still like to ask you
>> whether you find it acceptable to have the classes I have suggested in
>> SymPy?
>>
>
> Also, I think we got a little carried away by the whole Ring.mul vs __mul__
> busi
Well, I actually had in mind to base my implementation of the Groebner
walk off these classes, this is why I was so eager about discussing
the topic.
I think this is the part which I really don't understand. Groebner basis
code works for very specific rings (namely polynomial rings in finitely
On Tue, Apr 3, 2012 at 10:10 PM, Tom Bachmann wrote:
>> Tom, I think I understand your points, but I'd still like to ask you
>> whether you find it acceptable to have the classes I have suggested in
>> SymPy?
>>
>
> To be honest I don't really care (other than that, most of the time, new
> code in
Tom, I think I understand your points, but I'd still like to ask you
whether you find it acceptable to have the classes I have suggested in
SymPy?
Also, I think we got a little carried away by the whole Ring.mul vs
__mul__ business. I think it has been established now that the
approaches are
Tom, I think I understand your points, but I'd still like to ask you
whether you find it acceptable to have the classes I have suggested in
SymPy?
To be honest I don't really care (other than that, most of the time, new
code in sympy is good news). Don't get me wrong, I'm really interested
in
Am 03.04.2012 20:30, schrieb Sergiu Ivanov:
Tom, I think I understand your points, but I'd still like to ask you
whether you find it acceptable to have the classes I have suggested in
SymPy?
To the critics: I'd strongly recommend proposing a better structure over
just saying "this structure is
On 03.04.2012 19:32, Sergiu Ivanov wrote:
On Tue, Apr 3, 2012 at 10:14 AM, Tom Bachmann wrote:
On 02.04.2012 21:50, Ronan Lamy wrote:
Le lundi 02 avril 2012 à 21:28 +0100, Tom Bachmann a écrit :
On 02.04.2012 15:30, Sergiu Ivanov wrote:
In conclusion, I cannot see how my ideas fundamental
On Tue, Apr 3, 2012 at 10:14 AM, Tom Bachmann wrote:
> On 02.04.2012 21:50, Ronan Lamy wrote:
>>
>> Le lundi 02 avril 2012 à 21:28 +0100, Tom Bachmann a écrit :
>>>
>>> On 02.04.2012 15:30, Sergiu Ivanov wrote:
In conclusion, I cannot see how my ideas fundamentally contradict the
ap
My delay with the answer is explained by the fact that I have
deliberately waited for a day to hear everyone's opinion.
On Mon, Apr 2, 2012 at 11:50 PM, Ronan Lamy wrote:
> Le lundi 02 avril 2012 à 21:28 +0100, Tom Bachmann a écrit :
>> On 02.04.2012 15:30, Sergiu Ivanov wrote:
>> > In conclusion
On 02.04.2012 21:50, Ronan Lamy wrote:
Le lundi 02 avril 2012 à 21:28 +0100, Tom Bachmann a écrit :
On 02.04.2012 15:30, Sergiu Ivanov wrote:
In conclusion, I cannot see how my ideas fundamentally contradict the
approaches evoked in this thread. Therefore, I will try to pose the
dual question:
On Mon, Apr 2, 2012 at 8:40 AM, Sergiu Ivanov
wrote:
> On Sun, Apr 1, 2012 at 10:26 PM, Aaron Meurer wrote:
>> On Sun, Apr 1, 2012 at 12:08 PM, Ronan Lamy wrote:
>>
>>> Besides, how can a and b know which they belong to? This would require
>>> having several different versions of e.g. sqrt(6): o
Le lundi 02 avril 2012 à 21:28 +0100, Tom Bachmann a écrit :
> On 02.04.2012 15:30, Sergiu Ivanov wrote:
> > In conclusion, I cannot see how my ideas fundamentally contradict the
> > approaches evoked in this thread. Therefore, I will try to pose the
> > dual question: do you think the current Rin
On 02.04.2012 15:30, Sergiu Ivanov wrote:
In conclusion, I cannot see how my ideas fundamentally contradict the
approaches evoked in this thread. Therefore, I will try to pose the
dual question: do you think the current Ring class is well-suited for
a future implementation of ring theory? I hop
On Sun, Apr 1, 2012 at 10:26 PM, Aaron Meurer wrote:
> On Sun, Apr 1, 2012 at 12:08 PM, Ronan Lamy wrote:
>
>> Besides, how can a and b know which they belong to? This would require
>> having several different versions of e.g. sqrt(6): one in QQ[sqrt(6)],
>> one in QQ[sqrt(2), sqrt(3)], one in RR
On Sun, Apr 1, 2012 at 9:08 PM, Ronan Lamy wrote:
> Le dimanche 01 avril 2012 à 18:54 +0300, Sergiu Ivanov a écrit :
>>
>> It should be possible to have operation-unaware classes for elements
>> and operation-aware rings, and then define simple ring-aware wrappers
>> for elements which will take c
Actually, I don't really see what is wrong with having several
"versions" of sqrt(6). Clearly the one inside C and the one inside R
should know about each other / be the same. But what about the element x
of the quotient ring QQ[x]/(x^2 - 6)? Surely they should not, a priory,
be the same?
Your
Le dimanche 01 avril 2012 à 21:01 +0100, Tom Bachmann a écrit :
> On 01.04.2012 20:26, Aaron Meurer wrote:
> >> Besides, how can a and b know which they belong to? This would require
> >> having several different versions of e.g. sqrt(6): one in QQ[sqrt(6)],
> >> one in QQ[sqrt(2), sqrt(3)], one in
On 01.04.2012 20:26, Aaron Meurer wrote:
Besides, how can a and b know which they belong to? This would require
having several different versions of e.g. sqrt(6): one in QQ[sqrt(6)],
one in QQ[sqrt(2), sqrt(3)], one in RR, one in CC, ... IIUC, Sage does
exactly that, but it feels profoundly wrong
On Sun, Apr 1, 2012 at 12:08 PM, Ronan Lamy wrote:
> Le dimanche 01 avril 2012 à 18:54 +0300, Sergiu Ivanov a écrit :
>> On Sat, Mar 31, 2012 at 10:19 PM, Aaron Meurer wrote:
>> > On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann wrote:
>> >> Obviously I don't want to sound obstinate either, but I
Le dimanche 01 avril 2012 à 18:54 +0300, Sergiu Ivanov a écrit :
> On Sat, Mar 31, 2012 at 10:19 PM, Aaron Meurer wrote:
> > On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann wrote:
> >> Obviously I don't want to sound obstinate either, but I really cannot
> >> imagine you find a majority on this li
On Sat, Mar 31, 2012 at 10:19 PM, Aaron Meurer wrote:
> On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann wrote:
>> Obviously I don't want to sound obstinate either, but I really cannot
>> imagine you find a majority on this list which prefers to write R.mul(a, b)
>> instead of a*b, whatever the arg
On Sat, Mar 31, 2012 at 8:22 PM, Tom Bachmann wrote:
>
> On 31.03.2012 16:05, Sergiu Ivanov wrote:
>>
>> Summarising: when you work in concrete rings (integers, reals, etc.)
>> and focus on elements thereof, the "real" stuff is indeed in elements.
>> However, if the focus is on the rings themselve
Am 31.03.2012 16:50, schrieb Tom Bachmann:
Since all the "real stuff" is in the elements, why bother with a ring
class at all?
The ring class might hold code and comments that apply to all rings,
regardless of domain and operations.
> It turns out (every time I try to think about it) that it
On Sat, Mar 31, 2012 at 2:04 PM, Tom Bachmann wrote:
> On 31.03.2012 20:19, Aaron Meurer wrote:
>>
>> On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann wrote:
>>>
>>> Obviously I don't want to sound obstinate either, but I really cannot
>>> imagine you find a majority on this list which prefers to w
On 31.03.2012 20:19, Aaron Meurer wrote:
On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann wrote:
Obviously I don't want to sound obstinate either, but I really cannot
imagine you find a majority on this list which prefers to write R.mul(a, b)
instead of a*b, whatever the argument for or against.
On Sat, Mar 31, 2012 at 11:22 AM, Tom Bachmann wrote:
> Obviously I don't want to sound obstinate either, but I really cannot
> imagine you find a majority on this list which prefers to write R.mul(a, b)
> instead of a*b, whatever the argument for or against.
The way I see it, if a and b are elem
Obviously I don't want to sound obstinate either, but I really cannot
imagine you find a majority on this list which prefers to write R.mul(a,
b) instead of a*b, whatever the argument for or against.
On 31.03.2012 16:05, Sergiu Ivanov wrote:
Summarising: when you work in concrete rings (intege
On Sat, Mar 31, 2012 at 5:50 PM, Tom Bachmann wrote:
>
> [Sorry to make this become the sort of "tiring discussion" I was warning
> of...]
No problem :-)
> I agree that, mathematically, the operations should be part of the ring
> structure, and not of the elements. But in practice, that is not t
On 31.03.2012 15:41, Sergiu Ivanov wrote:
On Fri, Mar 30, 2012 at 11:52 PM, Aaron Meurer wrote:
In what way can it not represent any ring?
Sorry, I chose the wrong word.
Indeed the class Ring can represent any ring, just as a Domain (the
parent class of Ring) can represent any algebraic dom
On Fri, Mar 30, 2012 at 11:52 PM, Aaron Meurer wrote:
>
> In what way can it not represent any ring?
Sorry, I chose the wrong word.
Indeed the class Ring can represent any ring, just as a Domain (the
parent class of Ring) can represent any algebraic domain.
However, the Ring class knows nothing
In what way can it not represent any ring?
Aaron Meurer
On Fri, Mar 30, 2012 at 2:44 PM, Sergiu Ivanov
wrote:
> Hello,
>
> In sympy/polys/domains/rings.py I can see defined the class Ring
> which, according to the docstring, represents a ring domain. While it
> does essentially represent *a* ri
Hello,
In sympy/polys/domains/rings.py I can see defined the class Ring
which, according to the docstring, represents a ring domain. While it
does essentially represent *a* ring, it doesn't do so in general,
i.e., it cannot be used to represent *any* ring. I envision problems
when someone will l
47 matches
Mail list logo
