Struct Bc5dTable 

pub struct Bc5dTable { /* private fields */ }

BC5D table with 4D interpolation (drag type is discrete)

Implementations

impl Bc5dTable

pub fn load<P: AsRef<Path>>(path: P) -> Result<Self, Bc5dError>

Load a BC5D table from a binary file

pub fn from_bytes(bytes: &[u8]) -> Result<Self, Bc5dError>

Parse a BC5D table directly from an in-memory byte slice.

Behaves identically to Bc5dTable::load but performs no filesystem access, which makes it usable from WASM (wasm32-unknown-unknown, where there is no std::fs). The host JS/Node layer fetches the .bin and hands the raw bytes across the boundary.

pub fn lookup( &self, weight_grains: f64, base_bc: f64, muzzle_velocity: f64, current_velocity: f64, drag_type: &str, ) -> f64

Look up a BC correction factor with 4D linear interpolation (drag type is discrete, not interpolated)

Arguments

• weight_grains - Bullet weight in grains
• base_bc - Published BC value
• muzzle_velocity - Initial muzzle velocity in fps
• current_velocity - Current bullet velocity in fps
• drag_type - “G1” or “G7”

Returns

Correction factor (multiply published BC by this value)

pub fn get_effective_bc( &self, weight_grains: f64, base_bc: f64, muzzle_velocity: f64, current_velocity: f64, drag_type: &str, ) -> f64

Get the effective BC at a given velocity

This multiplies the base BC by the correction factor from the table.

pub fn generate_segments( &self, base_bc: f64, drag_type: &str, weight_grains: f64, muzzle_velocity_fps: Option<f64>, ) -> Option<Vec<BCSegmentData>>

Generate velocity-dependent BC segments for a bullet from this table.

This mirrors the CLI’s --bc-table-dir segment synthesis: the 4D correction surface is sampled at a fixed ladder of velocity breakpoints (from 500 fps up through the muzzle velocity) and each adjacent pair becomes a crate::BCSegmentData carrying the corrected BC over that band. The solver consumes these via inputs.bc_segments_data + use_bc_segments, giving the same velocity-dependent BC degradation offline that the online solver produces.

All velocities are in fps and weight_grains in grains, matching the table’s native units. Returns None when the table carries no meaningful correction for this bullet (every sampled cell ~= 1.0), so callers can leave the constant published BC in place.

pub fn caliber(&self) -> f32

Get caliber this table is for

pub fn caliber_key(&self) -> i32

The table’s own caliber as a BC5D key (caliber_to_key) — exactly the value Self::ensure_caliber_matches compares against, and the value bc5d.info reports as caliber_key so an app can pre-check a downloaded table itself.

pub fn ensure_caliber_matches( &self, shot_caliber_in: f64, ) -> Result<(), Bc5dError>

Refuse this table for a shot of a different caliber.

shot_caliber_in is the shot’s bullet diameter in INCHES.

Why this is an error and not a warning or a silent skip

Nothing in the lookup path fails on a foreign table: Self::lookup clamps out-of-range values to the edge bins, so a table for another caliber still returns a plausible-looking correction for every cell and Self::generate_segments still emits a full ladder. Measured: the published bc5d_224.bin handed a 175 gr / G1 0.505 / 2600 fps .308 shot yields a 25-segment ladder whose segment BCs are 0.4710..0.5114 where the .308 table gives 0.4989..0.5072 — ~6.7 % off in the low bands, with no diagnostic anywhere; a .308 table on a .243 shot measures -17.9 % effective BC. A wrong-caliber table is therefore WORSE than no table at all: no table leaves the published BC intact, while a wrong one silently biases every row. So the caller is refused outright — never corrected with foreign data, and never quietly downgraded to an uncorrected solve either, because a caller that asked for a table and got an unannotated uncorrected answer cannot tell.

Matching rule

Equality of the 3-digit BC5D caliber key (caliber_to_key) — the same key find_table_file uses to choose bc5d_<key>.bin for --bc-table-dir. The guard therefore accepts exactly the diameters for which the CLI would have selected this table’s own filename: precedent decides the rule, so the CLI and the path/bytes consumers (bridge cards, bridge solve, solve-json, WASM) cannot disagree about what “this table is for my shot” means.

In practice that is a half-thousandth tolerance — a 308 table accepts [0.3075, 0.3085) — expressed as a bucket rather than a centered epsilon. Bucketing matters: the header caliber is an f32, so 0.308 arrives as 0.30799998, and rounding to the nearest thousandth absorbs that representation error, whereas a centered |a - b| <= 0.0005 comparison would have to carry a separate fudge for it.

pub fn version(&self) -> u32

Get table version

pub fn api_version(&self) -> &str

Get API version used to generate the table

pub fn timestamp(&self) -> u64

Get generation timestamp

pub fn total_cells(&self) -> usize

Get total number of cells in the table

pub fn bin_counts(&self) -> (usize, usize, usize, usize, usize)

Bin counts per axis: (weight, bc, muzzle_vel, current_vel, drag_types).

The structured counterpart of Self::dimensions_str, for callers that report table metadata over a wire (e.g. the bridge’s bc5d.info).

pub fn dimensions_str(&self) -> String

Get table dimensions as a string

pub fn weight_range(&self) -> (f32, f32)

Get weight range

pub fn velocity_range(&self) -> (f32, f32)

Get velocity range

Trait Implementations

impl Debug for Bc5dTable

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.