quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[U.Mutlu <um...@mu...>]

Ioannis Rigopoulos wrote on 09/11/23 11:47:
 > By the way, this is how my histogram of S(t) (for t = 1) simulated values
 > looks like when I used 100,000 time steps and 100,000 simulations. It is
 > clearly lognormal in shape.

Yes, it's lognormally. My values are lognormlly as well,
You just restate the obvious fact.

 > I am sure, if you do the same when time steps = 1,
 > you will get a normal distribution for S(t), which would prove
 > that time steps = 1 does not reproduce the theoretically expected
 > values for S(t).

Not true, simply from the fact that the set boundary is lognormally:
   -1SD: 74.08182206817179
   +1SD: 134.9858807576003
Ie. it's not symmetric (Gaussian, normally distributed) around the
initial mean (100), but is lognormally (and therefore unsymmetric).

FYI: in my other test program (that does not use QuantLib)
I get in such simulations exact results almost identical
to the expected theoretical results! So, your math and arguing is wrong, IMO.

You are too much fixated on timeSteps=1. Maybe you have
a much different understanding of what timeSteps really
means in practice. It's _not_ something like the number
of simulations that you simply can change and expect
to get the same result; no, it has a clearly defined context
and gives different results for different timeSteps.

And you haven't answered the question why you think it has
to be 68.27% for all timeSteps (which IMO is wrong).

For those interested, here are more details about the above said:
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548

And, I today did a brief summary of these ongoing discussions on GBM here:
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-5#post-5861919


Ioannis Rigopoulos wrote on 09/11/23 11:47:
> Our SDE for the evolution of S is:
>
> dS = μSdt + σSdw
>
> In your code you use:
>
>
> PathGenerator<RandomSequenceGenerator<MersenneBoxMuller>>
> gbmPathGenerator(gbm, t, timeSteps, gsg, false);
> const Path& samplePath = gbmPathGenerator.next().value;
>
> The PathGenerator::next().value is designed to return an array of numbers
> {S(T₁) , S(T₂) , ... , S(Tᵤ)}
>
> where
>
> u := timeSteps
>
> Δt := t/u
>
> Tᵢ := iΔt for i = 1,...,u
>
> It follows:
>
> Tᵤ = t = the final time when we are interested to know the simulated values of
> S (in your test you use t = 1).
>
> QuantLib builds the sequence {S(T₁) , S(T₂) , ... , S(Tᵤ)} incrementally
> through a total number of u steps by adding the quantity ΔS := μSΔt + σSΔw on
> the previous member of the sequence, with Δw := random number drawn from
> N~(0,Δt¹ᐟ²).
>
> The previous member of S(T₁) is assumed the T₀ = 0 and the initial value S(T₀)
> = S(0) is assumed deterministic and known.
>
> So, starting with the given S(T₀), QuantLib calculates the S(T₁) using the
> formula:
>
> S(T₁) := S(T₀) + μS(T₀)Δt + σS(T₀)Δw
>
> Then given the S(T₁) as calculated above, it proceeds to calculate S(T₂) as:
>
> S(T₂) := S(T₁) + μS(T₁)Δt + σS(T₁)Δw
>
> For simplicity I have used the same notation for the Δw in the equations
> above, but they are different.
>
> After u steps, the final value S(t) = S(Tᵤ) is calculated as:
>
> S(t) = S(Tᵤ) := S(Tᵤ₋₁) + μS(Tᵤ₋₁)Δt + σS(Tᵤ₋₁)Δw
>
> All equations above hold only in an approximate sense when Δt is finite.
>
> They are accurate only in a limiting sense as Δt → 0.
>
> It follows that the value S(t) will be calculated correctly only if Δt → 0,
> which is equivalent to u → ∞
>
> If you use u = 1 (i.e. one time step), you will still match the 68.27% rule
> when the 1SD interval is defined in accordance with a normal distribution
> because S(T₁) := S(T₀) + μS(T₀)Δt + σS(T₀)Δw corresponds to a normal
> distribution and if you build a histogram of all simulated values you will
> notice that S(T₁) is distributed normally, which is clearly not consistent
> with the SDE that predicts lognormal distribution.
>
> The correct procedure is of course to use a very large u and define the 1SD
> interval in accordance with a lognormal distribution, as I described in my
> previous email.
>
> Then you will get convergence to the 68.27% rule.
>
> By the way, this is how my histogram of S(t) (for t = 1) simulated values
> looks like when I used 100,000 time steps and 100,000 simulations. It is
> clearly lognormal in shape. I am sure, if you do the same when time steps = 1,
> you will get a normal distribution for S(t), which would prove that time steps
> = 1 does not reproduce the theoretically expected values for S(t).
>
> Ioannis
>
> On 9/11/2023 10:19 AM, U.Mutlu wrote:
>> Dear Ioannis Rigopoulos, I now analysed your table and
>> must say that you seem to have a much different expectation to,
>> and understanding of that table.
>>
>> The  values in your table for timeSteps > 1 can definitely
>> not be correct, b/c why do you think it has to be 68.27 for all timeSteps?
>> This is illogical b/c the more timeSteps the more the hitrate%
>> must be, like in my table. It saturates at about 84.93%
>>
>> Sorry, I have to retract my initial enthusiastic judment
>> of your work below, as it's fundamentally flawed & wrong,
>> and I should have been more careful when I quickly & briefly
>> inspected your posting in the early morning here.
>>
>> Since your results in the table for timeSteps > 1 are wrong,
>> then your formulas must be wrong too, so I had to stop my analysis right there.
>>
>> Please just answer why you think it has to be 68.27% for all timeSteps?
>>
>>
>> U.Mutlu wrote on 09/11/23 08:36:
>>> Mr. Ioannis Rigopoulos, that's a brilliant work by you. Thank you very much.
>>> I need some time to study and verify the reults, but it looks very good
>>> to solve the confusion and mystery I had experienced when I started this
>>> research some weeks ago.
>>> I'll try to replicate your results and will report later in detail here.
>>>
>>> Ioannis Rigopoulos wrote on 09/10/23 19:29:
>>>  > On a different topic, I do not understand your statement "/I've never seen
>>>  > that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>>>  > What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where
>>>
>>> Sorry for the consfusion, it just means the stock price (Sx after time t,
>>> ie. S(t) or S_t) for the lower boundary at -1SD and for the upper boundary at
>>> +1SD,
>>> ie. your "min of S(t)" and "max of S(t)" in your other posting.
>>> In future I'll use a more common term like yours, sorry.
>>>
>>> Thx
>>>
>>>
>>> Ioannis Rigopoulos wrote on 09/10/23 19:29:
>>>> Yes, I mean mu * t - 0.5 * sigma * sigma * t
>>>>
>>>> Are you sure, you also adjusted the boundaries corresponding to plus and
>>>> minus
>>>> 1 SD?
>>>>
>>>> I ran an Excel spreadsheet by modifying a spreadsheet I had published several
>>>> years ago at https://blog.deriscope.com/index.php/en/excel-value-at-risk that
>>>> uses the GeometricBrownianMotionProcess , albeit with the
>>>> PseudoRandom::rsg_type generator.
>>>>
>>>> At any case, I got convergence to 68.27% as I increased the number of time
>>>> steps and keeping the number of simulations fixed to 100,000, provided I used
>>>> the correct (Ito-adjusted) means, as below:
>>>>
>>>> As you see above, the "No Ito-adjusted" boundaries are 74.08 and 134.99, just
>>>> like those you use.
>>>>
>>>> The Ito-adjusted boundaries are 70.82 and 129.05 produced by shifting the
>>>> no-adjusted boundaries - in log terms - to the left by 0.5*sigma^2*t.
>>>>
>>>> The simulation results (percentage of values being within the min and max
>>>> boundaries) are below:
>>>>
>>>> As you see, the Ito-adjusted percentage reaches 68.30% for 100,000 time
>>>> steps,
>>>> which is close to the expected 68.27%.
>>>>
>>>> The No Ito-adjusted percentage seems instead to converge to a different value
>>>> around 67.73%
>>>>
>>>> On a different topic, I do not understand your statement "/I've never seen
>>>> that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>>>>
>>>> What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where m is
>>>> the mean of a normally distributed variable. This means that one needs to
>>>> calculate m in order to do the mentioned computation.
>>>>
>>>> If your starting point is an SDE like dS = S*mu*dt + S*sigma*dw, then
>>>> ln(S(t))
>>>> at any time t will be normally distributed with mean m = ln(S(0)) + mu*t -
>>>> 0.5*sigma^2*t , where the last term is a consequence of the Ito lemma.
>>>>
>>>> Do you have any reason to believe that the Ito lemma is somehow not valid so
>>>> that m = ln(S(0)) + mu*t?
>>>>
>>>> Ioannis
>>>>
>>>> On 9/10/2023 3:00 PM, U.Mutlu wrote:
>>>>
>>>>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>>>> > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)
>>>>>
>>>>> Thank you for your analysis.
>>>>> I guess you mean "mu * t - 0.5 * sigma * sigma * t",
>>>>> though in our example with t=1 it doesn't make any difference.
>>>>> It gives for timeSteps=1 this result:
>>>>>
>>>>> $ ./Testing_GBM_of_QuantLib.exe 1
>>>>> timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000
>>>>> sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : -1SD=70.822035
>>>>> +1SD=129.046162
>>>>> cHit=663067/1000000(66.307%)
>>>>>
>>>>> This is far from the expected value of 68.2689% for timeStep=1.
>>>>> So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)
>>>>>
>>>>> Cf. also the following showing similar results for GBM,
>>>>> which then was compared to the standard lognormal calculation:
>>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get computed with
>>>>> Ito's lemma applied.
>>>>>
>>>>>
>>>>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>>>>> Thank you for testing the BoxMullerGaussianRng code, which - as I wrote -
>>>>>> does
>>>>>> not seem to be used in other areas of the standard part of QuantLib.
>>>>>>
>>>>>> Your numerical results below ...
>>>>>>
>>>>>> indicate that the simulated values for ln(S(t)) produced with timeSteps = 1
>>>>>> are very likely normally distributed with mean (I use your notation)
>>>>>> ln(S(0))
>>>>>> + mu*t and standard deviation sigma * sqrt(t)
>>>>>>
>>>>>> This result _*is consistent*_ with:
>>>>>>
>>>>>> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>>>>>>
>>>>>> _*and*_
>>>>>>
>>>>>> b) the fact that in QuantLib the PathGenerator.next().value returns the
>>>>>> result
>>>>>> of the SDE expression _*without *_applying the ITO correction associated
>>>>>> with
>>>>>> the fact that dt is not infinitesimal.
>>>>>>
>>>>>> The b) is also responsible for the lack of convergence in your output
>>>>>> towards
>>>>>> the theoretical target of 68.27%
>>>>>>
>>>>>> You would get the correct convergence if you modified your code by using
>>>>>> the
>>>>>> expressions below:
>>>>>>
>>>>>>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
>>>>>> -1.0);     // Sx at -1SD
>>>>>>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
>>>>>> 1.0);     // Sx at +1SD
>>>>>>
>>>>>>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma) (as
>>>>>> Peter also pointed out)
>>>>>>
>>>>>> Again, due to b) one can produce the correct simulated values of a GBM
>>>>>> diffused quantity (such as a stock price in the GBM model) by using N time
>>>>>> steps, with N very large. Using N = 1 (like in your example), the simulated
>>>>>> values will still be lognormally distributed (whence your good result with
>>>>>> N =
>>>>>> 1), but will be centered at a wrong mean and thus will _*fail *_to
>>>>>> represent
>>>>>> the correct values expected by the GBM SDE.
>>>>>>
>>>>>> Ioannis
>>>>>>
>>>>>> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>>>>>>> As said in other posting here, after fixing the test program
>>>>>>> by skipping the first item (the initial price) in the
>>>>>>> generated sample path, BoxMullerGaussianRng now passes the said test.
>>>>>>>
>>>>>>> The bugfixed test code and the new test results can be found here:
>>>>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That important fact that the generated sample path contains
>>>>>>> not timeSteps elements but 1 + timeSteps elements needs
>>>>>>> to be documented in the library doc.
>>>>>>> For example on this API doc page one normally would expect
>>>>>>> to find such an important information, but it's missing:
>>>>>>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html
>>>>>>>
>>>>>>> If you or someone else can change/extend the test program by using
>>>>>>> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
>>>>>>> to hear about it. Thx.
>>>>>>>
>>>>>>>
>>>>>>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>>>>>>> If you search within the QuantLib code for BoxMullerGaussianRng, you will
>>>>>>>> see
>>>>>>>> it is used only in the experimental folder. It is therefore not
>>>>>>>> surprising if
>>>>>>>> it doesn't produce the expected results.
>>>>>>>>
>>>>>>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which is
>>>>>>>> used
>>>>>>>> extensively in other areas of QuantLib.
>>>>>>>>
>>>>>>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>>>>>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me good
>>>>>>>> results.
>>>>>>>>
>>>>>>>> Ioannis Rigopoulos, founder of deriscope.com

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[Ioannis R. <qua...@de...>]

