[Numpy-discussion] Problem while writing array with np.savetxt

[Andrew Nelson]

Dear list,
whilst trying to write an array to disk I am coming across the following.
What am I doing wrong?  Surely f is a file handle?
(python 3.4.3, numpy 1.9.2)

import numpy as np
a = np.arange(10.)
with open('test.dat', 'w') as f:
np.savetxt(f, a)

---

TypeError Traceback (most recent call
last) in ()  2 a =
np.arange(10.)  3 with open('test.dat', 'w') as f:> 4
np.savetxt(f, a)
/Users/anz/Documents/Andy/programming/dev3/lib/python3.4/site-packages/numpy/lib/npyio.py
in savetxt(fname, X, fmt, delimiter, newline, header, footer,
comments)   1085 else:   1086 for row in X:-> 1087
fh.write(asbytes(format % tuple(row) + newline))
1088 if len(footer) > 0:   1089 footer =
footer.replace('\n', '\n' + comments)
TypeError: must be str, not bytes




-- 
_
Dr. Andrew Nelson


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

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Jens Jørgen Mortensen]

On 09/23/2015 06:07 AM, Nathaniel Smith wrote:

On Tue, Sep 22, 2015 at 8:12 PM, Charles R Harris
 wrote:

Hi all,

I'm pleased to announce the availability of Numpy 1.10.0rc1. Sources and 32
bit binary packages for Windows may be found at Sourceforge.  Please test
this out, as I would like to move to the final release as rapidly as
possible and the lack of error reports from the beta has left me nervous.
It's been quiet, too quiet. In the movies, we would all die in the next five
minutes.


Hi!

I found this strange thing:

jensj@jordan:~$ python
Python 2.7.9 (default, Apr  2 2015, 15:33:21)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a = np.zeros((2, 2, 2))
>>> b = np.zeros((2, 2, 2))
>>> a[0, 0] = 7
>>> b[0, 0] = 6
>>> np.vdot(a[:, :, 0], b[:, :, 0]).real
84.0
>>> np.__version__
'1.10.0rc1'

The result should be 42.  This is on Ubuntu 15.04.

Jens Jørgen

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

Re: [Numpy-discussion] draft NEP for breaking ufunc ABI in a controlled way

[Nathaniel Smith]

On Tue, Sep 22, 2015 at 7:57 AM, Antoine Pitrou  wrote:
>
> Hi,
>
> This e-mail is an attempt at proposing an API to solve Numba's needs.

Thanks!

> Attribute access
> 
>
> int PyUFunc_Nin(PyUFuncObject *)
>
>   Replaces ufunc->nin.
>
> int PyUFunc_Nout(PyUFuncObject *)
>
>   Replaces ufunc->nout.
>
> int PyUFunc_Nargs(PyUFuncObject *)
>
>   Replaces ufunc->nargs.
>
> PyObject *PyUFunc_Name(PyUFuncObject *)
>
>   Replaces ufunc->name, returns a unicode object.
>   (alternative: return a const char *)

These all seem trivially supportable going forward.

> For introspection, the following would be nice too:
>
> int PyUFunc_Identity(PyFuncObject *)
>
>   Replaces ufunc->identity.

Hmm, I can imagine cases where we might want to change how this works.
(E.g. if np.dot were a ufunc then the existing identity settings
wouldn't work very well... and I have some vague memory that there
might already some delicate code in a few places because of
difficulties in defining "zero" and "one" for arbitrary dtypes.)

> const char *PyUFunc_Signature(PyUFuncObject *, int i)
>
>   Gives a pointer to the types of the i'th signature.
>   (equivalent today to &ufunc->ntypes[i * ufunc->nargs])

I assume the 'i' part isn't actually interesting here (since there's
no longer any parallel vector of function pointers accessible), and
the high-level semantics that you're looking for are "please give me
the set of signatures that have a loop defined"?

[Edit: Also, see the discussion below about integer type pointers. The
consequences here are that we can certainly provide an operation like
this, but if we do then we might be abandoning it in a few releases
(e.g. it might start telling you about only a subset of defined
signatures). So can you expand a bit on what you mean by "would be
nice" above?]

> Lifetime control
> 
>
> PyObject *PyUFunc_SetObject(PyUFuncObject *, PyObject *)
>
>   Sets the ufunc's "object" to the given object.  The object has no
>   special semantics except that it is DECREF'ed when the ufunc is
>   deallocated (this is today's ufunc->obj).  The DECREF should happen
>   only after the ufunc has accessed any internal resources (since the
>   DECREF could deallocate some of those resources).

I understand why you need a "base" object like this for individual
loops, but if ufuncs start managing the ufunc-level memory buffers
internally, then is this still useful? I guess I'm curious to see an
example.

> PyObject *PyUFunc_GetObject(PyUFuncObject *)
>
>   Return the ufunc's current "object".

Oh, are you planning to actually use this to attach some arbitrary
metadata, not just attach deallocation callbacks?

> Loop registration
> -
>
> int PyUFunc_RegisterLoopForSignature(
> PyUFuncObject* ufunc,
> PyUFuncGenericFunction function, int *arg_types,
> void *data, PyObject *obj)
>
>   Register a loop implementation for the given arg_types (built-in
>   types, presumably). This either appends the loop to the types and
>   functions array (reallocating it if necessary), or replaces an
>   existing one with the same signature.
>
>   A copy of arg_types is done, such that the caller does not have to
>   manage its lifetime. The optional "PyObject *obj" is an object which
>   gets DECREF'ed when the loop is relinquished (for example when the
>   ufunc is destroyed, or when the loop gets replaced with another by
>   calling this function again).
>
>
> I cannot say I'm 100% sure this is sufficient, but this seems it should
> cover our current needs.
>
> Note this is a minimal proposal. For example, Numpy could instead decide
> to pass and return all argument types as PyArray_Descr pointers rather
> than raw integers, and that would probably work for us too.

Hmm, that's an interesting and tricky point, actually -- I think the
way it will work eventually is that signatures will be specified in
terms of "dtypetypes" (i.e., subclasses of dtype, rather than ints
*or* instances of dtype = PyArray_Descrs). But I guess that's just a
challenge we'll have to think about when implementing this stuff --
either it means that the new ufunc API will have to wait a bit for
more of the new dtype machinery to be ready, or we'll have to
temporarily bridge the gap with an loop registration API that takes
new-style loop callbacks but uses int signatures (and then later turn
it into a thin wrapper around the final API).

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Nathaniel Smith]

On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant  wrote:
>>
>> Here is a list of the current Contributors to the main NumPy repository:
>>
>>
>> [https://github.com/numpy/numpy/graphs/contributors](https://github.com/numpy/numpy/graphs/contributors)
>>
>
> One of the problems with this list is that my contributions to the project
> are extremely under-represented because the large majority of my commitment
> of code happened in 2005 to 2006 before github was used.  So, using this
> as a list of the contributors is quite misleading --- and there are a lot of
> people now looking only at lists like this one and it might confuse them why
> I care so much.So, if you are going to make this list public in a
> governance document like this, then I think some acknowledgement of the
> source of the original code and the contributors to that needs to also be
> made --- or you could just also point to the THANKS document which lists
> people up to about 2008.   Between 2008 and 2010 we will lose contributions,
> still and this can be acknowledged.

I'm actually not even sure why this link is even here -- it's another
thing that just got copied from Jupyter/IPython :-)

It looks like the reason your commits are massively undercounted on
that page is that github uses emails to match up commits to github
accounts. Unfortunately it looks like almost all your old commits used
 for your email address, and apparently the
