Open bootchk opened 8 years ago
To answer your question: Yes, since we designed the algorithm as an iterative procedure, updatePixelEntropy
was implemented as specified. I guess it didn't have to be called periodically. However, we implemented it that way for a reason, which I can't recall at the moment. It may bring itself to the forefront as you continue your testing.
To clarify, the function computes a value and stores it in KDI.entropy. But the value of KDI.entropy is not used in the function, nor anywhere else except when the value is read but not recomputed to create saliency map at the end. At which time the values KDI.entropy could be stale with respect to iterations that occurred after the values KDI.entropy were calculated. I could be mistaken.
You're correct. This was an oversight.
The updatePixelEntropy() function is called every 32 iterations. It stores a result in the densityEstimate, but the result does not seem to be a function of prior results. Also, after iteration stops, it seems like there likely have been additional samples (after the last call to updateEntropy) which have not contributed to the estimate.
I removed the periodic call to this function and made method KernelDensityInfo.entropy() (instead of a data field), called only once when creating the saliency map. That doesn't seem to affect the results, good or bad. So this is not much of an issue.
But just for my understanding, is the purpose to be found in equation 5 of your paper? My best guess is that the top equation of 5 should be computed every iteration by updatePixelEntropy(), but that computing it every 32 iterations is heuristic simplification from the ideal. But the data flow doesn't seem to support that purpose.