Improve implementation, validations and testing for Rust instruments

[nicolad]

Cython / Python Method	Rust Method in Instrument	Notes on Parity
symbol (property)	symbol(&self) -> &str	Same return semantics (borrowed &str).
venue (property)	venue(&self) -> &str	Same return semantics.
get_cost_currency()	cost_currency(&self) -> &Currency	Renamed for Rust style; logic identical.
make_price(value)	make_price(&self, value: f64)	Rounds using instrument price-precision.
make_qty(value, round_down=False)	make_qty(&self, value: f64, round_down: bool)	Round-down flag mirrors Python.
notional_value(qty, price, use_quote)	notional_value(&self, qty, price, use_quote_for_inverse: bool)	Handles linear & inverse paths.
calculate_base_quantity(qty, last_px)	calculate_base_quantity(&self, qty, last_px)	One-to-one logic.

[nicolad]

Area	Status	What’s still needed (➜ “left”)
Trait vs struct architecture	✅	Nothing – existing Instrument trait + concrete structs is sufficient.
Core helpers (make_price, make_qty, tick navigation)	✅	–
Auto-derive price_increment from price_precision when caller passes None	❌	Add default in each constructor (10^-price_precision).
_min_price_increment_precision logic in make_price	⚠️	Re-implement rounding to use min(price precision, tick-increment precision).
Common validations parity with Cython (validate_instrument_common)	⚠️	Add guards for max_price, max_notional > 0 and cross-field “both-or-neither” conditions.
Negative-path unit tests for every validation guard	❌	rstest each failure case; assert panic messages.
from_dict (serde) + round-trip to_dict/from_dict tests	❌	Implement via serde_json::from_value; test JSON⇄struct equality.
PyO3 conversions (struct ⇄ Python object)	❌	Implement #[pymethods] __getstate__/__setstate__; write tests for Python↔Rust round-trip and dict conversions.
Functional tests for inverse & quanto notional / cost-ccy	❌	Validate calculate_notional_value and cost_currency across instrument types.
Tick-scheme range tests (min/max price limits)	❌	Verify next_bid/ask_prices stop at bounds and respect custom schemes.
Decision on separate Instrument struct	✅	No dedicated struct needed – trait approach confirmed.

[cjdsellers]

Is all this additional code to ensure half-even rounding?

[nicolad]

Concern / Feature	“Before” – simple f64 version	“After” – rust_decimal + guards	Why the extra code?
Numeric type used	Pure f64 maths.	Decimal (base-10 exact) → then back to f64.	Avoids binary-decimal drift.
Rounding when round_down = Some(true)	floor() toward −∞.	RoundingStrategy::ToZero (truncate toward 0).	Symmetric for neg & pos sizes; aligns with most exchange “round-down” rules.
Default rounding (None / false)	No rounding at all (just passes value).	MidpointNearestEven (half-even, “banker’s”).	Yes, half-even rounding is now explicit instead of implicit/absent.
Half-even support on midpoint ties	❌ (relies on Quantity::new or IEEE default).	✅ Guaranteed via MidpointNearestEven.	Adds determinism and auditability.
Handling NaN / ∞	Whatever Quantity::new does (implicit).	from_f64_retain + expect("non-finite") – explicit panic.	Fail fast & loud.
Guard against sub-tick quantities	None.	Panics if positive input would round to < 10 % of one tick.	Prevents zero-size orders.
Cross-platform determinism	Dependent on IEEE-754 quirks / FP env.	Pure integer math inside Decimal → deterministic.	Reproducible replays.
Performance	Minimal ops (cheap).	Extra Decimal ops; still cheap but slower in tight loops.	Usually negligible outside ultra-low-latency paths.
Lines of code / readability	Short, easy to scan.	Longer, self-documenting; comments explain invariants.	Clarity & safety trade-off.
Primary reason for the added code?	—	Not just half-even rounding; also precision-safe conversion, non-finite guard, sub-tick guard, deterministic behaviour.	Half-even is one piece of the puzzle.

Is all this additional code only to ensure half-even rounding?

No. Ensuring midpoint-nearest-even rounding is an important part, but the extra lines also:

1. Eliminate binary floating-point drift by moving to exact base-10 arithmetic during rounding.
2. Fail fast on NaN/∞ instead of relying on downstream checks.
3. Guarantee deterministic behaviour across platforms and compiler flags.
4. Prevent “rounded-to-zero” sizes that would be rejected by exchanges.

So half-even rounding is necessary but not sufficient—the additional safeguards and determinism are equally valuable in a trading context.

[nicolad]

let me know if there are any actions I need to take here ☝️

[cjdsellers]

Prices can potentially be negative (options, spreads, commodities etc).

[nicolad]

adjusted, thx