Mathematics Contributor
  • Content count

  • Joined

  • Last visited

About Gryphon_

  • Rank
    RIP Chair

Profile Information

  • Gender
  • Location
    Los Angeles
  • Server

Recent Profile Visitors

2,447 profile views
  1. Each core can run multiple threads, they just timeslice, especially as each thread in an app like this is almost always in waiting for data mode. But I hear you on the 20/sec limit on your account.
  2. Have you tried multi-threading it with each thread running its own token, taken from a list of known tokens? That could speed things up a bit
  3. There you go. Its not the red haired stepchild it used to be...
  4. If T71 can turn ME into a recent purple, it has to be good. Highly recommended.
  5. And there's more:
  6. Cant get that portal to return any results
  7. I suggest using the v31 table to allocate values that cant be calculated reliably. Better than a pluglist.. average_expected_values_v31.csv
  8. Version v31 is already taken, that's the consolidated table by type and tier, which wotlabs will adopt in next 24 hours. So please repost as v32 to avoid confusion. My comments: a) You need to add the missing tanks - especially AMX M4 mle. 49, A-32, and T-100 LT - to the pluglist, so that the values when published are complete. Then you have to be prepared to do this again every time they issue a new tank or change something. b) I dont support dropping the 50 battle filter and applying weights else the guy who played 18000 battles in his Maus distorts the regression towards his results. All that matters is how each player does on each tank compared to how each player did on all tanks (post filter) c) The changes that we are seeing in player WN8 from v29 (normal) to v30 (averaged) is minimal. For example, mine changed from 1630 to 1635. So it looks like the averages work well enough and require no further work. How would you justify the work involved (you and the other websites) in going back to the normal method? & Floor is open for community to comment on the values you published..
  9. A lot of these OP premium problems could be fixed by changing the ammo they use, and the ammo the non-prems use. After all, the premium tank doesn't come with the ammo so if you nerf the ammo no-one has actual standing to complain. Example: too many heavily armored premiums at tier 8? Increase the pen of the non-prems to level the field. Example: Defender has too much alpha? Reduce it to 'standard' 390. But I bet WG wouldn't like the video that explained that either.
  10. I've just watched his original video, and I think WG went pretty easy on him. He has valid points about this tank being another in a long series intended to force players to fire prem ammo, but if his intent was to make WG think again he went the wrong way about it.
  11. Yep. Tier 7 also seems to get top tier a lot - especially lights (T71)
  12. Well as Im sure you've noticed WN8 isnt retiring without a fuss, so the sooner a follow on is developed, the better. If you need any help with analysis I'd be happy to write scripts in R to do that if needed.
  13. The rare tanks are going to be less of a problem if you are pulling loads of data. We used data on 20k accounts from vbaddict for all the runs we did ,so if you have way more than that it should fill the gaps. Plots with less than 100 dots will be error prone. You might want to modify the script to 'pass' on calculating value corrections if there are less than 100 datapoints for the tank in the 'userTankStatsFiltered' dataframe. For future reference regarding WN9, note that each graph, in the title gives the intercept and slope of the line of best fit. So if you wanted to generate the 'scaling' values for WN9, you can see where the data comes from (but you have to run the plots AFTER applying the new expected values first). We used to assign values to some reward tanks and rare tanks using a pluglist where the community estimate an 'equivalent' tank for each , ie M60 = M48, and the script then read across those values from a pluglist before writing the results to a expected values file. Note: upkeep of the pluglist is a major PITA and that's one reason we went to averaged values. The list I posted would need a lot of work to figure out which tanks could be removed from it (enough data exists) and which need to be added. The code snippet to run a pluglist is here, and the last pluglist we used is attached. any( newExpectedValues <- newExpectedValues[,c("compDescr","eFRAG", "eDAMAGE", "eSPOT", "eDEF", "eWIN")] #make substitutions for rare tanks expectedValuesAdjusted <- expectedValues # newExpectedValues pluglist <- read.csv("~/R/WN8/pluglist.csv") for (t in pluglist$tank_id) { tank <- pluglist$tank_id[pluglist$tank_id == t] substitute <- pluglist$substitute_tankid[pluglist$tank_id == t] expectedValuesAdjusted[expectedValuesAdjusted$compDescr == tank,names(expectedValuesAdjusted) != "compDescr"] <- expectedValuesAdjusted[expectedValuesAdjusted$compDescr == substitute,names(expectedValuesAdjusted) != "compDescr"] } any( newExpectedValues <- expectedValuesAdjusted pluglist30.csv
  14. Has anyone tried some datamining to see if there are any hidden API calls? I find it hard to believe that assisted damage isnt exposed somehow.
  15. If anyone does figure out a way to automatically generate new WN8 per tank expected values its important they publish the values for other sites to use otherwise everyone will be using different values. Until that happens, the official values are v30/31. We are trying to start up WN9 development again, as that uses averaged expected values then adds per tank scaling factors. WN8 (averaged) and WN9 (per tank) is where we should go.