Machine learning in trading: theory, models, practice and algo-trading - page 203
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Ok, accepted.
And why do you say, "...correctly so..."? From what considerations is it correct? Poke me again at Wolfram, where statistician Uncle John wrote "0".
You are stubbornly refusing to accept the reality, hiding behind "accepted, thank you. You even missed this time pointing to similar results in Matlab.
So you're going against the combination of MQL5 + Matlab + Wolfram + explanation, which proves the correctness of our conclusions, and defending orphan R standing alone with its error.
Your own thoughts as an expert as to why in zero the density is most appropriately defined as 0? And examples when defining density as 1 or inf becomes a problem?
Infinity in the integration interval can lead to problems with normalization. Do you have any examples of distributions where inf in the density does not lead to problems?
I reproduced the case where infinity returns.
The integral on the right at the zero point for a function with the same parameters counts as 1:
pgamma(0,0.5,1,log = FALSE,lower.tail = F)
That is, there is no problem defining it over the whole domain (no problem with the uncertainty at 0), which in practice means no problem. Maybe you are talking about something else, then please clarify...
And matlab or something else, doesn't matter to me. I can give you examples from the most popular programming languages where 0^0 will return 1. And...
You're engaging in religious branding, not understanding the difference between the concepts of "error" and "convenience". What some (and a very significant) portion of the mathematical community accepts as convenient you have branded as erroneous. That's what we've been writing to since the beginning.
Thank you.
Our approach - transfer your developments from R to MQL5 using our standard libraries.
Cool, no irony. But it's impossible to transfer all the custom R-functions and newly appearing ones, which contain the latest mathematical and algebraic achievements in different areas.
Where will you slow down? At what point would you say the porting is over?
I reproduced the case where infinity returns.
The integral on the right at the zero point for a function with the same parameters counts as 1:
pgamma(0,0.5,1,log = FALSE,lower.tail = F)
That is, there is no problem defining it over the whole domain (no problem with the uncertainty at 0), which in practice means no problem. Maybe you are talking about something else, then please clarify...
I'm not sure if this integral is counted using dgamma results, since infinity has disappeared somewhere. We can't debug this point, since it all happens inside R.
We need code (in any language) to calculate pgamma using dgamma where infinity is returned to trace the moment the infinity problem disappears.
I'm not sure if this integral is counted using the results of dgamma, since infinity has disappeared somewhere. We can't debug this point, since it all happens inside R.
We need code (in any language) to calculate pgamma using dgamma where infinity is returned to track when the infinity problem disappears.
Yes, we're not sure about that....
But how do you envision using dgamma to integrate on the whole spport? That's what pgamma is designed for...
You are stubbornly unwilling to accept reality, hiding behind "accepted, thank you". You even missed pointing out similar results in Matlab this time.
So you're going against a bunch of MQL5 + Matlab + Wolfram + explanation, which proves the correctness of our conclusions, and defend orphan R standing alone with its error.
Unfortunately no, all Quantum's explanations are "because that's how it is in Wolfram". The mentioned AS243 function gives an error of a decimal place, not 1, and it has nothing to do with the error in dgamma().
Alexey's explanation - the result of dgamma function at x=0 depends on the result 0^0= ?
R returns 1 to this question. Wolfram returns nothing. That's the difference. No one knows the right way, it's an undefined operation. And to say that 0^0 = 0 is the only right solution is kind of silly. But when calculating in such a situation, the software has to return something, so the creators of mathematical software return some constants at will. That there will be 0 is a personal decision of wolfram programmers, not the truth in the last resort. They could even flip a coin to choose between 0 and 1, and now someone is referring to it.
Calling a function with an invalid parameter, and then comparing the results with other programs, and then claiming to have found errors is somehow not academic. Your sixth point in the article as it stands is marketing, not math.
So soon you'll get to the point where you declare that R doesn't multiply infinities correctly, for example :)
Calling a function with an invalid parameter, and then comparing the results with other programs, and then claiming to have found errors is somehow not academic. Your sixth point in the article in its current form is marketing, not math.
Sadly no, Quantum's entire explanation is "because that's the way it is in Wolfram." The AS243 function mentioned gives an error of about a decimal place, not 1, and it has nothing to do with the error in dgamma().
Alexey's explanation - the result of dgamma function at x=0 depends on the result 0^0= ?
R returns 1 to this question. Wolfram returns nothing. That's the difference. No one knows the right way, it's an undefined operation. And to say that 0^0 = 0 is the only right solution is kind of silly. But when calculating in such a situation, the software has to return something, so the creators of mathematical software return some constants at will. The fact that there will be 0 is a personal decision of wolfram programmers, not the truth in the last instance. They could even flip a coin to choose between 0 and 1, and now someone is referring to it.
Calling a function with an invalid parameter, and then comparing the results with other programs, and then claiming to have found errors is somehow not academic. Your sixth point in the article as it stands is marketing, not math.
So soon you'll get to the point where you'll declare that R doesn't multiply infinities correctly, for example :)
Thank you.
I'm losing the desire to talk to the esteemed Renat here, because he's already branding me as well, accusing me of something that doesn't exist. There is a dialogue with Quantum, but he stubbornly refuses to answer the question of why what he is doing is "Right. Simply because there is no one right point of view on this issue. And that would entail having to change the wording in the article.
This is not the tone of scholarly discussion. This is forum whistleblowing.
We said that the phrase about the error was not correct, and it turns out that the people who were told it can't even understand what it's about. And suggest they take their word for it... Thank you, we will refrain.
Cool, without irony. But it is not possible to transfer all the custom R-functions and newly appearing ones that carry the latest math and algebraic advances in various fields.
Where will you slow down? At what point would you say the porting is over?
We don't need all of them, a basic set of mat functionality is enough. We all are not going to chase modules.
Target libraries will be written by the people for MQL5. We have created an ecosystem and managed to unite a great number of traders and developers. We will do the rest.