octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion on priorities for improving pytave


From: Abhinav Tripathi
Subject: Re: Suggestion on priorities for improving pytave
Date: Thu, 7 Jul 2016 12:36:24 +0530

Colin Macdonald <address@hidden> wrote:
I don't think we want to drop numpy.  I think the numpy dependency is the right thing for 2D/3D/nD arrays.  But I also think scalars should perhaps not be wrapped in numpy.  I think we have a bitbucket issue about this?

Oh. I forgot to consider nD arrays. Yes there is a bitbucket issue about scalar. I'll get to it then.
 
The other priorities sound fine to me.  I agree de-boosting could be time-consuming.

I'll follow-up about Symbolic priorities later...


On Thu, Jul 7, 2016 at 4:31 AM, Mike Miller <address@hidden> wrote:

Please make some notes, at some point it might be nice to get a summary
of what has been done so far and what the blockers are, either in a
README or on the wiki.

Sure. I will make a README and then try to upload the contents to a wiki page too.
 
Agree with Colin, I think we may want to keep numpy for arrays. Needs
some thought put into it. It may be possible to remove it if it's easy
enough to construct a numpy array from an Octave array. But that mode of
operation, whether done implicitly or explicitly, should remain easy.

Wouldn't it be the same as now? I mean if we just add a special case for 1x1 arrays then everything else remain as is, right?
 
Once the pyobject stuff is merged, though, you could look at removing
some of the other non-array conversions, for example the automatic
conversions to cell arrays and struct arrays.

Definitely.
 
Sorry, I'm not sure I follow. Can you demonstrate with some code what
you mean by this? I'm all for making it easier to convert Octave data
types into Python, just not sure what use case you are talking about.

Currently if I have to store an octave variable in python with a particular name. I will do:
----------------------------------------------------------------------------------
pyexec ([ "global var_with_req_name" ...
              "def func_to_fill_var(x):" ...
              "    global var_with_req_name" ...
              "    var_with_req_name = x" ]);
pycall ("func_to_fill_var", req_octave_value);
----------------------------------------------------------------------------------
It seems a little too much to do for just storing a variable, instead I would like to do:
----------------------------------------------------------------------------------
pystore ("var_with_req_name", req_octave_value);
----------------------------------------------------------------------------------

Yes, not sure about the method you describe, but definitely adding
support for arbitary argument lists, and also unpacking multiple return
values.

I just meant we could store all the arguments to a python variable (tuple/list) using pystore and then call then function with unpacking that python variable.
 
Maybe some kind of support for function kwargs as well? A scalar struct
to pass named parameters?

This could prove to be a bit tricky. I tried but couldn't use map unpacking to call a python function.

Yes, and this could easily be done incrementally. As you've seen and
started doing in your PRs, you can mix and match the Python native API
with the Boost.Python API to some extent.

Sure.
 
I have been idle on pytave for the past week or so, but I am hoping to
get back into it and review and merge all of the work you and Colin have
been putting into it. Once I get all of the outstanding PRs and issues
handled, I will try to brainstorm some more immediate ideas for
improvements.

Thank you for your contributions so far!

--
mike

It had been nice working with both of you. I got a lot of support from the octave community which made it easier to work as per the timeline...
.
Abhinav

reply via email to

[Prev in Thread] Current Thread [Next in Thread]