-
Notifications
You must be signed in to change notification settings - Fork 113
Glyph ID handling #21
Comments
This is OS dependent (mail daemon etc). We should really start doing a better featurization (cf. #21).
Hey @heiner, I'm changing the original agent implementation and I was thinking to use a different embedding representation. Is this issue still valid? I saw that the PyTorch people closed the issue on their side. |
The PyTorch issue has to do with the speed of embeddings and is more of an aside. This issue here describes the fact that glyph ids are not great for ML necessarily (e.g., over half of all glyph ids are of type "swallow", 99% of which will never show up in the actual game). We are experimenting with ways to preprocess these glyphs in our agent code. |
Thanks for clarifying this. So I assume this doesn't have an effect on the NeurIPS code release right? |
Is there a mapping between the glyph id and the monster name? It would help to featurize attributes of the monster |
Amazing - thank you! Is there a doc for whats exposed through the FFI? (Im guessing you alls are using pybind11) |
Not documentation per se but the actual source code shouldn't be too hard to read: https://github.com/facebookresearch/nle/blob/master/win/rl/pynethack.cc#L502 |
no - it isnt too hard to read! Thanks! |
Currently, each dungeon tile (ignoring the char/color/specials observation that's also available) is an int16 between
0
andnethack.MAX_GLYPH == 5976
. We use an embedding lookup table of that sizeembedding_dim == 32
. That's5976 * 32 == 191232
floating points, or191232 * 16 == 3059712
bits, or ~0.3MB. That doesn't seem too much but there's some issues with the embedding itself. Also, it does not give the agent a cue that certain ids (e.g., dog and large dog) are more related than others (large dog vs wall).The way these glyphs are organized is that first come all the monsters (
NUMMONS
many, which is 381), then pets (againNUMMONS
many because in theory every monster can be tame, then a single glyph for an invisible monster (GLYPH_INVIS_OFF
, which is 762), then a glyph for each "detected" monster (againNUMMONS
many). For some obscure reason, then there's corpses, which are not monsters (but there'sNUMMONS
many), and then there's ridden monsters, which are monsters (NUMMONS
many). The checkglyph_is_monster(glyph)
does this:This makes a list like
[i for i in range(nethack.MAX_GLYPH) if nethack.glyph_is_monster(i)]
have lengthnethack.NUMMONS*4 == 1524
, but it's not contiguous.Cf. https://github.com/fairinternal/NetHack/blob/rl/win/rl/helper.cc#L37 for a list of the offsets and take a look at the comment in https://github.com/fairinternal/NetHack/blob/rl/include/display.h#L235 explaining this.
After monsters there's
MAXPCHARS == 96
cmap
entries for dungeon features, then there's zap beams (NUM_ZAP << 2 == 8 << 2 == 32
many). Then there'sNUMMONS << 3 == 3048
(!) "swallow" glyphs. That's a lot for stuff that basically never happens to our agents. Then there'sWARNCOUNT == 6
warning glyphs and finallyNUMMONS
statue glyphs.As a graphic representation, the glyph ids are:
Where
More than half of all glyph ids are swallow!
We should rethink the featurization of the glyph ids.
The text was updated successfully, but these errors were encountered: