Most of my work has been in MPI, working from the following references;
I also find UPC an intrigueing environment in which I want to play around when I have the time;
Here is a test case Parallel play ground that I will keep around for educational reasons.
First some C refence material http://www.iso-9899.info/wiki/Books
Because I am not so great at remembering every logical construct, I have decided to catalog the bit manipulation techniques that I use.
First the truth tables for the bitwise operators in C,
These are are the standard boolean expressions and have the following truth tables.
| AND | OR | XOR | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| a | b | a&b | a | b | a|b | a | b | a^b | ||
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | ||
| 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 1 | ||
| 1 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 | ||
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ||
<< (L. shift) >> (R. shift) these effectively transfer all bits to the left or right (respectively) by one digit.
| NOT | |
|---|---|
| a | ~a |
| 1 | 0 |
| 0 | 1 |
Most of the time bit twiddling is to assign state or test bits for a branch. Consider a bit field that we wish to know about or set certain bits in, if we have a mask called bitN (maybe 000100, for instance)
To test if a bit in the Nth position of flag is set without concern for any other bits
if( flag & bitN )
printf("bit N is set, don't know anything about other bits");
To test if and only if a bit in the Nth position is set
if( (flag & bitN) == bitN )
printf("only bit N is set");
To check if a bit is unset in the Nth position
if( ~flag & bitN )
printf("bit N is zero, don't know anything about other bits");
Now to set bits we have some options.
Suppose we want to set bit N of flag without affecting any other bits in flag, then
flag |= bitN;
conversely we can unset bit N without affecting other bits in flag
flag &= ~bitN;
or perhaps we want only bit N set, this one is trivial
flag = bitN;
we could be interested in toggling the state of bitN in flag regardless of previous state
flag ^= bitN;
Hardware architecture that has memory access organized via N pointers, instead of linear single pointer memory access. So that problems that process calculations in N dimensions have direct and efficient memory access.
Nearest neighbor discrete calculus for modeling typical diff-eq's found in physics seems to better represent the 'no absolute inertial reference frame' meme in physics. Massively parallel - each object only needs to calculate properties with respect to its neighbors - nodes only need to know their neighbors and their neighbors neighbors so that if relative positions change the list of nearest neighbors can be accurately represented.
Compression efficiency is considered to be a finite value for compressing arbitrary data. Usually compressing highly random data is considered difficult and many algorithms claim to have efficiencies of 10:1 or so. Doing considerably better is thought to be very hard (it is). However, if you are looking for a limit on compression consider the following argument in which I think that infinite compression is achievable.
The digits of pi are pseudo-random, the very same data that is considered most difficult to compress. As a limit to efficiency consider this tiny algorithm to calculate pi written in C.
| file: tinypi.c author: Gjerrit Meinsma g.meinsma@math.utwente.nl |
|---|
long k=4e3,p,a[337],q,t=1e3; main(j){for(;a[j=q=0]+=2,--k;) for(p=1+2*k;j<337;q=a[j]*k+q%p*t,a[j++]=q/p) k!=j>2?:printf("%.3d",a[j-2]%t+q/p/t);} |
Since pi is an infinitely long sequence the efficiency is ∞/141 = ∞! The most difficult data type to compress has infinite compressibility for this particular sequence. So with a bit of innovation there is a lot of room for progress in compression research.
DokuWiki comes close (this page is served from it) to being just right, but still a bit difficult to install/configure and not based on what I consider a standard tool set.
What I would really like is a WYSIWYG/wiki/html modal editor in a browser window that uses a content versioning system to manage the webspace.
Something like integrating TinyMCE with SVN. Further, have interpreter plugins for various program output, like LaTeXRender does for Latex, giving the ability to generate a wide assortment of media (from PDF to SVG) from a standard (XML?) input scheme.
Pros
Cons
All wiki metadata resides in a .htwiki subdirectory at the root of the wiki controlled web space. *When httpd.conf has lines like
| file: httpd.conf |
|---|
<Files ~ "^\.ht"> Order allow,deny Deny from all </Files> |
Then no access is allowed into the metadata directly.
Extend default X copy paste functionality to include paste over highlight without breaking current mouse-highlight (copy) mouse middle-click (paste) methods.
Information from http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki Practical use for the atom SECONDARY. If mouse-highlight (HL) data is different from contents of atom PRIMARY, duplicate atom PRIMARY into atom SECONDARY and put content of (HL) in atom PRIMARY. Then on (HL) middle-click if (HL) is same as atom PRIMARY contents paste data from atom SECONDARY.
This keeps the existing behavior, implements additional features and is not difficult to implement. Since atom SECONDARY is mostly unused this would be a good use for it - IMO.
A log on installing win98 to a laptop using qemu and linux. win98 under qemu
website for detailing the various uses of each and every integer.
Bash currently allows for the saving of a time stamp and the command executed with the following format in .bash_history
#12345678 runfoo --someoptions somearguments #12345679 runbar --opts args ...
where the comment line keeps the epoch number and the following line the command executed. This only archives when and what. It also is designed to keep a limited number of commands and extending that indefinately makes bash slow.
Proposal: First change the behaviour to allow for indefinite command storage even if only a limited number are available without a special override option on history. Second, modify the .bash_history file format to;
#<when> <who@whereURL(pwd)> <whyOptionalComment> <what> ... #12345678 user@hostname:/home/user/bin #update foo for some reason runfoo --someoptions args
when the command line looks like
user@hostname:~/bin $ runfoo --someoptions args #update foo for some reason
The latest version of ssh includes a visual representation of the key fingerprint, and while somewhat cool, I am a little dubious as to its actual usefulness. Here is a link to a more descriptive page regarding the new visual depiction of the key fingerprint.
My Output on running
froze@butsuri$ ssh-keygen
25:29:83:3e:2c:6b:bf:67:0a:23:98:e9:95:12:22:f8 froze@butsuri The key's randomart image is: +--[ RSA 2048]----+ | | | . . | | . o o . | |. o o o | |+.. + S | |++.o.. | |=.Eo | |.oo+ o | | . += | +-----------------+