Strasmore Research

Brier Score: Forecast کو کیسے پرکھیں

Brier score probability forecasts کو حقیقی نتائج کے مقابل mean squared error سے جانچتا ہے۔ کم score بہتر ہے، جبکہ ہر بار 50% کہنا 0.25 score دیتا ہے۔

Brier score کسی probability forecast کو حقیقی نتیجے کے مقابل پرکھتا ہے۔ آپ نے جو probability بیان کی تھی، اس میں سے outcome منہا کریں (اگر واقعہ پیش آیا ہو تو 1، اور نہ آیا ہو تو 0)، اس فرق کا مربع نکالیں، پھر اپنی تمام forecasts کے مربعوں کا average لیں۔ کم score بہتر ہوتا ہے: 0 ایک مکمل ریکارڈ ہے، جبکہ ہر معاملے میں “50%” کہنے پر score 0.25 بنتا ہے۔

Brier score کیا ہے؟

Forecast دراصل probability کے بارے میں ایک دعویٰ ہوتا ہے، اور کسی ایک probability کو اکیلے درست یا غلط قرار نہیں دیا جا سکتا۔ آپ نے کسی واقعے کے ہونے کا امکان 30% بتایا اور وہ واقعہ پیش آ گیا۔ کیا آپ غلط تھے؟ ابھی نہیں۔ 1950 میں weather forecasters کے لیے لکھتے ہوئے Glenn Brier نے اس مسئلے کا حل یہ نکالا کہ کسی ایک forecast کی درجہ بندی کرنے سے انکار کر دیا جائے۔ یہ score پورے ریکارڈ کو ایک ساتھ جانچتا ہے۔

یہ دس forecasts کا ایک فرضی ریکارڈ ہے۔ ان میں سے کوئی عدد market سے نہیں لیا گیا؛ یہ صرف حساب سمجھانے کے لیے بنائے گئے ہیں۔

  • 90% بتایا گیا، واقعہ پیش آ گیا۔ Squared miss 0.01۔
  • 80% بتایا گیا، واقعہ پیش آ گیا۔ 0.04۔
  • 70% بتایا گیا، واقعہ پیش نہیں آیا۔ 0.49۔
  • 60% بتایا گیا، واقعہ پیش آ گیا۔ 0.16۔
  • 50% بتایا گیا، واقعہ پیش نہیں آیا۔ 0.25۔
  • 40% بتایا گیا، واقعہ پیش نہیں آیا۔ 0.16۔
  • 30% بتایا گیا، واقعہ پیش آ گیا۔ 0.49۔
  • 20% بتایا گیا، واقعہ پیش نہیں آیا۔ 0.04۔
  • 10% بتایا گیا، واقعہ پیش نہیں آیا۔ 0.01۔
  • 95% بتایا گیا، واقعہ پیش آ گیا۔ 0.0025۔

دسوں squared misses کا مجموعہ 1.6525 بنتا ہے۔ اسے دس پر تقسیم کریں تو Brier score 0.165 آتا ہے۔ یہی مکمل حساب ہے، اور یہ python3 میں چل جاتا ہے جو ہر Mac یا Linux machine کے ساتھ پہلے سے موجود ہوتا ہے۔ کچھ install کرنے یا libraries کی ضرورت نہیں۔

  • rows = [(0.90, 1), (0.80, 1), (0.70, 0), (0.60, 1), (0.50, 0), (0.40, 0), (0.30, 1), (0.20, 0), (0.10, 0), (0.95, 1)]
  • brier = sum((p - o) * (p - o) for p, o in rows) / len(rows)
  • flat = sum((0.5 - o) * (0.5 - o) for _, o in rows) / len(rows)
  • print(round(brier, 3), round(flat, 3)) prints 0.165 0.25

0.25 وہ عدد ہے جس سے بہتر کارکردگی دکھانا ضروری ہے

ہر سوال کے بارے میں 50% امکان بتائیں تو ہر squared miss کا نتیجہ 0.25 ہوگا، چاہے کچھ بھی ہو۔ یہ مستقل 0.25 ہاں یا نہیں والے سوالات کے کسی بھی مجموعے کے لیے no-information benchmark ہے۔ skill score اسے ایک عدد میں تبدیل کرتا ہے: ایک منفی آپ کے score کو benchmark کے score سے تقسیم کرنے کا نتیجہ۔ فرضی log کا 0.165 score، 0.34 کے skill score کے برابر بنتا ہے۔

ایک اہم احتیاط scorekeeping کی بہت سی غلطیوں کو بے نقاب کرتی ہے۔ اگر جن events کی آپ درجہ بندی کر رہے ہیں وہ صرف 10% مرتبہ پیش آتے ہیں، تو ہر بار مستقل 10% کہنا، انفرادی سوالات کے بارے میں کچھ بھی جانے بغیر، 0.09 کا score دیتا ہے۔ سوالات کے غیر متوازن مجموعے میں 0.25 سے کم score skill کا ثبوت نہیں ہوتا۔ درست benchmark ان سوالات کی base rate ہے جن کا آپ نے حقیقتاً جواب دیا۔

Calibration اور confidence کا ایک ساتھ جائزہ لیا جاتا ہے

Calibration کا مطلب یہ ہے کہ جن تمام امکانات کو آپ نے 70% قرار دیا، ان میں تقریباً 70% واقعی وقوع پذیر ہوں۔ Confidence، جسے statisticians resolution کہتے ہیں، اس بات کو ظاہر کرتی ہے کہ کسی معلومات کی بنیاد پر آپ base rate سے کتنی دور جانے کے لیے تیار ہیں۔ ہر سوال کے جواب میں 50% کہنے والا forecaster مکمل طور پر calibrated تو ہوتا ہے، مگر بالکل بےکار بھی؛ Brier score دونوں خصوصیات کی ایک ہی وقت میں قیمت متعین کرتا ہے: miscalibration اسے بڑھاتی ہے، جبکہ حاصل شدہ confidence اسے کم کرتی ہے۔

خود ساختہ log کو بیان کردہ probability کے لحاظ سے buckets میں تقسیم کرنے سے معلوم ہوتا ہے کہ calibration check کیسا دکھائی دیتا ہے۔ Python میں ہر bucket کے لیے ایک سطر ہوتی ہے، hits = [o for p, o in rows if p >= 0.8]، پھر hits کا average نکالا جاتا ہے۔

  • 10% سے 30% بیان کردہ امکان، average 20%: 3 میں سے 1 واقع ہوا، یعنی 33%۔
  • 40% سے 50% بیان کردہ امکان، average 45%: 2 میں سے 0 واقع ہوئے، یعنی 0%۔
  • 60% سے 70% بیان کردہ امکان، average 65%: 2 میں سے 1 واقع ہوا، یعنی 50%۔
  • 80% سے 95% بیان کردہ امکان، average 88%: 3 میں سے 3 واقع ہوئے، یعنی 100%۔

ان buckets سے کوئی نتیجہ اخذ کرنے کے لیے دس forecasts ہرگز کافی نہیں۔ Calibration کے لیے ہر bucket میں سیکڑوں resolved questions درکار ہوتے ہیں۔ اس صفحے کے باقی حصے میں ایسا forecast log استعمال کیا گیا ہے جس میں لاکھوں سوالات شامل ہیں۔

مارکیٹ کی اپنی پیش گوئی کا جائزہ

ہر listed option کے ساتھ ایک ایسا عدد منسلک ہوتا ہے جو بیان کردہ probability کی طرح برتاؤ کرتا ہے۔ Delta یہ پیمائش کرتا ہے کہ underlying stock میں ایک dollar کی تبدیلی پر option کی قیمت کتنی بدلتی ہے۔ ایسے contract کے لیے جو یا تو in the money ختم ہوتا ہے، یعنی expiry پر اس کی کچھ value باقی رہتی ہے، یا بے قیمت ختم ہوتا ہے، Delta کی absolute value اس market-implied probability کے قریب ہوتی ہے کہ contract in the money ختم ہوگا۔ یہ اسی سطح سے اخذ ہوتی ہے جو AAPL کی implied volatility طے کرتی ہے۔ ہر contract کی expiry ہوتی ہے، اس لیے ان تمام پیش گوئیوں کا نتیجہ بھی سامنے آ جاتا ہے۔

ذیل کا panel expiry سے تقریباً ایک ماہ پہلے مشاہدہ کیے گئے ہر SPY option کو، جنوری 2025 سے مئی 2026 تک، stated delta کے حساب سے مختلف buckets میں تقسیم کرتا ہے۔ پھر یہ شمار کرتا ہے کہ contract کتنی مرتبہ in the money ختم ہوا۔

استفسار کریںSPY option deltas بمقابل ان معاہدوں کے in the money ختم ہونے کی شرح
ہر عدد کے پیچھے موجود درست SQL
WITH settle AS
(
    SELECT
        date                             AS settle_date,
        any(toFloat64(underlying_close)) AS settle_px
    FROM global_markets.options_greeks
    WHERE underlying_symbol = 'SPY'
      AND date >= '2025-01-01'
      AND date <  '2026-08-01'
    GROUP BY date
),
scored AS
(
    SELECT
        toUInt8(floor(abs(toFloat64(g.delta)) * 10))    AS bucket,
        abs(toFloat64(g.delta))                         AS stated,
        startsWith(lower(toString(g.option_type)), 'c') AS is_call,
        if(is_call,
           s.settle_px > toFloat64(g.strike_price),
           s.settle_px < toFloat64(g.strike_price))     AS finished_itm
    FROM global_markets.options_greeks AS g
    INNER JOIN settle AS s ON s.settle_date = g.expiration_date
    WHERE g.underlying_symbol = 'SPY'
      AND g.date >= '2025-01-01'
      AND g.date <  '2026-06-01'
      AND g.expiration_date <= '2026-07-31'
      AND g.days_to_expiry BETWEEN 28 AND 35
      AND g.iv_converged = 1
      AND g.volume > 0
      AND abs(g.delta) > 0.02
      AND abs(g.delta) < 0.98
)
SELECT
    concat(toString(bucket * 10), ' to ', toString(bucket * 10 + 10), '%') AS stated_bucket,
    round(avg(stated) * 100, 1)       AS stated_pct,
    round(avg(finished_itm) * 100, 1) AS finished_itm_pct,
    count()                           AS sample_size
FROM scored
GROUP BY bucket
ORDER BY bucket
Run this yourself

دونوں series کا باہمی موازنہ کریں۔ سب سے نچلے bucket میں market نے اوسطاً 5.2% کی پیش گوئی کی، جبکہ یہ contracts 3.7% مرتبہ in the money ختم ہوئے۔ سب سے اونچے bucket میں stated 94% کے ساتھ 96.5% contracts in the money ختم ہوئے۔ تمام 10 buckets میں realized frequency، stated frequency کے تقریباً اسی دائرے میں رہتی ہے۔ calibration table کا مقصد یہی ہے: یہ bucket بہ bucket اس فرق کو نمایاں کرتی ہے کہ forecaster کیا کہتا ہے اور حقیقت میں کیا ہوتا ہے، بجائے اس کے کہ اسے ایک واحد average میں چھپا دیا جائے۔

کیا مارکیٹ coin flip سے بہتر پیش گوئی کرتی ہے؟

اب خود score پر نظر ڈالتے ہیں۔ طریقۂ کار وہی ہے۔ اس میں کئی معروف نام شامل ہیں، اور ہر نام کا Brier score بالکل انہی contracts پر calculated flat 50% baseline کے ساتھ رکھا گیا ہے۔

استفسار کریںہر underlying کے لحاظ سے market کی بیان کردہ probability کا Brier score
ہر عدد کے پیچھے موجود درست SQL
WITH settle AS
(
    SELECT
        underlying_symbol                AS sym,
        date                             AS settle_date,
        any(toFloat64(underlying_close)) AS settle_px
    FROM global_markets.options_greeks
    WHERE underlying_symbol IN ('SPY', 'AAPL', 'MSFT', 'NVDA', 'KO', 'TSLA')
      AND date >= '2025-01-01'
      AND date <  '2026-08-01'
    GROUP BY sym, settle_date
),
scored AS
(
    SELECT
        g.underlying_symbol                             AS symbol,
        abs(toFloat64(g.delta))                         AS stated,
        startsWith(lower(toString(g.option_type)), 'c') AS is_call,
        if(is_call,
           s.settle_px > toFloat64(g.strike_price),
           s.settle_px < toFloat64(g.strike_price))     AS finished_itm
    FROM global_markets.options_greeks AS g
    INNER JOIN settle AS s
        ON s.sym = g.underlying_symbol AND s.settle_date = g.expiration_date
    WHERE g.underlying_symbol IN ('SPY', 'AAPL', 'MSFT', 'NVDA', 'KO', 'TSLA')
      AND g.date >= '2025-01-01'
      AND g.date <  '2026-06-01'
      AND g.expiration_date <= '2026-07-31'
      AND g.days_to_expiry BETWEEN 28 AND 35
      AND g.iv_converged = 1
      AND g.volume > 0
      AND abs(g.delta) > 0.02
      AND abs(g.delta) < 0.98
)
SELECT
    symbol,
    round(avg((stated - finished_itm) * (stated - finished_itm)), 4) AS market_brier,
    round(avg((0.5 - finished_itm) * (0.5 - finished_itm)), 4)       AS coin_flip_brier,
    formatReadableQuantity(count())                                  AS graded_contracts
FROM scored
GROUP BY symbol
ORDER BY market_brier
Run this yourself

NVDA نے 28.54 thousand graded contracts پر 0.1122 score حاصل کیا، جبکہ اسی set پر flat baseline کا score 0.25 تھا۔ ان 6 ناموں میں سب سے کمزور نام SPY بھی 0.1375 پر آتا ہے۔ یہاں options کوئی جادو نہیں کرتے۔ Deep out-of-the-money contracts کے deltas تقریباً 0.02 ہوتے ہیں اور یہ زیادہ تر worthless expire ہوتے ہیں۔ اس لیے ان کے بارے میں درست forecast کرنا آسان ہوتا ہے، اور یہی آسانی اس number میں شامل ہے۔ یہی بنیادی وجہ ہے کہ اکیلا Brier score تقریباً کچھ نہیں بتاتا۔

ایک ہی forecaster مختلف سوالات پر مختلف اسکور حاصل کرتا ہے

ایک ہی طریقۂ کار کو سوال کے حل ہونے تک باقی مدت کے لحاظ سے تقسیم کریں؛ اس صورت میں اس کے تحت اسکور بدلتا رہتا ہے۔

استفسار کریںexpiry horizons کے دوران market کا Brier score، SPY
ہر عدد کے پیچھے موجود درست SQL
WITH settle AS
(
    SELECT
        date                             AS settle_date,
        any(toFloat64(underlying_close)) AS settle_px
    FROM global_markets.options_greeks
    WHERE underlying_symbol = 'SPY'
      AND date >= '2025-01-01'
      AND date <  '2026-08-01'
    GROUP BY date
),
scored AS
(
    SELECT
        multiIf(g.days_to_expiry <=   7, 1,
                g.days_to_expiry <=  14, 2,
                g.days_to_expiry <=  30, 3,
                g.days_to_expiry <=  60, 4,
                g.days_to_expiry <= 120, 5,
                6)                                      AS horizon_rank,
        abs(toFloat64(g.delta))                         AS stated,
        startsWith(lower(toString(g.option_type)), 'c') AS is_call,
        if(is_call,
           s.settle_px > toFloat64(g.strike_price),
           s.settle_px < toFloat64(g.strike_price))     AS finished_itm
    FROM global_markets.options_greeks AS g
    INNER JOIN settle AS s ON s.settle_date = g.expiration_date
    WHERE g.underlying_symbol = 'SPY'
      AND g.date >= '2025-01-01'
      AND g.date <  '2026-06-01'
      AND g.expiration_date <= '2026-07-31'
      AND g.days_to_expiry BETWEEN 1 AND 250
      AND g.iv_converged = 1
      AND g.volume > 0
      AND abs(g.delta) > 0.02
      AND abs(g.delta) < 0.98
)
SELECT
    multiIf(horizon_rank = 1, '1 to 7 days',
            horizon_rank = 2, '8 to 14 days',
            horizon_rank = 3, '15 to 30 days',
            horizon_rank = 4, '31 to 60 days',
            horizon_rank = 5, '61 to 120 days',
            '121 to 250 days')                                       AS horizon,
    round(avg((stated - finished_itm) * (stated - finished_itm)), 4) AS market_brier,
    round(avg((0.5 - finished_itm) * (0.5 - finished_itm)), 4)       AS coin_flip_brier,
    count()                                                          AS sample_size
FROM scored
GROUP BY horizon_rank
ORDER BY horizon_rank
Run this yourself

مارکیٹ کا delta ان contracts پر 0.1084 رہا جن کے ختم ہونے میں 1 to 7 days باقی تھے، جبکہ ان contracts پر 0.1218 رہا جن کے ختم ہونے میں 121 to 250 days باقی تھے۔ forecaster بھی وہی تھا اور method بھی وہی، مگر سوالات کے دو مختلف مجموعے تھے۔ مستقل 50% baseline پہلی row میں 0.25 اور آخری row میں 0.25 پر ہے۔ یوں یہ ہر horizon میں واحد مستقل reference بنتا ہے۔ دو forecasters کے درمیان کسی بھی comparison کے لیے ضروری ہے کہ وہ ایک ہی window کے دوران انہی سوالات پر جانچے جائیں؛ بصورتِ دیگر skill کے بجائے سوالات کی دشواری کا موازنہ ہو رہا ہوگا۔

موزوں scoring rules کیوں اہم ہیں

Mean absolute error، یعنی آپ کے بتائے ہوئے probability اور حقیقی outcome کے درمیان سادہ فاصلے کی اوسط، بظاہر ایک معقول متبادل لگتا ہے، مگر یہ غلط طور پر اسکور کرتا ہے۔ فرض کریں آپ واقعی سمجھتے ہیں کہ کسی event کے ہونے کا امکان 70% ہے۔ 70% بتانے پر آپ کی متوقع absolute error یہ ہوگی: 0.7 x 0.3 + 0.3 x 0.7 = 0.42۔ اس کے بجائے 100% بتائیں تو یہ کم ہو کر 0.7 x 0 + 0.3 x 1 = 0.30 رہ جاتی ہے۔ Absolute error کے تحت ایماندار اندازہ آپ کے لیے نقصان دہ ہے، اور جو metric اعتماد کو بڑھا چڑھا کر بیان کرنے پر فائدہ دے، وہ forecasting کی درست پیمائش نہیں کر رہا۔

Brier score میں یہ خامی نہیں ہے۔ 70% کا یقین ہو اور آپ 70% بتائیں تو آپ کا متوقع score یہ ہوگا: 0.7 x 0.09 + 0.3 x 0.49 = 0.21۔ 100% بتانے پر یہ بڑھ کر 0.30 ہو جاتا ہے۔ 60% بتانے پر یہ 0.22 ہو جاتا ہے۔ کم ترین score عین اسی number پر حاصل ہوتا ہے جس پر آپ کو یقین ہوتا ہے۔ ایسی خصوصیت رکھنے والے rule کو proper کہا جاتا ہے، اور یہی وجہ ہے کہ forecasting tournaments میں Brier default بن گیا۔

Log score دوسرا عام proper rule ہے: جس outcome کے واقع ہونے کا امکان آپ نے بتایا، اس probability کا natural log لیں، پھر sign تبدیل کر دیں۔ کسی واقع ہونے والے event کے لیے 1% بتانے کی لاگت 4.6 آتی ہے، جبکہ 0% بتانے کی لاگت infinity ہوتی ہے۔ فرضی ten-forecast log پر یہ flat baseline کے 0.693 کے مقابلے میں 0.483 بنتا ہے۔ Brier score صفر اور ایک کے درمیان رہتا ہے، اس لیے scorecard کے طور پر زیادہ فطری محسوس ہوتا ہے۔ Log score کی کوئی بالائی حد نہیں، اس لیے یہ ایسی grading کے لیے موزوں ہے جس میں extreme outcomes کا risk اہم ہو۔

ایونٹ کنٹریکٹس کے لیے اس کا مطلب

ایسا event contract جو کسی واقعے کے ہونے پر $1 اور نہ ہونے پر $0 ادا کرتا ہے، ایسی قیمت پر trade ہوتا ہے جو پہلے ہی ایک probability ظاہر کرتی ہے۔ باسٹھ سینٹ، spread اور fees نکالنے سے پہلے، 62% forecast کے برابر ہے۔ ہمارا event contract prices کو probabilities میں تبدیل کرنے کا guide اس conversion کی وضاحت کرتا ہے، جبکہ event contracts کیسے settle ہوتے ہیں یہ بتاتا ہے کہ contract کی اپنی زبان میں “یہ واقعہ ہوا” سے کیا مراد ہے۔

یہ قیمت ایک ایسی forecast ہے جس کا public track record اور settlement date موجود ہے۔ اسی لیے یہ وہ benchmark بنتی ہے جس سے آپ کے اپنے log کو بہتر کارکردگی دکھانی ہوگی۔ اسی مدت کے دوران انہی سوالات پر اپنی forecasts کو score کریں۔ اگر کسی trader کا Brier score اس قیمت کے Brier score سے زیادہ ہو تو اس سوالات کے مجموعے پر اس کی کوئی measured edge نہیں، چاہے trade کے ساتھ منسلک narrative کتنا ہی مضبوط کیوں نہ ہو۔ یہی test sports odds پر بھی لاگو ہوتا ہے، جب آپ betting odds سے vig نکال دیں، اور rate markets پر بھی، جہاں Fed rate odds معلوم resolution day والے سوال کے لیے ایک تاریخ متعین probability فراہم کرتی ہیں۔

یہ panels market کی درجہ بندی کیسے کرتے ہیں

Delta ہر contract کے لیے روزانہ کے options greeks record سے حاصل کیا جاتا ہے۔ صرف وہی contracts شامل کیے جاتے ہیں جن میں observation day پر volume موجود ہو اور جن کے لیے volatility solve converged ہو۔ Outcome کا تعین contract کی expiration date پر underlying کی closing price سے کیا جاتا ہے: call اس وقت in the money شمار ہوتا ہے جب closing price strike سے اوپر ہو، جبکہ put اس وقت جب closing price strike سے نیچے ہو۔ حقیقی settlement، close کے بعد ہونے والے exercise decision کے ذریعے ہوتا ہے، اس لیے strike کے چند pennies کے اندر pinned contracts اس simplification کے برخلاف settle ہو سکتے ہیں۔ ان panels میں شامل ہر contract پہلے ہی expire ہو چکا ہے، اور طویل مدت والے buckets لازماً window میں پہلے کی observation dates سے data لیتے ہیں۔ اگر observation date اور expiry کے درمیان share split ہو جائے تو strike اور settlement price مختلف scales پر آ جائیں گے۔ یہی ایک اور وجہ ہے کہ ہر bucket کے ساتھ اس کا sample count بھی دیا جاتا ہے۔

Delta حقیقی دنیا کی probability کے بجائے risk-neutral probability کا تخمینہ پیش کرتا ہے۔ دونوں میں فرق options prices میں شامل risk premium کی وجہ سے ہوتا ہے۔ Calibration table اسی فرق کو ناپنے کا ذریعہ ہے، بجائے اس کے کہ اسے نظرانداز کر دیا جائے۔

عمومی سوالات

کیا کم Brier score بہتر ہوتا ہے؟

جی ہاں۔ Brier score غلطی کی پیمائش ہے، اس لیے 0 بہترین ریکارڈ اور 1 بدترین ممکنہ نتیجہ ہے۔ 1 اس وقت حاصل ہوتا ہے جب ہر سوال کے لیے 100% امکان بتایا جائے، مگر کوئی بھی واقعہ پیش نہ آئے۔ ہر سوال کے جواب میں 50% کہنے سے حاصل ہونے والے score کو 0.25 سے کم کوئی بھی score بہتر سمجھا جاتا ہے۔

اچھا Brier score کیا ہوتا ہے؟

اس کے لیے کوئی عالمی طور پر قابلِ قبول عدد نہیں، کیونکہ score کا انحصار سوالات کی مشکل پر ہوتا ہے۔ کل بارش کی پیش گوئی میں 0.10 حاصل کرنے والے موسمی forecaster اور قریبی انتخابات کی پیش گوئی میں 0.18 حاصل کرنے والے سیاسی forecaster کا باہمی تقابل نہیں کیا جا سکتا۔ Scores کا موازنہ صرف ان forecasters کے درمیان کریں جو ایک ہی مدت کے دوران ایک ہی سوالات کے جواب دے رہے ہوں۔

0.25 کا Brier score کیا ظاہر کرتا ہے؟

یہ اس forecaster کا score ہے جو ہر سوال کے جواب میں 50% کہتا ہے، کیونکہ نتیجہ کچھ بھی ہو، ہر squared miss پھر 0.25 بنتی ہے۔ ہاں یا نہیں والے سوالات کے مجموعے کے لیے یہ معیاری no-information benchmark ہے۔ تاہم اگر سوالات کے مجموعے میں ایک جواب کا تناسب واضح طور پر زیادہ ہو تو اس کے بجائے base rate کو benchmark بنانا چاہیے۔

Brier score، log score سے کس طرح مختلف ہے؟

دونوں proper scoring rules ہیں۔ اس کا مطلب ہے کہ score اس وقت کم سے کم ہوتا ہے جب آپ وہی probability بیان کریں جس پر آپ واقعی یقین رکھتے ہیں۔ Brier score غلطی کو square کرتا ہے اور 0 سے 1 کے درمیان رہتا ہے۔ log score پُراعتماد مگر غلط پیش گوئیوں کو کہیں زیادہ سخت سزا دیتا ہے، اور کسی ایسے واقعے کے لیے 0% کہنا جو بعد میں پیش آ جائے، infinity کی لاگت رکھتا ہے۔

کیا option delta کو probability کے طور پر پڑھا جا سکتا ہے؟

delta کی absolute value اس market-implied probability کے قریب ہوتی ہے کہ option in the money ختم ہوگا۔ یہ real-world probability کے بجائے risk-neutral probability ہوتی ہے۔ اوپر موجود panels اسے forecast کے طور پر grade کرتے ہیں: ایک محور پر بیان کردہ delta اور دوسرے محور پر ان contracts کا حصہ ہوتا ہے جو حقیقت میں in the money ختم ہوئے۔


یہاں موجود ہر panel اپنے عین SQL کے ساتھ فراہم کیا گیا ہے، جو اس کے نیچے موجود ہوتا ہے۔ اس لیے grading کو line by line audit کیا جا سکتا ہے۔ انہی سوالات پر market کی forecast کے مقابلے میں اپنی forecast log کو score کرنے کے لیے Strasmore terminal پر plain English میں اعداد طلب کریں۔

#prediction markets#forecasting#brier score#calibration#event contracts