Difference between revisions of "Talk:Lokad business forecasting"
| (8 intermediate revisions by 3 users not shown) | |||
| Line 63: | Line 63: | ||
:::So what I understand is: You have a very large set of points which you shatter every time you want to forecast a value. Each time you shatter the points, again you have a set of points as the candidates of forecasting to choose from. Would you please tell me how the selection is done, if what I've understood is right?<br> | :::So what I understand is: You have a very large set of points which you shatter every time you want to forecast a value. Each time you shatter the points, again you have a set of points as the candidates of forecasting to choose from. Would you please tell me how the selection is done, if what I've understood is right?<br> | ||
:::Thank you. Warm regards, --[[User:Bmovaqar|Bahman]] 08:36, 28 February 2007 (EST) | :::Thank you. Warm regards, --[[User:Bmovaqar|Bahman]] 08:36, 28 February 2007 (EST) | ||
| + | |||
| + | ::::I am not really sure to understand your last question. Lokad uses complicated sets of models associated to various optimization methods (please, don't ask for the detail). There are both computational constraints and statistical constraints. The forecasted point is the result of a risk minimization (empirical risk vs. structural risk).--[[User:Vermorel|Vermorel]] 16:44, 1 March 2007 (EST) | ||
| + | |||
| + | :::::What I really want to know is the accuracy of the algorithm. It would be kind of you if you would give some sort of a technical accuracy estimation...but maybe I'm talking about the things beyond the red line :-) Anyway thank you for your responses. --[[User:Bmovaqar|Bahman]] 01:19, 3 March 2007 (EST) | ||
| + | |||
| + | ::::::I can't tell you the accuracy of our algorithm because it mostly depends on the data that you use as input. For example, if Lokad was able to do 1% better that pure random guesses for stock prices, then it would already be a fantastic algorithm; but if you consider supply chain data, then typically accuracy ranges from 10% to 20% depending on the ''smoothness'' of the input data. --[[User:Vermorel|Vermorel]] 04:05, 3 March 2007 (EST) | ||
| + | |||
| + | :::::::Would you please tell me what do you mean by '10% or 20%'? You mean 10% of guesses are correct or the difference between the real value and the guess is about 10% of the real value? | ||
| + | :::::::Warm regards, --[[User:Bmovaqar|Bahman]] 06:48, 3 March 2007 (EST) | ||
| + | |||
| + | :::::::: I was talking about the difference between the forecasted value and the actual value expressed as a percentage. But, please take those estimates lightly; it really depends on the input data. --[[User:Vermorel|Vermorel]] 03:00, 5 March 2007 (EST) | ||
Latest revision as of 17:32, 10 April 2007
So far we have tested the add-on only with the latest version of ADempiere (3.14 at the time of this post) under Oracle database. Since this add-on relies on very elementary database tables of ADempiere, I would guess that we are actually supporting many different version of ADempiere. If you start using this add-on with different versions of ADempiere, do not hesitate to report that it works on the wiki page, or, on the contrary, to make a bug report if it does not. --Vermorel 04:22, 24 February 2007 (EST)
Welcome and many thanks Vermore, for such an important addon and well done finished works. U been added as the latest hottest add-on in http://www.adempiere.org! We appreciate the smart partnership to allow our users enjoy a more feature-rich application suite. This cross-brand of products and user-bases is mutually encouraged within the bazaar. Feel free to put in more of your relevant product or services info to advertise your business as needed. Equally do ask us if u need any further assistance. Like to also credit Carlos Ruiz who assisted in translating the LOKAD/ADempiere SQL query statement for this to work. - Red1 05:47, 24 February 2007 (EST)
Thank you very much for your support. I have added a special thanks section at the bottom of the page. Carlos Ruiz is also mentioned directly on the Lokad website (see the bottom of the Lokad Desktop page). I have also clarified the business model of Lokad based on the feedback of Ramiro Vergara.--Vermorel 09:39, 24 February 2007 (EST)
- There is new info that there is a non-free service from Lokad. We are discussing with Vermore further on what actually that model is, whether its restrictive to the OS nature or if it affects the GPLv2 licensing here. We welcome ideas from others meanwhile - Red1
- I will try to answer the questions that have been raised in the various emails. Concerning open source commitment, we are trying to make the things as open as possible. All the Lokad Desktop source code is being hosted on sourceforge.net, all documentation being made available through our wiki. Everything is released under a BSD license. It means that all the code can be reused within open or closed source products without any licensing hassle. In particular, the BSD license is compatible with the GPL license. We do (not) intend to ever change of licensing model because it would not make any sense in the Lokad business model. The more applications with business forecasting modules out-there, the more potential customers for Lokad.
- Concerning the question about vendor lock-in, we believe that the Lokad approach is fair. The Lokad forecasting technology is a commercial technology that requires a paid subscription plan. Yet, we are designing our products in a "clean" manner. If you want to replace the Lokad forecasting services by any other web services or by a locally implemented algorithm, it is completely straightforward (just a single class to replace). Yet, by doing that you would loose the two of main benefits of Lokad: collaborative forecasting (data are shared to improve accuracy on a collective basis) and accuracy monitoring (accuracy gets monitored in a continuous manner in order to maintain/improve the forecast accuracy).--Vermorel 12:19, 24 February 2007 (EST)
Winner takes all
- Vermore, i corrected a seeming typo do (not) above. Thanks for your sincere explanation. As long as it is within our Charter and Vision, all this is fine. Now our charter basically says that the 'Bazaar is Supreme' and determines all issues, thus time trials will tell. Meanwhile i like to humbly allude your consideration to making your model more globally branded and unassailable by totally going open source even on the call-in rent-based service. With an unattackable flag on the hill, every inch of your teritory turns to gold. Basically this is what another vertical add-on - posterita is exactly doing - by turning every inch of their wares out into the open they stand ALL chance, and their competition stands NO chance - Winner Takes All in this singularity dotcom space. Anyway, we are also meeting again in Germany this May, perhaps we meet up there to exchange more intensely on this. Meanwhile, we remain heartily thankful to your sharing effort. - - Red1 22:15, 24 February 2007 (EST)
Multi-parameter Series
I am evaluating Lokad and so I'm just a newbie.
Suppose I have a problem which is affected by two parameters, say Y and Z in a manner that Y effects Z. So the parameters are
T [the time, independent parameter],
Y = f(T) and
Z = g(Y)
How can I forecast both Y and Z?
1. Should I create 2 separate 'serie' for each of them?
2. Or should I create a TimeValue class with 2 values (Y) and (Z)?
I did the second approach but it seems that the graphs only take one parameter -Y- into account.
Am I right? If not please help me figure it out.
Warm Regards, --Bahman 06:53, 26 February 2007 (EST)
- Bahman, you are raising a important question. The answer is complex because it precisely depends on the nature of the relationship between the variables. I have tried to produce a meaningful and not too technical answer on the Lokad Blog today, see the post Notes about concurrent time-series.
- Hope this helps. Keep me informed if you need further information. --Vermorel 15:25, 26 February 2007 (EST)
I created two separate series:
Y = f(T) = Sin(T)(T*T - 1) / (3T), T=2,3,...,21 Z = g(Y) = (1/Y)Cos(3y/2), T=2,3,...,21
Both functions are continuous and derivable on the given domain and I don't feel these are complex functions for real business as many business relations are expressed through non-linear functions.
I added both of them programmatically using the Java demo project on SF[1].
Now the results seem a bit disappointing. Below you can see the forecasting graph for each variable:
The expected results for T=22,23,...,26 are (in place of the green bars):
Y = -0.0647 -6.475 -7.232 -1.101 6.599 Z = -15.365 0.148 0.020 0.073 -0.134
Am I totally going wrong?
Warm regards, --Bahman 07:13, 27 February 2007 (EST)
- No, you are not wrong. Yet, Lokad is absolutely not designed for the kind of situation that you are proposing. This is very unfortunate, but basically do not expect to get meaningful results out of Lokad for this kind of situation. Lokad is not a mathematical function regressor that tries to fit a simple mathematical expressions to explain the time-series patterns. They are several reason why Lokad will totally fail at that.
- First, Lokad implicitly assumes a lot of noise in the data. We do not assume that the time-series could be "explained" through simple mathematical functions because practical examples prove that it is totally untrue (sales or market prices tend to vary in erratic manners). Thus, Lokad makes no assumption such as "simple fit" for the time-series functions. Thus, Lokad will invariably fails for polynomials, trigonometric functions or whatever mathematical functions that you are choosing because it does not correspond to what Lokad has been designed for.
- Second, Lokad is anything but real-time. Thus, do not expect to get instant results with through the web interface. Lokad forecasting algorithms are running in the background, and it can takes a significant amount of time for the accuracy to increase (a couple of days typically). Again, this would be disappointing if you try to use Lokad as a mathematical regressor, but for practical situations (inventory optimization), it's almost totally unimportant if the system needs one week to get fully "stabilized" on the given sales data.
- I am really sorry for the disappointment. We have updated today our pricing terms in order to be sure that nobody gets charged for something that does not fulfill their needs.--Vermorel 14:28, 27 February 2007 (EST)
- Thank you for your quick responses. However I don't understand the idea behind Lokad forecasting, accepting 'business' values for series while there are no chances for 'mathematical' values. Would you please explain it a bit more, even technically? Thank you again. Warm regards --Bahman 06:21, 28 February 2007 (EST)
- The true answer to this question lies in the Vapnik Chervonenkis theory. Intuitively, the real problem is that you do not seek to build a model that is accurate for your historical data, the problem is to build a model that is accurate for the data, you do not have (typically future data). In your situation, there an infinite number of mathematical functions that could have produced the exact same values for the history points and different values for the future points. Thus, Lokad attempts to produce a meaningful answer with no assumption on the initial time-series which means exploring an unbounded function space. Hope it helps.--Vermorel 07:20, 28 February 2007 (EST)
- So what I understand is: You have a very large set of points which you shatter every time you want to forecast a value. Each time you shatter the points, again you have a set of points as the candidates of forecasting to choose from. Would you please tell me how the selection is done, if what I've understood is right?
- Thank you. Warm regards, --Bahman 08:36, 28 February 2007 (EST)
- So what I understand is: You have a very large set of points which you shatter every time you want to forecast a value. Each time you shatter the points, again you have a set of points as the candidates of forecasting to choose from. Would you please tell me how the selection is done, if what I've understood is right?
- The true answer to this question lies in the Vapnik Chervonenkis theory. Intuitively, the real problem is that you do not seek to build a model that is accurate for your historical data, the problem is to build a model that is accurate for the data, you do not have (typically future data). In your situation, there an infinite number of mathematical functions that could have produced the exact same values for the history points and different values for the future points. Thus, Lokad attempts to produce a meaningful answer with no assumption on the initial time-series which means exploring an unbounded function space. Hope it helps.--Vermorel 07:20, 28 February 2007 (EST)
- I am not really sure to understand your last question. Lokad uses complicated sets of models associated to various optimization methods (please, don't ask for the detail). There are both computational constraints and statistical constraints. The forecasted point is the result of a risk minimization (empirical risk vs. structural risk).--Vermorel 16:44, 1 March 2007 (EST)
- What I really want to know is the accuracy of the algorithm. It would be kind of you if you would give some sort of a technical accuracy estimation...but maybe I'm talking about the things beyond the red line :-) Anyway thank you for your responses. --Bahman 01:19, 3 March 2007 (EST)
- I can't tell you the accuracy of our algorithm because it mostly depends on the data that you use as input. For example, if Lokad was able to do 1% better that pure random guesses for stock prices, then it would already be a fantastic algorithm; but if you consider supply chain data, then typically accuracy ranges from 10% to 20% depending on the smoothness of the input data. --Vermorel 04:05, 3 March 2007 (EST)
- Would you please tell me what do you mean by '10% or 20%'? You mean 10% of guesses are correct or the difference between the real value and the guess is about 10% of the real value?
- Warm regards, --Bahman 06:48, 3 March 2007 (EST)
- I was talking about the difference between the forecasted value and the actual value expressed as a percentage. But, please take those estimates lightly; it really depends on the input data. --Vermorel 03:00, 5 March 2007 (EST)