Rank Normalization: Comparable Scales Still Need Clear Conventions

Features with different units or numeric ranges can produce a sum dominated by the larger numbers. Rank normalization transforms the ordering of securities on the same date into a common scale. It uses a security's relative position rather than the raw size of its measurement.

The transformation makes scale differences easier to handle; it does not establish predictive usefulness. It also discards distances. Two almost equal observations and two widely separated observations may have the same difference between their transformed ranks.

Take fictional values A=2, B=5, C=9 and D=14. Ascending ranks r are 1, 2, 3 and 4. For this teaching example, define u=(r−1)/(n−1). With n=4, the transformed values are 0, 1/3, 2/3 and 1. This illustrates one convention; it does not assert KabuForge's implementation formula.

Multiplying every raw value by ten leaves the order and these transformed values unchanged. The original gap of four between B and C is lost. For an actual run, inspect the implementation and recipe to establish its scale, ordering direction and tie convention.

For fictional values 2, 5, 5 and 14, average ranks are 1, 2.5, 2.5 and 4. The illustrative formula produces 0, 0.5, 0.5 and 1. Sorting tied observations by security code does not add information to the underlying feature.

Replacing a missing value with zero confuses an unavailable measurement with an observed zero. Preserve the missing-value policy and valid count. Check whether calculations are defined for one valid security or a constant cross-section: the illustrative formula divides by zero when n=1.

Whether a high raw value or a low raw value should receive a high score belongs to the feature definition. Normalization does not choose that direction. If you reverse it after inspecting evaluation results, record that period as information used in the selection.

For fictional normalized values 0.75 and 0.25, a weighted average using 0.5 for each equals 0.5. These are arithmetic examples, not recommended weights. Even on a common scale, highly similar features may cause the same information to be counted twice.

Public Demo 2 documents factor diagnostics using rank normalization. This does not establish that every other transformation is supported through that interface. Inspect your build's recipe, feature outputs and valid counts, then record the convention actually used.

The deliverable is both a hand-worked example and a clear explanation of the rules applied to an actual output. Keep normalized features separate from future labels. Evaluation results do not automatically provide trading decisions or optimal weights.

Read What is a factor? · Information coefficient · Quantile analysis to place this topic alongside other research checks. Confirm documented operations and limits in the official GUI research courses. Use documentation for your selected build; if public main differs from your environment, defer unverified claims.

This article teaches research procedures. Numerical examples are fictional teaching illustrations, not actual investment performance. It does not recommend securities or trades or guarantee future returns. Historical public courses do not establish complete historical information availability. Disclaimer

SciPy rank and tie conventions。 Check tie conventions here, and reconcile the fictional example separately from the recipe actually selected.

Explore the factors learning path

• Factor Correlation: Check Whether Features Repeat the Same Information
• ICIR: What the Mean and Variation of IC Can Tell You
• What Is a Factor? Comparing Security Characteristics with Numbers