Hi Nicolas,
> Could you make a list of those that were not marked as deprecated? I
> also vote for deprecating them, but other opinions are welcome.
Here, I think, is the complete list together with their recommended
replacements:
deprecation(13072,'partitions_set is deprecated. Use SetPartitions
instead.')
deprecation(13072,'number_of_partitions_set is deprecated. Use
SetPartitions instead.')
deprecation(13072,'ordered_partitions is deprecated. Use
OrderedPartitions instead.')
deprecation(13072,'number_of_ordered_partitions is deprecated. Use
OrderedPartitions().cardinality instead.')
deprecation(13072,'partitions_greatest is deprecated. Use
PartitionsGreatestLE instead.')
deprecation(13072,'partitions_greatest_eq is deprecated. Use
PartitionsGreatestEQ instead.')
deprecation(13072,'partition_tuples is deprecated. Use PartitionTuples
instead.')
deprecation(13072,'number_of_partition_tuples is deprecated. Use
PartitionTuples instead.')
deprecation(13072,'partition_power is deprecated. Use
Partition(mu).power() instead.')
Even though these functions were not marked for deprecation, some one had
written the corresponding classes to replace them already.
Looking again at the code, the function cyclic_permutations_of_partition
should probably also become a method of Partitions() but I didn't do this
(yet?).
There might be another reason for deprecating number_of_partitions in
> the interpreter but not in the code: the implementation is really
> really fast, and the cost of constructing Partitions(n) first might be
> comparatively non negligible for heavy use.
Actually, this argument is not so compelling because the default way of
computing the number of partitions is to call the cython function
sage.combinat.partitions.number_of_partitions
If speed is really an issue then people should be calling this directly.
In actual fact, the current implementation of
partition.number_of_partitions creates extra overhead with some argument
parsing. Ultimately, the function either calls the cython code or it calls
gap's NrPartitions(), if the number of parts are specified, or there is
another option for using pari. I think that it would be better to deprecate
partitions.number_of_partitions in favour of the cython code.
Best,
Andrew
On Friday, 24 August 2012 01:57:26 UTC+10, Nicolas M. Thiery wrote:
>
> Hi Andrew,
>
> On Thu, Aug 23, 2012 at 05:23:32AM -0700, Andrew Mathas wrote:
> > I have to confess that I didn't really appreciate that I was
> deprecating
> > these functions from the global name space but in any case I am in
> favour
> > of doing so, so +1.
>
> I have to confess in return that I missed the fact that most of those
> functions were marked as deprecated in their docstrings. For all of
> those your clean up need no discussion: they should be completely
> deleted.
>
> > If everyone agrees that this is a good idea then I will add
> deprecation
> > warnings into sage.combinat.all. If the we vote to keep them then
> I'll
> > reinstate the global names in the patch. In terms of the functions in
> > doctests etc the best fix would be to change them so that use
> > Partition(n).cardinality() etc. Again, I would hunt these down and
> fix
> > them if people are in favour of deprecation.
>
> > By the way, number_of_partitions is one of the few such functions
> that I
> > didn't deprecate in partition.py. The reason for this is that this
> > function is wrapped in a cached_function call and I didn't want to
> break
> > this... I suspect that if simply put a cached_method decorator on
> > Partition.cardinality() then this would have the same effect but as I
> > wasn't sure I left it well enough alone. Is this true?
>
> There might be another reason for deprecating number_of_partitions in
> the interpreter but not in the code: the implementation is really
> really fast, and the cost of constructing Partitions(n) first might be
> comparatively non negligible for heavy use.
>
> Thanks for your clean up!
>
> Cheers,
> Nicolas
> --
> Nicolas M. Thi�ry "Isil" <[email protected] <javascript:>>
> http://Nicolas.Thiery.name/
>
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/hKvx4fyLqdYJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
