> > A DBMS is a good way to keep your raw data. But I highly doubt that a > majority of your analysis algorithms are going to be expressible in SQL > without going way beyond the intended purpose of the language.
I think you are right, but the cases where it can be expressed in SQL means it can also be exploited by SQL and that's what I'm after. What I mean, is simply being able to apply existing functions that work on float values, and apply them to the result of other functions. The financial math is filled with these... for example, one guy develops the rate of change of the price of a stock (roc) which shows the basic difference between price today and price X days ago. Then another guy decides to smooth the result through a moving average. There is yet one more guy to come in the future and divide the result by some other result, and yet another guy in the future to smooth that through another moving average, and so on. I understand there are other ways outside SQL to do this. I know. I believe I can code a moving average within 5-15 minutes, but that's not the point, that's the last resort. > You will either find yourself limiting the analyses to what is convenient > to express in SQL, or you will spend much more time writing queries than > you would spend describing your data processing in a form more suited to > functions. SQL is primarily a language for extracting sets from other > sets, according to defined criteria (which include set relationships). Your > analyses, unless they are like nothing I've ever seen or imagined, are > going to be derived from functions on time series rather than sets, per se. > I expect you would find a signal processing library, such as can be found > in Matlab, Octave, or Scilab, to be a much better start than what you might > write in SQL in reasonable time. > I will definitely look into it. Although I might appear to, I don't want to close doors just because I have a strong desire to do things my way! ;) > That said, it is not hard to imagine that selection of datasets might be > done with SQL, and perhaps some query criteria might include measures > derived from your own custom functions on time series. As I mentionned in reply to petite-abeille, a mix of a cross-join and custom aggregate functions might lead to the concept of analytical functions. > There is no real either/or choice posed here. You can create your own > custom functions to be incorporated into SQLite queries, including > aggregate functions. The aggregate functions might produce some output > other than what is returned to SQLite. What I think will be unreasonable > or unduly limiting is making it happen in bare SQLite. You will need more. > It comes back to your first statement "I highly doubt that a majority of your analysis algorithms are going to be expressible in SQL [...]". The key is determining what needs to be in the core and what needs not. And perhaps, what simply cannot be...! But I'm just getting started and I will start my undergrad studies in maths in September, until then, I have plenty of time to struggle with the basics! ;) Thanks a lot for the information and guidance you provided, Simon _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
