I am learning to use Castalia for WSN simulation.
I realized that in the user manual, the YYYYMMDD serial number that has been referred to in the examples of obtaining the CastaliaResults was "100809-004640.txt".
However, in the CastaliaPlot to plot the graph, a new number "101209-235427.txt" is being referred to.
Can anybody help with the source of this new number in Castalia 3.2 manual?
As you realised the output files are named with a YYMMDD-HHmmss.txt convention
The name of the actual file does not matter much. They are used as examples in the manual. Obviously you will not have the same filenames when trying out the commands on your own.
In the specific example you mention, it would be better (more consistent) if the manual used the same filename, but it does not matter much.
I wrote the manual. I do not remember exactly what I did all these years back, but the simple explanation for the new filename is that I was rewriting only that part of the manual (the graphs part), so I used some more recent output files to draw the graphs. Probably you can find instances of this minor inconsistency in other places in the manual as well.
Related
I try to use function names that are active and descriptive, which I then document with active and descriptive text (!). This generates redundant-looking code.
Simplified (but not so unrealistic) example in python, following numpy docstring style:
def calculate_inverse(matrix):
"""Calculate the inverse of a matrix.
Parameters
----------
matrix : ndarray
The matrix to be inverted.
Returns
-------
matrix_inv : ndarray
The inverse of the matrix.
"""
matrix_inv = scipy.linalg.inv(matrix)
return matrix_inv
Specifically for python, I have read PEP-257 and the sphinx/napoleon example numpy and Google style docstrings. I like that I can automatically generate documentation for my functions, but what is the "best practice" for redundant examples like above? Should one simply not document "obvious" classes, functions, etc? The degree of "obviousness" then of course becomes subjective ...
I have in mind open-source, distributed code. Multiple authors suggests that the code itself should be readable (calculate_inverse(A) better than dgetri(A)), but multiple end-users would benefit from sphinx-style documentation.
I've always followed the guideline that the code tells you what it does, the comments are added to explain why it does something.
If you can't read the code, you have no business looking at it, so having (in the extreme):
index += 1 # move to next item
is a total waste of time. So is a comment on a function called calculate_inverse(matrix) which states that it calculates the inverse of the matrix.
Whereas something like:
# Use Pythagoras theorem to find hypotenuse length.
hypo = sqrt (side1 * side1 + side2 * side2)
might be more suitable since it adds the information on where the equation came from, in case you need to investigate it further.
Comments should really be reserved for added information, such as the algorithm you use for calculating the inverse. In this case, since your algorithm is simply handing off the work to scipy, it's totally unnecessary.
If you must have a docstring here for auto-generated documentation, I certainly wouldn't be going beyond the one-liner variant for this very simple case:
"""Return the inverse of a matrix"""
"Always"? Definitively not. Comment as little as possible. Comments lie. They always lie, and if they don't, then they will be lying tomorrow. The same applies to many docs.
The only times (imo) that you should be writing comments/documentation for your code is when you are shipping a library to clients/customers or if you're in an open source project. In these cases you should also have a rigorous standard so there is never any ambiguity what should and should not be documented, and how.
In these cases you also need to have an established workflow regarding who is responsible for updating the docs, since they will get out of sync with the code all the time.
So in summary, never ever comment/document if you can help it. If you have to (because of shipping libs/doing open source), do it Properly(tm).
Clear, concise, well written, and properly placed comments are often useful. In your example, however, I think the code stands alone without the comments. It can go both ways. Comments range from needed and excellent to completely useless.
This is an important topic. You should read the chapter on comments in “Clean Code: A Handbook of Agile Software Craftsmanship,” by Robert Martin and others (2008). Chapter 4, “Comments,” starts with this assertion, “Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments. Rather than spend your time writing the comments that explain the mess you’ve made, spend it cleaning the mess.” The chapter continues with an excellent discussion on comments.
Yes, you should always document functions.
Many answers write about commenting your code, this is very different. I say about docstrings, which document your interface.
Docstrings are useful, because you can get interactive help in python interpreter. For example,
import math
help(math)
shows you the following help:
...
cos(...)
cos(x)
Return the cosine of x (measured in radians).
cosh(...)
cosh(x)
Return the hyperbolic cosine of x.
...
Note that even though cos and cosh are very familiar (and exactly repeat functions from C math.h), they are documented. For cos it is stated explicitly that its argument should be in radians. For your example it would be useful to know what a matrix could be. Is it an array of arrays? A tuple of tuples, or an ndarray, as you correctly wrote in its proper documentation? Will a rectangular or zero matrix suit?
Another 'familiar' function is chdir from os, which is documented like this:
chdir(...)
chdir(path)
Change the current working directory to the specified path.
Frankly speaking, not all functions in standard library modules are documented. I found a non-documented method of a class statvfs_result in os:
| __reduce__(...)
Maybe it is still a good example of why you should document. I admit that I forgot what reduce does, so I've no idea about this method. More familiar __eq__, __ne__ are still documented in that class (like x.__eq__(y) <==> x==y).
If you don't document your function, the help for your module will look like this:
calculate_inverse(matrix)
Functions will clump together more, because a docstring takes additional vertical space.
Write a docstring for a person who doesn't see your code. If the function is really simple, the docstring should be simple as well. It will give confidence that the function really is simple, and nothing unexpected will raise from that undocumented function (if they didn't bother to write documentation, are they competent and responsible to produce good code, indeed?)
The spirit of PEPs and other guidelines is that code should be good for all.
I'm pretty sure that somebody will once have difficulty with which is obvious for you.
I (currently) write from my laptop with not a very large screen, and have only one window in vim, but I write in conformance with PEP 8, which says: "Limiting the required editor window width makes it possible to have several files open side-by-side, and works well when using code review tools that present the two versions in adjacent columns". PEP 257 recommends docstrings which will work well with Emacs' fill-paragraph.
So, I don't know any good example when not to write a docstring is worthy. But, as PEPs and guidelines are only recommendations, you can omit a docstring if your function will not be used by many people, if you won't use it in the future, and if you don't care to write good code (at least there).
I'm not sure this is the right fit for stackoverflow but maybe you guys would suggest where to put this question otherwise but here it is anyway. Suppose I have a few sentences of a text like this:
John reads newspapers everyday. Right now he has just finished reading
one. He will read another one and might even read a small book
tomorrow.
This small extract contains the following grammar units:
present simple (reads)
present perfect (has finished)
future simple (will read)
modal verb may
Do you know of any software, algorithm or study that defines rules for identifying these grammar patterns?
Read this also if you are going to use Ruby than you can use TreeTop or find the equivalent parser in other programming language.
NTLK is a natural language parser for python, it works by tagging words. You can look at some examples here. It creates a parse-tree, which are very useful for these types of problems.
I haven't seen it distinguish between simple and perfect, but it could be modified to do so.
imagine you have 2 texfiles (let's say 500kB - 3 MB large): the first is original, the second is the update of this original. How can I find out, what was changed (inserted, deleted) and where the changes took place (in the update file in comparison to original)?
Is there any tool or library somewhere?
Resides this function in any well known text editors?
Does anybody know an algorithm? Or what are the common methods to solve it on the large scale?
What would you do if you face this kind of problem?
Thanx for your ideas...
What you're describing sounds exactly like a diff-style tool. This sort of functionality is available in many of the more advanced text editors.
You can try Notepad++ it is an open source text editor that has a compare files plug in.
There is an extensive list of file comparison tools on wikipedia.
If you want to do it programatically I've used SED and AWK on Unix systems before now - and there are windows versions. Basically these types of file processing languages allow you to read and compare text files on a line-by-line basis and then allow you to do something with the differences (for example save them to a third file).
The unix diff tool does line-by-line differences; there is a GNU tool called wdiff which will do word-by-word differences, and should be available as a package for most Linux distributions or Cygwin.
Classic papers on the algorithm are:
"An Algorithm for Differential File Comparison" - James W. Hunt and M. Douglas McIlroy (1976)
"An O(ND) Difference Algorithm and Its Variations" - Eugene W. Myers (1986)
GNU Diffutils http://www.gnu.org/software/diffutils/
Is there any tool or library somewhere?
There are many. Try using diff, it's a command line based file comparison utility that works fine for small diffs. But if the two file differs a lot, it'll be hard to understand the output of diff. In that case you can use visual file diff tools like diffmerge, Kompare or vimdiff.
Resides this function in any well known text editors?
Many modern editors like vim, Eclipse have this visual diffing feature..
Does anybody know an algorithm? Or what are the common methods to solve it on the large scale?
It is based on the Longest common subsequence algorithm, popularly known as LCS.
LCS of old text and new text gives the part that has remain unchanged. So the parts of old text that is not part of LCS is the one that got changed.
What would you do if you face this kind of problem?
I'd use one of the visual diff tools mentioned to see what and where the changes were made.
I'm looking for ways to programmatically convert my GPS logs to images and would like to do this in Ruby... if that's an acceptable tool. I have no GIS background whatsoever but as a programmer i think it's an interesting problem to look at.
Here is what I have come up with so far. First you'll need some kind of graphing library. I went for gnuplot as I found a Ruby binding for that one but R seems hot these days. I created a small script that converts a GPX file and feeds the data to gnuplot resulting in something like this: alt text http://dl.dropbox.com/u/45672/gpslog.png
This looks fine but gnuplot seems really a tool to create graphs, not spatial data. Is this the way to do it or are there much better solutions available?
Here is another example, any idea how you build stuff like this?
Answer to First Question
Since you stated that you "would like to do this in Ruby...if that's an acceptable tool", I'll go out on a limb and assume that you might be open to a non-Ruby solution if it meets all of your other requirements.
I would recommend Python primarily because in the first chapter of Beginning Python Visualization, Shai Vaingast—the author—goes through an example of reading in GPS data from a GPS receiver and then plots the results. If you're open to a Python-based solution, this book would be a great resource.
Here are the Python packages that are used to read and plot the GPS data:
pySerial to read the GPS data in from the serial port
matplotlib to plot the data. "matplotlib is a library for making 2D plots of arrays in Python. Although it has its origins in emulating the MATLAB® graphics commands, it is independent of MATLAB, and can be used in a Pythonic, object oriented way."
Here's an example figure created by Shai Vaingast showing off a few of the different capabilities of matplotlib for plotting GPS data.
If you are not open to a Python solution, and would prefer Ruby—for whatever reason—I understand. I tried to search for an equivalent of matplotlib in Ruby, but I didn't find an equivalent package.
Answer to Last Question
Here is another example, any idea how you build stuff like this?
Looking at the lower, right-hand corner, it appears that DISLIN was used to create that image. While DISLIN is available for quite a few programming languages, the DISLIN software requirements page does not show that Ruby is supported.
According to the DISLIN website,
DISLIN is a high-level plotting library for displaying data as curves, polar plots, bar graphs, pie charts, 3D-color plots, surfaces, contours and maps.
The software is available for several C, Fortran 77 and Fortran 90/95 compilers on the operating systems UNIX, Linux, FreeBSD, OpenVMS, Windows, Mac OSX and MS-DOS. DISLIN programs are very system-independent, they can be ported from one operating system to another without any changes.
For some operating systems, the programming languages Perl, Python, Java and the C/C++ interpreter Ch are also supported by DISLIN. The DISLIN interpreter DISGCL is availble for all supported operating systems. See a complete list of the supported operating systems and compilers.
Do you really want images, or just a way to visualize the data? How about using the google maps api?
Check out this link:
http://google-dox.net/O.Reilly-Google.Maps.Hacks/0596101619/googlemapshks-CHP-4-SECT-10.html
I think that using gnuplot from any programming language is a good starting approach.
However, I strongly suggest adding the set size ratio -1 gnuplot command somewhere in your code, as this will make the x and y axis scales equal in the plot, which is extremely important.
You could also augment the line with very small point markers equally spaced in time (assuming you have time information in your data, or at least you know that rows are sampled at regular time intervals), so you get a feel of the speed of the movement, which is otherwise lost (i.e., large-spaced point markers on the line mean faster movement). Obviously you should pick a time interval between point markers that makes them appropriately spaced, or compute such time interval automatically: i.e. by computing the length of your curve, converting it in pixel units, and dividing by anything between 10 and 100, to get the total number of points you want to place. The time interval is then given by the total time of the track divided by such number of points. This should work robustly for reasonably regular movements.
Another option is to use a different charting system than gnuplot, which is powerful but a bit old. Options known to me include:
gruff, which is for ruby but seems to miss 2D plotting abilities (which is an obvious requirement).
XML/SWF Charts, which is powerful and flexible, but commercial. In this case, you would use ruby or any other programming language to generate an XML file which then gets interpreted to an interactive graph.
Google Chart API, which can return chart images over the web, forging an appropriate GET or POST request in your code. In this case, you are intersted in the lxy chart type, possibly compounded with a scatter chart for the point markers.
The third option seems the most fun.
GDAL is very popular Open Source GIS kit, there are GDAL Ruby bindings. If you want map data, open street map is very useful. Combined plotting of OSM and the GPS will give pretty nice results. GDAL/OGR Api tutorial is here.
If you want to look more into R, there are Ruby bindings for that too, but there has been no activity on the project for over a year:
http://github.com/alexgutteridge/rsruby
Maybe you have heard of Processing already but have you heard of Ruby-Processing ?
From the Ruby-Processing readme:
Ruby-Processing is a Ruby wrapper for the Processing code art framework.
…
If some quality time with Ruby is your
idea of a pleasant afternoon, or you
harbor ambitions of entering the
fast-paced and not altogether
cutthroat world of Code Art, then
Ruby-Processing is probably something
you should try on for size.
…
Processing is an MIT-developed
framework for making little code
artifacts, animations,
visualizations, and the like,
developed originally by Ben Fry and
Casey Reas, supported by a small army
of open-source contributors.
Processing has become a sort of
standard for visually-oriented
programming, strongly influencing
the designs of Nodebox, Shoes,
Arduino, and other kindred projects
Is it possible to write a program that can extract a melody/beat/rhythm provided by a specific instument in a wave (or other music format) file made up of multiple instruments?
Which algorithms could be used for this and what programming language would be best suited to it?
This is a fascinating area. The basic mathematical tool here is the Fourier Transform. To get an idea of how it works, and how challenging it can be, take a look at the analysis of the opening chord to A Hard Day's Night.
An instrument produces a sound signature, just the same way our voices do. There are algorithms out there that can pick a single voice out of a crowd and identify that voice from its signature in a database which is used in forensics. In the exact same way, the sound signature of a single instrument can be picked out of a soundscape (such as your mixed wave) and be used to pick out a beat, or make a copy of that instrument on its own track.
Obviously if you're thinking about making copies of tracks, i.e. to break down the mixed wave into a single track per instrument you're going to be looking at a lot of work. My understanding is that because of the frequency overlaps of instruments, this isn't going to be straightforward by any means... not impossible though as you've already been told.
There's quite an interesting blog post by Comparisonics about sound matching technologies which might be useful as a start for your quest for information: http://www.comparisonics.com/SearchingForSounds.html
To extract the beat or rhythm, you might not need perfect isolation of the instrument you're targeting. A general solution may be hard, but if you're trying to solve it for a particular piece, it may be possible. Try implementing a band-pass filter and see if you can tune it to selects th instrument you're after.
Also, I just found this Mac product called PhotoSounder. They have a blog showing different ways it can be used, including isolating an individual instrument (with manual intervention).
Look into Karaoke machine algorithms. If they can remove voice from a song, I'm sure the same principles can be applied to extract a single instrument.
Most instruments make sound within certain frequency ranges.
If you write a tunable bandpass filter - a filter that only lets a certain frequency range through - it'll be about as close as you're likely to get. It will not be anywhere near perfect; you're asking for black magic. The only way to perfectly extract a single instrument from a track is to have an audio sample of the track without that instrument, and do a difference of the two waveforms.
C, C++, Java, C#, Python, Perl should all be able to do all of this with the right libraries. Which one is "best" depends on what you already know.
It's possible in principle, but very difficult - an open area of research, even. You may be interested in the project paper for Dancing Monkeys, a step generation program for StepMania. It does some fairly sophisticated beat detection and music analysis, which is detailed in the paper (linked near the bottom of that page).