Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider typing the sparse array itself, rather than the underlying data arrays #24

Closed
willow-ahrens opened this issue Mar 19, 2023 · 1 comment

Comments

@willow-ahrens
Copy link
Collaborator

Instead of defining the types of underlying in-memory arrays, e.g. pointers_1_type and indices_0_type, consider defining the types of the in-memory sparse array as a whole. Consider the following spec:

The index_types, position_type, and value_type keys must be present and
shall define the data types of all required arrays based on the [[#key_format]].
The types declare the type of the in-memory arrays. While these are often
identical to the types used when storing the arrays on disk in the container,
the container may choose to store the arrays in another format. For example,
uint64 type may be stored as int8 if all the numbers in the array are small
enough to fit, but position_type would still list the array as having type
uint64.

The index_types shall define the types of in-memory arrays that hold indices.
It shall be an array [i_type_0, ..., i_type_(N-1)] where i_type_r is the
type of r^th index to the array (regardless of whether the array is row-major or
column major).

The position_type shall define the type of in-memory arrays that hold positions.

The value_type shall define the type of in-memory arrays that hold the array elements themselves.

@willow-ahrens
Copy link
Collaborator Author

willow-ahrens commented May 17, 2023

I'm closing this for now, we can bring this back later if it becomes useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant