Re: [tlug] issues with format of double (or IEEE754)

[Michal Hajek <hajek1@example.com>]

Hello :)

 
> > on an i386 mashine...
> 
> ISA bus? 

no, I use a PCI bus gpib board from INES production. It has quite a good
support and documentation. 
Oh, I see the point now... it is not an actual 386 procesor. It is a

model name      : AMD Athlon(tm) 4 processor
stepping        : 2
cpu MHz         : 1466.890

based computer. 
Sorry for the confusion. My mystake.  

> > char result_normal_plus[17]="00000000000000000";
> 
> If that is global, keep in mind that result_normal_plus will 
> initialized only _once_. 
 
yes, thank you for pointing that out. But I consider the inicialization
as a side issue for the time being :) (this consideration is based on
the fact, that program returns a reasonable number, only 4 orders of
magnitude wrong, but the actual digits are right)

as for the number 17, it is just ad-hoc number. I choose it only to be
long enough. Perhaps a mystake. Perhaps it could be 10 as well. 
Since later I put "end of string" mark at position 10, I did not bother
to use the other 7 bits in any way. 
I thought I can change it to lower number later, when everything works
well. My understanding is that it only saves memory but actualy does not
influence anything alse.

> I am confused about which data is binary and which data is ASCII. 
> I get the hazy impression that ibrd() does binary, 
> so seeing result_normal_plus[ibcnt]='\0' looks odd. 

The function ibrd is implemented (by people writing gpib code for linux)
as:
int ibrd(int ud, void *buffer, long num_bytes); 

The problem is, that first 16bit read from the nanovoltmeter are two
asci characters (#0 header) which I do not want. Being a poor programer
myself, I could not find any other solution than just take everything
and store it in a string. Than point another variable (a pointer to
double) to the right place in the string (kind of saying "from this
point on take the following 8 characters as a double floating point
number").

Although if I know some kind of binary type where I could store 80 bits and
than take only last 64, it would be perhaps a less confusing solution. 

 
> Where is the problem? Divide and conquer. 
> Does the meter output in the format you expect? How do you know? 
> Does double* use the format you expect? How do you know? 
> 
> Print out in hexadecimal (or even binary!), 
> the data returned by ibrd(). 
> 
> Parse it by hand. Calculate what you believe the numbers to be. 

Out of despair, I have already started to work on that :) But the
results are not so easy to obtain... :) 
I need little more time. :)

 
> (BTW, where does ibcnt come from?)

ibcnt is set by ibrd() to the number of bytes read. 
So I use the information to cut the string in the right place. 
Sometimes it could be 0, if something goes wrong with the devices on
gpib bus or the bus itself. If all works ok, than the ibcnt is same as
the number you give to ibrd as last parameter. 
 
> First, make it work right, then make it work correct. 
...
> Did reading in ASCII, then converting with atof() work correctly? 

yes, it works well. No problem. 

 
> How much time does it take to do it _correctly_? 
well, I intend to run a measurement in a loop. One such loop has about
four atof() and whole together takes about 0.8 seconds to finish. 

I do not know how much time I can save with avoindig atof(). From profiler I
cannot source the information, since atof() is buried inside another
function. But if I run the program in gdb, than my personal subjective
impression is, that atof() takes considerably more time than for example
ibrd(). I do not know any other way how to find the information :( 

> Is the ASCII format and atof(), the fastest way that works _correctly_?
> Avoid premature optimization. 

Well, the program is rather simple. Maybe this is a wrong path from the
point of view of having work done. But I also want to know how things
work. So my line of reasoning was based on these assumptions :

1. the manual (which I believed) says the nanovoltmeter can return
values in binary IEEE754 double precision format
2. it should be possible to exploit this feature and avoid atof(). 

When the program does not work like I expected, I tend to look for the
errors in the program first and try to stick to assumptions as long as
possible. Only I understand why the assumptions are wrong, I am
satisfied and can leave them aside happily :) 

> Why do you care about speed? How much speed is enough? 

This is difficult to say. The nanovoltmeter can make a conversion very
quickly, but for my purpose about 16.6ms would be ok. In one loop, there
are 4 measurements. Together less than 0.07s.  For my math model, 7 loops
per second would be great. So there is about 0.5s for all the remaining
work on the computer side. But for a computer 0.5s could be a lot of
time, right? :) 

I do not know if I can reach this value, but every speed up will be
good. I want to go to the possible limit of hw.  Maybe I will have to go
realtime, but for the first approximation, I want to try without it. 

> just worry about correctness and making your program easy to understand. 

agree. At least easy to understand is definitely my goal too. 

Unfortunately, right now the timing of my work is a problem. I have
about 24 hours to find a solution and than I am leaving for 7 day
holiday.  After I come back, I will continue this work. So right now I
will try to find out what are the actual digits which the nanovoltmeter
returns and how they represent the measured value. I will let you know
what I have been able to find. 

Thank you once again for your advice...

Best regards
Michal