<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 5, 2013 at 1:45 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Thu, Sep 5, 2013 at 1:34 PM, Bradley M. Froehle <span dir="ltr"><<a href="mailto:brad.froehle@gmail.com" target="_blank">brad.froehle@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I put this test case through `git bisect run` and here's what came<br>
back.  I haven't confirmed this manually yet, but the blamed commit<br>
does seem reasonable:<br>
<br>
b26c675e2a91e1042f8f8d634763942c87fbbb6e is the first bad commit<br>
commit b26c675e2a91e1042f8f8d634763942c87fbbb6e<br>
Author: Nathaniel J. Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>><br>
Date:   Thu Jul 12 13:20:20 2012 +0100<br>
<br>
    [FIX] Make np.random.shuffle less brain-dead<br>
<br>
    The logic in np.random.shuffle was... not very sensible. Fixes trac<br>
    ticket #2074.<br>
<br>
    This patch also exposes a completely unrelated issue in<br>
    numpy.testing. Filed as Github issue #347 and marked as knownfail for<br>
    now.<br>
<br>
:040000 040000 6f3cf0c85a64664db6a71bd59909903f18b51639<br>
0b6c8571dd3c9de8f023389f6bd963e42b12cc26 M numpy<br>
bisect run success<br>
<br>
On Thu, Sep 5, 2013 at 11:58 AM, Charles R Harris<br>
<div><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Sep 5, 2013 at 12:50 PM, Fernando Perez <<a href="mailto:fperez.net@gmail.com" target="_blank">fperez.net@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Thu, Sep 5, 2013 at 11:43 AM, Charles R Harris<br>
>> <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> > Oh, nice one ;) Should be fixable if you want to submit a patch.<br>
>><br>
>> Strategy? One option is to do, for structured arrays, a shuffle of the<br>
>> indices and then an in-place<br>
>><br>
>> arr = arr[shuffled_indices]<br>
>><br>
>> But there may be a cleaner/faster way to do it.<br>
>><br>
>> I'm happy to submit a patch, but I'm not familiar enough with the<br>
>> internals to know what the best approach should be.<br>
>><br>
><br>
> Better open an issue. It looks like a bug in the indexing code.<br>
><br></div></blockquote><div><br></div></div></div><div>Also fails for string arrays.<br><br><span style="font-family:courier new,monospace">In [6]: x = np.zeros(5, dtype=[('n', 'S1'), ('s', 'S1')])<br>

<br>In [7]: x['s'] = [c for c in 'abcde']<br><br>In [8]: x<br>Out[8]: <br>array([('', 'a'), ('', 'b'), ('', 'c'), ('', 'd'), ('', 'e')], <br>

      dtype=[('n', 'S1'), ('s', 'S1')])<br><br>In [9]: x[0], x[1] = x[1], x[0]<br><br>In [10]: x<br>Out[10]: <br>array([('', 'b'), ('', 'b'), ('', 'c'), ('', 'd'), ('', 'e')], <br>

      dtype=[('n', 'S1'), ('s', 'S1')])<br></span><br></div></div></div></div></blockquote><div><br><div><div>This behavior is not new, it is also present in 1.6.x<br><br>In [1]: x = np.zeros(5, dtype=[('n', 'S1'), ('s', 'S1')])<br>
<br>In [2]: x['s'] = [c for c in 'abcde']<br><br>In [3]: x<br>Out[3]: <br>array([('', 'a'), ('', 'b'), ('', 'c'), ('', 'd'), ('', 'e')], <br>
      dtype=[('n', '|S1'), ('s', '|S1')])<br><br>In [4]: x[0], x[1] = x[1], x[0]<br><br>In [5]: x<br>Out[5]: <br>array([('', 'b'), ('', 'b'), ('', 'c'), ('', 'd'), ('', 'e')], <br>
      dtype=[('n', '|S1'), ('s', '|S1')])<br><br>In [6]: np.__version__<br>Out[6]: '1.6.3.dev-3f58621'<br><br></div>So it looks like it needs to be decided if this is a bug or not. I think the returned scalars should be copies of the data.<br>
<br></div>Chuck </div></div><br></div></div>