Our SDE for the evolution of S is:

dS = μSdt + σSdw

In your code you use:


PathGenerator<RandomSequenceGenerator<MersenneBoxMuller>> 
gbmPathGenerator(gbm, t, timeSteps, gsg, false);
const Path& samplePath = gbmPathGenerator.next().value;

The PathGenerator::next().value is designed to return an array of 
numbers {S(T₁) , S(T₂) , ... , S(Tᵤ)}

where

u := timeSteps

Δt := t/u

Tᵢ := iΔt for i = 1,...,u

It follows:

Tᵤ = t = the final time when we are interested to know the simulated 
values of S (in your test you use t = 1).

QuantLib builds the sequence {S(T₁) , S(T₂) , ... , S(Tᵤ)} incrementally 
through a total number of u steps by adding the quantity ΔS := μSΔt + 
σSΔw on the previous member of the sequence, with Δw := random number 
drawn from N~(0,Δt¹ᐟ²).

The previous member of S(T₁) is assumed the T₀ = 0 and the initial value 
S(T₀) = S(0) is assumed deterministic and known.

So, starting with the given S(T₀), QuantLib calculates the S(T₁) using 
the formula:

S(T₁) := S(T₀) + μS(T₀)Δt + σS(T₀)Δw

Then given the S(T₁) as calculated above, it proceeds to calculate S(T₂) as:

S(T₂) := S(T₁) + μS(T₁)Δt + σS(T₁)Δw

For simplicity I have used the same notation for the Δw in the equations 
above, but they are different.

After u steps, the final value S(t) = S(Tᵤ) is calculated as:

S(t) = S(Tᵤ) := S(Tᵤ₋₁) + μS(Tᵤ₋₁)Δt + σS(Tᵤ₋₁)Δw

All equations above hold only in an approximate sense when Δt is finite.

They are accurate only in a limiting sense as Δt → 0.

It follows that the value S(t) will be calculated correctly only if Δt → 
0, which is equivalent to u → ∞

If you use u = 1 (i.e. one time step), you will still match the 68.27% 
rule when the 1SD interval is defined in accordance with a normal 
distribution because S(T₁) := S(T₀) + μS(T₀)Δt + σS(T₀)Δw corresponds to 
a normal distribution and if you build a histogram of all simulated 
values you will notice that S(T₁) is distributed normally, which is 
clearly not consistent with the SDE that predicts lognormal distribution.

The correct procedure is of course to use a very large u and define the 
1SD interval in accordance with a lognormal distribution, as I described 
in my previous email.

Then you will get convergence to the 68.27% rule.

By the way, this is how my histogram of S(t) (for t = 1) simulated 
values looks like when I used 100,000 time steps and 100,000 
simulations. It is clearly lognormal in shape. I am sure, if you do the 
same when time steps = 1, you will get a normal distribution for S(t), 
which would prove that time steps = 1 does not reproduce the 
theoretically expected values for S(t).

Ioannis

On 9/11/2023 10:19 AM, U.Mutlu wrote:
> Dear Ioannis Rigopoulos, I now analysed your table and
> must say that you seem to have a much different expectation to,
> and understanding of that table.
>
> The  values in your table for timeSteps > 1 can definitely
> not be correct, b/c why do you think it has to be 68.27 for all 
> timeSteps?
> This is illogical b/c the more timeSteps the more the hitrate%
> must be, like in my table. It saturates at about 84.93%
>
> Sorry, I have to retract my initial enthusiastic judment
> of your work below, as it's fundamentally flawed & wrong,
> and I should have been more careful when I quickly & briefly
> inspected your posting in the early morning here.
>
> Since your results in the table for timeSteps > 1 are wrong,
> then your formulas must be wrong too, so I had to stop my analysis 
> right there.
>
> Please just answer why you think it has to be 68.27% for all timeSteps?
>
>
> U.Mutlu wrote on 09/11/23 08:36:
>> Mr. Ioannis Rigopoulos, that's a brilliant work by you. Thank you 
>> very much.
>> I need some time to study and verify the reults, but it looks very good
>> to solve the confusion and mystery I had experienced when I started this
>> research some weeks ago.
>> I'll try to replicate your results and will report later in detail here.
>>
>> Ioannis Rigopoulos wrote on 09/10/23 19:29:
>>  > On a different topic, I do not understand your statement "/I've 
>> never seen
>>  > that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>>  > What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, 
>> where
>>
>> Sorry for the consfusion, it just means the stock price (Sx after 
>> time t,
>> ie. S(t) or S_t) for the lower boundary at -1SD and for the upper 
>> boundary at
>> +1SD,
>> ie. your "min of S(t)" and "max of S(t)" in your other posting.
>> In future I'll use a more common term like yours, sorry.
>>
>> Thx
>>
>>
>> Ioannis Rigopoulos wrote on 09/10/23 19:29:
>>> Yes, I mean mu * t - 0.5 * sigma * sigma * t
>>>
>>> Are you sure, you also adjusted the boundaries corresponding to plus 
>>> and minus
>>> 1 SD?
>>>
>>> I ran an Excel spreadsheet by modifying a spreadsheet I had 
>>> published several
>>> years ago at 
>>> https://blog.deriscope.com/index.php/en/excel-value-at-risk that
>>> uses the GeometricBrownianMotionProcess , albeit with the
>>> PseudoRandom::rsg_type generator.
>>>
>>> At any case, I got convergence to 68.27% as I increased the number 
>>> of time
>>> steps and keeping the number of simulations fixed to 100,000, 
>>> provided I used
>>> the correct (Ito-adjusted) means, as below:
>>>
>>> As you see above, the "No Ito-adjusted" boundaries are 74.08 and 
>>> 134.99, just
>>> like those you use.
>>>
>>> The Ito-adjusted boundaries are 70.82 and 129.05 produced by 
>>> shifting the
>>> no-adjusted boundaries - in log terms - to the left by 0.5*sigma^2*t.
>>>
>>> The simulation results (percentage of values being within the min 
>>> and max
>>> boundaries) are below:
>>>
>>> As you see, the Ito-adjusted percentage reaches 68.30% for 100,000 
>>> time steps,
>>> which is close to the expected 68.27%.
>>>
>>> The No Ito-adjusted percentage seems instead to converge to a 
>>> different value
>>> around 67.73%
>>>
>>> On a different topic, I do not understand your statement "/I've 
>>> never seen
>>> that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>>>
>>> What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, 
>>> where m is
>>> the mean of a normally distributed variable. This means that one 
>>> needs to
>>> calculate m in order to do the mentioned computation.
>>>
>>> If your starting point is an SDE like dS = S*mu*dt + S*sigma*dw, 
>>> then ln(S(t))
>>> at any time t will be normally distributed with mean m = ln(S(0)) + 
>>> mu*t -
>>> 0.5*sigma^2*t , where the last term is a consequence of the Ito lemma.
>>>
>>> Do you have any reason to believe that the Ito lemma is somehow not 
>>> valid so
>>> that m = ln(S(0)) + mu*t?
>>>
>>> Ioannis
>>>
>>> On 9/10/2023 3:00 PM, U.Mutlu wrote:
>>>
>>>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>>> > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)
>>>>
>>>> Thank you for your analysis.
>>>> I guess you mean "mu * t - 0.5 * sigma * sigma * t",
>>>> though in our example with t=1 it doesn't make any difference.
>>>> It gives for timeSteps=1 this result:
>>>>
>>>> $ ./Testing_GBM_of_QuantLib.exe 1
>>>> timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000
>>>> sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : -1SD=70.822035
>>>> +1SD=129.046162
>>>> cHit=663067/1000000(66.307%)
>>>>
>>>> This is far from the expected value of 68.2689% for timeStep=1.
>>>> So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)
>>>>
>>>> Cf. also the following showing similar results for GBM,
>>>> which then was compared to the standard lognormal calculation:
>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548 
>>>>
>>>>
>>>>
>>>>
>>>> And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get 
>>>> computed with
>>>> Ito's lemma applied.
>>>>
>>>>
>>>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>>>> Thank you for testing the BoxMullerGaussianRng code, which - as I 
>>>>> wrote -
>>>>> does
>>>>> not seem to be used in other areas of the standard part of QuantLib.
>>>>>
>>>>> Your numerical results below ...
>>>>>
>>>>> indicate that the simulated values for ln(S(t)) produced with 
>>>>> timeSteps = 1
>>>>> are very likely normally distributed with mean (I use your 
>>>>> notation) ln(S(0))
>>>>> + mu*t and standard deviation sigma * sqrt(t)
>>>>>
>>>>> This result _*is consistent*_ with:
>>>>>
>>>>> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>>>>>
>>>>> _*and*_
>>>>>
>>>>> b) the fact that in QuantLib the PathGenerator.next().value 
>>>>> returns the
>>>>> result
>>>>> of the SDE expression _*without *_applying the ITO correction 
>>>>> associated with
>>>>> the fact that dt is not infinitesimal.
>>>>>
>>>>> The b) is also responsible for the lack of convergence in your 
>>>>> output towards
>>>>> the theoretical target of 68.27%
>>>>>
>>>>> You would get the correct convergence if you modified your code by 
>>>>> using the
>>>>> expressions below:
>>>>>
>>>>>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
>>>>> sqrt(t) *
>>>>> -1.0);     // Sx at -1SD
>>>>>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
>>>>> sqrt(t) *
>>>>> 1.0);     // Sx at +1SD
>>>>>
>>>>>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, 
>>>>> sigma) (as
>>>>> Peter also pointed out)
>>>>>
>>>>> Again, due to b) one can produce the correct simulated values of a 
>>>>> GBM
>>>>> diffused quantity (such as a stock price in the GBM model) by 
>>>>> using N time
>>>>> steps, with N very large. Using N = 1 (like in your example), the 
>>>>> simulated
>>>>> values will still be lognormally distributed (whence your good 
>>>>> result with
>>>>> N =
>>>>> 1), but will be centered at a wrong mean and thus will _*fail *_to 
>>>>> represent
>>>>> the correct values expected by the GBM SDE.
>>>>>
>>>>> Ioannis
>>>>>
>>>>> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>>>>>> As said in other posting here, after fixing the test program
>>>>>> by skipping the first item (the initial price) in the
>>>>>> generated sample path, BoxMullerGaussianRng now passes the said 
>>>>>> test.
>>>>>>
>>>>>> The bugfixed test code and the new test results can be found here:
>>>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> That important fact that the generated sample path contains
>>>>>> not timeSteps elements but 1 + timeSteps elements needs
>>>>>> to be documented in the library doc.
>>>>>> For example on this API doc page one normally would expect
>>>>>> to find such an important information, but it's missing:
>>>>>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html 
>>>>>>
>>>>>>
>>>>>> If you or someone else can change/extend the test program by using
>>>>>> the suggested alternative(s) to BoxMullerGaussianRng, I would be 
>>>>>> happy
>>>>>> to hear about it. Thx.
>>>>>>
>>>>>>
>>>>>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>>>>>> If you search within the QuantLib code for BoxMullerGaussianRng, 
>>>>>>> you will
>>>>>>> see
>>>>>>> it is used only in the experimental folder. It is therefore not
>>>>>>> surprising if
>>>>>>> it doesn't produce the expected results.
>>>>>>>
>>>>>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, 
>>>>>>> which is
>>>>>>> used
>>>>>>> extensively in other areas of QuantLib.
>>>>>>>
>>>>>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>>>>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and 
>>>>>>> gives me good
>>>>>>> results.
>>>>>>>
>>>>>>> Ioannis Rigopoulos, founder of deriscope.com
>>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>>>
>>>
>>> Virus-free.www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>
>>
>

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[U.Mutlu <um...@mu...>]

Dear Ioannis Rigopoulos, I now analysed your table and
must say that you seem to have a much different expectation to,
and understanding of that table.

The  values in your table for timeSteps > 1 can definitely
not be correct, b/c why do you think it has to be 68.27 for all timeSteps?
This is illogical b/c the more timeSteps the more the hitrate%
must be, like in my table. It saturates at about 84.93%

Sorry, I have to retract my initial enthusiastic judment
of your work below, as it's fundamentally flawed & wrong,
and I should have been more careful when I quickly & briefly
inspected your posting in the early morning here.

Since your results in the table for timeSteps > 1 are wrong,
then your formulas must be wrong too, so I had to stop my analysis right there.

Please just answer why you think it has to be 68.27% for all timeSteps?


U.Mutlu wrote on 09/11/23 08:36:
> Mr. Ioannis Rigopoulos, that's a brilliant work by you. Thank you very much.
> I need some time to study and verify the reults, but it looks very good
> to solve the confusion and mystery I had experienced when I started this
> research some weeks ago.
> I'll try to replicate your results and will report later in detail here.
>
> Ioannis Rigopoulos wrote on 09/10/23 19:29:
>  > On a different topic, I do not understand your statement "/I've never seen
>  > that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>  > What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where
>
> Sorry for the consfusion, it just means the stock price (Sx after time t,
> ie. S(t) or S_t) for the lower boundary at -1SD and for the upper boundary at
> +1SD,
> ie. your "min of S(t)" and "max of S(t)" in your other posting.
> In future I'll use a more common term like yours, sorry.
>
> Thx
>
>
> Ioannis Rigopoulos wrote on 09/10/23 19:29:
>> Yes, I mean mu * t - 0.5 * sigma * sigma * t
>>
>> Are you sure, you also adjusted the boundaries corresponding to plus and minus
>> 1 SD?
>>
>> I ran an Excel spreadsheet by modifying a spreadsheet I had published several
>> years ago at https://blog.deriscope.com/index.php/en/excel-value-at-risk that
>> uses the GeometricBrownianMotionProcess , albeit with the
>> PseudoRandom::rsg_type generator.
>>
>> At any case, I got convergence to 68.27% as I increased the number of time
>> steps and keeping the number of simulations fixed to 100,000, provided I used
>> the correct (Ito-adjusted) means, as below:
>>
>> As you see above, the "No Ito-adjusted" boundaries are 74.08 and 134.99, just
>> like those you use.
>>
>> The Ito-adjusted boundaries are 70.82 and 129.05 produced by shifting the
>> no-adjusted boundaries - in log terms - to the left by 0.5*sigma^2*t.
>>
>> The simulation results (percentage of values being within the min and max
>> boundaries) are below:
>>
>> As you see, the Ito-adjusted percentage reaches 68.30% for 100,000 time steps,
>> which is close to the expected 68.27%.
>>
>> The No Ito-adjusted percentage seems instead to converge to a different value
>> around 67.73%
>>
>> On a different topic, I do not understand your statement "/I've never seen
>> that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>>
>> What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where m is
>> the mean of a normally distributed variable. This means that one needs to
>> calculate m in order to do the mentioned computation.
>>
>> If your starting point is an SDE like dS = S*mu*dt + S*sigma*dw, then ln(S(t))
>> at any time t will be normally distributed with mean m = ln(S(0)) + mu*t -
>> 0.5*sigma^2*t , where the last term is a consequence of the Ito lemma.
>>
>> Do you have any reason to believe that the Ito lemma is somehow not valid so
>> that m = ln(S(0)) + mu*t?
>>
>> Ioannis
>>
>> On 9/10/2023 3:00 PM, U.Mutlu wrote:
>>
>>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>> > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)
>>>
>>> Thank you for your analysis.
>>> I guess you mean "mu * t - 0.5 * sigma * sigma * t",
>>> though in our example with t=1 it doesn't make any difference.
>>> It gives for timeSteps=1 this result:
>>>
>>> $ ./Testing_GBM_of_QuantLib.exe 1
>>> timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000
>>> sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : -1SD=70.822035
>>> +1SD=129.046162
>>> cHit=663067/1000000(66.307%)
>>>
>>> This is far from the expected value of 68.2689% for timeStep=1.
>>> So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)
>>>
>>> Cf. also the following showing similar results for GBM,
>>> which then was compared to the standard lognormal calculation:
>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548
>>>
>>>
>>>
>>> And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get computed with
>>> Ito's lemma applied.
>>>
>>>
>>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>>> Thank you for testing the BoxMullerGaussianRng code, which - as I wrote -
>>>> does
>>>> not seem to be used in other areas of the standard part of QuantLib.
>>>>
>>>> Your numerical results below ...
>>>>
>>>> indicate that the simulated values for ln(S(t)) produced with timeSteps = 1
>>>> are very likely normally distributed with mean (I use your notation) ln(S(0))
>>>> + mu*t and standard deviation sigma * sqrt(t)
>>>>
>>>> This result _*is consistent*_ with:
>>>>
>>>> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>>>>
>>>> _*and*_
>>>>
>>>> b) the fact that in QuantLib the PathGenerator.next().value returns the
>>>> result
>>>> of the SDE expression _*without *_applying the ITO correction associated with
>>>> the fact that dt is not infinitesimal.
>>>>
>>>> The b) is also responsible for the lack of convergence in your output towards
>>>> the theoretical target of 68.27%
>>>>
>>>> You would get the correct convergence if you modified your code by using the
>>>> expressions below:
>>>>
>>>>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
>>>> -1.0);     // Sx at -1SD
>>>>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
>>>> 1.0);     // Sx at +1SD
>>>>
>>>>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma) (as
>>>> Peter also pointed out)
>>>>
>>>> Again, due to b) one can produce the correct simulated values of a GBM
>>>> diffused quantity (such as a stock price in the GBM model) by using N time
>>>> steps, with N very large. Using N = 1 (like in your example), the simulated
>>>> values will still be lognormally distributed (whence your good result with
>>>> N =
>>>> 1), but will be centered at a wrong mean and thus will _*fail *_to represent
>>>> the correct values expected by the GBM SDE.
>>>>
>>>> Ioannis
>>>>
>>>> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>>>>> As said in other posting here, after fixing the test program
>>>>> by skipping the first item (the initial price) in the
>>>>> generated sample path, BoxMullerGaussianRng now passes the said test.
>>>>>
>>>>> The bugfixed test code and the new test results can be found here:
>>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> That important fact that the generated sample path contains
>>>>> not timeSteps elements but 1 + timeSteps elements needs
>>>>> to be documented in the library doc.
>>>>> For example on this API doc page one normally would expect
>>>>> to find such an important information, but it's missing:
>>>>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html
>>>>>
>>>>> If you or someone else can change/extend the test program by using
>>>>> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
>>>>> to hear about it. Thx.
>>>>>
>>>>>
>>>>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>>>>> If you search within the QuantLib code for BoxMullerGaussianRng, you will
>>>>>> see
>>>>>> it is used only in the experimental folder. It is therefore not
>>>>>> surprising if
>>>>>> it doesn't produce the expected results.
>>>>>>
>>>>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which is
>>>>>> used
>>>>>> extensively in other areas of QuantLib.
>>>>>>
>>>>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>>>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me good
>>>>>> results.
>>>>>>
>>>>>> Ioannis Rigopoulos, founder of deriscope.com
>>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>> Virus-free.www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>
>

Re: [Quantlib-users] Bootstrapped Yield Curve extrapolation help

[Jonathan G. <Jon...@ni...>]

Hi Marcin,

Thank you for your input. Apologies for the delay in response.

Before your mail I settled on the following solution:


  1.  If I am correct in assuming, the constant zero rate post final bond maturity will be ‘fixed’ indefinitely if the preceding forward rate is equal to the zero rate.
  2.  I used the ultimate forward term structure and set the ultimate forward rate equal to the sampled final zero rate at t+1 post final bond maturity - https://rkapl123.github.io/QLAnnotatedSource/dc/dbf/class_quant_lib_1_1_ultimate_forward_term_structure.html

It seems to provide me with the curve I was intending. Any thoughts around this?

A question for you on your linear/non-linear point, have you had any attempt/success at using Piecewise Monotone Convex interpolation using python?

Thanks for your help!


Jonathan George
Quantitative Developer
T:+27 21 901 1363
36 Hans Strijdom Avenue
Foreshore, Cape Town, Western Cape, 8001, South Africa
www.ninetyone.com  |
Follow us
From: Marcin Rybacki <mry...@gm...>
Sent: 07 September 2023 17:56
To: Jonathan George <Jon...@ni...>
Cc: qua...@li...
Subject: Re: [Quantlib-users] Bootstrapped Yield Curve extrapolation help

Hi Jonathan,

I think that, at the moment, the library only offers flat forward extrapolation.
However, you could use the following workaround:

1) Build the curve, based on the original input rates, using linear log-discount interpolation without enabling the extrapolation
2) Retrieve the nodes of the curve, which I assume will be (in Python) a list of tuples with dates and discount factors
2) From this curve calculate a zero rate for the last node: last_zero_rate = crv.zeroRate(crv.maxTime(), ql.Continuous).rate()
3) Calculate a discount factor for the very last QuantLib date: max_dt = ql.Date.maxDate() By taking the exponent of the year fraction from the reference date to max date, times last zero rate and times -1. And append the nodes with this last tuple (date and discount factor)
4) Reconstruct the curve using ql.DiscountCurve(dates, discounts, day_counter) and enable extrapolation.

I think this should give the outcome you're looking for.

Please note that the above approach will only work for linear schemes. Applying it with e.g. cubic splines will lead to a different solution of the tridiagonal system, and the resulting curves will be slightly different.
Another downside is that bumping quote handles to obtain sensitivities will yield incorrect outcomes in the extrapolation region - so instead you would have to rebuild the curve to get the deltas.

Hope this helps.

Kind regards,
Marcin

On Thu, 24 Aug 2023 at 15:32, Jonathan George <Jon...@ni...<mailto:Jon...@ni...>> wrote:
Hi All,

I am hoping that I might be able to get some help from this forum.

Context:
I am trying to bootstrap a yield curve using piecewise flat forward interpolation between market obtained rates. Here is my output:

[cid:image003.png@01D9D69D.7A43BF10]

I am using python and my curve construction is quite straight forward with extrapolation enabled(I understand I am committing the cardinal sin by not posting my code, but hoping that this is theoretical enough a question for a straight forward answer)

Question:
Is it possible to fix the final zero rate post maturity of the last bond? It seems that enableExtrapolation is fixing the final forward rate making the zero rate decay over time. I am trying to avoid creating a custom function to return zero and forward rates post maturity of the final bond.
I have tried create two curves (a linear flat forward curve and a regular flat forward curve) and combining using CompositeZeroYieldStructure however I’m not sure which binary function to pass into the function.

Any help would be appreciated.
Regards
Jonathan George
Quantitative Developer

T:
+27 21 901 1363<tel:+27%2021%20901%201363>


36 Hans Strijdom Avenue
Foreshore, Cape Town, 8001
www.ninetyone.com  |<http://ninetyone.com/>
[cid:image533918.png@E2B7D91B.840C5271]<https://www.linkedin.com/company/ninetyone/>
Follow us<https://www.linkedin.com/company/ninetyone>
[cid:image087679.png@D95C995A.624A21B7]<https://ninetyone.com/>

_______________________________________________
QuantLib-users mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-users<https://lists.sourceforge.net/lists/listinfo/quantlib-users>

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[U.Mutlu <um...@mu...>]

Mr. Ioannis Rigopoulos, that's a brilliant work by you. Thank you very much.
I need some time to study and verify the reults, but it looks very good
to solve the confusion and mystery I had experienced when I started this
research some weeks ago.
I'll try to replicate your results and will report later in detail here.

Ioannis Rigopoulos wrote on 09/10/23 19:29:
 > On a different topic, I do not understand your statement "/I've never seen 
 > that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
 > What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where

Sorry for the consfusion, it just means the stock price (Sx after time t,
ie. S(t) or S_t) for the lower boundary at -1SD and for the upper boundary at 
+1SD,
ie. your "min of S(t)" and "max of S(t)" in your other posting.
In future I'll use a more common term like yours, sorry.

Thx


Ioannis Rigopoulos wrote on 09/10/23 19:29:
> Yes, I mean mu * t - 0.5 * sigma * sigma * t
>
> Are you sure, you also adjusted the boundaries corresponding to plus and minus
> 1 SD?
>
> I ran an Excel spreadsheet by modifying a spreadsheet I had published several
> years ago at https://blog.deriscope.com/index.php/en/excel-value-at-risk that
> uses the GeometricBrownianMotionProcess , albeit with the
> PseudoRandom::rsg_type generator.
>
> At any case, I got convergence to 68.27% as I increased the number of time
> steps and keeping the number of simulations fixed to 100,000, provided I used
> the correct (Ito-adjusted) means, as below:
>
> As you see above, the "No Ito-adjusted" boundaries are 74.08 and 134.99, just
> like those you use.
>
> The Ito-adjusted boundaries are 70.82 and 129.05 produced by shifting the
> no-adjusted boundaries - in log terms - to the left by 0.5*sigma^2*t.
>
> The simulation results (percentage of values being within the min and max
> boundaries) are below:
>
> As you see, the Ito-adjusted percentage reaches 68.30% for 100,000 time steps,
> which is close to the expected 68.27%.
>
> The No Ito-adjusted percentage seems instead to converge to a different value
> around 67.73%
>
> On a different topic, I do not understand your statement "/I've never seen
> that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>
> What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where m is
> the mean of a normally distributed variable. This means that one needs to
> calculate m in order to do the mentioned computation.
>
> If your starting point is an SDE like dS = S*mu*dt + S*sigma*dw, then ln(S(t))
> at any time t will be normally distributed with mean m = ln(S(0)) + mu*t -
> 0.5*sigma^2*t , where the last term is a consequence of the Ito lemma.
>
> Do you have any reason to believe that the Ito lemma is somehow not valid so
> that m = ln(S(0)) + mu*t?
>
> Ioannis
>
> On 9/10/2023 3:00 PM, U.Mutlu wrote:
>
>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>> > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)
>>
>> Thank you for your analysis.
>> I guess you mean "mu * t - 0.5 * sigma * sigma * t",
>> though in our example with t=1 it doesn't make any difference.
>> It gives for timeSteps=1 this result:
>>
>> $ ./Testing_GBM_of_QuantLib.exe 1
>> timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000
>> sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : -1SD=70.822035
>> +1SD=129.046162
>> cHit=663067/1000000(66.307%)
>>
>> This is far from the expected value of 68.2689% for timeStep=1.
>> So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)
>>
>> Cf. also the following showing similar results for GBM,
>> which then was compared to the standard lognormal calculation:
>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548
>>
>>
>> And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get computed with
>> Ito's lemma applied.
>>
>>
>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>> Thank you for testing the BoxMullerGaussianRng code, which - as I wrote - does
>>> not seem to be used in other areas of the standard part of QuantLib.
>>>
>>> Your numerical results below ...
>>>
>>> indicate that the simulated values for ln(S(t)) produced with timeSteps = 1
>>> are very likely normally distributed with mean (I use your notation) ln(S(0))
>>> + mu*t and standard deviation sigma * sqrt(t)
>>>
>>> This result _*is consistent*_ with:
>>>
>>> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>>>
>>> _*and*_
>>>
>>> b) the fact that in QuantLib the PathGenerator.next().value returns the result
>>> of the SDE expression _*without *_applying the ITO correction associated with
>>> the fact that dt is not infinitesimal.
>>>
>>> The b) is also responsible for the lack of convergence in your output towards
>>> the theoretical target of 68.27%
>>>
>>> You would get the correct convergence if you modified your code by using the
>>> expressions below:
>>>
>>>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
>>> -1.0);     // Sx at -1SD
>>>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
>>> 1.0);     // Sx at +1SD
>>>
>>>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma) (as
>>> Peter also pointed out)
>>>
>>> Again, due to b) one can produce the correct simulated values of a GBM
>>> diffused quantity (such as a stock price in the GBM model) by using N time
>>> steps, with N very large. Using N = 1 (like in your example), the simulated
>>> values will still be lognormally distributed (whence your good result with N =
>>> 1), but will be centered at a wrong mean and thus will _*fail *_to represent
>>> the correct values expected by the GBM SDE.
>>>
>>> Ioannis
>>>
>>> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>>>> As said in other posting here, after fixing the test program
>>>> by skipping the first item (the initial price) in the
>>>> generated sample path, BoxMullerGaussianRng now passes the said test.
>>>>
>>>> The bugfixed test code and the new test results can be found here:
>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666
>>>>
>>>>
>>>>
>>>> That important fact that the generated sample path contains
>>>> not timeSteps elements but 1 + timeSteps elements needs
>>>> to be documented in the library doc.
>>>> For example on this API doc page one normally would expect
>>>> to find such an important information, but it's missing:
>>>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html
>>>>
>>>> If you or someone else can change/extend the test program by using
>>>> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
>>>> to hear about it. Thx.
>>>>
>>>>
>>>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>>>> If you search within the QuantLib code for BoxMullerGaussianRng, you will
>>>>> see
>>>>> it is used only in the experimental folder. It is therefore not
>>>>> surprising if
>>>>> it doesn't produce the expected results.
>>>>>
>>>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which is
>>>>> used
>>>>> extensively in other areas of QuantLib.
>>>>>
>>>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me good
>>>>> results.
>>>>>
>>>>> Ioannis Rigopoulos, founder of deriscope.com
>>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[Ioannis R. <qua...@de...>]

I think, I understand now your confusion regarding the usage of Ito lemma.

The mean m = ln(S(0)) + mu*t - 0.5*sigma^2*t is the mean of ln(S(t)) at 
time t.

Formally, m := ||ln(S(t))|| = ln(S(0)) + mu*t - 0.5*sigma^2*t , where 
||x|| denotes the mean of the random variable x.

But, due to Ito again, the above implies:

m' := ||S(t)|| = S(0)*exp(mu*t)

which means the mean m' of S(t) does not contain the "Ito term" 
0.5*sigma^2*t.

When investigating the 68.27% rule, we always look in a normally 
distributed variable, in this case the ln(S(t)), which is centered 
around m (not around m').

But when we speak in terms of S(t) - rather than of ln(S(t)) - the 
distribution of S(t) is centered around m', which indeed does not 
involve the Ito term.

I guess, many practitioners prefer to refer to S(t) rather than to 
ln(S(t)) and therefore also refer to the 1SD double-side interval around 
m', giving the impression that the Ito term is not present.

But if one needs to calculate the precise min and max values of the 1SD 
double-side interval in the S(t) space, one should use:

min of S(t) = m'*exp(mu*t - 0.5*sigma^2*t - sigma*t¹ᐟ²)

max of S(t) = m'*exp(mu*t - 0.5*sigma^2*t + sigma*t¹ᐟ²)

The above expressions reintroduce the Ito term.

Ioannis

On 9/10/2023 7:29 PM, Ioannis Rigopoulos wrote:
>
> Yes, I mean mu * t - 0.5 * sigma * sigma * t
>
> Are you sure, you also adjusted the boundaries corresponding to plus 
> and minus 1 SD?
>
> I ran an Excel spreadsheet by modifying a spreadsheet I had published 
> several years ago at 
> https://blog.deriscope.com/index.php/en/excel-value-at-risk that uses 
> the GeometricBrownianMotionProcess , albeit with the 
> PseudoRandom::rsg_type generator.
>
> At any case, I got convergence to 68.27% as I increased the number of 
> time steps and keeping the number of simulations fixed to 100,000, 
> provided I used the correct (Ito-adjusted) means, as below:
>
> As you see above, the "No Ito-adjusted" boundaries are 74.08 and 
> 134.99, just like those you use.
>
> The Ito-adjusted boundaries are 70.82 and 129.05 produced by shifting 
> the no-adjusted boundaries - in log terms - to the left by 0.5*sigma^2*t.
>
> The simulation results (percentage of values being within the min and 
> max boundaries) are below:
>
> As you see, the Ito-adjusted percentage reaches 68.30% for 100,000 
> time steps, which is close to the expected 68.27%.
>
> The No Ito-adjusted percentage seems instead to converge to a 
> different value around 67.73%
>
> On a different topic, I do not understand your statement "/I've never 
> seen that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".
>
> What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, 
> where m is the mean of a normally distributed variable. This means 
> that one needs to calculate m in order to do the mentioned computation.
>
> If your starting point is an SDE like dS = S*mu*dt + S*sigma*dw, then 
> ln(S(t)) at any time t will be normally distributed with mean m = 
> ln(S(0)) + mu*t - 0.5*sigma^2*t , where the last term is a consequence 
> of the Ito lemma.
>
> Do you have any reason to believe that the Ito lemma is somehow not 
> valid so that m = ln(S(0)) + mu*t?
>
> Ioannis
>
> On 9/10/2023 3:00 PM, U.Mutlu wrote:
>
>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>> > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)
>>
>> Thank you for your analysis.
>> I guess you mean "mu * t - 0.5 * sigma * sigma * t",
>> though in our example with t=1 it doesn't make any difference.
>> It gives for timeSteps=1 this result:
>>
>> $ ./Testing_GBM_of_QuantLib.exe 1
>> timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000 
>> sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : 
>> -1SD=70.822035 +1SD=129.046162
>> cHit=663067/1000000(66.307%)
>>
>> This is far from the expected value of 68.2689% for timeStep=1.
>> So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)
>>
>> Cf. also the following showing similar results for GBM,
>> which then was compared to the standard lognormal calculation:
>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548 
>>
>>
>> And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get computed 
>> with Ito's lemma applied.
>>
>>
>> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>>> Thank you for testing the BoxMullerGaussianRng code, which - as I 
>>> wrote - does
>>> not seem to be used in other areas of the standard part of QuantLib.
>>>
>>> Your numerical results below ...
>>>
>>> indicate that the simulated values for ln(S(t)) produced with 
>>> timeSteps = 1
>>> are very likely normally distributed with mean (I use your notation) 
>>> ln(S(0))
>>> + mu*t and standard deviation sigma * sqrt(t)
>>>
>>> This result _*is consistent*_ with:
>>>
>>> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>>>
>>> _*and*_
>>>
>>> b) the fact that in QuantLib the PathGenerator.next().value returns 
>>> the result
>>> of the SDE expression _*without *_applying the ITO correction 
>>> associated with
>>> the fact that dt is not infinitesimal.
>>>
>>> The b) is also responsible for the lack of convergence in your 
>>> output towards
>>> the theoretical target of 68.27%
>>>
>>> You would get the correct convergence if you modified your code by 
>>> using the
>>> expressions below:
>>>
>>>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
>>> sqrt(t) *
>>> -1.0);     // Sx at -1SD
>>>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
>>> sqrt(t) *
>>> 1.0);     // Sx at +1SD
>>>
>>>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, 
>>> sigma) (as
>>> Peter also pointed out)
>>>
>>> Again, due to b) one can produce the correct simulated values of a GBM
>>> diffused quantity (such as a stock price in the GBM model) by using 
>>> N time
>>> steps, with N very large. Using N = 1 (like in your example), the 
>>> simulated
>>> values will still be lognormally distributed (whence your good 
>>> result with N =
>>> 1), but will be centered at a wrong mean and thus will _*fail *_to 
>>> represent
>>> the correct values expected by the GBM SDE.
>>>
>>> Ioannis
>>>
>>> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>>>> As said in other posting here, after fixing the test program
>>>> by skipping the first item (the initial price) in the
>>>> generated sample path, BoxMullerGaussianRng now passes the said test.
>>>>
>>>> The bugfixed test code and the new test results can be found here:
>>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666 
>>>>
>>>>
>>>>
>>>> That important fact that the generated sample path contains
>>>> not timeSteps elements but 1 + timeSteps elements needs
>>>> to be documented in the library doc.
>>>> For example on this API doc page one normally would expect
>>>> to find such an important information, but it's missing:
>>>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html 
>>>>
>>>>
>>>> If you or someone else can change/extend the test program by using
>>>> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
>>>> to hear about it. Thx.
>>>>
>>>>
>>>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>>>> If you search within the QuantLib code for BoxMullerGaussianRng, 
>>>>> you will see
>>>>> it is used only in the experimental folder. It is therefore not 
>>>>> surprising if
>>>>> it doesn't produce the expected results.
>>>>>
>>>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, 
>>>>> which is used
>>>>> extensively in other areas of QuantLib.
>>>>>
>>>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives 
>>>>> me good
>>>>> results.
>>>>>
>>>>> Ioannis Rigopoulos, founder of deriscope.com
>>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virus-free.www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[Ioannis R. <qua...@de...>]

Yes, I mean mu * t - 0.5 * sigma * sigma * t

Are you sure, you also adjusted the boundaries corresponding to plus and 
minus 1 SD?

I ran an Excel spreadsheet by modifying a spreadsheet I had published 
several years ago at 
https://blog.deriscope.com/index.php/en/excel-value-at-risk that uses 
the GeometricBrownianMotionProcess , albeit with the 
PseudoRandom::rsg_type generator.

At any case, I got convergence to 68.27% as I increased the number of 
time steps and keeping the number of simulations fixed to 100,000, 
provided I used the correct (Ito-adjusted) means, as below:

As you see above, the "No Ito-adjusted" boundaries are 74.08 and 134.99, 
just like those you use.

The Ito-adjusted boundaries are 70.82 and 129.05 produced by shifting 
the no-adjusted boundaries - in log terms - to the left by 0.5*sigma^2*t.

The simulation results (percentage of values being within the min and 
max boundaries) are below:

As you see, the Ito-adjusted percentage reaches 68.30% for 100,000 time 
steps, which is close to the expected 68.27%.

The No Ito-adjusted percentage seems instead to converge to a different 
value around 67.73%

On a different topic, I do not understand your statement "/I've never 
seen that Sx@-1SD and Sx@+1SD get computed with Ito's lemma applied/".

What do the Sx@-1SD and Sx@+1SD mean? I suppose m -1SD and m +1SD, where 
m is the mean of a normally distributed variable. This means that one 
needs to calculate m in order to do the mentioned computation.

If your starting point is an SDE like dS = S*mu*dt + S*sigma*dw, then 
ln(S(t)) at any time t will be normally distributed with mean m = 
ln(S(0)) + mu*t - 0.5*sigma^2*t , where the last term is a consequence 
of the Ito lemma.

Do you have any reason to believe that the Ito lemma is somehow not 
valid so that m = ln(S(0)) + mu*t?

Ioannis

On 9/10/2023 3:00 PM, U.Mutlu wrote:

> Ioannis Rigopoulos wrote on 09/10/23 13:06:
> > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)
>
> Thank you for your analysis.
> I guess you mean "mu * t - 0.5 * sigma * sigma * t",
> though in our example with t=1 it doesn't make any difference.
> It gives for timeSteps=1 this result:
>
> $ ./Testing_GBM_of_QuantLib.exe 1
> timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000 
> sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : -1SD=70.822035 
> +1SD=129.046162
> cHit=663067/1000000(66.307%)
>
> This is far from the expected value of 68.2689% for timeStep=1.
> So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)
>
> Cf. also the following showing similar results for GBM,
> which then was compared to the standard lognormal calculation:
> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548 
>
>
> And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get computed 
> with Ito's lemma applied.
>
>
> Ioannis Rigopoulos wrote on 09/10/23 13:06:
>> Thank you for testing the BoxMullerGaussianRng code, which - as I 
>> wrote - does
>> not seem to be used in other areas of the standard part of QuantLib.
>>
>> Your numerical results below ...
>>
>> indicate that the simulated values for ln(S(t)) produced with 
>> timeSteps = 1
>> are very likely normally distributed with mean (I use your notation) 
>> ln(S(0))
>> + mu*t and standard deviation sigma * sqrt(t)
>>
>> This result _*is consistent*_ with:
>>
>> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>>
>> _*and*_
>>
>> b) the fact that in QuantLib the PathGenerator.next().value returns 
>> the result
>> of the SDE expression _*without *_applying the ITO correction 
>> associated with
>> the fact that dt is not infinitesimal.
>>
>> The b) is also responsible for the lack of convergence in your output 
>> towards
>> the theoretical target of 68.27%
>>
>> You would get the correct convergence if you modified your code by 
>> using the
>> expressions below:
>>
>>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
>> sqrt(t) *
>> -1.0);     // Sx at -1SD
>>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
>> sqrt(t) *
>> 1.0);     // Sx at +1SD
>>
>>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma) 
>> (as
>> Peter also pointed out)
>>
>> Again, due to b) one can produce the correct simulated values of a GBM
>> diffused quantity (such as a stock price in the GBM model) by using N 
>> time
>> steps, with N very large. Using N = 1 (like in your example), the 
>> simulated
>> values will still be lognormally distributed (whence your good result 
>> with N =
>> 1), but will be centered at a wrong mean and thus will _*fail *_to 
>> represent
>> the correct values expected by the GBM SDE.
>>
>> Ioannis
>>
>> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>>> As said in other posting here, after fixing the test program
>>> by skipping the first item (the initial price) in the
>>> generated sample path, BoxMullerGaussianRng now passes the said test.
>>>
>>> The bugfixed test code and the new test results can be found here:
>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666 
>>>
>>>
>>>
>>> That important fact that the generated sample path contains
>>> not timeSteps elements but 1 + timeSteps elements needs
>>> to be documented in the library doc.
>>> For example on this API doc page one normally would expect
>>> to find such an important information, but it's missing:
>>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html 
>>>
>>>
>>> If you or someone else can change/extend the test program by using
>>> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
>>> to hear about it. Thx.
>>>
>>>
>>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>>> If you search within the QuantLib code for BoxMullerGaussianRng, 
>>>> you will see
>>>> it is used only in the experimental folder. It is therefore not 
>>>> surprising if
>>>> it doesn't produce the expected results.
>>>>
>>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, 
>>>> which is used
>>>> extensively in other areas of QuantLib.
>>>>
>>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives 
>>>> me good
>>>> results.
>>>>
>>>> Ioannis Rigopoulos, founder of deriscope.com
>

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[U.Mutlu <um...@mu...>]

Ioannis Rigopoulos wrote on 09/10/23 13:06:
 > new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma)

Thank you for your analysis.
I guess you mean "mu * t - 0.5 * sigma * sigma * t",
though in our example with t=1 it doesn't make any difference.
It gives for timeSteps=1 this result:

$ ./Testing_GBM_of_QuantLib.exe 1
timeSteps=1 nRuns=1000000 seed=1694350548 S=100.000000 mu=0.000000 
sigma=0.300000 t=1.000000 : nGenAll=1000000 USE_ITO=1 : -1SD=70.822035 
+1SD=129.046162
cHit=663067/1000000(66.307%)

This is far from the expected value of 68.2689% for timeStep=1.
So, there must be a bug somewhere. IMO it's our suspect friend Ito :-)

Cf. also the following showing similar results for GBM,
which then was compared to the standard lognormal calculation:
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548

And, honestly, I've never seen that Sx@-1SD and Sx@+1SD get computed with 
Ito's lemma applied.


Ioannis Rigopoulos wrote on 09/10/23 13:06:
> Thank you for testing the BoxMullerGaussianRng code, which - as I wrote - does
> not seem to be used in other areas of the standard part of QuantLib.
>
> Your numerical results below ...
>
> indicate that the simulated values for ln(S(t)) produced with timeSteps = 1
> are very likely normally distributed with mean (I use your notation) ln(S(0))
> + mu*t and standard deviation sigma * sqrt(t)
>
> This result _*is consistent*_ with:
>
> a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw
>
> _*and*_
>
> b) the fact that in QuantLib the PathGenerator.next().value returns the result
> of the SDE expression _*without *_applying the ITO correction associated with
> the fact that dt is not infinitesimal.
>
> The b) is also responsible for the lack of convergence in your output towards
> the theoretical target of 68.27%
>
> You would get the correct convergence if you modified your code by using the
> expressions below:
>
>      const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
> -1.0);     // Sx at -1SD
>      const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * sqrt(t) *
> 1.0);     // Sx at +1SD
>
>      new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma) (as
> Peter also pointed out)
>
> Again, due to b) one can produce the correct simulated values of a GBM
> diffused quantity (such as a stock price in the GBM model) by using N time
> steps, with N very large. Using N = 1 (like in your example), the simulated
> values will still be lognormally distributed (whence your good result with N =
> 1), but will be centered at a wrong mean and thus will _*fail *_to represent
> the correct values expected by the GBM SDE.
>
> Ioannis
>
> On 9/10/2023 11:29 AM, U.Mutlu wrote:
>> As said in other posting here, after fixing the test program
>> by skipping the first item (the initial price) in the
>> generated sample path, BoxMullerGaussianRng now passes the said test.
>>
>> The bugfixed test code and the new test results can be found here:
>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666
>>
>>
>> That important fact that the generated sample path contains
>> not timeSteps elements but 1 + timeSteps elements needs
>> to be documented in the library doc.
>> For example on this API doc page one normally would expect
>> to find such an important information, but it's missing:
>> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html
>>
>> If you or someone else can change/extend the test program by using
>> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
>> to hear about it. Thx.
>>
>>
>> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>>> If you search within the QuantLib code for BoxMullerGaussianRng, you will see
>>> it is used only in the experimental folder. It is therefore not surprising if
>>> it doesn't produce the expected results.
>>>
>>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which is used
>>> extensively in other areas of QuantLib.
>>>
>>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me good
>>> results.
>>>
>>> Ioannis Rigopoulos, founder of deriscope.com

Re: [Quantlib-users] Some list mails missing

[Luigi B. <lui...@gm...>]

Hello—that was the third and last message I got, some 50 hours after
sending the message.  In the meantime, it did try to resend it.


On Sun, Sep 10, 2023 at 12:43 PM U.Mutlu <um...@mu...> wrote:

> Luigi, your below posting of today morning as well I did not
> receive but found only in the archive.
>
> Normally in case of such problems the sending mail server tries to
> resend it later, but your mail server seems not to try to resend it.
>
> Look what google says at
>
> https://support.google.com/mail/answer/6596#zippy=%2Crecipient-server-did-not-accept-our-requests
>
> It says "Try sending the email again later.", ie. the user has to do it
> manually. That's very funny :-)
>
> "
> "Recipient server did not accept our requests"
> Why your message bounced
> You'll see this error message if Gmail can’t connect to your recipient’s
> email
> server.
>
> What you can do
> The problem usually goes away quickly without you doing anything. Try
> sending
> the email again later.
>
> If you keep getting the error:
>
> Check if there are any mistakes in the recipient's email address.
> Contact the customer support team of your recipient's email provider.
> If you got this error while emailing someone at your work, school, or
> other
> organization, contact your administrator.
> "
>
> I checked my server, but could not find anything related in the logs.
> I now have disabled IPv6 as I don't need it on that server, and rebooted
> the
> server.
> I will also contact my hosting provider about this problem. Thx.
>
>
>
> Luigi B. <lui...@gm...> on 2023-09-10 07:12:54 wrote
>  >
>  > I don't think the problem is in the mailing list.  I was replying to
> your
>  > address directly, not through the mailing list, and I've been getting
>  > warnings all week like the one below.  The same happened when I replied
> to
>  > the private email you sent to me.  It seems to me the emails were all
> sent,
>  > but it's your server that's not behaving.
>  >
>  > Luigi
>  > Message not delivered
>  > There was a problem delivering your message to *um...@mu...*. See the
>  > technical details below.
>  > LEARN MORE <https://support.google.com/mail/answer/7720>
>  > The response was:
>  >
>  > The recipient server did not accept our requests to connect. Learn more
> at
>  > https://support.google.com/mail/answer/7720 [mail.mutluit.com.
>  > 195.201.130.20: timed out] [mutluit.com. 195.201.130.20: timed out]
>  >
>  > On Sat, Sep 9, 2023 at 9:33 PM U.Mutlu <um...@mu...> wrote:
>  >
>  > > I today learned that some of the recent mails posted in this mailing
> list
>  > > did not make to my email client.
>  > > For example the following posting by Jonathan S. on 2023-09-05
> 12:53:12
>  > > I only saw today on the web when I did some searching
>  > > in the archive at sourceforge:
>  > > https://sourceforge.net/p/quantlib/mailman/message/37892292/
>  > >
>  > > Folks, I think such commercial sites are very unreliable
>  > > for such open source projects.
>  > > It's IMO a nightmare situation for all list subscribers,
>  > > especially for active participants.
>  > >
>  > > What about switching the mailing list provider?
>  > > Where one also can download the old postings, which IMO is not
> possible at
>  > > this sourgeforge site.
>
>
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[Ioannis R. <qua...@de...>]

Thank you for testing the BoxMullerGaussianRng code, which - as I wrote 
- does not seem to be used in other areas of the standard part of QuantLib.

Your numerical results below ...

indicate that the simulated values for ln(S(t)) produced with timeSteps 
= 1 are very likely normally distributed with mean (I use your notation) 
ln(S(0)) + mu*t and standard deviation sigma * sqrt(t)

This result _*is consistent*_ with:

a) the SDE: dS(t) = S(t)*mu*dt + S(t)*sigma*dw

_*and*_

b) the fact that in QuantLib the PathGenerator.next().value returns the 
result of the SDE expression _*without *_applying the ITO correction 
associated with the fact that dt is not infinitesimal.

The b) is also responsible for the lack of convergence in your output 
towards the theoretical target of 68.27%

You would get the correct convergence if you modified your code by using 
the expressions below:

     const double m1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
sqrt(t) * -1.0);     // Sx at -1SD
     const double p1SD = S * exp(mu * t - 0.5*sigma^2*t + sigma * 
sqrt(t) *  1.0);     // Sx at +1SD

     new GeometricBrownianMotionProcess(S, mu - 0.5*sigma^2*t, sigma) 
(as Peter also pointed out)

Again, due to b) one can produce the correct simulated values of a GBM 
diffused quantity (such as a stock price in the GBM model) by using N 
time steps, with N very large. Using N = 1 (like in your example), the 
simulated values will still be lognormally distributed (whence your good 
result with N = 1), but will be centered at a wrong mean and thus will 
_*fail *_to represent the correct values expected by the GBM SDE.

Ioannis

On 9/10/2023 11:29 AM, U.Mutlu wrote:
> As said in other posting here, after fixing the test program
> by skipping the first item (the initial price) in the
> generated sample path, BoxMullerGaussianRng now passes the said test.
>
> The bugfixed test code and the new test results can be found here:
> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666 
>
>
> That important fact that the generated sample path contains
> not timeSteps elements but 1 + timeSteps elements needs
> to be documented in the library doc.
> For example on this API doc page one normally would expect
> to find such an important information, but it's missing:
> https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html 
>
>
> If you or someone else can change/extend the test program by using
> the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
> to hear about it. Thx.
>
>
> Ioannis Rigopoulos wrote on 09/09/23 16:28:
>> If you search within the QuantLib code for BoxMullerGaussianRng, you 
>> will see
>> it is used only in the experimental folder. It is therefore not 
>> surprising if
>> it doesn't produce the expected results.
>>
>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, 
>> which is used
>> extensively in other areas of QuantLib.
>>
>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me 
>> good
>> results.
>>
>> Ioannis Rigopoulos, founder of deriscope.com
>>
>> On 9/9/2023 11:25 AM, U.Mutlu wrote:
>>> A short standalone test code in C++ with test results posted online at
>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861368 
>>>
>>>
>>> demonstrates that the GBM method in QuantLib
>>> is fatally buggy and has been so since start.
>>>
>>> Can the experts please check it and comment it.
>>> It's suspicious that such a flaw in a very important part of the 
>>> library
>>> (GBM and Monte Carlo)
>>> got undetected by the experts and the user community for more that 
>>> 20+ years.
>>>
>>> Can the experts verify / confirm / duplicate the findings made there?
>>> Or is maybe that test code itself buggy or the test method maybe 
>>> unscientific?
>

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: [Quantlib-users] Some list mails missing

[U.Mutlu <um...@mu...>]

Luigi, your below posting of today morning as well I did not
receive but found only in the archive.

Normally in case of such problems the sending mail server tries to
resend it later, but your mail server seems not to try to resend it.

Look what google says at 
https://support.google.com/mail/answer/6596#zippy=%2Crecipient-server-did-not-accept-our-requests

It says "Try sending the email again later.", ie. the user has to do it 
manually. That's very funny :-)

"
"Recipient server did not accept our requests"
Why your message bounced
You'll see this error message if Gmail can’t connect to your recipient’s email 
server.

What you can do
The problem usually goes away quickly without you doing anything. Try sending 
the email again later.

If you keep getting the error:

Check if there are any mistakes in the recipient's email address.
Contact the customer support team of your recipient's email provider.
If you got this error while emailing someone at your work, school, or other 
organization, contact your administrator.
"

I checked my server, but could not find anything related in the logs.
I now have disabled IPv6 as I don't need it on that server, and rebooted the 
server.
I will also contact my hosting provider about this problem. Thx.



Luigi B. <lui...@gm...> on 2023-09-10 07:12:54 wrote
 >
 > I don't think the problem is in the mailing list.  I was replying to your
 > address directly, not through the mailing list, and I've been getting
 > warnings all week like the one below.  The same happened when I replied to
 > the private email you sent to me.  It seems to me the emails were all sent,
 > but it's your server that's not behaving.
 >
 > Luigi
 > Message not delivered
 > There was a problem delivering your message to *um...@mu...*. See the
 > technical details below.
 > LEARN MORE <https://support.google.com/mail/answer/7720>
 > The response was:
 >
 > The recipient server did not accept our requests to connect. Learn more at
 > https://support.google.com/mail/answer/7720 [mail.mutluit.com.
 > 195.201.130.20: timed out] [mutluit.com. 195.201.130.20: timed out]
 >
 > On Sat, Sep 9, 2023 at 9:33 PM U.Mutlu <um...@mu...> wrote:
 >
 > > I today learned that some of the recent mails posted in this mailing list
 > > did not make to my email client.
 > > For example the following posting by Jonathan S. on 2023-09-05 12:53:12
 > > I only saw today on the web when I did some searching
 > > in the archive at sourceforge:
 > > https://sourceforge.net/p/quantlib/mailman/message/37892292/
 > >
 > > Folks, I think such commercial sites are very unreliable
 > > for such open source projects.
 > > It's IMO a nightmare situation for all list subscribers,
 > > especially for active participants.
 > >
 > > What about switching the mailing list provider?
 > > Where one also can download the old postings, which IMO is not possible at
 > > this sourgeforge site.

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts? (SOLVED)

[U.Mutlu <um...@mu...>]

As said in other posting here, after fixing the test program
by skipping the first item (the initial price) in the
generated sample path, BoxMullerGaussianRng now passes the said test.

The bugfixed test code and the new test results can be found here:
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666

That important fact that the generated sample path contains
not timeSteps elements but 1 + timeSteps elements needs
to be documented in the library doc.
For example on this API doc page one normally would expect
to find such an important information, but it's missing:
https://www.quantlib.org/reference/class_quant_lib_1_1_path_generator.html

If you or someone else can change/extend the test program by using
the suggested alternative(s) to BoxMullerGaussianRng, I would be happy
to hear about it. Thx.


Ioannis Rigopoulos wrote on 09/09/23 16:28:
> If you search within the QuantLib code for BoxMullerGaussianRng, you will see
> it is used only in the experimental folder. It is therefore not surprising if
> it doesn't produce the expected results.
>
> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which is used
> extensively in other areas of QuantLib.
>
> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me good
> results.
>
> Ioannis Rigopoulos, founder of deriscope.com
>
> On 9/9/2023 11:25 AM, U.Mutlu wrote:
>> A short standalone test code in C++ with test results posted online at
>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861368
>>
>> demonstrates that the GBM method in QuantLib
>> is fatally buggy and has been so since start.
>>
>> Can the experts please check it and comment it.
>> It's suspicious that such a flaw in a very important part of the library
>> (GBM and Monte Carlo)
>> got undetected by the experts and the user community for more that 20+ years.
>>
>> Can the experts verify / confirm / duplicate the findings made there?
>> Or is maybe that test code itself buggy or the test method maybe unscientific?

Re: [Quantlib-users] Some list mails missing

[Luigi B. <lui...@gm...>]

I don't think the problem is in the mailing list.  I was replying to your
address directly, not through the mailing list, and I've been getting
warnings all week like the one below.  The same happened when I replied to
the private email you sent to me.  It seems to me the emails were all sent,
but it's your server that's not behaving.

Luigi
Message not delivered
There was a problem delivering your message to *um...@mu...*. See the
technical details below.
LEARN MORE <https://support.google.com/mail/answer/7720>
The response was:

The recipient server did not accept our requests to connect. Learn more at
https://support.google.com/mail/answer/7720 [mail.mutluit.com.
195.201.130.20: timed out] [mutluit.com. 195.201.130.20: timed out]

On Sat, Sep 9, 2023 at 9:33 PM U.Mutlu <um...@mu...> wrote:

> I today learned that some of the recent mails posted in this mailing list
> did not make to my email client.
> For example the following posting by Jonathan S. on 2023-09-05 12:53:12
> I only saw today on the web when I did some searching
> in the archive at sourceforge:
> https://sourceforge.net/p/quantlib/mailman/message/37892292/
>
> Folks, I think such commercial sites are very unreliable
> for such open source projects.
> It's IMO a nightmare situation for all list subscribers,
> especially for active participants.
>
> What about switching the mailing list provider?
> Where one also can download the old postings, which IMO is not possible at
> this sourgeforge site.
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Fwd: Re: QuantLib's GBM found flawed. What say the experts? (SOLVED)

[U.Mutlu <um...@mu...>]

(Resending b/c it seems postings with attachments (zip) get silently discarded)


The bugfixed version (v1.1) can be found here:
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861666

     History:
       2023-09-09-Sa: v1.1 Fixed a bug in accessing the generated path data: now
skipping 0th element and still taking timeSteps elements

     Expected for 1SD:
       timeSteps   HitRate
          1         68.27%    cf. [3]
          2         76.27%    cf. [4]
          3         79.29%
          4         80.79%
          5         81.66%
         10         83.33%
        100         84.77%
       1000         84.92%

     Results of QuantLib testing:
       timeSteps   HitRate
          1         68.46%
          2         75.59%
          3         78.42%
          4         79.93%
          5         80.94%
         10         82.85%
        100         84.33%
       1000         85.55%

These new test results, after fixing the test program in v1.1, show that
QuantLib's GBM using the BoxMullerGaussianRng<MersenneTwisterUniformRng> is OK.
It seems that Ito's lemma does not get used, b/c otherwise the result would
differ much.



U.Mutlu wrote in other thread on 09/10/23 02:39:
   > Finally found the bug:
   >
   > The loop below must be so:
   >   for (size_t j = 1; j <= timeSteps; ++j)
   >
   > This of course invalidates the old test results
   > Will see how good the results are now, but it looks much better now.

Re: [Quantlib-users] RandomSequenceGenerator first element always equals startingPrice

[U.Mutlu <um...@mu...>]

Finally found the bug:

The loop below must be so:
   for (size_t j = 1; j <= timeSteps; ++j)

This of course invalidates the old test results.
Will see how good the results are now, but it looks much better now.


U.Mutlu wrote on 09/10/23 02:24:
> Hmm, are you sure Luigi? B/c it does not work.
> I have such a code and using timeSteps = 1.
> How do you mean one can get out 2 values from this path?
> Is it possible at all? It seems not possible.
>
>   ...
>   PathGenerator<RandomSequenceGenerator<MersenneBoxMuller>>
> gbmPathGenerator(gbm, t, timeSteps, gsg, false);
>   const Path& samplePath = gbmPathGenerator.next().value;
>
>   for (size_t j = 0; j < timeSteps; ++j)
>     {
>       const auto Sx = samplePath.at(j);
>       ...
>
>
> Luigi B. <lui...@gm...> on 2023-09-05 12:47:38 wrote:
>  >
>  >    the first point of the path corresponds to t=0, therefore it contains
>  > the starting price.  Passing timeSteps = 1 to the generator should give you
>  > sample paths with 2 points, that is, the starting point and the one after
>  > the time step.
>  >
>  >
>  > > On Mon, Sep 4, 2023 at 10:54 PM U.Mutlu <um...@mu...> wrote:
>  > >
>  > > I've the following, possibly very old, code for generating GBM values.
>  > > It practically requires that nIntervalls_in_t (ie. timeSteps)
>  > > must be >= 2 b/c the first generated value always equals the passed
>  > > startingPrice.
>  > > Is this behavior hardcoded in QuantLib or can this be overridden
>  > > via a setting or function call, so that it shall not return always
>  > > the startingPrice as the first value
>
>
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] RandomSequenceGenerator first element always equals startingPrice

[U.Mutlu <um...@mu...>]

Hmm, are you sure Luigi? B/c it does not work.
I have such a code and using timeSteps = 1.
How do you mean one can get out 2 values from this path?
Is it possible at all? It seems not possible.

  ...
  PathGenerator<RandomSequenceGenerator<MersenneBoxMuller>> 
gbmPathGenerator(gbm, t, timeSteps, gsg, false);
  const Path& samplePath = gbmPathGenerator.next().value;

  for (size_t j = 0; j < timeSteps; ++j)
    {
      const auto Sx = samplePath.at(j);
      ...


Luigi B. <lui...@gm...> on 2023-09-05 12:47:38 wrote:
 >
 >    the first point of the path corresponds to t=0, therefore it contains
 > the starting price.  Passing timeSteps = 1 to the generator should give you
 > sample paths with 2 points, that is, the starting point and the one after
 > the time step.
 >
 >
 > > On Mon, Sep 4, 2023 at 10:54 PM U.Mutlu <um...@mu...> wrote:
 > >
 > > I've the following, possibly very old, code for generating GBM values.
 > > It practically requires that nIntervalls_in_t (ie. timeSteps)
 > > must be >= 2 b/c the first generated value always equals the passed
 > > startingPrice.
 > > Is this behavior hardcoded in QuantLib or can this be overridden
 > > via a setting or function call, so that it shall not return always
 > > the startingPrice as the first value

Re: [Quantlib-users] RandomSequenceGenerator first element always equals startingPrice

[U.Mutlu <um...@mu...>]

Jonathan S. <sw...@gm...> on 2023-09-05 12:53:12 wrote:
 >
 > 1. Could you provide a bit more info on why you want a path containing a
 > single step? The typical use case for PathGenerator is for many steps, with
 > the value at the first step (i.e. at t_0) being equal to the starting
 > price. Maybe what you're looking for isn't a path, but something else.

I'm doing a research on GBM implementations out there in the field
by running Monte Carlo simulations to see how good the generated data is
by comparing it to the table below of timeSteps and ExpectedHitRate%:

I was not able to use timeSteps=1 in QuantLib for verifying
the first case below. timeSteps >= 2 is doable, but as said
the results are far from being correct.
Recent postings here suggested to replace the use of Box-Muller
class by some other classes; I'm now trying to test that too.


Expected HitRate% for 1SD around initial stock price for varying GBM timeSteps
This table is an extension of https://en.wikipedia.org/wiki/68–95–99.7_rule as 
there only timeStep=1 is given.
These numbers are exact values, not the result of simulations.
Params used: S=100 rPct=0 qPct=0 IV=30(s=0.3) DIY=365.00 DTE=365(t=1 dt=1 
dd=365) zFm=-1(SxFm=74.081822) zTo=++1(SxTo=134.985881)
    timeSteps   Expected_HitRate
           1       68.2689%   cf. https://en.wikipedia.org/wiki/68–95–99.7_rule
           2       76.2695%
           3       79.2918%
           4       80.7919%
           5       81.6648%
           6       82.2304%
           7       82.6265%
           8       82.9197%
           9       83.1461%
          10       83.3265%
          15       83.8653%
          20       84.1337%
          25       84.2942%
          30       84.4010%
          35       84.4771%
          40       84.5341%
          45       84.5785%
          50       84.6139%
          60       84.6671%
          70       84.7050%
          80       84.7334%
          90       84.7555%
         100       84.7732%
         500       84.9003%
        1000       84.9162%
       10000       84.9305%
      100000       84.9319%
     1000000       84.9320%
    10000000       84.9320%

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts?

[U.Mutlu <um...@mu...>]

I think Ito's lemma is the big culprit here. Ito's lemma is IMO
misused in the whole field, and should especially not be used
in GBM since GBM uses timeSteps...

I'm 100% sure that one really does not need this Ito's lemma stuff,
neither in GBM nor in the Black-Scholes-Merton (BSM) option pricing formula.
Dunno about fields beyond these 2 cases.

Just ask me if you need a proof for the BSM case.

The GBM case (using the standard GBM algoritm with Ito's lemma)
was proven to be incorrect just some weeks ago, again by me:
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-3#post-5849548
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5851336

I wonder why the academia favors and is using this Ito's lemma stuff,
as it's really unnecessary, IMO.


Peter Caspers wrote on 09/09/23 20:24:
> Also notice that the (Ito-) solution of the SDE of
> GeometricBrownianMotionProcess
>
>              dS(t, S)= \mu S dt + \sigma S dW_t.
>
> see here
>
> https://github.com/OpenSourceRisk/QuantLib/blob/00d2fced875622c1f52d9025b3ab01d04729eee8/ql/processes/geometricbrownianprocess.hpp#L36
>
> is lognormally distributed with parameters
>
> ln S(t) ~ N( \mu * t - 0.5 * \sigma^2 * t, \sigma^2 * t ).
>
> Your testing code seems to assume
>
> ln S(t) ~ N( \mu, \sigma^2 * t).
>
> on the other hand. So maybe this is just a misunderstanding of the
> parameters going into the constructor of
> GeometricBrownianMotionProcess?
>
> Best
> Peter
>
> On Sat, 9 Sept 2023 at 16:45, Ioannis Rigopoulos <qua...@de...> wrote:
>>
>> If you search within the QuantLib code for BoxMullerGaussianRng, you
>> will see it is used only in the experimental folder. It is therefore not
>> surprising if it doesn't produce the expected results.
>>
>> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which
>> is used extensively in other areas of QuantLib.
>>
>> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
>> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me
>> good results.
>>
>> Ioannis Rigopoulos, founder of deriscope.com
>>
>> On 9/9/2023 11:25 AM, U.Mutlu wrote:
>>> A short standalone test code in C++ with test results posted online at
>>> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861368
>>>
>>> demonstrates that the GBM method in QuantLib
>>> is fatally buggy and has been so since start.
>>>
>>> Can the experts please check it and comment it.
>>> It's suspicious that such a flaw in a very important part of the
>>> library (GBM and Monte Carlo)
>>> got undetected by the experts and the user community for more that 20+
>>> years.
>>>
>>> Can the experts verify / confirm / duplicate the findings made there?
>>> Or is maybe that test code itself buggy or the test method maybe
>>> unscientific?
>>>
>>>
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Some list mails missing

[U.Mutlu <um...@mu...>]

I today learned that some of the recent mails posted in this mailing list
did not make to my email client.
For example the following posting by Jonathan S. on 2023-09-05 12:53:12
I only saw today on the web when I did some searching
in the archive at sourceforge:
https://sourceforge.net/p/quantlib/mailman/message/37892292/

Folks, I think such commercial sites are very unreliable
for such open source projects.
It's IMO a nightmare situation for all list subscribers,
especially for active participants.

What about switching the mailing list provider?
Where one also can download the old postings, which IMO is not possible at 
this sourgeforge site.

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts?

[Peter C. <pca...@gm...>]

Also notice that the (Ito-) solution of the SDE of
GeometricBrownianMotionProcess

            dS(t, S)= \mu S dt + \sigma S dW_t.

see here

https://github.com/OpenSourceRisk/QuantLib/blob/00d2fced875622c1f52d9025b3ab01d04729eee8/ql/processes/geometricbrownianprocess.hpp#L36

is lognormally distributed with parameters

ln S(t) ~ N( \mu * t - 0.5 * \sigma^2 * t, \sigma^2 * t ).

Your testing code seems to assume

ln S(t) ~ N( \mu, \sigma^2 * t).

on the other hand. So maybe this is just a misunderstanding of the
parameters going into the constructor of
GeometricBrownianMotionProcess?

Best
Peter

On Sat, 9 Sept 2023 at 16:45, Ioannis Rigopoulos <qua...@de...> wrote:
>
> If you search within the QuantLib code for BoxMullerGaussianRng, you
> will see it is used only in the experimental folder. It is therefore not
> surprising if it doesn't produce the expected results.
>
> I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which
> is used extensively in other areas of QuantLib.
>
> This type expands to InverseCumulativeRsg< RandomSequenceGenerator<
> MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me
> good results.
>
> Ioannis Rigopoulos, founder of deriscope.com
>
> On 9/9/2023 11:25 AM, U.Mutlu wrote:
> > A short standalone test code in C++ with test results posted online at
> > https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861368
> >
> > demonstrates that the GBM method in QuantLib
> > is fatally buggy and has been so since start.
> >
> > Can the experts please check it and comment it.
> > It's suspicious that such a flaw in a very important part of the
> > library (GBM and Monte Carlo)
> > got undetected by the experts and the user community for more that 20+
> > years.
> >
> > Can the experts verify / confirm / duplicate the findings made there?
> > Or is maybe that test code itself buggy or the test method maybe
> > unscientific?
> >
> >
> >
> > _______________________________________________
> > QuantLib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] QuantLib's GBM found flawed. What say the experts?

[Ioannis R. <qua...@de...>]

If you search within the QuantLib code for BoxMullerGaussianRng, you 
will see it is used only in the experimental folder. It is therefore not 
surprising if it doesn't produce the expected results.

I use myself the MultiPathGenerator with PseudoRandom::rsg_type, which 
is used extensively in other areas of QuantLib.

This type expands to InverseCumulativeRsg< RandomSequenceGenerator< 
MersenneTwisterUniformRng > , InverseCumulativeNormal > and gives me 
good results.

Ioannis Rigopoulos, founder of deriscope.com

On 9/9/2023 11:25 AM, U.Mutlu wrote:
> A short standalone test code in C++ with test results posted online at
> https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861368 
>
> demonstrates that the GBM method in QuantLib
> is fatally buggy and has been so since start.
>
> Can the experts please check it and comment it.
> It's suspicious that such a flaw in a very important part of the 
> library (GBM and Monte Carlo)
> got undetected by the experts and the user community for more that 20+ 
> years.
>
> Can the experts verify / confirm / duplicate the findings made there?
> Or is maybe that test code itself buggy or the test method maybe 
> unscientific?
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com

[Quantlib-users] QuantLib's GBM found flawed. What say the experts?

[U.Mutlu <um...@mu...>]

A short standalone test code in C++ with test results posted online at
https://www.elitetrader.com/et/threads/simulating-stock-prices-using-gbm.375533/page-4#post-5861368
demonstrates that the GBM method in QuantLib
is fatally buggy and has been so since start.

Can the experts please check it and comment it.
It's suspicious that such a flaw in a very important part of the library (GBM 
and Monte Carlo)
got undetected by the experts and the user community for more that 20+ years.

Can the experts verify / confirm / duplicate the findings made there?
Or is maybe that test code itself buggy or the test method maybe unscientific?

Re: [Quantlib-users] Irregular Schedule

[Steve H. <war...@gm...>]

Hi Michael
Schedule also has constructor that take irregular dates.

Here is the C++ constrictor,
  Schedule
<https://rkapl123.github.io/QLAnnotatedSource/d5/d5b/class_quant_lib_1_1_schedule.html#a19ab5a444f1f8c74856f75a8e16915d4>
 (const std::vector< Date
<https://rkapl123.github.io/QLAnnotatedSource/db/d60/class_quant_lib_1_1_date.html>
 > &, Calendar
<https://rkapl123.github.io/QLAnnotatedSource/da/d3e/class_quant_lib_1_1_calendar.html>
calendar
<https://rkapl123.github.io/QLAnnotatedSource/d5/d5b/class_quant_lib_1_1_schedule.html#a4ffdceafee5fe94e7646e4f04300ba18>
=NullCalendar
<https://rkapl123.github.io/QLAnnotatedSource/da/d77/class_quant_lib_1_1_null_calendar.html>
(), BusinessDayConvention
<https://rkapl123.github.io/QLAnnotatedSource/d1/d37/group__datetime.html#gaff46c5ae9385d20709bedade86edd368>
convention=Unadjusted
<https://rkapl123.github.io/QLAnnotatedSource/d1/d37/group__datetime.html#ggaff46c5ae9385d20709bedade86edd368a5fb8b90b7fdf1a3a228fbbc083e64547>,
const ext::optional< BusinessDayConvention
<https://rkapl123.github.io/QLAnnotatedSource/d1/d37/group__datetime.html#gaff46c5ae9385d20709bedade86edd368>
 > &terminationDateConvention=ext::nullopt
<https://rkapl123.github.io/QLAnnotatedSource/d4/d5c/namespace_quant_lib_1_1ext.html#a3d1f3fb2cb126ecea6a56dd80734c3d3>,
const ext::optional< Period
<https://rkapl123.github.io/QLAnnotatedSource/df/dfa/class_quant_lib_1_1_period.html>
 > &tenor
<https://rkapl123.github.io/QLAnnotatedSource/d5/d5b/class_quant_lib_1_1_schedule.html#afc2f7230de3dbcc6b4808594aec7eb5e>
=ext::nullopt
<https://rkapl123.github.io/QLAnnotatedSource/d4/d5c/namespace_quant_lib_1_1ext.html#a3d1f3fb2cb126ecea6a56dd80734c3d3>,
const ext::optional< DateGeneration::Rule
<https://rkapl123.github.io/QLAnnotatedSource/dc/dcb/struct_quant_lib_1_1_date_generation.html#a11fcd51ef86118f65e603c1474377a78>
 > &rule
<https://rkapl123.github.io/QLAnnotatedSource/d5/d5b/class_quant_lib_1_1_schedule.html#ab66924874e68d30a2306b3f2b2c732a0>
=ext::nullopt
<https://rkapl123.github.io/QLAnnotatedSource/d4/d5c/namespace_quant_lib_1_1ext.html#a3d1f3fb2cb126ecea6a56dd80734c3d3>,
const ext::optional< bool
<https://rkapl123.github.io/QLAnnotatedSource/d9/db9/classbool.html> > &
endOfMonth
<https://rkapl123.github.io/QLAnnotatedSource/d5/d5b/class_quant_lib_1_1_schedule.html#a76bf4d1422680b11983bf2908b42a9d5>
=ext::nullopt
<https://rkapl123.github.io/QLAnnotatedSource/d4/d5c/namespace_quant_lib_1_1ext.html#a3d1f3fb2cb126ecea6a56dd80734c3d3>,
std::vector< bool
<https://rkapl123.github.io/QLAnnotatedSource/d9/db9/classbool.html> >
isRegular
<https://rkapl123.github.io/QLAnnotatedSource/d5/d5b/class_quant_lib_1_1_schedule.html#a63e84fe150fbc4f4b18b0b52e75cac06>
=std::vector< bool
<https://rkapl123.github.io/QLAnnotatedSource/d9/db9/classbool.html> >(0))


Following is a sample Python code.

payment_dates = [ql.Date(1,8,2023), ql.Date(7,12,2023), ql.Date(1,4,2024),
ql.Date(27,5,2024)]

is_regular_period = [False, False, False]

irregularSchedule = ql.Schedule(payment_dates, ql.NullCalendar(),
ql.Unadjusted, None, None, None, True,is_regular_period)

Best,
Steve

On Fri, Sep 8, 2023 at 5:33 AM Michael (DataDriven portal) <
mi...@da...> wrote:

> Hi All,
>
> I have a bond with irregular schedule dates and would like to set up the
> bond's Schedule using the list of dates e.g. like  *[Date(15,1,2015),
> Date(15,7,2015), Date(15,7,2016)].* Is it possible to do this in QuantLib?
>
> The only syntax for Schedule that I found (below) allows to create a
> schedule for a given frequency, frequency, etc
>
> *ql.Schedule(issueDate, maturityDate,ql.Period(ql.Annual), ql.TARGET(),
> ql.Following, ql.Following, ql.DateGeneration.Backward, False)*
>
> I would appreciate any help!
>
> Thanks,
>
> Michael
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Rationale behind LazyObject::alwaysForward_ and Observable::DeferredNotification

[SX L <han...@ho...>]

Hi,

I found the LazyObject and Observer pattern are slightly different from the standard ones. Can someone share some scenarios to demonstrate the rationale behind the implementation? Thanks.

Regards,

Philip

[Quantlib-users] Irregular Schedule

[Michael (D. portal) <mi...@da...>]

Hi All,

I have a bond with irregular schedule dates and would like to set up the
bond's Schedule using the list of dates e.g. like  *[Date(15,1,2015),
Date(15,7,2015), Date(15,7,2016)].* Is it possible to do this in QuantLib?

The only syntax for Schedule that I found (below) allows to create a
schedule for a given frequency, frequency, etc

*ql.Schedule(issueDate, maturityDate,ql.Period(ql.Annual), ql.TARGET(),
ql.Following, ql.Following, ql.DateGeneration.Backward, False)*

I would appreciate any help!

Thanks,

Michael