Thread: a histogram program

  1. #31
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Yes, well the OP hasn't even responded as of yet and we have already accumulated 1050 views on this thread. We should give this a break.

  2. #32
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by tabstop View Post
    Which is why you ask the question of how often it happens.
    Not really, because it amounts to paying attention to noise.

    You just have to accept the a histogram is a noisy representation of the data. If you are trying to make decisions in a way that would be influenced by sample flip-flopping due to noise, then you are using the histogram in a way that is not justifiable.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #33
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by claudiu View Post
    So what you are saying is that because a histogram is just a gross interpretation of the real distribution it is perfectly OK to do a sloppy job in implementing it. That's just marvelous!

    The REAL issue here is that you can pick values for the input array so that you will get different histograms while running that same code on the same input.
    That's ridiculous. There's nothing sloppy about it.

    A value can only end up affecting the height of the wrong bar if the rounding caused by storing the number in the float data type to begin actually pushes the value across the logical boundary between bars. That's an error rate of 1 in 2^25! I.e. 1 in 32 million. Even if the original poster produced 100 histograms, from 100 data values each, the chance that even one of those values would end up in mathematically the wrong bar is still under 1 in 1000, and that unlucky data point was so damn near the boundary that it practically had just about as much right to end up where it did anyway.
    It does not make the graph wrong!

    At the end of the day its only usage it to provide a rough estimation of the distribution of the data, and the person viewing it simply has no basis for treating the result any differently to what one produced from an infinitely accurate data type could produce. In all practicality, your argument is just pointless nonsense.

    Yes I have coded histograms in a professional product,.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  4. #34
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Quote Originally Posted by iMalc View Post
    That's ridiculous. There's nothing sloppy about it.

    A value can only end up affecting the height of the wrong bar if the rounding caused by storing the number in the float data type to begin actually pushes the value across the logical boundary between bars. That's an error rate of 1 in 2^25! I.e. 1 in 32 million. Even if the original poster produced 100 histograms, from 100 data values each, the chance that even one of those values would end up in mathematically the wrong bar is still under 1 in 1000, and that unlucky data point was so damn near the boundary that it practically had just about as much right to end up where it did anyway.
    It does not make the graph wrong!

    At the end of the day its only usage it to provide a rough estimation of the distribution of the data, and the person viewing it simply has no basis for treating the result any differently to what one produced from an infinitely accurate data type could produce. In all practicality, your argument is just pointless nonsense.

    Yes I have coded histograms in a professional product,.
    You are right in that this should not be a particularly large error rate, but you are wrong assuming that it is constant. The rounding error is dependent on other things not accounted for here such as: compiler, architecture (specifically native floating point register design) and even weird things such as the number of instructions between your floating point variable initialization and its subsequent use in a local function. A compiler may choose to optimize the code or send things out of order for speculative execution.

    Yes, using a float is sufficient. Using a double is doing the best you can do.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Need help with a program, theres something in it for you
    By engstudent363 in forum C Programming
    Replies: 1
    Last Post: 02-29-2008, 01:41 PM
  2. Replies: 4
    Last Post: 02-21-2008, 10:39 AM
  3. Replies: 3
    Last Post: 03-04-2005, 02:46 PM
  4. My program, anyhelp
    By @licomb in forum C Programming
    Replies: 14
    Last Post: 08-14-2001, 10:04 PM