--- Log opened Tue Jun 11 00:00:43 2019 20190611 00:15:24<+wesdiscordbot> @ghype My one comment for now would be to just make sure you don't take on too much at once, with the Dunefolk sprites and new music. 20190611 00:21:21<+wesdiscordbot> @ghype i was thinking something choral/orchestral should probably be reserved for a single use at the end of a campaign. So, probably something... uplifting 20190611 00:22:45-!- celmin|away is now known as celticminstrel 20190611 04:40:21-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] 20190611 06:49:59-!- galegosimpatico [~ec2-user@unaffiliated/ushiu] has left #wesnoth-dev ["WeeChat 1.9.1"] 20190611 07:16:31-!- galegosimpatico [~ec2-user@unaffiliated/ushiu] has joined #wesnoth-dev 20190611 07:19:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190611 07:22:12-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190611 07:27:35-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190611 07:37:34<+wesdiscordbot> we are working mostly in a team. spriting is something I do on the way all the time and making music is my main occupation. So that would be fine. but Hejnewar had a good remark. Instead of contributing generally to Wesnoth music and sounds - what if I instead focus on creating a theme for Dunefolk, if we seariously want to establish them in wesnoth? 20190611 07:38:41<+wesdiscordbot> that could be great, actually. The orcish wardrums in some scenarios make great atmosphere 20190611 08:14:20<+wesdiscordbot> @ghype that definitely sounds like a good idea ๐Ÿ‘ 20190611 08:41:30-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 258 seconds] 20190611 08:51:50<+wesdiscordbot> @Vultraz That's the statistics dialog change we talked about last week 20190611 08:52:17<+wesdiscordbot> I changed the -5 to 0 before merging 20190611 08:52:27<+wesdiscordbot> I think it looks fine now... 20190611 08:54:02-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190611 08:56:44<+wesdiscordbot> screenshot https://github.com/wesnoth/wesnoth/pull/4070#issuecomment-500751546 20190611 09:33:35<+wesdiscordbot> will take a closer look when i have a chance 20190611 10:01:25-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 252 seconds] 20190611 10:01:42-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190611 10:09:15<+wesdiscordbot> thanks 20190611 11:25:06-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20190611 11:45:12<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/587970581060780032/2019-06-11-112448_422x185_scrot.png 20190611 11:45:44<+wesdiscordbot> Interesting how the damage stats and hits stats can tell different stories 20190611 11:46:20<+wesdiscordbot> +3% sounds like it was a little lucky, 93.4% sounds like it was very lucky 20190611 11:47:20<+wesdiscordbot> Another one 20190611 11:47:21<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/587971119009759232/2019-06-11-114649_325x177_scrot.png 20190611 11:59:10< Soliton> what do the percentages and their color mean? 20190611 12:19:42-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev 20190611 12:27:20-!- Appleman1234 [~Appleman1@2001:44b8:21b3:4001::100] has joined #wesnoth-dev 20190611 12:29:19-!- celticminstrel is now known as celmin|away 20190611 12:34:20<+wesdiscordbot> I'd like to know as well, because I don't get it. 20190611 12:37:48<+wesdiscordbot> The color shifts from red (first % big) to green (first % small) and the first % is smaller if the first number is closer to 0. Maybe it tells you how likely it would have been for the number to be smaller/bigger? 20190611 12:40:01<+wesdiscordbot> (In that case it would make more sense if the color shifts from red (1st number bigger than 2nd number) to green (1st number = 2nd number) to red (1st number smaller than 2nd number). 20190611 12:41:07-!- Appleman1234 [~Appleman1@2001:44b8:21b3:4001::100] has quit [Ping timeout: 250 seconds] 20190611 12:41:12<+wesdiscordbot> Or to reverse the color shift, so green indicates 'good luck' (more dmg inflicted than expected) and red indicates 'bad luck' (less dmg inflicted than expected). 20190611 12:47:09<+wesdiscordbot> Soliton, @Konrad2 https://github.com/wesnoth/wesnoth/blob/e27ddf7535dbcd49ca0d1f2832c3ed9539bb7997/data/gui/window/statistics_dialog.cfg#L568 20190611 12:47:30<+wesdiscordbot> If the tooltip doesn't explain what the numbers are, I'll revise the tooltip ๐Ÿ˜ƒ 20190611 12:48:29<+wesdiscordbot> @Konrad2 About the colors, they're chosen so green means "you were unlucky" and red means "you were lucky". https://github.com/wesnoth/wesnoth/pull/4070/commits/061edc2bb300a6c810992a7c0a1e21c9c3f93e39 20190611 12:48:43<+wesdiscordbot> (ignore the last line of that commit message) 20190611 12:48:51<+wesdiscordbot> Neat, I was right. 20190611 12:48:58<+wesdiscordbot> ๐Ÿ‘ 20190611 12:49:35<+wesdiscordbot> But I'm still questioning why you'd set bloodred as good and happy green as bad. ๐Ÿ˜… 20190611 12:50:04<+wesdiscordbot> If there was 90% that you'd hit more and you won, then you played well. So: green 20190611 12:50:23<+wesdiscordbot> Green means the RNG was not on your side 20190611 12:50:23<+wesdiscordbot> Who said I won? 20190611 12:50:49<+wesdiscordbot> It's just an example. 20190611 12:51:05<+wesdiscordbot> But yeah. When you lose... 20190611 12:51:09<+wesdiscordbot> But you are basing the color scheme on it. D: 20190611 12:51:33<+wesdiscordbot> We can reverse the color scheme 20190611 12:51:49<+wesdiscordbot> Hooray. :D 20190611 12:52:22<+wesdiscordbot> But note that it's not as simple as "> average == green" 20190611 12:52:37<+wesdiscordbot> Taken and Inflicted are colored in opposite senses 20190611 12:53:03<+wesdiscordbot> 90,10 in inflicted in red, but 90,10 in taken is green 20190611 12:53:33<+wesdiscordbot> I assumed as much. It just means that both associate green with bad luck and red with good luck. 20190611 12:53:55<+wesdiscordbot> Yes 20190611 12:54:51<+wesdiscordbot> You might also want to consider my other idea about coloring the numbers to indicate average luck vs good/bad luck. ^^ 20190611 12:55:20<+wesdiscordbot> I tried that before, actually 20190611 12:55:27<+wesdiscordbot> It caused every line to have both a green and a red 20190611 12:55:35<+wesdiscordbot> 90,10 would be 90 in red and 10 in green 20190611 12:56:00<+wesdiscordbot> I switched from that to the current scheme... 20190611 12:56:29<+wesdiscordbot> (and I'm still open to reversing the current scheme to "good luck = green", if that's more natural) 20190611 12:56:41<+wesdiscordbot> I think it would be more natural, too. 20190611 12:57:10< Soliton> my expectation was the other way around as well. 20190611 12:57:43< Soliton> i like the statement you're making but i'm afraid it's not intuitive. :-) 20190611 12:59:52< Soliton> so i guess there is no simple way to re-calculate the percentages if i'd know the total amount of attacks? 20190611 13:00:04<+wesdiscordbot> - str2 << font::span_color(game_config::red_to_green((more_is_better ? probability : 1.0 - probability) * 100.0, true)) + str2 << font::span_color(game_config::red_to_green((!more_is_better ? probability : 1.0 - probability) * 100.0, true)) 20190611 13:00:07<+wesdiscordbot> That should do it 20190611 13:00:07<+wesdiscordbot> Hm. Can you color the % according to their difference? 20190611 13:00:22<+wesdiscordbot> Soliton, recalculate what ? 20190611 13:00:45< Soliton> the percentages 20190611 13:00:49<+wesdiscordbot> @Konrad2 That would be easy to implement 20190611 13:01:08<+wesdiscordbot> Soliton, and what do you assume you know? 20190611 13:01:11< Soliton> i guess you'd need to know the defense values of each battle. 20190611 13:01:14<+wesdiscordbot> The percentages are just the weighted average of all strikes 20190611 13:01:16<+wesdiscordbot> weighted by cth 20190611 13:01:18<+wesdiscordbot> Well, that would do exactly what I suggested. 20190611 13:01:36< Soliton> yeah, can't easily display that info, ok. 20190611 13:02:01<+wesdiscordbot> Because if the (absolute of the) difference is small, then they are near equal. And the reverse is true as well. 20190611 13:02:15<+wesdiscordbot> Soliton, the original idea was to show a histogram of hit/miss ratio by CTH 20190611 13:02:36<+wesdiscordbot> I'm not saying that you should implement it, just that you could probably implement it that way. 20190611 13:02:42<+wesdiscordbot> @Konrad2 You're right about the arithmetic but would that be a good UI? 20190611 13:02:57<+wesdiscordbot> Would that way of coloring be better ? 20190611 13:03:17< Soliton> i would use a different color scheme to show magnitude of deviation. 20190611 13:03:32< Soliton> like some neutral color if the deviation is small. 20190611 13:03:42<+wesdiscordbot> do you mean standard deviation? 20190611 13:03:47<+wesdiscordbot> Or the difference, like Konrad2 is sayign? 20190611 13:03:59< Soliton> just what Konrad2 was talking about. 20190611 13:04:00<+wesdiscordbot> That depends on whether the player wants to know at first glance whether he was (un)lucky or if the priority is how much the outcome was based on luck. 20190611 13:04:29<+wesdiscordbot> Maybe I'll just start a forum thread inviting more ideas 20190611 13:05:06<+wesdiscordbot> By the way, Soliton, you can actually load old savefiles and view their hitstats 20190611 13:05:14<+wesdiscordbot> I'm looking at all those players complaining about their luck. 20190611 13:05:18< Soliton> i think putting more emphasis on how big the difference is from the expected sounds interesting. 20190611 13:05:21<+wesdiscordbot> Just the "Inflicted" ones (top left cell of bottom table), though, for old savefiles 20190611 13:05:48<+wesdiscordbot> I think both are interesting. They just fill different niches. 20190611 13:06:10<+wesdiscordbot> @Konrad2 Mathematically, the difference is the a priori probability of the actual result 20190611 13:06:31<+wesdiscordbot> For example, if you hit 3/2.8, then the difference is the a priori probability of 3 hits 20190611 13:06:48<+wesdiscordbot> which is 10.3% 20190611 13:07:06<+wesdiscordbot> but why is that number important? 20190611 13:07:35<+wesdiscordbot> When you view the statistics of a campaign, asking about how likely it was to have 1745 hits (as in my screenshot) isn't very interesting, is it? 20190611 13:07:48<+wesdiscordbot> That's not significantly different from 1744 or 1746 hits 20190611 13:08:18< Soliton> @josteph surely you could re-calculate both from the replay? :-P but that's nice indeed. 20190611 13:08:37<+wesdiscordbot> Soliton, I can, and if you play the replay to the end, that's exactly what happens 20190611 13:08:51<+wesdiscordbot> Soliton, but when you load the replay, up front it only shows the one I mentioned 20190611 13:09:11< Soliton> good, good. 20190611 13:14:27<+wesdiscordbot> The difference between 100% and (1st % + 2nd %) would be the a priori probability, no? 20190611 13:14:50<+wesdiscordbot> Instead of 1st % - 2nd %. 20190611 13:15:05<+wesdiscordbot> But my number was indeed wrong. 20190611 13:15:32<+wesdiscordbot> ...or was it. I need another moment to think. 20190611 13:16:32<+wesdiscordbot> Sorry, yes 20190611 13:16:39<+wesdiscordbot> 100% - left - right is the a priori of actual result 20190611 13:16:39<+wesdiscordbot> but 20190611 13:16:44<+wesdiscordbot> imagine the probabilities are 20190611 13:16:47<+wesdiscordbot> I think it's actually right. If the actual dmg is the same as the expected dmg, then you'd have your 0,5 Quantil. 20190611 13:16:52<+wesdiscordbot> 1%, 98%, 1% (less, exactly, actual) 20190611 13:16:57<+wesdiscordbot> compare that to 20190611 13:17:01<+wesdiscordbot> 49%, 2%, 49% 20190611 13:17:07<+wesdiscordbot> you would have both of them colored the same 20190611 13:17:21<+wesdiscordbot> Sounds right. 20190611 13:17:25<+wesdiscordbot> not to me ๐Ÿ˜ƒ 20190611 13:17:34<+wesdiscordbot> in the first case, the actual result was a priori likely 20190611 13:17:40<+wesdiscordbot> in the second case, it was a priori unlikely 20190611 13:17:55<+wesdiscordbot> In both cases it was a priori the most likely. 20190611 13:18:04<+wesdiscordbot> in 49,2,49 it wasn't 20190611 13:18:32<+wesdiscordbot> Right, my bad. 20190611 13:19:21<+wesdiscordbot> I need to write this down. Maybe it will help. 20190611 13:19:50<+wesdiscordbot> Sure. 20190611 13:21:37<+wesdiscordbot> It just occured to me that I'm not convinced that your second example can actually occur. 20190611 13:21:49<+wesdiscordbot> Or, happen. xD 20190611 13:21:49<+wesdiscordbot> @Konrad2 Can you describe in English (not math) what you'd like the coloring algorithm to be ? 20190611 13:23:10<+wesdiscordbot> I'll try to formulate that. But please do tell/prove to me that the 2nd example can actually happen. ...maybe leveling up can make it happen..? 20190611 13:23:29<+wesdiscordbot> leveling up has nothing to do with this 20190611 13:23:34<+wesdiscordbot> it just counts hits and misses 20190611 13:23:37<+wesdiscordbot> Right. 20190611 13:23:45<+wesdiscordbot> I just ran into that as well. xD 20190611 13:24:02<+wesdiscordbot> Still. Provide an example for your example. :D 20190611 13:25:31<+wesdiscordbot> I want the color to be green (or neutral something) when the actual result is very close or equal to the expected result. I want it to shift towards red the further those two results are apart. 20190611 13:26:31<+wesdiscordbot> And I believe 49, 2, 49 can only happen if 2% is the actual result, while 49% is the chance for a smaller/greater number of hits. 20190611 13:26:51<+wesdiscordbot> that's what I meant 20190611 13:27:10<+wesdiscordbot> a,b,c means a% of getting less than actual, b% of getting actual, c% of getting more than actual 20190611 13:27:16<+wesdiscordbot> obviously b!=0 always 20190611 13:28:51<+wesdiscordbot> So why do you think that the 2% wouldn't be at least as likely as any other single result? 20190611 13:29:41<+wesdiscordbot> 49% is a sum of probabilities of other results, not the probability of a single result itself. 20190611 13:30:37<+wesdiscordbot> Wesnoth statistics seems to be based on 'normal' GauรŸ curves, without any inverted ones. 20190611 13:30:50<+wesdiscordbot> Or rather that's what is stuck in my mind. 20190611 13:31:29<+wesdiscordbot> for any single battle, yes 20190611 13:31:47<+wesdiscordbot> but the question is, when you sum up many battles, can you approximate an inverted curve 20190611 13:31:51<+wesdiscordbot> a bathtub curve 20190611 13:31:57<+wesdiscordbot> Well. No. 20190611 13:32:04<+wesdiscordbot> Law of strong numbers, right? 20190611 13:32:20<+wesdiscordbot> You approximate a normal curve instead. 20190611 13:32:36<+wesdiscordbot> but you're adding up different distributions 20190611 13:32:42<+wesdiscordbot> (Gesetz der starken Zahlen). I'm only guessing the translation. 20190611 13:32:47<+wesdiscordbot> Hm... 20190611 13:32:50<+wesdiscordbot> https://en.wikipedia.org/wiki/Law_of_large_numbers#Strong_law 20190611 13:33:07<+wesdiscordbot> If you take say a binomial distribution B(N,p) and increase N, that approximates a bell 20190611 13:33:29<+wesdiscordbot> but if you add B(N,p) and B(N',p') and B(N'',p'') and so on, what do you get ? 20190611 13:33:35<+wesdiscordbot> (other than a headache) 20190611 13:36:04<+wesdiscordbot> https://en.m.wikipedia.org/wiki/Central_limit_theorem 20190611 13:36:15<+wesdiscordbot> That's what I was looking for. 20190611 13:36:24<+wesdiscordbot> yeah 20190611 13:36:27<+wesdiscordbot> >>> p = 0.8; q = 0.2 >>> pq, p(1-q)+(1-p)q, (1-p)(1-q) (0.16000000000000003, 0.6800000000000002, 0.15999999999999998) 20190611 13:36:44<+wesdiscordbot> That's the example you asked for, one of them 20190611 13:36:59<+wesdiscordbot> if you do one strike at 80% cth and one strike at 0.2% cth, then the probabilities are 16/68/16 20190611 13:38:37<+wesdiscordbot> I don't have yet an example where both tails are heavy 20190611 13:38:53<+wesdiscordbot> You won't get one. 20190611 13:39:15<+wesdiscordbot> To answer your question (with help from google and wikipedia), you get this: 20190611 13:39:18<+wesdiscordbot> https://en.m.wikipedia.org/wiki/Poisson_binomial_distribution 20190611 13:39:44<+wesdiscordbot> yeah, I found that one 20190611 13:40:19<+wesdiscordbot> Where does it say that it can't have two heavy tails? 20190611 13:40:25<+wesdiscordbot> Though I still need to check whether it actually says what I think it does. xd 20190611 13:40:31<+wesdiscordbot> Just a second. D: 20190611 13:40:59<+wesdiscordbot> @Konrad2 I can get 0/1/0 and 0.25/0.5/0.25 with that example, though 20190611 13:41:14<+wesdiscordbot> for lower/exactly/higher 20190611 13:41:31<+wesdiscordbot> that's not as extreme as I hoped for but it's still something, isn't it ? 20190611 13:47:46<+wesdiscordbot> Well. No. Because that's covered by the first example. 20190611 13:48:29<+wesdiscordbot> It's not really different from the 16/68/16 one either. 20190611 13:51:17<+wesdiscordbot> Yeah, the middle one is a priori most likely 20190611 13:51:30<+wesdiscordbot> Hmm, wait 20190611 13:51:37<+wesdiscordbot> To get the middle one small, you just need a ton of hits, don't you? 20190611 13:51:45<+wesdiscordbot> Like, a 1x100 50% attack 20190611 13:51:51<+wesdiscordbot> But I found on the wikipedia entry that it can be approximated by a normal distribution. (https://de.m.wikipedia.org/wiki/Verallgemeinerte_Binomialverteilung directly above 'Beispiele'), so no two heavy tails for you?) 20190611 13:52:27<+wesdiscordbot> Huh. Hm. 20190611 13:52:57<+wesdiscordbot> it'll still be a bell, but the bell will be 'flat' 20190611 13:52:58<+wesdiscordbot> Yeah, but the middle one would still have the greatest probability. 20190611 13:53:11<+wesdiscordbot> yeah, it would be the most likely single outcome 20190611 13:53:59<+wesdiscordbot> Bringing me back to: So why do you think that the 2% wouldn't be at least as likely as any other single result? 49% is a sum of probabilities of other results, not the probability of a single result itself. 20190611 13:54:01<+wesdiscordbot> it'll be 46/8/46 20190611 13:54:12<+wesdiscordbot> in the case of 1x100 50% and you got 50 hits 20190611 13:54:40<+wesdiscordbot> We do agree it's still a gauรŸ curve, right? 20190611 13:54:48<+wesdiscordbot> I assume it is 20190611 13:54:57<+wesdiscordbot> And that means that 50 hits is the most likely outcome 20190611 13:54:58<+wesdiscordbot> So those 8% are our most likely number. 20190611 13:55:11<+wesdiscordbot> *biggest probability for a number 20190611 13:55:24<+wesdiscordbot> Yeah 20190611 13:55:32<+wesdiscordbot> So this being green is just what we want. 20190611 13:55:43<+wesdiscordbot> Why? 20190611 13:55:46<+wesdiscordbot> There's 8% to get 50, sure 20190611 13:56:01<+wesdiscordbot> wait... 20190611 13:56:21<+wesdiscordbot> but there's 18% to get >=55 or <=45 20190611 13:56:23<+wesdiscordbot> each 20190611 13:56:33<+wesdiscordbot> 18% to get >=55, 18% to get <=45 20190611 13:56:34<+wesdiscordbot> In both cases it was a priori the most likely. in 49,2,49 it wasn't 20190611 13:57:02<+wesdiscordbot> yes, the middle of the bell is the most likely single outcome 20190611 13:57:06<+wesdiscordbot> Your 18% is for what exact number of hits? 20190611 13:57:10<+wesdiscordbot> but the tail as a whole is much more likely than the middle 20190611 13:57:21<+wesdiscordbot> 18.4% of getting >=55 hits out of 100 at 50% cth 20190611 13:57:28<+wesdiscordbot> But we don't care about as a whole. 20190611 13:57:32<+wesdiscordbot> why? 20190611 13:57:42<+wesdiscordbot> Let me quote more stuff. 20190611 13:57:47<+wesdiscordbot> Just a second. :D 20190611 13:57:55<+wesdiscordbot> you brought up the normal approximation 20190611 13:58:01<+wesdiscordbot> the normal distribution is continuous, not discrete 20190611 13:58:15<+wesdiscordbot> in continuous distributions asking about a range is the only question you can ask 20190611 13:58:31<+wesdiscordbot> I brought it up as an approximation. 20190611 13:59:19<+wesdiscordbot> To show that, if you have two equally heavy tails, then your result will be at least as likely as any other result. 20190611 13:59:41<+wesdiscordbot> that's true for the normal distribution, yes 20190611 14:00:07<+wesdiscordbot> You were disputing that said result would always be at least as likely as any other result. 20190611 14:00:20<+wesdiscordbot> No 20190611 14:00:21<+wesdiscordbot> ...right? 20190611 14:00:23<+wesdiscordbot> Wait a second, please 20190611 14:00:24<+wesdiscordbot> Mehta. 20190611 14:00:26<+wesdiscordbot> *meh. 20190611 14:00:39<+wesdiscordbot> In the normal distribution, the center is the most likely single result 20190611 14:00:50<+wesdiscordbot> If I said otherwise, I was wrong and I apologize for the mistake 20190611 14:00:54<+wesdiscordbot> But what I meant to say was 20190611 14:01:10<+wesdiscordbot> that the tails can be heavier than the one result in the middle 20190611 14:01:24<+wesdiscordbot> Sure. They can be. 20190611 14:01:46<+wesdiscordbot> But what does that actually matter? ๐Ÿ˜… 20190611 14:01:49<+wesdiscordbot> as I said at one point - when you do "All Scenarios" stats for a campaign, you don't care if you got 1744 hits or 1745 hits 20190611 14:02:06<+wesdiscordbot> what we have is a histogram 20190611 14:02:21<+wesdiscordbot> we have to reduce it to one or to numbers for the user 20190611 14:02:47<+wesdiscordbot> so I don't think looking at one value is the right approach 20190611 14:03:07<+wesdiscordbot> one of the reasons for showing "probability of <" and "probability of >" is that those are probabilities of a range 20190611 14:03:14<+wesdiscordbot> and with large number of hits, that's meaningful 20190611 14:04:28<+wesdiscordbot> We started with: You have two examples. 1, 98, 1 49, 2, 49 I said that in both cases the middle number was a priori the most likely result. Which you disputed and which spiralled into this. ๐Ÿ˜… 20190611 14:05:24<+wesdiscordbot> Can we get back to designing the stats dialog please ? 20190611 14:05:33<+wesdiscordbot> Yeah sure. 20190611 14:05:41<+wesdiscordbot> I already said, I think there was a misunderstanding, and if I spoke nonsense then I beg forgiveness 20190611 14:05:53<+wesdiscordbot> You said, "I want the color to be green (or neutral something) when the actual result is very close or equal to the expected result. I want it to shift towards red the further those two results are apart." 20190611 14:06:10<+wesdiscordbot> You meant that as an alternative to "red to green" = "the RNG favored the player"? 20190611 14:06:15<+wesdiscordbot> Yes. 20190611 14:07:01<+wesdiscordbot> As in RNG favoured someone vs RNG favoured noone 20190611 14:07:13<+wesdiscordbot> Interesting 20190611 14:07:52<+wesdiscordbot> Let's see then ... 20190611 14:08:04<+wesdiscordbot> And the way I wanted to achieve this, was to color it green if the actual result was a priori the most likely result, which would result in equally heavy tails. 20190611 14:08:11<+wesdiscordbot> Can we start with the 50 out of 100 at 50% example again ? 20190611 14:08:18<+wesdiscordbot> Sure. 20190611 14:08:50<+wesdiscordbot> Here's some more data 20190611 14:09:04<+wesdiscordbot> 45.7% to get <=39 hits out of 100 at 60% 20190611 14:09:14<+wesdiscordbot> 46.2% to get >=61 hits out of 100 at 60% 20190611 14:09:38<+wesdiscordbot> I assume 60 hits is the most probable outcome, but note the tails aren't equal 20190611 14:10:01<+wesdiscordbot> Because of 101 possible results. 20190611 14:10:18<+wesdiscordbot> ? 20190611 14:10:24<+wesdiscordbot> 0-100 20190611 14:10:25<+wesdiscordbot> No, they're unequal because 0.6 != 50% 20190611 14:10:30<+wesdiscordbot> Yes, I see how it's 101 results 20190611 14:10:35<+wesdiscordbot> I don't understand why that explains the asymmetry 20190611 14:10:49<+wesdiscordbot> I was bring dumb. D: 20190611 14:10:52<+wesdiscordbot> *being 20190611 14:11:24<+wesdiscordbot> let me give you {TRAIT_INGELLIGENT} then ๐Ÿ˜ƒ 20190611 14:11:49<+wesdiscordbot> Neat. 20190611 14:12:14<+wesdiscordbot> So, anyway 20190611 14:12:18<+wesdiscordbot> 50 hits out of 100 at 50% 20190611 14:12:25<+wesdiscordbot> what's the algorithm that ends up making this green? 20190611 14:13:17<+wesdiscordbot> I was suggesting the absolute difference between the tails. 0 = green 20190611 14:14:15<+wesdiscordbot> Okay, but this won't color the most likely single outcome in green. 20190611 14:14:24<+wesdiscordbot> In the 60 example, the difference will be nonzero 20190611 14:14:49<+wesdiscordbot> The difference is 0.5% there, it's the closest to zero you can get in that distribution, I think 20190611 14:15:21<+wesdiscordbot> so the most likely outcome will be closer to green than any other outcome, but not exactly green. 20190611 14:21:03<+wesdiscordbot> Short question. How did you get your 40% something numbers? 20190611 14:21:48<+wesdiscordbot> I have a script that computes that 20190611 14:21:56<+wesdiscordbot> I'm getting 0.00002 for <= 39 hits out of 100. 20190611 14:22:12<+wesdiscordbot> So I'm really wondering what I'm doing wrong. 20190611 14:22:50<+wesdiscordbot> change 39 to 3, 100 to 4, and look at the damage calculations histogram in-game 20190611 14:22:53<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/588010259201785867/JPEG_20190611_162243.jpg 20190611 14:22:55<+wesdiscordbot> does your code give the right answer in that case ? 20190611 14:23:24<+wesdiscordbot> 0.8704 20190611 14:23:30<+wesdiscordbot> you're computing the probability of <39 hits at 60% 20190611 14:23:46<+wesdiscordbot> Ahhhh 20190611 14:23:48<+wesdiscordbot> I see 20190611 14:23:52<+wesdiscordbot> I meant to write 59 20190611 14:23:53<+wesdiscordbot> not 39 20190611 14:24:37<+wesdiscordbot> the tails are <=59 and >=61 20190611 14:24:44<+wesdiscordbot> Now it makes sense. 20190611 14:25:15<+wesdiscordbot> So. Yeah. It won't color it in green, but it will color it almost in green. 20190611 14:25:45<+wesdiscordbot> Because green would be the rare case of the most likely case being a number that can actually happen. 20190611 14:25:53<+wesdiscordbot> Sorry about the typo 20190611 14:26:16<+wesdiscordbot> It often being at most almost green is for me not a bad thing, but a good thing. 20190611 14:26:56<+wesdiscordbot> If you really want it to be green at some point, I'll remind you that your color scheme can't do that either. 20190611 14:28:01<+wesdiscordbot> And my bad for saying that the most expected result should be green. I meant it should be the greenest of all of them. ^^ 20190611 14:30:47<+wesdiscordbot> It's a good idea 20190611 14:31:00<+wesdiscordbot> I'm not sure if it's my favorite, though 20190611 14:31:14<+wesdiscordbot> I kinda like "deep green" or "deep red" instantly communicating whether you were or weren't lucky 20190611 14:31:41<+wesdiscordbot> as opposed to "It's red. Hmm. That means I was either very lucky or very unlucky, but I'll have to read more carefully to determine which" 20190611 14:55:07< Soliton> yeah, that's what i meant with using a different color scheme for the difference magnitude. 20190611 14:55:34< Soliton> to not confuse the two schemes and perhaps combine them. 20190611 14:56:26< Soliton> i think it needs to be explained in the tooltip either way though unlikely to be intuitive. 20190611 15:06:05-!- irker096 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190611 15:06:05< irker096> wesnoth/wesnoth:master jostephd e27ddf7535 Merge pull request #4070 from jostephd/h AppVeyor: All builds passed 20190611 15:08:56<+wesdiscordbot> Soliton, @Konrad2 The implementation is really easy, maybe try it on some actual replays? http://sprunge.us/Nvb222 20190611 15:29:24<+wesdiscordbot> While I understand the appeal of using game_config::red_to_green, it has yellow in the center, representing the neutral outcomes. Wouldn't deep-redโ†’light-redโ†’greyโ†’light-greenโ†’deep-green be better here? 20190611 15:31:01<+wesdiscordbot> this might be an opportunity to get the color logic out of game_config and generalize it 20190611 15:35:13< Soliton> @josteph that patch doesn't change any colors does it? 20190611 15:36:42-!- travis-ci [~travis-ci@ec2-52-91-29-212.compute-1.amazonaws.com] has joined #wesnoth-dev 20190611 15:36:42< travis-ci> wesnoth/wesnoth#21693 (master - aa90147 : Reuben Rakete): The build has errored. 20190611 15:36:42< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/544265930 20190611 15:36:42-!- travis-ci [~travis-ci@ec2-52-91-29-212.compute-1.amazonaws.com] has left #wesnoth-dev [] 20190611 15:41:10< irker096> wesnoth/wesnoth:master Reuben Rakete aa901478c2 Fix crash when adding/removing hotkeys w AppVeyor: vs2017/Release Failed 20190611 15:41:11< irker096> Details: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/25199895 20190611 15:54:09-!- travis-ci [~travis-ci@ec2-54-144-113-185.compute-1.amazonaws.com] has joined #wesnoth-dev 20190611 15:54:09< travis-ci> wesnoth/wesnoth#21694 (1.14 - 78589ba : Reuben Rakete): The build has errored. 20190611 15:54:09< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/544266220 20190611 15:54:09-!- travis-ci [~travis-ci@ec2-54-144-113-185.compute-1.amazonaws.com] has left #wesnoth-dev [] 20190611 16:02:36<+wesdiscordbot> @ai I'm no good at picking colors. If someone writes a red_to_green_through_grey I can use it. 20190611 16:02:59<+wesdiscordbot> Soliton, it doesn't change color values. It changes the algorithm for deciding which color to use. 20190611 16:03:33<+wesdiscordbot> The travis failure looks like a false positive, different jobs failed, both due to timeout 20190611 16:03:36<+wesdiscordbot> Well, that an be done afterwards. No real reason to hold up this PR over it. 20190611 16:03:44<+wesdiscordbot> Good, because I've merged it ๐Ÿ˜ƒ 20190611 16:04:30< Soliton> looks to me like it changes the value that is displayed. 20190611 16:04:45<+wesdiscordbot> yeah, I didn't mean to do that 20190611 16:20:49<+wesdiscordbot> and I found a probably-bug in red_to_green 20190611 16:20:53<+wesdiscordbot> http://sprunge.us/RKC6wY fixed patch 20190611 16:21:14<+wesdiscordbot> that is, the last color of the range is only picked if the value is exactly 100 20190611 16:21:33<+wesdiscordbot> yeah 20190611 16:22:15<+wesdiscordbot> values >100 would also choose the last color 20190611 16:22:21<+wesdiscordbot> if you have 6 colors, you get ranges [0,19], [20,39], [40,59], [60,79], [80,99] and [100,100] 20190611 16:22:32<+wesdiscordbot> because it's clamped, true 20190611 16:22:43<+wesdiscordbot> but the same goes for numbers < 0 20190611 16:22:44<+wesdiscordbot> yeah, integer division rounds down 20190611 16:22:56<+wesdiscordbot> I wonder if this is something we want to fix 20190611 16:23:34<+wesdiscordbot> I think whatever we do, should be symmetric for 0 and 100 20190611 16:23:42<+wesdiscordbot> if 0,19 is a bucket, then 81,100 should be a bucket 20190611 16:24:09 * Soliton agrees 20190611 16:25:09<+wesdiscordbot> this bug has been around at least since 2009, when this function was created 20190611 16:26:47<+wesdiscordbot> okay, then this will become a multiple-part patch (possibly not in this order): 1) fix bucket sizes 2) factor out function from red_to_green and blue_to_white 3) add new scale 4) add optional color interpolation in addition to indexing 20190611 16:29:29< Soliton> to get back to this screenshot https://cdn.discordapp.com/attachments/259976436490829825/587970581060780032/2019-06-11-112448_422x185_scrot.png the first percentage there means that on average there was a 93% chance to get a worse attack (a miss?) than the player got? in a game with 1745 hits (even more attacks) while 1703 were expected? 20190611 16:30:36< Soliton> that seems crazy, i must be misunderstanding something. 20190611 16:32:15<+wesdiscordbot> it's a campaign 20190611 16:32:24<+wesdiscordbot> the "All Scenarios" view after beating WoV 20190611 16:32:38<+wesdiscordbot> it says was 93.4% of getting 1744 or fewer hits 20190611 16:33:07<+wesdiscordbot> yes, 1703.2 hits were expected 20190611 16:37:06<+wesdiscordbot> Is this a correct interpretation? : 93.4% of the 'bell curve' is to the left of or under this point. 6.1% is to the right of or under this point. So -0.5% is directly under it, or there are some serious rounding issues. 20190611 16:37:40<+wesdiscordbot> or you know strictly to the left, strictly to the right, and 0.5% directly under 20190611 16:40:06<+wesdiscordbot> 93.4 + 6.1 < 100 20190611 16:40:12<+wesdiscordbot> Looks right to me 20190611 16:40:28< Soliton> so 2% more hits than expected and that somehow means 93% chance to get less hits. 20190611 16:41:03<+wesdiscordbot> well, yes? 20190611 16:41:05< Soliton> seems difficult to get any meaning from that. 20190611 16:41:15<+wesdiscordbot> take the example I gave Konrad earlier 20190611 16:41:36<+wesdiscordbot> if you have a 1x100 attack at 50% CTH, there's 18% that it'll score >=55 hits 20190611 16:42:05<+wesdiscordbot> that means there's about a 60% chance of being between 46 and 54 20190611 16:42:12< Soliton> >= 55 is 5% off not 2%. 20190611 16:42:32<+wesdiscordbot> 10% 20190611 16:42:56<+wesdiscordbot> I'm trying to say that the distribution is not very even 20190611 16:43:23<+wesdiscordbot> Also, that screenshot - I had to manually edit some savefiles to get it 20190611 16:43:34< Soliton> 5 more hits than expected based on 100 in total. 20190611 16:43:43<+wesdiscordbot> It's a screenshot of a playthrough I started without the patch 20190611 16:44:04<+wesdiscordbot> you said 2%, 2% is 1745/1703.2 20190611 16:44:12<+wesdiscordbot> so I did 55/50 20190611 16:44:36<+wesdiscordbot> anyway, we agree 55 is further away from 50 than 1745 from 1703 20190611 16:44:57< Soliton> true, i don't know the total number from your screenshot. 20190611 16:45:58<+wesdiscordbot> it's WoV, so probably 1703/0.6, assuming most of the attacks were against enemies on 40% defense 20190611 16:46:42< Soliton> so no idea how i should imagine the distribution looks to have any kind of idea what that means for the luck involved in that game. 20190611 16:47:15< Soliton> the numbers seem crazy at least. 20190611 16:47:21<+wesdiscordbot> yeah, it's hard to get a sense of a distribution from just two numbers 20190611 16:47:23-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 248 seconds] 20190611 16:47:29<+wesdiscordbot> why don't you try it yourself? 20190611 16:47:47<+wesdiscordbot> build master and load a savegame or replay of a late scenario in any campaign 20190611 16:48:02<+wesdiscordbot> like I said, the "inflicted" code works on old savefiles 20190611 16:48:53< Soliton> i don't really see how that helps me understand those numbers but i can't run wesnoth here anyway. 20190611 16:49:31<+wesdiscordbot> there's a chance that my playthrough just happened to be an extreme one 20190611 16:50:36<+wesdiscordbot> or that I made an error in retrofitting the hitrate_map_entry data into my replay files by hand 20190611 17:03:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190611 17:17:33< Soliton> had you gotten 1703.2 hits then both percentages would have to be near 50%, right? 20190611 17:18:53< Soliton> or they don't as much need to be near 50% but they should have quite similar values. 20190611 17:19:25< Soliton> though for that many hits also likely near 50%. 20190611 17:22:21< Soliton> if we assume ~50% then the hits from 1703 to 1745 account for ~43%. that feels like a lot at least. 20190611 17:22:50< Soliton> must be quite the spike in the center of that histogram. 20190611 17:23:36< Soliton> not sure what it means though. not much variance expected in most attacks? 20190611 17:30:23<+wesdiscordbot> Discussing the same topic on the forums. I am asking @josteph to remove the two percentage values for hit stats (probability of hit less / probability of hit more) in favor of the same approach as for damage stats (actual/expected - 1) * 100% Link to my first comment of the discussion https://forums.wesnoth.org/viewtopic.php?p=643330#p643328 20190611 17:31:29<+wesdiscordbot> My arguments - hits stats is hard to understand for an average player, UX is inconsistent comparing to the damage stats. 20190611 17:35:42<+wesdiscordbot> Soliton, the expected value doesn't have to be the median, but for 60% for example it's quite close. In 100 strikes at 60%, there's 8% of getting 60 hits exactly and the two tails are almost equal, 45.7 and 46.2 20190611 17:36:53<+wesdiscordbot> Soliton, again, I don't think we should draw too many conclusions from this one playthrough. Maybe the code is correct and that just happened to be one of the 7% of playthroughs that give a result of 93% 20190611 17:38:41< Soliton> i don't care so much about that specific example as about what the numbers mean and are able to tell me. 20190611 17:40:20< Soliton> if they don't mean or tell me much perhaps they shouldn't be displayed. especially since we seem to all agree they're difficult to understand. 20190611 17:42:43<+wesdiscordbot> I don't know if we all agree about that 20190611 17:43:03<+wesdiscordbot> Sergey says they're difficult but he hasn't replied when I told him there's a tooltip that explains them 20190611 17:43:22<+wesdiscordbot> Also, I kinda wish that if it's a bad idea, someone would have said something before I spent time ironing out all the bugs 20190611 17:43:44<+wesdiscordbot> Anyway, what do you propose to do? Remove the hits table, or change it, or what? 20190611 17:44:52< Soliton> oh, i'm not trying to bash your feature. it's quite nice expect for those percentage values which are not the main part anyway, right? 20190611 17:44:59< Soliton> except* 20190611 17:45:59< Soliton> well, i was trying to understand the meaning so far to get to a point where it would be possible for me to suggest improvements if possible. 20190611 17:46:17< Soliton> reading the code cleared it up now, i think. 20190611 17:47:38< Soliton> (btw, i found the word "simulating" in the code comment confusing since i assumed it means attack simulation like the monte carlo variant we have) 20190611 17:48:11<+wesdiscordbot> I didn't read it as bashing, don't worry ๐Ÿ˜ƒ 20190611 17:48:16<+wesdiscordbot> Glad you understand it 20190611 17:49:57<+wesdiscordbot> how to clarify the comment ? 20190611 17:50:27< Soliton> if we don't agree that the percentages are difficult to understand then i'd like to say in case it wasn't clear from my questions that the tooltip didn't help much. :-P 20190611 17:51:14<+wesdiscordbot> ok, noted 20190611 17:51:27<+wesdiscordbot> but before I think of fixing it, let's first agree if those percentages are what we want to show or not 20190611 17:54:59< Soliton> well, i can't play around with other replays atm so no idea if you can get much from them in other games. 20190611 17:55:49< Soliton> if no one can say what to make of the numbers generally then i wouldn't show them or at least not in that form. 20190611 17:56:44< Soliton> if it only becomes meaningful if we show more of the histogram then i'd rather think about how to do that. 20190611 17:57:38< Soliton> i think you wanted to show the histogram at first? what was the issue if so? too little space? 20190611 17:57:54<+wesdiscordbot> https://cdn.discordapp.com/attachments/259976436490829825/588064376314134549/2019-06-11-175739_333x155_scrot.png 20190611 17:58:03<+wesdiscordbot> Here's another example 20190611 17:58:18<+wesdiscordbot> This is from the All Scenarios view of some replay from the forums 20190611 17:58:29<+wesdiscordbot> What do you make of this? 20190611 17:58:43<+wesdiscordbot> The idea on the forums was to show the histogram 20190611 17:59:09<+wesdiscordbot> I did just these stats because I thought it'd be easier and suffice 20190611 18:00:28< Soliton> well, that is exactly the question: what to make of this? what does it tell me? 20190611 18:01:06< Soliton> the percentages seem to suggest that was quite the unlikely game? but was it really? 20190611 18:02:13<+wesdiscordbot> why would it be unlikely? 20190611 18:02:47< Soliton> since 20% and 78% are fairly far apart. 20190611 18:03:42<+wesdiscordbot> The probability of this particular outcome is 100 - 20.5 - 77.8 which is small, yes 20190611 18:03:47<+wesdiscordbot> but look at it another way. 20190611 18:03:58< Soliton> that's not what i meant. 20190611 18:03:59<+wesdiscordbot> One-fifth of the distribution is below you 20190611 18:04:04<+wesdiscordbot> Four-fifths above you 20190611 18:04:10<+wesdiscordbot> that's roughly "in the middle" 20190611 18:04:33< Soliton> that is not what i would call roughly in the middle is exactly my point. 20190611 18:04:52< Soliton> if that's what it tells you maybe that's exactly right. 20190611 18:05:26< Soliton> if you can explain that to other people it'd be useful. 20190611 18:05:56< Soliton> though not particularly insightful either way? 20190611 18:07:06< Soliton> like if a range of 1/5 to 4/5 is normal when comes abnormal when does it tell me anything interesting? 20190611 18:07:13<+wesdiscordbot> seeing 20% there isn't that unlikely 20190611 18:07:28<+wesdiscordbot> assuming the code is correct, the probability of being below the 20% percentile or above the 80% percentile is 40% 20190611 18:08:00<+wesdiscordbot> well, I also downloaded another replay in which the play had 100% in the "below" stat 20190611 18:08:09<+wesdiscordbot> hits 2300 / 2200 20190611 18:08:33<+wesdiscordbot> 100%, 0.0% 20190611 18:08:36< Soliton> there might be an error there. :-P 20190611 18:09:45< Soliton> wait, what is the 2200? expected or overall? 20190611 18:10:23<+wesdiscordbot> 2300 actual, 2200 expected 20190611 18:10:25< Soliton> s/overall/total/ 20190611 18:10:28<+wesdiscordbot> the code starts here https://github.com/wesnoth/wesnoth/blob/aa901478c22be3dc0c32cdcf4c4807f19af2f428/src/statistics.cpp#L210-L236 20190611 18:10:43<+wesdiscordbot> I checked it when I wrote it... 20190611 18:11:29< Soliton> ok, the / is confusing but i guess we have to live with that. 20190611 18:11:52<+wesdiscordbot> I could change it if someone has a better idea. 20190611 18:12:10<+wesdiscordbot> There is a review at the top of 4070 with some idaes. 20190611 18:14:20< Soliton> well, why put anything between these values? just make a column for expected and for actual hits? 20190611 18:14:51<+wesdiscordbot> Could do that, of course. 20190611 18:14:58<+wesdiscordbot> The dialog will be wider because of the column headers. 20190611 18:17:38<+wesdiscordbot> "Sergey says they're difficult but he hasn't replied when I told him there's a tooltip that explains them" Tolltip helped to understand the numbers. But it is still hard to translate those numbers to some measure of luck. And that is what players expect from the stats I believe. "Also, I kinda wish that if it's a bad idea, someone would have said something before I spent time ironing out all the bugs" Sorry for not 20190611 18:17:38<+wesdiscordbot> reading it before. To be honest that topic on the forums was very hard to understand, a lot of math. Recently one of the players said that he don't understand the numbers. When I saw the tooltip and the screenshot it was much easier to understand what is going on here and provide some feedback. 20190611 18:18:03<+wesdiscordbot> Even you chat with @Konrad2 here was a hard reading. 20190611 18:19:29<+wesdiscordbot> My chat with Konrad got into some areas of probability that both he and I studied outside wesnoth 20190611 18:19:50<+wesdiscordbot> The central limit theorem, for example. I don't expect everyone in the channel to know what that is 20190611 18:20:02<+wesdiscordbot> (Everyone isn't a mathematician) 20190611 18:20:19<+wesdiscordbot> As to understanding the numbers, do you know what a median is ? 20190611 18:20:45<+wesdiscordbot> yes 20190611 18:21:19<+wesdiscordbot> The percentages tell you what quantile you are at 20190611 18:21:43<+wesdiscordbot> If the percentages say 46% and 46% (approximately equal), then you're at the median 20190611 18:21:52<+wesdiscordbot> if they say 20% 80%, then you're at the 20% quantile 20190611 18:22:03<+wesdiscordbot> with respect to number of hits, not hitpoints 20190611 18:23:07<+wesdiscordbot> I understand that. Do you agree that it is a way to hard to understand for an average player? 20190611 18:23:52<+wesdiscordbot> The dialog already shows the expected value of hitpoints dealt 20190611 18:24:29<+wesdiscordbot> I am talking about percentages. 20190611 18:24:40< Soliton> even if people can understand it (which i agree is unlikely) afaict nobody mentioned any useful conclusions from those percentages so far. 20190611 18:25:03<+wesdiscordbot> Forget about all your mates that like math. Think about an average guy. 20190611 18:25:40<+wesdiscordbot> Soliton, why does the damage stats table exist? The hits stats tries to answer the same question in a different way 20190611 18:26:02< Soliton> yes. 20190611 18:26:13<+wesdiscordbot> @sergey I understand that. I think understanding quantiles isn't harder than understanding the hitpoints table that's already there, which uses expectations 20190611 18:26:39< Soliton> so what do the percentages add? 20190611 18:26:44<+wesdiscordbot> 20%, 80% means "there was 20% that it would have ended up worse" 20190611 18:27:24<+wesdiscordbot> Soliton, they add up the probability of getting 0, 1, 2, ..., N-1 hits 20190611 18:27:29<+wesdiscordbot> where N is the number to the left of the /. 20190611 18:27:56<+wesdiscordbot> that's probability_lt in statistics_dialog.cpp 20190611 18:28:00< Soliton> yes, i understand now what they mean but that doesn't answer the question. 20190611 18:28:25<+wesdiscordbot> Ah, you meant what value they add to the user ? 20190611 18:28:32< Soliton> yes. 20190611 18:28:59<+wesdiscordbot> The damage stats is there to give a sense of the effect of the RNG 20190611 18:29:10<+wesdiscordbot> The hitstats are there for exactly the same reason 20190611 18:29:22<+wesdiscordbot> Look at the last few posts in the thread, sergey and I posted examples that show when the two stats differ 20190611 18:29:44< Soliton> as i said the addition of the hitstats is cool and helps flesh out the stats dialog a bit more but these percentages don't seem to add much more. 20190611 18:30:08<+wesdiscordbot> so you're saying to keep the actual/expected but remove the percentages ? 20190611 18:30:56<+wesdiscordbot> @josteph the percentage in the damage stats shows how much more / less percent of damage I deal comparing to expected. "there was 20% that it would have ended up worse" doesn't say how much worse. 20190611 18:30:59< Soliton> yes, from the beginning i've only asked about the percentages and was only talking about them. 20190611 18:31:54<+wesdiscordbot> "how much more / less percent of damage I deal comparing to expected" is important for the player. "there was 20% that it would have ended up worse" is not important, because it doesn't say how much worse. 20190611 18:32:00<+wesdiscordbot> Soliton Understood. Could you open an issue or something? I'd like to get some more feedback, also about what we could do instead 20190611 18:32:41<+wesdiscordbot> @sergey The percentage shown by the damage dialog can be derived from the other values. 20190611 18:32:59<+wesdiscordbot> Like in the 3/2.8 screenshot, if you actually divide 3 by 2.8 you'll get that number 20190611 18:33:31<+wesdiscordbot> yes, that is a user friendly form of showing the values 20190611 18:33:35<+wesdiscordbot> "how much worse" is the cumulative probability of any worse result, between 0 and N-1 20190611 18:33:45<+wesdiscordbot> if you have a better idea for how to present that when N=1745 do share it. 20190611 18:34:03<+wesdiscordbot> that's the number of hits in my WoV playthrough 20190611 18:34:18<+wesdiscordbot> @sergey I already answered that on the forum 20190611 18:34:28<+wesdiscordbot> 3/2.8 is not interesting because it'll always be around zero 20190611 18:34:38<+wesdiscordbot> I said it earlier. (actual_hits / expected_hits - 1) * 100% 20190611 18:34:44<+wesdiscordbot> yes, it can be derived 20190611 18:34:56<+wesdiscordbot> yes, (actual/expected-1)*100% will be +1% or -1% 20190611 18:35:06<+wesdiscordbot> because actual/expected is almost equal to 1 20190611 18:35:09<+wesdiscordbot> on the long run 20190611 18:35:12< Soliton> that is a good point. i think what most people expect when they see a percentage (especially if there is some X / Y before that) is that the computer has just done the math for them to compute the percentage of X and Y in some form. 20190611 18:35:15<+wesdiscordbot> yes 20190611 18:35:40<+wesdiscordbot> Soliton, then we can change the / to something else 20190611 18:36:24< Soliton> or change the percentage to exactly that, the same way it is on the damage stats. 20190611 18:36:43<+wesdiscordbot> like I said, I don't think that would be useful 20190611 18:36:53<+wesdiscordbot> the percentage will almost always be around zero 20190611 18:36:53< Soliton> i can see you would like to add more info instead of showing redundancy. 20190611 18:36:58<+wesdiscordbot> if it's always the same value, there's no reason to show it 20190611 18:37:16< Soliton> but for that we need useful values that mean something. 20190611 18:37:33<+wesdiscordbot> even if we do remove the quantiles, I'm not convinced we should add the quotient instead 20190611 18:37:38< Soliton> you can say the same thing about the damage stats? 20190611 18:37:43<+wesdiscordbot> yes 20190611 18:37:47<+wesdiscordbot> see my last post on the thread ๐Ÿ˜ƒ 20190611 18:38:13<+wesdiscordbot> sorry, the one before last 20190611 18:38:28<+wesdiscordbot> last sentence of it. 20190611 18:39:47<+wesdiscordbot> "if it's always the same value, there's no reason to show it" on the long run almost the same. but what about a single scenario? 20190611 18:40:13< Soliton> well, i don't necessarily disagree but it's what we have so far which should perhaps not be dismissed too lightly. 20190611 18:41:06< Soliton> and i think it's fairly common as i said to show percentages just as another form of the same info generally. 20190611 18:41:23<+wesdiscordbot> also keep in mind consistency of the damage / hit tables. it would be confusing to show different things there. 20190611 18:41:27-!- irker096 [~irker@wesnoth/umc-dev/bot/shikadibot] has quit [Quit: transmission timeout] 20190611 18:41:54<+wesdiscordbot> Would this tooltip be better? (_"stats dialog^Quantiles. The first percentage is the a priori probability of scoring fewer than 1745 hits. The second percentage is the a priori probability of scoring more than 1745 hits.") 20190611 18:42:27<+wesdiscordbot> @sergey So how about adding column headers to the percentages column. 20190611 18:42:35<+wesdiscordbot> The header would be "Ratio" in the damage table and "Quantiles" in the hits table 20190611 18:43:04<+wesdiscordbot> Actually most of the players would have to google "a priori" and think some time what does that mean in that particular context. 20190611 18:43:25< Soliton> i'm sure people will google quantile as well. 20190611 18:43:41< Soliton> with more success though perhaps. 20190611 18:44:37<+wesdiscordbot> Soliton, the very next sentence explains what quantiles are... 20190611 18:44:40<+wesdiscordbot> in the proposed tooltip 20190611 18:45:12< Soliton> so why say quantiles then? 20190611 18:45:16<+wesdiscordbot> Maybe create a poll or something on the forums? Because if I will tell you my own experience that may dissapoint you. 20190611 18:45:47<+wesdiscordbot> If you have a better idea I'm al lears. 20190611 18:45:58< Soliton> anyhow i think that is already much better. 20190611 18:47:07< Soliton> if you were asking me then the implication would be to just remove the "Quantiles." part. 20190611 18:47:40<+wesdiscordbot> OK 20190611 18:47:46<+wesdiscordbot> So I have a math background and I like a read instructions before trying to push all the buttons. But I noticed that damage stat page only after years of playing. I didn't get if from the beginning. Not sure if there is a tooltip or not, I googled what it is and found an answer on the forums. And recently I explained what it means to other guy who played about 5 years or something. 20190611 18:48:18<+wesdiscordbot> And that is just expected damage and ratio. 20190611 18:48:41<+wesdiscordbot> Not saying about quantiles and "a priori". 20190611 18:48:44<+wesdiscordbot> Yeah, I did the same a while back 20190611 18:49:02<+wesdiscordbot> To figure out what the divisor was 20190611 18:49:17< Soliton> (honestly i'm also not sure what the "a priori" adds. i don't mind using proper math terms if that is the idea but i'm afraid it doesn't help the understanding of the average person much.) 20190611 18:50:11<+wesdiscordbot> (I can remove that too) 20190611 18:55:08<+wesdiscordbot> Created the issue https://github.com/wesnoth/wesnoth/issues/4113 20190611 18:55:33<+wesdiscordbot> If I forgot any requests please add them there. @Konrad2 (and everyone else) 20190611 18:55:39<+wesdiscordbot> @josteph once again sorry for not providing a feedback earlier. I really believe that most people don't like math and don't like to read instructions. They like simple and intuitive interfaces. 20190611 18:59:26<+wesdiscordbot> like "ok, show me how lucky I was" 20190611 18:59:38<+wesdiscordbot> +10%? sounds good 20190611 19:00:13<+wesdiscordbot> green 30% red 20% ... what? 20190611 19:00:42<+wesdiscordbot> I agree with you about people liking simple interfaces 20190611 19:01:09<+wesdiscordbot> but there is a tradeoff between showing too little information and showing too much information - 20190611 19:01:36<+wesdiscordbot> https://github.com/endless-sky/endless-sky/issues/4106#issuecomment-451141572 20190611 19:01:43<+wesdiscordbot> as to green 30 red 20 20190611 19:01:50<+wesdiscordbot> that's not gonna happen except in the most trivial of cases 20190611 19:02:00<+wesdiscordbot> that happened after one battle 20190611 19:02:07<+wesdiscordbot> so the probability of the actual result was 40% 20190611 19:02:19<+wesdiscordbot> usually it's something like 1% so both percentages are the same color 20190611 19:02:25<+wesdiscordbot> look at the other screenshots I posted 20190611 19:05:40< Soliton> IMO the percentages as they are now are too little info. if we want more perhaps start with showing the complete histogram. 20190611 19:06:23<+wesdiscordbot> under the spoiler "detailed statistics"? 20190611 19:07:26<+wesdiscordbot> Soliton, how do you show an histogram for the "All Scenarios" case? 1745 actual hits means >3000 strikes 20190611 19:08:05<+wesdiscordbot> assuming cth on the order of 40% or 60% 20190611 19:08:11< Soliton> a histogram over the possible chance-to-hit i was thinking. 20190611 19:08:33<+wesdiscordbot> how would that work? 20190611 19:08:42<+wesdiscordbot> for each cth value (30 to 80) you'd show... what ? 20190611 19:08:43< Soliton> haven't thought much about that though. 20190611 19:08:55< Soliton> the number of hits. 20190611 19:09:23<+wesdiscordbot> so the histogram would typically say something like 30%: 30%, 40%: 40%, 50%: 50% ? 20190611 19:09:40<+wesdiscordbot> it'll be approximately linear 20190611 19:10:00< Soliton> the number of hits is not a percentage. 20190611 19:10:29<+wesdiscordbot> I assumed you'd also show the number of strikes, otherwise the number of hits doesn't mean anything 20190611 19:12:19< Soliton> not sure what you're asking or getting at. 20190611 19:12:38<+wesdiscordbot> imagine the dialog didn't show 1745/1703.2, but simply 1745 and nothing else 20190611 19:12:49<+wesdiscordbot> that wouldn't convey anything 20190611 19:13:04< Soliton> i think the total number of strikes could be useful certainly. 20190611 19:13:37<+wesdiscordbot> so you want to show the number of hits at each cth, and the total number of strikes? 20190611 19:14:51< Soliton> not sure if you're talking about the histogram or what. i think the total number of strikes could be an additional column in the current dialog. 20190611 19:15:09< Soliton> not related to the histogram. 20190611 19:15:36<+wesdiscordbot> I'm trying to understand what you're proposing. 20190611 19:15:53<+wesdiscordbot> OK on the total number of strikes, good idea. 20190611 19:16:55<+wesdiscordbot> About a histogram - I'd like to understand what you propose exactly, but broadly speaking, what I like about showing the quantiles is that they are just one figure, really (p and 100%-p) so it's not hard to interpret them. 20190611 19:17:58<+wesdiscordbot> Like, in that game that resulted in 100%,0%, the player was lucky. If it had been 0%,100%, the player would have been unlucky. This much should be clear even to people without doctorates in math 20190611 19:19:09< Soliton> 2300 actual hits and 2200 expected also told the same though, no? 20190611 19:20:53<+wesdiscordbot> qualitatively, yes 20190611 19:21:21<+wesdiscordbot> Remember that getting 60/100 at 50% is much rarer than people think intuitively it ought to be 20190611 19:21:52<+wesdiscordbot> (the probability for exactly 60 hits is ||1.1%||. For >=60 hits it's ||2.8%||) 20190611 19:22:45< Soliton> with a histogram based on cth you could see the distribution of your attacks based on terrain perhaps or what units you attacked anyway. not sure how useful that is as i said i haven't thouhgt about it much. 20190611 19:23:35< Soliton> it's not necessarily something to judge luck but another statistic of the game. 20190611 19:23:42<+wesdiscordbot> Soliton, I think the first priority should be to see what's already there and make sure it's releaseable 20190611 19:23:52<+wesdiscordbot> Adding new things has its place but I'd say it's lower priority 20190611 19:24:02< Soliton> certainly. 20190611 19:24:09<+wesdiscordbot> For example, I really don't want to do the red-to-green reversal in a patch release ๐Ÿ˜ƒ 20190611 19:24:25<+wesdiscordbot> Any further feedback you may have will be welcome 20190611 19:24:49<+wesdiscordbot> Feel free to put it here or github or on the forums, I'll find it 20190611 19:25:40< Soliton> my point so far is just that the percentages as they are now are difficult to understand and don't say too much additionally. the improved tooltip helps though. 20190611 19:25:51<+wesdiscordbot> Thanks for the feedback, Soliton, @sergey @Konrad2 @ai (and sorry if I forgot anyone) 20190611 19:26:20< Soliton> and perhaps more important is the possible confusion much less so that the values are perhaps not that interesting all the time. 20190611 19:26:43<+wesdiscordbot> I think the quantiles do add value. 20190611 19:26:51<+wesdiscordbot> Regarding confusion, that problem is inherited from the damage table. 20190611 19:27:11<+wesdiscordbot> We could suppress the stats until there's enough data but I am not sure that would be a good idea 20190611 19:27:21< Soliton> well, then i would at least make it clear that those values are quite different from the damage table. 20190611 19:27:25<+wesdiscordbot> As @sergey said interfaces should be simple, and this sort of hidden activation condition can backfire 20190611 19:27:53<+wesdiscordbot> It may be better to have the table show data always and let the player figure out that at the beginning of the scenario stats aren't yet interesting 20190611 19:28:14<+wesdiscordbot> Yeah, that's what the header idea on the percentages column is for 20190611 19:28:27< Soliton> yes, that's good. 20190611 19:28:34<+wesdiscordbot> https://github.com/wesnoth/wesnoth/issues/4113 third point 20190611 19:38:20<+wesdiscordbot> @jyrkive feedback addressed 20190611 19:39:52<+wesdiscordbot> All right, looks good now. ๐Ÿ‘ 20190611 19:59:57<+wesdiscordbot> I used braceless style as I that was what was deleted in an earlier commit. 20190611 20:00:26<+wesdiscordbot> Using braces is the preferred code style in Wesnoth though. 20190611 20:02:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection] 20190611 20:02:43-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20190611 20:02:57<+wesdiscordbot> I know. It was just a misguided attempt to make the change "smaller" 20190611 20:06:24-!- APic [apic@apic.name] has joined #wesnoth-dev 20190611 20:41:17-!- irker157 [~irker@wesnoth/umc-dev/bot/shikadibot] has joined #wesnoth-dev 20190611 20:41:17< irker157> wesnoth/wesnoth:master Reuben Rakete aa901478c2 Fix crash when adding/removing hotkeys w AppVeyor: 1/4 builds failed 20190611 20:41:17< irker157> Details vs2017/Release: https://ci.appveyor.com/project/wesnoth/wesnoth-605wt/builds/25199895 20190611 21:21:35-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 258 seconds] 20190611 21:29:28-!- boucman_work [~boucman@wesnoth/developer/boucman] has joined #wesnoth-dev 20190611 21:54:08-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has quit [Ping timeout: 248 seconds] 20190611 21:55:44-!- Rhonda [~rhonda@wesnoth/developer/rhonda] has joined #wesnoth-dev 20190611 22:58:58-!- boucman_work [~boucman@wesnoth/developer/boucman] has quit [Ping timeout: 258 seconds] 20190611 23:34:02< irker157> wesnoth/wesnoth:1.14 Reuben Rakete 78589ba311 Fix crash when adding/removing hotkeys w AppVeyor: All builds passed --- Log closed Wed Jun 12 00:00:45 2019