[sage-devel] Re: Design question about rings, re #6441

On Tue, Sep 22, 2009 at 11:25:12AM -0700, Robert Bradshaw wrote: > On Sep 22, 2009, at 4:49 AM, Nicolas M. Thiery wrote: > > Variant: > > > > sage: R = Zmod(6) > > sage: R.set_category(Fields())# or maybe better R.add_category > > (Fields()) > > sage: R in Fields() > > True >

[sage-devel] Re: Design question about rings, re #6441

On Sep 22, 2009, at 4:49 AM, Nicolas M. Thiery wrote: > > Hi, > > Getting back on my late sage e-mails ... > > On Mon, Aug 24, 2009 at 11:25:50PM -0700, William Stein wrote: >> On Mon, Aug 24, 2009 at 10:43 PM, Robert >> Bradshaw wrote: >>> What I'd rather see is something like >>> >>> sag

[sage-devel] Re: Design question about rings, re #6441

Hi, Getting back on my late sage e-mails ... On Mon, Aug 24, 2009 at 11:25:50PM -0700, William Stein wrote: > On Mon, Aug 24, 2009 at 10:43 PM, Robert > Bradshaw wrote: > > What I'd rather see is something like > > > > sage: R = Zmod(6) > > sage: K = categories.Fields(R, check=False) #

[sage-devel] Re: Design question about rings, re #6441

On Mon, Aug 24, 2009 at 10:43 PM, Robert Bradshaw wrote: > > On Aug 23, 2009, at 12:42 PM, William Stein wrote: > >> On Sun, Aug 23, 2009 at 12:27 PM, Sebastian Pancratz >> wrote: >> >> I think as a first step I'll only implement the additional argument >> for the two methods "is_field" and "is_i

[sage-devel] Re: Design question about rings, re #6441

On Aug 23, 2009, at 12:42 PM, William Stein wrote: > On Sun, Aug 23, 2009 at 12:27 PM, Sebastian Pancratz > wrote: > > I think as a first step I'll only implement the additional argument > for the two methods "is_field" and "is_integral_domain". +1 to this idea. > For the other suggestion, n

[sage-devel] Re: Design question about rings, re #6441

Hi William, On Aug 24, 1:35 pm, William Stein wrote: [...] > > But you couldn't use the attribute "._properties" in doc tests anyway, > > because AFAIK rings are cdef classes, so, you can't access the > > attributes on a python level. > > Yes you can, if you declare them "cdef public _properties

[sage-devel] Re: Design question about rings, re #6441

On Mon, Aug 24, 2009 at 12:41 AM, Simon King wrote: > > Hi Minh, > > On 24 Aug., 02:10, Minh Nguyen wrote: > [...] > > > Since I am not an experienced programmer: Are there reasons to not use > > > a dictionary for those kind of things? > > > > A good point: searching through a dictionary is esse

[sage-devel] Re: Design question about rings, re #6441

Hi Minh, On 24 Aug., 02:10, Minh Nguyen wrote: [...] > > Since I am not an experienced programmer: Are there reasons to not use > > a dictionary for those kind of things? > > A good point: searching through a dictionary is essentially constant time. > > A bad point: can't assume that each key/va

[sage-devel] Re: Design question about rings, re #6441

On Mon, Aug 24, 2009 at 6:21 AM, Simon King wrote: > > I guess this would provide some flexibility, but I don't know if it > would be a "clean" thing to do. > Since I am not an experienced programmer: Are there reasons to not use > a dictionary for those kind of things? A good point: searching

[sage-devel] Re: Design question about rings, re #6441

On Sun, Aug 23, 2009 at 1:21 PM, Simon King wrote: > > Hi! > > On Aug 23, 8:42 pm, William Stein wrote: > [...] > > Don't make it upper case. Make the attribute _is_field. Otherwise the > > above sounds great to me. > > Or one could have a single attribute "_properties", which is a > dictionar

[sage-devel] Re: Design question about rings, re #6441

Hi! On Aug 23, 8:42 pm, William Stein wrote: [...] > Don't make it upper case.  Make the attribute _is_field.  Otherwise the > above sounds great to me. Or one could have a single attribute "_properties", which is a dictionary, and then one can define self._properties['integrally_closed'] = Tr

[sage-devel] Re: Design question about rings, re #6441

On Sun, Aug 23, 2009 at 12:27 PM, Sebastian Pancratz wrote: > > I think as a first step I'll only implement the additional argument > for the two methods "is_field" and "is_integral_domain". > > For the other suggestion, namely to allow the user to assert that a > ring is in fact a field, would th

