[
https://issues.apache.org/jira/browse/PARQUET-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729402#comment-17729402
]
Anja Boskovic edited comment on PARQUET-758 at 6/5/23 6:26 PM:
---------------------------------------------------------------
Hi Gabor!
I would support a proposal for implementing bfloat16, maybe even as a canonical
extension type in Arrow.
However, I have a hesitency to including that in this round of implementations.
I think it should be considered seperately.
1. My understanding is that the implementations have already begun (I messaged
the parties working on the implementations, to create appropriate tickets).
2. This it will increase the time added to the format review and then to the
implementations.
3. Part of that, I forsee additional back-and-forth over debating why
"bfloat16"; why not tensorfloat? Why not add both?
And my experience has been that these conversations take a really long time for
the Parquet community.
Float16 being an IEEE standard has a simplicity to its inclusion.
So, I guess my takeaway is that I support us opening a seperate format PR for
bfloat16 inclusion, and having that occur seperate from the work of including,
and implementing, IEEE float16.
was (Author: JIRAUSER288952):
Hi Gabor!
I would support a proposal for implementing bfloat16, maybe even as a canonical
extension type in Arrow.
However, I have a hesitency to including that in this round of implementations.
I think it should be considered seperately.
1. My understanding is that the implementations have already begun (I am
messaging the parties working on the implementations, to create appropriate
tickets).
2. This it will increase the time added to the format review and then to the
implementations.
3. Part of that, I forsee additional back-and-forth over debating why
"bfloat16"; why not tensorfloat? Why not add both?
And my experience has been that these conversations take a really long time for
the Parquet community.
Float16 being an IEEE standard has a simplicity to its inclusion.
So, I guess my takeaway is that I support us opening a seperate format PR for
bfloat16 inclusion, and having that occur seperate from the work of including,
and implementing, IEEE float16.
> [Format] HALF precision FLOAT Logical type
> ------------------------------------------
>
> Key: PARQUET-758
> URL: https://issues.apache.org/jira/browse/PARQUET-758
> Project: Parquet
> Issue Type: Improvement
> Components: parquet-format
> Reporter: Julien Le Dem
> Priority: Minor
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
