If you are working with linear algebra type matrices, then simply make a column that represents each element. For example, a Jones matrix which is 2x2 would have four columns. Then each set of matrices are represented by a row. Best way to handle is to visualizes how you would use the numbers. If you are using recursive numerical techniques that requires algorithmic access, then a structure that supports subscript accessing is most efficient (wjicj means tables of numbers). If you are dealing with large data sets that follow a defined size, say x number of samples per test yielding y number of calculated coefficients, then the data tells you to have two tables, one for input data one for output data, with the number of columns defined by your mathematical variables. Number one rule is to keep it simple and obvious.
Using a blob seems counter productive as you need to access your data by some rules, which seems to indicate a straight forward table of numbers. Write them out on a sheet of paper like you would do in a math class. The structure of the table will become self evident. ------------ Scott Doctor scott at scottdoctor.com On 4/24/2015 6:37 AM, Drago, William @ CSG - NARDA-MITEQ wrote: > 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 > >
