PyTave and Symbolic

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PyTave and Symbolic

Colin Macdonald-2
On 20/05/16 03:40, Abhinav Tripathi wrote:
> I saw the python_to_octave.cc file
> and it seems that it throws exception when it can't recognise the
> object. So, how are we still getting the object when it is sym? I
> couldn't find it yet. Cause everytime i made a small change in pytave
> (basically only "cout<<" statements), i had to rebuild pytave and do
> everything again.

[replying to list]

Yes I often shy away from C++ for this reason! :-)

My plan was to modify python_to_octave.cc with special support for SymPy
objects (as a first step).

But maybe an easier way is possible: try this new PyTave bookmark:

https://bitbucket.org/macdonald/pytave/commits/branch/cbm_pyobj

Read "help @pyobj/dummy" and
http://wiki.octave.org/Python_interface#Python_Objects_in_Octave

Colin


Reply | Threaded
Open this post in threaded view
|

Re: PyTave and Symbolic

Abhinav Tripathi
Thanks. I went through the bookmark and the wiki.
I didn't know how to pull and use bookmarks in mercurial. So, it took some time.
.
I'll start from your code then and add upon it some more functionalities (adding conversion of @sym objects, to be specific)... Or should I add the functionality to main PyTave branch? (in case this is for testing only)...
I still don't know about PRs in hg. So, I'll go through some more mercurial tutorials before adding the conversion of @sym objects...
.
Abhinav

On Fri, May 20, 2016 at 8:40 PM, Colin Macdonald <[hidden email]> wrote:
On 20/05/16 03:40, Abhinav Tripathi wrote:
> I saw the python_to_octave.cc file
> and it seems that it throws exception when it can't recognise the
> object. So, how are we still getting the object when it is sym? I
> couldn't find it yet. Cause everytime i made a small change in pytave
> (basically only "cout<<" statements), i had to rebuild pytave and do
> everything again.

[replying to list]

Yes I often shy away from C++ for this reason! :-)

My plan was to modify python_to_octave.cc with special support for SymPy
objects (as a first step).

But maybe an easier way is possible: try this new PyTave bookmark:

https://bitbucket.org/macdonald/pytave/commits/branch/cbm_pyobj

Read "help @pyobj/dummy" and
http://wiki.octave.org/Python_interface#Python_Objects_in_Octave

Colin


Reply | Threaded
Open this post in threaded view
|

Re: PyTave and Symbolic

Colin Macdonald-2
On 22/05/16 07:54, Abhinav Tripathi wrote:
> Thanks. I went through the bookmark and the wiki.
> I didn't know how to pull and use bookmarks in mercurial. So, it took
> some time.

Same here :)

> I'll start from your code then and add upon it some more functionalities
> (adding conversion of @sym objects, to be specific)... Or should I add
> the functionality to main PyTave branch? (in case this is for testing
> only)...
> I still don't know about PRs in hg. So, I'll go through some more
> mercurial tutorials before adding the conversion of @sym objects...

I'm thinking we might *almost* have enough functionality in @pyobj that
you could try to use that directly in Symbolic's python_ipc_pytave.m:

After the line `pyexec(s)`, the stuff we want to return to Octave is in
a Python list called `_outs`.  Maybe we can just use something like:

tmp = pyeval('_outs[0]');

(note currently pyobj will not deal with the list correctly itself,
you'll need to get the elements of the list).

See python_header.py: "octoutput" function, specifically after the line
`elif x is None or isinstance(x, (sp.Basic, sp.MatrixBase)):`.  Compare
this to `extractblock.m` so see which properties of a SymPy Python
object we need to make a @sym object.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: PyTave and Symbolic

Jordi Gutiérrez Hermoso-2
On Sun, 2016-05-22 at 09:11 -0700, Colin Macdonald wrote:
> On 22/05/16 07:54, Abhinav Tripathi wrote:
> > Thanks. I went through the bookmark and the wiki. I didn't know
> > how to pull and use bookmarks in mercurial. So, it took some time.
>
> Same here :)

