Choosing between look up tables

--000e0cd5169ada80f704a791aa1b
Content-Type: text/plain; charset=ISO-8859-1

Hi everyone,

I could use both suggestions and answers on the follow topic. The problem
I'm trying to solve is quite simple: I must parse through a large csv file.
A field within the csv will signify which product type the included data is
associated with. Once the product type is known then a field within the
same csv (a 64 byte long hex string) must be parsed out. The hex string is
converted to binary where each binary bit represents pass/fail for a
particular functional test. Each functional test is unique and the index of
said test in the 512 bit string may differ by product type. Everything
described so far I'm comfortable tackling. Now to the real question. My
initial direction with this problem was to have a separate functable.pl file
with unique arrays for each lookup table (the value of the each array
location was simply a scalar of the test name). Then "use functable.pl" in
the main parsing script and reference the desired lookup table. If I knew
every lookup table ahead of time, I would of course just include them in the
parsing script. However, new product types will always be around the
corner. So is this a reasonable solution or a rookie mistake? Or should I
simply have a .txt file that might look like the following:
###############################
# begin: product1
testA,0
testB,8
testC,16
testD,32
# end

# begin: product2
testA,2
testB,4
testC,8
testD,16
# end
###############################

Then simply read in the .txt file and build the array from within the main
parsing script as opposed to referencing an array in a separate file?
Thanks for your time. I hope to read some good discussion.

Sincerely,

Steven

--000e0cd5169ada80f704a791aa1b--

Re: Choosing between look up tables

On Fri, 08 Jul 2011 09:53:05 -0700, Steven Surgnier wrote:

> Hi everyone,
>=20
> I could use both suggestions and answers on the follow topic. The
> problem I'm trying to solve is quite simple: I must parse through a
> large csv file.
> A field within the csv will signify which product type the included
> data is
> associated with. Once the product type is known then a field within th=
e
> same csv (a 64 byte long hex string) must be parsed out. The hex strin=
g
> is converted to binary where each binary bit represents pass/fail for a
> particular functional test. Each functional test is unique and the
> index of said test in the 512 bit string may differ by product type.=20
> Everything described so far I'm comfortable tackling. Now to the real
> question. My initial direction with this problem was to have a separat=
e
> functable.pl file with unique arrays for each lookup table (the value o=
f
> the each array location was simply a scalar of the test name). Then
> "use functable.pl" in the main parsing script and reference the desired
> lookup table. If I knew every lookup table ahead of time, I would of
> course just include them in the parsing script. However, new product
> types will always be around the corner. So is this a reasonable
> solution or a rookie mistake? Or should I simply have a .txt file that
> might look like the following: ###############################
> # begin: product1
> testA,0
> testB,8
> testC,16
> testD,32
> # end
>=20
> # begin: product2
> testA,2
> testB,4
> testC,8
> testD,16
> # end
> ###############################
>=20
> Then simply read in the .txt file and build the array from within the
> main parsing script as opposed to referencing an array in a separate
> file?

It seems as though you are talking about data rather than code; hard to=20
say because you don't describe how the functional tests may vary. But if=20
all the variations can be captured in data then store it as data, either=20
in a single file if there's not much of it, multiple files if you want to=
=20
partition responsibility for updating new product types, or a database if=
=20
it's really dynamic. Don't create reams of code that initializes arrays=20
to literal lists, it's excruciating to read.

--=20
Peter Scott
http://www.perlmedic.com/ http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=3D0137001274
http://www.oreillyschool.com/courses/perl4/

--=20
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/