Here's my problem: I want to display a pie chart (using the awesome Zedgraph library available on CodeProject), but I don't know in advance how many slices it will have. It can be 5, it can be 25. Of course, I could define a hundred or so color constants, but that is not very elegant.
I've searched on Google for a color generation algorithm that would generate a random set of reasonably contrasting colors, but I can't find anything.
Anybody has seen anything like this? If you have or know of some source code, in any language, that would be great, C# preferred. For an example of how it should work, see Excel, no matter how many slices you add (within reason), it generates different colors for each slice.
I actually think your best way would be to create a cyclic ordered list of about 16 colors: c1->c2-> ..., c20 ->c1 ... where each color is nicely contrasted with the one in front of it (I think any real totally non color-constant based method could create high contrast colors, but would have a hard time making them be attractive).
Then you could either just keep cycling between the colors as you create boxes (and checking that the first bar color generated is high contrast with the last, which will be adjacent pie pieces), or you could tweak the r, g, and b values of each color by adding a plus or minus 3 or something to each value.
Basically, I just don't think that people can at all easily tell between more than about 20 colors the way you need them to for your app. (as an experiment if you reply to this, check out the list of emoticons you can choose from - almost all are in the orange/redish side of the spectrum. How many of those do you think you could really easily tell the difference between if you we looking for pieces in a pie? 4 maybe? So if you have 4 for each of red, yellow, green, blue, you need 16 constants).
So point is that after any hypothetical algorithm you're describing generates 16 or 20 colors or so, it'll be tough to start telling new colors apart from old. Therefore making a list of 20 color values, *hand-picked* to look particularly good together, is likely the best way to go.
If you want to add a little variety to the 20 colors, I would say take the rgb triplet of each color "generaed" and add a random number in the [-j, j] range, where j is some number you'll have to figure out empirically based on what works best. That'd be likely to be best of both worlds, I think.
I've trying to read a .txt files in order to plot the data on a ZedGraph. The problem is I cannot convert the data to double. The compiler gives bunch of errors(Error 1 Cannot convert type 'string' to 'double'). The following is a piece of code that i'm having trouble with.
private void BRead(GraphPane myPane)
FileStream fleReader = new FileStream("kel.txt", FileMode.Open, FileAccess.Read);
StreamReader stmReader = new StreamReader(fleReader);
StringBuilder lstChars = new StringBuilder();
double x = 0, y;
int iChar = stmReader.Read();
// double yx = new double[lstChars.Length];
PointPairList list = new PointPairList();
while (iChar > -1)
x = x + (double)0.0002;
iChar = stmReader.Read();
y = (double)(lstChars.ToString()); //error
Replace: y = (double)(lstChars.ToString()); //error
with: y = Convert.ToDouble(lstChars.ToString());
You are attempting to perform a cast that is not implicit. You need to use the ConvertTo function to handle this type of cast. Also, if the string does not represent a double or has characters in it that would not be used to represent a double the cast will fail.
This error tells me that the string that you are passing in to be converted contains something other than numbers and a decimal point. For example if you pass in "A32.41" the conversion to double will fail. If you pass in "36.42" the coversion will pass. Look to see what the actual string is when you call the convert function.
Say there is a parliamentary consituency with X number of voters. Candidates A, B, C and D are standing for election. There is also the possibility that a voter may abstane or they may spoil their paper. Thus when the results are announced it is stated how many votes each candidate received, how many abstaned, and how many spoiled ballot papers there were.
If X (the total number of eligible voters) is known. How many permutations of results will allow candidate A to win? (using a first-past-the-post system. i.e. the candidate with more votes than any other candidate. Spoiled papers and abstentions are ignored for a win)
that should be simple:
- abstaned/spoiled can be ignored completely, so you can remove them immediately
(rather than after doing the permutations)
- so there remain four candidates ABCD, of their permutations obviously one quarter
has A first, hence winning.
the one slight inaccuracy is the small chance that first and second place have equal
number of votes (and hence are undecided both in result and in permutation order),
but then a revote would be required, and it would again be 1 out of 4.
Sorry, that's not quite what I wanted. I wanted to know how many permutations in total there would be. Also, permutations including absentee and spoiled votes do count since they are valid scenarios.
For example with an electorate of 2 the permutations are:
A B C D Absentee Spoiled
200000 A wins
100010 A wins
100001 A wins
In the above, there are 3 permutations where A can win
If that chart were continued for an electorate of 45,000 voters, how many permuations would A win. Is there a formula that can calculate this?
Luc Pattyn wrote:
Going for president in Scotland ??
Not quite, there are elections coming up in a little over a month and one of the "election communications" I got said that only C or D can win this seat. A or B cannot win. I just wanted to write back and claim false avertising on the grounds that mathematically there were so many permutations of results where A could indeed win the election.
I'm still not with you, you gave no clue as to any difference between A,B,C and D,
so they all have equal chances, and hence A/B/C/D will each win with 25% probability.
To put it differently, there are many permutations that make A win, but a similar
set of permutations makes B (or C or D) win.
Or still differently: with the given info, there is absolute symmetry.
So, what you are saying here is that (without spoiled or absentee ballots) there are 25% of possible permutations that allow a candidate to win. From your other post you possibly hinted that the total number of permutations was number of options (X) to the power of the number of electorate (Y): X^Y
So, discounting absentee and spoiled papers (which I don't want to do because they are valid options and do affect the balance) the number of permuations where A wins is (4^45000)/4
also I am not convinced you should concentrate on the table of permutations, because
different lines have different probabilities, so counting the lines does not help.
As an example, assume two voters E and F; they each can vote A/B/C/D/absent/spoiled
(6 possibilities each), so there are in fact 36 different combinations (that you
would group in 30 lines):
A B C D ab sp count
2000001 requires E and F to both vote A
1000102 requires E to vote A and F to be absent, OR vice versa
1000012 requires E to vote A and F to spoil, OR vice versa
0200001 requires E and F to both vote B
0100102 requires E to vote B and F to be absent, OR vice versa
0100012 requires E to vote B and F to spoil, OR vice versa
0020001 requires E and F to both vote C
0010102 requires E to vote C and F to be absent, OR vice versa
0010012 requires E to vote C and F to spoil, OR vice versa
0002001 requires E and F to both vote D
0001102 requires E to vote D and F to be absent, OR vice versa
0001012 requires E to vote D and F to spoil, OR vice versa
1100002 requires E to vote A and F to vote B, OR vice versa
1010002 requires E to vote A and F to vote C, OR vice versa
1001002 requires E to vote A and F to vote D, OR vice versa
0110002 requires E to vote B and F to vote C, OR vice versa
0101002 requires E to vote B and F to vote D, OR vice versa
0011002 requires E to vote C and F to vote D, OR vice versa
0000201 requires E and F to both be absent
0000112 requires E absent and F spoil, OR vice versa
0000021 requires E and F to both spoil
I am writing an app that will download a 60MB file to update a DB on 20 remote users that all have 144K air cards. the internet connection that host the DB has a max upload speed of 250kbps and upload of 1MB.
I am trying to figure out at what KB will the upload speed kill the download speed.
I am also trying to figure out how to randomize the times they download the file in a controlled manner on the update flag is tripped.
A simple approach would be to split your serial number into two sections. One section contains a sequential number the other is a random number. The first section will make your number unique while the second makes it non-consecutive.
If you want to have some kind of validation for the numbers add a third section containing a hash of the first two.
Actually, if I understand your algorithm correctly, I don't think it's the best thing to do. (Please correct me if I'm wrong though)
Basically, your set of numbers will be much less random than they should be (they will end up being much more evenly spread over the range than they would be if they were "really" random).
If you try to generate a list of a bunch of random and non-equal 4 digit numbers, the way I understand your algorithm works, it would do something like the following (got the random umbers on the right hand side from python).
And you're saying that because of the numbers on the left, from 10 to 14, guarantee the numbers will be unique (which is true), and the ones on the right "randomize" the numbers. The problem is that your numbers aren't very random at all (not uniformly distributed in the range 1000-9999). If you generate 40 numbers this way, none of them will be over 5000. For a really random set of 40 different numbers, the chance would be somewhere around (but not equal to, because the numbers are all different) about (1/2)^40, which is no chance at all.
If you switch your algorithm around, by putting the random half first, you get something MUCH better. In this case, you would get the numbers 4710, 6711, 7712, 2313, 1114. Your numbers will be much, much, much more random. In this guys case, you'd generate 11 digit random numbers, and use the last 5 for the sequence. They still won't be as great as they could theoretically be. If, for example, you did statistical tests of these numbers, you would find that exactly 10% of the numbers end in 1, 10% in 2, and so on. Obviously that wouldn't be true of a "really" random set.
Basically the best way to do it is just generate random numbers in that range. There is about a one in 50 million chance you'll have overlaps if your random number generator is good.
Last Visit: 31-Dec-99 19:00 Last Update: 28-Nov-22 16:02