All, I always learn something from this group even when the answers don't directly solve my problem, and for that I am always thankful. Perhaps I should have included more information about what I'm trying to accomplish and/or phrased the question differently. That might have saved some time for the folks who replied. The problem is solved, but there's more info below if anyone is interested.
In this case the problem is very simple: All I have to do is store the data. I don't have to search it or perform any computations on it, and portability is not an issue as this is Windows only in-house code. The complex data array, which represents a network analyzer trace (similar to the trace on an oscilloscope), is processed by my application to extract the pertinent information which is stored in a properly normalized database. Once all the useful information has been extracted from the array there is no need to keep the array, however, as an extra measure of thoroughness I do keep it just in case something was missed and we need to look at it again sometime in the future. Since the data is received from the analyzer as an array of real/imaginary pairs (R,I,R,I,R,I,R,I...), 3202 elements total, that's how I will blob and store it. This is the simplest way to add it to the database. It's just one more field along with all the other data. If I ever need to operate on that trace data again it's a simple matter of pulling out of the database and un-blobbing it. Thank you for your suggestions, -- Bill Drago Senior Engineer L3 Narda-MITEQ 435 Moreland Road Hauppauge, NY 11788 631-272-5947 / William.Drago at L-3COM.com > -----Original Message----- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite- > users-bounces at mailinglists.sqlite.org] On Behalf Of James K. Lowden > Sent: Friday, April 24, 2015 12:42 PM > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] Thoughts on storing arrays of complex numbers > > On Fri, 24 Apr 2015 13:37:40 +0000 > "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? > > A table in First Normal Form has no repeating groups. That means no > row has an array of any kind. Arrays in the relational model are > represented in columns, one element per row. > > A column whose type is nonrepeating is said to be "atomic", but that's > something of a convention. An atom is supposed to be indivisible, but > we can take substrings of string, parts of dates, and exponents of > floating point numbers. So nonrepeating datatypes aren't necessarily > atomic, exactly. They're just not repeating. ;-) > > The question of your complex array then comes down to two apects: how > to represent the complex number, and how to represent the array. The > case for the array is simple: keep one complex number per row. The > case for the "divisible atomic" complex number depends on a choice: how > you want the DBMS to treat the components of the complex type. > > The most general solution -- and therefore probably the best one -- is > to keep the real and complex component each in its own REAL column. > That lets you sort and select the complex numbers using SQLite's built- > in functions without limitation. For example, if we call those > components "a" and "b", you could say, > > select * from T where "a" between 1.0 and 2.0 > > Such a table would be > > create table complex_array > ( name TEXT not null > , ordinal INTEGER not null > , real_part REAL not null > , imaginary REAL not null > , primary key( name, ordinal ) > ); > > That's the textbook solution on a DBMS without user-defined types. > > An alternative is to conceive of the complex type as a datatype, and > represent it in SQLite as BLOB or TEXT. That severely limits SQLite's > ability to compare and select the values, although that limitation can > be somewhat alleviated with user-defined functions e.g., > > select * from T where "C" = complex(1.0, -0.5) > > If 1) you're not interested in letting the DBMS inspect the data, and > 2) you have some convenient C function to losslessly convert your > complex type to a string or bit-string, then a single-column > representation might be more convenient. > > --jkl > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any attachments are solely for the use of the addressee and may contain information that is privileged or confidential. Any disclosure, use or distribution of the information contained herein is prohibited. In the event this e-mail contains technical data within the definition of the International Traffic in Arms Regulations or Export Administration Regulations, it is subject to the export control laws of the U.S.Government. The recipient should check this e-mail and any attachments for the presence of viruses as L-3 does not accept any liability associated with the transmission of this e-mail. If you have received this communication in error, please notify the sender by reply e-mail and immediately delete this message and any attachments.
