search

Lumiwealth / quantstats_lumi

Apache License 2.0
82 stars 26 forks source link

Sharpe/Sortino period needs to be 252 for financial markets #30

Open Koha101 opened 5 months ago

Koha101 commented 5 months ago

The period has been changed from 252 in quantstats to 365 in quanstats_lumi, to correct the CAGR calculation, since it uses calendar days in its calculation. This breaks the sharpe and sortino calculations, since they use the sqrt(period), which should be the number of trading days, not calendar days, 252 for financial markets. The 365 number works for crypto, since that's available 365 days/year.

I propose the default should be 252 for sharpe and sortino, and 365 for CAGR. Additionally, it would be worth having 2 separate periods in reports.py, calendar_period and trading_period, to use the correct one on calls to the metrics, and expose the two periods in calls like reports.html().

grzesir commented 5 months ago

This makes a lot of sense. If you submit a pull request then I can add it to the project

Robert Grzesik 347-635-3416

On Tue, Apr 23, 2024 at 1:39 PM Koha101 @.***> wrote:

The period has been changed from 252 in quantstats to 365 in quanstats_lumi, to correct the CAGR calculation, since it uses calendar days in its calculation. This breaks the sharpe and sortino calculations, since they use the sqrt(period), which should be the number of trading days, not calendar days, 252 for financial markets. The 365 number works for crypto, since that's available 365 days/year.

I propose the default should be 252 for sharpe and sortino, and 365 for CAGR. Additionally, it would be worth having 2 separate periods in reports.py, calendar_period and trading_period, to use the correct one on calls to the metrics, and expose the two periods in calls like reports.html().

— Reply to this email directly, view it on GitHub https://github.com/Lumiwealth/quantstats_lumi/issues/30, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIYQK3NX7OZZRC3R5GXWGLY62METAVCNFSM6AAAAABGVMIQE2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2TSNBRGYYDIMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

jakewillms17 commented 3 months ago

I disagree with using 365 and 252 like this. Very simple fix for CAGR would be to just count the len(returns) to gather the number of days as opposed to the calendar calculation. Makes more sense IMO to standardize 252 as we are dealing with financial data.

jiema commented 4 weeks ago

252 is correct imo, and 365 is wrong. unless you are working with an asset traded 24/7 like bitcoin.