kwargs for a Function (re-implementing Stirling numbers)

65 views
Skip to first unread message

Peleg Michaeli

unread,
Feb 15, 2015, 5:34:35 AM2/15/15
to sy...@googlegroups.com
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?

hac...@gmail.com

unread,
Apr 30, 2015, 12:15:37 AM4/30/15
to sy...@googlegroups.com
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?

Aaron Meurer

unread,
May 2, 2015, 5:17:24 PM5/2/15
to sy...@googlegroups.com
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
> --
> 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 sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> 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.
Reply all
Reply to author
Forward
0 new messages