Thread: vector values not updating

Hi,

I'm having a problem with values read in from a file and assigned to a vector using push_back are not updating. After the values have been assigned, the vector returns zero for all of its values for a fixed time after assignment. The behavior is consistent, and I do not understand why it is happening.

Here are the primary methods involved:

Code:

process(Event &event)
{
  Module& md = *(_decoder->module(event.id()));
  if (_doonce) {
    std::cout << "Calling initPedestals for module: " << event.id()
              << " on event: " << event.event() << std::endl;
    initPedestals(md);
  }

  std::vector<double>& pedestals = (md.pedestals());
  // now we find the max channel
  ChannelList& channels = event.channels();
  ChannelList::iterator it = channels.begin();
  int channel;
  double max;
  for (;it!=channels.end();++it) {
    double signal = (*it)->signal() - pedestals.at((*it)->channel());
    std::cout << "Event: " << event.event()
              << " Channel: " << (*it)->channel()
              << " Signal: " << (*it)->signal()
              << " Pedestal: " << pedestals.at((*it)->channel())
              << " S - P: " << signal << std::endl;
    if (signal>max) {
      max = signal;
      channel = (*it)->channel();
    }
  }

  std::stringstream ss;

  ss << event.date() << ' ' << event.id() << ' ' << event.event() << ' '
     << channel << ' ' << max << '\n';

  _fman.file(_fname).write(ss.str().c_str(),ss.str().size());
//  _fman.file(_fname) << ss.str();
  _doonce = false;
}

initPedestals(Module &md)
{
  _pflist.insert(PFEntry(256,"pedestals.txt"));
  PFList::iterator it = _pflist.find(md.id());
  if (it!=_pflist.end()) {
    std::string name = it->second;
    FileManager fman;
    fman.open(name,FileManager::Old);
    std::fstream& file = fman.file(name);
    while (file.good()) {
      double val;
      file >> val;
      if (!file.good()) break;
      std::cout << "ped = " << val;
      md.pedestals().push_back(val);
      file >> val;
      if (!file.good()) break;
      std::cout << " noise = " << val << std::endl;
      md.noise().push_back(val);
    }
    for (int i=0;i<(int)md.pedestals().size();i++) {
      std::cout << "pedestal = " << md.pedestals()[i];
      std::cout << " noise = " << md.noise()[i] << std::endl;
    }
  }
  else
    for (int i=0;i<md.ntot();i++) {
      md.pedestals().push_back(0);
      md.noise().push_back(0);
    }
}

Sorry if the code is a bit ugly, I have been throwing print statements in everywhere to try and debug.

All of the print statements indicate that the value of all of the pedestal entries are 0 for about the first 75000 calls, at which point they begin to reflect the values read in from the file. However, the print statements also verify that the values are being read in at the beginning of the first call. I can't explain the delay between assignment of values using "push_back" in initPedestals and the return of the values using "at" in process. (or the direct access operator in the print statement in initPedestals either!)

If anyone can see what the problem is, or give me an idea of what might be causing this so I can track it down in the rest of my code, it would be much appreciated!

Ok, I got the values to register by doing this in initPedestals:

Code:

initPedestals(Module &md)
{
  _pflist.insert(PFEntry(256,"pedestals.txt"));
  PFList::iterator it = _pflist.find(md.id());
  if (it!=_pflist.end()) {
    std::string name = it->second;
    FileManager fman;
    fman.open(name,FileManager::Old);
    std::fstream& file = fman.file(name);
    std::vector<double> tmp1,tmp2;
    while (file.good()) {
      double val;
      file >> val;
      if (!file.good()) break;
      std::cout << "ped = " << val;
      tmp1.push_back(val);
      //md.pedestals().push_back(val);
      file >> val;
      if (!file.good()) break;
      std::cout << " noise = " << val << std::endl;
      tmp2.push_back(val);
      //md.noise().push_back(val);
    }
    md.pedestals().swap(tmp1);
    md.noise().swap(tmp2);
    for (int i=0;i<(int)md.pedestals().size();i++) {
      std::cout << "pedestal = " << md.pedestals()[i];
      std::cout << " noise = " << md.noise()[i] << std::endl;
    }
  }
  else
    for (int i=0;i<md.ntot();i++) {
      md.pedestals().push_back(0);
      md.noise().push_back(0);
    }
}

I would still appreciate an explanation of why this is necessary and any advice on how I could implement this better.

Thanks!

well, seems I was too optimistic about the above fix. The code works as is, but if i take out the various print statements and revert the control statements (basically undoing all the damage done during the debug process) the problem returns.

still looking for a true solution!

learn how to use a debugger added to my todo list.

i modified the else statement like so:

Code:

  else {
    std::cout << "what am i doing here" << std::endl;
    for (int i=0;i<md.ntot();i++) {
      md.pedestals().push_back(0);
      md.noise().push_back(0);
    }
  }

control never enters the else statement.

Originally Posted by cowboyjo

All of the print statements indicate that the value of all of the pedestal entries are 0 for about the first 75000 calls, at which point they begin to reflect the values read in from the file.

Let me guess. You sized your vector (by declaring whatever(75000) or something similar) when you declared it, putting 75000 copies of 0 in your vector, and then you're using push_back to add things to the back of your vector, after those 75000 zeroes.

How'd I do?

Let me guess. You sized your vector (by declaring whatever(75000) or something similar) when you declared it, putting 75000 copies of 0 in your vector, and then you're using push_back to add things to the back of your vector, after those 75000 zeroes.

How'd I do?

It doesn't seem to be that simple. I do not have a vector of length 75000 plus, I merely access the elements of a 128 deep vector 75000 times and get a zero, and then magically get the correct value on the 75001 time (it's actually 76495, but that's irrelevant).

I've confirmed the values are only read in and assigned at the beginning of the first call, that control never enters the final else statement in initPedestals, and no further calls to initPedestals are made.

Also, using swap to fill the vectors got rid of the problem temporarily, but it resurfaced when I changed the if statement at the top of process to "if (md.pedestals().empty())"

I'll post more info and a simplified example if I can recreate the problem within a simpler context, but until then I would still appreciate any insight into this problem. Has any one ever experienced anything like this?

Originally Posted by cowboyjo

I'll post more info and a simplified example if I can recreate the problem within a simpler context, but until then I would still appreciate any insight into this problem. Has any one ever experienced anything like this?

Well, to be honest, lots of times. And it's always been using push_back when I meant to assign whatever[i] instead (or forgetting about a bunch of zeroes in the front, etc.). That's strongly indicated by the fact that swap worked, since temp1 and temp2 were blank when you started, so you're not adding to the back of a lot of zeroes. (I mean, if you're calling this routine hundreds of times (if not 75000 times), your pedestal vector must get freakishly large.) I suppose you could check what pedestals().size() is when you start, and if it's not zero then you've got extra stuff. It sounds like your file is opening.

Thanks for your replies tabstop, I did find where the vector is being filled with zeros in a different part of the code.

What threw me was the fact that the correct values eventually did appear. Just for clarification, I'm only filling the pedestals vector with 128 values and then calling pedestals.at(0..127) to retrieve those values. Thus, I would have expected all accesses to pedestals to return 0, and can still not explain why the nonzero values suddenly appeared after so many calls. Perhaps there is still another bug to be tracked down...

I did get the time to pick up the basics of gdb this week, and it has already proved a worthwhile investment.

Just wanted to let you know that I did take your advice, laserlight, it just wasn't feasible in the time frame I had to fix the above bug.