I am trying to learn pyopencl, but I ran into issues already in the following very simple code:
import pyopencl as cl
platform = cl.get_platforms()
my_devices = platform[0].get_devices()
print(my_devices)
However, this returns an empty list, while as I understand it it should give my a list containing an object corresponding to my graphics card. How do I troubleshoot this problem?
Apparently I had to install drivers(?) for my graphics card that made it available for opencl (which was not mentioned anywhere when installing pyopencl). For the Intel graphics card on linux, there is the open source implementation Beignet, which works fine.
Related
I am a beginner in Machine Learning and trying Document Embedding for a university project. I work with Google Colab and Jupyter Notebook (via Anaconda). The problem is that my code is perfectly running in Google Colab but if i execute the same code in Jupyter Notebook (via Anaconda) I run into an error with the ConcatenatedDoc2Vec Object.
With this function I build the vector features for a Classifier (e.g. Logistic Regression).
def build_vectors(model, length, vector_size):
vector = np.zeros((length, vector_size))
for i in range(0, length):
prefix = 'tag' + '_' + str(i)
vector[i] = model.docvecs[prefix]
return vector
I concatenate two Doc2Vec Models (d2v_dm, d2v_dbow), both are working perfectly trough the whole code and have no problems with the function build_vectors():
d2v_combined = ConcatenatedDoc2Vec([d2v_dm, d2v_dbow])
But if I run the function build_vectors() with the concatenated model:
#Compute combined Vector size
d2v_combined_vector_size = d2v_dm.vector_size + d2v_dbow.vector_size
d2v_combined_vec= build_vectors(d2v_combined, len(X_tagged), d2v_combined_vector_size)
I receive this error (but only if I run this in Jupyter Notebook (via Anaconda) -> no problem with this code in the Notebook in Google Colab):
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
Input In [20], in <cell line: 4>()
1 #Compute combined Vector size
2 d2v_combined_vector_size = d2v_dm.vector_size + d2v_dbow.vector_size
----> 4 d2v_combined_vec= build_vectors(d2v_combined, len(X_tagged), d2v_combined_vector_size)
Input In [11], in build_vectors(model, length, vector_size)
3 for i in range(0, length):
4 prefix = 'tag' + '_' + str(i)
----> 5 vector[i] = model.docvecs[prefix]
6 return vector
AttributeError: 'ConcatenatedDoc2Vec' object has no attribute 'docvecs'
Since this is mysterious (for me) -> Working in Google Colab but not Anaconda and Juypter Notebook -> and I did not find anything to solve my problem in the web.
If it's working one place, but not the other, you're probably using different versions of the relevant libraries – in this case, gensim.
Does the following show exactly the same version in both places?
import gensim
print(gensim.__version__)
If not, the most immediate workaround would be to make the place where it doesn't work match the place that it does, by force-installing the same explicit version – pip intall gensim==VERSION (where VERSION is the target version) – then ensuring your notebook is restarted to see the change.
Beware, though, that unless starting from a fresh environment, this could introduce other library-version mismatches!
Other things to note:
Last I looked, Colab was using an over-4-year-old version of Gensim (3.6.0), despite more-recent releases with many fixes & performance improvements. It's often best to stay at or closer-to the latest versions of any key libraries used by your project; this answer describes how to trigger the installation of a more-recent Gensim at Colab. (Though of course, the initial effects of that might be to cause the same breakage in your code, adapted for the older version, at Colab.)
In more-recent Gensim versions, the property formerly called docvecs is now called just dv - so some older code erroring this way may only need docvecs replaced with dv to work. (Other tips for migrating older code to the latest Gensim conventions are available at: https://github.com/RaRe-Technologies/gensim/wiki/Migrating-from-Gensim-3.x-to-4 )
It's unclear where you're pulling the ConcatenatedDoc2Vec class from. A clas of that name exists in some Gensim demo/test code, as a very minimal shim class that was at one time used in attempts to reproduce the results of the original "Paragaph Vector" (aka Doc2Vec) paper. But beware: that's not a usual way to use Doc2Vec, & the class of that name I know barely does anything outside its original narrow purpose.
Further, beware that as far as I know, noone has ever reproduced the full claimed performance of the two-kinds-of-doc-vectors-concatenated approach reported in that paper, even using the same data/described-technique/evaluation. The claimed results likely relied on some other undisclosed techniques, or some error in the writeup. So if you're trying to mimic that, don't get too frustrated. And know most uses of Doc2Vec just pick one mode.
If you have your own separate reasons for creating concatenated feature-vectors, from multiple algorithms, you should probably write your own code for that, not limited to the peculiar two-modes-of-Doc2Vec code from that one experiment.
I'm having this weird issue where my target, which interfaces a slightly customized python module (installed with pip install --editable) through reticulate, gives different results when it's being called from an interactive session in R from when targets is being started from the command line directly, even when I make sure the other argument(s) to tar_make are identical (callr_function = NULL, which I use for interactive debugging). The function is deterministic and should be returning the exact same result but isn't.
It's tricky to provide a reproducible example but if truly necessary I'll invest the required time in it. I'd like to get tips on how to debug this and identify the exact issue. I already safeguarded against potential pointer issues; the python object is not getting passed around between different targets/environments (anymore), rather it's immediately used to compute the result of interest. I also checked that the same python version is being used by printing the result of reticulate::pyconfig() to screen. I also verified both approaches are using the same version of the customized module.
Thanks in advance..!
I have a dataset in RDS format that I managed in RStudio, but I would like to open this in Python to do the analysis. Would it be possible to open this type of format into Python?
I tried the following codes already:
pip install pyreadr
import pyreadr
result = pyreadr.read_r('/path/to/file.Rds')
However, I get a
MemoryError: Unable to allocate 18.9 MiB for an array with shape
(2483385,) and data type float64.
What can I do?
Pyreadr is a wrapper around the C library librdata, and librdata has a hardcoded limit on the size an R vector can have. The limit used to be very low in old versions, but it was increased. Your vector would fail in older versions but should work in a recent one, so please check that you are using the most recent version.
If that doesn't help, then it may be a bug. If you can share the file please submit an issue in github.
Here a link to the old issues in github librdata and pyreadr (theoretically now solved)
https://github.com/WizardMac/librdata/issues/19.
https://github.com/ofajardo/pyreadr/issues/3
EDIT:
The limit is now permently removed in pyreadr 0.3.0. Now this should not be an issue anymore.
From my knowledge, you could store the data to a pandas dataframe as mentioned in this link.
The second option(link)
How can I explicitly free memory in Python?
If you wrote a Python program that acts on a large input file to create a few million objects representing and it’s taking tons of memory and you need the best way to tell Python that you no longer need some of the data, and it can be freed?
The Simple answer to this problem is:
Force the garbage collector for releasing an unreferenced memory with gc.collect().
I hope this answers your query
This is an issue I am encountering for different pieces of codes I am writing in R.
Basically, I would like to generate a window that displays a picture (a .png file). Following for instance guidances from this or this, I come up with this kind of code:
library(tcltk)
tmpFile <- tempfile(fileext = ".png")
download.file("https://www.r-project.org/logo/Rlogo.png", tmpFile)
tcl("image","create","photo", "imageLogo", file=tmpFile)
win1 <- tktoplevel()
tkpack(ttklabel(win1, image="imageLogo", compound="image"))
This works fine under Mac OS, but not on Linux nor on Windows, where I am displayed such an error message:
[tcl] couldn't recognize data in image file
I can find some workarounds when I want to display graphs, using for instance packages tkrplot or igraph. Nonetheless, I would be really eager to understand why I got such errors when running my scripts on Linux or Windows, whereas it works just fine on Mac OS.
Apologies in case this issue is obvious, but I haven't found anything about potential differences with the tcltk package depending on the OS.
Tk's native support for PNG was added in 8.6. Prior to that, you need to have the tkimg extension loaded into Tk to add the image format handler required. If your installation of Tcl/Tk that R is using is set up right, you can probably make it work with:
tclRequire("Img")
once you've initialised things sufficiently. Yes, the name used internally is “Img” for historical reasons, but that's just impossible to search for! (This is the key thing in this mailing list message from way back.)
However, upgrading the versions of Tcl and Tk to 8.6 is likely to be a better move.
Finally and a bit lately, I would like to close this issue and sum up the different suggestions that were kindly made in response of my question:
R comes along with Tcl 8.5, even with the latest version 3.3.2, which means that there is no way for embedding a PNG file with the usual command into a window created thanks to Tcl/Tk. For some reasons it is working on Mac OS, but do not expect this to work easily on other OSs.
In order to display pictures, graphs, etc. in a window generated by Tcl/Tk in R, better look for either using the GIF support (when possible) or trying alternative solutions (see the question for possible alternative options).
In case one really wants to display PNG files, the solution consists of installing Tcl 8.5 (for instance ActiveTcl) along with the extension Img. In order to use the Tcl/Tk package that you've just installed on your computer, you can refer to the R FAQ for Windows for instance (as stated in the FAQ, you need to install Tcl 8.5 - I tried with Tcl 8.6, thereby hoping to solve my issue, but it didn't work). Basically, you need to set up an environment variable (MY_TCLTK) and put the path where the package Tcl/Tk is installed. Needless to be said, Tcl/Tk is commonly used in R in order to implement GUIs; if you have to go through very complex procedures to set up the system, the package definitely loses its advantages.
Finally, since Tcl 8.6 should be available soon or later with R (already implemented in the devel version), this issue will be de facto outdated.
I am using Qt on two ubuntu machines and am copying the source code from time to time between them. I found a really annoying problem when doing that and I can't figure out why this happens.I am using a table Widget to display some data and want to stretch the horizontal header to fit the content length. To do that I use the following line:
ui->tableWidget->horizontalHeader()->setResizeMode(0, QHeaderView::ResizeToContents);
This works just fine.
I have a few of this codelines.
However, when I now copy over my source code to the other PC to work on it, I get the following compile error:
'class QHeaderView' has no member named 'setResizeMode'
Renaming 'setResizeMode' to 'setSectionResizeMode' will work just fine to fix that problem, but if I now copy the source code back to the first PC, it tells me:
'class QHeaderView' has no member named 'setSectionResizeMode'
...and I have to rename it to 'setResizeMode' again, to continue working.
I checked the Qt version on both PCs and they are both "Qt Creator 2.7.0" based on "Qt 5.0.1 (32 bit)".
Also the systems are up to date.
The only difference is, that I am using one of them in english system language, the other one in german...but I don't see how that would affect Qt's member declaration. o.O
Anyone knows what the problem is?
The constant renaming can get annoying over time.
it may be that the QT header versions don't match up
double check the QT_VERSION_STR in QtCore/qglobal.h
for a quick check if you are too lazy add a #pragma message("QT version: " QT_VERSION_STR) to the code to have the compiler output it while compiling