[sage-devel] Re: Design question about rings, re #6441

I think as a first step I'll only implement the additional argument for the two methods "is_field" and "is_integral_domain". For the other suggestion, namely to allow the user to assert that a ring is in fact a field, would the following be the "right" way to implement this? 1. Add a new attribu

[sage-devel] Re: Design question about rings, re #6441

On Sat, Aug 22, 2009 at 3:02 PM, Simon King wrote: > > Hi Sebastian, > > On 22 Aug., 23:46, Sebastian Pancratz wrote: > [...] > > I think I'd prefer the other suggestion, namely leaving the default > > behaviour of methods like "is_field" as it is at the moment (thereby > > not breaking any othe

[sage-devel] Re: Design question about rings, re #6441

Simon King wrote: > If one really wants to know whether R is provably not a field, then > one asks R.is_field()==False. A short aside unrelated to the general discussion, but good to know: it's usually much faster to do "some_value is False", since that is a pointer comparison. Also, 0==Fals

[sage-devel] Re: Design question about rings, re #6441

Hi Sebastian, On 22 Aug., 23:46, Sebastian Pancratz wrote: [...] > I think I'd prefer the other suggestion, namely leaving the default > behaviour of methods like "is_field" as it is at the moment (thereby > not breaking any other code!) and introducing an optional argument to > specifically sui

[sage-devel] Re: Design question about rings, re #6441

> I agree that consistent behaviour is good, but I don't see the point > of the "proof=True" option: Catching an error is not more difficult > than putting an extra argument "proof=False". I am not sure about this. In the current implementation, none of the intermediate methods (e.g. for quotien

[sage-devel] Re: Design question about rings, re #6441

On Sat, Aug 22, 2009 at 2:23 PM, Sebastian Pancratz wrote: > > > > In this file, the current behaviour is the following, > > > > > o Try to establish the answer (yes or no). > > > o If this doesn't work, throw an exception. > > > > > although the actual behaviour is down to the inheriting clas

[sage-devel] Re: Design question about rings, re #6441

> > In this file, the current behaviour is the following, > > >  o  Try to establish the answer (yes or no). > >  o  If this doesn't work, throw an exception. > > > although the actual behaviour is down to the inheriting classes. > > > From the point of view of the ring, this might seem sensible.

[sage-devel] Re: Design question about rings, re #6441

On Sat, Aug 22, 2009 at 1:50 PM, Simon King wrote: > > Hi William, > > On Aug 22, 8:30 pm, William Stein wrote: > [...] > > > The logic > > > between the equality testing and this question seems like it should be > > > consistent. > > > > That's a good point -- the question is perhaps impossible

[sage-devel] Re: Design question about rings, re #6441

Hi William, On Aug 22, 8:30 pm, William Stein wrote: [...] > > The logic > > between the equality testing and this question seems like it should be > > consistent. > > That's a good point -- the question is perhaps impossible to answer in > general in both cases.     That said, I know for a fact

[sage-devel] Re: Design question about rings, re #6441

On Sat, Aug 22, 2009 at 12:17 PM, Jason Grout wrote: > > William Stein wrote: > > > > > > On Sat, Aug 22, 2009 at 4:16 AM, Sebastian Pancratz > > wrote: > > > > > > Dear all, > > > > At SAGE Days 16 I implemented some code for division-free matrix > > operati

[sage-devel] Re: Design question about rings, re #6441

William Stein wrote: > > > On Sat, Aug 22, 2009 at 4:16 AM, Sebastian Pancratz > wrote: > > > Dear all, > > At SAGE Days 16 I implemented some code for division-free matrix > operations, which is being tracked as ticket #6441. The main > contributio

[sage-devel] Re: Design question about rings, re #6441

>sage: R.is_field(unknown_returns_false=True) >True or False Why not R.is_field(unknown_returns=XXX) so you can specify the desired value for "I don't know", either False or True? Otherwise, +1 -- this has been a problem in other places for me. Nick --~--~-~--~~

[sage-devel] Re: Design question about rings, re #6441

On Sat, Aug 22, 2009 at 4:16 AM, Sebastian Pancratz wrote: > > Dear all, > > At SAGE Days 16 I implemented some code for division-free matrix > operations, which is being tracked as ticket #6441. The main > contribution is code to compute the characteristic polynomial without > divisions, and thi