Re: [Numpy-discussion] Integers to negative integer powers, time for a decision.

[V. Armando Sole]

Well, testing under windows 64 bit, Python 3.5.2, positive powers of 
integers give integers and negative powers of integers give floats. So, 
do you want to raise an exception when taking a negative power of an 
element of an array of integers? Because not doing so would be 
inconsistent with raising the exception when applying the same operation 
to the array.


Clearly things are broken now (I get zeros when calculating negative 
powers of numpy arrays of integers others than 1), but that behavior was 
consistent with python itself under python 2.x because the division of 
two integers was an integer. That does not hold under Python 3.5 where 
the division of two integers is a float.


You have offered either to raise an exception or to always return a 
float (i.e. even with positive exponents). You have never offered to be 
consistent with what Python does. This last option would be my favorite. 
If it cannot be implemented, then I would prefer always float. At least 
one would be consistent with something and we would not invent yet 
another convention.



On 08.10.2016 21:36, Charles R Harris wrote:

On Sat, Oct 8, 2016 at 1:31 PM, Krisztián Horváth
 wrote:


Hello,

I think it should be consistent with Python3. So, it should give
back a float.

Best regards,
Krisztian


Can't do that and also return integers for positive powers. It isn't
possible to have behavior completely compatible with python for
arrays: can't have mixed type returns, can't have arbitrary precision
integers.

Chuck

___
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] Integers to negative integer powers, time for a decision.

[V. Armando Sole]

Hi all,

Just to have the options clear. Is the operator '**' going to be handled 
in any different manner than pow?


Thanks.

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

Re: [Numpy-discussion] Integers to integer powers, let's make a decision

[V. Armando Sole]

Also in favor of 2. Always return a float for '**'

On 04.06.2016 21:47, josef.p...@gmail.com wrote:

On Sat, Jun 4, 2016 at 3:43 PM, Charles R Harris
 wrote:


On Sat, Jun 4, 2016 at 11:22 AM, Charles R Harris
 wrote:


Hi All,

I've made a new post so that we can make an explicit decision.
AFAICT, the two proposals are

* Integers to negative integer powers raise an error.
* Integers to integer powers always results in floats.

My own sense is that 1. would be closest to current behavior and
using a float exponential when a float is wanted is an explicit
way to indicate that desire. OTOH, 2. would be the most convenient
default for everyday numerical computation, but I think would more
likely break current code. I am going to come down on the side of
1., which I don't think should cause too many problems if we start
with a {Future, Deprecation}Warning explaining the workaround.


I'm in favor of 2.  always float for `**`
I don't see enough pure integer usecases to throw away a nice
operator.



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

Re: [Numpy-discussion] Best way to expose std::vector to be used with numpy

[V. Armando Sole]

On 15.10.2014 21:48, Chris Barker wrote:
 Sorry about SWIG -- maybe a chance to move on ;-)
 
 I'd go with Cython -- this is pretty straightforward, and it handles
 the buffer protocol for you under the hood.
 

+1


All the standard containers are automatically wrapped and C++ exceptions 
can be caught and translated to Python ones.

Armando

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

Re: [Numpy-discussion] [JOB ANNOUNCEMENT] Software Developer permanent position

[V. Armando Sole]

On 21.02.2014 10:55, David Goldsmith wrote:
 On Thu, Feb 20, 2014 at 10:37 PM,  wrote:

 Date: Fri, 21 Feb 2014 07:43:17 +0100
 From: V. Armando Sol?
 *Ref. 8173* *- Deadline for returning application forms: *
 *01/04/2014*

 I assume thats the European date format, i.e., the due date is April
 1, 2014, not Jan. 4 2014, oui?


Yes, it is European date format and it is *not* an April 1st joke.

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

[Numpy-discussion] [JOB ANNOUNCEMENT] Software Developer permanent position available at ESRF, France

[V. Armando Sole]

Dear colleagues,