@teoliphant github account doesn't have that listed as one of its
emails. I guess that's probably unfixable on your end, and while git
has a standard way to solve these issues (.mailmap -- that's why
Stephan got the right answer from git shortlog), github is not clever
enough to use it:
   https://github.com/holman/ama/issues/551#issuecomment-46129792

So it sounds like that page is basically unfixable, and if it's
misleading then we should just delete it from the doc. We definitely
don't want to diminish anyone's contributions!

[snip]
>> ### Council membership
>>
>> To become eligible to join the Steering Council, an individual must be a
>> Project Contributor who has produced contributions that are substantial in
>> quality and quantity, and sustained over at least one year. Potential
>> Council Members are nominated by existing Council members and voted upon by
>> the existing Council after asking if the potential Member is interested and
>> willing to serve in that capacity. The Council will be initially formed from
>> the set of existing Core Developers who, as of late 2015, have been
>> significantly active over the last year.
>>
>
> Concretely, I'm asking to be included in this initial council so a simple
> "along with Travis Oliphant who is the original author of NumPy".   If other
> long-time contributors to the code-base also want to be on this initial seed
> council, I think it would make sense as well.

I'll leave this discussion for the other thread that's specifically
about the council membership, so as not to confuse matters.

>>
>> When considering potential Members, the Council will look at candidates
>> with a comprehensive view of their contributions. This will include but is
>> not limited to code, code review, infrastructure work, mailing list and chat
>> participation, community help/building, education and outreach, design work,
>> etc. We are deliberately not setting arbitrary quantitative metrics (like
>> “100 commits in this repo”) to avoid encouraging behavior that plays to the
>> metrics rather than the project’s overall well-being. We want to encourage a
>> diverse array of backgrounds, viewpoints and talents in our team, which is
>> why we explicitly do not define code as the sole metric on which council
>> membership will be evaluated.
>>
>> If a Council member becomes inactive in the project for a period of one
>> year, they will be considered for removal from the Council. Before removal,
>> inactive Member will be approached to see if they plan on returning to
>> active participation. If not they will be removed immediately upon a Council
>> vote. If they plan on returning to active participation soon, they will be
>> given a grace period of one year. If they don’t return to active
>> participation within that time period they will be removed by vote of the
>> Council without further grace period. All former Council members can be
>> considered for membership again at any time in the future, like any other
>> Project Contributor.  Retired Council members will be listed on the project
>> website, acknowledging the period during which they were active in the
>> Council.
>
>
> I would just remove quite a bit of this language and just say that members
> who are inactive on the Council may be asked to step down if they are not
> planning on returning to active participation.

I think it's important to have *some* kind of relatively
objective/impartial criteria here, because if the rules force somebody
to be the bad guy before anyone can get pruned, then the council will

Re: [Numpy-discussion] Problem while writing array with np.savetxt

[Eric Firing]

On 2015/09/23 9:17 PM, Andrew Nelson wrote:

Dear list,
whilst trying to write an array to disk I am coming across the
following.  What am I doing wrong?  Surely f is a file handle?
(python 3.4.3, numpy 1.9.2)

import numpy as np
a = np.arange(10.)
with open('test.dat', 'w') as f:
 np.savetxt(f, a)



It will work if you open with 'wb'.  Yes, this seems like a bug; or at 
least, the anomaly should be noted in the docstring.


Eric


---

TypeError  Traceback (most recent call last)
  in() 2 a = np.arange(10.)3 with 
open('test.dat', 'w') as f:>
4np.savetxt(f,
a)/Users/anz/Documents/Andy/programming/dev3/lib/python3.4/site-packages/numpy/lib/npyio.py
in savetxt(fname, X, fmt, delimiter, newline, header, footer, comments)
1085 else:1086 for row in X:-> 1087fh.write(asbytes(format % tuple(row)
+ newline))1088 if len(footer) > 0:1089 footer = footer.replace('\n',
'\n' + comments)TypeError: must be str, not bytes




--
_
Dr. Andrew Nelson


_


___
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] interpretation of the draft governance document (was Re: Governance model request)

[Nathaniel Smith]

On Thu, Sep 24, 2015 at 12:22 AM, Nathaniel Smith  wrote:
> So it sounds like that page is basically unfixable, and if it's
> misleading then we should just delete it from the doc. We definitely
> don't want to diminish anyone's contributions!

I just posted a pull request version of the governance document:

   https://github.com/numpy/numpy/pull/6352

It's definitely still a draft, but now that we're making changes I
wanted to get it into a form where people can at least see what those
are :-).

In interests of making that easy, the PR is structured as a
ReST-converted version of the document originally posted, plus
clearly-separated commits on top of that.

The only non-trivial changes are:
- I split the lists of people out into a separate document:
https://github.com/njsmith/numpy/blob/governance/doc/source/dev/governance/people.rst
  (currently filled with the original seed council proposal for the
reasons mentioned above)
- I removed the link to the inaccurate github "contributors" page

-n

-- 
Nathaniel J. Smith -- http://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: numtraits v0.2

[Thomas Robitaille]

Hi Sylvain,

Sylvain Corlay wrote:
> Hi Thomas,
> 
> This is great news! 
> 
> FYI, the traitlets module has been undergoing significant refactoring
> lately, improving the API to favor a broader usage in the community. 
> One reason for this is that several projects outside of the Jupyter
> organization are considering adopting traitlets. You can find a summary
> of the ongoing work and API changes
> here: https://github.com/ipython/traitlets/issues/48
> 
> One of the items in this discussion is about what would be the best
> place for a repository of trait types for standard data structures of
> the scipy stack (numpy array, pandas series and dataframes, etc...) It
> is unlikely that such trait types would be accepted in those libraries
> at this moment, and the main traitlets package might not be the right
> place for it either - hence the need for another repo. However, if we
> don't work on a centralized project, we will probably see a number of
> competing implementations in different libraries that are clients of
> traitlets.
> 
> Hence the idea would be to propose a new project in the Jupyter
> incubator with a reference implementation. What would be cool would be
> to join forces and work on a specification or start a discussion of what
> the ideal implementation for such trait types would look like.

I'm very open to collaborating on centralizing these kind of scipy-stack
traits. I'm not particularly attached to the idea of keeping our
numtraits implementation separate, and would be very happy to merge it
in to a larger effort or only re-use parts of it. Realistically I won't
be able to lead/write a proposal for the incubator in the next few
weeks, but if no one gets to it first, I can try and work on it later in
the year.

Cheers,
Tom

> 
> Cheers,
> 
> Sylvain
> 
> 
> On Wed, Sep 23, 2015 at 12:39 PM, Thomas Robitaille
> mailto:thomas.robitai...@gmail.com>> wrote:
> 
> Hi everyone,
> 
> We have released a small experimental package called numtraits that
> builds on top of the traitlets package and provides a NumericalTrait
> class that can be used to validate properties such as:
> 
> * number of dimension (for arrays)
> * shape (for arrays)
> * domain (e.g. positive, negative, range of values)
> * units (with support for astropy.units, pint, and quantities)
> 
> The idea is to be able to write a class like:
> 
> class Sphere(HasTraits):
> 
> radius = NumericalTrait(domain='strictly-positive', ndim=0)
> position = NumericalTrait(shape=(3,))
> 
> and all the validation will then be done automatically when the user
> sets 'radius' or 'position'.
> 
> In addition, tuples and lists can get automatically converted to
> arrays, and default values can be specified. You can read more about
> the package and see examples of it in use here:
> 
>   https://github.com/astrofrog/numtraits
> 
> and it can be easily installed with
> 
>   pip install numtraits
> 
> The package supports both Python 3.3+ and Legacy Python (2.7) :)
> 
> At this point, we would be very interested in feedback - the package
> is still very young and we can still change the API if needed. Please
> open issues with suggestions!
> 
> Cheers,
> 
> Tom and Francesco
> ___
> 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] interpretation of the draft governance document (was Re: Governance model request)

