If there are only four kinds, I would just split them into four classes. If there are infinite possibilities, just make at a normal argument. You can still pass normal arguments as keyword arguments in Python, i.e., if you have
def f(x, y, z): pass you can call it as f(1, 2, z=3). Aaron Meurer On Wed, Apr 29, 2015 at 11:15 PM, <[email protected]> wrote: > I was actually just looking at doing this myself, so I searched for > "stirling" to see what traffic was on the mailing list about it. The > approach I was going to take was to have 2 different classes: one each for > Stirling numbers of the first and second kind. I guess then you also have > signed vs. unsigned, for which there is a less compelling argument to split > into different classes, although I'm not sure I could justify why. > > The thing I was not sure about was how to render them in the printer or in > latex. Looking at the wikipedia page, there are several notations. it looks > like [] and {} might be the preferred notations for the (unsigned) stirling > numbers of the first and second kind, respectively. does anyone have any > thoughts on that? > > > On Sunday, February 15, 2015 at 5:34:35 AM UTC-5, Peleg Michaeli wrote: >> >> I am re-implementing Stirling numbers, so they will become classes >> (subclasses of Function) instead of python functions as they are today. >> However, I thought it is a good idea to leave the user the option to use the >> same class for three different functions - Stirling numbers of the second >> kind (default), Stirling numbers of the first type which are unsigned >> (default for this kind) or signed. This is consistent with the current >> implementation as well. >> >> However, for that I need to allow the user to write something like >> >> stirling(n, k, kind=1) >> >> but that will cause Application to raise >> >> Traceback (most recent call last): >> File "<ipython-input-12-f9400eba577d>", line 1, in <module> >> stirling(0, 0, kind=1) >> File "sympy/core/cache.py", line 91, in wrapper >> retval = cfunc(*args, **kwargs) >> File "sympy/core/compatibility.py", line 871, in wrapper >> result = user_function(*args, **kwds) >> File "sympy/core/function.py", line 375, in __new__ >> result = super(Function, cls).__new__(cls, *args, **options) >> File "sympy/core/cache.py", line 91, in wrapper >> retval = cfunc(*args, **kwargs) >> File "sympy/core/compatibility.py", line 871, in wrapper >> result = user_function(*args, **kwds) >> File "sympy/core/function.py", line 196, in __new__ >> raise ValueError("Unknown options: %s" % options) >> ValueError: Unknown options: {'kind': 1} >> >> So, unless I am missing something, it looks like the Function class does >> not support kwargs at all. I can pass these as args, but that's not as nice. >> What do you think? > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/sympy. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/e93b52a5-bcab-4710-a441-0c6a6bf58623%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6L-ETabUeSMx3BqgJAyOQVQK9mgeb8GbDKpodnHf4w0fQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
