[Numpy-discussion] Numpy scalar integers to negative scalar integer powers.

[Charles R Harris]

Hi All,

I've put up a PR to deal with the numpy scalar integer powers at
https://github.com/numpy/numpy/pull/8221. Note that for now everything goes
through the np.power function.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] How to use user input as equation directly

[Robert McLeod]

On Thu, Oct 27, 2016 at 11:35 PM, Benjamin Root 
wrote:

> Perhaps the numexpr package might be safer? Not exactly meant for this
> situation (meant for optimizations), but the evaluator is pretty darn safe.
>
>
It would not be able to evaluate something like 'np.arange(50)' for
example, since it only has a limited subset of numpy functionality. In the
example provided that or linspace is likely the natural input for the
variable 't'.

-- 
Robert McLeod, Ph.D.
Center for Cellular Imaging and Nano Analytics (C-CINA)
Biozentrum der Universität Basel
Mattenstrasse 26, 4058 Basel
Work: +41.061.387.3225
robert.mcl...@unibas.ch
robert.mcl...@bsse.ethz.ch 
robbmcl...@gmail.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] How to use user input as equation directly

[Ben Rowland]

It is important to bear in mind where the code is being run - if this is 
something running on a researcher’s own system, they almost certainly have lots 
of other ways of messing it up. These kind of security vulnerabilities are 
normally only relevant when you are running code that came from somewhere else.

That being said, this use case sounds like it could work with the Jupyter 
notebook. If you want something that is like typing code into a .py file but 
evaluated at run time instead, why not just use an interactive Python REPL 
instead of eval(input()).

Ben

> On 27 Oct 2016, at 17:52, Benjamin Root  wrote:
> 
> "only be used by engineers/scientists for research"
> 
> Famous last words. I know plenty of scientists who would love to "do 
> research" with an exposed eval(). Full disclosure, I personally added a 
> security hole into matplotlib thinking I covered all my bases in protecting 
> an eval() statement.
> 
> Ben Root
> 
> On Thu, Oct 27, 2016 at 4:21 PM, djxvillain  > wrote:
> This will not be a public product and will only be used by other
> engineers/scientists for research.  I don't think security should be a huge
> issue, but I appreciate your input and concern for the quality of my code.
> 
> 
> 
> --
> View this message in context: 
> http://numpy-discussion.10968.n7.nabble.com/How-to-use-user-input-as-equation-directly-tp43665p43670.html
>  
> 
> Sent from the Numpy-discussion mailing list archive at Nabble.com.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org 
> https://mail.scipy.org/mailman/listinfo/numpy-discussion 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] padding options for diff

[Marten van Kerkwijk]

Matthew has made what looks like a very nice implementation of padding
in np.diff in https://github.com/numpy/numpy/pull/8206. I raised two
general questions about desired behaviour there that Matthew thought
we should put out on the mailiing list as well. This indeed seemed a
good opportunity to get feedback, so herewith a copy of
https://github.com/numpy/numpy/pull/8206#issuecomment-256909027

-- Marten

1. I'm not sure that treating a 1-d array as something that will just
extend the result along `axis` is a good idea, as it breaks standard
broadcasting rules. E.g., consider
```
np.diff([[1, 2], [4, 8]], to_begin=[1, 4])
# with your PR:
array([[1, 4, 1],
   [1, 4, 4]])
# but from regular broadcasting I would expect
array([[1, 1],
   [4, 4]])
# i.e., the same as if I did to_begin=[[1, 4]]
```
I think it is slightly odd to break the broadcasting expectation here,
especially since the regular use case surely is just to add a single
element so that one keeps the original shape. The advantage of
assuming this is that you do not have to do *any* array shaping of
`to_begin` and `to_end` (which perhaps also suggests it is the right
thing to do).

2. As I mentioned above, I think it may be worth thinking through a
little what to do with higher order differences, at least for
`to_begin='first'`. If the goal is to ensure that with that option, it
becomes the inverse of `cumsum`, then I think for higher order one
should add multiple elements in front, i.e., for that case, the
recursive call should be
```
return np.diff(np.diff(a, to_begin='first'), n-1, to_begin='first')
```
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion