Data Structures | |
| struct | EMAC_PKT_DESC_s |
| Emac packet descriptor specification. More... | |
| struct | EMAC_IOCTL_CMD_RESP_s |
| Emac IOCTL command response specification. More... | |
| struct | EMAC_CHAN_MAC_ADDR_tag |
| Used to Initialize the Emac Driver Instance with mac addresses and channel information. More... | |
| struct | EMAC_OpenConfigInfo_s |
| Used to Initialize the Emac Driver Instance at time of emac_open. More... | |
| struct | EMAC_IOCTL_PARAMS_S |
| IOCTL parameters field of emac_ioctl API. More... | |
Macros | |
| #define | EMAC_MAC_ADDR_LENTH 6U |
| UAC address specification. More... | |
Typedefs | |
| typedef struct EMAC_PKT_DESC_s | EMAC_PKT_DESC_T |
| Emac packet descriptor specification. More... | |
| typedef struct EMAC_IOCTL_CMD_RESP_s | EMAC_IOCTL_CMD_RESP_T |
| Emac IOCTL command response specification. More... | |
| typedef struct EMAC_CHAN_MAC_ADDR_tag | EMAC_CHAN_MAC_ADDR_T |
| Used to Initialize the Emac Driver Instance with mac addresses and channel information. More... | |
| typedef struct EMAC_OpenConfigInfo_s | EMAC_OpenConfigInfo |
| Used to Initialize the Emac Driver Instance at time of emac_open. More... | |
| typedef struct EMAC_IOCTL_PARAMS_S | EMAC_IOCTL_PARAMS |
| IOCTL parameters field of emac_ioctl API. More... | |
| #define EMAC_MAC_ADDR_LENTH 6U |
UAC address specification.
This type is used to pass MAC addresses to the driver.
| typedef struct EMAC_CHAN_MAC_ADDR_tag EMAC_CHAN_MAC_ADDR_T |
Used to Initialize the Emac Driver Instance with mac addresses and channel information.
This configuration structure is a field of EMAC_OPEN_CONFIG_INFO_T and used to configure the driver with channel and mac addreses information
| typedef struct EMAC_IOCTL_CMD_RESP_s EMAC_IOCTL_CMD_RESP_T |
Emac IOCTL command response specification.
The packet structure defines the format of the IOCTL reponse message and is provivded inthe callback
| typedef struct EMAC_IOCTL_PARAMS_S EMAC_IOCTL_PARAMS |
IOCTL parameters field of emac_ioctl API.
Specififies IOCTL command parameters
| typedef struct EMAC_OpenConfigInfo_s EMAC_OpenConfigInfo |
Used to Initialize the Emac Driver Instance at time of emac_open.
TThis configuration structure is used to initialize the Emac Driver Instance. This configuration information is passed while opening the DRV instance
| typedef struct EMAC_PKT_DESC_s EMAC_PKT_DESC_T |
Emac packet descriptor specification.
The packet structure defines the basic unit of memory used to hold data packets for the EMAC device.
A packet is comprised of one or more packet buffers. Each packet buffer contains a packet buffer header, and a pointer to the buffer data. The EMAC_Pkt structure defines the packet buffer header.
The pDataBuffer field points to the packet data. This is set when the buffer is allocated, and is not altered.
BufferLen holds the the total length of the data buffer that is used to store the packet (or packet fragment). This size is set by the entity that originally allocates the buffer, and is not altered.
The Flags field contains additional information about the packet
ValidLen holds the length of the valid data currently contained in the data buffer.
DataOffset is the byte offset from the start of the data buffer to the first byte of valid data. Thus (ValidLen+DataOffet)<=BufferLen.
Note that for receive buffer packets, the DataOffset field may be assigned before there is any valid data in the packet buffer. This allows the application to reserve space at the top of data buffer for private use. In all instances, the DataOffset field must be valid for all packets handled by EMAC.
The data portion of the packet buffer represents a packet or a fragment of a larger packet. This is determined by the Flags parameter. At the start of every packet, the SOP bit is set in Flags. If the EOP bit is also set, then the packet is not fragmented. Otherwise; the next packet structure pointed to by the pNext field will contain the next fragment in the packet. On either type of buffer, when the SOP bit is set in Flags, then the PktChannel, PktLength, and PktFrags fields must also be valid. These fields contain additional information about the packet.
The PktChannel field detetmines what channel the packet has arrived on, or what channel it should be transmitted on. The EMAC library supports only a single receive channel, but allows for up to eight transmit channels. Transmit channels can be treated as round-robin or priority queues.
The PktLength field holds the size of the entire packet. On single frag packets (both SOP and EOP set in BufFlags), PktLength and ValidLen will be equal.
The PktFrags field holds the number of fragments (EMAC_Pkt records) used to describe the packet. If more than 1 frag is present, the first record must have EMAC_PKT_FLAGS_SOP flag set, with corresponding fields validated. Each frag/record must be linked list using the pNext field, and the final frag/record must have EMAC_PKT_FLAGS_EOP flag set and pNext=0.
In systems where the packet resides in cacheable memory, the data buffer must start on a cache line boundary and be an even multiple of cache lines in size. The EMAC_Pkt header must not appear in the same cache line as the data portion of the packet. On multi-fragment packets, some packet fragments may reside in cacheable memory where others do not.
<b> NOTE: It is up to the caller to assure that all packet buffers residing in cacheable memory are not currently stored in L1 or L2 cache when passed to any EMAC function. </b>
Some of the packet Flags can only be set if the device is in the proper configuration to receive the corresponding frames. In order to enable these flags, the following modes must be set: RxCrc Flag : RXCRC Mode in EMAC_Cpsw3gInitConfig RxErr Flags : PASSERROR Mode in EMAC_Cpsw3gInitConfig RxCtl Flags : PASSCONTROL Mode in EMAC_Cpsw3gInitConfig RxPrm Flag : EMAC_RXFILTER_ALL in CPSW_setReceiveFilter()


RT @codinghorror: Thinking about writing a book on parenting. It'll be titled "The Joys of Being a Fath-- AAH STOP BITING ME!"
4/13/2011, 9:50:06 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @codinghorror: Thinking about writing a book on parenting. It'll be titled "The Joys of Being a Fath-- AAH STOP BITING ME!"
4/13/2011, 9:50:06 AM
Favs: 0
Retweets: 0
link


WhatsApp Stat
Please Select A WhatsApp Chat Log File ( .txt ):
Choose File
Privacy:
Your File Is Processed Locally And Not Sent To Any Server
How To Export Your Whatsapp Chat Log
Save As Image
Made With
By
Rishabh Tripathi


|
Bullet Collision Detection & Physics Library
|
The btTransform class supports rigid transforms with only translation and rotation and no scaling/shear. More...
#include <btTransform.h>
Public Member Functions | |
| btTransform () | |
| No initialization constructor. More... | |
| btTransform (const btQuaternion &q, const btVector3 &c=btVector3(btScalar(0), btScalar(0), btScalar(0))) | |
| Constructor from btQuaternion (optional btVector3 ) More... | |
| btTransform (const btMatrix3x3 &b, const btVector3 &c=btVector3(btScalar(0), btScalar(0), btScalar(0))) | |
| Constructor from btMatrix3x3 (optional btVector3) More... | |
| btTransform (const btTransform &other) | |
| Copy constructor. More... | |
| btTransform & | operator= (const btTransform &other) |
| Assignment Operator. More... | |
| void | mult (const btTransform &t1, const btTransform &t2) |
| Set the current transform as the value of the product of two transforms. More... | |
| btVector3 | operator() (const btVector3 &x) const |
| Return the transform of the vector. More... | |
| btVector3 | operator* (const btVector3 &x) const |
| Return the transform of the vector. More... | |
| btQuaternion | operator* (const btQuaternion &q) const |
| Return the transform of the btQuaternion. More... | |
| btMatrix3x3 & | getBasis () |
| Return the basis matrix for the rotation. More... | |
| const btMatrix3x3 & | getBasis () const |
| Return the basis matrix for the rotation. More... | |
| btVector3 & | getOrigin () |
| Return the origin vector translation. More... | |
| const btVector3 & | getOrigin () const |
| Return the origin vector translation. More... | |
| btQuaternion | getRotation () const |
| Return a quaternion representing the rotation. More... | |
| void | setFromOpenGLMatrix (const btScalar *m) |
| Set from an array. More... | |
| void | getOpenGLMatrix (btScalar *m) const |
| Fill an array representation. More... | |
| void | setOrigin (const btVector3 &origin) |
| Set the translational element. More... | |
| btVector3 | invXform (const btVector3 &inVec) const |
| void | setBasis (const btMatrix3x3 &basis) |
| Set the rotational element by btMatrix3x3. More... | |
| void | setRotation (const btQuaternion &q) |
| Set the rotational element by btQuaternion. More... | |
| void | setIdentity () |
| Set this transformation to the identity. More... | |
| btTransform & | operator*= (const btTransform &t) |
| Multiply this Transform by another(this = this * another) More... | |
| btTransform | inverse () const |
| Return the inverse of this transform. More... | |
| btTransform | inverseTimes (const btTransform &t) const |
| Return the inverse of this transform times the other transform. More... | |
| btTransform | operator* (const btTransform &t) const |
| Return the product of this transform and the other. More... | |
| void | serialize (struct btTransformData &dataOut) const |
| void | serializeFloat (struct btTransformFloatData &dataOut) const |
| void | deSerialize (const struct btTransformData &dataIn) |
| void | deSerializeDouble (const struct btTransformDoubleData &dataIn) |
| void | deSerializeFloat (const struct btTransformFloatData &dataIn) |
Static Public Member Functions | |
| static const btTransform & | getIdentity () |
| Return an identity transform. More... | |
Private Attributes | |
| btMatrix3x3 | m_basis |
| Storage for the rotation. More... | |
| btVector3 | m_origin |
| Storage for the translation. More... | |
The btTransform class supports rigid transforms with only translation and rotation and no scaling/shear.
It can be used in combination with btVector3, btQuaternion and btMatrix3x3 linear algebra classes.
Definition at line 28 of file btTransform.h.
|
inline |
No initialization constructor.
Definition at line 38 of file btTransform.h.
|
inlineexplicit |
Constructor from btQuaternion (optional btVector3 )
| q | Rotation from quaternion |
| c | Translation from Vector (default 0,0,0) |
Definition at line 42 of file btTransform.h.
|
inlineexplicit |
Constructor from btMatrix3x3 (optional btVector3)
| b | Rotation from Matrix |
| c | Translation from Vector default (0,0,0) |
Definition at line 52 of file btTransform.h.
|
inline |
Copy constructor.
Definition at line 59 of file btTransform.h.
|
inline |
Definition at line 268 of file btTransform.h.
|
inline |
Definition at line 280 of file btTransform.h.
|
inline |
Definition at line 274 of file btTransform.h.
|
inline |
Return the basis matrix for the rotation.
Definition at line 108 of file btTransform.h.
|
inline |
Return the basis matrix for the rotation.
Definition at line 110 of file btTransform.h.
|
inlinestatic |
Return an identity transform.
Definition at line 197 of file btTransform.h.
|
inline |
Fill an array representation.
| m | A pointer to a 16 element array (12 rotation(row major padded on the right by 1), and 3 translation |
Definition at line 135 of file btTransform.h.
|
inline |
Return the origin vector translation.
Definition at line 113 of file btTransform.h.
|
inline |
Return the origin vector translation.
Definition at line 115 of file btTransform.h.
|
inline |
Return a quaternion representing the rotation.
Definition at line 118 of file btTransform.h.
|
inline |
Return the inverse of this transform.
Definition at line 182 of file btTransform.h.
|
inline |
Return the inverse of this transform times the other transform.
| t | The other transform return this.inverse() * the other |
Definition at line 222 of file btTransform.h.
Definition at line 215 of file btTransform.h.
|
inline |
Set the current transform as the value of the product of two transforms.
| t1 | Transform 1 |
| t2 | Transform 2 This = Transform1 * Transform2 |
Definition at line 76 of file btTransform.h.
Return the transform of the vector.
Definition at line 90 of file btTransform.h.
Return the transform of the vector.
Definition at line 96 of file btTransform.h.
|
inline |
Return the transform of the btQuaternion.
Definition at line 102 of file btTransform.h.
|
inline |
Return the product of this transform and the other.
Definition at line 230 of file btTransform.h.
|
inline |
Multiply this Transform by another(this = this * another)
| t | The other transform |
Definition at line 174 of file btTransform.h.
|
inline |
Assignment Operator.
Definition at line 65 of file btTransform.h.
|
inline |
Definition at line 256 of file btTransform.h.
|
inline |
Definition at line 262 of file btTransform.h.
|
inline |
Set the rotational element by btMatrix3x3.
Definition at line 154 of file btTransform.h.
|
inline |
Set from an array.
| m | A pointer to a 16 element array (12 rotation(row major padded on the right by 1), and 3 translation |
Definition at line 127 of file btTransform.h.
|
inline |
Set this transformation to the identity.
Definition at line 166 of file btTransform.h.
|
inline |
Set the translational element.
| origin | The vector to set the translation to |
Definition at line 146 of file btTransform.h.
|
inline |
Set the rotational element by btQuaternion.
Definition at line 160 of file btTransform.h.
|
private |
Storage for the rotation.
Definition at line 32 of file btTransform.h.
|
private |
Storage for the translation.
Definition at line 34 of file btTransform.h.


Contents
See the page for GRUB in LFS book.
The GRUB package provides GRand Unified Bootloader. In this page it will be built with UEFI support, which is not enabled for GRUB built in LFS.
This package is known to build and work properly using an LFS-10.1 platform.
Download (HTTP): https://alpha.gnu.org/gnu/grub/grub-2.06~rc1.tar.xz
Download MD5 sum: 3c222b51347c182d655f9b94d5b56582
Download size: 6.2 MB
Estimated disk space required: 592 KB
Estimated build time: 0.9 SBU
Unicode font data used to display GRUB menu
Download (HTTP): https://unifoundry.com/pub/unifont/unifont-13.0.06/font-builds/unifont-13.0.06.pcf.gz
Download MD5 sum: 4fbc33c8d8d25985f1bcdd4d28bc2420
Download size: 1.3 MB
User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/grub-efi
First, install font data as the root
user:
mkdir -pv /usr/share/fonts/unifont && gunzip -c unifont-13.0.06.pcf.gz > /usr/share/fonts/unifont/unifont.pcf
Unset any environment variables which may affect the build:
unset {C,CPP,CXX,LD}FLAGS
Don't try “tuning” this package with custom compilation flags: this package is a bootloader, with low-level operations in the source code which is likely to be broken by some aggressive optimizations.
Build GRUB with the following commands:
./configure --prefix=/usr \ --sbindir=/sbin \ --sysconfdir=/etc \ --disable-efiemu \ --enable-grub-mkfont \ --with-platform=efi \ --disable-werror && make
This package does not have a test suite providing meaningful results.
Now, as the root
user:
make install && mv -v /etc/bash_completion.d/grub /usr/share/bash-completion/completions
--enable-grub-mkfont
: Build
the tool named grub-mkfont to generate the font
file for the boot loader from the font data we've installed.
If the recommended dependency FreeType-2.10.4 is not installed, it is possible to omit this option and build GRUB. However, if grub-mkfont is not built, or the unicode font data is not avaliable at the time GRUB is built, GRUB won't install any font for the boot loader. The GRUB boot menu will be displayed using a coarse font and the early stage of kernel initialization will be in “blind mode” — you can't see any kernel messages before the graphics card driver is initialized. It will be very difficult to diagnose some boot issues, especially if the graphics driver is built as module.
--with-platform=efi
:
Ensures building GRUB with EFI enabled.
Using GRUB to make the LFS system bootable on UEFI platform will be discussed in Using GRUB to Set Up the Boot Process with UEFI.
See the page for GRUB in LFS book.
Last updated on 2021-02-21 03:35:58 +0800


This assignment is all my own work. I did not copy or rewrite the code from any other source except the code given in the assignment.
I have used JQuery basic functions for binding the function event calls, hide, show.I have used the javascript mdn documentation for sorting, finxdex and other javascripts events. Used the d3 documentation for d3 nest and other syntaxes. Below are some of the main links used for reference
http://www.cis.umassd.edu/~dkoop/dsc530-2017sp/a4/a4.html
http://www.cis.umassd.edu/~dkoop/dsc530-2017sp/a4/a4.js
https://dakoop.github.io/IntroD3/#1
https://developer.mozilla.org/en-US/docs/Web/JavaScript
Assign 2 for line chart
http://stackoverflow.com/questions/13242017/syntax-for-axis-transition-in-svg-d3
https://medium.com/@c_behrens/enter-update-exit-6cafc6014c36


Byte based writer for un-aligned bit streaming. More...
#include <encoding.h>
Public Member Functions | |
| bit_out (TEncoder &dest) | |
| ~bit_out () | |
| void | put_bit (unsigned value) |
| void | put_bits (unsigned value, unsigned count) |
| void | put_zero_bit () |
| void | put_zero_bits (register unsigned count) |
| void | gamma (unsigned value) |
| void | flush () |
Byte based writer for un-aligned bit streaming.
Definition at line 141 of file encoding.h.
| bm::bit_out< TEncoder >::bit_out | ( | TEncoder & | dest | ) | [inline] |
Definition at line 144 of file encoding.h.
| bm::bit_out< TEncoder >::~bit_out | ( | ) | [inline] |
Definition at line 148 of file encoding.h.
| void bm::bit_out< TEncoder >::flush | ( | ) | [inline] |
Definition at line 304 of file encoding.h.
| void bm::bit_out< TEncoder >::gamma | ( | unsigned | value | ) | [inline] |
Definition at line 229 of file encoding.h.
References BM_ASSERT, and bm::ilog2_LUT().
Referenced by bm::serializer< BV >::gamma_gap_array().
| void bm::bit_out< TEncoder >::put_bit | ( | unsigned | value | ) | [inline] |
Definition at line 154 of file encoding.h.
References BM_ASSERT.
| void bm::bit_out< TEncoder >::put_bits | ( | unsigned | value, | |
| unsigned | count | |||
| ) | [inline] |
Definition at line 162 of file encoding.h.
| void bm::bit_out< TEncoder >::put_zero_bit | ( | ) | [inline] |
Definition at line 195 of file encoding.h.
| void bm::bit_out< TEncoder >::put_zero_bits | ( | register unsigned | count | ) | [inline] |
Definition at line 201 of file encoding.h.


{% extends "layout.html" %} {% block heading %} Welcome {{name}}, You can search for books in the following three ways {% endblock %} {% block body %}
Please select one of the following methods to search for books


This is simply a collection of things I've done in order to improve my JavaScript and CSS skills and to get some experience with some of the available libraries. It is not meant to be a definitive guide or reference to these techniques and libraries.


“I am particularly interested in students coming to us from low-income families and low-participation neighbourhoods. I think we would be incredibly proud if we could bring even more students from all backgrounds...Mark Regev, spokesperson for the Israeli prime minister's office


{% load static %}
This is a simple demonstration of my completion of the official django introduction tutorial.


The chr function is used to convert an integer to a character.
The character is the i-th character of the ASCII sequence of
characters (except on the IBM mainframe, which uses the EBCDIC
sequence.) For example, chr (65) is "A".
The ord function is the inverse of chr, so for any
character c,:
chr(ord (c)) = c.
Details
There are two sets of characters representing values 128-255: the
ANSI values (the default values for Windows), and the MS-DOS OEM
character set, which contains various line drawing characters. To
use the MS-DOS character set, you must use the
setscreen ("msdos") command.
Example
Another example is available that displays the entire characters
set, both the regular ANSI character set and the MS_DOS OEM
character set.


ScopeLookup Enumerated Type
Definition
Line
8
of
cppsymbols/Scope.cm
Underlying Type
int
Enumeration Constants
none
0
this_
1 << 0
parent
1 << 1
bases
1 << 2
this_and_parent
this_ | parent
this_and_bases
this_ | bases
this_and_bases_and_parent
this_ | bases | parent


Just a "p"; No container classes = no padding etc. Preset 8 strength shadow
With a header and in w3-container classes, which provides the right padding. No border.
With a header and footer and in w3-container classes, which provides the right padding... also uses w3-hover-shadow
Footer info here


Experiment Chains
CHAINS
is a Common Lisp system for constructing an experiment chain
in which a number of tasks are executed to produce a result. Its main
purpose is to accommodate scenarios where the line between a
scientific experiment and algorithmic experimentation is blurred.
Table of Contents
1 A Backstory
This section outlines the main use case for the CHAINS
system. The
abstraction the CHAINS
system employs is rather strange when
introduced on its own. Hopefully this section aids in understanding
why. The example presented in this section is real, and is the primary
reason for the existence of the CHAINS
system.
An important problem in the field of computer vision is that of congealing. The task of congealing is very simple, discover the location of an object contained in an ensemble of images. A key trait of congealing algorithms is that they know nothing about the object in each image, other than it can be assumed that the object is present in each image. A concrete example of congealing would be, given an ensemble of images containing faces, find me the bounding box of each face.
When evaluating a congealing algorithm one must evaluate the algorithm against the following criteria
- Level of initial misalignment
- How far away from the true location can then algorithm correctly locate the object?
- Lighting variation
- How does the algorithm handle variation in appearance due to illumination conditions?
- Image noise
- How does the algorithm handle variation in appearance due to image noise?
- Appearance variation
- How does the algorithm handle variation in appearance of the object? For faces, this would mean male versus female, beard versus non-beard, and so on.
- Occlusion
- How does the algorithm handle cases where the object is occluded by another object? e.g. a face occluded by hair, glasses or another object.
- Ensemble size
- How does the number of images in the ensemble influence performance?
- Cross validation on images
- Testing performance on another ensemble of images with exactly the same statistics.
- Cross validation on geometry
- Testing performance on the same collection of images but with different random starting locations.
It is fine if you do not understand all of the above. The key point is that they are variables or statistics measured on the ensemble of images fed to the congealing algorithm. Congealing algorithms behave differently depending on the value of each variable. In fact, even a different ensemble with the same statistics can cause algorithms to behave differently.
In addition to variables associated with the input data, a congealing algorithm typically has a number of parameters that influence its own behaviour. These parameters have a range of values that are "worth" trying, with the best value selected at the end by some means.
One also must compare the algorithm against another algorithm on exactly the same image ensemble. Having exactly the same ensemble is extremely important as a strategically chosen change can have a dramatic effect on performance for some algorithms.
Once all of the algorithms are executed, a results collation process begins. The results obtained depend on the report or paper that is being written. These results may involve performance conditioned on the statistics of the image ensemble, or the amount of influence an algorithm parameter has on the overall algorithm performance.
Everything up to this point is straight forward. You prepare the image ensemble to be fed to all congealing algorithms, execute each algorithm, prepare the results and then write the report/paper. Easy.
Unfortunately, this rarely occurs in practice. In practice, one implements an algorithm that has been published. Upon experimenting (or implementing) with the algorithm, it is discovered that there is something that could be improved. For example, the algorithm cannot handle image ensembles with certain statistics or the algorithm is really sensitive to a particular parameter or the algorithm is flawed in some manner. With this new information, the goal now is to empirically confirm the identified problem and design a new algorithm that can overcome the identified problem.
Immediately we see that the algorithm and the experiments to be performed are not concrete. One typically creates many algorithms that may "do the job", but one does not know whether it is an idea worth investigating further until it has been implemented and a preliminary set of results are obtained. Additionally, the type of results required may change depending on the point needed to be made.
What a scientist wants to work on is the algorithm. That is what is important. That is what is publishable. The experiment stuff validates the argument for the algorithm, but it is not the primary focus.
Saying it is not of primary focus is rather ironic. The experiment design partly led to the discovery. The experiment design also empirically validates a new discovery. Furthermore, it is the experiment design where much of a computer scientist's effort is spent and it is to easy to see why.
The problem with experiments is that they take time to implement and to execute. The long execution time is because the number of experiments is a combinatorial function defined by the number of values specified for each experiment parameter. i.e. if you have a large number of experiment parameters and a large number of values per experiment parameter then you have an extremely large number of experiments. Fortunately, since the experiments are independent, they can be executed in parallel. Well, not quite in parallel as described later, but the experiment execution problem does belong to the class of embarrassingly parallelisable problems.
Another difficulty is collating results. When writing a report or a paper, one typically needs additional graphs (or tables, but who likes tables?) that were not thought of initially. To accommodate this use case, the output of the experiments should be saved in order to save (valuable) time. This serialisation not only applies to the algorithm output and input, but for all data computed in the experiment.
This database of serialised experiment data also needs to have the ability to be queried. This ability is needed by the results collation step mentioned previously.
All of this is simple to state, but is moderately difficult to implement and very easy to make simple mistakes which are hard to identify. Moreover, the pipeline for conducting experiments is similar across many domains. Writing something again and again is not a smart use of one's time. Additionally, the code that performs the experiment setup, execution and result collation very rarely receives the level of attention and care that algorithms receive. In my local minima which is termed life, I have not seen released code that just performs experiments. Why? Great question.
The CHAINS
system attempts to provide facilities for the above tasks
in order for the scientist to spend more time on developing an
understanding of existing algorithms and to develop new algorithms
that overcome identified issues.
Lastly, the CHAINS
system is not a plug and play work flow optimiser
where one only performs plumbing. It should not be a dependency in
your algorithm implementations. The only place where the CHAINS
system should be used is in verifying and validating an algorithm's
performance on different types of data and collating algorithm results
for some sort of publication.
2 Concepts and mental models
The background section painted a picture of the aspects of the problem
the CHAINS
system attempts to address. This section illustrates more
of the core concepts and code that underpin the library.
Performing a single experiment is really the serial execution of a number of tasks. For the congealing problem outlined above, the high-level tasks are as follows
The input data task is responsible for creating the ensemble of images fed to the algorithm. Once the algorithm has provided an estimate of the object's position, this position is then compared to the ground truth using a metric. The metric provides a quantitative measure of the algorithm's performance.
This linking of tasks to be executed is termed a task chain, or just a chain.
A collection of experiments to be executed is really a tree. Consider the following figure where there are two congealing algorithms being evaluated on two different sets of input data.
The above figure presents two trees which start from an input data
task. The CHAINS
system inserts a "start here" root task in order to
produce a single tree. A key property of the above tree is that a path
from the root task to a leaf represents a single experiment or task
chain.
The tree view of the experiments also highlights the parallelism of the experiment execution. Once a task is completed, all of its children can now be executed in parallel.
The CHAINS
system does not limit the length of the chain, nor is
there any requirement that all leaves should have the same distance to
the root task. In fact the CHAINS
system does not provide any
default tasks as tasks are fundamentally problem specific.
Another important characteristic of tasks is the way they
interact. The CHAINS
system assumes that a task can only depend on
output from previous tasks in the chain. This is shown in the next
figure for the congealing problem.
As you can see, the input to the algorithm requires data from the
task(s) that synthesize the image ensemble and the task(s) that
synthesize the initial guess. The above diagram is obviously no longer
a chain, it is a directed graph. How the CHAINS
system models the
above graph is by distinguishing between the operation to be performed
and the input and output of that operation. This distinction is made
to encourage the creation of reusable tasks. How tasks form a chain is
dependent on the experiment design and is by definition not reusable
across designs.
We now turn to implementing the above graph. The macro DEFINE-TASK
is used to create a new task class. The "Algorithm" task in the above
diagram would be defined using the following code
(define-task algorithm () ((sigma :initarg :sigma :reader sigma)))
where SIGMA
is some parameter for the algorithm. The DEFINE-TASK
macro is like DEFCLASS
but with some features removed. Its purpose
is to hide away the details of how tasks are implemented. Facilities
for the programmatic creation of new task classes are provided
e.g. ENSURE-TASK
.
When a task is performed, the task's operation is executed. Before outlining how to define a task's operation, lets outline what an operation is. An operation can be understood as being a method like so
(defmethod perform-task ((task task-class) chain) ;; Obtain task inputs (let ((var-a (compute-task-input :input-a (find-class 'task-class) chain)) (var-b (compute-task-input :input-b (find-class 'task-class) chain))) ;; Task Body ...))
where CHAIN
is a list of tasks that have already been performed. As
you can see, a task can only have one operation i.e. the performed
tasks in CHAIN
have no effect on the operation. How the performed
tasks in the chain influence the operation is via the task's
inputs. Computing the value of these inputs is performed using the
hypothetical function COMPUTE-TASK-INPUT
. It is the inputs to the
task's operation that depend on the already performed tasks. This is
how the CHAINS
system connects tasks to form a graph.
The operation for the "Algorithm" task would be implemented as follows
in the CHAINS
system.
(define-task-input ensemble-images) ;; The images fed to the algorithm (define-task-input initial-guess) ;; The initial guess of the object's location (define-operation (object algorithm) ((images ensemble-images) (guess initial-guess)) (perorm-congealing images guess :sigma (sigma object)))
We begin with the DEFINE-OPERATION
form where the expression
(OBJECT ALGORITHM)
corresponds to the task specialization in the
PERFORM-TASK
method example. The second argument to
DEFINE-OPERATION
is a list of the inputs required by the task. Each
item in this list must be a list of two symbols. The first symbol is a
variable the operation body can use to access the value of the task
input. The second symbol represents the name of the task input that
the task needs to perform its operation.
Each task input specified in DEFINE-OPERATION
must have been
declared using DEFINE-TASK-INPUT
. It is important to understand that
a task input is not a class, it is special type of function provided
by the CHAINS
system. This special function dispatches on the tasks
found in the CHAIN
and the task that is about to be performed.
Before detailing how to add "methods" or TASK-INPUT-FUNCTIONS
to a
TASK-INPUT
, we first create the tasks responsible for controlling
the image ensemble and the initial guess.
(define-task basic-ensemble () (number-of-subjects samples-per-subject)) (define-task initial-guess/similarity-transform () (scale rotation translation))
With the above tasks, we are now ready to define the task input
functions using DEFINE-TASK-INPUT-FUNCTION
for the algorithm
operation.
(define-task-input-function ensemble-images algorithm ((data basic-ensemble)) (task-value data)) (define-task-input-function initial-guess algorithm ((data initial-guess/similarity-transform)) (task-value data))
The first argument to DEFINE-TASK-INPUT-FUNCTION
is the name of the
task input that the function is to be added to. The second argument
refers to the task that is about to be performed, termed the target
task or target class. The third argument represents the performed
tasks needed to compute the value to be used as input. All forms after
the third argument represent the body of the task input function. The
value (values are unsupported) of the last evaluated form is what is
fed to the operation.
The function TASK-VALUE
returns the result of executing a tasks'
operation, in this case the result of
INITIAL-GUESS/SIMILARITY-TRANSFORM
task.
The rules for computing which task input function is to be used to compute a value are currently defined as
- the most specific target task
- the most recent performed task
- the most specific performed task
This is obviously a partial definition. At the time of writing it is
not clear what the defaults should be and I am interested in getting
feedback from users. Because of this, there is no such
CALL-NEXT-FUNCTION
local function like there is with generic
functions and methods with the local function CALL-NEXT-METHOD
.
3 Serialisation
The default serialisation strategy employed in the CHAINS
system is
a very simple system requiring only the lisp pretty printer and files
and directories on the storage device.
Each node of an experiment tree has its own directory in order to
store the task parameters, the task value generated by a task's
operation and other task specific data. The name of this directory is
computed using the function TASK-STRING
.
(defgeneric task-string (task))
A default implementation of TASK-STRING
exists for all tasks. Example
output for the task is as follows
(define-task example-task () ((sigma :initarg :sigma :reader sigma) (rho :initarg :rho :reader rho))) (task-string (make-instance 'example-task :sigma 0.5 :rho 1.1)) ;; "example-task-0.5-1.1"
Note that the slot values for the task's superclasses precede the slot values for the subclass.
Serialisation of tasks is performed using the function
SERIALISE-TASK
. This function produces a string that when read and
evaluated creates a new instance of the task which is considered
equal to the task that was serialised.
(defun serialise-task (stream task))
SERIALISE-TASK
iterates through all slots of the task,
transforming each slot value in to an s-expression which evaluates to
an equal object. Customisation of the generated expression for a
given object is provided by the OBJECT-SEXP
generic function.
(defgeneric object-sexp (object))
If no OBJECT-SEXP
method exists for OBJECT
, then the object will
be serialised using PRINT-OBJECT
with *PRINT-READABLY*
bound to
T
.
4 Querying
Querying a set of experiments is critical to the collation of results.
The function CONTAINS-TASK-P
can be used to determine if a chain
contains a task that is a subclass of TASK-CLASS
.
(defun contains-task-p (chain task-class))
The function FIND-CHAINS-WITH-TASK
returns all chains in which
CONTAINS-TASK-P
is T
for the given task.
(defun find-chains-with-task (chains task-class))
Another important function is GROUP-BY
, which can group chains
together according to given a test.
(defun group-by (sequence test &key key))
In practice, the GROUP-BY
function is needed so frequently and
coupled so tightly with the tasks, that a special function
GROUP-CHAINS
is provided. The GROUP-CHAINS
function works in
conjunction with information specified when creating a new task class.
(defun group-chains (chains expression &key sort inner-sort))
An EXPRESSION
is a form which is used to synthesize a predicate
which is used to compare two chains. Valid expressions are
symbol
- Find two tasks, one from each chain, whose classes are
EQUAL
and of typeSYMBOL
. e.g. all congealing algorithm tasks inherit fromALGORITHM
, thus specifying(quote ALGORITHM)
would group all chains that use the same algorithm. (= symbol :static)
- Find two tasks, one from each chain, which
are of type
SYMBOL
and are equal according to the predicate for the task classSYMBOL
. (= symbol :dynamic)
- Find two tasks, one from each chain, whose
classes are
EQUAL
, are of typeSYMBOL
, and are equal according to the task predicate for the found task class. (= symbol)
- Find two tasks, one from each chain, which are of
type
SYMBOL
and are equal according to the predicate for the task classSYMBOL
. An error is signaled if a task is found which is a subclass ofSYMBOL
. (= symbol name)
- This expression specifies that the chains
within a group all have the same value for the slot
NAME
in the task with typeSYMBOL
. (and &rest expressions)
- This expression specifies that all the
chains in a single group satisfy all
EXPRESSIONS
.
The last two expressions do not explicitly refer to the predicate
=
. The actual predicate used is obtained from the :PREDICATES
slot
definition argument used within DEFINE-TASK
(define-task geometric-cross-validation () ((sample :initarg sample :reader sample :predicates number :documentation "The index of the random sample.")))
Predicates represent a collection of comparison functions for a
specific type of value. The predicates for the built-in NUMBER
are
defined as follows
(define-predicates number #'= #'< #'>)
Other built-in predicates are STRING/CASE-SENSITIVE
and
STRING/CASE-INSENSITIVE
.
(define-predicates string/case-sensitive #'string= #'string< #'string>) (define-predicates string/case-insensitive #'string-equal #'string-lessp #'string-greaterp)
The keyword arguments SORT
and INNER-SORT
of the GROUP-CHAINS
function perform sorting of the groups and the chains within the
groups respectively according to a specified sort expression. A sort
expression can be one of
(> symbol name)
- Like the
=
expression previously, but using theTEST>-FUNCTION
predicate. (< symbol name)
- Similar to the
>
expression. (:classes &rest task-class-names)
- Order tasks according to
their order of appearance in
TASK-CLASS-NAMES
. It is an error if a task is found which does not inherit from any class inTASK-CLASS-NAMES
.
If the same expression and sort expression arguments are being
repeatedly passed to GROUP-CHAINS
consider using the function
PREPARE-GROUP-CHAINS
.
(defun prepare-group-chains (expression &key sort inner-sort))
This function returns a new function that accepts a single argument which are the chains to be grouped and sorted.
5 Generating
This section outlines the process of generating and documenting a set of experiments.
Creating a set of experiments requires two steps. The first step is
specifying the experiment design using the DEFINE-DESIGN
macro. The
second step is generating the experiment tree using the function
GENERATE
. It is important to understand that the design document
only contains the information needed to generate the tree, it does not
contain the experiments themselves.
The macro DEFINE-DESIGN
is as follows
(defmacro define-design (name design-options &body levels))
The argument NAME
is a symbol naming the design that is being
defined. DEFINE-OPTIONS
is a list of design options that will be
covered throughout this section. The important argument, LEVELS
,
contains information about the hierarchy of the tree.
The following diagram is used to illustrate the LEVELS
argument in
DEFINE-DESIGN
The first item of LEVELS
, level 0, contains information about
generating the children of the root node. In other words, the children
of the root node represent the first tasks to be executed in each
experiment chain. The second item of LEVELS
contains information
about generating the children for each of the children in
level 0. In essence, a level represents the tasks that are to be added
to all leaves in the tree constructed from the previous levels.
Each element of LEVELS
is a level definition expression. Examples of
these forms can be seen in an example design used for the congealing
problem
(define-design congealing ((:documentation "A set of experiments for the paper XYZ.")) ;; Images ((image-appearance-and-lighting (:lighting-variation 0 0.1 0.2 0.3 0.4) (:number-of-subjects 1 2 5 10 20) (:samples-per-subject 1 5 10))) ((image-cross-validation (:sample (:splice (loop :for x :from 0 :below 10 :collect x))))) ((synthetic-occlusion (:count 0 1 2) (:size 0.5 0.1 0.2))) ;; Initial guess of object location ((distance-away-from-ground-truth (:distance 2 5 10 15))) ((geometric-cross-validation (:sample 0 1 2))) ;; Algorithms to be executed ((learned-miller (:deltas '(1 1 0.1 0.1 1 1))) least-squares-congealing rasl) ;; Results to be computed. (alignment-performance))
A level definition is a list containing generate expressions, where a generate expression specifies the tasks to generate. When the tasks for each generate expression have been generated, they are appended together to form the list of tasks that are to be appended to each leaf in the current experiment tree.
Lets consider the generate expression used as the level 0 definition in the above example.
(image-appearance-and-lighting (:lighting-variation 0 0.1 0.2 0.3 0.4) (:number-of-subjects 1 2 5 10 20) (:samples-per-subject 1 5 10))
This states that the following list of tasks are to be generated.
(list (make-instance 'image-appearance-and-lighting :lighting-variation 0 :number-of-subjects 1 :samples-per-subject 1) (make-instance 'image-appearance-and-lighting :lighting-variation 0.1 :number-of-subjects 1 :samples-per-subject 1) ... (make-instance 'image-appearance-and-lighting :lighting-variation 0.4 :number-of-subjects 20 :samples-per-subject 10))
Thus there exists an instance of the task
IMAGE-APPEARANCE-AND-LIGHTING
for every permutation of the argument
values for the slots :LIGHTING-VARIATION
, :NUMBER-OF-SUBJECTS
and
:SAMPLES-PER-SUBJECT
.
The previous generate expression illustrates some basic functionality. The generate expression for level 1 illustrates some more advanced capabilities.
(image-cross-validation (:sample (:splice (loop :for x :from 0 :below 10 :collect x))))
The :SPLICE
keyword operator evaluates the form (loop :for x :from 0 :below 10 :collect x)
and splices it in place to produce the
following equivalent expression.
(image-cross-validation (:sample 0 1 2 3 4 5 6 7 8 9))
It should be noted that the evaluation only occurs during GENERATE
and not when the design is created.
The expression involving the algorithms represents the following children
(list (make-instance 'learned-miller :deltas '(1 1 0.1 0.1 1 1) :maximum-number-of-iterations 100) (make-instance 'least-squares-congealing :maximum-number-of-iterations 10) (make-instance 'rasl :maximum-number-of-iterations 10))
A special generate expression (:design design-name)
is provided to
allow trees with leaves at different depths. For example, the
CONGEALING
design could be written as follows.
(define-design congealing/input-data ...) (define-design congealing/algorithms ...) (define-design congealing/results ...) (define-design congealing (:documentation "The complete set of experiments for congealing.") ((:design congealing/input-data)) ((:design congealing/algorithms)) ((:design congealing/results)))
The function GENERATE
is used to create the experiments defined with
the DEFINE-DESIGN
macro.
(defun generate (design-name))
This function returns a TREE
containing the entire collection of
generated experiments.
6 Executing
Before a tree of experiments is executed, an area to store the results
must be prepared. The function PREPARE-DIRECTORY
performs this task.
(defgeneric prepare-directory (directory &key if-exists))
The argument IF-EXISTS
determines what to do if there exists tasks
in DIRECTORY
that would be overwritten. IF-EXISTS
can be one of
:ERROR
or :SKIP
.
In order to execute a single task of a chain you use the function
PERFORM-LEAF
.
(defun perform-leaf (area chain &key force &allow-other-keys))
The AREA
argument specifies a prepared area in which to store the
results. The CHAIN
argument is the chain whose leaf is to be
executed. The keyword argument FORCE
specifies that the task should
be executed, overwriting any existing values.
An operation can obtain the value of the FORCE
argument via the
FORCEDP
function. Other keyword arguments passed to PERFORM-LEAF
can be retrieved using the function OPERATION-PLIST
.
(defun operation-plist ())
Whilst PERFORM-LEAF
is on the call stack, a number of useful
functions can be used within the body of operations and task input
functions. These are
(defun task-data-directory (task)) ;; The directory where any data for TASK is stored. (defun task-value (task)) ;; The value of the result computed for TASK.
When an operation is performed, the dynamic variable
*DEFAULT-PATHNAME-DEFAULTS*
is set to the output of
TASK-DATA-DIRECTORY
on the executing task.
Associated with the PERFORM-LEAF
function is the function
PERFORM
. This function executes all tasks in the chain.
(defun perform (area chain &key force &allow-other-keys))
6.1 Execution parameters
The above execution model works well for most tasks. There is a class of tasks which unfortunately do not fit this model and require special attention.
The class of tasks are those that execute an iterative algorithm whose output is continually reprocessed until some sort of criteria is met e.g. non-linear optimisation.
It is tempting to define a task class like this
(define-task iterative-algorithm ()
((number-of-iterations
...)))
The problem with this is that you are implicitly assuming that
NUMBER-OF-ITERATIONS
is the maximum number of iterations that you
will ever need to execute. If you change NUMBER-OF-ITERATIONS
, then
the task has to start from the beginning because the TASK-NAME
will
change.
More importantly, NUMBER-OF-ITERATIONS
is not an experiment
parameter. It does change the result of the task, but it is not a
measure like the amount of appearance variation experiment measure
found in congealing.
The recommended way of implementing these types of tasks is to introduce this execution parameter as a dynamic variable.
(defvar *number-of-iterations* 10)
The value of this parameter represents a default value. Alongside this
dynamic variable should be a function which checks OPERATION-PLIST
to see if an alternate value is specified, otherwise revert to the
default.
(defun number-of-iterations () (or (getf (operation-plist) :number-of-iterations) *number-of-iterations*))
Obviously, specifying the number of iterations to execute impacts the
CHAINS
system's method of determining whether a task is finished or
not. The generic function responsible for determining whether a task
has been completed is the function TASK-COMPLETED-P
.
(defgeneric task-completed-p (task))
Just like PERFORM-LEAF
, the value of *DEFAULT-PATHNAME-DEFAULTS* ~TASK-DATA-DIRECTORY
is bound to the value of TASK-DATA-DIRECTORY
.
This method can be implemented for a specific task which checks that the correct number of iterations have been executed.
(defmethod task-completed-p ((task iterative-algorithm)) (and (probe-file (iteration-output task (number-of-iterations))) (call-next-method)))
The operation for the task is then responsible for finding the correct output to reprocess.
7 Obtaining Results
Now that all chains in an experiment design have been executed and
queried and sorted, it is time to retrieve values. This requires an
AREA
object and the two functions TASK-DATA-DIRECTORY
and
TASK-VALUE
.
(defun task-data-directory (task &optional chain area)) (defun task-value (task &optional chain area))
The dynamic variables *CHAIN*
and *AREA*
are provided as default
values for the chain and area arguments respectively.
The value of the TASK
argument can be one of the following
- Instance of type
TASK
- The instance must be present in the
CHAIN
argument. - Instance of type
TASK-CLASS
- Find a task instance in chain whose
type is a subclass of
TASK-CLASS
. - Symbol
- The name of a
TASK-CLASS
. - Function
- Find an object in chain for which the function returns non-NIL.
8 Parallel Execution Environments
This section outlines the functionality of the CHAINS.PEE
package.
As stated previously, when a task in an experiment has completed its
operation, all of that task's children can be executed in
parallel. The function PARALLEL-PERFORM
performs this task for you
for a given TREE
and AREA
.
(defun parallel-perform (area tree &rest args &key force &allow-other-keys))
The dynamic variable *NUMBER-OF-PROCESSES*
controls the number of
threads that PARALLEL-PERFORM
uses to execute the TREE
.
There also exists support for generating a command line program which
can be invoked by xargs
or a distributed computing environments like
the Oracle Grid Engine or PBS/Torque.
At the heart of this functionality is the DEFINE-PROGRAM
macro which
provides the ability to define a new executable which simply invokes
PERFORM-LEAF
.
(define-program experiments ((number-of-iterations :documentation "The number of congealing algorithm iterations to perform." :argument ("iterations" (integer 0)))))
The above specification defines a program that when generated has the following help message
$ ./program --help Usage: [options] [custom options] <data> <depth> <leaf number> Options: --help This helpful message. --force Overwrite any existing output. Custom Options: --number-of-iterations <iterations> The number of congealing algorithm iterations to perform. <data> Information needed to execute a tree of tasks. <depth> The depth of the tasks that are to be executed. <leaf number> The index of the leaf at <depth> that is to be executed.
The DEFINE-PROGRAM
macro provides a very thin wrapper over
LISP-EXECUTABLE:DEFINE-PROGRAM
. With the program defined,
LISP-EXECUTABLE
's integration with ASDF can be used to build the
executable.
DEFINE-PROGRAM
also accepts option arguments. The only option
supported at present is the :PROLOGUE
option. This option allows for
some arbitrary code to be executed prior to performing the task.
(define-program example-of-prologue () (:prologue (setf *random-state* (make-random-state t))))
The <data>
argument to the command line program produced by
DEFINE-PROGRAM
is created using the function WRITE-PROGRAM-DATA
.
(defun write-program-data (pathname area tree))
This function requires the AREA
and the values stored in TREE
to
have implemented the OBJECT-SEXP
method.
One can invoke the generated executable manually, however, there are functions which generate shell scripts which perform the necessary invocations of the program to execute an entire tree.
8.1 Sun / Oracle Grid Engine
The function PREPARE-OGE-SCRIPT
is used to produce scripts which use
the Oracle Grid Engine to invoke a specified program.
(defun prepare-oge-script (directory area tree program &key (if-exists :error) (output "stdout/") (error :output)))
DIRECTORY
is the location to store the generated files, AREA
is a
prepared area, TREE
is the tree to be executed and PROGRAM
is the
pathname to the generated program or a list containing the path to a
LISP-EXECUTABLE:EXECUTABLE
component in an ASDF system.
The files generated in DIRECTORY
are as follows
oge.sh
- The script to be executed on the job submission host.
oge-program.sh
- A thin wrapper over the executable pathname which extracts information from the grid engine.
oge-program-arguments
- A user editable file for passing command line arguments to the program.
oge-arguments
- A user editable file for passing command line arguments to the grid engine scheduler.
oge-data.sexp
- The file containing the area and tree to be executed by the grid engine.
The keyword argument IF-EXISTS
in PREPARE-OGE-SCRIPT
specifies
what to do if any of the above files exist. Valid values are
:ERROR
- Signal an error if any of the above files exist.
:SUPERSEDE
- Overwrite
oge.sh
,oge-program.sh
andoge-data.sexp
. Do not touchoge-program-arguments
andoge-arguments
. :SUPERSEDE-ALL
- Overwrite all of the above files.
The keyword arguments OUTPUT
and ERROR
specify what to do with the
data written to standard output and standard error for each task. The
OUTPUT
argument accepts a directory pathname designator which
represents the directory in which to store the output of each
task. The ERROR
argument is like the OUTPUT
argument, but it is
permitted to pass the keyword :OUTPUT
. The keyword :OUTPUT
states
that the standard error stream is joined to the standard output
stream.
The default contents for the files oge-program-arguments
and
oge-arguments
are obtained from the dynamic variables
*OGE-PROGRAM-ARGUMENTS-STRING*
and *OGE-ARGUMENTS-STRING*
respectively.
8.2 xargs
The function PREPARE-XARGS-SCRIPT
is like PREPARE-OGE-SCRIPT
, but
it prepares a script that uses xargs(1)
as the scheduler.
(defun prepare-xargs-script (directory area tree program &key (if-exists :error)))
DIRECTORY
is the location to store the generated files, AREA
is a
prepared area, TREE
is the tree of experiments to be executed and
PROGRAM
is the pathname to the generated program or a list
containing the path to a LISP-EXECUTABLE:EXECUTABLE
component in an
ASDF system.
The files generated in DIRECTORY
are as follows
xargs.sh
- The script which invokes
xargs(1)
to run all of the experiments. xargs-program.sh
- A shell script which incorporates any
arguments in
xargs-program-arguments
in to the invocation ofPROGRAM
. xargs-program-arguments
- A user editable file for passing
command line arguments to
PROGRAM
. xargs-arguments
- A user editable file for passing command line
arguments to
xargs
. xargs-data.sexp
- A file containing the area and tree to be executed.
The keyword argument IF-EXISTS
in PREPARE-XARGS-SCRIPT
specifies
what to do if any of the above files exist. Valid values are
:ERROR
- Signal an error if any of the above files exist.
:SUPERSEDE
- Overwrite
xargs.sh
,xargs-program.sh
andxargs-data.sexp
. Do not touchxargs-program-arguments
andxargs-arguments
. :SUPERSEDE-ALL
- Overwrite all of the above files.
The default contents for the files xargs-program-arguments
and
xargs-arguments
are obtained from the dynamic variables
*XARGS-PROGRAM-ARGUMENTS-STRING*
and *XARGS-ARGUMENTS-STRING*
respectively.
8.3 PBS / Torque
The function PREPARE-PBS-SCRIPT
is like PREPARE-OGE-SCRIPT
, but it
prepares a script that invokes the PBS command qsub
.
(defun prepare-pbs-script (directory area tree program &key (if-exists :error) (output "stdout/") (error :output)))
DIRECTORY
is the location to store the generated files, AREA
is a
prepared area, TREE
is the tree of experiments to be executed and
PROGRAM
is the pathname to the generated program or a list
containing the path to a LISP-EXECUTABLE:EXECUTABLE
component in an
ASDF system.
The files generated in DIRECTORY
are as follows
pbs.sh
- The script which invokes
qsub
. pbs-program.sh
- A shell script which incorporates any
arguments in
pbs-program-arguments
in to the invocation ofPROGRAM
. pbs-program-arguments
- A user editable file for passing
command line arguments to
PROGRAM
. pbs-arguments
- A user editable file for passing command line
arguments to
qsub
. pbs-data.sexp
- A file containing the area and tree to be executed.
pbs-script-*.sh
- An intermediary shell script which invokes
pbs-program.sh
for a specific depth ofTREE
. These shell scripts are required due to limitations in Torque's implementation of PBS.
The keyword argument IF-EXISTS
in PREPARE-PBS-SCRIPT
specifies
what to do if any of the above files exist. Valid values are
:ERROR
- Signal an error if any of the above files exist.
:SUPERSEDE
- Overwrite
pbs.sh
,pbs-program.sh
andpbs-data.sexp
. Do not touchpbs-program-arguments
andpbs-arguments
. :SUPERSEDE-ALL
- Overwrite all of the above files.
The default contents for the files pbs-program-arguments
and
pbs-arguments
are obtained from the dynamic variables
*PBS-PROGRAM-ARGUMENTS-STRING*
and *PBS-ARGUMENTS-STRING*
respectively.


Nokia and Sendai City test drones in tsunami disaster scenario
by StipeA few days ago, Nokia partnered with the YouTuber Mr.Whosetheboss to showcase what the Finnish network gear vendor has been doing in regards to drones. For quite some time Nokia has been mentioning drones and how they use them in network inspection, and our Marin back at MWC19 even asked the people at Nokia why didn’t they have drones flying at their booth and they said they didn’t get a permit from GSMA to do it.
In a recent press release, Nokia announced that it successfully tested drones in disaster scenarios with the city of Senda in Japan, that was hit by a devastating tsunami back in 2011. In a disaster simulation, Nokia drones used speakers to guide survivors and broadcast emergency messages, and thermal and HD cameras for monitoring.
For this test Nokia set up a private LTE network using its “plug and play” digital automation cloud technology. Nokia’s 4G mission critical network is ideal in such situation because it’s fast to set up and more secure (and reliable) than WiFi.
Drones can often go where evacuation teams can’t and Nokia’s dron is even capable of delivering smaller packages, which can be extremely handy is such worst case scenarios.
Source: Nokia


#001 Bulbasaur
Grass
Poison
Weight: 0kg
Height: 0m
Color: Green
Footprint:
Bodytype:
HP:
45
Attack:
49
Defense:
49
Sp. Attack:
65
Sp. Defense:
65
Speed:
45
X
>
<


Savegame Editor
for Rhythm Paradise/Heaven Megamix
by
Marc Robledo
See on GitHub
Donate
Close file
Save changes
Basic
Coins
Onions
Flow balls
Silver onions
Gold onions


Upload Meeting Minutes
General notes, terminology and policies
- There are two environments in which you can work;
- The sandbox environment is where you can test and try things out to familiarize yourself with the steps you will be going through. The sandbox environment starts with dev. Our sandbox environment is https://dev.raleighhog.com
- The production environment is the site that all members see. This is where you make the changes that chapter members see. Our production environment is https://www.raleighhog.com
- Please note that prior to doing anything in the production environment you can test in the sandbox environment first. This environment is used for testing and is not seen by members.
- Your login credentials are the same for both environments
- Your webmaster will help with any questions you may have.
- Please use caution when in the directories. You have the ability to delete files. This should never be done.
- Files being uploaded should include a datestamp. This is how we distinguish the latest file to be used.
- For instance,
minutes_YYYYMMDD.pdf
where YYYY
is the four digit year, MM
is the two digit month and DD
is the two digit day is a good filename as it allows the files to easily be ordered by date.
- Note that there is a directory under
root --> users
. The directory name starts with a 'u
'. This is a directory that only you can see. You can upload files here but they cannot be shared with others. This directory will not be addressed in this document. Additional information about it can be found by talking with your local webmaster.
- By default, this is the directory selected when you first log in. Be sure and follow the instructions below to upload into the correct, working directory.
Upload the Monthly Minutes
- Login to your account on raleighhog.com
- With your mouse, hover over the My Account link and click the Meeting Minutes link. see image below
- On the page that opens, click the Edit tab. see image below
- The Meeting Minutes page opens in edit mode. The next three steps will add the line for the next month's minutes.
- Place your cursor at the end of the line for the last month listed in the current calendar year. Jun of 2022 is shown for this tutorial. see screenshot below
- Tap the Enter key to move to a new line. (Do NOT add a space prior to hitting the Enter key) see screenshot below
- Following the naming convention, type in the line for the next month. (Do NOT add any extra spaces at the end of the line) see image below
- The next five steps will walk through uploading the meeting minutes and linking to them
- Highlight the entire line you just added by hovering the cursor over it and clicking three times. When the line is highlighted, move the cursor and click the link icon in the Body toolbar (outlined in the image). see image below
- In the pop-up window that opens, click the Browse Server button. see image below
- Click on the shared directory to expand it, then click on the meeting_minutes subdirectory to expand it, then click on the current year subdirectory to expand it.
To place/upload a file to the correct directory, the directory must be selected. (2022 is used for this tutorial) The list of files currently in the subdirectory are listed.
Click Upload from the toolbar. see image below
- Click the Choose File button and select from your machine the PDF file you want to upload. (This file will be in whichever directory you placed it.)
When the file finishes loading click the Upload button.
Click the x in the upper right to close the window. see image below
- The PDF has been successfully uploaded to the server
- In the list of files, double click on the file you just uploaded to select it, then click the Upload icon in the toolbar. see image below
- The URL path has been filled in. Click the OK button. see image below
- The Meeting Minutes is now a link to the PDF you just uploaded
- Scroll down to the bottom of the screen. see image below
- Optionally fill in the Revision log message with a short message of what you just did. Something short like "add Jul 2022 mtg minutes" is good enough to let others know what you did.
- Click the Save button to save your changes.
- Success! You are brought back to the Meeting Minutes home page showing the meeting minutes link you just added.


Smart pointer for OpenGL buffer object with reference counting. More...
#include <opencv2/core/opengl.hpp>
Public Types | |
| enum | Access { READ_ONLY = 0x88B8, WRITE_ONLY = 0x88B9, READ_WRITE = 0x88BA } |
| enum | Target { ARRAY_BUFFER = 0x8892, ELEMENT_ARRAY_BUFFER = 0x8893, PIXEL_PACK_BUFFER = 0x88EB, PIXEL_UNPACK_BUFFER = 0x88EC } |
| The target defines how you intend to use the buffer object. More... | |
Public Member Functions | |
| Buffer () | |
| The constructors. More... | |
| Buffer (int arows, int acols, int atype, unsigned int abufId, bool autoRelease=false) | |
| Buffer (Size asize, int atype, unsigned int abufId, bool autoRelease=false) | |
| Buffer (int arows, int acols, int atype, Target target=ARRAY_BUFFER, bool autoRelease=false) | |
| Buffer (Size asize, int atype, Target target=ARRAY_BUFFER, bool autoRelease=false) | |
| Buffer (InputArray arr, Target target=ARRAY_BUFFER, bool autoRelease=false) | |
| void | bind (Target target) const |
| Binds OpenGL buffer to the specified buffer binding point. More... | |
| unsigned int | bufId () const |
| get OpenGL opject id More... | |
| int | channels () const |
| Buffer | clone (Target target=ARRAY_BUFFER, bool autoRelease=false) const |
| Creates a full copy of the buffer object and the underlying data. More... | |
| int | cols () const |
| void | copyFrom (InputArray arr, Target target=ARRAY_BUFFER, bool autoRelease=false) |
| Copies from host/device memory to OpenGL buffer. More... | |
| void | copyFrom (InputArray arr, cuda::Stream &stream, Target target=ARRAY_BUFFER, bool autoRelease=false) |
| void | copyTo (OutputArray arr) const |
| Copies from OpenGL buffer to host/device memory or another OpenGL buffer object. More... | |
| void | copyTo (OutputArray arr, cuda::Stream &stream) const |
| void | create (int arows, int acols, int atype, Target target=ARRAY_BUFFER, bool autoRelease=false) |
| Allocates memory for ogl::Buffer object. More... | |
| void | create (Size asize, int atype, Target target=ARRAY_BUFFER, bool autoRelease=false) |
| int | depth () const |
| int | elemSize () const |
| int | elemSize1 () const |
| bool | empty () const |
| cuda::GpuMat | mapDevice () |
| map to device memory (blocking) More... | |
| cuda::GpuMat | mapDevice (cuda::Stream &stream) |
| Maps OpenGL buffer to CUDA device memory. More... | |
| Mat | mapHost (Access access) |
| Maps OpenGL buffer to host memory. More... | |
| void | release () |
| Decrements the reference counter and destroys the buffer object if needed. More... | |
| int | rows () const |
| void | setAutoRelease (bool flag) |
| Sets auto release mode. More... | |
| Size | size () const |
| int | type () const |
| void | unmapDevice () |
| void | unmapDevice (cuda::Stream &stream) |
| Unmaps OpenGL buffer. More... | |
| void | unmapHost () |
| Unmaps OpenGL buffer. More... | |
Static Public Member Functions | |
| static void | unbind (Target target) |
| Unbind any buffers from the specified binding point. More... | |
Detailed Description
Smart pointer for OpenGL buffer object with reference counting.
Buffer Objects are OpenGL objects that store an array of unformatted memory allocated by the OpenGL context. These can be used to store vertex data, pixel data retrieved from images or the framebuffer, and a variety of other things.
ogl::Buffer has interface similar with Mat interface and represents 2D array memory.
ogl::Buffer supports memory transfers between host and device and also can be mapped to CUDA memory.
Member Enumeration Documentation
◆ Access
◆ Target
The target defines how you intend to use the buffer object.
Constructor & Destructor Documentation
◆ Buffer() [1/6]
| cv::ogl::Buffer::Buffer | ( | ) |
The constructors.
Creates empty ogl::Buffer object, creates ogl::Buffer object from existed buffer ( abufId parameter), allocates memory for ogl::Buffer object or copies from host/device memory.
◆ Buffer() [2/6]
| cv::ogl::Buffer::Buffer | ( | int | arows, |
| int | acols, | ||
| int | atype, | ||
| unsigned int | abufId, | ||
| bool | autoRelease = false |
||
| ) |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
◆ Buffer() [3/6]
| cv::ogl::Buffer::Buffer | ( | Size | asize, |
| int | atype, | ||
| unsigned int | abufId, | ||
| bool | autoRelease = false |
||
| ) |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
◆ Buffer() [4/6]
| cv::ogl::Buffer::Buffer | ( | int | arows, |
| int | acols, | ||
| int | atype, | ||
| Target | target = ARRAY_BUFFER , |
||
| bool | autoRelease = false |
||
| ) |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
- Parameters
-
arows Number of rows in a 2D array. acols Number of columns in a 2D array. atype Array type ( CV_8UC1, ..., CV_64FC4 ). See Mat for details. target Buffer usage. See cv::ogl::Buffer::Target . autoRelease Auto release mode (if true, release will be called in object's destructor).
◆ Buffer() [5/6]
| cv::ogl::Buffer::Buffer | ( | Size | asize, |
| int | atype, | ||
| Target | target = ARRAY_BUFFER , |
||
| bool | autoRelease = false |
||
| ) |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
- Parameters
-
asize 2D array size. atype Array type ( CV_8UC1, ..., CV_64FC4 ). See Mat for details. target Buffer usage. See cv::ogl::Buffer::Target . autoRelease Auto release mode (if true, release will be called in object's destructor).
◆ Buffer() [6/6]
|
explicit |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
- Parameters
-
arr Input array (host or device memory, it can be Mat , cuda::GpuMat or std::vector ). target Buffer usage. See cv::ogl::Buffer::Target . autoRelease Auto release mode (if true, release will be called in object's destructor).
Member Function Documentation
◆ bind()
| void cv::ogl::Buffer::bind | ( | Target | target | ) | const |
Binds OpenGL buffer to the specified buffer binding point.
- Parameters
-
target Binding point. See cv::ogl::Buffer::Target .
◆ bufId()
| unsigned int cv::ogl::Buffer::bufId | ( | ) | const |
get OpenGL opject id
◆ channels()
| int cv::ogl::Buffer::channels | ( | ) | const |
◆ clone()
| Buffer cv::ogl::Buffer::clone | ( | Target | target = ARRAY_BUFFER , |
| bool | autoRelease = false |
||
| ) | const |
Creates a full copy of the buffer object and the underlying data.
- Parameters
-
target Buffer usage for destination buffer. autoRelease Auto release mode for destination buffer.
◆ cols()
| int cv::ogl::Buffer::cols | ( | ) | const |
◆ copyFrom() [1/2]
| void cv::ogl::Buffer::copyFrom | ( | InputArray | arr, |
| Target | target = ARRAY_BUFFER , |
||
| bool | autoRelease = false |
||
| ) |
Copies from host/device memory to OpenGL buffer.
- Parameters
-
arr Input array (host or device memory, it can be Mat , cuda::GpuMat or std::vector ). target Buffer usage. See cv::ogl::Buffer::Target . autoRelease Auto release mode (if true, release will be called in object's destructor).
◆ copyFrom() [2/2]
| void cv::ogl::Buffer::copyFrom | ( | InputArray | arr, |
| cuda::Stream & | stream, | ||
| Target | target = ARRAY_BUFFER , |
||
| bool | autoRelease = false |
||
| ) |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
◆ copyTo() [1/2]
| void cv::ogl::Buffer::copyTo | ( | OutputArray | arr | ) | const |
Copies from OpenGL buffer to host/device memory or another OpenGL buffer object.
- Parameters
-
arr Destination array (host or device memory, can be Mat , cuda::GpuMat , std::vector or ogl::Buffer ).
◆ copyTo() [2/2]
| void cv::ogl::Buffer::copyTo | ( | OutputArray | arr, |
| cuda::Stream & | stream | ||
| ) | const |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
◆ create() [1/2]
| void cv::ogl::Buffer::create | ( | int | arows, |
| int | acols, | ||
| int | atype, | ||
| Target | target = ARRAY_BUFFER , |
||
| bool | autoRelease = false |
||
| ) |
Allocates memory for ogl::Buffer object.
- Parameters
-
arows Number of rows in a 2D array. acols Number of columns in a 2D array. atype Array type ( CV_8UC1, ..., CV_64FC4 ). See Mat for details. target Buffer usage. See cv::ogl::Buffer::Target . autoRelease Auto release mode (if true, release will be called in object's destructor).
◆ create() [2/2]
| void cv::ogl::Buffer::create | ( | Size | asize, |
| int | atype, | ||
| Target | target = ARRAY_BUFFER , |
||
| bool | autoRelease = false |
||
| ) |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
- Parameters
-
asize 2D array size. atype Array type ( CV_8UC1, ..., CV_64FC4 ). See Mat for details. target Buffer usage. See cv::ogl::Buffer::Target . autoRelease Auto release mode (if true, release will be called in object's destructor).
◆ depth()
| int cv::ogl::Buffer::depth | ( | ) | const |
◆ elemSize()
| int cv::ogl::Buffer::elemSize | ( | ) | const |
◆ elemSize1()
| int cv::ogl::Buffer::elemSize1 | ( | ) | const |
◆ empty()
| bool cv::ogl::Buffer::empty | ( | ) | const |
◆ mapDevice() [1/2]
| cuda::GpuMat cv::ogl::Buffer::mapDevice | ( | ) |
map to device memory (blocking)
◆ mapDevice() [2/2]
| cuda::GpuMat cv::ogl::Buffer::mapDevice | ( | cuda::Stream & | stream | ) |
Maps OpenGL buffer to CUDA device memory.
This operation doesn't copy data. Several buffer objects can be mapped to CUDA memory at a time.
A mapped data store must be unmapped with ogl::Buffer::unmapDevice before its buffer object is used.
◆ mapHost()
Maps OpenGL buffer to host memory.
mapHost maps to the client's address space the entire data store of the buffer object. The data can then be directly read and/or written relative to the returned pointer, depending on the specified access policy.
A mapped data store must be unmapped with ogl::Buffer::unmapHost before its buffer object is used.
This operation can lead to memory transfers between host and device.
Only one buffer object can be mapped at a time.
- Parameters
-
access Access policy, indicating whether it will be possible to read from, write to, or both read from and write to the buffer object's mapped data store. The symbolic constant must be ogl::Buffer::READ_ONLY , ogl::Buffer::WRITE_ONLY or ogl::Buffer::READ_WRITE .
◆ release()
| void cv::ogl::Buffer::release | ( | ) |
Decrements the reference counter and destroys the buffer object if needed.
The function will call setAutoRelease(true) .
◆ rows()
| int cv::ogl::Buffer::rows | ( | ) | const |
◆ setAutoRelease()
| void cv::ogl::Buffer::setAutoRelease | ( | bool | flag | ) |
Sets auto release mode.
The lifetime of the OpenGL object is tied to the lifetime of the context. If OpenGL context was bound to a window it could be released at any time (user can close a window). If object's destructor is called after destruction of the context it will cause an error. Thus ogl::Buffer doesn't destroy OpenGL object in destructor by default (all OpenGL resources will be released with OpenGL context). This function can force ogl::Buffer destructor to destroy OpenGL object.
- Parameters
-
flag Auto release mode (if true, release will be called in object's destructor).
◆ size()
| Size cv::ogl::Buffer::size | ( | ) | const |
◆ type()
| int cv::ogl::Buffer::type | ( | ) | const |
◆ unbind()
|
static |
Unbind any buffers from the specified binding point.
- Parameters
-
target Binding point. See cv::ogl::Buffer::Target .
◆ unmapDevice() [1/2]
| void cv::ogl::Buffer::unmapDevice | ( | ) |
◆ unmapDevice() [2/2]
| void cv::ogl::Buffer::unmapDevice | ( | cuda::Stream & | stream | ) |
Unmaps OpenGL buffer.
◆ unmapHost()
| void cv::ogl::Buffer::unmapHost | ( | ) |
Unmaps OpenGL buffer.
The documentation for this class was generated from the following file:
- opencv2/core/opengl.hpp


{% extends "base.html" %} {# Load the tag library #} {% load bootstrap3 %} {# Load CSS and JavaScript #} {% bootstrap_css %} {% bootstrap_javascript %} {# Display django.contrib.messages as Bootstrap alerts #} {% bootstrap_messages %} {% block landing-page %}
Your username and password didn't match. Please try again.
{% endif %}


Alleged Chinese Involvement in Australian Internal Affairs 'Disturbing' - Canberra
MOSCOW (Sputnik) - Australian Prime Minister Scott Morrison said on Monday that the alleged Chinese involvement in the internal affairs of his country was "disturbing" and "troubling," but urged the public to not jump to conclusions.
"I would caution anyone leaping to any conclusions about these matters … I'm not. But I do find the allegations troubling and disturbing," Morrison said at a press conference on Monday, as quoted by Channel Nine.
In his speech, the prime minister emphasized the government’s readiness to keep Australians free and safe from any foreign interference.
On Sunday, the Australian Channel Nine broadcaster reported that Chinese operatives allegedly offered $1 million to Nick Zhao, an Australian liberal party member, to run for the federal parliament seat in the division of Chisholm in Victoria state. Zhao then reportedly told the Australian Security Intelligence Organisation (ASIO) about the deal. In March, he was found dead in his hotel room in Melbourne.
Apart from that, Australia's The Sydney Morning Herald news outlet and The Age daily reported on Saturday that suspected Chinese spy Wang "William" Liqiang had informed the ASIO about alleged Chinese interference in Australia, Taiwan and Hong Kong. Wang has requested protection from the Australian government.
Beijing claims that Wang is a fraudster and is wanted by China's police forces.


My name is Shanaya Nagendran and I am currently an undergraduate student at Loyola Marymount University pursuing a Bachelors Degree in Computer Science with a minor in Business Administration.
My third summer at Google I worked on a Google Assistant team in Chelsea, New York. My project involved working with the client-side dashboard which allows organizations that create custom Actions to track user statistics. I will be providing more relevant information and further context for the existing data.
My second summer at Google, I worked on the Google Cloud Platform Learn Assistant Panel to integrate a feature that provides GCP users with learning material such as tutorials and forums. I built the infrastructure to customize these provided tutorials based on user history. To do so, I used Java and JavaScript along with 2 Google internal languages.
My first summer at Google, I worked on an internal team, Legal Works, which built a search engine tailored toward lawyer needs. My project was to add a feature to the knowledge card of a queried company that visually represented its first degree subsidiary companies. I did this by accessing knowledge endpoints and using the D3js library to create the visualization.
This is a semester long group project for a Langauge Translation and Implementation (Compilers) class at LMU. RealHotGirlScript is an esoteric language filled with pop culture references, in an attempt to break out from what programmers would except from a normal programming language.
RealHotGirlScript creates its syntax by using an Ohm grammar, which is parsed by Abstract Syntax Tree nodes, analyzed for semantic errors using static semantic analysis, and finally connected with a backend in JavaScript and optimized. RealHotGirlScript supports multiple data types, arithmetic expressions,
functions, if/else statements, loops, comments, classes, and print statements.
Created: Spring 2020 (currently in progress)
TrapMap is an iOS application for finding events near you! The application integrates the Eventful API to search and update existing event and venue databases.
Created: Fall 2019
This web application was created to be the first music social networking app purely for the sharing, discovery, and promotion of music.
Created: August 2017
This project was a group project for my Operating Systems course at LMU. The rap name generator creates its own unix command that asks a user for their first and last name, and returns
a users rap name based of initials mapped to rap names. The initials inputted are converted to ASCII values and given an offset to correspond to the proper index in an array of rap first and last names; this allows a user to get the same rap name for their name regardless of case sensitivity.
This project invovled using Ubutnu, Virtual Box, Makefiles, and reading and writing C code in a linux kernel.
Created: Spring 2020
I am currently serving my second term on the Executive Board of the LMU SWE chapter as the Professional Development and Mentorship Chair. This involves bringing recruiters and speakers to campus in order to grow our members' professional skills and networks. In this position, I have also re-vamped the peer mentorship program to provide students with the proper resources to further their academic and professional futures.


Madzz will send you a one time verification code by SMS.
Depending on your carrier, it may take a few seconds.
Number Verified!!
Oops!! Wrong Key. Please Try Again


ltimer
OS/161 Reference Manual
Name
ltimer - LAMEbus timer device
Synopsis
ltimer* at lamebus*
Description
ltimer is a driver for the CS161 LAMEbus clock/timer card. The first
such card will provide "hardclock" functionality to the system. The
card can also provide beep services to the kernel.
The beep and rtclock
generic devices can be attached to an ltimer instance.
See Also
lamebus


(% extends "layout.html" %)
(% block content %)
(( display_name )) App
Great! The app has been created. Click the button below to download a .zip file containing the playbook app.
Download the app
View (( app_name )).py
(( python_file ))
(% endblock %)


Early design involvement,
focused technical expertise
and extra effort customer support
pufocused technical expertise
and extra effort customer support
put EMI among the top performing
OEM representatives in the country
for our suppliers.focused technical expertise
and extra effort customer support
put EMI among the top performing
OEM representatives in the country
for our suppliers.focused technical expertise
and extra effort customer support
put EMI among the top performing
OEM representatives in the country
for our suppliers.t EMI among the top performing
OEM representatives in the country
for our suppliers.
Download our line card.


Your browser does not support HTML5 video.
TETRIS SPHERES
by dcts
PLAY
PARTICLES BY
Edan
Kwan
MUSIC
Tobias
Herzog
NEXT
TIME
00:00.00
SCORE
0


IE Skate
I like skateboards so much, I decided to replicate that experience with a little HTML / CSS / Javascript. Enjoy!
Sign up todayI like skateboards so much, I decided to replicate that experience with a little HTML / CSS / Javascript. Enjoy!
Sign up today


{% extends "registration/base.html" %} {% load static %} {% block title %}Reset your password{% endblock %} {% block content %}
We've emailed you instructions for setting your password.
If you don't receive an email, please make sure you've entered the address you registered with.


If you want search a book for publish/unpublish change metadata you can choice the book function on the menu as you can see in the figure. For other details please follow next tips
If you want search a book for management you can filling the form with book name field. for information about the field you can use the tool tips ad in figure
Every row in book list has the otpions for publush/unpublish, open option popup in which you can change Author, Description and add/remove search tags


$ git config --global user.name "Your name here"
# Sets the default name for git to use when you commit
$ git config --global user.email "Your email here"
# Sets the default email for git to use when you commit
# some BASH commands you will use quite often from now on:
$ ls #show contents of directory you are in
$ cd Documents
$ mkdir git_mb
$ cd git_mb
$ git init #initialise this working directory as a new repo
$ touch README.md
$ vi README.md
# you can edit this file in any text based editor like notepad
Martin@MB-PC ~/Documents/git_mb (master)
$ git status
# On branch master
#
# Initial Commit
#
# Untracked files:
# (use "git add <file>... " to include in what will be committed)
#
# README.md
nothing added to commit but untracked files present (use "git add"
to track)
Martin@MB-PC ~/Documents/git_mb (master)
$
Martin@MB-PC ~/Documents/git_mb (master)
$ git add README.md
Martin@MB-PC ~/Documents/git_mb (master)
$ git status
# On branch master
#
# Initial Commit
#
# Changes to be committed:
# (use "git rm --cached <file>... " to unstage)
#
# new file:README.md
#
Martin@MB-PC ~/Documents/git_mb (master)
$
Martin@MB-PC ~/Documents/git_mb (master)
$ git commit -m 'Initialise repo and creation of readme file'
[master (root-commit) e881faa] initialise repo and creation
of readme file
1 file changed, 1 insertion(+)
create mode 100644 README.md
Martin@MB-PC ~/Documents/git_mb (master)
$ git status
# On branch master
nothing to commit, working directory clean
Martin@MB-PC ~/Documents/git_mb (master)
$
Martin@MB-PC ~/Documents/git_mb (master)
$ git log
commit e881faa051b1fb5e51074e05e88a744349cb97a6
Author: MBing<EMAIL_ADDRESS>Date: Mon Jun 3 22:38:32 2013 +0200
Initialise repo and creation of readme file
Martin@MB-PC ~/Documents/git_mb (master)
$
Martin@MB-PC ~/Documents/git_mb (master)
$ git clone https://github.com/yourusername/GIT-presentation.git
Cloning into 'GIT-presentation'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
 to include in what will be committed)
#
# yourname.html
nothing added to commit but untracked files present (use git
"git add" to track)
Martin@MB-PC ~/Documents/GIT-presentation (master)
$
Martin@MB-PC ~/Documents/GIT-presentation (master)
$ git add yourname.html
Martin@MB-PC ~/Documents/GIT-presentation (master)
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>... " to unstage)
#
# new file: yourname.html
#
Martin@MB-PC ~/Documents/GIT-presentation (master)
$
Martin@MB-PC ~/Documents/GIT-presentation (master)
$ git commit -m 'adding an html file with my name'
[master 328e0cb] adding an html file with my name
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 yourname.html
Martin@MB-PC ~/Documents/GIT-presentation (master)
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
# (use "git push" to publish your local commits)
#
nothing to commit, working directory clean
Martin@MB-PC ~/Documents/GIT-presentation (master)
$
Martin@MB-PC ~/Documents/GIT-presentation (master)
$ git push origin master
Counting objects: 4 done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 302 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/yourname/GIT-presentation.git
ad764dc..328e0cb master -> master
Martin@MB-PC ~/Documents/GIT-presentation (master)
$ git status
# On branch master
nothing to commit, working directory clean
Martin@MB-PC ~/Documents/GIT-presentation (master)
$


Code + goodies used in Prof. Baines' STA 250 Course (UC Davis, Fall 2013)
NOTE: These are practice questions, they are not due in class, and there is no credit for completing the questions (other than your own sense of satisfaction). These questions are intended to be slightly easier than the homework questions, to allow you to get started on the topics at a comfortable pace.
Simulate from the linear regression model:
\[ y_{i} = x_{i}^{T}\beta + \epsilon_{i} , \quad i=1,\ldots,n , \]with n=100. Use the bootstrap procedure to estimate \(\textrm{SD}(\hat{\beta})\) based on \(B=1000\) bootstrap resamples.
Compare to the asymptotic results reported by lm
or computed using the square root of the diagonal elements of \(\hat{\sigma^{2}}(X^{T}X)^{-1}\).
a. Derive the Jeffreys prior for \(\lambda\).
b. Is the Jeffreys prior a proper prior?
c. Find the family of conjugate priors for \(\lambda\).
d. Derive the posterior distribution for \(\lambda\) under both the Jeffreys and conjugate prior.
e. Does the Jeffreys prior lead to a proper posterior distribution for \(\lambda\)?
f. Let \(n=20\) and \(\sum_{i=1}^{n}y_{i}=97\). Provide a central \(95\%\) credible interval for \(\lambda\).
a. Derive the (joint) Jeffreys prior for \(\theta\).
b. Is the Jeffreys prior a proper prior?
c. Find the family of conjugate priors for \(\theta\).
d. Derive the posterior distribution for \(\theta\) under both the Jeffreys and conjugate prior.
e. Does the Jeffreys prior lead to a proper posterior distribution for \(\theta\)?
f. What is the conditional posterior distribution \(\mu|\sigma^{2},y\)?
g. What is the conditional posterior distribution \(\sigma^{2}|\mu,y\)?
h. Are you able to derive the marginal posterior distribution for \(\mu\) i.e., \(p(\mu|y)\)?