>
>
> Great, I'll look at this. Apart from that, should we rename the name of
> the parameter p in q_analogues to q -- and (in a separate patch) also
> make q and t named parameters in qt_catalan_number?
>
I think that qt_catalan should have named parameters (there are none
now while all the o
Mike Zabrocki writes:
> Hi Martin,
> Maybe you should take a look at scalar_qt in sfa.py
> since it is similar to the effect you want to have with
> principle specialization.
> That function
> (a) has parameters which are called q and t
> (b) outputs something that uses the variables q and t
Hi Martin,
Maybe you should take a look at scalar_qt in sfa.py
since it is similar to the effect you want to have with
principle specialization.
That function
(a) has parameters which are called q and t
(b) outputs something that uses the variables q and t
even if the symmetric function base_ri
Mike Zabrocki writes:
> Hi Martin
>
> I find this slightly confusing...
>
> I think that p is there to differentiate the variable name (which is p
> probably short for 'parameter') from the variable value (which is by
> default q).
Sorry, I wasn't clear enough: what I find confusing is that
Hi Martin
I find this slightly confusing...
>
I think that p is there to differentiate the variable name (which is p
probably short for 'parameter')
from the variable value (which is by default q).
You don't actually need to have the "p=" in your
command for it to work,
sage: from sage.combinat.
Mike Zabrocki writes:
> Hi Franco,
>
> I will add the Error message improvement to my list of
> things to fix (Anne has also identified a number of issues that
> I need to address yet).
One tiny, possibly unrelated question: I noticed that q_int, q_binomial,
q_factorial take "p" as optional na
Hi Mike,
> I will add the Error message improvement to my list of
> things to fix (Anne has also identified a number of issues that
> I need to address yet). The idea behind the choice is that
> we don't want to assume that the user wants sage to change
> the base ring just to use Macdonald polyn
Hi Franco,
I will add the Error message improvement to my list of
things to fix (Anne has also identified a number of issues that
I need to address yet). The idea behind the choice is that
we don't want to assume that the user wants sage to change
the base ring just to use Macdonald polynomials.
Hi Mike,
I did some timing tests on the old and new code:
sage: Sym = SymmetricFunctions(QQ['q','t'].fraction_field())
sage: s = Sym.schur()
sage: m = Sym.monomial()
sage: timeit('m(s([6,3,3,2,1]))')
25 loops, best of 3: 8.51 ms per loop
sage: timeit('m(s([10,6,3,3,2,1]))')
5 loops, best of 3: 21
Hi,
I should add that one thing that should really be tested in addition to
behavior is *speed*!
With these changes there might be potential slow-down from previous
versions.
We don't want this to happen. I've tested a bit, but this is one thing
that is even more difficult to identify than a b
10 matches
Mail list logo
