You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Andrew Lamb (Jira)" <ji...@apache.org> on 2021/04/26 12:50:02 UTC

[jira] [Closed] (ARROW-11882) [Rust] Implement Debug printing "kernel"

     [ https://issues.apache.org/jira/browse/ARROW-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Lamb closed ARROW-11882.
-------------------------------
    Resolution: Invalid

> [Rust] Implement Debug printing "kernel"
> ----------------------------------------
>
>                 Key: ARROW-11882
>                 URL: https://issues.apache.org/jira/browse/ARROW-11882
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: Rust
>            Reporter: Andrew Lamb
>            Priority: Major
>
> [~jorgecarleitao] offered a great way to improve the Debug/Display implementations for various Array implementations on https://github.com/apache/arrow/pull/9624#issuecomment-790976766 
> The only reason we are implementing to_isize/to_usize on NativeType is because we have a function to represent an array (for Display) that accepts a generic physical type T, and then tries to convert it to a isize depending on a logical type (DataType::Date). However, there is already a Many to one relationship between logical and physical types.
> Thus, a solution for this is to have the `Debug` function branch off depending on the (logical) datatype, implementing the custom string representation depending on it, instead of having a loop of native type T and then branching off according to the DataType inside the loop.
> I.e. instead of
> {code}
> for i in ... {
>    match data_type {
>          DataType::Date32 => represent array[i] as date
>          DataType::Int32 => represent array[i] as int
>    }
> }
> {code}
> imo we should have
> {code}
> match data_type {
>      DataType::Date32 => for i in ... {represent array[i] as date}
>      DataType::Int32 => for i in ... {represent array[i] as int}
> }
> {code}
> i.e. treat the Display as any other "kernel", where behavior is logical, not physical, type-dependent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)