Completely in support of fixed bit width types. Just thinking that it shouldn't be done by using a list.
Not sure how the two are orthogonal. What am I missing? On Tue, Jul 12, 2016 at 5:38 PM, Wes McKinney <wesmck...@gmail.com> wrote: > I think it would be good to revisit that discussion. This is somewhat > orthogonal -- i.e. having a fixed-width binary type that does not have > an accompanying list of n + 1 offsets. > > On Tue, Jul 12, 2016 at 5:36 PM, Jacques Nadeau <jacq...@apache.org> > wrote: > > I was further reflecting on the previous discussion on lists and > > binary/utf8. I think that treating strings (binary or utf8) as lists is > too > > much of reduction. This seems like a good example of how they are treated > > differently (beyond the previously discussed not-possible-nullability). > As > > such I'm -1 on this change and would prefer if we go back and further > > review the concept of treating a string of bits, or bytes as a > "primitive" > > type. > > > > On Tue, Jul 12, 2016 at 5:19 PM, Wes McKinney <wesmck...@gmail.com> > wrote: > > > >> I'm +1 on this. I've seen fixed-width strings and other things in many > >> different contexts. I would say that fixed-width binary is probably > >> the primary use case, but you could imaging casting int96 data to > >> fixed_list<3, int32> > >> > >> On Mon, Jul 11, 2016 at 11:24 PM, Micah Kornfield < > emkornfi...@gmail.com> > >> wrote: > >> > This came up in a code review a while ago, but what do people think of > >> > adding a fixed width list type to the memory layout spec. > >> > > >> > This would have the same layout as the current list type. Instead of > >> > having a separate offset buffer to determine location and length of > >> > each list, the length would be stored as part of metadata and offsets > >> > would be calculated using multiplication instead of lookups. > >> > > >> > One use case for this is an easy mapping to the "FIXED_LEN_BYTE_ARRAY" > >> > in parquet. > >> > > >> > If people like the idea I can file a JIRA and update the current > >> layout.md. > >> > > >> > Thanks, > >> > -Micah > >> >
