Several things seem odd about the current bumps design. This ticket is to see if there is a good reason for any of them.
- Maximum 10 bumps per type. Seems completely arbitrary. See
|
raise RuntimeError("No more than 10 bump filters of a type allowed. Exceeded for type "+key_orig) |
for the error message; the code above it hardcodes looking for 10.
- Why are keys being created with the original key, a dot, and a counter?
|
new_key = key_orig+"."+str(i) |
- It is not entirely clear to me if the order in which one applies the bumps matters. If each transforms the k-space representation then they would be order dependent. I think that is not the case because the code applies each bump to the original data,
x, and adds up the results. Can anyone confirm?
It seems to me a more natural data structure would be to make the bumps a list of Bump objects, with each object having all relevant info including the signal key.
Several things seem odd about the current bumps design. This ticket is to see if there is a good reason for any of them.
bifs/bifs/priors/AbstractPrior.py
Line 195 in d4a786a
bifs/bifs/priors/AbstractPrior.py
Line 190 in d4a786a
x, and adds up the results. Can anyone confirm?It seems to me a more natural data structure would be to make the bumps a list of Bump objects, with each object having all relevant info including the signal key.