Fans: data item 'spread' is really half-spread?

[michaelaye]

My reconstruction of fans only fits well if I interpret the data item 'spread' as the half-spread angle for fans. When I take spread as the full spread angle of a fan: When I take spread as the half-angle of spread:

Do we maybe have it written down somewhere how the data items are derived from the GUI, or what exactly in geometrical terms each data item means?

Edit: I should add that this is a marking from myself, and the latter way is how I would have marked this fan.

[mschwamb]

Not that I don't believe you, but I didn't seem to notice that issue when doing my simple fan plotting. Do you have another example that ight not be as ambiguous what the volunteers were doing. Could it be this case t that in this cutout, the volunteers only marked the very dark region? Do you have another cutout example to show as well? Cheers, ~Meg On 7/13/14, 6:38 PM, K.-Michael Aye wrote:

My reconstruction of fans only fits well if I interpret the data item 'spread' as the half-spread angle for fans. When I take |spread| as the full spread angle of a fan: spread https://cloud.githubusercontent.com/assets/69774/3567138/39c0e2ae-0b10-11e4-8dd5-08dcadb55a83.png When I take |spread| as the half-angle of spread: half_spread https://cloud.githubusercontent.com/assets/69774/3567137/39c0bb58-0b10-11e4-94b8-b7a479e63798.png

Do we maybe have it written down somewhere how the data items are derived from the GUI, or what exactly in geometrical terms each data item means?

— Reply to this email directly or view it on GitHub https://github.com/zooniverse/MarsZoo/issues/107.

[michaelaye]

I don't know why you speak about volunteers? I wrote that this is all me.

I have lots examples, it's all the time it doesn't fit. spread is actually spread/2: spread is the full spread:

[mschwamb]

@chrissnyder can we talk about this and confirm whether its the full or half angle on the telecon next week?

Thanks, ~Meg

[michaelaye]

I will provide the notebook with my math included until then, so that everybody can check if my math is wrong or the interpretation of the p4 data.

[michaelaye]

Didn't have time for nice notebook, but my math is here: https://gist.github.com/michaelaye/9b628988c6c2afdb431d

[michaelaye]

I did some more playing with the developer tools. Findings:

• Confirmed more than once, and at different positions inside subframe (corner and center), that a right-angle fan spread is represented by about 36 degree.
• A 180 spread angle (most likely not precisely) provides a value of 87, so very close to the half-spread value.

[michaelaye]

Here's another one, trying to do a 45 angle spread. While it's hard to do just visually, the given value is I think significant enough off from the half-value (16 given vs 21-24 for a half angle, including my drawing uncertainty).

[brian-c]

So sorry, I just read this thread today and I've been playing with it all morning. Looks like there are definitely some bugs in the fan tool. It's consistently wrong though, so we should be able to back up and get the right numbers based on how the tool actually renders.

I have zero confidence in my ability to get the math right; @ggdhines, can you help me with some nasty trig when you've got a minute?

Here are some commands I'm using to debug:

Show the values of all current marks: JSON.stringify(zooniverse.models.Classification.instances[0].annotations)

Manually manipulate the values on the first mark: zooniverse.models.Classification.instances[0].annotations[0].set({source: {x: 0, y: 0}, distance: 250, angle: 45/2, spread: 45}) (E.g. this one should have a side nearly parallel with the top.)

I'm currently fixing the tool to render correctly, but I won't deploy until we figure out how to reinterpret the data. I'll keep this thread posted.

[mschwamb]

@brian-c So the drawing tools is fine, it's the way it records values is wrong?

While you're at it, would you mind confirming there aren't any issues with the blotch/ellipse tool? It didn't look there was, but it would be good to make sure.

[michaelaye]

Not to put salt in wounds, and thanks Brian that you work on that, but I don't understand what you mean Meg: What part of the drawing tool is fine if it doesn't record the correct values?

[mschwamb]

I'm asking if the fix for the 'tool to render correctly' means that it will make the interface calculate the correct angle (I presume it really uses pixel positions and computes the angle ), and that's it's not changing how the user draws the fan or how the user currently interacts with the fan tool.

[michaelaye]

Gotcha. I agree it would be fan if the way the fan tool operates would change. But even for this potential change, we need to mark the transition. There are usually 2 ways to do it:

1. Note down the time t in a configuration file and have the reduction routines do one reduction for the times before t and another one for times after t.
   • Advantage: Only one for data point to keep.
   • Disadvantage: The data becomes not self-consistent, requiring a meta-data file.
2. Add another column called 'fan_version' indicating what version of the fan tool was run.
   • Advantage: Self-consistent data
   • Disadvantage: A lot of extra data-fields for this one information.

If I were to have a vote, I'd have a slight preference for method 2, as in the grander scheme, the fractional increase isn't that much, is it?

[brian-c]

The fan tool has been fixed, and they now have a version: 2 property.

Next step is to write a little formula to correct the old values.

The entire issue was that I was drawing the semicircle of the fan using the radius of a circle inscribed in the fan's extended triangle (from the source point out to the distance point) when I should have been using the side of a square inscribed in half that triangle (Brooke figured out the math here), so the error starts small and gets more severe with larger spread angles. Very sorry about that that, and that it wasn't caught until now.

