On Mon, 27 Apr 2015 16:35:11 -0400 Jim Callahan <jim.callahan.orlando at gmail.com> wrote:
> So, the application of arrays and complex numbers go far beyond the > one question posed to this list with arrays of integers and reals > being far more common than arrays of complex numbers. > > Complex numbers are included as types in C, C#, FORTRAN and Python > and are being added to server databases (Oracle and Microsoft SQL > Server) as user defined types, so programmers and server database > administrators may develop an expectation that complex types or user > defined types will be supported SQLite3. Useful as complex numbers and arrays are to scientific work, SQLite is deficient in ordinary math. Division by zero yields NULL, for example. The usual suite of mathematical functions such as declared in math.h are absent, never mind linear algebra. Even enforcing the rule that a column always hold a number is inconvenient at best. > I would expect that users of complex numbers would be an > extremely small subset of data base users Yes, and database users are a small subset of scientific programmers. As some of the papers you cited allude to, there is some work (thanks in part to Jim Gray) to answer the needs of that subset. Most of that work, though -- already a subset of subset -- focuses on giant datasets. "SQLite for science" is thus a small population by almost any measure. IMO a "scientific DBMS" comprises two separate good ideas. Neither one has been solved. The first is efficient computation over "array-like" stuff, alerting the computation engine that it is working with arrays, not sets, and/or directly invoking existing libraries e.g. BLAS. A major hurdle is the memory model: because array-programming libraries normally mandate the data be in contiguous memory, there's a cost to converting to/from the DBMS's B+ tree. The more array-like the physical storage of the DBMS, the more it cedes transactional and update capability. The second is expression of mathematics in a database language. SciQL goes some distance in that direction by making tables and arrays interchangable, but the battle is not yet won. I suspect a better answer would arise from APL-for-databases than SQL-for-math. But, see above, not exactly a popular topic. --jkl
