Sigh, I'll look at this again, but I'm so fed up with our arguments that my head hurts. That's why I took a long break.
> im pretty sure your wrong. [Estimating Thistleknot's function return value]
A miscalculation on my part? Let me see.
What about the other extreme, (CTI == 1) ? The correct return value is max. Sim3 returns max -1 or similar.
gap = (max - curr) * 500 / CTI
normalised_gap = 0.5 - 250 / CTI //
There was an error here and it propagated. normalised_gap = 0.5 / (0.5 + 250/CTI)
normalised_gap = 1 / (1 + 500/CTI)
add_value = (max - curr) * (500 / CTI) * 1 / (1 + 500/CTI)
For small CTI that's slightly below (max-curr)
mod_Att_Value is slightly below max.
Yes, I admit, that this edge value is correct.
> btw. we did a simple fix for values over or at max. we just returm current.
Good. Small things like this tend to lead to bugs. The code you provided also lacks things like capping cap at 5000, capping the CTI at 1, checking if current attribute value is positive. You know, the sanity checks.
> the problem with all this code, is we need to figure it out, because Splinterz is on the cusp of his next release, and you keep getting my formula wrong... dogging it and all is frustrating when your saying incorrect things about it.
Sigh. Well, yes, I admit, I should have spent some time playing around with it and making graphs. I just like it less than sim3 on principle; in my experience current value of attributes is what matters most.
> so it makes it harder for Splinterz to figure out what goes into v20.
Yeah, about that. I get into heated discussions with Thistleknot. I'm often right, but also sometimes wrong. There is some bad emotional fallout from that and it is counter-productive to make Dwarf Therapist better. Sorry about that, Splinterz.
> This all started because I want to feed the values back into the bins (which I now firmly believe can be done safely)
I seem to fail to make a thought leap here. On one side you have your bins that try to approximate attribute distribution and map it to probability of value this or smaller. On the other side there are methods to factor in current value of an attribute as well as it's max value and CTI. I fail to see how to connect them. I'm not saying there is no connections, just that I lack an epiphany here.
I think the "normal" values for CTI would be 100 to 2000, even for mods. 1 CTI or less is a really abnormal case. The 1/x function behaves nicely enough where x is within an order of magnitude from 1. In other words, you may be somewhat off from what a human would pick, but the order will be correct at least.
Looking at the code:
> In sim3: //default_cti could be a weighted average of all cti's.
Personally I'd leave it at 500, but as long as you're using the same value the same attribute for all castes, you should be good.
> if(att >= 5000) return 5000;
Well, for such stellar attributes there should probably be a bonus (for example to roles), but this is quite rare, even with modding in "Strength potions" and similar interactions. If values above 5000 would screw something up on a higher level, this is fine.
//att_sim is based on median possible gain, not sure if it should be based on average possible gain, or median possible gain, or max possible gain
Any of the above will work, but I really had "expected average gain for this attribute over a few years" in mind.
> However, you seem to be quite aloof to reading about things you have an understanding of.
I have some degree of mathematical intuition, but in this case the output of both functions looks similar. I should have made some graphs before bashing what you did.
It may be that I understand exactly what I did, but fail to see the logic behind what you did. To me it looks as if you fiddled with formulas at random and got something that worked.
> > BTW, in case you didn't notice this yourself, your graphs for sim3 had 2 intervals where they were linear: before the cap and after the cap.
> Link, please.
Well, there wasn't one. And come to think of it, this is untrue. If sim_gain after factoring in CTI won't cap, then you the function basically returns (curr + sim_gain /2). After it caps, the return value becomes ((cap-curr)*(curr + cap)/2 + (sim_gain -(cap-curr))*cap) / sim_gain, so as sim_gain increases, the return value changes at the speed of (1 + x)/x, which isn't linear.
> I don't want you thinking I'm hating on you, I'm just trying to figure this shit out. If we can't implement it without not knowing how it works, it's like magic to us.
I've already explained the trapezoid method. I guess to explain it again, I'd need a drawing. Here, I made one. Sim3 computes
the average value of an attribute as it trains by att_sim. To do that, you can make a loop that goes on for 2000 or so times or use a smart method. The field of trapezoid is h*(a + b)/2 (or you can think of it as a sum of arithmethic series: (b-a) * (a+b)/2, same thing really). The field of a rectangle is b*c. You add the fields under the graph (as if computing an integral), then divide it by att_sim to get the average value. The slope before capping is always 45 degrees and att_sim is the only thing that depends on CTI. To compute the average value of a function over some interval, you calculate the surface area between the "x" axis and the function graph, then divide that by the length of the interval. I don't think, I can put this in simpler terms.
> so I think we're hitting on the same things, maybe you can explain SUPER LAMEN terms how what I conjured compares with yours (I know you don't owe us that, but if you present it, then Splinterz will understand, and be that much better to make his decision on v20!).
Lol, the problem here is that I understand exactly how my method works, but your formulas look magic to me. Still, the output is pretty similar.
Since you were kind enough to provide me with some source code, I guess, I'll go ahead and make some graphs of my own. Yours are jumping all over the place. Man, I got rusty with gnuplot and Matlab. I guess, I'll just use Open Office Calc. I only made any meaningful changes to the main function to give it a loop changing either att or CTI and print the values to a csv.
The first graph was made by taking Starting Attribute for [450:950:1150:1250:1350:1550:2250], computing cap from that and using CTI of 500. Up to attribute value 1250 the cap is 1250 + att and after that it becomes 2*att. At that point the slope changes very little for sim3, while the change is greater for your function. For sim3 the current attribute value is much more important, while your function values the cap more.
For the second graph I kept the attribute value at 1250, the cap at 2500 and manipulated the CTI from 50 (ten times faster gain) to 2000 (four times slower gain). For fast attribute gain the cap is more important, while for slow gain the current attribute value wins and both functions got that right. It is just that sim3 looks much smoother and "prettier", while your has some kind of irregularity around 500 (where it it most important to get things right). In retrospect, maybe I should have used a logarithmic scale for CTI here.
All in all I still prefer sim3, but the difference is not as great as I expected and both methods will get the job done.
EDIT: > Just out of mild curiosity: What are you (maklak), thistleknot and to some extend, splinterz, trying to do with this? I saw long posts by all three of you for pages without end.
I think this is about a method for taking attribute values, then mapping them to <0, 100> for the purpose of factoring that into suggestions of roles for Dwarves. Not sure.
Author
Topic: Dwarf Therapist (LATEST 0.6.12 5/23/12 see first post) (Read 870379 times)