This makes perfect sense. Thank you. -- 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 Jim Callahan > Sent: Saturday, April 25, 2015 1:37 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Thoughts on storing arrays of complex numbers > > 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 > > > _______________________________________________ > 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.
