If I'm running my model in Winbugs14 via a script, what's the command for thinning, or drawing box-plots? I know some of the basic commands, for example:
set(x)
update(1000)
density(alpha)
but I couldn't find the commands for thinning, or drawing model-fit, or drawing box-plots on Winbugs14 documentation. Any ideas?
The complete list of commands is on pages 34-35 of the user manual:
https://faculty.washington.edu/jmiyamot/p548/spiegelhalter%20winbugs%20user%20manual.pdf
In particular I think you want:
thin.updater(thin)
dic.set()
dic.stats()
I'm not sure there is a command to draw boxplots but that can be done in other software e.g. R.
I guess you already know this, but development of WinBUGS stopped years ago, so you really should switch to either OpenBUGS or JAGS at some point soon. I am admittedly biased, but I think that the runjags R package is a good route for people that are familiar with WinBUGS but not as much with R - you could take a look at the first section of:
http://runjags.sourceforge.net/quickjags.html
Related
I have recently tried my hand at learning GTK using Andrew Krause's "Foundations of GTK+ Development" (this is the most recent - 2007 - book on GTK I could find). Thus far, about half of the programs compile & run outright and the other half have deprecated functions which I can find replacements for with a little googling. I do use some online tutorials but they don't have the detail of explanation that Mr. Krause's book has.
In a perfect world, I would like to have an up to date book to learn from but that is not available. Thus I have to go back and forth between the book (GTK2) and online sources (GTK3).
My question, when I try to compile the source code from the book, I get several errors. I have been able to update all of the code except for the issue I name in the title that I cannot get past.
From the book, chapter 3 event boxes, this line is the one I am having trouble with:
gdk_window_set_cursor (eventbox->window, gdk_cursor_new (GDK_HAND1));
I have been able to modify it to work to this point but still get the error when I compile:
gdk_window_set_cursor (eventbox->window, gdk_cursor_new_for_display (gdk_display_get_default(), GDK_HAND1));
When I compile I get:
eventboxes.c:37:33: error: ‘GtkWidget {aka struct _GtkWidget}’ has no member named ‘window’
gdk_window_set_cursor (eventbox->window, gdk_cursor_new_for_display (gdk_display_get_default(), GDK_HAND1));
Having read some other items online such as this one "using cairo with gtk3"
I have found that changes between GTK2 and GTK3 have made members, such as window, inaccessible.
Sorry for the longwinded post by my question is:
Is there a way in GTK3 to make the line of code work or I am just pursuing a fool's errand and should let this one die?
This exact code can be fixed the following way:
GdkWindow * gdk_window = gtk_widget_get_window (eventbox);
gdk_window_set_cursor (gdk_window, gdk_cursor_new (GDK_HAND1));
However, I don't think it's a good idea to learn Gtk3 with Gtk2 books. You can read them to get overall view, but then switch to gtk documentation, gtk3-demo app for some recipes, gtk3-widget-factory source code and, of course, SO.
I am trying to run Omnet++ and matlab software in parallel and want them to communicate. When Omnet++ is running, I want to update the position of the node and for that I want to edit the .ned and .int files with matlab results continuously. During simulation I want to generate the result file using the updated files. I want just to update the position and don't want to add or delete any node. Please suggest me a way for proceeding?
matlab_loop
{
matlab_writes_position_in_ned_file;
delay(100ms);
}
omnet_loop
{
omnet_loads_ned_and_simulates;
//sca and vec should update;
delay(100ms);
}
Thank you.
NED and Ini files are read only during initialization of the model. You can't "read" them again after the simulation started. On the other hand, you are free to modify your parameters and create/delete modules using OMNeT++'s C++ API. What you want to achieve is basicaly: set your node position based on some calculations carried out by matlab code. The proper way to do it:
Generate C code from your matlab code.
Link that code to your OMNeT++ model
Create a new mobility model (assuming you are using INET) that is using the matlab code
What you are looking for seems to be more of a project rather than a question/problem which can be solved in Q&A site like stackoverflow.
Unfortunately, I have little understanding of matlab and V-REP to provide you a satisfactory answer. However, it seems that you will need to play around with APIs in lower levels.
As an example of coupling different simulation tools to form a simulation framework in case of need consider reading this paper and this
Also note the answer given by #Rudi. He seems to know what he is talking about.
This problem may seem a bit weird; please bear with me.
When I try to access any function in the 'Symbolic Math Toolbox' in MATLAB, such as help ztrans or help laplace, I get the following kind of message
ztrans not found.
Use the Help browser Search tab to search the documentation, or
type "help help" for help command options, such as help for methods.
However, the toolbox seems to be installed when I try the ver or pathtool command.
Moreover, when I try some simple code such as:
>> syms k x
>> f = sin(k);
>> ztrans(f, k, x)
the code works fine and on trying the help command again, they seem to work fine as well. However, the problem again arises when I close and reopen MATLAB.
I found a few instances of other users facing similar problems on the Mathworks portal, but none of them seemed to provide any concrete solutions. Some of them seem to blame it on MATLAB hashing the tollbox incorrectly, so I tried the rehash toolbox command as well, but had no luck.
I'm not sure if this problem is just for this particular toolbox or not, but the other toolboxes I use at least seem to work fine.
EDIT-I
I also realised that the documentation is always available when I take Help --> Product Help from the menu-bar, though it is not available in the function browser even after I try the sample code.
EDIT-II
>> license('checkout','Symbolic_Toolbox')
gives me
ans =
1
I'm not working on a student license either.
It could be a license issue. Try to get further information with:
license('inuse')
If you have a Student version, some functions cannot be executed.
istudent
In case that you are in an office/university, and you have floating licenses. Be sure to check-out all the licenses before running your code.
license('checkout','toolbox_name')
Can anyone share his experience on workflow for R peject development under ESS? I tried several times to learn emacs but I have not get it yet. I can understand ESS as an editor, but is there a project view in ESS? what's the efficient ways to set up/view R project directory, coding, and testing, and how's ESS has an edge to facilitate the whole process?
Do you use ESS as a good R editor only or tend to emulate a R IDE environment within ESS?
Thanks for any advices.
It sounds like you're asking two separate questions.
One question concerns workflow and the other concerns using ESS.
As I use StatET and Eclipse, I'll just share my experience regarding the workflow aspect of your question.
As with Vincent I also follow something like the workflow set out by Josh Reich here (also see Hadley's useful comments):
Workflow for statistical analysis and report writing
Although it can vary between projects, I tend to have a couple of main R files
import.R: this imports data files and does any necessary cleaning and manipulation
analyse.R: This generates the output that I need for any final report
main.R: This calls import.R and analyse.R
The aim is for import.R and analyse.R to represent the complete and final workflow for producing the final results of any analyses.
In terms of a directory structure for an analysis project, I'll often also have the following folders
data: for storing any raw data files
meta: for storing meta data, such as variable labels, scoring systems for tests, recoding information, etc.
output: for storing any graphics, tables, or text generated by my analyses that I might want to incorporate into an external program
temp: When exploring the data and brainstorming analyses, I like to type code into files instead of using the console. I tend to label these temp1.R, temp2.R, temp3.R. I store these in a temp folder. That way I have a permanent record that's easily accessible. If the analyses become final they get incorporated into one of the main R files (i.e., import.R or analysis.R)
functions: If I think that a function will be needed across a couple of projects, I often place it one function per file or a set of related functions in a file in a folder called functions. This makes it relatively easy to reuse functions across projects, when the formal requirements of package development are more than needed.
library: If I want to create some general functions that I think will be project specific, I'll place them in this folder
save: A folder to store any saved R objects
StatET and Eclipse make it easy to interact with such a file system.
Of course, given all the R gurus that use ESS and Emacs, I'm sure it also handles interactions with the file system well.
I'm not exactly sure what you expect as an answer on this one. I, for one, have stolen (and adapted) a system that was suggested here a little while ago (by Josh Reich):
Create a folder for every project, and split up your work in a bunch of different .R files:
Load.R for getting your raw data into R;
Prep.R for cleaning the data, recoding variables, etc.;
Func.R for coding any custom functions you will need for evaluation; and
Eval.R for running your final stuff.
If that doesn't fit your style, just change it.
Then, you can either have a master file to call each of the parts one after each other (good for reproducibility), or save at different stages and have the individual scripts load the appropriate data (good if some of the prep work is very computationally/time intensive).
**
On a different note, the trick that is posted at the link really helped me get into ESS. It turns Shift-Enter into a one-stop-ESS-shop: http://www.kieranhealy.org/blog/archives/2009/10/12/make-shift-enter-do-a-lot-in-ess/
Others have given you some good ideas about how to setup your directory/file structure for a project.
You also asked about "project views," in which case you might want to look into the Emacs Code Browser (ECB).
You can find some screen shots of it in action on its site, here:
http://ecb.sourceforge.net/screenshots/index.html
Some of the developers on the project I work on have a habit of commenting their code to show which version of the product it was added for, e.g.
// added for superEnterpriseyWonder v2.5
string superMappingTag = MakeTag(extras);
if (superMappingTag.empty())
{
autoMapping = false;
}
// end added for superEnterpriseyWonder v2.5
Whenever I see this my blood pressure rises, and I have to spend 5 minutes browsing SO to cool off. It seems to me that they don't understand version control and if I were to use this practice too every other line in the source files would be a comment about when things were added. I'm considering removing all such comments from files that I work on, but am wondering is it just me being picky and is there actually some value to these comments?
If you're using Source Control then I would advocate adding a build label to Source Control after every build. That way you can search for all source modified for a specific build, with no nasty comments clogging your code.
This from Clean Code, a book by Bob Martin:
"The proper use of comments is to
compensate for our failure to express
ourself in code. Note that I used the
word failure. I meant it. Comments are
always failures."
I always think of that quote when I see a comment so I'm not suprised your blood boils.
No value whatsoever. If you have a blame tool in your version control this will achieve this, they just add noise.
Whats worse is they will attract further comments to your code to make it completely unreadable
// added for superEnterpriseyWonder v2.5
string superMappingTag = MakeTag(extras);
if (superMappingTag.empty())
{
// bug fix #12345674 shuld have been true
autoMapping = true;
// bug fix #12345674 should have been true
i++; // v2.6 now need to up the counter DO NOT DELETE
}
// end added for superEnterpriseyWonder v2.5
and then someone will delete the method but leave the code comment in
// added for superEnterpriseyWonder v2.5
// bug fix #12345674 should have been true
// v2.6 now need to up the counter DO NOT DELETE
// end added for superEnterpriseyWonder v2.5
Just say no to crappy comments
I'd say there's no value: This info can also be retrieved with your SCM's annotate/blame functionality. Also, anyone can add text between these comments, which make the comments dated (since you might add something for v2.6 while the comments say v2.5)
Another thing to note is that these comments are essentially hidden: You only see them when you are looking at the source code in question, so you can't use it to generate a changelog or something.
The comment as shown, is probably not to useful. However, there may be times that adding a feature may cause the addition of not so obvious code. In which case, a comment describing the change and/or why it the code is not obvious would be appropriate.
Not only is there no value here...there's negative value. Maintenance of comments is already sketchy in most places, this just adds another thing for people to screw with. These comments have no value to the reader and are therefore clogging their brain up with useless version information when they could have another line of code in their memory. It's also another line to have a merge conflict on (totally not joking here..I've seen merge conflicts on comments).
Could be useful in some cases (e.g. if this helps to understand why some function works differently in V3 than in V2) but in general, it's the job of the SCM to know what has been added when.
You are not picky IMHO. There are at least three good reasons not to add this type of comment in source code:
their place is actually in a Version Control System, where you can have a global view of everything that has changed to accommodate a new version of a library or a new feature. Provided it is done correctly and the logs are used.
if the source code is part of the deliverables to clients, maybe they don't need to know the history of what happened. Imagine you have done a modification for another client, and put that in comments!
too many comments are no better than too few.
The line is not clear though, what would be the difference between
// Compliance with specs abc (additional xyz feature)
...
... // some code
and:
// xyz feature:
...
... // some code
In general terms, I would not put anything that is related to the history in the source code, but stick to commenting what is done, how it is done, so that someone else can easily browse through the code and understand it.
My advice: have a methodology document written, or an informal discussion.
If seeing a superfluos comment makes your blood pressure rise, you need to take up drinking or something.
That said, I agree that such comments are mostly useless. If used consistently, the program would quickly become a maze of such comments. What if a line is changed once for version 2.5 and then a year later changed again for bug 3294? Do you put two "version" comments on the same line, or just keep the latest? If you only keep the latest, then you've lost the fact that this was originally added for 2.5. If you keep them both, what happens when there's a third change or a fourth? How do we know what the state was at each change? What happens when you add a block of code in version 2.5, and then for version 2.6 you add another block of code embedded within the 2.5 block? Etc etc. The program could easily end up having more version comments than lines of code.
If not done consistently, the comments would quickly become misleading. Someone could put a comment saying this block was added for 2.5, someone else could insert code inside that block for version 2.6 and not comment it, and now we have a comment that seems to say that the second block was added for 2.5.
And do we care that much? It's pretty rare that I care when a change was made. Oh, okay a couple of weeks ago I cared because I wanted to know who to blame for a major screw up.
As others have pointed out, version control systems do this for you on the rare occasions when you need it. I guess if you didn't have any sort of VCS, a case could be made for doing this. But you can get some very nice VCSs for free. If you need one, get one. Otherwise you're like the people who say that you should practice doing arithmetic in your head because otherwise what would you do if your calculator quit working. The assumption apparently being that at any moment, all the calculators in the world might simultaneously break.
You might say that it can help to be able to say, "Ohhhh, this was added to order entry to support the new salesman timecard function" or some such. But then the important this is not "This code was changed by Bob for version 3.2.4", but rather, "This code produces this data which isn't used here but is needed by another module over there".
I am a firm believer in writing comments that introduce sections of code and describe the general idea behind complex or otherwise non-obvious code. But that's an entirely different thing.
Consider that some may have to grab snapshots from the VCS. In that case, they don't have history to fall back on .. and such comments become useful.
I saw that a lot in code written by people that didn't use version control until recently. I guess they just took the habit and now it's hard to stop.
Another reason I found was that sometime it is important to know what piece of code is associated with what version. Of course you can always check the version log, but you don't always have time for that, and it's annoying. In some cases saying "code for v3.2" speaks more to other developers than "code to do x, y and z"... it all depends on the conventions established by the team.
Another answer is that in some projects I worked with some code was commented like that, but it was before the project actually started using version control. In that case it also made sense to keep it that way.
I find them useful, it saves chasing through the VCS to find out why a change was made to the code, or to find the BugId for a defect, given I remember what the code change was.
Although in theory the VCS contains the information, in practice it can get buried, particularly by integrations.
In other works which is easier:
// DEF43562 - changed default value
foobar = true
Or
blame(or equiv)
chase through
history to find the correct change.
Follow integration to source, and
repeat 1&2.
Find bug id attached
to original change, if you are
lucky.
Basically the comment is a short-cut around the VCS, and flaky VCS/BugTracking integration.
I find that the comments are also useful as a marker for: "This decision has been reviewed by customers/users/review committee, and this is the selected answer, be careful about changing the behaviour".