PERL Miscellaneous - File::SortedSeek not working

Author

File::SortedSeek not working

worker

2008-01-24, 7:18 pm

Hi, all,
I am using this File::SortedS

module to search a big data file
and it is not working.

The data file has these entries:

01/01/1960,0.75
01/02/1960,0.00
etc

basically, a date followed by a number

Then, I have this other file contains only the list of valid date
as follows:

01/05/1960
01/07/1960

So, what I am doing is to get a line from the valid date file, then
File::SortedS

out the matching date in the data file, but no matter
how I try, it is not matching at all,

Is that module real or just a quack?!
thx
bill

J. Gleixner

2008-01-24, 7:18 pm

worker wrote:
> Hi, all,
> I am using this File::SortedS

module to search a big data file
> and it is not working.
>
> The data file has these entries:
>
> 01/01/1960,0.75
> 01/02/1960,0.00
> etc
>
> basically, a date followed by a number
>
> Then, I have this other file contains only the list of valid date
> as follows:
>
> 01/05/1960
> 01/07/1960
>
> So, what I am doing is to get a line from the valid date file, then
> File::SortedS

out the matching date in the data file, but no matter
> how I try, it is not matching at all,
>
> Is that module real or just a quack?!

Check line 42.

xhoster@gmail.com

2008-01-24, 7:19 pm

worker <tzhai2007@gmail.com> wrote:
> Hi, all,
> I am using this File::SortedS

out the matching date in the data file, but no matter
> how I try, it is not matching at all,
>
> Is that module real or just a quack?!

It is far more likely that you are a quack who is using the module
incorrectly. If you showed us the code, we might be able to verify
which if the two is the case.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

worker

2008-01-24, 7:19 pm

On Jan 24, 12:36 pm, "J. Gleixner" <glex_no-s...@qwest-spam-
no.invalid> wrote:
> worker wrote:
>
>
>
>
>
>
>
>
> Check line 42.

