The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.

OptimalBinningWoE 1.13.3

Audit fixes (2026-08-21)

Bug-fix release from a third internal audit, covering the WoE/IV return contract, the converged flag and the max_bins constraint across all 37 algorithm/type combinations. Every item below was reproduced before the fix and re-verified after it. The regression suite gained tests/testthat/test-audit-regressions.R, which fails on 1.13.2.

Behavior changes (read before upgrading)

Corrected values

Fixed crashes

converged now means the same thing everywhere

The flag was effectively inverted in several engines: initialised false and set true only on a degenerate shortcut or an in-loop tolerance test, while the normal successful exit – reaching the bin-count target – set nothing. So ordinary well-binned features reported FALSE and only degenerate ones reported TRUE.

The intended contract is now documented in src/common/bin_structures.h: converged == true means the algorithm reached a valid stopping state (tolerance met, monotonicity achieved, or the bin-count target reached); false means it exhausted max_iterations.

Three algorithms were quadratic in the number of rows

lpdb, ldb and numerical udt scaled as n^2.00, n^2.00 and n^2.30. A single variable with 10^6 rows would have taken lpdb roughly 72 minutes; measured against jedi at the same size they were 2,772x the median algorithm’s cost. Nothing warned about it.

Two distinct causes, neither of them inherent to the methods:

Measured at n = 50,000, against a build of the previous revision:

algorithm before after speedup
ldb 10.740s 0.010s 1074x
lpdb 10.725s 0.011s 975x
udt 7.354s 0.019s 387x

All three now scale linearly and land within a factor of two of jedi, the package default. At n = 400,000 they take 0.085s, 0.087s and 0.170s against jedi’s 0.103s – sizes the previous code could not reach at all.

Results. udt and ldb are bit-identical to the previous revision: udt by construction, and ldb’s local-minimum search resolves the grid estimate to the same cut points. Both are pinned by a new regression test.

lpdb changes. It differentiates the density twice to find inflection points, and finite differences taken between adjacent observations are not the same thing as finite differences on a properly sampled curve. Its critical points are now located on the estimation grid. On German Credit the partitions generally improve – duration goes from 2 bins and IV 0.0923 to 5 bins and IV 0.2635, age from 2 bins and 0.0628 to 4 bins and 0.0781 – and no variable tested got materially worse. Anyone with a fitted lpdb model should expect different cut points.

Also removed OBN_LPDB::local_polynomial_density(), which no longer had a caller and never did local polynomial regression despite its name.

Fixed: categorical dmiv ignored max_bins

Fixed: categorical mba read past the end of its bin vector

Fixed: categorical ivb and gmb dropped observations

Documentation

Smaller items

OptimalBinningWoE 1.13.2

The fitted object now records how it was fitted

Nothing changes for the default configuration: "%;%" remains the default everywhere, so only the custom-separator path – which was broken – behaves differently.

OptimalBinningWoE 1.13.1

Audit fixes (2026-08-20)

Bug-fix release addressing an internal code audit of 1.13.0. Every item below either changes a computed value that was previously wrong, or removes an API surface the author never intended to publish. See the pull request for the full item-by-item breakdown.

API changes

Behavior changes (read before upgrading)

Fixes

OptimalBinningWoE 1.13.0

New features (2026-08-20)

obwoe_scorecard() — the pipeline as one artefact

Runs the whole origination workflow in a single call — stratified split, binning, screening by Information Value and correlation, model fitting, PDO scaling — and returns an object that also writes itself out as an .xlsx model document. The point is not convenience: each stage records why it did what it did, so the workbook is reviewable evidence rather than a set of numbers.

Supporting functions

Fixed during review

Dependencies

openxlsx and glmnet are added to Suggests. Neither is needed unless a workbook is written or engine = "glmnet" is requested.

OptimalBinningWoE 1.12.0

New features (2026-08-19)

Two additions close the gap between a fitted binning and a deployed scorecard: deciding which variables deserve to enter the model, and shipping the accepted transformation to the database where the data lives.

obwoe_select() — automated variable screening

Screens every binned variable of an obwoe model against the two criteria that govern variable admission in credit risk practice — predictive strength, graded with the Siddiqi (2006) Information Value bands, and guaranteed rank ordering, measured by monotonicity of the bin event rate — and returns a verdict for each.

obwoe_sql() — SQL code generation

Translates a fitted binning into executable SQL, so the WoE transformation runs inside the database with no round trip through R.

Validation

Bug fixes

Both defects below were uncovered while validating the two new functions against real data, and both are pinned by tests in tests/testthat/test-regression-audit.R that fail on 1.11.0 — 31 assertions in total.

Documentation

Notes

OptimalBinningWoE 1.11.0

C++ Engine — Runtime Audit (2026-08-12)

Follow-up to the 1.10.0 static audit, this time driven by instrumented builds (-fsanitize=address,undefined), a degenerate-input stress harness, and a golden-output regression suite covering all 37 exported algorithms (~3,200 result comparisons). All fixes below are covered by new tests in tests/testthat/test-regression-audit.R, each of which fails on 1.10.0.

Bug Fixes — crashes and hangs

Reproducibility

Output consistency

Parallelism (obcorr) — CRAN policy and determinism

Build hygiene

Interval convention — standardised on (a, b] (changes numeric output)

The package previously disagreed with itself about what a bin is. Bin labels advertised (a;b], but many algorithms assigned observations as [a;b); ob_apply_woe_num() had its two binary searches swapped, so both settings of include_upper_bound did the opposite of what the argument documents; and several equal-frequency pre-binners split runs of tied values, so their reported counts could not be derived from their own reported cutpoints under any convention. A value landing exactly on a cutpoint — routine for integer, rounded or currency features — could be scored into a different bin than the one it was trained in.

Measured across 63 algorithm/dataset combinations, 31 violated the documented (a, b] convention before this release; 0 do now.

ob_numerical_cm silently discarded observations. Its equal-frequency pre-binner, on hitting a tie that straddled a bin boundary, advanced past the tied records without ever assigning them to a bin. On tied or discrete features this dropped a large share of the data — 26% on an integer feature and 40% on a coarse one in testing — and the reported WoE/IV were computed from the surviving subset. The tied records are now absorbed into the preceding bin.

Known issues (not yet fixed)

OptimalBinningWoE 1.10.0

C++ Engine — Comprehensive Audit & Hardening (2026-05-17)

This release is the result of a full static audit of the C++ engine covering all 36 binning algorithms. No public R API was changed.

Bug Fixes

Performance Improvements

CRAN / ODR Safety

Code Quality


OptimalBinningWoE 1.0.9

OptimalBinningWoE 1.0.8

OptimalBinningWoE 1.0.7

OptimalBinningWoE 1.0.6

OptimalBinningWoE 1.0.5

OptimalBinningWoE 1.0.4

OptimalBinningWoE 1.0.3

OptimalBinningWoE 1.0.2

OptimalBinningWoE 1.0.1

OptimalBinningWoE 1.0.0

Initial Release

OptimalBinningWoE is a high-performance R package for optimal binning and Weight of Evidence (WoE) transformation, designed for credit scoring and predictive modeling.

Key Features

usage

These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.