Thank you Chris. Indeed, swaping does the trick. No need for unpack now baby! Woohoo!
On 10 July 2011 01:23, chm <[email protected]> wrote: > On 7/9/2011 2:44 AM, dpath2o wrote: > >> Hi Chris, et. al. >> >> OK, so this might interest you because I don't know if it's a non-feature >> or >> a bug in FlexFaw. Below is some code that will process the attached file. >> Notice the difference in the results. However this is assuming that >> FlexRaw >> 'float' and unpack 'f' should behave in the same manner. >> > > Your template is using 'f>' not 'f'. Do you get the > same result as readflex if you use just 'f'? > > > Anyway, while syntax-icly! this clunky I know that I can proceed here and >> use PDL, and this makes me happy. It'd be nice to understand why these >> results are different. >> > > The '>' and '<' modifiers are for little-endian and > big-endian byte order specification.My guess is that > your platform is '<' byte order which is why you get > different results. > > > Cheers. >> >> ------------------------------ >> use strict; use warnings; use PDL; use PDL::IO::FlexRaw; >> my $hdr_size=84; >> my $N_DopplerBins=512; >> open(CS,'dat.cs'); >> binmode(CS); >> seek(CS,$hdr_size,0); >> my $bytes = readflex( \*CS , [ { Type=>'byte' , NDims=>1 , >> Dims=>[$N_DopplerBins*4,1] } ] ); >> my @tmp = unpack 'f>*', ${ $bytes->get_dataref }; >> my $dat1 = pdl @tmp; >> print "UNPACK RESULTS: ".$dat1."\n"; >> seek(CS,$hdr_size,0); >> my $dat2 = readflex( \*CS , [ { Type=>'float' , NDims=>1 , >> Dims=>[$N_DopplerBins,1] } ] ); >> print "FLEXRAW RESULTS: ".$dat2."\n"; >> close(CS); >> ------------------------------**- >> UNPACK RESULTS: [1.963092e-12 1.4716339e-12 3.4353432e-12 2.1053842e-12 >> 1.5967331e-12 1.3974084e-12 2.7670049e-12 ... 2.0514502e-12] >> FLEXRAW RERSULTS: [-7.88412e+26 3.67428e-08 -8.21574e-17 0.00254942 >> 2.66434e+19 -6.76475e+30 -2.80484e+28 ... -4.75018e-17] >> >> >> On 9 July 2011 13:41, dpath2o<[email protected]**> wrote: >> >> Hi Chris, >>> >>> The readflex documentation is not clear on how to swap byte order. Can >>> you >>> give a standard example? >>> >> > Yes, the documentation is not complete on this point. > Basically for the 'f77' and 'swap' toggles, they need > to be the first headers before the one to read any > data as they just change the state of the IO. E.g., > > $data = readflex($fh, > [ { Type=>'swap' }, > { Type='float', NDims=>1, Dims=>[512] } > ] ); > > appears to be the syntax to use or just a line by > itself in a .hdr file. > > Cheers, > Chris > > > > On 7 July 2011 21:11, chm<[email protected]> wrote: >>> >>> On 7/7/2011 2:55 AM, dpath2o wrote: >>>> >>>> Chris, et. al. >>>>> >>>>> I'm through the header and now into the data portion of this file. I >>>>> have >>>>> used your suggestions to get through the header and they have worked >>>>> really >>>>> nicely. >>>>> >>>>> I have successfully read the data into a piddle with the following >>>>> command: >>>>> my $data = readflex($fh, [ { Type=>'float', NDims=>3, >>>>> Dims=>[$Dpplr_n,10,$rng_n] } ] ); >>>>> Note: the 10th dimension there is because of a quality control values >>>>> for >>>>> each range cell. >>>>> >>>>> However, that method makes getting out the data a little more tricky >>>>> and >>>>> the >>>>> following method is more intuitive: >>>>> for (my $i=0; $i<$rng_n; $i++) { >>>>> my @data = readflex($fh, [ >>>>> { Type=>'float', NDims=>1, Dims=>[$Dpplr_n] }, >>>>> { Type=>'float', NDims=>1, Dims=>[$Dpplr_n] }, >>>>> { Type=>'float', NDims=>1, Dims=>[$Dpplr_n] }, >>>>> { Type=>'float', NDims=>2, Dims=>[2,$Dpplr_n] }, >>>>> { Type=>'flota', NDims=>2, Dims=>[2,$Dpplr_n] }, >>>>> { Type=>'float', NDims=>2, Dims=>[2,$Dpplr_n] }, >>>>> { Type=>'float', NDmins=>1, Dims=>[$Dpplr_n] } >>>>> ]); >>>>> } >>>>> >>>>> My problem that I'm stuck on right now is verifying that the data is >>>>> actually the data! >>>>> >>>>> >>>> If the reading is correct, I would expect the values to >>>> be identical. The general approach I use is to read a single >>>> chunk of data by hand in the pdl2 shell doing one readflex() >>>> at a time and verify the data step-by-step. >>>> >>>> Some problems you might be having (the kind I usually >>>> see myself): >>>> >>>> (1) perl is 0 based and matlab is 1 based array indexing >>>> so you could confirm that the offsets are not off-by-1 >>>> >>>> (2) data big/little-endian issues (does the data look >>>> better if you swap bytes or reverse them? try using >>>> unpack on the data chunk using the get_dataref trick >>>> to investigate. >>>> >>>> (3) dimension order for matlab and PDL multidimensional >>>> data is different---probably not the issue here with >>>> all the 1-D reads, but it could be. >>>> >>>> Hope this helps, >>>> Chris >>>> >>>
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