Hi, I am listing my little test code below, please help: (the problem
is that it can't find a match)
I guess the main thing I didn't get right is the matching pattern that
matches those dates, so I guess that's the part I am s

ing help.
thx.

####### Start test code #####
use File::SortedS

;
my $dfile = './dtest.file';
my $file = './test.file';

open DTEST,">$dfile" or die "0bad\n";
open TEST, ">$file" or die "bad\n";
print DTEST "01/01/1960\n01/02/1960\n"; close(DTEST);

print TEST
"01/10/1949,0.1\n01/02/1950,0.2\n1/1/1960,7.0\n1/2/1960,8.0\n3/3/1980,9.0\n";
close(TEST);

open DTEST,"<$dfile" or die "0bad\n";
open TEST, "<$file" or die "bad\n";

my $line;
my $zline;
$line = <DTEST>;
chomp ($line);
$tell = File::SortedS

::alphabetic(*TEST,$line
,\&munge_string);

$zline = <TEST>;
print "Found it?:: $zline\n";
close(TEST);close(DTEST);
exit(0);

sub munge_string {
my $line = shift || return undef;
# return ($line =~ m/\|(\w+)$/) ? $1 : undef;
# return ($line =~ m/^[0-9]+\/[0-9]+\/[0-9]+,/) ? $1 : undef;
return ($line =~ m/^\/,/) ? $1 : undef;
}

#### End test code ####

xhoster@gmail.com

2008-01-24, 7:19 pm

worker <tzhai2007@gmail.com> wrote:
> On Jan 24, 12:36 pm, "J. Gleixner" <glex_no-s...@qwest-spam-
> no.invalid> wrote:

The example code produced file like this:

01/10/1949,0.1
01/02/1950,0.2
1/1/1960,7.0
1/2/1960,8.0
3/3/1980,9.0

It is not canonical, as the sometimes it is zero-padded and sometimes
it is not. It does appear to be in a reasonable sorted order, but I
don't know if that is by design or by accident (If you designed something
to sort it properly, why doesn't it canonicalize it while it is at it?)

But isn't clear if the semantics are day/month/year or month/day/year,
as both are compatible with the given order. I'm assuming day/month/year

....
[color=darkred]
> $line = <DTEST>;
> chomp ($line);
> $tell = File::SortedS

::alphabetic(*TEST,$line
,\&munge_string);

The query $line needs to be munged in way compatible with the querent
lines' munging. Otherwise it won't work. The easiest way to do this is to
pass in munge_string($line) rather than $line.

>
> sub munge_string {
> my $line = shift || return undef;
> # return ($line =~ m/\|(\w+)$/) ? $1 : undef;
> # return ($line =~ m/^[0-9]+\/[0-9]+\/[0-9]+,/) ? $1 : undef;
> return ($line =~ m/^\/,/) ? $1 : undef;
> }

The function has to munge the data in such a way that the lines of the
file being searched are in alphabetic sorted order after the munging. With
the sort order your file already has, it thus has to reorder the fields so
that the most significant (year) comes first.

return ($line =~ m/(^[0-9]+)\/([0-9]+)\/([0-9]+)(,|$)/) ?
sprintf "%04d%02d%02d", $3,$2,$1 : undef;

The (,|$) is so that it will work on the query, which is not followed by a
comma, as well as the querent.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

worker

2008-01-25, 4:28 am

On Jan 24, 4:00 pm, xhos...@gmail.com wrote:
> worker <tzhai2...@gmail.com> wrote:
>
>
>
> The example code produced file like this:
>
> 01/10/1949,0.1
> 01/02/1950,0.2
> 1/1/1960,7.0
> 1/2/1960,8.0
> 3/3/1980,9.0
>
> It is not canonical, as the sometimes it is zero-padded and sometimes
> it is not. It does appear to be in a reasonable sorted order, but I
> don't know if that is by design or by accident (If you designed something
> to sort it properly, why doesn't it canonicalize it while it is at it?)
>
> But isn't clear if the semantics are day/month/year or month/day/year,
> as both are compatible with the given order. I'm assuming day/month/year
>
> ...
>
>
> The query $line needs to be munged in way compatible with the querent
> lines' munging. Otherwise it won't work. The easiest way to do this is to
> pass in munge_string($line) rather than $line.
>
>
>
>
> The function has to munge the data in such a way that the lines of the
> file being searched are in alphabetic sorted order after the munging. With
> the sort order your file already has, it thus has to reorder the fields so
> that the most significant (year) comes first.
>
> return ($line =~ m/(^[0-9]+)\/([0-9]+)\/([0-9]+)(,|$)/) ?
> sprintf "%04d%02d%02d", $3,$2,$1 : undef;
>
> The (,|$) is so that it will work on the query, which is not followed by a
> comma, as well as the querent.
>
> Xho
>
> --
> --------------------http://NewsReader.Com/--------------------
> The costs of publication of this article were defrayed in part by the
> payment of page charges. This article must therefore be hereby marked
> advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
> this fact.

thnx for the explanation.
I made the following changes according to your suggestions:

$aSimDateMunged = &munge_string($aSimDate);
$tell = File::SortedS

::alphabetic(*FRAW,$aSim
DateMunged,
\&munge_string);

return ($line =~ m/(^[0-9]+)\/([0-9]+)\/([0-9]+)(,|$)/) ?
sprintf "%04d%02d%02d", $3,$1,$2 : undef;

my data is in month/day/year.

once I tried it, this is what I got as response:

Name "main::tell" used only once: possible typo at ztest.pl line 22.

Ark, File::SortedS

got to EOF
Failed to find: 'SCALAR(0x354c0)'
The search mode for the file was 'Ascending order'
$line: undef
$next: undef
File size: 74 Bytes
$top: 55 Bytes
$bottom: 74 Bytes
Perhaps try reversing the search mode
Are you using the correct method - alhpabetic or numeric?

If you think it is a bug please send a bug report to:
jfreeman@tassie.net.au
A sample of the file, the call to this module and
this error message will help to fix the problem
Use of uninitialized value in concatenation (.) or string at ztest.pl
line 25, <
TEST> line 8.
Found it?::

Help?

worker

2008-01-26, 7:15 pm

On Jan 24, 11:24 pm, worker <tzhai2...@gmail.com> wrote:
> On Jan 24, 4:00 pm, xhos...@gmail.com wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> thnx for the explanation.
> I made the following changes according to your suggestions:
>
> $aSimDateMunged = &munge_string($aSimDate);
> $tell = File::SortedS

::alphabetic(*FRAW,$aSim
DateMunged,
> \&munge_string);
>
> return ($line =~ m/(^[0-9]+)\/([0-9]+)\/([0-9]+)(,|$)/) ?
> sprintf "%04d%02d%02d", $3,$1,$2 : undef;
>
> my data is in month/day/year.
>
> once I tried it, this is what I got as response:
>
> Name "main::tell" used only once: possible typo at ztest.pl line 22.
>
> Ark, File::SortedS

got to EOF
> Failed to find: 'SCALAR(0x354c0)'
> The search mode for the file was 'Ascending order'
> $line: undef
> $next: undef
> File size: 74 Bytes
> $top: 55 Bytes
> $bottom: 74 Bytes
> Perhaps try reversing the search mode
> Are you using the correct method - alhpabetic or numeric?
>
> If you think it is a bug please send a bug report to:
> jfree...@tassie.net.au
> A sample of the file, the call to this module and
> this error message will help to fix the problem
> Use of uninitialized value in concatenation (.) or string at ztest.pl
> line 25, <
> TEST> line 8.
> Found it?::
>
> Help?

Hello?
could anyone help with this? thx.

xhoster@gmail.com

2008-01-26, 7:15 pm

worker <tzhai2007@gmail.com> wrote:

Where did $aSimDate and *FRAW come from? The point of posting test code
is that we can use it for testing. If you keep changing the variable
names, that kind of defeats the purpose.
[color=darkred]

Are you taking a reference to a scalar someplace that you aren't showing
us?
[color=darkred]
>
> Hello?
> could anyone help with this? thx.

When I made the indicated changes to the example you originally provided,
it worked just fine. I don't think you are reliably transferring
code/information back and forth between this forum and your own code, so
there is little more I can do for you.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Sponsored Links