Re: interesting projects for Peter

[Peter Li]

I think working on PyStan would be great, but I'm not sure where to
start or how it would work at all. Is there any particular package or
reference that would be good to learn more about how this would work?
Are we looking for a python wrapper for C++ like
http://wiki.python.org/moin/Pyrex?

I could also work on the logCDF and logCCDF, but I should probably wait
until after Daniel is done with implementing the distributions for fvar.


Peter


On 5/31/13 11:23 PM, Bob Carpenter wrote:
>
>
> On 5/31/13 7:47 PM, Peter Li wrote:
>> All of these sounds great. The distributions seem pretty simple. I'll
>> try to do those this weekend. As for the other
>> projects, I don't really have a preference; I'd be fine with whatever
>> is most urgent/would be most helpful. I also think
>> the ensemble sampler would be cool--have we sorted out how we want to
>> implement this?
>
> No --- we haven't sorted it out. That's what makes it
> a more interesting project :-)
>
> The projects are all fairly high priority, but they're
> apples and oranges.
>
> PyStan will probably extend Stan's reach to the largest
> number of people. It'll probably also incur the most
> interaction with users longer term.
>
> Developing all the samplers could lead to some interesting
> evaluation papers and is more research oriented in focus.
>
> Fixing up the existing functions and making them more robust
> and faster will, well, make Stan go faster.
>
> - Bob

[Ben Goodrich]

I believe Cython is more advanced than Pyrex, and wikipedia seems to agree

http://en.wikipedia.org/wiki/Cython

Ben

[Peter Li]

According to the Cython user group, Cython still can't handle wrapping templated functions (https://groups.google.com/forum/?fromgroups#!topic/cython-users/npFq7OycR58).


Peter

[Peter Li]

Ah, but there is a workaround here: https://github.com/charanpald/sppy/blob/master/sppy/TemplateExpander.py.


Peter

[Bob Carpenter]

On 6/12/13 6:04 PM, Peter Li wrote:
> I could also work on the logCDF and logCCDF, but I should probably wait until after Daniel is done with implementing the
> distributions for fvar.

I think those changes will be independent. Once we
have OperandsAndPartials working for reverse mode, it
should just work if you implement things that way.

- Bob

[Bob Carpenter]

I'd first get in contact with Rob to see what he's
managed to do --- maybe you could start where he left
off.

Otherwise, there are several options for wrapping
C++, but I don't know the pros and cons.

As a model of what you want to do, there's RStan.
We pretty much just want to build RStan in Python.
Ideally with as few other dependencies as possible.
You'll probably need to use numpy.

This should all be done vs. Stan 2.0 at this point.
My number one priority now is to review the new command
structure and work on outstanding bug issues.

- Bob

On 6/12/13 6:04 PM, Peter Li wrote:

[Peter Li]

Is it Rob Zinkov (who emailed the stan-users list about
PySta...@zinkov.com)?


Peter

[Marcus Brubaker]

Peter,

Boost Python might be a better choice for PyStan.  At the very least I would suggest looking into it and if you end up using it, I might be able to help out a bit.

Cheers,

Marcus

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Peter Li]

Ok. And just to verify, we only really want logCDF and logCCDF, not CDF
and CCDF?


Peter

[Bob Carpenter]

On June 13, 2013 12:39:58 PM EDT, Peter Li <li.pe...@gmail.com> wrote:

> Ok. And just to verify, we only really want logCDF and logCCDF, not CDF
> and CCDF?

I

We need CDF to maintain backward compatibility.
We could deprecate it, but I don't want to get rid of
it right away.

There aren't any CCDFs yet, so there's no issue there,
so it'd be OK not to implement CCDF directly. If we
decide to get rid of CDF (by deprecating it and eventually
removing it),

>
> Peter
>
> On 6/13/13 10:45 AM, Bob Carpenter wrote:
>> On 6/12/13 6:04 PM, Peter Li wrote:
>>> I could also work on the logCDF and logCCDF, but I should probably
>>> wait until after Daniel is done with implementing the
>>> distributions for fvar.
>>
>> I think those changes will be independent. Once we
>> have OperandsAndPartials working for reverse mode, it
>> should just work if you implement things that way.
>>
>> - Bob
>>
>

