votevote.page is live

culi

@paretoman Just rewatched the video. Yup my calculations do already use the geometric mean instead of the euclidean mean haha

culi

PS you can preview the upcoming versions here: https://dev--votevote.netlify.app/

This week's been crazy at work so I probably won't be able to implement the color space changes until next weekend, but I have some other exciting updates already in

paretoman

@culi The OKLrCH is interesting. It seems to give the least amount of banding when cycling through hues, at least in my eyes. I would think it would be really good for measuring distance. Well, with one transformation. I would use the hue (H) as a polar angle in cylindrical coordinates and C as the radius. Then convert to cartesian and measure distance. I don't know how I would actually implement this, but it's an idea

... I guess color space is like a double cone with extra pointy parts. I wonder how different this double cone would be from the RGB cube on its diagonal.

rob

Regarding the video about how RGB blending is wrong due to gamma... that's true, although I suspect of minor importance in this scenario. But you could certainly do the conversion prior to comparing colors for proximity.

For your purposes, though, the gamma issue is pretty minor importance. If you are doing graphics stuff such as a paint program, much more so. The important thing here is to have it communicate to people who want to mostly think about voting theory, not color theory. (I say this as someone who has spent far more time working with and thinking about color theory than voting theory)

Whether or not you account for gamma, it is still RGB, though, and I think that's rather important. Other systems tend to have degenerate cases, as black white and gray in HSV. Hue is indeterminate for black, for instance, but near blacks would have a hue. So #000001 and #010000 both appear as black on most monitors, but have very different hues meaning they are treated as not-particularly-close colors. The significance of hue should be reduced as the saturation is reduced.... and that is true for RGB systems.

If you want to get even better, you can account for the fact that certain RGB colors (whether or not you've done the above d-gamma-ing) appear lighter than others even if their RGB sum is equal. Pure blue (#0000ff) is much darker-appearing than pure green (#00ff00), at least on monitors. (less so if printed with an ink jet). So you could distort the cube to account for that, like how the Munsell color model is distorted to put yellow at a higher value than blue.

Notice that in Munsell, the physical distance in the color solid is a good indicator of similarity of colors. However, the way Munsell numerically represents the colors (which is HSV, but not the simplified form used in most computer representations), would not be a good way to determine similarity, since it amplifies the importance of hue with low saturation colors.

It's great to allow users to have options, but for the vast majority of the users that don't spend a lot of time thinking about color theory, try to go with what is most intuitive: if colors appear similar, treat them as similar.

You spoke of color names, and that is a different issue. Personally I wouldn't use any names, or stick with simple ones (red, yellow, green etc) rather than expecting people know what is meant by "seafoam". I go to the beach often enough to know what the color of seafoam is, and it ain't that.

Yup! This is supposed to be an exploration of the ways to count votes itself and not at all model real life elections

Sure but strategy is sort of at the heart of all this stuff. You can simplify it, as I did with my simulators, but ignoring it altogether, seems quite misleading to me.

culi

@rob The color names are based on XKCD's average from their survey of thousands of people. I'd say the results are, by design, much closer to how people map color names to colors than what some paint company decides

rob

@culi Maybe true but I wouldn't rely on names at all, especially if you are using them in ways that go beyond simple visual. (i.e. "distance" between colors)

culi

@rob Fair, but I still don't see why it's an issue. You can remove/add whatever candidates and/or voters you'd like. If you want to limit yourself to red/green/blue/other basic colors you totally can!

Anyways all these concerns should be resolved once I have it set up so anyone can add their own custom dataset

rob

@culi said in votevote.page is live:

If you want to limit yourself to red/green/blue/other basic colors you totally can!

Gotcha. To be clear, I wasn't suggesting limiting to basic colors like that because that defeats the whole purpose. My suggestion would be pick the colors purely visually from a palette (a small 8x8 palette for 64 colors would be perfect), or using a color picker. If you use a color picker and it shows the RGB values that are used in the proximity calculations (preferably with gamma applied so it is more realistic per the linked video), people will know what 'color proximity' actually means, so I'd consider that a huge plus.

Expecting people to set up a custom dataset is fine, if it's that kind of app. If you want to have something that quickly communicates a concept though, not the approach I'd use.

Obviously it's your app and you can handle it as you want. I actually love the idea of using colorspace to represent ideological space, BTW.

culi

@rob said in votevote.page is live:

To be clear, I wasn't suggesting limiting to basic colors like that because that defeats the whole purpose. My suggestion would be pick the colors purely visually from a palette (a small 8x8 palette for 64 colors would be perfect), or using a color picker.

Oh gotchu. Yeah not a bad idea

Expecting people to set up a custom dataset is fine, if it's that kind of app.

Oh no, that's not actually what I meant. What I envision is that the default is to use the current color data. But there's a drop down to use other stuff.

For example, in Wikipedia there's a common example given of cities in Tennessee trying to elect a new capital. Each city's preferences are based on their X,Y coordinates and distance from each other. I could totally add this as a dataset as well (with even more cities probably)

And then at that point I think the logical next step is to make one of the drop down options "custom" where the user can enter arbitrary data. This might also actually make this toy somewhat useful. Like if someone already has votes from a scored election and is wondering how the outcome would've differed under a different scoring method, they can enter that data here simulate it all

But the default would still be color-based unless the user specifically decides they wanna go with something else.

Jack Waugh

Do you have the source code up on Gitlabs or Bitbucket or Github or the like?

culi

@jack-waugh At the bottom of all my projects is a "Steal This" button that takes you to the source code. It's up on GitHub:

https://github.com/tif-calin/votevote/

Though I must warn you I haven't yet cleaned it up to make it easy to contribute to (planning on it when I get some free time).

All the logic happens inside this SuperElection class. The main motivation behind this is making a lot of use of cacheing to optimize these calculations. I.e. why calculate the borda score twice for Borda and for STAR when you can just calculate it once and reuse it.

So it's quite tangled up right now and not as documented as it should be