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

H-3947: Implement higher precision when convert data types in the graph #6303

Conversation

TimDiekmann
Copy link
Member

@TimDiekmann TimDiekmann commented Jan 31, 2025

🌟 What is the purpose of this PR?

As a stop-gap solution to do math for any numbers, we're going to

  • Use our own JSON type (instead of serde_json::Value)
  • Use a decimal library to do conversions in the graph
  • Store only f64

🔍 What does this change?

  • Introduce a new Value type which replaces serde_json::Value to have more control over it
  • Implement a Real type which represents a decimal number
  • Use the Real type in the newly added Value

Real behavior:

  • Creation from integers is lossless
  • Conversion from f32 and f64 fails if it's NaN
  • Converting to primitives may round and truncate
  • Can be converted to/from FLOAT4 and FLOAT8 in Postgres
  • It can be deserialized from number primitives and strings

Value behavior:

  • Parses and outputs Number from/as f64
  • This means, outside of the graph (API and Postgres) only f64 precision is retained, but internally, a higher precision is used

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

  • does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

  • are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

  • do not affect the execution graph

Sorry, something went wrong.

TimDiekmann and others added 3 commits January 30, 2025 15:25

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@TimDiekmann TimDiekmann self-assigned this Jan 31, 2025
@github-actions github-actions bot added area/deps Relates to third-party dependencies (area) area/infra Relates to version control, CI, CD or IaC (area) area/libs Relates to first-party libraries/crates/packages (area) type/eng > backend Owned by the @backend team area/tests New or updated tests labels Jan 31, 2025
Copy link

codecov bot commented Jan 31, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 20.87%. Comparing base (9b2708f) to head (4b1b3d9).
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #6303      +/-   ##
==========================================
- Coverage   21.03%   20.87%   -0.16%     
==========================================
  Files         580      580              
  Lines       19832    19792      -40     
  Branches     2929     2929              
==========================================
- Hits         4171     4132      -39     
+ Misses      15609    15608       -1     
  Partials       52       52              
Flag Coverage Δ
apps.hash-ai-worker-ts 1.34% <ø> (ø)
apps.hash-api 1.14% <ø> (ø)
blockprotocol.type-system 46.42% <ø> (ø)
local.harpc-client 48.69% <ø> (ø)
local.hash-backend-utils 8.81% <ø> (ø)
local.hash-graph-sdk 58.62% <ø> (ø)
local.hash-isomorphic-utils 0.91% <ø> (ø)
local.hash-subgraph 24.54% <ø> (ø)
rust.deer 6.66% <ø> (ø)
rust.error-stack 72.53% <ø> (ø)
rust.sarif 88.81% <ø> (+0.15%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@vilkinsons
Copy link
Member

How many number-related data types are we exposing to users as HASH "Data Types" in the ontology/entities UI? (Integer, 64 bit float, 128 bit float, etc.)

@TimDiekmann
Copy link
Member Author

How many number-related data types are we exposing to users as HASH "Data Types" in the ontology/entities UI? (Integer, 64 bit float, 128 bit float, etc.)

Currently, we only expose number in TypeScript, which corresponds to a 64 bit floating point (IEEE 754). For embeddings, we use 32 bit. See H-3988 for more thoughts on this topic.
The frontend may restrict number further depending on constraints such as whole numbers, min, max, etc.

CiaranMn
CiaranMn previously approved these changes Feb 3, 2025
Copy link
Member

@CiaranMn CiaranMn left a comment

Choose a reason for hiding this comment

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

Looks good, thanks @TimDiekmann!

…ues-when-converting-data-types

# Conflicts:
#	Cargo.lock
#	Cargo.toml
#	libs/@blockprotocol/type-system/rust/src/schema/data_type/constraint/array.rs
#	libs/@blockprotocol/type-system/rust/src/schema/data_type/constraint/number.rs
#	libs/@blockprotocol/type-system/rust/src/schema/data_type/constraint/string.rs
#	tests/graph/integration/postgres/data_type.rs
#	tests/graph/integration/postgres/partial_updates.rs
#	tests/graph/integration/postgres/property_metadata.rs
@TimDiekmann
Copy link
Member Author

Thanks! I need a re-approval due to merge conflicts due to changes in rustfmt in the toolchain bump merged earlier today.

CiaranMn
CiaranMn previously approved these changes Feb 3, 2025
@TimDiekmann TimDiekmann added this pull request to the merge queue Feb 3, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 3, 2025
@vilkinsons vilkinsons added this pull request to the merge queue Feb 3, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 3, 2025
@TimDiekmann TimDiekmann added this pull request to the merge queue Feb 3, 2025
github-merge-queue bot pushed a commit that referenced this pull request Feb 3, 2025
@TimDiekmann TimDiekmann added this pull request to the merge queue Feb 3, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Feb 3, 2025
Copy link
Contributor

github-actions bot commented Feb 3, 2025

Benchmark results

@rust/hash-graph-benches – Integrations

scaling_read_entity_complete_zero_depth

Function Value Mean Flame graphs
entity_by_id 25 entities 3.34 ms ± 9.81 μ s ( 3.76 % ) Flame Graph
entity_by_id 1 entities 1.99 ms ± 11.5 μ s ( 0.432 % ) Flame Graph
entity_by_id 5 entities 2.00 ms ± 8.72 μ s ( 0.088 % ) Flame Graph
entity_by_id 10 entities 2.20 ms ± 6.62 μ s ( 0.246 % ) Flame Graph
entity_by_id 50 entities 4.17 ms ± 23.4 μ s ( 17.113 % ) Flame Graph

representative_read_entity

Function Value Mean Flame graphs
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/organization/v/1 16.8 ms ± 198 μ s ( 26.609 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/block/v/1 17.1 ms ± 202 μ s ( 24.996 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/song/v/1 16.0 ms ± 196 μ s ( 0.472 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/uk-address/v/1 17.0 ms ± 181 μ s ( 0.321 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/playlist/v/1 16.1 ms ± 167 μ s ( 4.151 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/page/v/2 15.3 ms ± 185 μ s ( 5.990 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/book/v/1 15.5 ms ± 164 μ s ( 4.156 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/person/v/1 15.8 ms ± 182 μ s ( 30.383 % ) Flame Graph
entity_by_id entity type ID: https://blockprotocol.org/@alice/types/entity-type/building/v/1 16.1 ms ± 185 μ s ( 6.82 % ) Flame Graph

representative_read_entity_type

Function Value Mean Flame graphs
get_entity_type_by_id Account ID: d4e16033-c281-4cde-aa35-9085bf2e7579 2.11 ms ± 8.05 μ s ( 0.014 % ) Flame Graph

representative_read_multiple_entities

Function Value Mean Flame graphs
link_by_source_by_property depths: DT=0, PT=2, ET=2, E=2 85.6 ms ± 381 μ s ( 0.502 % ) Flame Graph
link_by_source_by_property depths: DT=0, PT=0, ET=2, E=2 80.5 ms ± 311 μ s ( 0.927 % ) Flame Graph
link_by_source_by_property depths: DT=0, PT=0, ET=0, E=2 72.4 ms ± 426 μ s ( 0.030 % ) Flame Graph
link_by_source_by_property depths: DT=2, PT=2, ET=2, E=2 89.2 ms ± 549 μ s ( 0.349 % ) Flame Graph
link_by_source_by_property depths: DT=255, PT=255, ET=255, E=255 97.5 ms ± 486 μ s ( 1.190 % ) Flame Graph
link_by_source_by_property depths: DT=0, PT=0, ET=0, E=0 37.0 ms ± 259 μ s ( 3.754 % ) Flame Graph
entity_by_property depths: DT=0, PT=2, ET=2, E=2 51.9 ms ± 337 μ s ( 0.046 % ) Flame Graph
entity_by_property depths: DT=0, PT=0, ET=2, E=2 46.8 ms ± 225 μ s ( 0.535 % ) Flame Graph
entity_by_property depths: DT=0, PT=0, ET=0, E=2 42.2 ms ± 388 μ s ( 1.14 % ) Flame Graph
entity_by_property depths: DT=2, PT=2, ET=2, E=2 55.5 ms ± 369 μ s ( 0.582 % ) Flame Graph
entity_by_property depths: DT=255, PT=255, ET=255, E=255 64.6 ms ± 267 μ s ( 0.267 % ) Flame Graph
entity_by_property depths: DT=0, PT=0, ET=0, E=0 37.1 ms ± 226 μ s ( 0.264 % ) Flame Graph

scaling_read_entity_complete_one_depth

Function Value Mean Flame graphs
entity_by_id 25 entities 174 ms ± 745 μ s ( 4.078 % ) Flame Graph
entity_by_id 1 entities 20.7 ms ± 65.9 μ s ( 0.770 % ) Flame Graph
entity_by_id 5 entities 27.4 ms ± 269 μ s ( 2.30 % ) Flame Graph
entity_by_id 10 entities 31.4 ms ± 157 μ s ( 45.531 % ) Flame Graph
entity_by_id 50 entities 5.60 s ± 281 ms ( 0.049 % ) Flame Graph

scaling_read_entity_linkless

Function Value Mean Flame graphs
entity_by_id 100 entities 2.21 ms ± 8.99 μ s ( 1.03 % ) Flame Graph
entity_by_id 1000 entities 2.89 ms ± 11.4 μ s ( 7.374 % ) Flame Graph
entity_by_id 10000 entities 9.29 ms ± 91.1 μ s ( 2.87 % ) Flame Graph
entity_by_id 1 entities 1.99 ms ± 6.10 μ s ( 0.648 % ) Flame Graph
entity_by_id 10 entities 2.00 ms ± 8.65 μ s ( 0.697 % ) Flame Graph

@TimDiekmann TimDiekmann added this pull request to the merge queue Feb 3, 2025
Merged via the queue into main with commit 837a151 Feb 3, 2025
146 checks passed
@TimDiekmann TimDiekmann deleted the t/h-3947-avoid-floating-point-issues-when-converting-data-types branch February 3, 2025 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/deps Relates to third-party dependencies (area) area/infra Relates to version control, CI, CD or IaC (area) area/libs Relates to first-party libraries/crates/packages (area) area/tests New or updated tests type/eng > backend Owned by the @backend team
Development

Successfully merging this pull request may close these issues.

None yet

3 participants