I am trying to implement code in parallel using Julia. I'm using the #everywhere macro in order to make all processes fetch data from a RemoteRef.
Is it possible to use a variable name thats only defined on the first process in the #everywhere expression and somehow specify that I want it to send the value of that variable, and not the variable name, to all processes?
Example:
r = RemoteRef()
put(r, data)
#everywhere data = fetch(r)
This returns an error because r is not defined on all processes.
How should I move data to all processes?
Also, can I tell Julia to put the value instead of the variable name in the expression?
Something akin to how name = "John"; println("Hello, $name") will print "Hello, John"
To find the functions (and macros) Spencer pointed in a nice little package, checkout ParallelDataTransfer.jl. The tests are good examples of usage (and the CI shows that these tests pass on v0.5 on all platforms).
For your problem, you can use the sendto function:
z = randn(10, 10); sendto(workers(), z=z)
#everywhere println(z)
Related
I have functions process and matrix. The following code works
process(matrix({{2,4,6},{8,10,12},{14,16,20}}))
However the following doesn't work.
n='matrix({{2,4,6},{8,10,12},{14,16,20}})'
process(n)
It throws some error. The reason is obvious that process takes n as string rather than the output of the function matrix. So the basic difficulty involved here is about evaluating string from variable n and then give it as argument to the function process. Here loadstring function is of no use as matrix is local function and can't be referred from loadstring.
Is there any work around for this? I hope that I have clearly stated the problem here. It is about evaluating (or unloading) string and then passing it as argument to another function. Any help will be appreciated. Thanks.
as matrix is local function
Lua takes local declarations seriously. If a variable is declared local, it can only be accessed by code which is statically within the local scope of that variable. Strings which you later turn into code are not statically in the local scope and therefore cannot access local variables.
Now, with Lua 5.2+, you can provide load with a second parameter, a table which represents the global environment against which that Lua chunk will be built. If that table contains a matrix value, then the loaded string can access it. For Lua 5.1, you'd have to use setfenv on the function returned to load to accomplish a similar effect. The Lua 5.2+ method would look like this:
local env = {matrix = matrix}
local func = load("return matrix({{2,4,6},{8,10,12},{14,16,20}})", nil, "t", env)
process(func())
Note the following:
You must create an explicit table which is the global environment. There's nothing you can pass that says "make my locals available"; you have to put every local you'd like to access there. Which is, generally speaking, why you pass these things as parameters or just make them globals.
You explicitly need the "return " there if you want to get the results of the call to matrix.
You have to call the function. Functions are values in Lua, so you can freely pass them around. But if you want to pass the results of a function to another function, you have to actually call it.
I need to convert a list into a string and then do the reverse process. Note that one script will convert List->String and another script will convert String->List, so store the list in a variable is not a solution. Use split(', ') or similar is not a solution either in all cases. So, as a challange I invite you to do the conversion in the following example:
l = ['ab,.cd\'ac"', b'\x80', '\r\nHi, !', b'\x01']
str_l = str(l)
I have tried one thing that worked: using exec() built-in function but people says is not a good practice, so I invite you to give me another alternative. Also I am having problems using exec() inside a function but that's another question that you can check -> Using exec() inside a function Python 3
This should work:
str_l = ("|").join(l)
Which gives you your first string. Then do:
l_2 = str_l.split("|")
Which gives you your second list.
Is there any way to duplicate a ParserRule? I need a real deep copy, so copyFrom() doesn't do the trick. Or must I re-parse the code?
An alternative idea how to solve the following would also be much appreciated:
I am working on a compiler, translating old legacy code to modern programming languages, in this case EGL -> Java.
EGL has a concept called Standalone Function, which are similar to C-macros. This means that code inside the functions can reference symbols in the calling scope. So both defining and resolving of symbols and type promotion are context-dependent.
In ANTLR3, we solved this by dupTree(), and simply made a copy to work on in each calling scope.
Dynamic types is not an option.
Example (pseudo code) to illustrate:
Program A
int var = 4;
saf(); # Prints 5
end A;
Program B
String var = "abc";
saf(); # Prints abc1
end B;
function saf()
int j = 1;
print(var + j);
end saf;
As of version 4.2, ANTLR 4 does not include any API for manipulating the structure of a parse tree after the parse is complete. This is an area we are currently exploring, especially considering the possibilities created by the new pattern matching syntax.
For duplicating trees, I recommend you implement the visitor interface created when you generated your parser. This will allow you to call visit on any node in your parse tree to create a deep copy of that node.
Hello I'm trying to write a function which reads a certain type of spreadsheet and creates vectors dynamically from it's data then returns said vectors to the workspace.
My xlcs is structured by rows, in the first row there is a string which should become the name of the vector and the rest of the rows contain the numbers which make up the vector.
Here is my code:
function [ B ] = read_excel(filename)
%read_excel a function to read time series data from spreadsheet
% I get the contents of the first cell to know what to name the vector
[nr, name]=xlsread(filename, 'sheet1','A2:A2');
% Transform it to a string
name_str = char(name);
% Create a filename from it
varname=genvarname(name_str);
% Get the numbers which will make up the vector
A=xlsread(filename,'B2:CT2');
% Create the vector with the corect name and data
eval([varname '= A;']);
end
As far as I can tell the vector is created corectly, but I have no ideea how to return it to the workspace.
Preferably the solution should be able to return a indeterminate nr of vectors as this is just a prototype and I want the function to return a nr of vectors of the user's choice at once.
To be more precise, the vector varname is created I can use it in the script, if I add:
eval(['plot(',varname,')'])
it will plot the vector, but for my purposes I need the vector varname to be returned to the workspace to persist after the script is run.
I think you're looking for evalin:
evalin('base', [varname '= B;']);
(which will not work quite right as-is; but please read on)
However, I strongly advise against using it.
It is often a lot less error-prone, usually considered good practice and in fact very common to have predictable outcomes of functions.
From all sorts of perspectives it is very undesirable to have a function that manipulates data beyond its own scope (i.e., in another workspace than its own), let alone assign unpredictable data to unpredictable variable names. This is unnecessarily hard to debug, maintain, and is not very portible. Also, using this function inside other functions does not what someone who doesn't know your function would think it does.
Why not use smoething like a structure:
function B = read_excel(filename)
...
B.data = xlsread(filename,'B2:CT2');
B.name = genvarname(name_str);
end
Then you always have the same name as output (B) which contains the same data (B.data) and whose name you can also use to reference other things dynamically (i.e., A.(B.name)).
Because this is a function, you need to pass the variables you create to an output variable. I suggest you do it through a struct as you don't know how many variables you want to output upfront. So change the eval line to this:
% Create the vector with the correct name and data
eval(['B.' varname '= A;']);
Now you should have a struct called B that persists in the workspace after running the function with field names equal to your dynamically created variable names. Say for example one varname is X, you can now access it in your workspace as B.X.
But you should think very carefully about this code design, dynamically creating variables names is very unlikely to be the best way to go.
An alternative to evalin is the function assignin. It is less powerfull than evalin, but does exacty what you want - assign a variable in a workspace.
Usage:
assignin('base', 'var', val)
Basically, I have 10 data files and I wrote a MATLAB function to process these data.
The code is like this:
function Z = fitdata(file_path)
A = importdata(file_path,',');
...
end
Since I don't want to input the same command 10 times (for different file names), I wrote another script to automate this processing. The code looks like this:
function X = automate()
myarray = {'file_one', 'file_two', 'file_three',......,'file_ten'};
for i = 1:9
mypath = myarray{i};
W = fitdata(mypath);
...
end
end
But I'm getting the error "Too many input arguments" at the call to the fitdata(file_path) function.
How should I do this?
EDIT: Since the suggestions below didn't solve the problem, and since there doesn't appear to be anything else wrong with the code you posted, I would next check to make sure the version of fitdata given above is the only function of that name on the MATLAB path. You may have inadvertently created another function or script and saved it as fitdata.m, and this may be getting called instead of the version you created above.
Previous answer:
I think you mean to use the IMPORTDATA function instead of IMPORT, which is the likely source of the error you are getting.
One additional piece of advice: it's best not to name one of your variables path, since there is already a function PATH. The variable will end up being used instead of the function (based on the MATLAB precedence rules), which will still be what you want to happen in this specific case but is a source of confusion and error in other cases.