Comments on: Computing Graph Limits https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/ Thoughts, rants, and even some code from the mind of Barney Boisvert. Thu, 11 Sep 2014 09:58:12 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Barney https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/comment-page-1/#comment-321 Barney Fri, 07 Apr 2006 16:08:33 +0000 http://barneyb.com/barneyblog/?p=151#comment-321 Adam, that's good stuff. I'll have to tune my solution a little on that. I don't know why the heck I didn't think of using logarithms, but that should make things much more straightforward. Adam, that's good stuff. I'll have to tune my solution a little on that. I don't know why the heck I didn't think of using logarithms, but that should make things much more straightforward.

]]> By: Adam Ness https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/comment-page-1/#comment-320 Adam Ness Fri, 07 Apr 2006 15:53:31 +0000 http://barneyb.com/barneyblog/?p=151#comment-320 I did up some formulas for this a few years ago, using CFCHART. I was always using a minimum value of 0, so you might need to adjust it, but here's the psuedocode: <cfset orderOfMag = int(log10(maxValue))> <cfif orderOfMag gt 1 and (maxValue/10^orderOfmag) lt 5> <cfset totalMax = (int(maxValue/10^orderOfMag)*4+1)/4 * 10^orderOfMag> <cfset gridLineCount = int(totalmax/10^orderOfMag)*4+1> <cfelseif orderOfMag gt -1 or (maxValue/10^orderOfmag) gt 5> <cfset totalMax = (int(maxValue/10^orderOfMag)*2+1)/2 * 10^orderOfMag> <cfset gridLineCount = int(totalmax/10^orderOfMag)*2+1> <cfelse> <cfset totalMax = (int(maxValue/10^orderOfMag)*4+1)/4 * 10^orderOfMag> <cfset gridLineCount = int(totalmax/10^orderOfMag)*4+1> </cfif> I did up some formulas for this a few years ago, using CFCHART. I was always using a minimum value of 0, so you might need to adjust it, but here's the psuedocode:

<cfset orderOfMag = int(log10(maxValue))>
<cfif orderOfMag gt 1 and (maxValue/10^orderOfmag) lt 5>
<cfset totalMax = (int(maxValue/10^orderOfMag)*4+1)/4 * 10^orderOfMag>
<cfset gridLineCount = int(totalmax/10^orderOfMag)*4+1>
<cfelseif orderOfMag gt -1 or (maxValue/10^orderOfmag) gt 5>
<cfset totalMax = (int(maxValue/10^orderOfMag)*2+1)/2 * 10^orderOfMag>
<cfset gridLineCount = int(totalmax/10^orderOfMag)*2+1>
<cfelse>
<cfset totalMax = (int(maxValue/10^orderOfMag)*4+1)/4 * 10^orderOfMag>
<cfset gridLineCount = int(totalmax/10^orderOfMag)*4+1>
</cfif>

]]> By: Patrick McElhaney https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/comment-page-1/#comment-319 Patrick McElhaney Fri, 07 Apr 2006 14:20:23 +0000 http://barneyb.com/barneyblog/?p=151#comment-319 It sounds like you want your interval to be 10^n, where n is a whole number. Gotta run, but I hope that helps you move a little bit closer. It sounds like you want your interval to be 10^n, where n is a whole number.

Gotta run, but I hope that helps you move a little bit closer.

]]> By: Barney https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/comment-page-1/#comment-318 Barney Thu, 06 Apr 2006 20:19:46 +0000 http://barneyb.com/barneyblog/?p=151#comment-318 An interesting turn of scope; I think it's still the same question, but maybe not. I'm thinking ceiling((high - low) / intervalCount) is what you're looking for. However, if high and low are 21,753 and 23,543, it's going to be arbitrary, because ceiling operates at the decimal point, and those numbers won't yield meaningful factional parts. This is the same problem that I had to begin with: devising a general solution for finding the limits. There's something lurking in there with scaling the ceiling call (some factor of the range), but I can't put my finger on it. Here's a better description of what I do currently: compute the range of values, create the smallest number with 1 non-zero digit that is strictly larger than the range, divide that by the number of intervals, and then find the next smallest and next largest intervals below and above the actual range. So for 21753 and 23543, the range is 1790, the 1-sig-fig number is 2000, 10 intervals yields 200 per interval, and the tightest boundaries are 21600 and 23600 (which, as you'd expect, are 2000 apart). That worked really well in this case, but when there's a jump right at the end, not so much. Consider 21,500 to 23,501: range is 2001, 1-sig-fig number is 3000, so 300 per interval, with boundaries of 21,300 and 23,700, which are NOT 3000 apart. However, what I'm now realizing is that perhaps forcing the number of intervals is what my problem is. The algorithm does yield a good range, just not one that can be broken in the right number of parts. But that number doesn't really matter. What does 10 versus eight intervals really matter? An interesting turn of scope; I think it's still the same question, but maybe not. I'm thinking ceiling((high – low) / intervalCount) is what you're looking for. However, if high and low are 21,753 and 23,543, it's going to be arbitrary, because ceiling operates at the decimal point, and those numbers won't yield meaningful factional parts.

This is the same problem that I had to begin with: devising a general solution for finding the limits. There's something lurking in there with scaling the ceiling call (some factor of the range), but I can't put my finger on it.

Here's a better description of what I do currently:

compute the range of values, create the smallest number with 1 non-zero digit that is strictly larger than the range, divide that by the number of intervals, and then find the next smallest and next largest intervals below and above the actual range. So for 21753 and 23543, the range is 1790, the 1-sig-fig number is 2000, 10 intervals yields 200 per interval, and the tightest boundaries are 21600 and 23600 (which, as you'd expect, are 2000 apart).

That worked really well in this case, but when there's a jump right at the end, not so much. Consider 21,500 to 23,501: range is 2001, 1-sig-fig number is 3000, so 300 per interval, with boundaries of 21,300 and 23,700, which are NOT 3000 apart.

However, what I'm now realizing is that perhaps forcing the number of intervals is what my problem is. The algorithm does yield a good range, just not one that can be broken in the right number of parts. But that number doesn't really matter. What does 10 versus eight intervals really matter?

]]> By: Josh https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/comment-page-1/#comment-317 Josh Thu, 06 Apr 2006 19:59:46 +0000 http://barneyb.com/barneyblog/?p=151#comment-317 Make that 0 to 80. Make that 0 to 80.

]]> By: Josh https://www.barneyb.com/barneyblog/2006/04/06/computing-graph-limits/comment-page-1/#comment-316 Josh Thu, 06 Apr 2006 19:58:37 +0000 http://barneyb.com/barneyblog/?p=151#comment-316 Instead of trying to calculate bounds first, try to determine a good interval first. For instance, if your values range from 8 - 76, you might find that 10 is a good interval. Then you can base the chart bounds on that inverval. You could make the chart go from 80. I don't have a good function on hand to find a good interval, but it shouldn't be too hard to write one. Instead of trying to calculate bounds first, try to determine a good interval first. For instance, if your values range from 8 – 76, you might find that 10 is a good interval. Then you can base the chart bounds on that inverval. You could make the chart go from 80.

I don't have a good function on hand to find a good interval, but it shouldn't be too hard to write one.

]]>