Omgili, forum search, forums search, search forums, discussion search,discussions search, search discussions, board search, boards search, search boards
  Advanced Search

Re: MBF to IEEE (Beg. Q)

On Sat, 30 May 2009 13:44:40 -0500, Webbiz <...@forme.thanks.com

On Sun, 24 May 2009 07:01:06 -0400, "Jim Mack" <...@mdxi.nospam.comwrote:

Ah. Got it. Much like ByRef I assume?

The Metastock file MASTER apparently contains the stock header
information in the following format:

Public Type TMetaStock
ID As Byte
Reserved As Integer
Rec_Len As Byte
Num_Fields As Byte
Reserved1 As Integer
File_Name As String * 16
Reserved2 As Byte
Flag As Byte
Init_Date(0 To 3) As Byte
Fin_Date(0 To 3) As Byte
Time As Byte
Intr_Time As Byte
Reserved3 As Byte
Symbol As String * 14
Reserved4 As Byte
Autorun_Flag As Byte
Reserved5 As Byte
End Type

The dates here...

Init_Date(0 To 3) As Byte
Fin_Date(0 To 3) As Byte

...is the information that is being retrieved as arrays of 4 bytes in
MBF format.

So what you are saying then is to load this data directly into Single
variables like this...

Init_Date As Single
Fin_Date As Single

We'd bypass the need to convert the array of 4 bytes from MBF to IEEE
and then into a Single and just go directly to a converted IEEE single
using the DxToIEEEs?

DxToIEEEs Init_Date

I'm not sure if the array of bytes is a UDT as you are asking, but a
search on the web I found the following format for the MASTER file, as
follows:

/*
* MASTER file description
* floats are in Microsoft Basic format
* strings are padded with spaces, not null terminated
*/
struct rec_1 {
u_short num_files; /* number of files master contains */
u_short file_num; /* next file number to use (highest F#
used) */
char zeroes[49];
};
struct rec_2to255 { /* description of data files */
u_char file_num; /* file #, i.e., F# */
char file_type[2]; /* CT file type = 0'e' (5 or 7 flds) */
u_char rec_len; /* record length in bytes (4 x num_fields)
*/
u_char num_fields; /* number of 4-byte fields in each record
*/
char reserved1[2]; /* in the data file */
char issue_name[16]; /* stock name */
char reserved2;
char CT_v2_8_flag; /* if CT ver. 2.8, 'Y'; o.w., anything
else */
float first_date; /* yymmdd */
float last_date;
char time_frame; /* data format:
'I'(IDA)/'W'/'Q'/'D'/'M'/'Y' */
u_short ida_time; /* <b char symbol[14]; /* stock symbol */
char reserved3; /* <bspace */
char flag; /* ' ' or '*' for autorun */
char reserved4;
};

Looking at the above code, it would seem to me that the decision to
load the data as an array of 4 bytes or as a 'Single' (same as Float,
right?) is up to the programmer. Correct?

float first_date; /* yymmdd */
float last_date;

Sorry for the VB 101 questions, but remember 7th grader here. :-b

Got it!

I'm going to assume that, if the issue here is of simply changing my
VB structure to hold singles rather than array of 4 bytes as it
currently does, that I really don't need to concern myself with
DxArrayMBF. And other than the routine that I'm currently using to
convert an array of 4 bytes of MBF into IEEE, I have no other use for
having an array of 4 bytes that I can see.

So assuming you agree with the above, it really comes down to personal
choice which way to go. And if that is the case, which would provide,
in your opinion, an advantage or edge or better way to go?

Thanks!

Webbiz



On Sat, 30 May 2009 16:41:41 -0400, "Jim Mack" <...@mdxi.nospam.com

Yes, replacing the byte arrays with Singles is the idea.

However, Init_Date doesn't exist independently of the containing Type,
so you'd be doing something like:

DxToIEEEs MyVariable.Init_Date

... snip ...

Yes, exactly. How you view a set of bits is up to you (within reason,
and some limits imposed by the language).

Not exactly. The "array" in the name refers to an array of the Master
Type, not an array of bytes.

If you have one single variable of the MetaStock Master Type, then
DxArrayMBF doesn't offer any advantage. If you have an array of such
types, for example, read directly from a file, DxArrayMBF can convert
ALL the singles in ALL the members of that Type array in one call. For
a largish file it could be tens of times faster than doing each entry
individually.

But in no case do you "need" DxArrayMBF -- you can do what you need to
using the free version.

--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"

On Sat, 30 May 2009 19:23:57 -0500, Webbiz <...@forme.thanks.com

On Sat, 30 May 2009 16:41:41 -0400, "Jim Mack" <...@mdxi.nospam.comwrote:

Let me see if I understand this.

What you are saying is that an array of the above Metastock structure
passed to DxArrayMBF would result in EVERY Single type variable being
coverted from MBF to IEEE?

The Master file can hold no more than 254 records, each representing
one stock. Would you consider 254 (assuming it was maxed out) to be a
significant number of array(items) or small stuff for something like
DxArrayMBF?

You mention 'free version'. I assume this means DxArrayMBF is a
royalty product?

Thanks.

Webbiz

On Sat, 30 May 2009 21:42:06 -0400, "Jim Mack" <...@mdxi.nospam.com

Yes. You pass in a key descriptor telling the function where the
floats are located in the UDT, and the function converts them in
place.

It's not just the number you do in one gulp, but how many gulps over
how much time. 254 isn't a huge number, but I don't know what else
your software is doing, or how often. If the conversion is within a
real-time tracking process, then it's probably worth it. Otherwise,
probably not. But it's your program...

It's part of our Stamina library, which is a commercial product having
some 500 functions written in ASM for use by VB and VBA. DxToIEEEs is
also in the library, but we long ago decided that the community could
use a good 32-bit version of the widely used 16-bit MBFIEE.DLL, so we
put those few functions into our free MBFIEE32.DLL

We should probably let the commercial talk drop here -- I really just
wanted to mention it for completeness.

--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"

Discussion Title: Re: MBF to IEEE (Beg. Q)
Title Keywords: IEEE  (Beg.