| Re: Histogram Hot-shots Required [message #16364 is a reply to message #16297] |
Mon, 19 July 1999 00:00   |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Eddie Haskell (haskell@see.signature.edu) writes:
> The number of the bin in which the data value resides can be calculated
> as:
>
> bin=(where(R ge ((where(((where(A eq V))[0]) eq
> R[R[0]:*]))[0]+R[0])))[0]
>
> and the number of elements in that bin is then:
>
> num=R[bin+1]-R[bin]
Just because I know you folks like a little fun...
I don't really understand this little equation of Eddie's,
but I thought I would implement it anyway and compare it
to the example Liam and other's sent me. Here is the way
I implemented my code. The Histogram method is returning,
via the keywords, the original array that the histogram is
performed on, the bin size, and the reverse indices. Value,
you recall, is the value I have and I want to know which bin
this value is in.
histdata = info.image->Histogram(Data=array, Title=title, $
Binsize=binsize, Reverse_Indices=r)
bins = (Findgen(N_Elements(histdata)) * binsize) + Min(array)
; Liam's method:
binNum = Round((value - Min(array)) / binsize)
; Eddie's method:
binNum =(where(R ge ((where(((where(array eq value))[0]) eq $
R[R[0]:*]))[0]+R[0])))[0]
pixelDensity = histdata[binNum]
Since the bin number must be an integer, I experimented
with taking the FLOOR, CEIL, and ROUND of the calculated
value using Liam's method.
Here is what I learned. Most of the time, the two methods
are pretty good at finding the same bin number, but not
always. If I take the FLOOR of Liam's calculated value, the
bin number is pretty consistently one LESS than Eddie's
number. If I take the CEIL of Liam's value, the values
are mostly the same, but not always. If I take the
ROUND of the value, I see a similar pattern: mostly the
same, but not always.
Which number is most consistent with the graph of the
Histogram plot, do you think?
Plot, bins, histData, PSym=10
PLOTS, [value, value], !Y.CRange
Well, this surprised me, but it is Liam's number with
the ROUNDing.
Now...what do you make of that? Which do you think is
*really* more accurate?
And, then, tonight I was reading the release notes for IDL
5.2.1 and I found this:
HISTOGRAM Function Error with BINSIZE Set Fixed:
The HISTOGRAM function error resulting when the BINSIZE
keyword is set has been fixed in this release.
Could *this* be the problem? What *was* that problem, anyway?
I'm still confused. I don't like code with fudge factors and
algorithms I arrive at by trial and error. :-(
Let's just say I'm awaiting further insight...
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