`hg pull` will pull everything, including all bookmarks. `hg pull
-r somebookmark` will pull just that bookmrk. Then `hg update
somebookmark` or `hg checkout somebookmark` will take your working
directory to that bookmark.

If you prefer, I'm often in IRC to answer this sort of question, both
in the #octave and #mercurial channels. Of course, many others can
answer these questions in the latter channel.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: PyTave and Symbolic

Abhinav Tripathi


> `hg pull` will pull everything, including all bookmarks. `hg pull
> -r somebookmark` will pull just that bookmrk. Then `hg update
> somebookmark` or `hg checkout somebookmark` will take your working
> directory to that bookmark.

Thanks

> If you prefer, I'm often in IRC to answer this sort of question, both
> in the #octave and #mercurial channels. Of course, many others can
> answer these questions in the latter channel.
>

Sure. I'll post any questions on mercurial as and when I encounter them. :)
.
Abhinav

Reply | Threaded
Open this post in threaded view
|

Re: PyTave and Symbolic

Abhinav Tripathi
In reply to this post by Colin Macdonald-2

I'm thinking we might *almost* have enough functionality in @pyobj that
you could try to use that directly in Symbolic's python_ipc_pytave.m:

So, we don't need to have @sym conversion logic in pytave anymore? Instead just bring it to python_ipc_pytave.m?
 
After the line `pyexec(s)`, the stuff we want to return to Octave is in
a Python list called `_outs`.  Maybe we can just use something like:

tmp = pyeval('_outs[0]');

(note currently pyobj will not deal with the list correctly itself,
you'll need to get the elements of the list).

See python_header.py: "octoutput" function, specifically after the line
`elif x is None or isinstance(x, (sp.Basic, sp.MatrixBase)):`.  Compare
this to `extractblock.m` so see which properties of a SymPy Python
object we need to make a @sym object.

I saw the files. It seems python_header.py and extractblock.m could be replaced with 1 mechanism in python_ipc_pytave.m (or in any other file).
I saw the fields that python_header.py is generating and how they are used in extractblock to create @sym object. I am assuming that all those fields are to be generated using pyeval and then used to generate the sym object. (probably by needing a new file like check_and_extract.m to check if it's a sympy object then do the conversion as required or else just return the _outs[0].
I'm working on this line and will probably submit a PR (on github) by tomorrow night (just to have an initial review and get guidance)...
.
Just one more question though, we need to ensure that proper version of pytave is being used on the user's end. (i.e., including the @pyobj as in ur bookmark). How do you propose to do that? (probably by first merging the changes in Mike's repo)
.
And, we are assuming that user builds pytave manually. Shouldn't we including something like automatic download and install of pytave (if pytave mechanism in supported -- atleast in *nix systems)?
.
Sorry for a lot of questions, I just wanted it all cleared out before submitting first code for review.
.
Abhinav
Reply | Threaded
Open this post in threaded view
|

Re: PyTave and Symbolic

Colin Macdonald-2
On 23/05/16 12:26, Abhinav Tripathi wrote:
> So, we don't need to have @sym conversion logic in pytave anymore?
> Instead just bring it to python_ipc_pytave.m

It looks like that might be possible.

> Just one more question though, we need to ensure that proper version of
> pytave is being used on the user's end.

I don't think we need to worry about that until we get near a release:
fairly common for dev versions of software to need the latest dev
version of some key dependency.

> And, we are assuming that user builds pytave manually. Shouldn't we
> including something like automatic download and install of pytave (if
> pytave mechanism in supported -- atleast in *nix systems)?

I think that's out of scope.  For example, `pkg install -forge pytave`
might someday do that.

> Sorry for a lot of questions, I just wanted it all cleared out before
> submitting first code for review.

Release early, release often: don't worry too much about getting it
"right" on the first try.  We probably don't know what "right" is yet
anyway ;-)

Colin