# Problem casting ULong64_t to Double_t in macro

Hi,

I have a macro which reads data from a TTree (using ULong64_t) and I need this data to be used in floating point calculation later on. Basically, I want to do the following:

``````ULong64_t  time;

Double_t  tinsec[i];

for (Int_t i=0; i<nentries;i++);
Tree->GetEntry(i);
tinsec[i]=time/1.e+9;
}``````

For some reason, this code works fine, except for the very first element of the array tinsec. For this one, I get a very small value.

To check this, I tried to just cast it using:

``````for (Int_t i=0; i<nentries;i++);
Tree->GetEntry(i);
tinsec[i]=(Double_t)time;
}``````

But this doesn’t work either… Any idea why this is? For the moment, I am using only the array elements for i>0, but this is very annoying…

Thanks!

Andrée

Hi Andree,
which ROOT version do you use?
Axel.

Hi!

I am using Root 5.08.

Thanks!

Andrée

Hi,
this sounds like a bug we’ve fixed a few weeks ago. Could you try CVS head or v5-14-00e or v5-15-04?
Cheers, Axel.

I just tried using the binary 5.14.00e for SLC4 and I get the same problem…

Here is the output:

(If I don’t try to cast the variable tinsec):
(i=0) time= 1147269598409000000 tinsec= 1.80749e+08
(i=1) time= 1147269605440000000 tinsec= 1.14727e+18

(And if I do):
(i=0) time= 1147269598409000000 tinsec= 1.80749e+08
(i=1) time= 1147269605440000000 tinsec= -1.37819e+09

Andrée

Hi,

you script is wrong: your for loop doesn’t do anything, and you don’t properly declare tinsec. [code]#include

void a() {
const int nentries = 10;
ULong64_t time;
Double_t tinsec[nentries];

for (Int_t i=0; i<nentries;i++) {
time = 1147269598409000000;
tinsec[i]=time/1.e+9;
cout << “time=” << time << " tinsec=" << tinsec[i] << endl;
}
}[/code]works for me.
Axel.

Sorry, I made a typo in my very first post (but not in the code!) where I should have declared tinsec to be Double_t tinsec[nentries]; and not Double_t tinsec[i];

To be clear, I am taking the data from a TTree, so time is declared in the macro as the tree branch. My loop does something since time is a new value obtained from GetEntry for each value of i.

In more details:

``````   TTree *bp = (TTree*)gDirectory->Get("bp");
ULong64_t       time;

Long64_t nentries = bp->GetEntries();
Double_t tinsec[nentries];
for (Int_t i=0; i<nentries;i++);
bp->GetEntry(i);
tinsec[i]=time/1.e+9;
}     ``````

Can you try this?

Andrée

Hi Andree,
just to let you know: I didn’t forget you, I’ll come back to you tomorrow.
Axel.

Hi Andree,
does the attached script work for you?
Axel.
t2.C (468 Bytes)

Hi Axel,

I tried it with root 5.08 and 5.14 and I got the following error message:

``````Error: integer literal too large, add LL or ULL for long long integer t2.C:14:
(const unsigned long long)4294967295
*** Interpreter error recovered ***``````

Thanks!

Andrée

Hi,
sorry, I was working on a 64bit machine. Can you try with `time = 1147269598409000000ULL;`
Axel.

Hi!

Ah, that’s what the error message meant…

I tried and here is the output on both 5.08 and 5.14:

``````time: 1147269598409000000 tinsec[0]: 0.180749
time: 1147269598409000000 tinsec[1]: 1.14727e+09
time: 1147269598409000000 tinsec[2]: 1.14727e+09
time: 1147269598409000000 tinsec[3]: 1.14727e+09
time: 1147269598409000000 tinsec[4]: 1.14727e+09
time: 1147269598409000000 tinsec[5]: 1.14727e+09
time: 1147269598409000000 tinsec[6]: 1.14727e+09
time: 1147269598409000000 tinsec[7]: 1.14727e+09
time: 1147269598409000000 tinsec[8]: 1.14727e+09
time: 1147269598409000000 tinsec[9]: 1.14727e+09``````

So it still gives it wrong to me for the first value and ok for the others… Can it be related to the fact that I am worknig on a 32-bit machine then?

Andrée

Hi Andree,

I was able to reproduce it with a build from March 19. This has already been fixed in the current CVS head.

Cheers, Axel.

Hi Axel,

Thanks for that info! So, this should be in for the next root version release or is there a way for me to checkout the newest version from CVS?

Cheers,

Andrée

Hi,
yes you can check it out, see the root web page’s CVS link (it’s on the left). You’ll have to build root yourself, though. The next root development release is coming next week.
Axel.

or wait for the next development release next Wednesday

Rene