Introducing a framework for is_* methods
Simon King
I think the other thread on categories is already long enough. So, I'd
like to split this detail off:
On Oct 22, 11:40 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
> > And do you have an idea of how the user can assert "X is finite/
> > infinite/doesn't matter"? What about a method "X.assert(self,
> > 'foo', value)" that creates an instance method X.is_foo returning
> > the given value?
>
> Oops, I am confused: are you referring back to some email of mine for
> the use case? If yes, can you point which one?
I think I remember that at some point you wrote that it would be
useful if the user could assert that a structure is finite or
infinite, because this is difficult/impossible to detect
algorithmically.
More generally: Assume that you have a property that is important for
containment in a specific category, but is, in general, difficult to
prove. Such as:
1) finiteness
2) commutativity
3) associativity
4) distributivity
5) ...
For each of these properties, it might be the case that the user knows
whether an object X satisfies the property. There already exist some
"is_*" methods, such as "is_field", "is_commutative", "is_finite". But
there is no standardised way to change the output of these methods
after initialisation of X.
I suggest to introduce a method "assert" for parents, like this:
def assert(self, name, value):
setattr(self, 'is_'+name, lambda : bool(value) if value is not
None else None)
If you have a specialised algorithm for finite structures, then you
could do
if hasattr(self,'is_finite') and self.is_finite() is True:
<specialised code>
else:
<generic code>
or if you have specialised code for infinite structures, you could do
if hasattr(self,'is_finite') and self.is_finite() is False:
<specialised code>
else:
<generic code>
So, if is_finite does not exist or returns "None" then the generic
code is executed in either case.
In other words, the user has the options:
1) X.assert('finite',None): Choose generic code, independent of
finiteness
2) X.assert('finite',True): Choose special code for finite structures
whenever possible
3) X.assert('finite',False): Choose special code for infinite
structures whenever possible
Do you think this would be useful to have?
Cheers,
Simon
Nicolas M. Thiery
On Sat, Oct 23, 2010 at 09:31:43AM -0700, Simon King wrote:
> On Oct 22, 11:40 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> wrote:
> > > And do you have an idea of how the user can assert "X is finite/
> > > infinite/doesn't matter"? What about a method "X.assert(self,
> > > 'foo', value)" that creates an instance method X.is_foo returning
> > > the given value?
> >
> > Oops, I am confused: are you referring back to some email of mine for
> > the use case? If yes, can you point which one?
>
> I think I remember that at some point you wrote that it would be
> useful if the user could assert that a structure is finite or
> infinite, because this is difficult/impossible to detect
> algorithmically.
Ah, I see. I got confused, because I thought you meant ``assert`` as
in assertion tests in the code (which I use all the time):
assert X in FiniteEnumeratedSets()
> More generally: Assume that you have a property that is important for
> containment in a specific category, but is, in general, difficult to
> prove. Such as:
> 1) finiteness
> 2) commutativity
> 3) associativity
> 4) distributivity
> 5) ...
>
> For each of these properties, it might be the case that the user knows
> whether an object X satisfies the property. There already exist some
> "is_*" methods, such as "is_field", "is_commutative", "is_finite". But
> there is no standardised way to change the output of these methods
> after initialisation of X.
I think this is the perfect use case for the idiom:
X.update_category(FiniteSets())
X.update_category(Fields())
So far, when we encountered similar situations, we either declared
appropriately the category in the __init__ of the parent (requiring to
change the sources), or passed this category to the __init__ of that
parent (which must accept this optional argument). Of course, this
approach can only be used at the time the parent is constructed, and
the update_category idiom would be much better. Still, I have done a
lot of that lately:
semigroupe.Semigroup(..., category = JTrivialMonoids())
In fact, I have used this idiom quite a few times to add code to an
already implemented parent, by creating a fake category containing
that code (a bit of a hack, but very handy!).
> If you have a specialised algorithm for finite structures, then you
> could do
> if hasattr(self,'is_finite') and self.is_finite() is True:
> <specialised code>
> else:
> <generic code>
Just a side note: specialized algorithms for finite (resp. infinite)
structures should go in the FiniteBlah (resp. InfiniteBlah) category.
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
Simon King
Meanwhile I found the your post in which you said something about is_*
-- and it turned out that I remembered the complete opposite of what
you actually wrote. You wrote that you are NOT so keen about is_*...
Sorry!
On 24 Okt., 19:00, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
>
>
> X.update_category(FiniteSets())
> X.update_category(Fields())
would be inherited from the category anyway.
> Just a side note: specialized algorithms for finite (resp. infinite)
> structures should go in the FiniteBlah (resp. InfiniteBlah) category.
As you may have noticed, I posted on sage-devel and asked if there is
interest in the automatic dynamical update of categories, at the
expense of slowing down "sage -testall -long" by 1.5%. I could imagine
that many people wouldn't like to slow things down if the only gain is
a generalisation of an abstract framework. But let us see what people
think.
in either case, I think that a method "update_category" is non-
controversial and clearly a missing feature. Using my experiences with
*automatically* updating the category and subclassing both parent and
element classes exploting the abc module, I would certainly be able
to implement the update_category functionality (simply drop the word
"automatically" in this sentence...).
Best regards,
Simon
Nicolas M. Thiery
On Sun, Oct 24, 2010 at 02:34:53PM -0700, Simon King wrote:
> As you may have noticed, I posted on sage-devel and asked if there is
> interest in the automatic dynamical update of categories, at the
> expense of slowing down "sage -testall -long" by 1.5%. I could imagine
> that many people wouldn't like to slow things down if the only gain is
> a generalisation of an abstract framework. But let us see what people
> think.
I have been overflowed by sage-devel lately, but I will have a look! I
would bet for a strong opposition, unless the slow down would only
concern code specifically using the feature.
> in either case, I think that a method "update_category" is non-
> controversial and clearly a missing feature. Using my experiences with
> *automatically* updating the category and subclassing both parent and
> element classes exploting the abc module, I would certainly be able
> to implement the update_category functionality (simply drop the word
> "automatically" in this sentence...).
Looking forward to that! This feature, especially combined with better
join treatment for Finite/Commutative/..., will be really powerful.
Cheers,
Nicolas
PS: by the way: the pushout construction mechanism does overlap much
with the "functorial constructions" in the categories
(Algebras/Subquotients/...). At some point, we will need to
investigate exactly how much they overlap, and devise plans to merge
the two features or at least make them interact smoothly. I know the
general principle of the pushout mechanism, but you have a much
stronger practical experience with it. Would you volunteer to start
this investigation?
Simon King
On 25 Okt., 11:01, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
> would bet for a strong opposition, unless the slow down would only
> concern code specifically using the feature.
if the only gain is not clear.
I don't know what parts of Sage are slower than before. Looking at the
times for doctesting separate files, it seems that the slow-down is
pretty much universal.
> > in either case, I think that a method "update_category" is non-
> > controversial and clearly a missing feature. Using my experiences with
> > *automatically* updating the category and subclassing both parent and
> > element classes exploting the abc module, I would certainly be able
> > to implement the update_category functionality (simply drop the word
> > "automatically" in this sentence...).
>
> Looking forward to that! This feature, especially combined with better
> join treatment for Finite/Commutative/..., will be really powerful.
> PS: by the way: the pushout construction mechanism does overlap much
> with the "functorial constructions" in the categories
> (Algebras/Subquotients/...).
from the construction functors.
> I know the
> general principle of the pushout mechanism, but you have a much
> stronger practical experience with it. Would you volunteer to start
> this investigation?
Cheers,
Simon
Nicolas M. Thiery
> On 25 Okt., 11:01, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> wrote:
> > Looking forward to that! This feature, especially combined with better
> > join treatment for Finite/Commutative/..., will be really powerful.
>
> OK, I hope I'll find the time to open a ticket this week.
>
> > PS: by the way: the pushout construction mechanism does overlap much
> > with the "functorial constructions" in the categories
> > (Algebras/Subquotients/...).
>
> Indeed I was wondering why the functorial construction do not inherit
> from the construction functors.
As a first round, I just wanted to focus on having a clean
infrastructure on the category side, without having to worry about
backward compatibility.
> > I know the general principle of the pushout mechanism, but you
> > have a much stronger practical experience with it. Would you
> > volunteer to start this investigation?
> First I need to settle in Jena, were I will return next week.
Sure, that's a long term / no rush project! Thanks!
Cheers,
Nicolas