Keith is close. I would suggest two tables: Elements and Arrays.
Elements Table Since arrays are usually referenced by names, I would include an "arrayname" field in the Elements table to indicate membership in a particular array. Also, I would not trust the recordID for the internal ordering of the array, so I would suggest a SeqNo (sequence number or unidimensional index) for the elements of the array. CREATE TABLE ComplexElements ( ComplexElementID INTEGER PRIMARY KEY, ComplexArrayName CHARACTER NOT NULL DEFAULT 'ComplexArray1', SeqNo INTEGER NOT NULL DEFAULT 0, -- zero based RealPart REAL NOT NULL DEFAULT 0, ImagPart REAL NOT NULL DEFAULT 0 ); The dimensions of the array are an array property and not an element property, therefore the number of elements in each dimensions are stored in the ComplexArrays table. SQLite knows nothing about the dimensions (they are just data) the higher level language calling SQLite coerces the dimensions on the unidimensional list of array element pairs provided by SQLite. I have allowed for up to five dimensions (dim1 through dim5). Do you want zero or one based arrays? Do you want row-major or column-major interpretation of element vector? ? CREATE TABLE ComplexArrays ( ComplexArrayID INTEGER PRIMARY KEY, ComplexArrayName CHARACTER NOT NULL DEFAULT 'ComplexArray1', dim1 INTEGER NOT NULL DEFAULT 0, -- min element 0 in 1 dim dim2 DEFAULT NULL ALIAS y, -- dim is maxsize of dim, not coord dim3 DEFAULT NULL ALIAS z, dim4 DEFAULT NULL, dim5 DEFAULT NULL, ); Coordinates, you would probably want to generate the indices for the arrays "on the fly" in the higher level language, but if you wanted to reference the array indices in SQL you might have a third table "Coordinates" which would store the ComplexArrayName, SeqNo, Coord1 ALIAS ,X Coord2 ALIAS Y, Coord3 ALIAS Z, Coord4, Coord5. Then one might create a SQL VIEW "ComplexData" which would allow one to query the contents of an array (a view is a stored query that acts as a virtual table -- you can use the view name as if it were a table in a query): SELECT ArrayName, X, Y, Z, RealPart, ImagPart FROM ComplexData WHERE ArrayName = 'Array1'; or, to select a single element, specify the coordinates: SELECT ArrayName, X, Y, Z, RealPart, ImagPart FROM ComplexData WHERE ArrayName = 'Array1' AND X = 0 AND Y = 0 AND Z = 0; -- 3D, zero based array Thanks to Keith, he was on the right track. Warning, my capitalization and names may be inconsistent and my SQL might be pseudocode, but the intent is create the structures to support the final two queries. Hope this helps. Jim Callahan Orlando, FL On Fri, Apr 24, 2015 at 5:52 PM, Keith Medcalf <kmedcalf at dessus.com> wrote: > > Create table ComplexNumbers > ( > id integer primary key, > real real not null default 0, > imag real not null default 0 > ); > > Then, where ever you need to use a complex number you store it in the > complex number table and store the id of that number instead. For example: > > ?? > create table Boxes > ( > id integer primary key, > length integer references ComplexNumbers, > width integer references COmplexNumbers > ); > > Or if you need a list then something lije: > > create table ListHeader > ( > List integer primary key, > Name text collate nocase not null unique, > ); > > create table ListEntries > ( > List integer not null references ListHeader, > member integer not null references ComplexNumber > ); > > This is called a Relational Data Model because, well, you relate things to > each other. > > > -----Original Message----- > > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > > bounces at mailinglists.sqlite.org] On Behalf Of Drago, William @ CSG - > > NARDA-MITEQ > > Sent: Friday, 24 April, 2015 09:38 > > To: General Discussion of SQLite Database > > Subject: [sqlite] Thoughts on storing arrays of complex numbers > > > > All, > > > > 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. > > > > Thanks, > > -- > > Bill Drago > > Senior Engineer > > L3 Narda-MITEQ<http://www.nardamicrowave.com/> > > 435 Moreland Road > > Hauppauge, NY 11788 > > 631-272-5947 / William.Drago at L-3COM.com<mailto:William.Drago at > > L-3COM.com> > > > > > > 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. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