The ESRF is looking for a Software Developer:

http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=300

Our ideal candidate would be experienced on OpenGL, OpenCL and Python.

Best regards,

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

Re: [Numpy-discussion] [JOB ANNOUNCEMENT] Software Developer permanent position available at ESRF, France

[V. Armando Sole]

Sorry, the link was in French ...

The English version:

http://esrf.profilsearch.com/recrute/fo_form_cand.php?_lang=enid=300

Best regards,

Armando


On 20.02.2014 18:21, V. Armando Sole wrote:
 Dear colleagues,

 The ESRF is looking for a Software Developer:

 http://esrf.profilsearch.com/recrute/fo_annonce_voir.php?id=300

 Our ideal candidate would be experienced on OpenGL, OpenCL and 
 Python.

 Best regards,

 Armando

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

Re: [Numpy-discussion] Windows, blas, atlas and dlls

[V. Armando Sole]

On 22.02.2013 19:54, Sergio Callegari wrote:

 from scipy.linalg.blas import fblas
 dgemm = fblas.dgemm._cpointer
 sgemm = fblas.sgemm._cpointer


 OK, but this gives me a PyCObject. How do I make it a function 
 pointer of the
 correct type in cython?


In cython I do not know it. I coded it directly in C.

In my code I receive the pointer in input2. The relevant part is:

 PyObject *input1;
 PyObject *input2 = NULL;
 /*pointer to dgemm function */
 void * gemm_pointer = NULL;

 /** statements **/
 if (!PyArg_ParseTuple(args, OO, input1, input2))
 return NULL;

 if (input2 != NULL){
#if PY_MAJOR_VERSION = 3
 if (PyCapsule_CheckExact(input2))
 gemm_pointer = PyCapsule_GetPointer(input2, NULL);
#else
 gemm_pointer = PyCObject_AsVoidPtr(input2);
#endif
   if (gemm_pointer != NULL)
   {
/* release the GIL */
 Py_BEGIN_ALLOW_THREADS
 /* your function call here */
 Py_END_ALLOW_THREADS
}
 }


Best regards,

Armando

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

Re: [Numpy-discussion] Windows, blas, atlas and dlls

[V. Armando Sole]

On 18.02.2013 21:23, Pauli Virtanen wrote:
 18.02.2013 20:41, Dag Sverre Seljebotn kirjoitti:
 [clip]
 I think there should be a new project, pylapack or similar, for 
 this,
 outside of NumPy and SciPy. NumPy and SciPy could try to import it, 
 and
 if found, fetch a function pointer table. (If not found, just stay 
 with
 what has been working for a decade.)

 The main motivation would be to decouple building NumPy from linking
 with BLAS and have that all happen at run-time. But a Cython 
 interface
 would follow naturally too.

 The main motivation for sticking it into Scipy would be a bit 
 different
 --- since the build and distribution infra is in place for Scipy,
 putting it in scipy.linalg makes it more easily available for a 
 larger
 number of people than some random 3-rd party module.

 We already ship low-level f2py bindings, so I don't see a reason for 
 not
 shipping Cython ones too.

I find Dag's approach more appealing.

SciPy can be problematic (windows 64-bit) and if one could offer access 
to the linear algebra functions without needing SciPy I would certainly 
prefer it.

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

Re: [Numpy-discussion] Windows, blas, atlas and dlls

[V. Armando Sole]

On 18.02.2013 22:47, Pauli Virtanen wrote:
 18.02.2013 23:29, V. Armando Sole kirjoitti:
 [clip]
 I find Dag's approach more appealing.

 SciPy can be problematic (windows 64-bit) and if one could offer 
 access
 to the linear algebra functions without needing SciPy I would 
 certainly
 prefer it.

 Well, the two approaches are not exclusive. Moreover, there already
 exist Cython wrappers for BLAS that you can just take and use.


Please correct me if I am wrong.

I assume those wrappers force you to provide the shared libraries so 
the problem is still there. If not, I would really be interested on 
getting one of those wrappers :-)

It is really nice to provide extensions receiving the pointer to the 
function to be used even under Linux: the extension does not need to be 
compiled each time the user changes/updates shared libraries. It is 
really nice to find your C extension is slow, you find ATLAS is not 
installed, you install it and your extension becomes very fast without 
needing to recompile.

 Windows 64-bit is probably problematic for everyone who wants to 
 provide
 binaries --- I don't think there's a big difference in difficulty in
 making binaries for a light Cython wrapper to BLAS/LAPACK vs. 
 providing
 the whole of Scipy :)

I have an Intel Fortran compiler license just to be able to provide 
windows 64-bit frozen binaries and extension modules :-) but that is not 
enough:

- If provide the MKL dll's a person willing to re-distribute the module 
also needs an MKL license
- If I do not provide the MKL dll's the extension module is useless

For the time being the best solution I have found is to use pointers to 
the wrapped functions in SciPy: the extension module use whatever 
library installed on the target system and I do not need to provide the 
shared libraries. It is just a pity that having the libraries in numpy, 
one cannot access them while one can do it in SciPy. Therefore I found 
Dag's approach quite nice: numpy and SciPy using the linear algebra 
functions via a third package providing all the needed pointers (or at 
least having that package available in first instance).

Best regards,

Armando

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

Re: [Numpy-discussion] Numpy unexpected (for me) behaviour

[V. Armando Sole]

At 01:44 23/01/2009 -0600, Robert Kern wrote:
It is an inevitable consequence of several features interacting
together. Basically, Python expands a[b] += 1 into this:

   c = a[b]
   d = c.__iadd__(1)
   a[b] = d

Basically, the array c doesn't know that it was created by indexing a,
so it can't do the accumulation you want.

Well inevitable would not be the word I would use. I would have expected a 
different behaviour between a[b] = a[b] + 1 and a[b] += 1

In the second case python (or numpy) does not need to generate an 
intermediate array and could be doing in-place operations.


  Is there a way I can achieve the first result
  without a for loop? In my application the difference is a factor 10 in
  execution time (1000 secons instead of 100 ...)

In [6]: bincount?
Type:   builtin_function_or_method
Base Class: type 'builtin_function_or_method'
String Form:built-in function bincount
Namespace:  Interactive
Docstring:
 bincount(x,weights=None)

 Return the number of occurrences of each value in x.

 x must be a list of non-negative integers.  The output, b[i],
 represents the number of times that i is found in x.  If weights
 is specified, every occurrence of i at a position p contributes
 weights[p] instead of 1.

 See also: histogram, digitize, unique.

Indeed what I am doing is very close to histogramming.

Unfortunaly what I have to add is not just one but a value. I have a set of 
scattered points (x,y,z) and values corresponding to those points. My goal 
is to get a regular grid in which in each voxel I sum the values of the 
points falling in them. I guess I will have to write a tiny C extension. I 
had expected the += sintax would trigger the in-place operation.

Best regards,

Armando 


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Numpy unexpected (for me) behaviour

[V. Armando Sole]

Hello,

In an effort to suppress for loops, I have arrived to the following situation.

Through vectorial logical operations I generate a set of indices for which 
the contents of an array have to be incremented. My problem can be reduced 
to the following:

#This works
import numpy
a=numpy.zeros(10)
b=numpy.ones(4, numpy.int)

for i in b:
 a[i] += 1
#a[1] contains 4 at the end


#This does not work
import numpy
a=numpy.zeros(10)
b=numpy.ones(4, numpy.int)
a[b] += 1

#a[1] contains 1 at the end

Is that a bug or a feature? Is there a way I can achieve the first result 
without a for loop? In my application the difference is a factor 10 in 
execution time (1000 secons instead of 100 ...)

Thanks,

Armando


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion