Wolfram Alpha’s New Data about Pokémon
blog.wolframalpha.com
blog.wolframalpha.com
https://www.wolframalpha.com/input/?i=linear+regression+of+h...
-- i'm dreaming
SELECT pokemon.name
FROM
pokemon
JOIN pokemon_learn_moves ON pokemon.id = pokemon_learn_moves.pokemon_id
JOIN move ON pokemon_learn_moves.move_id = move.id
WHERE
move.name_en = "Hydro Pump"
ORDER BY pokemon.sp_atk DESC LIMIT 1;
Ideally bulbapedia would provide mediawiki dumps for this, but they don't, and they've gone on record saying they don't intend to. They did leave the mediawiki API open though if you want to crawl a clean rip of each page's wikitext - the default mediawiki API guidelines are also intact, which say that single-threaded crawls should be acceptable in almost all instances, but you should warn the site owner before initiating a multi-threaded scrape.
You're doing a relational query: select, join, project. Translate it to a key-value store and you're going to end up with way more boilerplate. Using a key-value store for a relational query is like trying to use a screwdriver to drive a nail.
But assuming you have indexes `pokemon_learn_moves_by_move_id` and `moves_by_name`, you could write
pokemon_learn_moves_by_move_id[ moves_by_name["Hydro Pump"].id ]
.map( |id| [pokemon[id].sp_atk, pokemon[id].name] )
.greatest()[1];
[1]: http://veekun.com/dex [2]: https://github.com/veekun [3]: https://github.com/veekun/pokedex/tree/master/pokedex/data/c...
select(p.name for p in pokemon
if "Hydro Pump" in p.learn_moves.move.en_name
).order_by("p.sp_atk").first()Probably shouldn't be posting this. :P
Edit: According to http://pokemondb.net/type , when Grass is attacking Electric, the attack is "normal," 100% of the damage takes. However, when Electric is attacking Grass, the attack is "not very effective," and only 50% of the damage takes.
So Bulbasaur is totally going to win this.
Earth & Rock > Electric
Bulbasour its Grass though :p Electric is not very effective against Grass. /endOfPokemonNerdComment
I wonder what Wolfram has to say about this...
Pikachu's common passive ability 'Static' means that it can potentially inflict paralysis when hit with physical moves. On top of that, Bulbasaur has a fairly high Special Attack stat, so it'd be a good idea for it to use Special moves rather than Physical. On top of that Pokémon get a Same Type Attack Bonus (STAB) for using moves that match their type, so we want a non-physical Grass type move. 'Leaf Storm' is probably the best move we could use in this case. To get a Bulbasaur with that move, you have to do some breeding, but it's totally possible.
Now we'd also want to take advantage of Bulbasaur's own common ability, 'Overgrow', which boosts Grass type moves' effectiveness by 50% when it goes below 1/3 of its HP which, combined with our STAB means Grass type moves are now 200% as effective. Of course once we get our HP that low we're going to want to avoid taking much more damage. Using Bulbasaur's 'Sleep Powder' move at this point will cause Pikachu to fall asleep, preventing any further attacks.
So we've got our basic strategy, get down to 1/3 of our HP, put Pikachu to sleep and then wail on it with Leaf Storm. While we're letting our HP drop we could use something like 'Swords Dance' to boost our attack stat as well.
Bulbasaur would need Toxic/Sleep Powder, Growth, Energy Ball/Petal Dance/Giga Drain, and if you must, Hidden Power (Ground) with leftovers. Would NOT suggest using Leaf Storm unless you know you could knock out the opposing pokemon within two hits, even with the two stage lowering of the Special Attack. http://bulbapedia.bulbagarden.net/wiki/Bulbasaur_(Pok%C3%A9m...
The problem with your strategy is that it doesn't take into account crit attacks. Bulbasaur could get a critical hit on it and get all the way down to around 30% health left. The problem what that is that Bulbasaur is MUCH slower than Pikachu, so by the time that round is over, you don't have enough health to survive another neutral hit. The only way I could see Bulbasaur winning is with crit hits, or with just stalling out Pikachu (by changing growth to protect, hidden power ground to leech seed, and going with Giga Drain, you would have a really great chance to stall out Pikachu, if Pikachu doesn't 3HKO Bulbasaur), and hope he didn't have hidden power ice.
(If you're not using physical attacks, why waste a slot on Sword Dance, a move that increases the Physical attack stat??)
Now, let's say we gave Bulbasaur all the extra ev training into special attacking. It would still take about two hits to knock out Pikachu. Problem is, since Pikachu is faster, it'll get in two hits before Bulbasaur does. This is why both Pikachu and Bulbasaur are considered LC (Little Cup) or NU (Never Used), as they have a lot of problems dealing with a lot of different pokemons that occur in battling.
May I suggest you try a website called Pokemon Showdown? It's an online simulator which allows you to try out different strategies, and test them against other people. http://play.pokemonshowdown.com/
But what i really like, is to match stuff like protein in bananas vs spinach to know what i'm going to (prefer to) eat soon ^^..
So, thanks!
that said it's within grasp of many of us: natural language interfaces (NLI) and SPARQL databases and endpoints. have a look at this semanticweb q&a:
http://answers.semanticweb.com/questions/12747/natural-langu...
some good links in there. basically find your SPARQL endpoints, have a list of synonyms mapped between your inputs (which you parse with NLP tools like weka or the stanford parser, or even python's nltk) and map your query to your ontologie(s) from your endpoints. then try successive answers.
a good, simple interface to play around with that is quepy:
a few others exist.
hope that helps. despite challenges in the adoption rates of the semantic web, i think it's the future of information retrieval because it makes sense for us as users and truly organizes information.
The problem we've had with SPARQL and co is that we feel it isn't optimized for computational queries. Ontologies don't matter as much in that case, and inference in tuple stores costs you significantly in performance, although the technology is improving.
As often as not, however, the computationally irreducible work lies in making a domain suitable for computational consumption, not in the technology used for representation.
To analogize, UTF-8 is great, but without the notion of Unicode code points it wouldn't exist.
The computational complexity going on is minimal compared to the effort it takes to create and maintain the dataset. Accessing it with a formal query language is then straightforward.
The parlor trick is making the formal query language seem as informal and colloquial as possible. But fiddle with breaking it and you'll see you're just running searches on very specific and very specifically tagged data.
Edit: Having thought about it more, the reason it's 'underutilied' is that it's actually not that useful. Your knowledge of its dataset is more important than its ability to provide it for you--witness the person below who knew that it could provide nutrition information.
Your index on its information is better than its index, in other words.
-Vectorize the image into a set of bezier curves that have endpoints at intersections
-Walk the bezier curves so that the entire image can be represented by a single "strip" of piecewise bezier sections. If there's any overlapping sections from having to rewalk the a curve, maybe apply some offsets/small modifications to those curves to give it a "sketched" look.
-Rasterize the bezier curves in order at your desired resolution into a list of XY coordinates. Make sure the XY coordinates remain in order they were rasterized.
-Split the coordinates of each rasterized pixel so that you have two lists, (t, x) and (t, y), where t is the index of the rasterized pixel. Now you can represent the X and Y coordinates of your sketch on two coordinate planes as a function of t.
-For each coordinate plane X and Y, record the index where the second derivative of the rasterized graph changes. What this does is lets you distinguish subcurves on the line. For this to work it's probably important that the rasterization was done at a relatively high resolution.
-For each subcurve, generate an extremely low frequency trigonometric function that can represent that subcurve. Ideally outside of that subcurve, the trig function should be at or very near zero. This might require layering some additional trig functions in order to eliminate any noise.
-With the trig functions generated, return the results as a parametric function.
I should attempt it as a hobby sometime.
There is a lot of computing going on there, DPS (Damage Per Second) possibly modified by upgrades and enemy type, etc. This data could be genuinely useful to the SC community.
Expected result: 370 Result: 74