I just opened a pull request (#111). @chrissnyder, you mind merging and deploying that?

[michaelaye]

Ok, just to be sure: Will spread now be the full spread or the half spread of the fan?

[brian-c]

Full spread.

[mschwamb]

Makes sense now why for smaller fans the spread angles looked fine when we plotted it for smaller fans earlier on

Just to make sure everything is kosher, when you do the equation to convert the spread currently in the database, would it be possible for someone to make the edits required for the extra columns in the code that outputs the csv file and send the science team the new csv file so @michaelaye can confirm the spread matches?

@brian-c We probably need this for the paper anyway, so while we have you, how do you set the radius for the semicircle in the fan tool? For both default marking if someone just mouse clicks and for someone who grabs the handles around?

Thanks @brian-c for sorting this!

[michaelaye]

In Chrome, the spread handlers are awkwardly close to the direction handler at the end of the fan. Could they maybe get a bigger distance? https://www.dropbox.com/s/gpfi1vavctmzki2/Screenshot%202014-07-31%2011.50.11.pdf

[michaelaye]

Yay, 90 degrees! :+1: https://www.dropbox.com/s/h7jkfveztnz5vfp/Screenshot%202014-07-31%2011.51.13.pdf Thanks, @brian-c

[brian-c]

Deployed a fix for overlapping spread handles.

[mschwamb]

So just to confirm @brian-c there's a way to back out the correct fan spread angle from what's in the database? Can you share the conversion formula whenever that's ready? No pressure and thanks for sorting so quickly. Much appreciated!

[brian-c]

No calculation yet, but I did build a table to see how far off everything is. Looks like the recorded values start off at about half what the user saw, shrinking to 1/2.4 at 39°, and then dropping back down to about half.

It might take me a bit of time to work this out, I hope this is useful until then.

Recorded	Seen by user	Seen/Recorded
1	2.0175	2.0175
2	4.0698	2.0349
3	6.1568	2.0523
4	8.2784	2.0696
5	10.4343	2.0869
6	12.6239	2.1040
7	14.8470	2.1210
8	17.1028	2.1379
9	19.3907	2.1545
10	21.7098	2.1710
11	24.0592	2.1872
12	26.4379	2.2032
13	28.8447	2.2188
14	31.2783	2.2342
15	33.7373	2.2492
16	36.2201	2.2638
17	38.7252	2.2780
18	41.2509	2.2917
19	43.7952	2.3050
20	46.3562	2.3178
21	48.9319	2.3301
22	51.5203	2.3418
23	54.1191	2.3530
24	56.7261	2.3636
25	59.3391	2.3736
26	61.9557	2.3829
27	64.5736	2.3916
28	67.1905	2.3997
29	69.8041	2.4070
30	72.4120	2.4137
31	75.0120	2.4197
32	77.6019	2.4251
33	80.1794	2.4297
34	82.7425	2.4336
35	85.2890	2.4368
36	87.8172	2.4394
37	90.3251	2.4412
38	92.8109	2.4424
39	95.2731	2.4429
40	97.7101	2.4428
41	100.1204	2.4420
42	102.5028	2.4405
43	104.8561	2.4385
44	107.1792	2.4359
45	109.4712	2.4327
46	111.7313	2.4289
47	113.9586	2.4247
48	116.1527	2.4198
49	118.3129	2.4145
50	120.4390	2.4088
51	122.5306	2.4026
52	124.5874	2.3959
53	126.6094	2.3889
54	128.5965	2.3814
55	130.5487	2.3736
56	132.4661	2.3655
57	134.3490	2.3570
58	136.1974	2.3482
59	138.0117	2.3392
60	139.7922	2.3299
61	141.5392	2.3203
62	143.2532	2.3105
63	144.9347	2.3006
64	146.5839	2.2904
65	148.2016	2.2800
66	149.7881	2.2695
67	151.3440	2.2589
68	152.8698	2.2481
69	154.3662	2.2372
70	155.8337	2.2262
71	157.2728	2.2151
72	158.6842	2.2039
73	160.0684	2.1927
74	161.4261	2.1814
75	162.7578	2.1701
76	164.0641	2.1587
77	165.3455	2.1473
78	166.6028	2.1359
79	167.8363	2.1245
80	169.0468	2.1131
81	170.2347	2.1017
82	171.4007	2.0903
83	172.5452	2.0789
84	173.6688	2.0675
85	174.7720	2.0561
86	175.8554	2.0448
87	176.9194	2.0336
88	177.9645	2.0223
89	178.9912	2.0111

[brian-c]

Wasn't as tough as I thought. Here's a bit of CoffeeScript that does the conversion. Give it the angle that was recorded and it'll return the angle the user thought they were drawing.

{PI, cos, atan} = Math
toRad = (deg) -> deg / (180 / PI)
toDeg = (rad) -> rad * (180 / PI)
correctSpread = (spread) ->
  adjacent = 100 # Doesn't actually matter
  hypotenuse = adjacent / cos(toRad(spread))
  opposite = hypotenuse * sin(toRad(spread))
  inradius = (adjacent * opposite) / (adjacent + opposite + hypotenuse)
  renderedOpposite = inradius * 2
  renderedAdjacent = adjacent - renderedOpposite
  renderedAngle = atan(renderedOpposite / renderedAdjacent)
  renderedSpread = renderedAngle * 2
  return toDeg(renderedSpread)

Let me know if you need a hand converting this into another language.

[mschwamb]

Thanks very much. so with the csv file we get weekly, will the science team need to do the conversion ourselves of the spread using what you wrote above or is the plan to update the database moving the old fan values to a another variable in the database so we keep it for tracking sake and then update the spread variable ?

[brian-c]

@parrish: Would it be hard to run this function on the old records in the data dump as it's generated?

[mschwamb]

@chrissnyder and @brian-c I saw in the commit logs that the version number was added in a fix after the deploy on the fan angle correction. Did I see that correctly (https://github.com/zooniverse/MarsZoo/commit/f332091d283ffbf8581bb4bf692acc613b156a53) . If that is the case, are those classifications made after the fan tool was fixed going to manually get a version number so that we don't incorrectly correct them?

Thanks,

~Meg

[brian-c]

Those changes were all deployed by Chris at the same time.

[mschwamb]

This issue is resolved, so we might want to close the ticket for housekeeping.