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.
