I am trying to understand the char lstm example mentioned here - char-lstm julia example
Function lstm_cell accepts the second parameter as previous state -
function lstm_cell(data::mx.SymbolicNode, prev_state::LSTMState, param::LSTMParam;num_hidden::Int=512, dropout::Real=0, name::Symbol=gensym())
However, in the section - #stack LSTM cells
next_state = lstm_cell(hidden, l_state, l_param, num_hidden=dim_hidden, dropout=dp,name=Symbol(name, "lstm$t"))
hidden = next_state.h
layer_param_states[i] = (l_param, next_state)
layer_param_states[i] gets updated with the next state-
layer_param_states[i] = (l_param, next_state)
why is this done here. Why is the previous state being updated with the next state.
Because layer_param_states stores the final states of the sequence. Note in https://github.com/dmlc/MXNet.jl/blob/master/examples/char-lstm/lstm.jl#L110 the final state is grouped and will be used to make loss with provided labels.
Just FYI, the python example does exactly the same thing: https://github.com/apache/incubator-mxnet/blob/master/example/rnn/old/lstm.py#L167 . The name last_states makes more sense.
Related
I wrote a query which contains multiple for each statements. The query is taking more than 20 minutes to fetch the data. Is there a way to check what time each loop started and ended. (How much time does each loop takes to execute and also the total time taken to complete the program).
You could do as you ask (just follow JensD's suggestsions) but you would likely be better served to use the profiler. You can easily add profiling for a code snippet:
assign
profiler:enabled = yes
profiler:description = "description of this test"
profiler:profiling = yes
profiler:file-name = "filename.prf"
.
/* this is deliberately awful code that should take a long time to run */
for each orderline no-lock:
for each order no-lock:
for each customer no-lock:
if customer.custNum = order.custNum and orderLine.orderNum = orderLine.orderNum then
. /* do something */
end.
end.
end.
/* end of test snippet */
assign
profiler:enabled = no
profiler:profiling = no
.
profiler:write-data().
You can then load that prf file into an analysis tool. The specifics depend on your development environment - if you are using an up to date version of PSDOE there is a Profiler analyzer included, if not you might want to download ProTop
https://demo.wss.com/download.php and use the simple report included in lib/zprof_topx.p.
Ultimately what you are going to discover is that one or more of your FOR EACH statements is almost certainly using a WHERE clause that is a poor match for your available indexes.
To fix that you will need to determine which indexes are actually being selected and review the index selection rules. Some excellent material on that topic can be found here: http://pugchallenge.org/downloads2019/303_FindingData.pdf
If you don't want to go to the trouble of reading that then you should at least take a look at the actual index selection as shown by:
compile program.p xref program.xref
Do the selected indexes match your expectation? Did WHOLE-INDEX (aka "table scan") show up?
Using ETIME you can initiate a counter of milliseconds. It could be called once or several times to tell how much time has passed since reset.
ETIME(TRUE).
/*
Loop is here but instead I'll insert a small pause.
*/
PAUSE 0.5.
MESSAGE "This took" ETIME "milliseconds" VIEW-AS ALERT-BOX.
Milliseconds might not be useful when dealing with several minutes. Then you can use TIME to keep track of seconds but you need to handle start time yourself then.
DEFINE VARIABLE iStart AS INTEGER NO-UNDO.
iStart = TIME.
/*
Loop is here but instead I'll insert a slightly longer pause.
*/
PAUSE 2.
MESSAGE "This took" TIME - iStart "seconds" VIEW-AS ALERT-BOX.
If you want to keep track of several times then it might be better to output to a log file instead of using a MESSAGE-box that will stop execution until it's clicked.
DEFINE VARIABLE i AS INTEGER NO-UNDO.
DEFINE STREAM str.
OUTPUT STREAM str TO c:\temp\timing.txt.
ETIME(TRUE).
/*
Fake loop
*/
DO i = 1 TO 20:
PAUSE 0.1.
PUT STREAM str UNFORMATTED "Timing no " i " " ETIME "ms" SKIP.
END.
OUTPUT CLOSE.
I'm using the CPLEX solver to run my ILP model.The ILP model is implemented with Julia/MultiJuMP.
I would like to limit the time of optimization of the problem. If I were working with OPL, I would just have to add Cplex.tilimt=100
In Julia, I put the following code :
mmodel = MultiModel(solver = CplexSolver("CPLEX.tilim"=100), linear = true)
It doesn't work.
From the last section in https://github.com/JuliaOpt/CPLEX.jl/blob/master/README.md, it appears that Julia uses the legacy parameter names as they appear in the C API of CPLEX. For example, CplexSolver(CPX_PARAM_EPINT=1e-8).
Here's the link to the the CPLEX documentation for that parameter: https://www.ibm.com/support/knowledgecenter/SSSA5P_12.9.0/ilog.odms.cplex.help/CPLEX/Parameters/topics/EpInt.html. As you can see, the name appears as the first row in the 'Name prior to V12.6.0' column.
For the time limit, you should thus use CPX_PARAM_TILIM, as this is the name in https://www.ibm.com/support/knowledgecenter/SSSA5P_12.9.0/ilog.odms.cplex.help/CPLEX/Parameters/topics/TiLim.html.
I am new to sage and have got a code (link to code) which should run.
I am still getting an error message in the decoding part. The error trace looks like this:
in decode(y)
--> sigma[i+1+1] = sigma[i+1]*(z)\
-(delta[i+1]/delta[mu+1])*z^(i-mu)*sigma[mu+1]*(z);
in sage.structure.element.Element.__mul__
if BOTH_ARE_ELEMNT(cl):
--> return coercion_model.bin_op(left, right, mul)
in sage.structure.coerce.CoercionModel_cache_maps.bin_op
--> action = self.get_action(xp,yp,op,x,y)
...... some more traces (don't actually know if they are important)
TypeError: positive characteristics not allowed in symbolic computations
Does anybody know if there is something wrong in this code snipped? Due to previous errors, I changed the following to get to where I am at the moment:
.coeffs() changed to .coefficients(sparse=False) due to a warning message.
in the code line sigma[i+1+1] = sigma[i+1](z)\
-(delta[i+1]/delta[mu+1])*z^(i-mu)*sigma[mu+1](z); where the error occurs, i needed to insert * eg. sigma[i+1]*(z)
I would be grateful for any guess what could be wrong!
Your issue is that you are multiplying things not of characteristic zero (like elements related to Phi.<x> = GF(2^m)) with elements of symbolic computation like z which you have explicitly defined as a symbolic variable
Phi.<x> = GF(2^m)
PR = PolynomialRing(Phi,'z')
z = var('z')
Basically, the z you get from PR is not the same one as from var('z'). I recommend naming it something else. You should be able to access this with PR.gen() or maybe PR(z).
I'd be able to be more detailed, but I encourage you next time to paste a fully (non-)working example; trying to slog through a big worksheet is not the easiest thing to track all this down. Finally, good luck, hope Sage ends up being useful for you!
I have a unit test for a function that adds data (untransformed) to the database. The data to insert is given to the create function.
Do I use the input data in my asserts or is it better to specify the data that I’m asserting?
For eample:
$personRequest = [
'name'=>'John',
'age'=>21,
];
$id = savePerson($personRequest);
$personFromDb = getPersonById($id);
$this->assertEquals($personRequest['name'], $personFromDb['name']);
$this->assertEquals($personRequest['age'], $personFromDb['age']);
Or
$id = savePerson([
'name'=>'John',
'age'=>21,
]);
$personFromDb = getPersonById($id);
$this->assertEquals('John', $personFromDb['name']);
$this->assertEquals(21, $personFromDb['age']);
I think 1st option is better. Your input data may change in future and if you go by 2nd option, you will have to change assertion data everytime.
2nd option is useful, when your output is going to be same irrespective of your input data.
I got an answer from Adam Wathan by e-mail. (i took his test driven laravel course and noticed he uses the 'specify' option)
I think it's just personal preference, I like to be able to visually
skim and see "ok this specific string appears here in the output and
here in the input", vs. trying to avoid duplication by storing things
in variables." Nothing wrong with either approach in my opinion!
So i can't choose a correct answer.
Is there a way to resize a chunked dataset in HDF5 using Julia's HDF5.jl? I didn't see anything in the documentation. Looking through the source, all I found was set_dims!(), but that cannot extend a dataset (only shrink it). Does HDF5.jl have the ability to enlarge an existing (chunked) dataset? This is a very important feature for me, and I would rather not have to call into another language.
The docs have a brief mention of extendible dimensions in hdf5.md excerpted below.
You can use extendible dimensions,
d = d_create(parent, name, dtype, (dims, max_dims), "chunk", (chunk_dims), [lcpl, dcpl, dapl])
set_dims!(d, new_dims)
where dims is a tuple of integers. For example
b = d_create(fid, "b", Int, ((1000,),(-1,)), "chunk", (100,)) #-1 is equivalent to typemax(Hsize)
set_dims!(b, (10000,))
b[1:10000] = [1:10000]
I believe I've got it figured out. The issue is that I forgot to give the dataspace a large enough max_dims. Doing that required digging into the lower-level API. The solution I found was:
dspace = HDF5.dataspace((6,20)::Dims, max_dims=(6,typemax(Int64)))
dtype = HDF5.datatype(Float64)
dset = HDF5.d_create(prt, "trajectory", dtype, dspace, "chunk", (6,10))
Once I created a dataset that can be resized appropriately, the set_dims! function resizes the dataset correctly.
I think I located a few minor issues with the API, which I had to work around or change in my local version. I will get in touch with the HDF5.jl owner regarding those. For those interested:
The constant H5S_UNLIMITED is of type Uint64, but the dataspace function will only accept tuples of Int64, hence why I used typemax(Int64) for my max_dims to imitate how H5S_UNLIMITED is derived.
The form of d_create which I used calls h5d_create incorrectly; it passes parent instead of checkvalid(parent).id (can be seen by comparison with other forms of d_create).