/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Splitte tekstfil i felter ?
Fra : Bjarne Jensen


Dato : 26-04-08 11:14

Jeg har nogle store tekstfiler fyldt med data som har fast relativ
position som jeg gerne vil have læst ind i en db.

Første "linie" indeholder felt-navnene, herefter kommer data (a..Z,
0..9) i tekstform uden cr/lf :

felt1felt2felt3felt4abcde12345qwert67890fghij11111trewq23232....

"Rettet ud" ser det sådan ud:

felt1felt2felt3felt4
abcde1234 67890
fghij22222trewq23282
.....

I min grænseløse naivitet forestiller jeg mig, at der findes en
"file-view'er" som kan vise filerne med en af mig valgt cr/lf og med
chr-position read-out så jeg kan tælle mig frem til hvordan
indlæsningsloopet skal konstrueres?

Med venlig hilsen
Bjarne

 
 
Michael Zedeler (26-04-2008)
Kommentar
Fra : Michael Zedeler


Dato : 26-04-08 13:54

Bjarne Jensen wrote:
> Jeg har nogle store tekstfiler fyldt med data som har fast relativ
> position som jeg gerne vil have læst ind i en db.
>
> Første "linie" indeholder felt-navnene, herefter kommer data (a..Z,
> 0..9) i tekstform uden cr/lf :
>
> felt1felt2felt3felt4abcde12345qwert67890fghij11111trewq23232....
>
> "Rettet ud" ser det sådan ud:
>
> felt1felt2felt3felt4
> abcde1234 67890
> fghij22222trewq23282
> ....
>
> I min grænseløse naivitet forestiller jeg mig, at der findes en
> "file-view'er" som kan vise filerne med en af mig valgt cr/lf og med
> chr-position read-out så jeg kan tælle mig frem til hvordan
> indlæsningsloopet skal konstrueres?

Jeg kender ikke nogen viewer der lige kan klare den opgave. Det virker
også lidt underligt at feltbredden er defineret af navnet på det enkelte
felt. Hvad hvis jeg gerne vil skrive "Æblegrød" i felt1 i første data-række?

Mvh. Michael.

Bjarne Jensen (26-04-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 26-04-08 18:59

Michael Zedeler skrev:

> Hvad hvis jeg gerne vil skrive "Æblegrød" i felt1 i første
> data-række?

Det er ikke noget problem for du har du slet ikke lyst til at skrive
"Æblegrød" hvis du hedder Dept. of Navigational Services of United
States Air Force ;)

Det er data (public domain) som er beregnet til at indgå i et USAF
flyveplanlægningsprogram.

Michael Zedeler (26-04-2008)
Kommentar
Fra : Michael Zedeler


Dato : 26-04-08 19:21

Bjarne Jensen wrote:
> Michael Zedeler skrev:
>
>> Hvad hvis jeg gerne vil skrive "Æblegrød" i felt1 i første data-række?
>
> Det er ikke noget problem for du har du slet ikke lyst til at skrive
> "Æblegrød" hvis du hedder Dept. of Navigational Services of United
> States Air Force ;)
>
> Det er data (public domain) som er beregnet til at indgå i et USAF
> flyveplanlægningsprogram.

Tak for den sjove historie, men du svarede ikke på spørgsmålet.

Mvh. Michael.


Bjarne Jensen (26-04-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 26-04-08 21:06

Michael Zedeler skrev:

> Tak for den sjove historie, men du svarede ikke på spørgsmålet.

Selv tak for anledningen ;)

Det er helt udelukket at ændre noget i de data. Det er geografiske
oplysninger som position, magnetisk variation, frekvenser,
identitetsbetegnelser osv. Nix-pille her ellers er det værdiløst.

Michael Zedeler (27-04-2008)
Kommentar
Fra : Michael Zedeler


Dato : 27-04-08 08:56

Bjarne Jensen wrote:
> Michael Zedeler skrev:
>
>> Tak for den sjove historie, men du svarede ikke på spørgsmålet.
>
> Selv tak for anledningen ;)
>
> Det er helt udelukket at ændre noget i de data. Det er geografiske
> oplysninger som position, magnetisk variation, frekvenser,
> identitetsbetegnelser osv. Nix-pille her ellers er det værdiløst.

