I want to use Wordnet 1.6 with nltk for research purposes.
However the version I have is wordnet 3.0
wn.get_version()
u'3.0'
Is there a way for me to change the version or import another version?
from nltk.corpus import wordnet_1.6 #?
Related
I have been working on a github project from here:
https://github.com/jiacheng-xu/DiscoBERT
According to the authors, it requires Allennlp 0.9.0. I created a virtual environment using pip and tried installing 0.9, but it gave an error. So, I tried Allennlp 1.2 which installed fine,
but I am getting errors in the two following lines:
from allennlp.commands.fine_tune import fine_tune_model_from_file_paths
from allennlp.modules.token_embedders.bert_token_embedder import PretrainedBertModel, PretrainedBertEmbedder
It seems, in the 1.2 version at least, there is no fine_tune and bert_token_embedder module. Is there a quick way to get past these errors?
From https://github.com/allenai/allennlp/issues/4849:
We removed the file_tune command. You can now create your model with the from_archive() constructor (either with code, or from the config file), and train that way.
bert_token_embedder has also gone away. We unified the support for huggingface models in the pretrained_transformer_* classes. So there is now a pretrained_transformer_tokenizer, pretrained_transformer_indexer and a pretrained_transformer_embedder. Before we had several slightly different ways of doing the same thing, and that seemed dangerously confusing.
Why did installing the old version fail though? There is no reason old versions wouldn't work.
I am learning chisel now so I get lots of questions.
I know import chsel3._ can add Chisel library files into the codes.
And I see the chisel codes in chisel-tutorial that have import chisel3._ as well as import chisel3.util._
My question is when do I need to add import chisel3.util._ or something excludes import chisel3_?
Another question is when I write testbench ,What should I extend?
class XXTests(c:XX) extends PeekPokeTester(c){....}
or
class XXTests(c:XX) extends Tester(c){....}
When should I add import chisel3.iotesters.{PeekPokeTester, Driver, ChiselFlatSpec}?
Thanks in advance.
`
Basically, package chisel3 contains the main Chisel primitives like Module, UInt, and Reg while chisel3.util contains useful utilities like Arbiter, Queue, and PriorityEncoder. The distinction isn't always obvious, so it's best to look at the API documentation to see what is available in each: https://chisel.eecs.berkeley.edu/api/index.html (Note that package chisel3 actually points to members that are mostly in chisel3.core).
For your second question, take a look at the chisel-template (which is a good starting point for new Chisel projects). The design is located in src/main/scala/example/GCD.scala. You may note that it only imports chisel3._ because it doesn't use anything in chisel3.util. The test is located in src/test/scala/examples/test/GCDUnitTest.scala and it imports Chisel.iotesters (it should be chisel3.iotesters--this is a dated import but it still works). The test uses the PeekPokeTester to test the design. You should be extending PeekPokeTester or other testers located in the chisel-testers. I believe that extending Tester is old Chisel 2 API but I'm not certain.
I have a Cython extension which I've compiled on Ubuntu 14 and uploaded as an Anaconda package. I'm trying to install the package on another machine which is running Scientific Linux (6?) which ships with an older version of glibc. When I try to import the module I get an error that looks (something like) this:
./myprogram: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./myprogram)
When I say "something like" - the "myprogram" is actually the .so name of the extension.
From what I understand this error is because I have a newer version of glibc on the build system which has an updated version of the memcpy function.
This page has a good description of the problem, and some rather impractical solutions: http://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
There is also a much simpler answer proposed here: How can I link to a specific glibc version?
My question is: how to I apply this solution to my Cython extension? Assuming the __asm__ solution works (as given in the second link) what's the best way to get it into the C generated by Cython?
Also, more generally, how to other modules avoid this issue in the first place? For example, I installed and ran a pre-built copy of numpy without any issues.
This turned out to be quite simple.
Create the following header, glibc_fix.h:
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5")
Then include it by using CFLAGS="-include glibc_fix.h". This can be set as an environment variable, or defined in setup.py.
Additionally, it turns out numpy doesn't do anything special in this regard. if I compile it myself it links with the newer version on my system.
There are almost no questions related to natural language generation on here, so I'm hoping somebody can answer my question. I'm doing work in NLG and have been reading through the official NLTK FUF manual here. I'm trying to do some sentence realization and tried importing the fuf module:
>>> from nltk import fuf
When I do that I get an error which says the module doesn't exist. I checked my NLTK folder and there is no fuf stuff there. I was under the impression that the module came standard with NLTK, but apparently not. I have version 2.0.4 installed on my Mac. FUF isn't a third party package I have to download is it? Please advise.
Thanks,
Mika
It doesn't seem like the FUF package is in the standard NLTK. A note from 2009 in the NLTK google code repo reads:
Moved NLTK-Contrib outside NLTK. Synced some changes for book.
When I try to "import simplejson" (or something that depends on it) in IronPython 2.0, I get "LookupError: unknown encoding: hex". How do I make this work?
The workaround for this is to import the hex codec manually before attempting to import the broken dependency:
from encodings import hex_codec
The issue is being tracked by IronPython, but so far, they claim it's a bug in the standard Python library.
Thanks, sblom. I think IronPython crew are right in saying its a bug in the standard library (or at least Freeze tool as of 2.7). Problem occurs with "frozen" programs iffrom encodings import hex_codec is not explicitly written in the script.
Sorry to 'necro-post', but this issue I feel was relevant, at least in regard to the Freeze tool.