#NoMethodError (undefined method `reject' for 0:Integer

Question

I am using ruby 3.0 and rails 7.0.2 for my application. when i try to run console or generate controller or migration it gives me this error:

NoMethodError (undefined method `reject' for 0:Integer Did you mean? rect):

if existing_problem_sets.present? 
  existing_problem_sets.each do |problem_set| 
    problem_set.update!(
      sat_question_id: problem_set.sat_question_id.reject{|x| x==self.id.to_s}, 
      sat_position: problem_set.sat_position.reject{|x| x[:sat_question_id] == self.id.to_s}) 
  end #do
end #if

Answer 1

sat_question_id: problem_set.sat_question_id.reject{|x| x==self.id.to_s}

@mechnicov comment may be the key.

• The error message tells you that the method reject does not exist in the Integer class (it is "undefined")
• Immediately you should be telling yourself "I need to lookup the Integer class in the Ruby docs."
• Where is reject being called? Right there! so sat_question_id might be/must be an integer.
• What are the current values of the object(s) in that code? If they are correct then maybe the code is wrong. What object(s)/Classes do I have that have a reject method?

Based on this snippit - x==self.id.to_s - I am going to GUESS you meant to code something like this:

sat_question_id: problem_set.reject{|x| x.sat_question_id.to_s == self.id.to_s}, 

Nobody's answer will be better than a guess without seeing your data class(es) declarations and some actual instantiated objects. The actual object that caused the accident.

Answer 2

First of all, this won't work – convolution has memory, and your convolver doesn't save that. This makes the numbers that come out of your blk to depend on in what kind of "chunks" your input signal is delivered. That's not OK, because GNU Radio can (and will) use different lengths at any time. Your algorithm must be written in a way that always yields the same result, no matter how your (infinite or finite) input stream is being partitioned for individual calls to work.

That's basically it – the problem here seems to be that the result of your np.convolve call doesn't have the same length as output_itmes[0]. Read the documentation of numpy.convolve; it specifies exactly why and when this happens:

Mode ‘same’ returns output of length max(M, N). Boundary effects are still visible.

So, if the chunk of samples you've gotten is shorter than h, then you're trying to save len(h) items in a len(output_items[0]) sized array, which is too short.

This can always happen – as said, GNU Radio needs to "cut" the signal into pieces and hand them to your work, and the length of these chunks isn't fixed. Your Throttle just makes it more likely to happen.

So, you first need to conceptually solve the fact that this is not proper mathematically (the convolution of a long signal is not the same as a sequence of truncated convolutions of short sub-segments, simple as that). Most likely the answer to this is to just use one of the filter blocks GNU Radio comes with anyway.