I am working with the CartPole-v1 environment and I am trying to change some of the model parameters (such as force_mag) in order to test the robustness of my algorithms w.r.t model variations. I am trying to do so with the following code:
env = gym.make('myCartPole-v1)
env.force_mag = -10.0 # nominal is +10.0
but I do not see any change in the model behavior, while testing it with my learnt policy (which should fail/worsen, but it does not). Nothing happens when changing other parameters (e.g.
masscart, length...). Am I missing something? What is the best way to produce local changes to the models?
The problem was solved by creating an instance of the environment and by calling env.unwrapped. The code in the example should look like: env = gym.make('myCartPole-v1).unwrapped
Related
I am using BertJapaneseTokenizer for an NLP project.
I am running into the error "The unidic_lite dictionary is not installed". On checking under the hood it looks from one of the elif conditions that this error will be thrown only if the variable mecab_dic is set = "unidic_lite" (please see this link https://huggingface.co/transformers/v4.11.3/_modules/transformers/models/bert_japanese/tokenization_bert_japanese.html)
Furthermore, due to some unavoidable constraints I cannot install unidic_lite module (let's just assume this is a constraint I have). However, I can install unidic. So my question is -- is there a way to do a manual override like mecab_dic = "unidic" such that elif statement for unidic_lite is bypassed altogether?
(relatedly, we can see from the constructor of MecabTokenizer that mecab_dic should have default value as "ipadic", then why is it set as mecab_dic set = 'unidic_lite' anyway!?)
Any suggestion would be super helpful. Thanks!
(P.S: I am not super tech-savvy so this was attempt at a crude workaround)
What I tried: downloaded the tokenization_bert_japanese.py code to my local machine and created a static variable mecab_dic = "unidic" in it and tried to import BertJapanesTokenizer from this customized python script instead of the standard "from transformers import BertJapaneseTokenzier"
On 2021-10-13 in our application in Azure ML platform we get this new error that causes failures in pipeline steps - python module import failures - warning stack <- warning that leads to pipeline runtime error
we needed to set it to false. Why is it failing? What exactly are exact (and long term) consequences when opting out? Also, Azure ML users - do you think it was rolled out appropriately?
Try to add into your envirnoment new variable like this:
environment.environment_variables = {"AZUREML_COMPUTE_USE_COMMON_RUNTIME":"false"}
Long term (throughout 2022), AzureML will be fully migrating to the new Common Runtime on AmlCompute. Short term, this change is a large undertaking, and we're on the lookout for tricky functionality of the old Compute Runtime we're not yet handling correctly.
One small note on disabling Common Runtime, it can be more efficient (avoids an Environment rebuild) to add the environment variable directly to the RunConfig:
run_config.environment_variables["AZUREML_COMPUTE_USE_COMMON_RUNTIME"] = "false"
We'd like to get more details about the import failures, so we can fix the regression. Are you setting the PYTHONPATH environment variable to make your custom scripts importable? If so, this is something we're aware isn't working as expected and are looking to fix it within the next two weeks.
We identified the issue and have rolled out a hotfix on our end addressing the issue. There are two problems that could've caused the import issue. One is that we are overwriting the PYTHONPATH environment variable. The second is that we are not adding the python script's containing directory to python's module search path if the containing directory is not the current working directory.
It would be great if you can please try again without setting the AZUREML_COMPUTE_USE_COMMON_RUNTIME environment variable and see if the problem is still there. If it is, please reply to either Lucas's thread or mine with a minimal repro or description of where the module you are trying to import is located at in relation to the script being run and the root of the snapshot (which is the current working directory).
I am new to ML and W&B, and I am trying to use W&B to do a hyperparameter sweep. I created a few sweeps and when I run them I get a bunch of new runs in my project (as I would expect):
Image: New runs being created
However, all of the new runs say "no metrics logged yet" (Image) and are instead all of their metrics are going into one run (the one with the green dot in the photo above). This makes it not useable, of course, since all the metrics and images and graph data for many different runs are all being crammed into one run.
Is there anyone that has some experience in W&B? I feel like this is an issue that should be relatively straightforward to solve - like something in the W&B config that I need to change.
Any help would be appreciated. I didn't give too many details because I am hoping this is relatively straightforward, but if there are any specific questions I'd be happy to provide more info. The basics:
Using Google Colab for training
Project is a PyTorch-YOLOv3 object detection model that is based on this: https://github.com/ultralytics/yolov3
Thanks! 😊
Update: I think I figured it out.
I was using the train.py code from the repository I linked in the question, and part of that code specifies the id of the run (used for resuming).
I removed the part where it specifies the ID, and it is now working :)
Old code:
wandb_run = wandb.init(config=opt, resume="allow",
project='YOLOv3' if opt.project == 'runs/train' else Path(opt.project).stem,
name=save_dir.stem,
id=ckpt.get('wandb_id') if 'ckpt' in locals() else None)
New code:
wandb_run = wandb.init(config=opt, resume="allow",
project='YOLOv3' if opt.project == 'runs/train' else Path(opt.project).stem,
name=save_dir.stem)
The default cache directory is lack of disk capacity, I need change the configure of the default cache directory.
You can specify the cache directory everytime you load a model with .from_pretrained by the setting the parameter cache_dir. You can define a default location by exporting an environment variable TRANSFORMERS_CACHE everytime before you use (i.e. before importing it!) the library).
Example for python:
import os
os.environ['TRANSFORMERS_CACHE'] = '/blabla/cache/'
Example for bash:
export TRANSFORMERS_CACHE=/blabla/cache/
As #cronoik mentioned, alternative to modify the cache path in the terminal, you can modify the cache directory directly in your code. I will just provide you with the actual code if you are having any difficulty looking it up on HuggingFace:
tokenizer = AutoTokenizer.from_pretrained("roberta-base", cache_dir="new_cache_dir/")
model = AutoModelForMaskedLM.from_pretrained("roberta-base", cache_dir="new_cache_dir/")
I'm writing this answer because there are other Hugging Face cache directories that also eat space in the home directory besides the model cache and the previous answers and comments did not make this clear.
The Transformers documentation describes how the default cache directory is determined:
Cache setup
Pretrained models are downloaded and locally cached at: ~/.cache/huggingface/transformers/. This is the default directory given by the shell environment variable TRANSFORMERS_CACHE. On Windows, the default directory is given by C:\Users\username.cache\huggingface\transformers. You can change the shell environment variables shown below - in order of priority - to specify a different cache directory:
Shell environment variable (default): TRANSFORMERS_CACHE.
Shell environment variable: HF_HOME + transformers/.
Shell environment variable: XDG_CACHE_HOME + /huggingface/transformers.
What this piece of documentation doesn't explicitly mention is that HF_HOME defaults to $XDG_CACHE_HOME/huggingface and is used for other huggingface caches, e.g. the datasets cache, which is separate from the transformers cache. The value of XDG_CACHE_HOME is machine dependent, but usually it is $HOME/.cache (and HF defaults to this value if XDG_CACHE_HOME is not set) - thus the usual default $HOME/.cache/huggingface
So you probably will want to set the HF_HOME environment variable (and possibly set a symlink to catch cases where the environment variable is not set).
export HF_HOME=/path/to/cache/directory
This environment variable is also respected by Hugging Face datasets library, although the documentation does not explicitly state this.
part question. First, how do I configure the size of a branch predictor?
I can see that I can set the type using the se.py config script and the --bp-type argument. (In my case I'm setting it to LTAGE), but how do I change the size of the tables? And is there an easy way to see the total size of all tables?
My second part, is looking at the code, I don't understand the LTAGE constructor:
LTAGE::LTAGE(const LTAGEParams *params)
: TAGE(params), loopPredictor(params->loop_predictor)
{
}
The LTAGEParams doesn't appear to be defined anywhere except here:
LTAGE*
LTAGEParams::create()
{
return new LTAGE(this);
}
How can I see what all the members of LTAGEParams are?
About the size, have a look at m5out/config.ini after running a simulation, it contains all SimObject parameters.
In the case of branch predictors, all Python-visible parameters of each implemented predictor will be defined in its respective class declaration at src/cpu/pred/BranchPredictor.py. They also inherit the parameters of their base class. For example, LTAGE has all the parameters of the TAGE class - out of which the tage object is re-assigned to be an instance of LTAGE_TAGE - and a new parameter, loop_predictor, which is a LoopPredictor instance.
You can then just set any of the values in that file from your Python config and they will be used (double check in config.ini after re-running).
The C++ constructor of SimObjects takes a param object like LTAGEParams and that object is autogenerated from the corresponding Python SimObject file, and passes values from Python configs to C++ using pybind11.
gem5 has a lot of code generation, so whenever you can't find a definition, grep inside the build directory. This is also why I recommend setting up Eclipse inside the build directory: How to setup Eclipse IDE for gem5 development?
SimObject autogeneration is described further at: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-python-c-interaction