Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your "scary" solution does not appear scary to me. Calling <code>shuffle()</code> for two sequences of the same length results in the same number of calls to the random number generator, and these are the only "random" elements in the shuffle algorithm. By resetting the state, you ensure that the calls to the random number generator will give the same results in the second call to <code>shuffle()</code>, so the whole algorithm will generate the same permutation.</p> <p>If you don't like this, a different solution would be to store your data in one array instead of two right from the beginning, and create two views into this single array simulating the two arrays you have now. You can use the single array for shuffling and the views for all other purposes.</p> <p>Example: Let's assume the arrays <code>a</code> and <code>b</code> look like this:</p> <pre><code>a = numpy.array([[[ 0., 1., 2.], [ 3., 4., 5.]], [[ 6., 7., 8.], [ 9., 10., 11.]], [[ 12., 13., 14.], [ 15., 16., 17.]]]) b = numpy.array([[ 0., 1.], [ 2., 3.], [ 4., 5.]]) </code></pre> <p>We can now construct a single array containing all the data:</p> <pre><code>c = numpy.c_[a.reshape(len(a), -1), b.reshape(len(b), -1)] # array([[ 0., 1., 2., 3., 4., 5., 0., 1.], # [ 6., 7., 8., 9., 10., 11., 2., 3.], # [ 12., 13., 14., 15., 16., 17., 4., 5.]]) </code></pre> <p>Now we create views simulating the original <code>a</code> and <code>b</code>:</p> <pre><code>a2 = c[:, :a.size//len(a)].reshape(a.shape) b2 = c[:, a.size//len(a):].reshape(b.shape) </code></pre> <p>The data of <code>a2</code> and <code>b2</code> is shared with <code>c</code>. To shuffle both arrays simultaneously, use <code>numpy.random.shuffle(c)</code>.</p> <p>In production code, you would of course try to avoid creating the original <code>a</code> and <code>b</code> at all and right away create <code>c</code>, <code>a2</code> and <code>b2</code>.</p> <p>This solution could be adapted to the case that <code>a</code> and <code>b</code> have different dtypes.</p>
    singulars
    1. This table or related slice is empty.
    1. POBetter way to shuffle two numpy arrays in unison
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USSven Marnach
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POBetter way to shuffle two numpy arrays in unison
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CORe: the scary solution: I just worry that arrays of different shapes could (conceivably) yield different numbers of calls to the rng, which would cause divergence. However, I think you are right that the current behavior is perhaps unlikely to change, and a very simple doctest does make confirming correct behavior very easy...
      singulars
      1. PO
      1. USJosh Bleecher Snyder
    2. COI like your suggested approach, and could definitely arrange to have a and b start life as a unified c array. However, a and b will need to be contiguous shortly after shuffling (for efficient transfer to a GPU), so I think that, in my particular case, I'd end up making copies of a and b anyway. :(
      singulars
      1. PO
      1. USJosh Bleecher Snyder
    3. CO@Josh: Note that `numpy.random.shuffle()` operates on arbitrary mutable sequences, such as Python lists or NumPy arrays. The array shape does not matter, only the length of the sequence. This is *very* unlikely to change in my opinion.
      singulars
      1. PO
      1. USSven Marnach
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload