Hi!
Thanks everyone for your input. We are banging hard on IntegerListLex
at Sage Days 64, and hopefully will get a correct and as fast as
previously implementation in the coming days. Don't hold your breath,
but the point is that it's likely that the "non lex is faster" is only
a temporar
Hi,
please don't make a distinction based on the n being less than 15! That
would make a really bad pitfall.
Best regards,
Darij
On Wed, Mar 18, 2015 at 6:28 AM, Viviane Pons wrote:
>
>
> 2015-03-18 12:40 GMT+01:00 Mike Zabrocki :
>
>> That would make sense. My preference is that (at leas
2015-03-18 12:40 GMT+01:00 Mike Zabrocki :
> That would make sense. My preference is that (at least for values less
> than 15) the default is that the output is sorted and this can be
> controlled by the optional parameter.
>
> I think about how many times that I test symmetric function identitie
On 2015-03-18 12:40, Mike Zabrocki wrote:
(at least for values less than 15)
I really don't like that defaults would depend on the input size.
Somebody working with small examples might *assume* that the order is in
a given way, and then suddenly his code will break down on larger examples.
-
That would make sense. My preference is that (at least for values less
than 15) the default is that the output is sorted and this can be
controlled by the optional parameter.
I think about how many times that I test symmetric function identities on
partitions and realize that patterns that ind
On Wed, 18 Mar 2015, Jeroen Demeyer wrote:
So would it make sense to have an optional parameter sorted=None,
which one could set to 'lex' or 'revlex' to get them in a desired order.
The documentation could warn about the issues you just raised.
If there is a general agreement on this, I could
On 2015-03-18 09:20, Samuel Lelievre wrote:
So would it make sense to have an optional parameter sorted=None,
which one could set to 'lex' or 'revlex' to get them in a desired order.
The documentation could warn about the issues you just raised.
If there is a general agreement on this, I could
Nathann Cohen wrote:
>
> Hello,
>
> > I think that Partitions should be output in either lex (or possibly
> reverse
> > lex) since this order is compatible with dominance order.
>
> I only want to bring to your attention that deciding in which order
> the partitions should be returned is not f
I think that for *most* applications the order does not matter, so I
would vote on not sorting by default. If you need sorting, just do it
yourself (or use IntegerListsLex).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from thi
I agree that this is a decision that would have to weigh between cost in
speed and convenience. For small values of n the speedup will be small but
that is where order is more useful. For large values of n the order is
probably less important. Correct results are clearly the most important
c
Hello,
> I think that Partitions should be output in either lex (or possibly reverse
> lex) since this order is compatible with dominance order.
I only want to bring to your attention that deciding in which order
the partitions should be returned is not free in terms of
computational time.
The c
I think that Partitions should be output in either lex (or possibly reverse
lex) since this order is compatible with dominance order.
One example where this arises is the transition matrix between certain
bases factors into an upper and lower triangular matrix when the basis
elements are ordere
Dear Jeroen,
The order of strong order tableaux does not really matter.
One place where it might slightly matter might be in character
tables of the symmetric group. As far as I remember they are just
matrices where rows and columns are indexed by integers rather than
by partitions. In this case
13 matches
Mail list logo
