If you download data you'll likely end up with either csv files or
metastock files. The metastock format is a bit of a pain; I have the
format and a conversion utility I wrote around here somewhere but since
I no longer subscribe to any services that supply this format I don't
use it any more. Real-time ticker feeds are different; I had a front
end machine that received the ticker feed into a ring buffer but I no
longer process data that way.
> I am currently storing mine in a word processor files.
That's fine. Anything that's computer-readable is fine. It doesn't
matter if you store the data in Swahili, as long as a computer can read
it.
> Any other data storage strategies out there?
The only concern is getting the data into the machine. Once it's in the
machine the computer can be taught to find it, to decode it, to sort it,
process it and display it. Just get the data into the machine. Any
format, any file and directory organization. I have one routine that
does a tree search forwards and backwards until it finds the data it
needs; the machine can do this in a second or two so it's not worthwhile
for me to spend several days "figuring out" a better way to organize the
data. Let the computer do the work, you just need to get the data into
the computer.
Mesa 2 is wonderful because you can add Rexx as necessary to do any
download and conversion work that's necessary. Thus, .M2 files are
fine. If you want to stay with DeScribe files that's fine too -- as
long as a Mesa 2 workbook can run a Rexx routine that can either decode
a DeScribe file or run DeScribe with some parameters that will tell
DeScribe to open a file and output the data in a format such as csv
which Mesa 2 can read (I don't know if DeScribe can be automated to do
this).
> Is there a problem storing financial data in spreadsheet form?
Fractional pricing is a pain. I used special coding for ease of data
entry and readability when I was still typing in numbers: .18 was one
eighth, .34 was three fourths, etc. I have data for one stock which
traded in 32nds -- Jaguar (.1732 would be 17/32). Here's your first
classroom problem: If my computer saw a data entry of 27.78, what would
the real price be?
> Steven Levine wrote:
> > a database implementation does not get rid of the
> > sorting. It just hides it under the covers. Things
> > like Peter's issues with stable sort don't go away.
> > They have to be handled in the DB design.
Steven is correct, and so is Lynn when he speaks of ORDERED BY.
Databases have "a few different ways to sort the data". You can sort it
as you enter it (index it upon entry), or you can make believe you've
sorted it (create a new index), or you can really sort it (you actually
move the data records around until you like the way they've been
rearranged). Mesa 2 has a couple of ways to sort -- you can specify up
to three columns to sort on, or you can create a "key" and sort on the
key. Sometimes a sort needs an "escape", such as if you have different
types of data records and the sort fields are in different places
depending on the record type. In these cases you need to create a "key"
because Mesa 2's sort doesn't allow for external sequence checking as
the sort progresses.
Here's what I've learned over the years about sorting data: Every
single possible sort sequence can be used for something valuable. You
can sort by exchange, or by symbol, or by price, or by volume, or be
P/E, or by commission, or by market value, or by industry sector, or by
seasonal change, or by competitive market position, or by age of
company, or by days up days down, etc. Whatever you do, make sure you
can reliably sort the data because you'll be sorting a lot. I sort my
CSV files by putting a key on the front of each line, sorting on the key
(I use BIGSORT), then removing the key.
- Peter
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-sundialsig".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
>> Next Message >>
Return to [ 31 |
May |
2001 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
