>I could have two blob fields in my table. One for the real parts > and one for the imaginary. (I don't like this.)
Could you be more specific about what is not to like? A. Does it limit your ability to use SQL? B. Does it cause problems for the language interface? C. Is it harder to do data validation? It is not unusual to use data bases to store pairs of numbers, for example GIS programs use databases to store latitude and longitude pairs in separate columns. So, what specific problems would be created by a REAL column and an IMAGINARY column? Jim Callahan Orlando, FL On Fri, Apr 24, 2015 at 9:37 AM, Drago, William @ CSG - NARDA-MITEQ < William.Drago at l-3com.com> 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 >