[Sebastian Berg]

On Do, 2015-09-24 at 00:22 -0700, Nathaniel Smith wrote:
> On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant  wrote:
> >>
> >> Here is a list of the current Contributors to the main NumPy repository:

> >>
> >> To become eligible to join the Steering Council, an individual must be a
> >> Project Contributor who has produced contributions that are substantial in
> >> quality and quantity, and sustained over at least one year. Potential
> >> Council Members are nominated by existing Council members and voted upon by
> >> the existing Council after asking if the potential Member is interested and
> >> willing to serve in that capacity. The Council will be initially formed 
> >> from
> >> the set of existing Core Developers who, as of late 2015, have been
> >> significantly active over the last year.
> >>
> >
> > Concretely, I'm asking to be included in this initial council so a simple
> > "along with Travis Oliphant who is the original author of NumPy".   If other
> > long-time contributors to the code-base also want to be on this initial seed
> > council, I think it would make sense as well.
> 
> I'll leave this discussion for the other thread that's specifically
> about the council membership, so as not to confuse matters.

Well, I think we can at least learn one thing from this directly. I
think we should include some relation to historic contributions into the
document. I think what might be nice to do would be for example to also
"seed" the emeritus list (if it is not too difficult).
It is somewhat unrelated to governance, but since we want it to be a
prominent document, it should not overshadow the past.

- Sebastian



> 
> -n
> 



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Problem while writing array with np.savetxt

[Julian Taylor]

numpy text io is fundamentally broken in python3, there are sometimes
workarounds, but currently its probably best to stick to python2 or not
use it.
The workarounds usually just make actually fixing the functions harder.

On 09/24/2015 09:24 AM, Eric Firing wrote:
> On 2015/09/23 9:17 PM, Andrew Nelson wrote:
>> Dear list,
>> whilst trying to write an array to disk I am coming across the
>> following.  What am I doing wrong?  Surely f is a file handle?
>> (python 3.4.3, numpy 1.9.2)
>>
>> import numpy as np
>> a = np.arange(10.)
>> with open('test.dat', 'w') as f:
>>  np.savetxt(f, a)
>>
> 
> It will work if you open with 'wb'.  Yes, this seems like a bug; or at
> least, the anomaly should be noted in the docstring.
> 
> Eric
> 
>> ---
>>
>>
>> TypeError  Traceback (most recent call
>> last)
>>   in() 2 a = np.arange(10.)3
>> with open('test.dat', 'w') as f:>
>> 4np.savetxt(f,
>> a)/Users/anz/Documents/Andy/programming/dev3/lib/python3.4/site-packages/numpy/lib/npyio.py
>>
>> in savetxt(fname, X, fmt, delimiter, newline, header, footer, comments)
>> 1085 else:1086 for row in X:-> 1087fh.write(asbytes(format % tuple(row)
>> + newline))1088 if len(footer) > 0:1089 footer = footer.replace('\n',
>> '\n' + comments)TypeError: must be str, not bytes
>>
>>
>>
>>
>> -- 
>> _
>> Dr. Andrew Nelson
>>
>>
>> _
>>
>>
>> ___
>> 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] interpretation of the draft governance document (was Re: Governance model request)

[Robert Kern]

On Wed, Sep 23, 2015 at 11:12 PM, Travis Oliphant 
wrote:

>> [We also have to decide on the initial membership for the Council. While
the above text makes pains to distinguish between "committer" and "Council
Member", in the past we've pretty much treated them as the same. So to keep
things simple and deterministic, I propose that we seed the Council with
everyone who has reviewed/merged a pull request since Jan 1, 2014, and move
those who haven't used their commit bit in >1.5 years to the emeritus list.
Based on the output of
>>
>>git log --grep="^Merge pull request" --since 2014-01-01 | grep
Author: | sort -u
>>
>> I believe this would give us an initial Steering Council of: Sebastian
Berg, Jaime Fernández del Río, Ralf Gommers, Alex Griffing, Charles Harris,
Nathaniel Smith, Julian Taylor, and Pauli Virtanen (assuming everyone on
that list is interested/willing to serve).]
>
> I would ask to be on this initial council by having the rule include
"original contributors of the code" which would basically include Robert
Kern and Pearu Peterson in addition to Chuck Harris (though Pearu's main
contribution was numpy.distutils and f2py and he may not be interested any
longer in the rest of it).

Were I to want such a thing, I would simply review and merge one of the
many languishing PRs. I have the power to add myself to this list without
asking for special exemptions to the general rule, merely a token bit of
effort on my part.

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

Re: [Numpy-discussion] draft NEP for breaking ufunc ABI in a controlled way

[Antoine Pitrou]

On Thu, 24 Sep 2015 00:20:23 -0700
Nathaniel Smith  wrote:
> > int PyUFunc_Identity(PyFuncObject *)
> >
> >   Replaces ufunc->identity.
> 
> Hmm, I can imagine cases where we might want to change how this works.
> (E.g. if np.dot were a ufunc then the existing identity settings
> wouldn't work very well... and I have some vague memory that there
> might already some delicate code in a few places because of
> difficulties in defining "zero" and "one" for arbitrary dtypes.)

Yes... As long as there is a way for us to set the identity value
(whatever the exact API) when constructing a ufunc, it should be ok.

> I assume the 'i' part isn't actually interesting here (since there's
> no longer any parallel vector of function pointers accessible), and
> the high-level semantics that you're looking for are "please give me
> the set of signatures that have a loop defined"?

Indeed.

> [Edit: Also, see the discussion below about integer type pointers. The
> consequences here are that we can certainly provide an operation like
> this, but if we do then we might be abandoning it in a few releases
> (e.g. it might start telling you about only a subset of defined
> signatures). So can you expand a bit on what you mean by "would be
> nice" above?]

"Would be nice" really means "we could make use of it" for letting the
user access ufunc metadata. We don't *need* it currently. But
generally being able to query the high-level properties of a ufunc,
from C, sounds like a good thing, and perhaps other people would be
interested.

> > PyObject *PyUFunc_SetObject(PyUFuncObject *, PyObject *)
> >
> >   Sets the ufunc's "object" to the given object.  The object has no
> >   special semantics except that it is DECREF'ed when the ufunc is
> >   deallocated (this is today's ufunc->obj).  The DECREF should happen
> >   only after the ufunc has accessed any internal resources (since the
> >   DECREF could deallocate some of those resources).
> 
> I understand why you need a "base" object like this for individual
> loops, but if ufuncs start managing the ufunc-level memory buffers
> internally, then is this still useful? I guess I'm curious to see an
> example.

Well, for example, we dynamically allocate the ufunc's name (and
possibly its docstring), so we need to deallocate it when the ufunc is
destroyed.  Actually, we should probably deallocate more stuff that we
currently don't (such as the execution environment)...

> > PyObject *PyUFunc_GetObject(PyUFuncObject *)
> >
> >   Return the ufunc's current "object".
> 
> Oh, are you planning to actually use this to attach some arbitrary
> metadata, not just attach deallocation callbacks?

No, just deallocation callbacks. I was including the GetObject function
for completeness, I'm not sure we would need it (but it sounds trivial
to provide and maintain).

> Hmm, that's an interesting and tricky point, actually -- I think the
> way it will work eventually is that signatures will be specified in
> terms of "dtypetypes" (i.e., subclasses of dtype, rather than ints
> *or* instances of dtype = PyArray_Descrs).

Subclasses? I'm not sure what you mean by that, how would one specify
e.g. an int64 vs. an int32?

Are you referring to Travis' dtypes-as-classes project, or something
similar? In that case though, a dtype would still be an instance of a
"dtypetype" (metatype), not a subclass :-)

> But I guess that's just a
> challenge we'll have to think about when implementing this stuff --
> either it means that the new ufunc API will have to wait a bit for
> more of the new dtype machinery to be ready, or we'll have to
> temporarily bridge the gap with an loop registration API that takes
> new-style loop callbacks but uses int signatures (and then later turn
> it into a thin wrapper around the final API).

Well, as long as you keep the int typecodes in Numpy (and I guess
you'll do for quite some time, for compatibility), bridging should be
easy indeed.

Regards

Antoine.


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

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

[Sebastian Berg]

On Mi, 2015-09-23 at 17:08 -0600, Charles R Harris wrote:
> 
> 
> On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant 
> wrote:
> 
> 
> Regarding the seed council, I just tried to pick an
> objective
> criterion and an arbitrary date that seemed generally
> in keeping with
> idea of "should be active in the last
> 1-to-2-years-ish". Fiddling with
> the exact date in particular makes very little
> difference -- between
> pushing it back to 2 years ago today or forward to 1
> year ago today,
> the only thing that changes is whether Pauli makes the
> list or not.
> (And Pauli is obviously a great council candidate,
> though I don't know
> whether he even wants to be on it.)
> 
> > Personally, I have no idea how big the council
> should be. Too big, and
> > there is no point, consensus is harder to reach the
> larger the group,
> > and the main (only?) role of the council is to
> resolve issues where
> > consensus has not been reached in the larger
> community. But what is
> > too big?
> 
> 
> > As for make-up of the council, I think we need to
> expand beyond people
> > who have recently contributed core code.
> >
> > Yes, the council does need to have expertise to make
> technical
> > decisions, but if you think about the likely
> contentious issues like
> > ABI breakage, a core-code focused view is
> incomplete. So there should
> > be representation by:
> >
> > Someone(s) with a long history of working with the
> code -- that
> > institutional memory of why decisions were made the
> way they were
> > could be key.
> 
> Sure -- though I can't really imagine any way of
> framing a rule like
> this that *wouldn't* be satisfied by Chuck + Ralf +
> Pauli, so my guess
> is that such a rule would not actually have any effect
> on the council
> membership in practice.
> 
> 
> As the original author of NumPy, I would like to be on the
> seed council as long as it is larger than 7 people.That is
> my proposal.I don't need to be a permanent member, but I
> do believe I have enough history that I can understand issues
> even if I haven't been working on code directly.   
> 
> 
> I think I do bring history and information that provides all
> of the history that could be helpful on occasion. In
> addition, if a matter is important enough to even be brought
> to the attention of this council, I would like to be involved
> in the discussion about it. 
> 
> 
> 
> It's a simple change to the text --- basically an explanation
> that Travis requested to be on the seed council.  
> 

> I too would like you to be a member. We could either write it into the
> text in recognition of your status as the Numpy creator, or it could
> be the first order of business. I would only ask that you give
> yourself some time to become familiar with how things work and the
> people involved in the current community. It has been some years since
> you have been active in code development.
> 

I think I can agree with that. On a serious note, I now realize that I
am probably the one with the most objection, so for everyone, do not
bother with trying to convince me, you probably cannot fully, nor do you
have to, I will let it stand as is after this and let others take over
from here (after this, probably whatever Chuck says is good). [1]

More to the point of the actual members:

So to say, I feel the council members have to try to be *directly*
active and see being active as a necessary *commitment* (i.e. also try
to travel to meetings). This will always be a difficult judgment of
course, but there is no help to it. The current definitions imply this.
And two years seems fine. It is not that short, at least unless someone
stops contributing very abruptly which I do not think is that usual. I
will weight in to keep the current times but do not feel very strongly.

About using the commit log to seed, I think there are some old term
contributers (David Cournapeau maybe?), who never stopped doing quite a
bit but may not have merge commits. Howev

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Daπid]

On 24 September 2015 at 09:17, Jens Jørgen Mortensen 
wrote:

>
> >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> 84.0
> >>> np.__version__
> '1.10.0rc1'
>
> The result should be 42.  This is on Ubuntu 15.04.


I can reproduce on Fedora with Numpy linked against Openblas. Numpy 1.9 in
the same configuration works. The full test suite raises one error,  but
only due to lack of space when saving a large array.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Stefan van der Walt]

On 2015-09-24 00:17:33, Jens Jørgen Mortensen  wrote:
> jensj@jordan:~$ python
> Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> [GCC 4.9.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import numpy as np
>  >>> a = np.zeros((2, 2, 2))
>  >>> b = np.zeros((2, 2, 2))
>  >>> a[0, 0] = 7
>  >>> b[0, 0] = 6
>  >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> 84.0
>  >>> np.__version__
> '1.10.0rc1'
>
> The result should be 42.  This is on Ubuntu 15.04.

The input is not supposed to be matrices—but the docstring specifically
states that those should then be ravelled, so this is indeed a bug.

If I bisected correctly, the problematic change is this one:


commit 44877b36870ec2a0505c536a30b9fbf06a414c17
Author: Sebastian Berg 
Date:   Wed Sep 3 18:33:06 2014 +0200

ENH: Allow ravel to reshape in place when possible

This fixes a lot of corner cases in reshape 'K' when the array
is not contiguous in the first place, it was previously never
ravelled in place.

Closes gh-5033


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

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Sebastian Berg]

On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote:
> On 2015-09-24 00:17:33, Jens Jørgen Mortensen  wrote:
> > jensj@jordan:~$ python
> > Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> > [GCC 4.9.2] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >  >>> import numpy as np
> >  >>> a = np.zeros((2, 2, 2))
> >  >>> b = np.zeros((2, 2, 2))
> >  >>> a[0, 0] = 7
> >  >>> b[0, 0] = 6
> >  >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> > 84.0
> >  >>> np.__version__
> > '1.10.0rc1'
> >
> > The result should be 42.  This is on Ubuntu 15.04.
> 
> The input is not supposed to be matrices—but the docstring specifically
> states that those should then be ravelled, so this is indeed a bug.
> 
> If I bisected correctly, the problematic change is this one:
> 

Yeah, vdot uses `ravel`. That is correct, but it should only use it
after making sure the input is C-order, or make sure the output of ravel
is C-order (vdot was changed too in the mean time).

So the fix will be adding the contiguity check in vdot.

- Sebastian

> 
> commit 44877b36870ec2a0505c536a30b9fbf06a414c17
> Author: Sebastian Berg 
> Date:   Wed Sep 3 18:33:06 2014 +0200
> 
> ENH: Allow ravel to reshape in place when possible
> 
> This fixes a lot of corner cases in reshape 'K' when the array
> is not contiguous in the first place, it was previously never
> ravelled in place.
> 
> Closes gh-5033
> 
> 
> Stéfan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Sebastian Berg]

On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote:
> On 2015-09-24 00:17:33, Jens Jørgen Mortensen  wrote:
> > jensj@jordan:~$ python
> > Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> > [GCC 4.9.2] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >  >>> import numpy as np
> >  >>> a = np.zeros((2, 2, 2))
> >  >>> b = np.zeros((2, 2, 2))
> >  >>> a[0, 0] = 7
> >  >>> b[0, 0] = 6
> >  >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> > 84.0
> >  >>> np.__version__
> > '1.10.0rc1'
> >
> > The result should be 42.  This is on Ubuntu 15.04.
> 
> The input is not supposed to be matrices—but the docstring specifically
> states that those should then be ravelled, so this is indeed a bug.
> 
> If I bisected correctly, the problematic change is this one:
> 

Hmmm, unless we want to make sure that the output of ravel is always
contiguous (which would be a difference from `.reshape(-1)`.
It would be a bit safer, and not a useless feature maybe, since we can
point to `.reshape(-1)` as well for those who do not care.

As far as I can see a contiguous output was not guaranteed for
"keeporder", but nobody probably ever used keeporder

- Sebastian


> 
> commit 44877b36870ec2a0505c536a30b9fbf06a414c17
> Author: Sebastian Berg 
> Date:   Wed Sep 3 18:33:06 2014 +0200
> 
> ENH: Allow ravel to reshape in place when possible
> 
> This fixes a lot of corner cases in reshape 'K' when the array
> is not contiguous in the first place, it was previously never
> ravelled in place.
> 
> Closes gh-5033
> 
> 
> Stéfan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

Hello.

Can you give an example where GOTO is useful ?
Le 24 sept. 2015 07:24, "Charles R Harris"  a
écrit :

> At last, goto for python !
>
> Usage:
>
> from goto import with_goto
>
> @with_goto
> def range(start, stop):
> i = start
> result = []
>
> label .begin
> if i == stop:
> goto .end
>
> result.append(i)
> i += 1
> goto .begin
>
> label .end
> return result
>
>
> HT: LWN
>
> 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] ANN: Numpy 1.10.0rc1 released.

[Sebastian Berg]

On Do, 2015-09-24 at 13:14 +0200, Sebastian Berg wrote:
> On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote:
> > On 2015-09-24 00:17:33, Jens Jørgen Mortensen  wrote:
> > > jensj@jordan:~$ python
> > > Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> > > [GCC 4.9.2] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > >  >>> import numpy as np
> > >  >>> a = np.zeros((2, 2, 2))
> > >  >>> b = np.zeros((2, 2, 2))
> > >  >>> a[0, 0] = 7
> > >  >>> b[0, 0] = 6
> > >  >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> > > 84.0
> > >  >>> np.__version__
> > > '1.10.0rc1'
> > >
> > > The result should be 42.  This is on Ubuntu 15.04.
> > 
> > The input is not supposed to be matrices—but the docstring specifically
> > states that those should then be ravelled, so this is indeed a bug.
> > 
> > If I bisected correctly, the problematic change is this one:
> > 
> 
> Hmmm, unless we want to make sure that the output of ravel is always
> contiguous (which would be a difference from `.reshape(-1)`.
> It would be a bit safer, and not a useless feature maybe, since we can
> point to `.reshape(-1)` as well for those who do not care.
> 

So to say, I am not quite sure yet. But if anyone is even a tiny bit
nervous about doing less copying/not guaranteeing a contiguous result,
lets change the definition of ravel to return a contiguous array always
(and document it pointing people to reshape if they have no need for
it).


> As far as I can see a contiguous output was not guaranteed for
> "keeporder", but nobody probably ever used keeporder
> 
> - Sebastian
> 
> 
> > 
> > commit 44877b36870ec2a0505c536a30b9fbf06a414c17
> > Author: Sebastian Berg 
> > Date:   Wed Sep 3 18:33:06 2014 +0200
> > 
> > ENH: Allow ravel to reshape in place when possible
> > 
> > This fixes a lot of corner cases in reshape 'K' when the array
> > is not contiguous in the first place, it was previously never
> > ravelled in place.
> > 
> > Closes gh-5033
> > 
> > 
> > Stéfan
> > ___
> > 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



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] interpretation of the draft governance document (was Re: Governance model request)

[Sebastian Berg]

On Do, 2015-09-24 at 10:45 +0200, Sebastian Berg wrote:
> On Do, 2015-09-24 at 00:22 -0700, Nathaniel Smith wrote:
> > On Wed, Sep 23, 2015 at 3:12 PM, Travis Oliphant  
> > wrote:
> > >>
> > >> Here is a list of the current Contributors to the main NumPy repository:
> 
> > >>
> > >> To become eligible to join the Steering Council, an individual must be a
> > >> Project Contributor who has produced contributions that are substantial 
> > >> in
> > >> quality and quantity, and sustained over at least one year. Potential
> > >> Council Members are nominated by existing Council members and voted upon 
> > >> by
> > >> the existing Council after asking if the potential Member is interested 
> > >> and
> > >> willing to serve in that capacity. The Council will be initially formed 
> > >> from
> > >> the set of existing Core Developers who, as of late 2015, have been
> > >> significantly active over the last year.
> > >>
> > >
> > > Concretely, I'm asking to be included in this initial council so a simple
> > > "along with Travis Oliphant who is the original author of NumPy".   If 
> > > other
> > > long-time contributors to the code-base also want to be on this initial 
> > > seed
> > > council, I think it would make sense as well.
> > 
> > I'll leave this discussion for the other thread that's specifically
> > about the council membership, so as not to confuse matters.
> 
> Well, I think we can at least learn one thing from this directly. I
> think we should include some relation to historic contributions into the
> document. I think what might be nice to do would be for example to also
> "seed" the emeritus list (if it is not too difficult).
> It is somewhat unrelated to governance, but since we want it to be a
> prominent document, it should not overshadow the past.
> 

Heh, sorry, I see this was already pretty much the case. Could maybe be
extended a bit, but missed that


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



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] "Become an Open Source Contributor" workshop

[Scott Collis]

Hey Jamie, List,
Having just come back from a conference where our toolkit, Py-ART [1] 
has picked up a nice following of people keen to contribute I was 
wondering if you will be opening this up via a google hangout or similar?


I would love to advertise this to our users. We all want more 
contributors and a big roadblock is understanding the fork and pull 
request system of GitHub


We did run a course that had some GitGub etc here: 
https://github.com/scollis/SusSoPrac You are welcome to use anything 
liberally!


Cheers,
Scott


On 9/23/15 4:39 PM, numpy-discussion-requ...@scipy.org wrote:

Send NumPy-Discussion mailing list submissions to
numpy-discussion@scipy.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.scipy.org/mailman/listinfo/numpy-discussion
or, via email, send a message with subject or body 'help' to
numpy-discussion-requ...@scipy.org

You can reach the person managing the list at
numpy-discussion-ow...@scipy.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NumPy-Discussion digest..."


Today's Topics:

1. "Become an Open Source Contributor" workshop
   (Jaime Fern?ndez del R?o)
2. Re: composition of the steering council (was Re: Governance
   model request) (Travis Oliphant)
3. Re: Governance model request (Stefan van der Walt)
4. Re: Governance model request (Matthew Brett)
5. Re: composition of the steering council (was Re: Governance
   model request) (Chris Barker)


--

Message: 1
Date: Wed, 23 Sep 2015 14:06:08 -0700
From: Jaime Fern?ndez del R?o 
To: SciPy Developers List ,  Discussion of
Numerical Python 
Subject: [Numpy-discussion] "Become an Open Source Contributor"
workshop
Message-ID:

Content-Type: text/plain; charset="utf-8"

Apologies for the cross-posting.

