Interpreting values supposedly in fixed-point format

[DonRoth]

Hello Altenbach:

If the exponent is 14, then yes, the we have (2^14)*FractionY = 16384 * FractionY = FloatY.

No, I don't need to read as fixed point, any way to read is fine as long as I can get the answer.  So the next question is how to get FractionY so I can determine FloatY.  I thought to do that we would need to read in the fixed point format so that FractionY could be extracted somehow.

The other possibillity was to read in the file data as I32 as you did and find the ratio between the 0th value (367487552) and the known 0th value (63010.019) and then use this as the scaling factor for the data values. The problem with this is 1) it does not work to give the precisely same numbers as I show in the .xls file and 2) it is no guarantee to work for the next set of data down the road.

Sincerely,

Don

[DonRoth]

Centerbolt: Yes, but For the case of 0x40000000, sign bit is zero so it is a positive number so by your own formula would we not have 1*(2^2) = 4.  Where did you get the -2 (versus +2).  Still trying to figure out what formula makes 0x40000000 represent 0.25 and  0xC0000000 represents -0.25.  You may have to lay it our for me like an algebra proof - step-by-step....thanks, Don

[Wayne.C]

Don,

My formula shows 2 being raised to the ( -2 ) power.  In fact all the exponents in my examples are negative.  That is because of where the binary point is.  Binary point is to the left of this digit, Therefore exponent is negative.  This scheme is similar to what is used in DSP IC's.  I suspect that in this case it was personallized a bit.

All these negative exponents are only used to calculate float version of the FRACTION. 

Is the EXPONENT used for scaling in the header?

Message Edited by centerbolt on 05-27-2008 01:59 PM

[DonRoth]

I'm still not getting it - can you lay it out further with his examples using step-by-step and binary notation, and show me what you did.  Yes, the exponent is at byte offset 3 and labeled as char (although I read it in as U8) and gives 14.

The only header values I am concerned with (and am reading in fine) are:

Byte Position        Format        Name

3                           char             fexp

4                           DWORD     fnpts

8                           double           ffirst

16                         double          flast

Then the data starts at byte offset 544 as Altenbach stated.  There are fnpts number of data points.

[altenbach]

---

DonRoth wrote:

The other possibillity was to read in the file data as I32 as you did and find the ratio between the 0th value (367487552) and the known 0th value (63010.019) and then use this as the scaling factor for the data values. The problem with this is 1) it does not work to give the precisely same numbers as I show in the .xls file and 2) it is no guarantee to work for the next set of data down the road.

---

There is abviously something we are missing because it is the correct way to read it as little endian I32, and multiply by 2^(exponent-32) to get the scaled value. Everything else makes no sense. I don't know why the excel file would be different. Are you sure they are both based on the same raw data?

Can you post the specifications of the entire header?

[altenbach]

---

DonRoth wrote:

The other possibillity was to read in the file data as I32 as you did and find the ratio between the 0th value (367487552) and the known 0th value (63010.019) and then use this as the scaling factor for the data values.

---

This is obviously incorrect, because the scaling factor is NOT constant. SImply read the spc file with my method and the excel file (save as tab delimited text, the use "read from spreadsheet file). And you can immediately see that the multiplier is variable, which cannot be by your definition of the file structure.

Here I was using an exponent of x14, so the multiplier is 2^20 (1.04858E+6).

As you can see, the ratio between the two datasets varies between  ~1.2 and ~1.75 (rounded). The two datasets are similar, but NOT the same.

Message Edited by altenbach on 05-27-2008 12:09 PM

[DonRoth]

In fact you are correct.  After seeing your post, I brought up the thermoscientific viewer program to see the .spc file.  I just spoke with the person who sent me the files and he made a mistake.  Here is the correct .spc file corresponding to the .xls file.  Ignore the original .spc file. Sorry about that!! I should have checked first (and I specifically asked him to send me identical files!! one .spc and one .xls). But the data is still not scaled properly because as you can see the .xls file has data values between 50000 & 250000. 

In terms of the header specification, the only important values are the those I have laid out in the header file, and the data values according to the spec I gave in my original post.  There is an additional 32-byte subheader added onto the 512-byte header which is why the values start at 544 byte offset.

Sincerely,

Don

ps. contact me at donald.j.roth@nasa.gov so we can discuss the spec documentation issue off-line.

[altenbach]

Ah, now things start to make sense. Using an exponent of x13, the data are identical. Very few values differ by less than 0.0004, probably due to issues with the ASCII formatting when converting the xls file.

The figure shows the first 3500 points.... (there is a problem with the header size. that I have not explored yet)

(Don, I think you still have my e-mail. )

Message Edited by altenbach on 05-27-2008 12:37 PM

[altenbach]

OK, your second datafile is corrupt and is missing a byte somewhere near datapoint 3773. Values after that need to be read with a different frame shift.

Anyway, here's how you could read your galactic file, including relevant header.

Message Edited by altenbach on 05-27-2008 01:15 PM

[DonRoth]

I had the same problem with the bringing in the right number of data points using your I32 methodology.  The excel file length and the header fnpts value agree on the length of data. But we are making progress.

I will get in touch tomorrow. 

Also, sorry for the bonehead ratio method I was attempting - of course the fractionY value changes with every point since it is the data.  Too many things in my head!!

Sincerely,

Don