Lad mig lige spørge igen:

Du skriver:

felt1felt2felt3felt4abcde12345qwert67890fghij11111trewq23232....

Det betyder at der er præcis 5 tegn til hvert af felt 1, felt 2, ...

Men det er da noget af et tilfælde hvis det viser sig at feltnavnenes
længde lige nøjagtig passer med den ønskede bredde af felterne. Er du
sikker på at det ser sådan ud og ikke f. eks. sådan her ud:

felt1 felt2 felt3 felt4....

Så felt 1 har bredden 10, felt 2 6, felt 3 20 osv.?

Mvh. Michael.

Bjarne Jensen (27-04-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 27-04-08 18:24

Michael Zedeler skrev:

> Men det er da noget af et tilfælde hvis det viser sig at feltnavnenes
> længde lige nøjagtig passer med den ønskede bredde af felterne. Er du
> sikker på at det ser sådan ud og ikke f. eks. sådan her ud:
>
> felt1 felt2 felt3 felt4....

Ach - du har ret. Det var en tanketorsk at ilustrere felterne på den måde.
Felterne har forskellig længde men den længde de har i første linie
(hvor feltnavnet står) går igen og igen hele filen igennem så man kan
regne sig frem til hvor feltet begynder/slutter i en vilkårlig række.

Peter Lykkegaard (26-04-2008)
Kommentar
Fra : Peter Lykkegaard


Dato : 26-04-08 19:39

"Bjarne Jensen" skrev

> Jeg har nogle store tekstfiler fyldt med data som har fast relativ
> position som jeg gerne vil have læst ind i en db.
>
Hvilken db?

Nogle db systemer kan indlæse direkte fra fixed field filer (fx MSSQL)

- Peter


Bjarne Jensen (26-04-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 26-04-08 21:16

Peter Lykkegaard skrev:

> Hvilken db?

MySQL (den eneste jeg har adgang til)

> Nogle db systemer kan indlæse direkte fra fixed field filer (fx MSSQL)

Det enste jeg har fundet om "fixed field" i manualen til MySQL 5.1 er
nogle fejlkoder.

Peter Lykkegaard (26-04-2008)
Kommentar
Fra : Peter Lykkegaard


Dato : 26-04-08 22:13

"Bjarne Jensen" skrev:
>
> Det enste jeg har fundet om "fixed field" i manualen til MySQL 5.1 er
> nogle fejlkoder.

Det magiske udtryk er "fixed-row format" på mySQL
fx
http://faqts.com/knowledge_base/view.phtml/aid/2784/fid/100

- Peter


Bjarne Jensen (27-04-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 27-04-08 18:49

Peter Lykkegaard skrev:
> Det magiske udtryk er "fixed-row format" på mySQL

Ser man det! Det er fint men for mig at se kræver fixed-row format
stadigvæk, at man ved hvor felternes relative positioner er. Eller?

Peter Brodersen (28-04-2008)
Kommentar
Fra : Peter Brodersen


Dato : 28-04-08 00:40

On Sat, 26 Apr 2008 23:13:15 +0200, "Peter Lykkegaard"
<plykkegaard@gmail.com> wrote:

>> Det enste jeg har fundet om "fixed field" i manualen til MySQL 5.1 er
>> nogle fejlkoder.
>
>Det magiske udtryk er "fixed-row format" på mySQL
>fx
> http://faqts.com/knowledge_base/view.phtml/aid/2784/fid/100

Det er dog mest af alt blot en intern opdatering (som i øvrigt kan
anbefales, hvis ens data egner sig dertil ). Hvis alle felttyper gør,
at hver række altid vil fylde det samme antal bytes, så behøves der ikke
nogen fortegnelse om hvor, dataen rækker, idet række n altid kan findes
(n-1*rækkestørrelse) inde i datafilen.

Det har ikke dog ikke noget med importeringen at gøre.

--
- Peter Brodersen
Kendt fra Internet

Bjarne Jensen (28-04-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 28-04-08 21:20

Peter Brodersen skrev:
> Det er dog mest af alt blot en intern opdatering (som i øvrigt kan
> anbefales, hvis ens data egner sig dertil ).

Anbefales pga hastigheden, eller?

> Hvis alle felttyper gør,
> at hver række altid vil fylde det samme antal bytes, så behøves der ikke
> nogen fortegnelse om hvor, dataen rækker, idet række n altid kan findes
> (n-1*rækkestørrelse) inde i datafilen.

Jo, men her er des så jeg bliver vanskelig og gerne vil ha' en text-file
viewer med chr-position read-out så jeg kan tælle mig frem til hvordan
indlæsningsloopet skal konstrueres. Det drejer sig om mange filer (ca
50), nogle med store datasæt på 400 karakterer.

/Bjarne

Peter Brodersen (28-04-2008)
Kommentar
Fra : Peter Brodersen


Dato : 28-04-08 22:16

On Mon, 28 Apr 2008 22:19:47 +0200, Bjarne Jensen
<bjarne.b.jensen@gmail.com> wrote:

>> Det er dog mest af alt blot en intern opdatering (som i øvrigt kan
>> anbefales, hvis ens data egner sig dertil ).
>Anbefales pga hastigheden, eller?

Yep.

>Jo, men her er des så jeg bliver vanskelig og gerne vil ha' en text-file
>viewer med chr-position read-out så jeg kan tælle mig frem til hvordan
>indlæsningsloopet skal konstrueres. Det drejer sig om mange filer (ca
>50), nogle med store datasæt på 400 karakterer.

Det lyder mere som om, det er en eller anden form for indledende
behandling af dataen, du har brug for.

Jeg vil tro, at en del udviklere ville bruge sprog som perl eller lignende
til at opsplitte dataen. Ikke fordi lige præcis perl er nødvendigt til
opgaven, men til simpel processering af tekstfiler kan det være et godt
værktøj at kende.

Jeg er stadigvæk lidt i tvivl om formatet. Kan du prøve at lægge en fil op
et sted? Det kan være, det er meget simpelt at konstruere en hjemmeside,
som kan konvertere teksten til et andet format (fx CSV).

--
- Peter Brodersen
Kendt fra Internet

Bjarne Jensen (05-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 05-05-08 08:08

OK, her ligger så et eksempel:

http://thejarlog.phpwebhosting.com/usaf/FILE0

(den buster min quota på siten så den bliver snart slettet igen)


/Bjarne

Peter Brodersen wrote:
> On Mon, 28 Apr 2008 22:19:47 +0200, Bjarne Jensen
> <bjarne.b.jensen@gmail.com> wrote:
>
>>> Det er dog mest af alt blot en intern opdatering (som i øvrigt kan
>>> anbefales, hvis ens data egner sig dertil ).
>> Anbefales pga hastigheden, eller?
>
> Yep.
>
>> Jo, men her er des så jeg bliver vanskelig og gerne vil ha' en text-file
>> viewer med chr-position read-out så jeg kan tælle mig frem til hvordan
>> indlæsningsloopet skal konstrueres. Det drejer sig om mange filer (ca
>> 50), nogle med store datasæt på 400 karakterer.
>
> Det lyder mere som om, det er en eller anden form for indledende
> behandling af dataen, du har brug for.
>
> Jeg vil tro, at en del udviklere ville bruge sprog som perl eller lignende
> til at opsplitte dataen. Ikke fordi lige præcis perl er nødvendigt til
> opgaven, men til simpel processering af tekstfiler kan det være et godt
> værktøj at kende.
>
> Jeg er stadigvæk lidt i tvivl om formatet. Kan du prøve at lægge en fil op
> et sted? Det kan være, det er meget simpelt at konstruere en hjemmeside,
> som kan konvertere teksten til et andet format (fx CSV).
>

Peter Brodersen (05-05-2008)
Kommentar
Fra : Peter Brodersen


Dato : 05-05-08 13:00

On Mon, 05 May 2008 09:07:54 +0200, Bjarne Jensen
<bjarne.b.jensen@gmail.com> wrote:

>OK, her ligger så et eksempel:
>
>http://thejarlog.phpwebhosting.com/usaf/FILE0

Hentet. Hm, der er ingen linjeskift i den fil?

--
- Peter Brodersen
Kendt fra Internet

Stig Johansen (05-05-2008)
Kommentar
Fra : Stig Johansen


Dato : 05-05-08 18:08

Peter Brodersen wrote:

> On Mon, 05 May 2008 09:07:54 +0200, Bjarne Jensen
> <bjarne.b.jensen@gmail.com> wrote:
>
>>OK, her ligger så et eksempel:
>>
>>http://thejarlog.phpwebhosting.com/usaf/FILE0
>
> Hentet. Hm, der er ingen linjeskift i den fil?

Også hentet her, heller ingen ingen linieskift.
Men hvis man lige omlægger de første par records til:
01DEDUZGM00093ZERBST ....osv
01DVO IN99787KOLAR ....osv
01DEP PL00067PLOTY ....osv
01DLRTZRO00006TUZLA ....osv
01DESNFSW95751FARILA ....osv
01DKZ US08297PLANEACRES ....osv
01MUBBGAJ00001GYANDZHA ....osv
01MUD AM00005YEREVAN YEGVARD ....osv
01MUDELAM65747SHIRAK ....osv
01MFNHUAO66547HUAMBO ....osv
så lugter det langt væk af data udtræk fra noget IBM - 'noget'.
Det plejer at se sådan ud.

01 i starten er måske en eller anden form for generationsangivelse.
De næste 5 karakterer ligner en transaktionstype - DEDUZ, DVO, DEP osv.
Resten af indholdet skal højst sandsynligt fortolkes afhængigt af
transaktionstypen.

Disse ting med variant records er uhyggelig nemt at lave i COBOL, og der
burde som minimum være en dokumentation i form af record definitions for de
forskellige datasæt/transaktionstyper.

Uden dokumentation har Bjarne et stykke arbejde med at lave reverse
engeneering.
Med dokumentation, tror jeg det bliver noget af en udfordring at lave
indlæsning uden egentlig programmering.

Nu har jeg ikke kigget filen igennem (- linieskift), men som regel er
transaktionslængden afhængig af transaktionstypen.

Så der kan muligvis være tale om variende record længder ned igennem
datasættet.

--
Med venlig hilsen
Stig Johansen

Michael Zedeler (06-05-2008)
Kommentar
Fra : Michael Zedeler


Dato : 06-05-08 23:57

Bjarne Jensen wrote:
> OK, her ligger så et eksempel:
>
> http://thejarlog.phpwebhosting.com/usaf/FILE0
>
> (den buster min quota på siten så den bliver snart slettet igen)

Det er ikke en uoverkommelig opgave at skrive et lille perl-script som
kommer med et meget velkvalificeret gæt på hvor lang hver record er,
samt hvilke felter, der er.

Hvis det har interesse, skruer jeg gerne et sammen og poster det her.

Mvh. Michael.

Bjarne Jensen (07-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 07-05-08 16:54

Det ku'være interessant. Please go ahead!

Bjarne (som har slettet filen)

Michael Zedeler skrev:
> Bjarne Jensen wrote:
>> OK, her ligger så et eksempel:
>>
>> http://thejarlog.phpwebhosting.com/usaf/FILE0
>>
>> (den buster min quota på siten så den bliver snart slettet igen)
>
> Det er ikke en uoverkommelig opgave at skrive et lille perl-script som
> kommer med et meget velkvalificeret gæt på hvor lang hver record er,
> samt hvilke felter, der er.
>
> Hvis det har interesse, skruer jeg gerne et sammen og poster det her.
>
> Mvh. Michael.

Michael Zedeler (07-05-2008)
Kommentar
Fra : Michael Zedeler


Dato : 07-05-08 22:33

Bjarne Jensen wrote:
> Det ku'være interessant. Please go ahead!
>
> Bjarne (som har slettet filen)

Jeg får nok brug for at du lægger filen frem, men den behøver ikke at
indeholde så mange records. Hvis der bare er 50-100 stykker, er det fint.

Nu er det lidt sent at skrive scriptet, men jeg regner med at lave det
imorgen.

Mvh. Michael.

Bjarne Jensen (10-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 10-05-08 19:45

OK, så ligger der en anden fil (samme problem)

http://thejarlog.phpwebhosting.com/usaf/RWY.TXT

Den er endnu større så den må slettes snart.

Glæder mig til at se dit script.

Bjarne


Michael Zedeler wrote:
> Bjarne Jensen wrote:
>> Det ku'være interessant. Please go ahead!
>>
>> Bjarne (som har slettet filen)
>
> Jeg får nok brug for at du lægger filen frem, men den behøver ikke at
> indeholde så mange records. Hvis der bare er 50-100 stykker, er det fint.
>
> Nu er det lidt sent at skrive scriptet, men jeg regner med at lave det
> imorgen.
>
> Mvh. Michael.

Michael Zedeler (10-05-2008)
Kommentar
Fra : Michael Zedeler


Dato : 10-05-08 20:06

Hej Bjarne.

Bjarne Jensen wrote:
> OK, så ligger der en anden fil (samme problem)
>
> http://thejarlog.phpwebhosting.com/usaf/RWY.TXT
>
> Den er endnu større så den må slettes snart.

Denne fil er jo en almindelig csv-fil. Den burde du ikke have noget
problem med at indlæse. Den benytter tabulatorer til at adskille
felterne og linieskift efter hver række. Slipper du mit script løs på
den, får du ikke noget brugbart resultat.

Mvh. Michael.

Bjarne Jensen (10-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 10-05-08 21:20

Hovsa - det havde jeg ikke lige set - skimmedede den kuns lige i mc.


Michael Zedeler wrote:

> Denne fil er jo en almindelig csv-fil. Den burde du ikke have noget
> problem med at indlæse. Den benytter tabulatorer til at adskille
> felterne og linieskift efter hver række. Slipper du mit script løs på
> den, får du ikke noget brugbart resultat.
> Mvh. Michael.

Michael Zedeler (10-05-2008)
Kommentar
Fra : Michael Zedeler


Dato : 10-05-08 19:59

Hej Bjarne.

Bjarne Jensen wrote:
> Det ku'være interessant. Please go ahead!

Det tog lidt længere tid end forventet, men det var da skægt at lave.
Dette script laver en liste af forslag til mulige record-længder for en
given datafil.

Bemærk at scriptets køretid er O(n^2), så hvis du giver det en meget
stor datafil, bliver det aldrig færdigt. Du kan med fordel fodre
programmet med et udsnit der starter i starten af det datasæt, du vil
undersøge. Hvis der er sikkerhed for at datafilen altid indeholder et
helt antal records (at det ikke slutter i midten af en record), kan man
skrive det om til at køre i ca. O(n log(n)) hvilket er en del hurtigere.

Man kan også lave en eller anden adaptiv søgning, så scriptet selv kan
regne ud hvornår det skal holde op med at lede, men det må komme i en
senere version...

Derudover kan man også udvide scriptet til at finde kolonner, men det
resultat man så ville få, er en del mere usikkert, så det har jeg
droppet indtil videre.

Syntaks: recsize.pl < datafil

Output: første tal i hver række er et forslag til en record-størrelse og
andet tal er hvor godt den størrelse passer (højt tal ~ passer godt).

Mvh. Michael.

--- recsize.pl begynder her ---
#!/usr/bin/perl

# Find possible record sizes of data files with fixed size records and
# no record separators.

# Author: Michael Zedeler.

# Method:
# For each candidate record size:
# Set initial candidate record size score to zero.
# Traverse data column by column:
# Find size of vertical columns of spaces
# Each vertical column of space contributes with its height squared
# to the score of the given candidate record size.
# Print candidate record size and log10 of score.
#
# The highest scoring record size candidates are the ones that are
# most likely to be correct.

use warnings;

$/ = undef;
my @data = grep { $_ !~ /[\r\n]/} split //, <STDIN>;
my $data_length = @data;
my @scores;

foreach $record_length ( 3 .. $data_length ) {
my $records = int($data_length/$record_length);
my $score = 0;
my $height = 0;
for( my $i = 0; $i < $records * $record_length; $i++ ) {
# Traverse data column by column
my $row = $i % $records;
my $column = int( $i / $records );
my $char = $data[$row * $record_length + $column];
$height++ if( $char eq ' ');
# Add score of vertical space if we see another char or at end
# of column
if( $row == $records or $char ne ' ' ) {
$score += $height ** 2;
$height = 0;
}
}
# We may have missed a final score if last char was a space
$score += $height ** 2;
$score = log($score)/log(10);

print "$record_length: $score\n";
}

Bjarne Jensen (10-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 10-05-08 21:24

Tak for det Michael. Jeg har hovedet begravet i et byggeproject pt så
det varer lige et par dage før jeg melder tilbage.

/Bjarne (som sletter cvs filen igen)

Bjarne Jensen (12-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 12-05-08 21:03

Hi Michael,

Du skrev,

> Output: første tal i hver række er et forslag til en record-størrelse og
> andet tal er hvor godt den størrelse passer (højt tal ~ passer godt).

Jeg har pillet hvad der ser ud til at være den første record ud af FILE0
og lagt den op som http://thejarlog.phpwebhosting.com/usaf/b.b

Jeg kunne godt tænke mig at høre hvad du får ud af at køre scriptet da
jeg ikke rigtigt ved hvordan jeg skal tolke ex

../recsize.pl < b.b
3: 2.35602585719312
4: 2.26245108973043
5: 2.20682587603185
6: 2.13033376849501
7: 2.06069784035361
8: 2.03742649794062
9: 1.94448267215017
10: 1.94939000664491
11: 1.85125834871908
12: 1.82607480270083
13: 1.81291335664286
14: 1.83884909073726
15: 1.81954393554187
16: 1.72427586960079
17: 1.78532983501077
18: 1.69019608002851
19: 1.7160033436348
20: 1.72427586960079
21: 1.61278385671974
22: 1.67209785793572
23: 1.70757017609794
24: 1.55630250076729
25: 1.53147891704226
26: 1.54406804435028
27: 1.57978359661681
28: 1.65321251377534
29: 1.50514997831991
30: 1.50514997831991
31: 1.47712125471966
32: 1.49136169383427
33: 1.5910646070265
34: 1.65321251377534
35: 1.5910646070265
36: 1.46239799789896
37: 1.46239799789896
38: 1.46239799789896
39: 1.47712125471966
40: 1.47712125471966
41: 1.47712125471966
42: 1.49136169383427
43: 1.50514997831991
44: 1.61278385671974
45: 1.69897000433602
46: 1.74036268949424
47: 1.74036268949424
48: 1.43136376415899
49: 1.43136376415899
50: 1.43136376415899
51: 1.43136376415899
52: 1.43136376415899
53: 1.43136376415899
54: 1.43136376415899
55: 1.43136376415899
56: 1.43136376415899
57: 1.43136376415899
58: 1.47712125471966
59: 1.53147891704226
60: 1.53147891704226
61: 1.47712125471966
62: 1.47712125471966
63: 1.54406804435028
64: 1.54406804435028
65: 1.56820172406699
66: 1.5910646070265
67: 1.61278385671974
68: 1.65321251377534
69: 1.69019608002851
70: 1.69019608002851
71: 1.67209785793572
72: 2.69460519893357
73: 2.69460519893357
74: 2.69460519893357
75: 2.69460519893357
76: 2.69460519893357
77: 2.69460519893357
78: 2.69460519893357
79: 2.69460519893357
80: 2.69460519893357
81: 2.69460519893357
82: 2.69460519893357
83: 2.69460519893357
84: 2.69460519893357
85: 2.69460519893357
86: 2.69460519893357
87: 2.69460519893357
88: 2.69460519893357
89: 2.69460519893357
90: 2.69460519893357
91: 2.69460519893357
92: 2.69460519893357
93: 2.69460519893357
94: 2.69460519893357
95: 2.69460519893357
96: 2.69460519893357
97: 2.69460519893357
98: 2.69460519893357
99: 2.69460519893357
100: 2.69460519893357
101: 2.69460519893357
102: 2.69460519893357
103: 2.69460519893357
104: 2.69460519893357
105: 2.69460519893357
106: 2.69460519893357
107: 2.69460519893357
108: 2.69460519893357
109: 2.69460519893357
110: 2.69460519893357
111: 2.69460519893357
112: 2.69460519893357
113: 2.69460519893357
114: 2.69460519893357
115: 2.69460519893357
116: 2.6954816764902
117: 2.6954816764902
118: 2.6954816764902
119: 2.6954816764902
120: 2.6954816764902
121: 2.6954816764902
122: 2.6954816764902
123: 2.6954816764902
124: 2.6954816764902
125: 2.6954816764902
126: 2.69635638873333
127: 2.69635638873333
128: 2.69635638873333
129: 2.69722934275972
130: 2.69983772586725
131: 2.7041505168398
132: 2.71011736511182
133: 2.71767050300226
134: 2.72672720902657
135: 2.73719264270474
136: 2.74896286125616
137: 2.74896286125616
138: 2.74896286125616
139: 2.74896286125616
140: 2.74896286125616
141: 2.74896286125616
142: 2.74896286125616

Mvh Bjarne

Michael Zedeler (12-05-2008)
Kommentar
Fra : Michael Zedeler


Dato : 12-05-08 22:48

Bjarne Jensen wrote:
> Du skrev,
>
>> Output: første tal i hver række er et forslag til en record-størrelse
>> og andet tal er hvor godt den størrelse passer (højt tal ~ passer godt).
>
> Jeg har pillet hvad der ser ud til at være den første record ud af FILE0
> og lagt den op som http://thejarlog.phpwebhosting.com/usaf/b.b
>
> Jeg kunne godt tænke mig at høre hvad du får ud af at køre scriptet da
> jeg ikke rigtigt ved hvordan jeg skal tolke ex

Så vidt jeg kan se har du hevet een record ud af filen. Det er ikke nok
til at scriptet giver noget pålideligt output. Hvis du mener at hver
record er max N bytes lang, så tag de første N*10 bytes fra filen og
fodr programmet med den. Det gør ikke noget hvis du kommer til at klippe
i midten af en record. Du kan roligt fodre programmet med en fil på
50kb. Det giver større præcision, men du skal nok afbryde programmet når
du kan se hvilken størrelse, der er ser ud til at være korrekt.

> ./recsize.pl < b.b
> 3: 2.35602585719312

Her står at recordstørrelse 3 scorer 2.36. De recordstørrelser med
højest score er dem, der er mest sandsynlige. Når du kun har fodret
programmet med een record, er output helt ubrugeligt. Hvis blot du er
sikker på at der er mindst 4 records, bør det træde meget tydeligt frem
hvad den rigtige størrelse er.

Læs beskrivelsen som jeg anbragte inde i programmet for at forstå hvorfor.

Mvh. Michael.

Bjarne Jensen (20-05-2008)
Kommentar
Fra : Bjarne Jensen


Dato : 20-05-08 17:52

Aha! Lo and behold - nu fangede jeg den. Det virker ganske fint på en 50
kb fil.
Tak for indsatsen Michael!

Mvh / Bjarne

Michael Zedeler (22-05-2008)
Kommentar
Fra : Michael Zedeler


Dato : 22-05-08 22:43

Bjarne Jensen wrote:
> Aha! Lo and behold - nu fangede jeg den. Det virker ganske fint på en 50
> kb fil.

Fornøjelsen er skam på min side. Det var da skægt at skrive det script.

Mvh. Michael.

Søg
Reklame
Statistik
Spørgsmål : 177428
Tips : 31962
Nyheder : 719565
Indlæg : 6407944
Brugere : 218877

Månedens bedste
Årets bedste
Sidste års bedste