The Data Science Student Society of the University of California San Diego,
or DS3 @ UCSD as they like to call themselves, will be holding biweekly
Python themed workshops starting this fall.  On the week of October 19th,
they will be having yours truly doing a "Become an Open Source Contributor"
piece.  It will be a shortish event, 60-90 minutes, so my idea was to cover
the following:

1. (15 min) An introduction to the Python data science landscape.
2. (30 min) An overview of the GitHub workflow that most (all?) of the
projects follow.
3. (30-45 min) A hands on session, where we would make sure everyone
gets set up in GitHub, and forks and clones their favorite project.  Time
and participant willingness permitting, I would like to take advantage of
my commit bits, and have some of the participants submit a simple PR, e.g.
fixing a documentation typo, to NumPy or SciPy, and hit the green button
right there, so that they get to leave as knighted FOSS contributors.

And this is what I am hoping to get from you, the community:

1. If anyone in the area would like to get involved, please contact me.
I have recruited a couple of volunteers from PySanDiego, but could use more
help.
2. I'm also hoping to get some help, especially with the introductory
part.  Given that the crowd will mostly be university students and some
faculty, it would be great if someone who actually knew what they were
talking about could deliver a short, 10 minute talk, on Python, data
science, and academia.  I'm sure we could arrange it to have someone join
by video conference.
3. If you have organized anything similar in the past, and have material
that I could use to, ahem, draw inspiration from, or recommendations to
make, or whatever, I'd love to hear from you.

Thanks for reading!

Jaime



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

Re: [Numpy-discussion] Python needs goto

[R Schumacher]

An older non-decorator implementation, with examples (slower)
http://entrian.com/goto/


At 04:25 AM 9/24/2015, you wrote:


Hello.

Can you give an example where GOTO is useful ?
Le 24 sept. 2015 07:24, "Charles R Harris" 
<charlesr.har...@gmail.com> a écrit :

At last, goto for python!

Usage:
from goto import with_goto


@with_goto

def range(start, stop):

i = start

result = []


label .begin

if i == stop:

goto .end


result.append(i)

i += 1

goto .begin


label .end

return result

HT: LWN

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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Nathaniel Smith]

On Sep 24, 2015 4:14 AM, "Sebastian Berg" 
wrote:
>
> On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote:
> > On 2015-09-24 00:17:33, Jens Jørgen Mortensen 
wrote:
> > > jensj@jordan:~$ python
> > > Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> > > [GCC 4.9.2] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > >  >>> import numpy as np
> > >  >>> a = np.zeros((2, 2, 2))
> > >  >>> b = np.zeros((2, 2, 2))
> > >  >>> a[0, 0] = 7
> > >  >>> b[0, 0] = 6
> > >  >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> > > 84.0
> > >  >>> np.__version__
> > > '1.10.0rc1'
> > >
> > > The result should be 42.  This is on Ubuntu 15.04.
> >
> > The input is not supposed to be matrices—but the docstring specifically
> > states that those should then be ravelled, so this is indeed a bug.
> >
> > If I bisected correctly, the problematic change is this one:
> >
>
> Hmmm, unless we want to make sure that the output of ravel is always
> contiguous (which would be a difference from `.reshape(-1)`.
> It would be a bit safer, and not a useless feature maybe, since we can
> point to `.reshape(-1)` as well for those who do not care.
>
> As far as I can see a contiguous output was not guaranteed for
> "keeporder", but nobody probably ever used keeporder

I don't understand what these have to do with each other. If vdot is going
to ravel then yes, it certainly needs to control the order of the raveling.
(And there are lots of functions like this that implicitly ravel in numpy,
for better or worse... Do we need to audit any others?) But this is
"virtual" order that matters, right, nothing to do with storage order?

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

Re: [Numpy-discussion] ANN: Numpy 1.10.0rc1 released.

[Sebastian Berg]

On Do, 2015-09-24 at 10:03 -0700, Nathaniel Smith wrote:
> On Sep 24, 2015 4:14 AM, "Sebastian Berg" 
> wrote:
> >
> > On Do, 2015-09-24 at 03:26 -0700, Stefan van der Walt wrote:
> > > On 2015-09-24 00:17:33, Jens Jørgen Mortensen 
> wrote:
> > > > jensj@jordan:~$ python
> > > > Python 2.7.9 (default, Apr  2 2015, 15:33:21)
> > > > [GCC 4.9.2] on linux2
> > > > Type "help", "copyright", "credits" or "license" for more
> information.
> > > >  >>> import numpy as np
> > > >  >>> a = np.zeros((2, 2, 2))
> > > >  >>> b = np.zeros((2, 2, 2))
> > > >  >>> a[0, 0] = 7
> > > >  >>> b[0, 0] = 6
> > > >  >>> np.vdot(a[:, :, 0], b[:, :, 0]).real
> > > > 84.0
> > > >  >>> np.__version__
> > > > '1.10.0rc1'
> > > >
> > > > The result should be 42.  This is on Ubuntu 15.04.
> > >
> > > The input is not supposed to be matrices—but the docstring
> specifically
> > > states that those should then be ravelled, so this is indeed a
> bug.
> > >
> > > If I bisected correctly, the problematic change is this one:
> > >
> >
> > Hmmm, unless we want to make sure that the output of ravel is always
> > contiguous (which would be a difference from `.reshape(-1)`.
> > It would be a bit safer, and not a useless feature maybe, since we
> can
> > point to `.reshape(-1)` as well for those who do not care.
> >
> > As far as I can see a contiguous output was not guaranteed for
> > "keeporder", but nobody probably ever used keeporder
> 
> I don't understand what these have to do with each other. If vdot is
> going to ravel then yes, it certainly needs to control the order of
> the raveling. (And there are lots of functions like this that
> implicitly ravel in numpy, for better or worse... Do we need to audit
> any others?) But this is "virtual" order that matters, right, nothing
> to do with storage order?
> 

No, this change also potentially changed the contiguity of the output,
which does matter to vdot.
`.reshape(-1)` will be a view for arrays such as `np.zeros((4, 4,
4)[..., 0]`. However, before, `ravel` would always return a *contiguous*
chunk of memory (except for "keeporder"), so for the above case a copy
would be forced.

I think I underestimated the potential risk at the time, while I always
thought of `ravel` to create a view whenever possible (and the
documentation reads like it does), it never did and probably we should
be careful to avoid possible problems for C-interfacing code.

Asking everyone to use `reshape(-1)` instead if they want to have views
whenever possible, is maybe not as pretty sometimes, but safe.
I doubt "keeporder" should be special though, so I think I would also
add forcing of a copy there.

- Sebastian


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



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

[David Cournapeau]

On Thu, Sep 24, 2015 at 10:45 AM, Sebastian Berg  wrote:

> On Mi, 2015-09-23 at 17:08 -0600, Charles R Harris wrote:
> >
> >
> > On Wed, Sep 23, 2015 at 3:21 PM, Travis Oliphant 
> > wrote:
> >
> >
> > Regarding the seed council, I just tried to pick an
> > objective
> > criterion and an arbitrary date that seemed generally
> > in keeping with
> > idea of "should be active in the last
> > 1-to-2-years-ish". Fiddling with
> > the exact date in particular makes very little
> > difference -- between
> > pushing it back to 2 years ago today or forward to 1
> > year ago today,
> > the only thing that changes is whether Pauli makes the
> > list or not.
> > (And Pauli is obviously a great council candidate,
> > though I don't know
> > whether he even wants to be on it.)
> >
> > > Personally, I have no idea how big the council
> > should be. Too big, and
> > > there is no point, consensus is harder to reach the
> > larger the group,
> > > and the main (only?) role of the council is to
> > resolve issues where
> > > consensus has not been reached in the larger
> > community. But what is
> > > too big?
> >
> >
> > > As for make-up of the council, I think we need to
> > expand beyond people
> > > who have recently contributed core code.
> > >
> > > Yes, the council does need to have expertise to make
> > technical
> > > decisions, but if you think about the likely
> > contentious issues like
> > > ABI breakage, a core-code focused view is
> > incomplete. So there should
> > > be representation by:
> > >
> > > Someone(s) with a long history of working with the
> > code -- that
> > > institutional memory of why decisions were made the
> > way they were
> > > could be key.
> >
> > Sure -- though I can't really imagine any way of
> > framing a rule like
> > this that *wouldn't* be satisfied by Chuck + Ralf +
> > Pauli, so my guess
> > is that such a rule would not actually have any effect
> > on the council
> > membership in practice.
> >
> >
> > As the original author of NumPy, I would like to be on the
> > seed council as long as it is larger than 7 people.That is
> > my proposal.I don't need to be a permanent member, but I
> > do believe I have enough history that I can understand issues
> > even if I haven't been working on code directly.
> >
> >
> > I think I do bring history and information that provides all
> > of the history that could be helpful on occasion. In
> > addition, if a matter is important enough to even be brought
> > to the attention of this council, I would like to be involved
> > in the discussion about it.
> >
> >
> >
> > It's a simple change to the text --- basically an explanation
> > that Travis requested to be on the seed council.
> >
>
> > I too would like you to be a member. We could either write it into the
> > text in recognition of your status as the Numpy creator, or it could
> > be the first order of business. I would only ask that you give
> > yourself some time to become familiar with how things work and the
> > people involved in the current community. It has been some years since
> > you have been active in code development.
> >
>
> I think I can agree with that. On a serious note, I now realize that I
> am probably the one with the most objection, so for everyone, do not
> bother with trying to convince me, you probably cannot fully, nor do you
> have to, I will let it stand as is after this and let others take over
> from here (after this, probably whatever Chuck says is good). [1]
>
> More to the point of the actual members:
>
> So to say, I feel the council members have to try to be *directly*
> active and see being active as a necessary *commitment* (i.e. also try
> to travel to meetings). This will always be a difficult judgment of
> course, but there is no help to it. The current definitions imply this.
> And two years seems fine. It is not that short, at least unless someone
> stops contributing very abruptly which I do not think is that usual. I
> will weight in to keep the current times but do not feel very strongly.
>
> About using the commit log to seed, I think there are some old term
> contributers (David Cou

Re: [Numpy-discussion] Python needs goto

[Alexander Eberspächer]

On 24.09.2015 13:25, Christophe Bal wrote:

> Can you give an example where GOTO is useful ?

I think those pieces of code are best understood with some humour..

However, basically I can think two main causes for using goto:

1. Stop whatever your code is doing and jump towards the end of the
program. However, this is mainly something useful for languages without
exception handling and garbage collection.

2. Get out of something deeply nested. Also, this probably isn't very
useful in Python as there's exception handling.

Best

Alex




signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Yarko Tymciurak]

On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
alex.eberspaec...@gmail.com> wrote:

> On 24.09.2015 13:25, Christophe Bal wrote:
>
> > Can you give an example where GOTO is useful ?
>
> I think those pieces of code are best understood with some humour..
>
> However, basically I can think two main causes for using goto:
>
> 1. Stop whatever your code is doing and jump towards the end of the
> program. However, this is mainly something useful for languages without
> exception handling and garbage collection.
>
> 2. Get out of something deeply nested. Also, this probably isn't very
> useful in Python as there's exception handling.
>

I think there are more valid uses - I've read that "goto" basically is what
a state machine does.
Have a read of the brief implementation notes for "goto" in golang, for
example.  Goto may not be unreasonable to use, just most people would
abuse.  Sort of like "everyone shouldn't write assembly, but if you
understand the machine, you can make good things happen".  Without
compiler/interpreter checks, more responsibility rests on the coder to keep
out of trouble.



>
> Best
>
> Alex
>
>
>
> ___
> 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] Python needs goto

[Jason Newton]

In my experience, it's also come up with finite-state-machines where
there's lots of loops.  You might consider something like a long-lived
client-loop on some socket, where states like try-connect, connected, and
while-connected-and-everythings-ok exist and each can have it's own never
ending loops and each loop jumps to each others section.  It actually is
more straightforward than adding unneeded layers like callbacks which will
force you to design and pass around data, use auxiliary classes/structs,
and it's easier to shoot yourself in the foot with burden and context loss
that way.

-Jason

On Thu, Sep 24, 2015 at 1:54 PM, Alexander Eberspächer <
alex.eberspaec...@gmail.com> wrote:

> On 24.09.2015 13:25, Christophe Bal wrote:
>
> > Can you give an example where GOTO is useful ?
>
> I think those pieces of code are best understood with some humour..
>
> However, basically I can think two main causes for using goto:
>
> 1. Stop whatever your code is doing and jump towards the end of the
> program. However, this is mainly something useful for languages without
> exception handling and garbage collection.
>
> 2. Get out of something deeply nested. Also, this probably isn't very
> useful in Python as there's exception handling.
>
> Best
>
> Alex
>
>
>
> ___
> 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] Python needs goto

