Skip to content

Support for order kwarg in Lambdify #188

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 6 commits into from
Sep 22, 2017
Merged

Conversation

bjodah
Copy link
Contributor

@bjodah bjodah commented Sep 19, 2017

This addresses gh-174.

@bjodah
Copy link
Contributor Author

bjodah commented Sep 19, 2017

@raphaelquast I thought you might be interested. Any feedback (you can look at the test cases) is much appreciated.

@bjodah
Copy link
Contributor Author

bjodah commented Sep 20, 2017

Running times for benchmarks/heterogeneous_output_Lambdify.py are pretty much unaffected. Before this PR:

SymEngine (lambda double)       speed-up factor (higher is better) vs sympy:       40.154
symengine (LLVM)                speed-up factor (higher is better) vs sympy:        306.3
symengine (ManualLLVM)          speed-up factor (higher is better) vs sympy:       297.43

Using this PR:

SymEngine (lambda double)       speed-up factor (higher is better) vs sympy:       40.659
symengine (LLVM)                speed-up factor (higher is better) vs sympy:       270.86
symengine (ManualLLVM)          speed-up factor (higher is better) vs sympy:       313.15

@isuruf
Copy link
Member

isuruf commented Sep 20, 2017

I wouldn't worry much about LambdifyCSE as I'll get this PR finished before the next release and then we can get rid of sympy.

@bjodah
Copy link
Contributor Author

bjodah commented Sep 20, 2017

I saw that one -- impressive!
The fix of LambdifyCSE here is actually only a minor part of the PR. The biggest change here is that it allows the user to specify order ('C' or 'F') which is passed to numpy.ravel and numpy.reshape. This gives the user control over whether extra dimensions should be added "on the right" or "on the left".

Copy link
Member

@isuruf isuruf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure whether we want order at both initialization and eval. Otherwise looks good to me.

@@ -4399,16 +4365,20 @@ cdef class _Lambdify(object):
cdef list out_shapes
cdef readonly bint real
cdef readonly int n_exprs
cdef readonly str order
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make this a char?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried that, but Cython seems to inject logic expecting an integer then.

self.numpy_dtype = np.float64 if self.real else np.complex128
self.out_shapes = [get_shape(expr) for expr in exprs]
self.out_shapes = [np.asarray(expr).shape for expr in exprs]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is creating a numpy array just to get the shape. Isn't that expensive? I guess it doesn't matter much because this is in setup phase.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be more expensive, that's true. This was mostly the get rid of some non-trivial logic (the get_shape function). Maybe we should benchmark the creation of Lambdify instances as well.

@bjodah
Copy link
Contributor Author

bjodah commented Sep 21, 2017

Since both args and exprs have numpy.ravel applied to them they are still converted to arrays. I changed the logic so that conversion only happens once now.

@bjodah
Copy link
Contributor Author

bjodah commented Sep 21, 2017

One of the travis jobs needs a restart.

@bjodah
Copy link
Contributor Author

bjodah commented Sep 22, 2017

Ok, I think I'm happy with this on my side. Anything else you'd like me to change @isuruf ?
Regarding the next release: any time plan for that?
Would there be interest in backporting this into a patch release for v0.3 (i.e. v0.3.1)?

EDIT: if one uses e.g. conda config --add channels symengine/label/dev, does that mean that I continuously get the master branch of python-symengine?

@raphaelquast
Copy link

@bjodah thanks a lot for getting this issue running!

I haven't had the time to check the changes so far,
but i definitely will and in case I encounter any troubles I'll let you know.


def __cinit__(self, args, *exprs, cppbool real=True):
def __cinit__(self, args, *exprs, cppbool real=True, order='C'):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about moving all the stuff from here to __init__ and remove storing args and exprs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch. Works locally, pushed now.

@isuruf
Copy link
Member

isuruf commented Sep 22, 2017

Regarding the next release: any time plan for that?

No plans yet. I was thinking of a release every six months.

EDIT: if one uses e.g. conda config --add channels symengine/label/dev, does that mean that I continuously get the master branch of python-symengine?

That was the initial plan, but we felt it's a waste of CI resources. So, whenever someone wants a new binary, a PR is made, like https://github.com/symengine/python-symengine-feedstock/pull/2/files

Copy link
Member

@isuruf isuruf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. I'll merge when tests pass.

@ShikharJ ShikharJ merged commit 3fd1e48 into symengine:master Sep 22, 2017
@ShikharJ
Copy link
Member

Thanks for the PR.

@raphaelquast
Copy link

@isuruf

That was the initial plan, but we felt it's a waste of CI resources. So, whenever someone wants a
new binary, a PR is made, like https://github.com/symengine/python-symengine-feedstock/pull/2/files

unfortunately i don't fully get what you mean by that...
...in case i would like to test the new changes within my project, how do i get a
working binary (that incorporates the fixes) to replace my current installation of symengine?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants