On Fri, Apr 24, 2015 at 3:37 PM, Drago, William @ CSG - NARDA-MITEQ < William.Drago at l-3com.com> wrote:
> I'm trying to avoid re-inventing the wheel. Is there a best or generally > accept way to store arrays of complex numbers? I'm considering the > following: > > I could have two blob fields in my table. One for the real parts and one > for the imaginary. (I don't like this.) > Or, I could use a single blob field and concat the real and imaginary > parts into one long blob. (I like this.) > Or, I could store pairs in the blob > (realimaginaryrealimaginaryrealimaginaryrealimaginary). (I like this.) > > Or maybe there's a real nifty way to handle complex numbers that I haven't > thought of. > Unfortunately, if you do this, you DB/schema is not longer portable ( endianess issues), and becomes "opaque" (must know a-priori what the blob contains, and worse in what organization, i.e. your #1 or #2 or #3). SQLite pundits would tell you to store your real/imag floating-points in tables I guess. Forcing you to add an order col, and a FK back to the owner of the complex numbers in another table. But that's much less efficient as a storage mechanism. Others (like Steven) would tell you to store it in some human-readable text format (JSON, XML, YAML, TOML, whatever), but that forces to parse and adds a dependency on some parser. A middle ground is using some self-describing binary format and stay with blob, like AVRO for example, or CBOR perhaps, (or HDF5 with a custom VFS) to at least have a magic cookie in the blob to infer the format, and some portability. But still a dependency on some serializing library. These are all I'm afraid not very satisfactory. In Oracle you'd create a custom Complex type, and another for a VARRAY of that type, and store that in a "cell" (row,col). But SQLite doesn't have built-in support for arrays, nor user-defined-types. So you remain stuck between the proverbial rock and the hard place... There are no good solution in SQLite for things like this. --DD