[Charles R Harris]

On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak  wrote:

>
>
> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
> alex.eberspaec...@gmail.com> wrote:
>
>> On 24.09.2015 13:25, Christophe Bal wrote:
>>
>> > Can you give an example where GOTO is useful ?
>>
>> I think those pieces of code are best understood with some humour..
>>
>> However, basically I can think two main causes for using goto:
>>
>> 1. Stop whatever your code is doing and jump towards the end of the
>> program. However, this is mainly something useful for languages without
>> exception handling and garbage collection.
>>
>> 2. Get out of something deeply nested. Also, this probably isn't very
>> useful in Python as there's exception handling.
>>
>
> I think there are more valid uses - I've read that "goto" basically is
> what a state machine does.
> Have a read of the brief implementation notes for "goto" in golang, for
> example.  Goto may not be unreasonable to use, just most people would
> abuse.  Sort of like "everyone shouldn't write assembly, but if you
> understand the machine, you can make good things happen".  Without
> compiler/interpreter checks, more responsibility rests on the coder to keep
> out of trouble.
>

I would agree about state machines. When implemented using the standard
control flow constructs they always look a bit artificial.

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

Re: [Numpy-discussion] Python needs goto

[Benjamin Root]

Most of the time when I wanted to use goto in my early days, I found that
breaks and continues were better and easier to understand. I will admit
that there are occasional nested if/elif/else code that get messy without a
goto. But which smells worse? A "goto" package or a complex if/elif/else?

Ben Root

On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris  wrote:

>
>
> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>> alex.eberspaec...@gmail.com> wrote:
>>
>>> On 24.09.2015 13:25, Christophe Bal wrote:
>>>
>>> > Can you give an example where GOTO is useful ?
>>>
>>> I think those pieces of code are best understood with some humour..
>>>
>>> However, basically I can think two main causes for using goto:
>>>
>>> 1. Stop whatever your code is doing and jump towards the end of the
>>> program. However, this is mainly something useful for languages without
>>> exception handling and garbage collection.
>>>
>>> 2. Get out of something deeply nested. Also, this probably isn't very
>>> useful in Python as there's exception handling.
>>>
>>
>> I think there are more valid uses - I've read that "goto" basically is
>> what a state machine does.
>> Have a read of the brief implementation notes for "goto" in golang, for
>> example.  Goto may not be unreasonable to use, just most people would
>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>> understand the machine, you can make good things happen".  Without
>> compiler/interpreter checks, more responsibility rests on the coder to keep
>> out of trouble.
>>
>
> I would agree about state machines. When implemented using the standard
> control flow constructs they always look a bit artificial.
>
> 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] Python needs goto

[Christophe Bal]

To be honest, I am not very conviced. Does someone can give a pseudo
example ?
Le 24 sept. 2015 20:50, "Benjamin Root"  a écrit :

> Most of the time when I wanted to use goto in my early days, I found that
> breaks and continues were better and easier to understand. I will admit
> that there are occasional nested if/elif/else code that get messy without a
> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>
> Ben Root
>
> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
>>> alex.eberspaec...@gmail.com> wrote:
>>>
 On 24.09.2015 13:25, Christophe Bal wrote:

 > Can you give an example where GOTO is useful ?

 I think those pieces of code are best understood with some humour..

 However, basically I can think two main causes for using goto:

 1. Stop whatever your code is doing and jump towards the end of the
 program. However, this is mainly something useful for languages without
 exception handling and garbage collection.

 2. Get out of something deeply nested. Also, this probably isn't very
 useful in Python as there's exception handling.

>>>
>>> I think there are more valid uses - I've read that "goto" basically is
>>> what a state machine does.
>>> Have a read of the brief implementation notes for "goto" in golang, for
>>> example.  Goto may not be unreasonable to use, just most people would
>>> abuse.  Sort of like "everyone shouldn't write assembly, but if you
>>> understand the machine, you can make good things happen".  Without
>>> compiler/interpreter checks, more responsibility rests on the coder to keep
>>> out of trouble.
>>>
>>
>> I would agree about state machines. When implemented using the standard
>> control flow constructs they always look a bit artificial.
>>
>> 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
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Christophe Bal]

By pseudo example, I mean pseudo code.
Le 24 sept. 2015 20:56, "Christophe Bal"  a écrit :

> To be honest, I am not very conviced. Does someone can give a pseudo
> example ?
> Le 24 sept. 2015 20:50, "Benjamin Root"  a écrit :
>
>> Most of the time when I wanted to use goto in my early days, I found that
>> breaks and continues were better and easier to understand. I will admit
>> that there are occasional nested if/elif/else code that get messy without a
>> goto. But which smells worse? A "goto" package or a complex if/elif/else?
>>
>> Ben Root
>>
>> On Thu, Sep 24, 2015 at 2:41 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 12:13 PM, Yarko Tymciurak 
>>> wrote:
>>>


 On Thu, Sep 24, 2015 at 12:54 PM, Alexander Eberspächer <
 alex.eberspaec...@gmail.com> wrote:

> On 24.09.2015 13:25, Christophe Bal wrote:
>
> > Can you give an example where GOTO is useful ?
>
> I think those pieces of code are best understood with some humour..
>
> However, basically I can think two main causes for using goto:
>
> 1. Stop whatever your code is doing and jump towards the end of the
> program. However, this is mainly something useful for languages without
> exception handling and garbage collection.
>
> 2. Get out of something deeply nested. Also, this probably isn't very
> useful in Python as there's exception handling.
>

 I think there are more valid uses - I've read that "goto" basically is
 what a state machine does.
 Have a read of the brief implementation notes for "goto" in golang, for
 example.  Goto may not be unreasonable to use, just most people would
 abuse.  Sort of like "everyone shouldn't write assembly, but if you
 understand the machine, you can make good things happen".  Without
 compiler/interpreter checks, more responsibility rests on the coder to keep
 out of trouble.

>>>
>>> I would agree about state machines. When implemented using the standard
>>> control flow constructs they always look a bit artificial.
>>>
>>> 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
>>
>>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Charles R Harris]

On Thu, Sep 24, 2015 at 12:57 PM, Christophe Bal 
wrote:

> By pseudo example, I mean pseudo code.
>

I find Cleve Moler's old Fortran version of Brent's zero finding algorithm
using gotos clearer than the structured versions you can find in Numerical
Recipes. The operation of the algorithm is easiest to describe as a finite
state machine. As others have said, goto is also useful for languages
without exception handling, C for instance. You will find gotos in the
Linux kernel and in the Numpy core used for that purpose.

However, the post was for laughs, I didn't expect serious discussion. The
current thread is a pleasant surprise.

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

Re: [Numpy-discussion] composition of the steering council (was Re: Governance model request)

[Travis Oliphant]

>
>
>
> [1] Sorry to "footnote" this, but I think I am probably rudely repeating
> myself and frankly do **not want this to be discussed**. It is just to
> try to be fully clear where I come from:
> Until SciPy 2015, I could list many people on this list who have shown
> more direct involvement in numpy then Travis since I joined and have no
> affiliation to numpy. If Travis had been new to the community at the
> time, I would be surprised if I would even recognize his name.
> I know this is only half the picture and Travis already mentioned
> another side, but this is what I mostly saw even if it may be a harsh
> and rude assessment.
>
>
I do understand this.   That's actually why I'm speaking up, because I
don't think my activity has been understood by many people who have joined
this list only recently.   I don't want to interfere with your activity or
impede your progress, or to be asked permission for anything.   In fact, I
want to understand how to best use my limited time to support things.

You in particular are interested in indexing and fixing it --- the current
code is there for a reason and some of the issues being discussed today
have been discussed before --- though we have the benefit of hindsight now.


I have mostly been behind the scenes helping people since about 2010 ---
but still thinking a lot about NumPy, the downstream community, integration
with other libraries, and where things could go. I don't have the time
to commit major code changes, but I do have the time to contribute
perspective and even a design idea or two from time to time.Obviously,
nobody has to listen.

I understand and appreciate that there are a lot of people that have
contributed code and discussion since 2009 and to them it probably seems
I'm just popping in and out --- and if you only look at the contributor log
you can wonder "who is this guy...". But, I did do *a lot* of work to
get NumPy off the ground.   Quite a bit of that work was very lonely with
people interested in the merger but pretty skeptical until the work was
nearly done (and then many people helped finish it and get it working and
tested). I wish I had been a better architect at the time (I can see
now many things that would have been done differently).But, I'm still
proud of the work I did in creating a foundation many could build on --- at
the time nobody else was stepping up to do the job.

Since that time, I have remained very interested in the success of NumPy
and supporting the many *users* of NumPy. What I most bring to the
current community is having observed many, many uses of NumPy in the wild
--- from people who would never post to this list and whose use-cases are
absent from discussion or misunderstood.  I also bring knowledge about
the wider Python ecosystem and the broader world outside of NumPy alone.
The group is free to take my ideas and/or contributions or leave them.
 And I am also free to just review pull requests and contribute if and when
I might.

Best,

-Travis








>
> >
> > 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
>
>


-- 

*Travis Oliphant*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Python needs goto

[Alexander Eberspächer]

On 24.09.2015 21:12, Charles R Harris wrote:

> I find Cleve Moler's old Fortran version of Brent's zero finding
> algorithm using gotos clearer than the structured versions you can find
> in Numerical Recipes. The operation of the algorithm is easiest to
> describe as a finite state machine.

I need to look into that piece of Fortran code. I've never (knowingly)
implemented a state-machine myself. However I can say that specifically
Fortran has named loops, which probably helps to avoid many uses of goto.

> However, the post was for laughs, I didn't expect serious discussion.

Well, then let me fill in the missing piece - the obligatory XKCD strip:

https://www.xkcd.com/292/

Alex







signature.asc
Description: OpenPGP digital signature
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion