Rust-এ QuantLib: libitofin এবং এর ব্যবহারের নিয়ম

Rust-এ QuantLib হলো libitofin-এর এক লাইনের বর্ণনা: এটি QuantLib-এর একটি পোর্ট। QuantLib হলো C++ লাইব্রেরি, যা 2000-এর দশকের শুরু থেকে ডেরিভেটিভস প্রাইসিংয়ের জন্য ওপেন সোর্স রেফারেন্স হিসেবে ব্যবহৃত হয়ে আসছে। এই লাইব্রেরিটিকে Rust-এ রূপান্তর করা হয়েছে এবং এর ওপর itofin নামে একটি Python প্যাকেজ রয়েছে। আগস্ট 2026 পর্যন্ত, প্রকল্পটি নিজেকে 1.0-পূর্ববর্তী (pre-1.0) সংস্করণ হিসেবে বর্ণনা করে এবং এই লেবেলটি এর ব্যবহারের প্রতিটি ব্যবহারিক দিককে প্রভাবিত করে। একটি প্রাইসিং লাইব্রেরি তার ফর্মুলার চারপাশে থাকা মেকানিজমের মাধ্যমে নিজের গুরুত্ব প্রমাণ করে এবং যেকোনো প্রোগ্রামিং ভাষাতেই এই মেকানিজম তৈরির কাজ একই।

একটি প্রাইসিং লাইব্রেরি আপনাকে যা দেয়, যা স্প্রেডশিট ফর্মুলা দেয় না

স্প্রেডশিটে একটি Black-Scholes সেলে পাঁচটি ইনপুট দিলে তা একটি প্রাইস প্রদান করে। ফর্মুলাটি এখানে সহজ অংশ। এর চারপাশে চারটি স্তর থাকে এবং এই স্তরগুলোই হলো লাইব্রেরি।

টার্ম স্ট্রাকচার (Term structures)। ডিসকাউন্ট রেট হলো ম্যাচুরিটি বা মেয়াদ অনুযায়ী একটি কার্ভ, যেখানে পয়েন্টগুলোর মধ্যবর্তী গ্যাপের জন্য ইন্টারপোলেশন রুল থাকে যা বাস্তবে কোট করা হয়। নিচের প্যানেলটি হলো কাঁচামাল: একটি নির্দিষ্ট তারিখে কোট করা ট্রেজারি টেনর।

SELECT
    arrayElement(tenors, i)                  AS tenor,
    round(arrayElement(rates, i), 2)         AS yield_pct,
    formatDateTime(curve_date, '%b %e, %Y')  AS as_of
FROM
(
    SELECT
        date AS curve_date,
        ['1 month', '3 months', '6 months', '1 year', '2 years', '3 years',
         '5 years', '7 years', '10 years', '20 years', '30 years']         AS tenors,
        [toFloat64(yield_1_month), toFloat64(yield_3_month), toFloat64(yield_6_month),
         toFloat64(yield_1_year),  toFloat64(yield_2_year),  toFloat64(yield_3_year),
         toFloat64(yield_5_year),  toFloat64(yield_7_year),  toFloat64(yield_10_year),
         toFloat64(yield_20_year), toFloat64(yield_30_year)]                AS rates,
        arrayJoin(range(1, 12))                                            AS i
    FROM global_markets.treasury_yields
    WHERE date = (SELECT max(date) FROM global_markets.treasury_yields)
)
WHERE yield_pct > 0
ORDER BY i

Aug 10, 2026 অনুযায়ী, কোট করা কার্ভে 7 টি টেনর ছিল, যা 3.79% থেকে 1 month পর্যন্ত এবং 5.25% থেকে 30 years পর্যন্ত বিস্তৃত। স্প্রেডশিটে এটি একটি লুকআপ এবং হার্ডকোডেড 4% দিয়ে সমাধান করা হয়। একটি লাইব্রেরিতে এটি একটি কার্ভ অবজেক্টের মাধ্যমে করা হয়, যা প্রতিটি ইন্সট্রুমেন্টের প্রাইসিং নির্ধারণ করে। এটি একটি নির্দিষ্ট ইন্টারপোলেশন (জিরো রেটের ওপর লিনিয়ার, ডিসকাউন্ট ফ্যাক্টরের ওপর লগ-লিনিয়ার, মনোতোন স্প্লাইন) এবং শেষ পয়েন্টের পরের জন্য একটি নির্দিষ্ট এক্সট্রাপোলেশন পলিসি অনুসরণ করে। সেই একটি অবজেক্টকে এক বেসিস পয়েন্ট পরিবর্তন করলে বইয়ের প্রতিটি সেনসিটিভিটি তার সাথে সামঞ্জস্য রেখে পরিবর্তিত হয়।

ডে-কাউন্ট কনভেনশন (Day-count conventions)। সুদ বছরের একটি ভগ্নাংশের ওপর অর্জিত হয় এবং সেই ভগ্নাংশের সংজ্ঞাটি ইন্সট্রুমেন্টের সাথে যুক্ত একটি কনভেনশন। Actual/360 পদ্ধতিতে অতিক্রান্ত দিনগুলোকে 360 দিয়ে ভাগ করা হয়। Actual/365 পদ্ধতিতে 365 দিয়ে ভাগ করা হয়। 30/360 পরিবার ধরে নেয় যে প্রতিটি মাসে 30 দিন থাকে। Business/252 পদ্ধতিতে 252 দিনের বছরের বিপরীতে ট্রেডিং সেশন গণনা করা হয়, যার জন্য ছুটির দিনসহ একটি প্রকৃত এক্সচেঞ্জ ক্যালেন্ডারের প্রয়োজন হয়। ধরুন, 90 দিনের জন্য 5% হারে 1 মিলিয়ন ডলার ঋণ নেওয়া হয়েছে: একই ট্রেডে actual/360 পদ্ধতিতে 12,500 ডলার এবং actual/365 পদ্ধতিতে 12,329 ডলার সুদ অর্জিত হয়। নিচের প্যানেলটি দেখায় কেন বিজনেস-ডে বেসিসের জন্য ডিভাইজরের পরিবর্তে ক্যালেন্ডারের প্রয়োজন।

SELECT
    formatDateTime(toStartOfMonth(date), '%Y-%m')      AS month,
    countDistinct(date)                                AS trading_days,
    toUInt8(toDayOfMonth(toLastDayOfMonth(max(date)))) AS calendar_days
FROM global_markets.stocks_daily_aggs
WHERE ticker = 'SPY'
  AND date >= toStartOfMonth(today() - 365)
  AND date <  toStartOfMonth(today())
GROUP BY month
ORDER BY month

12 মাসের পর্যবেক্ষণে, 2026-07-এ 22 টি সেশন ছিল, যা 31 ক্যালেন্ডার দিনের বিপরীতে। কোনো গাণিতিক নিয়ম এই প্রথম সংখ্যাটি তৈরি করে না। এটি একটি হলিডে ক্যালেন্ডার থেকে আসে এবং প্রতিটি মাসের নিজস্ব উত্তর থাকে। একটি লাইব্রেরি প্রতিটি ভেন্যু এবং দেশের জন্য সেই ক্যালেন্ডারগুলো সরবরাহ করে; স্প্রেডশিটে আপনাকে সেগুলো নিজে রক্ষণাবেক্ষণ করতে হয়।

ক্যালিব্রেশন মেকানিজম (Calibration machinery)। মডেল প্যারামিটারগুলো কোথাও কোট করা থাকে না। আপনি কোটগুলোর একটি পুরো সারফেস জুড়ে বাজারমূল্যের সাথে মডেলের দাম মিলিয়ে এগুলো নির্বাচন করেন এবং সারফেস পরিবর্তনের সাথে সাথে পুনরায় ফিট করেন। এটি একটি বাউন্ডেড লিস্ট-স্কোয়ার্স সমস্যা এবং লাইব্রেরিটি এর চারপাশে লুপ সরবরাহ করে: একটি Levenberg-Marquardt অপ্টিমাইজার, প্যারামিটার ট্রান্সফর্ম যা কোনো হার্ড কনস্ট্রেইন্ট ছাড়াই ভ্যারিয়েন্সকে পজিটিভ রাখে, কোট সেটের ওপর একটি কস্ট ফাংশন এবং কনভারজেন্স ক্রাইটেরিয়া যা ভুল হলে চুপচাপ শুরুর অনুমান ফেরত না দিয়ে স্পষ্টভাবে ব্যর্থতার সংকেত দেয়।

একটি নিউমেরিকস লেয়ার (A numerics layer)। সবকিছুর নিচে লিনিয়ার অ্যালজেব্রা এবং ইন্টিগ্রেশন থাকে। QR এবং SVD ডিকম্পোজিশন ফিট থেকে উৎপন্ন সিস্টেমগুলো সমাধান করে, কোয়াড্র্যাচার এবং ফুরিয়ার ইন্টিগ্রেশন সেই মডেলগুলোর প্রাইসিং করে যাদের ফর্মুলা ইন্টিগ্রাল, এবং রুট ফাইন্ডার ইমপ্লাইড ভোলাটিলিটি বের করে। এই স্তরটি একঘেয়ে, কিন্তু ঠিক এই স্তরটিই ভুলভাবে রি-ইমপ্লিমেন্ট করা হয়। এর ক্লাসিক সংস্করণ হলো হাতে তৈরি নিউটন সলভার, যা লিকুইড অ্যাট-দ্য-মানি কোটগুলোতে কনভার্জ করে কিন্তু ডিপ আউট-অফ-দ্য-মানি কোটগুলোতে ভুল ফলাফল দেয়। এর কাছাকাছি আরেকটি হলো ম্যাট্রিক্স ইনভার্স, যা নিয়ার-সিঙ্গুলার ফিটে নির্ভুলতা হারায় এবং এমন প্যারামিটার দেয় যা দেখতে পুরোপুরি সঠিক মনে হয়। আপনি যদি স্ক্র্যাচ থেকে মেন্টাল মডেল তৈরি করেন, তবে যেকোনো লাইব্রেরির API রেফারেন্সের চেয়ে একটি ওপেন সোর্স কোয়ান্ট ট্রেডিং বই ভালো শুরুর পয়েন্ট হতে পারে।

libitofin কী এবং এটি কি Rust-এ QuantLib?

হ্যাঁ, গুরুত্বপূর্ণ দিক থেকে এটি তাই। এটি QuantLib-এর ডিজাইনের একটি Rust পোর্ট এবং প্রকল্পটি জানায় যে এটি QuantLib-এর নিজস্ব টেস্ট সুইটের বিপরীতে পরীক্ষিত। একটি নিউমেরিকস লাইব্রেরি পোর্ট করার এটিই সৎ উপায়: ফলাফলগুলো রেফারেন্স ইমপ্লিমেন্টেশনের বিপরীতে যাচাই করা হয়, উত্তরের প্রত্যাশার বিপরীতে নয়। Python পাথটি itofin নামে একটি প্যাকেজ, তাই একটি Python প্রসেস C++ টুলচেইন ছাড়াই Rust ইঞ্জিনে পৌঁছাতে পারে।

যে লেবেলটি বেশি গুরুত্বপূর্ণ তা হলো 1.0-পূর্ববর্তী (pre-1.0)। Rust-এর ভার্সনিং কনভেনশন অনুযায়ী, একটি 0.x রিলিজ মাইনর ভার্সনগুলোর মধ্যে কোনো সামঞ্জস্যের প্রতিশ্রুতি দেয় না: 0.4 থেকে 0.5-এ যেকোনো কিছু রিনেম, মুভ বা ডিলিট করা হতে পারে। API-কে একটি চলমান লক্ষ্য হিসেবে বিবেচনা করুন এবং কিছু অভ্যাস মেনে চলুন।

• আপনার lockfile-এ একটি নির্দিষ্ট ট্যাগ করা রিলিজ পিন করুন এবং ইচ্ছাকৃতভাবে আপগ্রেড করুন, যেখানে আপনার নিজস্ব টেস্ট সুইট গেট হিসেবে কাজ করবে।
• লাইব্রেরির টাইপগুলোর চারপাশে আপনার নিজস্ব একটি পাতলা র‍্যাপার রাখুন, যাতে রিনেমের ক্ষেত্রে 40টি ফাইলের পরিবর্তে একটি ফাইলে পরিবর্তন করলেই হয়।
• লাইব্রেরির ভার্সনটি তার উৎপাদিত সংখ্যার পাশে রেকর্ড করুন, যাতে কোনো অমিল হলে তা বাজারের পরিবর্তে আপগ্রেডের দিকে নির্দেশ করে।
• প্রোডাকশন মার্জিন, কোল্যাটারাল এবং রেগুলেটরি রিস্কের সংখ্যাগুলো এমন কিছুর ওপর রাখুন যা 1.0 ভার্সন আসার আগ পর্যন্ত সামঞ্জস্যের প্রতিশ্রুতি বহন করে।

এর কোনোটিই প্রকল্পের সমালোচনা নয়। 1.0-পূর্ববর্তী একটি সঠিক স্ব-বর্ণনা এবং একটি বিশাল লাইব্রেরির তরুণ পোর্টের জন্য এটিই সঠিক অবস্থান। ব্যর্থতার কারণ হতে পারে যদি কোনো পাঠক এটিকে একটি ড্রপ-ইন QuantLib সোয়াপ হিসেবে বিবেচনা করে এবং মাইনর রিলিজে সিগনেচার পরিবর্তনের সম্মুখীন হয়। ইন্সটলেশন নির্দেশাবলীও ভার্সনের সাথে পরিবর্তিত হয় এবং cargo ও pip উভয়েরই যেকোনো কিছু রেজলভ করার জন্য নেটওয়ার্ক অ্যাক্সেস প্রয়োজন, তাই ব্লগ পোস্ট থেকে কপি করা স্নিপেটের পরিবর্তে আপনি যে ট্যাগটি পিন করতে চান তার README পড়ুন।

Python, একটি কম্পাইলড ইঞ্জিন, নাকি Rust?

দুটি প্রশ্ন এটি নির্ধারণ করে এবং কোনোটিই পছন্দের বিষয় নয়। আপনি প্রতি সেকেন্ডে কতবার রিপ্রাইস করেন এবং আপনার সংখ্যাগুলো কি আলাদা প্রসেস জুড়ে মিলতে হবে? চেইন সাইজ প্রথম প্রশ্নের স্কেল নির্ধারণ করে।

WITH (SELECT max(date) FROM global_markets.options_greeks) AS last_session
SELECT
    underlying_symbol                      AS symbol,
    countDistinct(ticker)                  AS contracts_priced,
    formatDateTime(max(date), '%b %e, %Y') AS as_of
FROM global_markets.options_greeks
WHERE date = last_session
  AND underlying_symbol IN ('SPY', 'AAPL', 'NVDA', 'MSFT', 'KO')
  AND volume > 0
GROUP BY symbol
ORDER BY contracts_priced DESC

Aug 11, 2026 তারিখে, SPY-এ একটি সেশনে 5336 টি স্বতন্ত্র কন্ট্রাক্ট ট্রেড হয়েছে, যা KO-এর জন্য 360-এর বিপরীতে। ওয়াইড চেইন একবার প্রাইসিং করা কোনো ব্যাপারই নয়। প্রতিটি কন্ট্রাক্টে পাঁচটি সেনসিটিভিটিসহ, প্রতিটি কোট আপডেটে, আন্ডারলাইংয়ের একটি বই জুড়ে এটি প্রাইসিং করা ভিন্ন প্রোগ্রাম এবং ভিন্ন সীমাবদ্ধতার বিষয়।

যখন লুপটি মিনিটে হাজার হাজার ভ্যালুয়েশনে পরিমাপ করা হয় এবং আশেপাশের কাজগুলো গবেষণা, বিশ্লেষণ বা দিনের শেষের মার্কিং হয়, তখন একটি প্রতিষ্ঠিত লাইব্রেরিসহ Python-এ থাকুন। QuantLib-এর নিজস্ব Python বাইন্ডিংগুলো পরিপক্ক পছন্দ: একই C++ ইঞ্জিন, সবচেয়ে বিস্তৃত ইন্সট্রুমেন্ট কভারেজ এবং বছরের পর বছর প্রোডাকশন ব্যবহারের অভিজ্ঞতা। গবেষণার কোডে গতি খুব কমই সীমাবদ্ধতা তৈরি করে; কভারেজ এবং নির্ভুলতাই আসল।

যখন লুপটি হট থাকে এবং আশেপাশের কোডটি নয়, তখন Python থেকে একটি কম্পাইলড ইঞ্জিন কল করুন। এখানে দেখার বিষয় হলো বাউন্ডারি। Python থেকে প্রতি-কন্ট্রাক্ট কল প্রতিটি ক্রসিংয়ে ওভারহেড তৈরি করে এবং এর সমাধান হলো ইঞ্জিনকে একটি অ্যারে দেওয়া এবং একটি অ্যারে ফেরত নেওয়া। এটি সেই জায়গা যেখানে itofin, QuantLib-Python-এর পাশাপাশি কাজ করছে।

Rust-এ লিখুন যখন প্রাইসিং লুপটিই পণ্য: একটি কোটিং সার্ভিসের ভেতরে প্রাইসার, এমন শিডিউলে রিস্ক রান যা আপনি মিস করতে পারেন না, অথবা এমন বক্সে বাইনারি পাঠানো যেখানে Python নেই। দ্বিতীয় প্রশ্নটিও এখানে প্রযোজ্য। ফ্লোটিং পয়েন্ট ফলাফল অপারেশনের ক্রমের ওপর নির্ভর করে, তাই একই মডেল দুইবার ইমপ্লিমেন্ট করলে শেষ ডিজিটগুলোতে অমিল হতে পারে এবং একটি রিসার্চ নোটবুক যা প্রোডাকশন সার্ভিসের সাথে মেলে না তা এক সপ্তাহের ফরেনসিক কাজের সমান। উভয় দিক থেকে একটি ইঞ্জিন ব্যবহার করলে এই ধরনের অমিল দূর হয়, যা যেকোনো ভাষায় লেখা বাইন্ডিংসহ একটি কম্পাইলড কোরের জন্য টেকসই যুক্তি। একই প্রবৃত্তি কৌশলের কাজের ক্ষেত্রেও প্রযোজ্য, যেমনটি একটি পুনরুৎপাদনযোগ্য ব্যাকটেস্ট দেখায়।

ক্যালিব্রেশন টার্গেট আসলে কোথায় থাকে

ক্যালিব্রেশনের জন্য ফিট করার মতো কিছু প্রয়োজন এবং সেটি হলো বাজার-ইমপ্লাইড ভোলাটিলিটির একটি সারফেস। এর রুট-ফাইন্ডিং দিকটি কিভাবে ইমপ্লাইড ভোলাটিলিটি গণনা করা হয়-এ কভার করা হয়েছে। নিচের আকৃতিটি হলো যা একটি মডেলকে মেলাতে হবে।

SELECT
    multiIf(days_to_expiry <=   7, '0 to 7 days',
            days_to_expiry <=  30, '8 to 30 days',
            days_to_expiry <=  60, '31 to 60 days',
            days_to_expiry <= 120, '61 to 120 days',
            days_to_expiry <= 240, '121 to 240 days',
                                   '241 days or more') AS dte_bucket,
    round(avg(implied_volatility) * 100, 1)            AS iv_pct,
    countDistinct(ticker)                              AS contracts
FROM global_markets.options_greeks
WHERE underlying_symbol = 'AAPL'
  AND date >= today() - 10
  AND days_to_expiry >= 0
  AND iv_converged = 1
  AND volume > 0
  AND abs(toFloat64(strike_price) / toFloat64(underlying_close) - 1) < 0.05
GROUP BY dte_bucket
ORDER BY min(days_to_expiry)

মানি-এর কাছাকাছি, 0 to 7 days বাকেটে AAPL কন্ট্রাক্টগুলো পর্যবেক্ষণের সেশনগুলোতে গড়ে 29.6% ইমপ্লাইড ভোলাটিলিটি ছিল, যা 241 days or more-এ 29.3%-এর বিপরীতে। একটি ভোলাটিলিটি প্যারামিটার বহনকারী মডেল একই সাথে দুটি পয়েন্টে বসতে পারে না, যে কারণে ভোলাটিলিটি টার্ম স্ট্রাকচারসহ মডেলগুলোর অস্তিত্ব রয়েছে। এই ধরনের সারফেসে একটি ফিট করা হলো ক্যালিব্রেশন ধাপ এবং ফিট করা মডেল থেকে যে সেনসিটিভিটিগুলো বেরিয়ে আসে তা হলো গ্রিকস, যা অপশন গ্রিকস ব্যাখ্যা করা হয়েছে-এ কভার করা হয়েছে।

FAQ

libitofin কি QuantLib-এর একটি ড্রপ-ইন রিপ্লেসমেন্ট?

না। আগস্ট 2026 পর্যন্ত এটি একটি 1.0-পূর্ববর্তী পোর্ট যা QuantLib-এর সারফেসের কিছু অংশ কভার করে এবং QuantLib-এর নিজস্ব টেস্ট সুইটের বিপরীতে ফলাফল যাচাই করে। QuantLib নিজেই, যা তার Python বাইন্ডিংয়ের মাধ্যমে পৌঁছানো যায়, প্রোডাকশনের কাজের জন্য আরও বিস্তৃত এবং স্থিতিশীল বিকল্প হিসেবে রয়ে গেছে।

একটি প্রাইসিং লাইব্রেরির জন্য 1.0-পূর্ববর্তী হওয়ার অর্থ কী?

Rust-এর ভার্সনিং কনভেনশন অনুযায়ী, একটি 0.x রিলিজ সামঞ্জস্যের কোনো প্রতিশ্রুতি দেয় না: পরবর্তী মাইনর ভার্সন যেকোনো কিছু রিনেম বা রিমুভ করতে পারে। বাস্তবে এর অর্থ হলো একটি নির্দিষ্ট ট্যাগ করা রিলিজ পিন করা এবং প্রতিটি আপগ্রেডে আপনার নিজস্ব টেস্ট সুইট পুনরায় চালানো।

libitofin ব্যবহার করার জন্য কি আমাকে Rust লিখতে হবে?

না। প্রকল্পটি itofin নামে একটি Python প্যাকেজ প্রকাশ করে, তাই ইঞ্জিনটি একটি সাধারণ Python প্রসেস থেকে কল করা যায়। Rust লেখা তখন প্রাসঙ্গিক হয় যখন প্রাইসিং লুপটিই সেই জিনিস যা আপনি শিপ করছেন।

একটি প্রাইসিং লাইব্রেরি আমাকে কী দেয় যা স্প্রেডশিট ফর্মুলা দেয় না?

সিঙ্গেল রেটের পরিবর্তে কার্ভ, প্রকৃত এক্সচেঞ্জ ক্যালেন্ডারসহ ডে-কাউন্ট কনভেনশন, একটি ক্যালিব্রেশন লুপ যা মডেল প্যারামিটারগুলোকে কোট করা মূল্যের সাথে ফিট করে এবং এই তিনটির নিচে একটি পরীক্ষিত নিউমেরিকস লেয়ার। ক্লোজড-ফর্ম ফর্মুলা কাজের একটি ছোট অংশ মাত্র।

প্রোগ্রামিং ভাষা কি অপশনের দাম পরিবর্তন করে?

গাণিতিকভাবে নয়। এটি পুনরুৎপাদনযোগ্যতা পরিবর্তন করে: ফ্লোটিং পয়েন্ট ফলাফল অপারেশনের ক্রমের ওপর নির্ভর করে, তাই একটি মডেলের দুটি ইমপ্লিমেন্টেশন শেষ ডিজিটগুলোতে অমিল হতে পারে। একই ইঞ্জিন থেকে গবেষণা এবং প্রোডাকশন চালানো সেই ব্যবধান দূর করে।

এখানে প্রতিটি প্যানেলের নিচে তার সঠিক SQL রয়েছে, তাই গণনা কীভাবে করা হয়েছে তা দেখতে একটি প্রসারিত করুন। একই কার্ভ, ক্যালেন্ডার এবং চেইনের প্রশ্নগুলো Strasmore টার্মিনালে সাধারণ ইংরেজিতে করা যেতে পারে।