math logic bomb
I am working with random numbers, with the intent to attach them to a frame that moves. Never mind the code issues of moving the frame, I am struggling with the math. The average of all the numbers is what moves the pointer frame. So far so good.
The trouble is the end number has to be between 1 and 21, inclusive. Here is a hard-coded example. Lua Code:
Lua Code:
|
You can't have a mathematically correct average of a set of numbers if you're going to limit the average below the highest number of the set.
Why don't you limit your random numbers (e.g. random(21)) then divide the end result by the amount of numbers? |
The random numbers aren't generated from math.random. They are the average of all the mana deltas within x amount of time. For example, say you gain or lose the following amount of mana:
|
Is it a sliding window that always contains 21 datapoints?
(ie starts plotting when you have at least 21 datapoints and from that point on displays the last 21) |
If I understand you correctly, then yes, sort of. Think of the PvP capture bar, where it swings between Horde and Alliance. The vertical slider is my plot point, and moves the slider based on the mana returns. Obviously, a mana delta value measured in hundreds, or thousands, isn't any good; the graph would have to be huge, which is why I am making it 21 segments. The main frame behind has a width of 210, so breaking it up into 21 chunks makes setting a width of each segment easy.
That is why I am trying to figure out the math to convert the average deltas into somewhere on a 21 segment frame. I have the average, deltas, frame segments, all that built. It is just the math that converts I am having a challenge with. Does that make more sense? Oh, in fact, I AM using the PvP capture bar texture. |
Actually the math would be simple if I could understand what the bar represents.
I'm not sure you have decided that yet yourself :p I mean ok it's 21 segments, let's say 10 'negative' segments (losing mana) 1 'zero' segment (not losing or gaining), 10 'positive' segments (gaining mana) |----------|-|----------| What amount does the total width of the bar represent (splitting it in 21 segments aside, there must be something to divide to 21 parts) What is a meaningful number for the user to be at the left end of the bar (highest rate of losing mana) to the right end of the bar (highest rate of gaining mana)? Edit: What I posted above should get you an average MPS over 21 seconds if your deltas are 1/sec. There's no way to place -215 MPS (or +450 MPS) on a bar if you can't know what's the range of the bar, that's not a math problem it's a logic problem. Tell me what the full range of the bar corresponds to and I can help with the rest. |
You can't scale your sliding window average to your display range until you figure out what your display range is. What are the minimum and maximum values you intend to display? What will you do with values outside that range? Does the minimum = (-the maximum)?
Is the range fixed value? Is it determined by the values in the sliding window? Does it depend on values that have passed out of the sliding window? Once you have answered that, scaling the input value (the sliding window average) to an output value (an integer between -10 and +10, or equivalently 0 to 20, inclusive) is easy. |
Hrrmph... proof of concept.
Tried to think as a caster :p <<Center>> = "Rest" << Left = "How fast to OOM at current mana expenditure" (the more left the slider the faster we're going oom) Right >> = "How fast to mana-full at current mana-gain" (the more right, the faster we're gaining full mana) This makes it so we don't need a static MPS range, rather the user can set a "warning time" before the slider will start moving. In example code warning time = 30, 10 segments for each side, slider moves 1 notch at 30sec to OOM, another notch at 27sec to OOM and so on until full left at 3sec to OOM. Similar for right side with slider closer to center for slow mana-regen, further right for mana-tide/innervate etc. Code:
local frame = CreateFrame("Frame") |
Proof of concept is fun! :eek: Anyway, I thought I would post my code, before attempting to add Dridzt's modifications, just to see where I am at. The first pastebin is my entire code, complete with unnecessary, sometimes commented out parts. The second is pared down to include just the relevant stuff.
http://pastebin.com/A3w443DG -- full code. math breaks at line 476 http://pastebin.com/12RqSrk1 -- slimmed down. math breaks down at line 120 |
Quote:
Quote:
Quote:
|
ACM Slim modified
http://pastebin.com/fGJRa9Xg |
Thank you Dridzt. Will drop it in and see what happens. I have some other bugs that need squashing, and they are preventing the addon from working in the first place, but one way or the other, I will post back and let you know. :D:banana::cool:
|
Quote:
|
Quote:
The idea for ACM came from a guild healer that wanted to know how effective he was at conserving mana partway though a fight. He can see his current mana on his unit frame. "Am I actually conserving mana, and how effectively am I conserving it?" was his question. SDPhantom, if 1100 is too low, I can either hard code it up, or take Dridzt's suggestion and make it a user setting. |
Quote:
The first suggestion was rather extreme, but I have yet to see a better one for a static value. I was leaning more toward the dynamic "peak" value though, having the addon display out of the largest value it currently has come across (taking the absolute value of all deltas). Quote:
What lead to scrapping this idea was the complexity of all the abilities I would have to support that applies buffs/debuffs that increase damage dealt from you and other players or decreases the target's armor/resistance rating. This would be so the associated ability would get proper credit for its own efficiency rating. |
All times are GMT -6. The time now is 05:29 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI