Skip to content

Weird behavior of structured_to_unstructured on non-trivial dtypes #13333

Closed

Description

@eric-wieser

With the following helpers:

import numpy.lib.recfunctions as rfn
def subarray(dt, shape):
    return np.dtype((dt, shape))
def structured(*dts):
    return np.dtype([('x{}'.format(i), dt) for i, dt in enumerate(dts)])
def inspect(dt):
    arr = np.zeros((), dt)
    ret = rfn.structured_to_unstructured(arr)
    print(ret.shape, ret.dtype)

We can try a bunch of uses of structured_to_unstructured (added in #11526):

>>> inspect(structured(int, int))
(2,) int32  # obviously ok
>>> inspect(structured(int, structured(int, int)))
(3,) int32  # nested types are flattened, ok
>>> inspect(structured(int, subarray(int, 2)))
(3,) int32  # ok: 1 + 2
>>> inspect(structured(int, subarray(int, (2, 2))))
(5,) int32    # ok: 1 + 2*2

Here's where things start to go bad:

>>> inspect(structured(subarray(structured(int, int), 3)))
(3,) [('x0', '<i4'), ('x1', '<i4')] # bug?
>>> inspect(structured(subarray(subarray(int, 2), 2)))
(2, 2) int32  # bug
>>> inspect(structured(int))
() int32 # bug

(#13334)

>>> inspect(structured(int, subarray(subarray(int, 2), 2)))
TypeError: invalid type promotion
>>> inspect(structured())
    dts, counts, offsets = zip(*fields)
ValueError: not enough values to unpack (expected 3, got 0)

A lot of this behavior looks undesirable to me. @ahaldane, which cases were actually intended to be supported? Rather than locking ourselve into some of these weird constucts, we might want to raise an error for anything non-trivial.

Activity

  1. added this to the milestone on Apr 15, 2019
  2. modified the milestones: , on Apr 22, 2019
  3. ahaldane commented on Apr 22, 2019

    @ahaldane
    Member

    Good catches, I don't think the "weird" cases were intended.

    Looks like you already have the fix for the one-field bug in #13332.

    For the subarray bug, there is evidently some wrong recursion code. The bug contradicts the docstring for _get_fields_and_offsets.

  4. mattip commented on May 16, 2019

    @mattip
    Member

    Can we close this? #13332 and #13334 were merged

  5. eric-wieser commented on May 16, 2019

    @eric-wieser
    MemberAuthor

    No, the other weird cases still apply

  6. modified the milestones: , 1.16.5 release on May 27, 2019
  7. charris commented on Aug 20, 2019

    @charris
    Member

    Pushed off to 1.17.2.

  8. ahaldane commented on Aug 20, 2019

    @ahaldane
    Member

    Thanks for the ping, I'd forgotten this was hanging.

    I've got a fix for the cases above, will make PR soon.

  9. added 2 commits that reference this issue on Aug 23, 2019
    4c87dd7
    66395f2
  10. added a commit that references this issue on Sep 6, 2019
    0243768
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions