[Kde-finance-apps] Brainstorming requirements for an Alkimia Quotes Backend: Feedback/Reality-Check Needed Please :)

[Brian Cappello]

>
> > Also, is there any way I could maybe get a consensus on whether or not
> "the
> > powers that be" would ever allow TA-Lib to eventually be integrated into
> > this? The reason I ask is because it seems to me to determine whether I
> use
> > std arrays or QLists for storing prices. QLists are obviously more
> > convenient/less bookkeeping, but, they also don't work with TA-Lib. At
> least
> > not without copying all the data first, which I suppose isn't the end of
> the
> > world. Any strong opinions either way?
> >
>
> It has a BSD-license, which is open, but not quite easy to mix with
> GPL code without a special exception. We went through such a problem
> with OpenGPG and it was such a big deal Thomas had to use a whole
> different library.
> Does TA-lib provide such an advantage?
> KOffice has a good library for math, we could try to use that one if it
> fits.
>

I'll definitely look into that. TA-Lib is a relatively
complete/mature/tested project (started in '99 and still active) that
specifically targets the arguably "specialized" method of technical
analysis, so in that regard, personally I'd call that an advantage. But
considering the fact that for many people its functionality either falls
under the category of a "fancy extra" or (IMO foolishly shortsightedly)
"hogwash," I certainly wouldn't want to make it a required component.
Depending upon on what KOffice's math libs are capable of, that could
possibly make for a very good way to provide some limited functionality
without any "excess" external dependencies. But, even without having looked,
I really can't imagine KOffice's capabilities go very far beyond standard
statistical stuffs and simple/exponential moving averages. Meanwhile, TA-Lib
provides some 150+ indicators/pattern recognitions specifically designed and
tweaked for financial market analysis. (Granted, probably 3/4 of those can
be "easily" recreated with basic algebra and simple/exponential moving
averages (and/or less commonly statistics stuff) - but, the way I see it,
why reinvent the wheel?)

Anyways, between yours and Thomas' input and my now being able to better
understand the AlkValue class, I think I'm going to try to store prices as
QList<AlkValue> (as opposed to float[] or double[]). If at some point down
the road I've learned enough to be able to write code that can detect and
work with optional dependencies, then maybe I'll consider adding TA-Lib
support via a "middle man" prices holder class. [Memory just keeps getting
cheaper, no?] But, in the mean time, it's beginning to seem a little dumb to
trade off both convenience and accuracy for the possibility of future
laziness :)  [Or maybe I'm missing/don't know something? I know that happens
all the time with me... :]


> Regards,
> Alvaro
> _______________________________________________
> Kde-finance-apps mailing list
> Kde-finance-apps at kde.org
> https://mail.kde.org/mailman/listinfo/kde-finance-apps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-finance-apps/attachments/20100526/f50b868f/attachment-0001.htm