[Bob Carpenter]

Sorry -- I keep fat-fingering messages out of this HTML-based
mailer, which is all I can get to from where I'm at.

We want to leave the existing foo_cdf(...) in place for now.

The new implementations can just be of foo_cdf_log(...)
and foo_ccdf_log(...).

We can deprecate the non-log foo_cdf(...)
and suggest people replace them with
exp(foo_cdf_log(...)) longer term.

- Bob

On June 13, 2013 12:39:58 PM EDT, Peter Li <li.pe...@gmail.com> wrote:

> Ok. And just to verify, we only really want logCDF and logCCDF, not CDF
> and CCDF?
>
>

[Andrew Gelman]

Hi, I emailed Rob Zinkov a couple times recently and did not get a response. But it can't hurt to contact him.
A

[Bob Carpenter]

On 6/17/13 9:15 AM, Allen Riddell wrote:
> Hi Bob -- this got bounced for lack of posting privileges.

I just gave you posting privilege on stan-dev.

> Hi all,
>
> I've got something that should be working by the end of the week. All the C++ is
> wrapped and working (using Cython). What remains is the Python on-the-fly
> compilation (right now I have to compile the model cpp + wrapper by hand).

If it's available in the form of a GitHub repo, we can
take a look.

Do you know if the design following the same basic approach as RStan?

Also, is it coded vs. our release 1.3.0, our current develop branch,
or the pending changes to command line? In 2.0, which we hope to
get out soon (but all sorts of issues have cropped up as you may
be following on the dev list), the command line args will all change.

- Bob

[Peter Li]

Rob Zinkov just sent me a link to what he has so far: https://github.com/zaxtax/stan/tree/pystan/pystan

[Allen Riddell]

Hi,

re: pystan

I'm trying to mirror the api I find in the rstan-dev github repo right now. Are
there significant changes to the RStan api in the works?

My strategy is to have something api compatible with RStan with the following
deviations:

- obvious pythonic replacements: fit.extract(...) instead of extract(fit, ...)
- less obvious pythonic replacements; dictionaries (OrderedDict) instead of
R lists, numpy arrays instead of R matrices.
- No attempt to allow variables to be referenced by string (e.g. specifying
model_code or data with a string naming a variable). Python is
pass-by-reference so there's no need..

I've still got to figure out the install-time compilation of libstan.a and
libstanc.a and the run-time compilation of models. The hard work (wrapping cpp
with Cython) is finished.

I should have something tomorrow, I think. I'll post a link to the github repo.

Best,

Allen

p.s. I'm targeting Python 3.3, Cython 19.1. I don't think backporting to Python
2.7 should be too difficult.

[Jiqiang Guo]

Great.  There is not much change in rstan now. 

--

Jiqiang

[Bob Carpenter]

Great. What's the status of Python versions?
My understanding from when we first looked at it
was that the 3+ Pythons weren't being widely used.

Not being a Python-er myself, I have no idea.

I would think having the 2.x versions would be helpful,
but I do understand there are backward/forward compatibility
issues.

Anything at all that works is going to be better than
what we currently have!



- Bob

[Bob Carpenter]

>> - obvious pythonic replacements: fit.extract(...) instead of
>> extract(fit, ...)
>> - less obvious pythonic replacements; dictionaries (OrderedDict) instead of
>> R lists, numpy arrays instead of R matrices.

Makes sense. I think ordered dictionaries should be
just like lists if they nest.

>> - No attempt to allow variables to be referenced by string (e.g. specifying
>> model_code or data with a string naming a variable). Python is
>> pass-by-reference so there's no need..

We need something like name=value so we know which values
correspond to which variables. Having the strings just avoided
the R idiom of list(a=a,b=b,...), where the LHS a is a variable
name and the RHS is the value. But just having c(a,b,c), the
array of values, wouldn't be enough because you wouldn't know what the values
referred to.

- Bob

[Allen Riddell]

I'm developing for Python 3.3 or higher. Backporting to Python 2.7 shouldn't be
difficult. Most of the scientific computing packages now run on Python
3 (pandas, numpy, scipy, cython, scikit-learn, matplotlib, ipython, ...).

Best,

Allen