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

feat: add a schema for serialization #105

Merged
merged 11 commits into from
Oct 17, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ jobs:
python-version: ${{ matrix.python-version }}

- name: Install package
run: python -m pip install .[test]
run: python -m pip install .[test,schema]

- name: Test
run: python -m pytest -ra
Expand Down
7 changes: 6 additions & 1 deletion .pre-commit-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,6 @@ repos:
- importlib_metadata
- importlib_resources


- repo: https://github.com/pre-commit/pygrep-hooks
rev: v1.10.0
hooks:
Expand Down Expand Up @@ -72,3 +71,9 @@ repos:
hooks:
- id: check-readthedocs
- id: check-github-workflows
- id: check-metaschema
files: ^src/uhi/resources/histogram.json$
- id: check-jsonschema
name: Validate Histogram examples
args: [--schemafile, src/uhi/resources/histogram.json]
files: ^tests/resources/.*\.json
1 change: 1 addition & 0 deletions docs/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@
# ones.
extensions = [
"myst_parser",
"sphinx-jsonschema",
"sphinx.ext.napoleon",
"sphinx_copybutton",
"sphinx_github_changelog",
Expand Down
1 change: 1 addition & 0 deletions docs/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -30,6 +30,7 @@ to plot a histogram, including error bars.
indexing.rst
indexing+.rst
plotting.rst
serialization.md
changelog.md


Expand Down
118 changes: 118 additions & 0 deletions docs/serialization.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
# Serialization


## Introduction

Histogram serialization has to cover a wide range of formats. As such, we
describe a form for serialization that covers the metadata structure as
JSON-like, with a provided JSON-schema. The data (bins and/or variable edges)
is stored out-of-band in a binary format based on what type of data file you
are in. For very small (primarily 1D) histograms, data is allowed inline as
well.

The following formats are being targeted:

```
┌────────┐ ┌────────┐ ┌───────┐
│ ROOT │ │ HDF5 │ │ ZIP │
└────────┘ └────────┘ └───────┘
```

Other formats can be used as well, assuming they support out-of-band data and
text attributes or files for the metadata.

## Caveats

This structure was based heavily on boost-histogram, but it is intended to be
general, and can be expanded in the future as needed. As such, the following
limitations are required:

* Serialization followed by deserialisation may cause axis changes. Axis types
may change to an equivalent but less performant axis, growth status will be
lost, etc.
Comment on lines +30 to +32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For an interchangable standard that is acceptable, but boost-histogram should always have also its own data format were no information is lost.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still have pickling, which is both stable and lossless. It's just not interchangeable. ;)

* Metadata must be expressible as JSON. It should also be reasonably sized; some
formats like HDF5 may limit the size of attributes to 64K.
* Floating point errors could be incurred on conversion, as the storage format
uses a stable but different representation.
* Axis `name` is only part of the metadata, and is not standardized. This is

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a very welcome addition, at least in HS3 we will rely on the name of variables in order to match data and function evaluation inputs (both standards, in principle, don't need to agree, but it would be great of course if they could).

How would Hist handle this? Just as before, taking the name from the label?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would store the names in the metadata slot. So it would look for a name field in the metadata dict. Same way __dict__ and boost-histogram works now. :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remind me what is lacking in support from boost-histogram? The metadata field of the axis was originally just intended to be a name. @henryiii pushed for it to be a general Python type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The metadata stores the name, title, all ROOT metadata, etc. There are no requirements on it, except that it be a string-keyed dictionary. It would be nice to have an optional "name" slot which was guaranteed to be a unique string that can be used to refer to the the axis if present. One of the common themes at PyHEP.dev was a desire to avoid ever writing axis=<int>, something which Awkward and xarray allow you to do. Hist already has this, but unless it was added elsewhere, it's probably easier to leave it unstandardized and just hope people put "name" into the metadata.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this nearly leads to a slightly different discussion, but metadata can indeed be helpful. I would disect it into two parts:

  • name identifier: it seems in general beneficial to use names to access data (i.e. pandas vs numpy). I also see though why bh may choose to not go this path (as before, it's more "numpy" than "pandas" AFAIU). Still, talking also about xarray etc, the general accesability by name may becomes more common.
  • metadata: it seems that data is desired to have in many places metadata. "Lower" and "upper" seem to me a perfect example of that, label obviously. Nothing that every library (i.e. uproot) needs to know about, but that could be useful to carry around.

To go back specifically to BH and serialization:

  • Is an "axis-access-by-name" implementation for the library a possibility (given xarray etc) or out-of-scope (I can see why it may is)?
  • One could in the serialization standard only add a "name" attribute that will be autoconverted to and from "metadata" (if available). That's practical but not nice IMHO and could, worst case, just be another conversion layer (i.e. to make it HS3 compatible). Not great, not bad?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hist will look for "name": ... in the metadata, and if it's present, that will be the .name attribute on the axis, and you'll get access-by-name. Same with "label": .... When uproot is loading attributes from a ROOT file, it renames labels and names to match (all other metadata goes in as-is, like line widths and colors and such).

We could bake it into the standard instead, and then hist's job gets easier, while boost-histogram's job gets harder. Boost-histogram would have to have some way to handle names - currently this packing/unpacking is in Hist, so it's a little harder. That also could be done, so it's really a case of picking what's best for everyone else.

due to lack of support from boost-histogram.

## Design

The following axes types are supported:

* `"regular"`: A regularly spaced set of even bins. Boost-histogram's "integer"
axes maps to this axis as well. Has `upper`, `lower`, `bins`, `underflow`,
henryiii marked this conversation as resolved.
Show resolved Hide resolved
`overflow`, and `circular` properties. `circular` defaults to False if not
present.
* `"variable"`: A continuous axis defined by bins+1 edges. Has `edges`, which
is either an in-line list of numbers or a string pointing to an out-of-band data source.
Also has `underflow`, `overflow`, and `circular` properties. `circular`
defaults to False if not present.
* `"category_int"`: A list of integer bins, non-continuous. Has `categories`,
which is an in-line list of integers. Also has `flow`.
* `"category_str"`: A list of string bins. Has `categories`,
which is an in-line list of strings. Also has `flow`.
* `"boolean"`: A true/false axis.

Axes with gaps are currently not supported.

All axes support `metadata`, a string-valued dictionary of arbitrary, JSON-like data.

The following storages are supported:

* `"int"`: A collection of integers. Boost-histogram's Int64 and AtomicInt64
map to this, and sometimes Unlimited.
* `"double"`: A collection of 64-bit floating point values. Boost-histogram's
Double storage maps to this, and sometimes Unlimited.
* `"weighted"`: A collection of two arrays of 64-bit floating point values,
`"value"` and `"variance"`. Boost-histogram's Weight storage maps to this.
* `"mean"`: A collection of three arrays of 64-bit floating point values,
"count", "value", and "variance". Boost-histogram's Mean storage maps to
this.
* `"weighted_mean"`: A collection of four arrays of 64-bit floating point
values, `"sum_of_weights"`, `"sum_of_weights_squared"`, `"values"`, and
`"variances"`. Boost-histogram's WeighedMean storage maps to this.

## CLI/API

You can currently test a JSON file against the schema by running:

```console
$ python -m uhi.schema some/file.json
```

Or with code:

```python
import uhi.schema

uhi.schema.validate("some/file.json")
```

Eventually this should also be usable for JSON's inside zip, HDF5 attributes,
and maybe more.

```{warning}

Currently, this spec describes **how to prepare the metadata** for one of the
targeted backends. It does not yet cover backend specific details, like how to
define and use the binary resource locator strings or how to store the data.
JSON is not a target spec, but just part of the ZIP spec, meaning the files
that currently "pass" the tool above would be valid inside a `.zip` file
eventually, but are not valid by themselves.
```

## Rendered schema

```{jsonschema} ../src/uhi/resources/histogram.json
```


## Full schema

The full schema is below:

```{literalinclude} ../src/uhi/resources/histogram.json
:language: json
```
2 changes: 1 addition & 1 deletion noxfile.py
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ def tests(session):
"""
Run the unit and regular tests.
"""
session.install("-e.[test]")
session.install("-e.[test,schema]")
session.run("pytest", *session.posargs)


Expand Down
9 changes: 9 additions & 0 deletions pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -44,10 +44,15 @@ Documentation = "https://uhi.readthedocs.io/en/latest/"
Changelog = "https://github.com/scikit-hep/uhi/releases"

[project.optional-dependencies]
schema = [
"fastjsonschema",
"importlib-resources; python_version<'3.9'",
]
docs = [
"sphinx>=4.0",
"furo",
"sphinx-copybutton>=0.3.1",
"sphinx-jsonschema",
"myst-parser",
"sphinx_github_changelog",
]
Expand Down Expand Up @@ -88,6 +93,10 @@ show_error_codes = true
warn_unreachable = true
enable_error_code = ["ignore-without-code", "redundant-expr", "truthy-bool"]

[[tool.mypy.overrides]]
module = ["fastjsonschema"]
ignore_missing_imports = true

[tool.ruff]
select = [
"E", "F", "W", # flake8
Expand Down
Loading
Loading