octave-maintainers
[Top][All Lists]
Advanced

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

Re: Just a note down of the upcoming changes to pytave - GSoC 2016


From: Mike Miller
Subject: Re: Just a note down of the upcoming changes to pytave - GSoC 2016
Date: Sat, 23 Jul 2016 12:25:19 -0700
User-agent: Mutt/1.6.0 (2016-04-01)

On Sat, Jul 23, 2016 at 20:09:37 +0530, Abhinav Tripathi wrote:
> Hi,
> Since most of our discussed updates are done (a major setback has been
> windows build), I would like to note down the upcoming changes into PyTave
> and Symbolic which will be carried out.
> This mail is meant to be an update on what is planned to be carried out in
> the project and take suggestions on whether/how to implement those.
> .
> 1- Provide an option to set execution namespace in pyexec to allow symbolic
> to run everything in its own namespace. Also it will provide an alternative
> for the hypothetical 'pystore' function that I proposed.

This is https://bitbucket.org/mtmiller/pytave/issues/25, right? Can you
or Colin explain this a bit more? I'm not sure I understand the concrete
changes to be made here and what the user interface will look like.

> 2- Drop the conversion of python objects to a bare minimum. (hence
> dictionaries, lists, tuples will remain as pyobjects)

Yes.

> 3- Use (1) to implement calling of pyobjects with multiple arguments and
> probably extend the same logic to pycall.
> Or maybe we can extend pycall so that a pyobject maybe passed instead of a
> function name. This will reduce duplicate code.

This is mostly done already.

> 4- Edit all BIST tests in pytave and symbolic to adapt to these changes.
> 5- Solve a few more pytave bugs.
> 6- Try to reduce latency of Symbolic functions such as 'vpa'.
> 7- Fix the errors on travis which are causing build fail for symbolic.
> 8- work on merging pytave branch to master such that tests work on all IPCs
> (currently error messages differ on different IPCs and hence tests may fail
> on some IPC other than pytave)

This all sounds good.

> I have been at my hometown for the past few weeks and due to lack of proper
> internet connection, the work done has been quite slow. From this Tuesday
> onwards I can work again with full freedom and I intend to complete the
> above mentioned tasks within 10 days (starting Wednesday).
> .
> Also, I will write the blog and wiki on windows build on Wednesday.
> I have tried the windows build using DLLs from some other sites too (just
> out of curiosity) but didn't get any closer.

Yes, please document the progress you made and the blockers here. If the
major blocker is boost, for example, then maybe working on making pytave
not depend on boost can be an important next task.

> As there are only a few weeks left for GSoC, please mention any other
> important tasks that should be given priority. And please give
> comments/suggestions on the tasks (or their order) I proposed here.
> I fully intend to work on PyTave and Symbolic after GSoC too but I would
> like to complete as much work possible before GSoC ends.

The bug I filed about seg faults with Python 3.5 is an important task
you can work on next. I'm trying to set the priority accordingly on the
issue tracker, so use that.

> Just one more question (more of an octave question than pytave) -
> If I write "s = 1" then s is considered to be double (not an integer!) in
> octave. Why is the default type double when there is no decimal point
> supplied?!

Because this is Matlab's behavior that we must adhere to. The default
numeric data type is a double. The mixed type conversion rules also
reflect this, for example in C a double added to an int produces a
double, but in Octave a double added to an int32 results in an int32.

> This caused some trouble for me. Because if I send it to pytave it will be
> converted to python float and hence I won't be able to use that variable as
> an index to a list.
> I have to do "s = int8(1)"  or some other int type for this simple thing...

Yes. Since the default type in Octave is a double, doubles may be used
as indices as long as they are integer-valued.

At the moment I think this has to be, but we might special case methods
like subsasgn, subsindex, and subsref for indexing if needed.

-- 
mike



reply via email to

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