float solution
this is the center
absolute position solution
this is center
flexbox solution
this is center
table solution
this is center
grid solution
this is center


COMMODITY MARKET DYNAMICS
A SYSTEMS ANALYSIS OF FUNDAMENTAL RELATIONSHIPS
A THESIS Presented to The Faculty of the Graduate Division by
Robert Davis Landel
In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy
In the School of Industrial and Systems Engineering
Georgia Institute of Technology
September, 1969
Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.


Click on images to select color clicked on, like the Photoshop Eyedropper tool.
Basic Usage:
<eye-dropper img-src="{{logo}}" ng-model="eyedropperColor1"></eye-dropper>Result Color:
Change output to RGB:
<eye-dropper img-src="{{logo}}" ng-model="eyedropperColor2" output-format="rgb"></eye-dropper>Result Color:
Resize Image:
<eye-dropper img-src="{{logo}}" ng-model="eyedropperColor3" output-format="hex" height="200" width="200"></eye-dropper>Result Color:
| Options | Values (default values in bold) |
|---|---|
| output-format |
Optional 'hex', 'rgb' Format of output color |
| ng-model |
Required Angular model for the output color. |
| img-src |
Required Image source url |
| height |
Optional If height is provided, image will be resized to that height. If not original image height is used. |
| width |
Optional If width is provided, image will be resized to that width. If not original image width is used. |


Google Play Filtering
Google Play uses the <uses-sdk>
attributes declared in your app manifest to filter your app from devices
that do not meet it's platform version requirements. Before setting these
attributes, make sure that you understand
Google Play filters.
- syntax:
<uses-sdk android:minSdkVersion="integer" android:targetSdkVersion="integer" android:maxSdkVersion="integer" />
- contained in:
<manifest>
- description:
Lets you express an application's compatibility with one or more versions of the Android platform, by means of an API Level integer. The API Level expressed by an application will be compared to the API Level of a given Android system, which may vary among different Android devices.
Despite its name, this element is used to specify the API Level, not the version number of the SDK (software development kit) or Android platform. The API Level is always a single integer. You cannot derive the API Level from its associated Android version number (for example, it is not the same as the major version or the sum of the major and minor versions).
Also read the document about Versioning Your Applications.
- attributes:
-
android:minSdkVersion
- An integer designating the minimum API Level required
for the application to run. The Android system will prevent the user from installing
the application if the system's API Level is lower than the value specified in
this attribute. You should always declare this attribute.
Caution: If you do not declare this attribute, the system assumes a default value of "1", which indicates that your application is compatible with all versions of Android. If your application is not compatible with all versions (for instance, it uses APIs introduced in API Level 3) and you have not declared the proper
minSdkVersion
, then when installed on a system with an API Level less than 3, the application will crash during runtime when attempting to access the unavailable APIs. For this reason, be certain to declare the appropriate API Level in theminSdkVersion
attribute. android:targetSdkVersion
- An integer designating the API Level that the application targets. If not set, the default
value equals that given to
minSdkVersion
.This attribute informs the system that you have tested against the target version and the system should not enable any compatibility behaviors to maintain your app's forward-compatibility with the target version. The application is still able to run on older versions (down to
minSdkVersion
).As Android evolves with each new version, some behaviors and even appearances might change. However, if the API level of the platform is higher than the version declared by your app's
targetSdkVersion
, the system may enable compatibility behaviors to ensure that your app continues to work the way you expect. You can disable such compatibility behaviors by specifyingtargetSdkVersion
to match the API level of the platform on which it's running. For example, setting this value to "11" or higher allows the system to apply a new default theme (Holo) to your app when running on Android 3.0 or higher and also disables screen compatibility mode when running on larger screens (because support for API level 11 implicitly supports larger screens).There are many compatibility behaviors that the system may enable based on the value you set for this attribute. Several of these behaviors are described by the corresponding platform versions in the
Build.VERSION_CODES
reference.To maintain your application along with each Android release, you should increase the value of this attribute to match the latest API level, then thoroughly test your application on the corresponding platform version.
Introduced in: API Level 4
android:maxSdkVersion
- An integer designating the maximum API Level on which the application is
designed to run.
In Android 1.5, 1.6, 2.0, and 2.0.1, the system checks the value of this attribute when installing an application and when re-validating the application after a system update. In either case, if the application's
maxSdkVersion
attribute is lower than the API Level used by the system itself, then the system will not allow the application to be installed. In the case of re-validation after system update, this effectively removes your application from the device.To illustrate how this attribute can affect your application after system updates, consider the following example:
An application declaring
maxSdkVersion="5"
in its manifest is published on Google Play. A user whose device is running Android 1.6 (API Level 4) downloads and installs the app. After a few weeks, the user receives an over-the-air system update to Android 2.0 (API Level 5). After the update is installed, the system checks the application'smaxSdkVersion
and successfully re-validates it. The application functions as normal. However, some time later, the device receives another system update, this time to Android 2.0.1 (API Level 6). After the update, the system can no longer re-validate the application because the system's own API Level (6) is now higher than the maximum supported by the application (5). The system prevents the application from being visible to the user, in effect removing it from the device.Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.
Introduced in: API Level 4
Future versions of Android (beyond Android 2.0.1) will no longer check or enforce themaxSdkVersion
attribute during installation or re-validation. Google Play will continue to use the attribute as a filter, however, when presenting users with applications available for download.
- introduced in:
- API Level 1
What is API Level?
API Level is an integer value that uniquely identifies the framework API revision offered by a version of the Android platform.
The Android platform provides a framework API that applications can use to interact with the underlying Android system. The framework API consists of:
- A core set of packages and classes
- A set of XML elements and attributes for declaring a manifest file
- A set of XML elements and attributes for declaring and accessing resources
- A set of Intents
- A set of permissions that applications can request, as well as permission enforcements included in the system
Each successive version of the Android platform can include updates to the Android application framework API that it delivers.
Updates to the framework API are designed so that the new API remains compatible with earlier versions of the API. That is, most changes in the API are additive and introduce new or replacement functionality. As parts of the API are upgraded, the older replaced parts are deprecated but are not removed, so that existing applications can still use them. In a very small number of cases, parts of the API may be modified or removed, although typically such changes are only needed to ensure API robustness and application or system security. All other API parts from earlier revisions are carried forward without modification.
The framework API that an Android platform delivers is specified using an integer identifier called "API Level". Each Android platform version supports exactly one API Level, although support is implicit for all earlier API Levels (down to API Level 1). The initial release of the Android platform provided API Level 1 and subsequent releases have incremented the API Level.
The table below specifies the API Level supported by each version of the Android platform. For information about the relative numbers of devices that are running each version, see the Platform Versions dashboards page.
Uses of API Level in Android
The API Level identifier serves a key role in ensuring the best possible experience for users and application developers:
- It lets the Android platform describe the maximum framework API revision that it supports
- It lets applications describe the framework API revision that they require
- It lets the system negotiate the installation of applications on the user's device, such that version-incompatible applications are not installed.
Each Android platform version stores its API Level identifier internally, in the Android system itself.
Applications can use a manifest element provided by the framework API —
<uses-sdk>
— to describe the minimum and maximum API
Levels under which they are able to run, as well as the preferred API Level that
they are designed to support. The element offers three key attributes:
android:minSdkVersion
— Specifies the minimum API Level on which the application is able to run. The default value is "1".android:targetSdkVersion
— Specifies the API Level on which the application is designed to run. In some cases, this allows the application to use manifest elements or behaviors defined in the target API Level, rather than being restricted to using only those defined for the minimum API Level.android:maxSdkVersion
— Specifies the maximum API Level on which the application is able to run. Important: Please read the<uses-sdk>
documentation before using this attribute.
For example, to specify the minimum system API Level that an application
requires in order to run, the application would include in its manifest a
<uses-sdk>
element with a android:minSdkVersion
attribute. The value of android:minSdkVersion
would be the integer
corresponding to the API Level of the earliest version of the Android platform
under which the application can run.
When the user attempts to install an application, or when revalidating an
appplication after a system update, the Android system first checks the
<uses-sdk>
attributes in the application's manifest and
compares the values against its own internal API Level. The system allows the
installation to begin only if these conditions are met:
- If a
android:minSdkVersion
attribute is declared, its value must be less than or equal to the system's API Level integer. If not declared, the system assumes that the application requires API Level 1. - If a
android:maxSdkVersion
attribute is declared, its value must be equal to or greater than the system's API Level integer. If not declared, the system assumes that the application has no maximum API Level. Please read the<uses-sdk>
documentation for more information about how the system handles this attribute.
When declared in an application's manifest, a <uses-sdk>
element might look like this:
<manifest> <uses-sdk android:minSdkVersion="5" /> ... </manifest>
The principal reason that an application would declare an API Level in
android:minSdkVersion
is to tell the Android system that it is
using APIs that were introduced in the API Level specified. If the
application were to be somehow installed on a platform with a lower API Level,
then it would crash at run-time when it tried to access APIs that don't exist.
The system prevents such an outcome by not allowing the application to be
installed if the lowest API Level it requires is higher than that of the
platform version on the target device.
For example, the android.appwidget
package was introduced with API
Level 3. If an application uses that API, it must declare a
android:minSdkVersion
attribute with a value of "3". The
application will then be installable on platforms such as Android 1.5 (API Level
3) and Android 1.6 (API Level 4), but not on the Android 1.1 (API Level 2) and
Android 1.0 platforms (API Level 1).
For more information about how to specify an application's API Level
requirements, see the <uses-sdk>
section of the manifest file documentation.
Development Considerations
The sections below provide information related to API level that you should consider when developing your application.
Application forward compatibility
Android applications are generally forward-compatible with new versions of the Android platform.
Because almost all changes to the framework API are additive, an Android application developed using any given version of the API (as specified by its API Level) is forward-compatible with later versions of the Android platform and higher API levels. The application should be able to run on all later versions of the Android platform, except in isolated cases where the application uses a part of the API that is later removed for some reason.
Forward compatibility is important because many Android-powered devices receive over-the-air (OTA) system updates. The user may install your application and use it successfully, then later receive an OTA update to a new version of the Android platform. Once the update is installed, your application will run in a new run-time version of the environment, but one that has the API and system capabilities that your application depends on.
In some cases, changes below the API, such those in the underlying system itself, may affect your application when it is run in the new environment. For that reason it's important for you, as the application developer, to understand how the application will look and behave in each system environment. To help you test your application on various versions of the Android platform, the Android SDK includes multiple platforms that you can download. Each platform includes a compatible system image that you can run in an AVD, to test your application.
Application backward compatibility
Android applications are not necessarily backward compatible with versions of the Android platform older than the version against which they were compiled.
Each new version of the Android platform can include new framework APIs, such as those that give applications access to new platform capabilities or replace existing API parts. The new APIs are accessible to applications when running on the new platform and, as mentioned above, also when running on later versions of the platform, as specified by API Level. Conversely, because earlier versions of the platform do not include the new APIs, applications that use the new APIs are unable to run on those platforms.
Although it's unlikely that an Android-powered device would be downgraded to a previous version of the platform, it's important to realize that there are likely to be many devices in the field that run earlier versions of the platform. Even among devices that receive OTA updates, some might lag and might not receive an update for a significant amount of time.
Selecting a platform version and API Level
When you are developing your application, you will need to choose the platform version against which you will compile the application. In general, you should compile your application against the lowest possible version of the platform that your application can support.
You can determine the lowest possible platform version by compiling the
application against successively lower build targets. After you determine the
lowest version, you should create an AVD using the corresponding platform
version (and API Level) and fully test your application. Make sure to declare a
android:minSdkVersion
attribute in the application's manifest and
set its value to the API Level of the platform version.
Declaring a minimum API Level
If you build an application that uses APIs or system features introduced in
the latest platform version, you should set the
android:minSdkVersion
attribute to the API Level of the latest
platform version. This ensures that users will only be able to install your
application if their devices are running a compatible version of the Android
platform. In turn, this ensures that your application can function properly on
their devices.
If your application uses APIs introduced in the latest platform version but
does not declare a android:minSdkVersion
attribute, then
it will run properly on devices running the latest version of the platform, but
not on devices running earlier versions of the platform. In the latter
case, the application will crash at runtime when it tries to use APIs that don't
exist on the earlier versions.
Testing against higher API Levels
After compiling your application, you should make sure to test it on the
platform specified in the application's android:minSdkVersion
attribute. To do so, create an AVD that uses the platform version required by
your application. Additionally, to ensure forward-compatibility, you should run
and test the application on all platforms that use a higher API Level than that
used by your application.
The Android SDK includes multiple platform versions that you can use, including the latest version, and provides an updater tool that you can use to download other platform versions as necessary.
To access the updater, use the android
command-line tool,
located in the <sdk>/tools directory. You can launch the SDK updater by
executing android sdk
. You can
also simply double-click the android.bat (Windows) or android (OS X/Linux) file.
In ADT, you can also access the updater by selecting
Window > Android SDK
Manager.
To run your application against different platform versions in the emulator, create an AVD for each platform version that you want to test. For more information about AVDs, see Creating and Managing Virtual Devices. If you are using a physical device for testing, ensure that you know the API Level of the Android platform it runs. See the table at the top of this document for a list of platform versions and their API Levels.
Using a Provisional API Level
In some cases, an "Early Look" Android SDK platform may be available. To let you begin developing on the platform although the APIs may not be final, the platform's API Level integer will not be specified. You must instead use the platform's provisional API Level in your application manifest, in order to build applications against the platform. A provisional API Level is not an integer, but a string matching the codename of the unreleased platform version. The provisional API Level will be specified in the release notes for the Early Look SDK release notes and is case-sensitive.
The use of a provisional API Level is designed to protect developers and device users from inadvertently publishing or installing applications based on the Early Look framework API, which may not run properly on actual devices running the final system image.
The provisional API Level will only be valid while using the Early Look SDK and can only be used to run applications in the emulator. An application using the provisional API Level can never be installed on an Android device. At the final release of the platform, you must replace any instances of the provisional API Level in your application manifest with the final platform's actual API Level integer.
Filtering the Reference Documentation by API Level
Reference documentation pages on the Android Developers site offer a "Filter
by API Level" control in the top-right area of each page. You can use the
control to show documentation only for parts of the API that are actually
accessible to your application, based on the API Level that it specifies in
the android:minSdkVersion
attribute of its manifest file.
To use filtering, select the checkbox to enable filtering, just below the page search box. Then set the "Filter by API Level" control to the same API Level as specified by your application. Notice that APIs introduced in a later API Level are then grayed out and their content is masked, since they would not be accessible to your application.
Filtering by API Level in the documentation does not provide a view of what is new or introduced in each API Level — it simply provides a way to view the entire API associated with a given API Level, while excluding API elements introduced in later API Levels.
If you decide that you don't want to filter the API documentation, just disable the feature using the checkbox. By default, API Level filtering is disabled, so that you can view the full framework API, regardless of API Level.
Also note that the reference documentation for individual API elements specifies the API Level at which each element was introduced. The API Level for packages and classes is specified as "Since <api level>" at the top-right corner of the content area on each documentation page. The API Level for class members is specified in their detailed description headers, at the right margin.


02 November 2000
Disease Outbreak Reported
As of 2 November, the Ugandan Ministry of Health has reported cumulative figures of 262 cases including 81 deaths.
The first virologically confirmed case outside Gulu district has been reported in Mbarara district in southwestern Uganda. The sample was tested by the laboratory established in Gulu by the WHO Collaborating Centre at the US Centers for Disease Control and Prevention (CDC), United States. The Ugandan Ministry of Health has requested specialists in the management of Ebola in Gulu to carry out an investigation. A WHO-led team from Gulu including CDC and Médecins sans Frontières in Kampala are travelling to Mbarara district to investigate the report.


Spatial Transformer Layer
tefla.core.special_layers.spatialtransformer (U, theta, batch_size=64, downsample_factor=1.0, num_transform=1, name='SpatialTransformer', **kwargs)
Implements a spatial transformer layer as described in [1]. It's based on lasagne implementation in [2], modified by Mrinal Haloi
Args
- U: float The output of a convolutional net should have the shape [batch_size, height, width, num_channels].
- theta: float
The output of the localisation network should be [batch_size, num_transform, 6] or [batch_size, 6] if num_transform=1
python`theta`` to : - identity = np.array([[1., 0., 0.], - [0., 1., 0.]]) - identity = identity.flatten() - theta = tf.Variable(initial_value=identity)
- downsample_factor: a float, determines output shape, downsample input shape by downsample_factor
Returns
spatial transformed output of the network
Subsamples the input along the spatial dimensions
tefla.core.special_layers.subsample (inputs, factor, name=None)
Args
- inputs: A
Tensor
of size [batch, height_in, width_in, channels]. - factor: The subsampling factor.
- name: Optional variable_scope.
Returns
output: A Tensor
of size [batch, height_out, width_out, channels] with the
input, either intact (if factor == 1) or subsampled (if factor > 1).
Strided 2-D convolution with 'SAME' padding
tefla.core.special_layers.conv2d_same (inputs, num_outputs, kernel_size, stride, rate=1, name=None, **kwargs)
When stride > 1, then we do explicit zero-padding, followed by conv2d with 'VALID' padding.
Note that
net = conv2d_same(inputs, num_outputs, 3, stride=stride)
is equivalent to
net = conv2d(inputs, num_outputs, 3, stride=1, padding='SAME') net = subsample(net, factor=stride)
whereas
net = conv2d(inputs, num_outputs, 3, stride=stride, padding='SAME')
is different when the input's height or width is even, which is why we add the current function. For more details, see ResnetUtilsTest.testConv2DSameEven().
Args
- inputs: A 4-D tensor of size [batch, height_in, width_in, channels].
- num_outputs: An integer, the number of output filters.
- kernel_size: An int with the kernel_size of the filters.
- stride: An integer, the output stride.
- rate: An integer, rate for atrous convolution.
- name: name.
Returns
output: A 4-D tensor of size [batch, height_out, width_out, channels] with the convolution output.
Bottleneck residual unit variant with BN before convolutions
tefla.core.special_layers.bottleneck_v1 (inputs, depth, depth_bottleneck, stride, rate=1, name=None, **kwargs)
This is the full preactivation residual unit variant proposed in [2]. See Fig. 1(b) of [2] for its definition. Note that we use here the bottleneck variant which has an extra bottleneck layer.
When putting together two consecutive ResNet blocks that use this unit, one should use stride = 2 in the last unit of the first block.
Args
- inputs: A tensor of size [batch, height, width, channels].
- depth: The depth of the ResNet unit output.
- depth_bottleneck: The depth of the bottleneck layers.
- stride: The ResNet unit's stride. Determines the amount of downsampling of the units output compared to its input.
- rate: An integer, rate for atrous convolution.
- outputs_collections: Collection to add the ResNet unit output.
- name: Optional variable_scope.
Returns
The ResNet unit's output.
Bottleneck residual unit variant with BN before convolutions
tefla.core.special_layers.bottleneck_v2 (inputs, depth, depth_bottleneck, stride, rate=1, name=None, **kwargs)
This is the full preactivation residual unit variant proposed in [2]. See Fig. 1(b) of [2] for its definition. Note that we use here the bottleneck variant which has an extra bottleneck layer.
When putting together two consecutive ResNet blocks that use this unit, one should use stride = 2 in the last unit of the first block.
Args
- inputs: A tensor of size [batch, height, width, channels].
- depth: The depth of the ResNet unit output.
- depth_bottleneck: The depth of the bottleneck layers.
- stride: The ResNet unit's stride. Determines the amount of downsampling of the units output compared to its input.
- rate: An integer, rate for atrous convolution.
- outputs_collections: Collection to add the ResNet unit output.
- name: Optional variable_scope.
Returns
The ResNet unit's output.
DenseCRF over unnormalised predictions
tefla.core.special_layers.dense_crf (probs, img=None, n_classes=21, n_iters=10, sxy_gaussian= (1, 1), compat_gaussian=4, kernel_gaussian=
Args
- probs: class probabilities per pixel.
- img: if given, the pairwise bilateral potential on raw RGB values will be computed.
- n_iters: number of iterations of MAP inference.
- sxy_gaussian: standard deviations for the location component of the colour-independent term.
- compat_gaussian: label compatibilities for the colour-independent term (can be a number, a 1D array, or a 2D array).
- kernel_gaussian: kernel precision matrix for the colour-independent term (can take values CONST_KERNEL, DIAG_KERNEL, or FULL_KERNEL).
- normalisation_gaussian: normalisation for the colour-independent term (possible values are NO_NORMALIZATION, NORMALIZE_BEFORE, NORMALIZE_AFTER, NORMALIZE_SYMMETRIC).
- sxy_bilateral: standard deviations for the location component of the colour-dependent term.
- compat_bilateral: label compatibilities for the colour-dependent term (can be a number, a 1D array, or a 2D array).
- srgb_bilateral: standard deviations for the colour component of the colour-dependent term.
- kernel_bilateral: kernel precision matrix for the colour-dependent term (can take values CONST_KERNEL, DIAG_KERNEL, or FULL_KERNEL).
- normalisation_bilateral: normalisation for the colour-dependent term (possible values are NO_NORMALIZATION, NORMALIZE_BEFORE, NORMALIZE_AFTER, NORMALIZE_SYMMETRIC).
Returns
Refined predictions after MAP inference.
ResNeXt Block
tefla.core.special_layers.resnext_block (inputs, nb_blocks, out_channels, is_training, reuse, cardinality, downsample=False, downsample_strides=2, activation=
Args
- inputs:
Tensor
. Inputs 4-D Layer. - nb_blocks:
int
. Number of layer blocks. - out_channels:
int
. The number of convolutional filters of the layers surrounding the bottleneck layer. - cardinality:
int
. Number of aggregated residual transformations. - downsample:
bool
. If True, apply downsampling using 'downsample_strides' for strides. - downsample_strides:
int
. The strides to use when downsampling. - activation:
function
(returning aTensor
). - batch_norm:
bool
. If True, apply batch normalization. - use_ bias:
bool
. If True, a bias is used. - w_init:
function
, Weights initialization. - b_init:
tf.Tensor
. Bias initialization. - w_regularizer:
function
. Add a regularizer to this - weight_decay:
float
. Regularizer decay parameter. Default: 0.001. - trainable:
bool
. If True, weights will be trainable. - reuse:
bool
. If True and 'scope' is provided, this layer variables will be reused (shared). override name. - name: A name for this layer (optional). Default: 'ResNeXtBlock'.
Returns
4-D Tensor [batch, new height, new width, out_channels].
Embedding
tefla.core.special_layers.embedding (inputs, vocab_dim, embedding_dim, reuse, validate_indices=False, w_init=
Args
- inputs: a 2-D
Tensor
[samples, ids]. - vocab_dim: list of
int
. Vocabulary size (number of ids). - embedding_dim: list of
int
. Embedding size. - validate_indices:
bool
. Whether or not to validate gather indices. - w_init: Weights initialization.
- trainable:
bool
. If True, weights will be trainable. - reuse:
bool
. If True and 'scope' is provided, this layer variables will be reused (shared). - name: A name for this layer (optional). Default: 'Embedding'.
Returns
3-D Tensor [samples, embedded_ids, features].
Gated unit for language modelling
tefla.core.special_layers.gated_layer (inputs, layer, num_units, is_training, reuse, name='gated_layer', **kwargs)
Args
- inputs: a 3-D/4-D
Tensor
, input [samples, timesteps, input_dim] - layer: a
layer
, layer to pass the inputs e.g.tefla.core.layers
- num_units: a
int
, number of units for each layer - is_training: a
boolean
, Training if its true - reuse:
bool
. If True and 'scope' is provided, this layer variables will be reused (shared). - name: A name for this layer (optional). Default: 'gated_layer'.
Returns
a 3-D/4-D Tensor
, output of the gated unit
Returns glimpses at the locations
tefla.core.special_layers.glimpseSensor (img, normLoc, minRadius=4, depth=1, sensorBandwidth=12)
Args
- img: a 4-D
Tensor
, [batch_size, width, height, channels] - normloc: a
float
, [0, 1] normalized location - minRadius: a
int
, min radius for zooming - depth: a
int
, number of zooms - sensorbandwidth: a
int
, output glimpse size, width/height
Returns
a 5-D tensor
of glimpses
Adds a PVA block layer
tefla.core.special_layers.pva_block_v1 (x, num_units, name='pva_block_v1', **kwargs) convolution followed by crelu and scaling
Args
- x: A 4-D
Tensor
of with at least rank 2 and value for the last dimension, i.e.[batch_size, in_height, in_width, depth]
, - is_training: Bool, training or testing
- num_units: Integer or long, the number of output units in the layer.
- reuse: whether or not the layer and its variables should be reused. To be able to reuse the layer scope must be given.
- filter_size: a int or list/tuple of 2 positive integers specifying the spatial dimensions of of the filters.
- stride: a int or tuple/list of 2 positive integers specifying the stride at which to compute output.
- padding: one of
"VALID"
or"SAME"
. - activation: activation function, set to None to skip it and maintain a linear activation.
- batch_norm: normalization function to use. If
batch_norm
isTrue
then google original implementation is used and if another function is provided then it is applied. default set to None for no normalizer function - batch_norm_args: normalization function parameters.
- w_init: An initializer for the weights.
- w_regularizer: Optional regularizer for the weights.
- untie_biases: spatial dimensions wise baises
- b_init: An initializer for the biases. If None skip biases.
- trainable: If
True
also add variables to the graph collectionGraphKeys.TRAINABLE_VARIABLES
(see tf.Variable). - name: Optional name or scope for variable_scope/name_scope.
- use_bias: Whether to add bias or not
Returns
The 4-D Tensor
variable representing the result of the series of operations.
e.g.: 4-D Tensor
[batch, new_height, new_width, n_output].
Adds a PVA block v2 layer
tefla.core.special_layers.pva_block_v2 (x, num_units, name='pva_block_v2', **kwargs) first batch normalization followed by crelu and scaling, convolution is applied after scalling
Args
- x: A 4-D
Tensor
of with at least rank 2 and value for the last dimension, i.e.[batch_size, in_height, in_width, depth]
, - is_training: Bool, training or testing
- num_units: Integer or long, the number of output units in the layer.
- reuse: whether or not the layer and its variables should be reused. To be able to reuse the layer scope must be given.
- filter_size: a int or list/tuple of 2 positive integers specifying the spatial dimensions of of the filters.
- stride: a int or tuple/list of 2 positive integers specifying the stride at which to compute output.
- padding: one of
"VALID"
or"SAME"
. - activation: activation function, set to None to skip it and maintain a linear activation.
- batch_norm: normalization function to use. If
batch_norm
isTrue
then google original implementation is used and if another function is provided then it is applied. default set to None for no normalizer function - batch_norm_args: normalization function parameters.
- w_init: An initializer for the weights.
- w_regularizer: Optional regularizer for the weights.
- untie_biases: spatial dimensions wise baises
- b_init: An initializer for the biases. If None skip biases.
- trainable: If
True
also add variables to the graph collectionGraphKeys.TRAINABLE_VARIABLES
(see tf.Variable). - name: Optional name or scope for variable_scope/name_scope.
- use_bias: Whether to add bias or not
Returns
The 4-D Tensor
variable representing the result of the series of operations.
e.g.: 4-D Tensor
[batch, new_height, new_width, n_output].
Performs a pooling operation that results in a fixed size:
tefla.core.special_layers.max_pool_2d_nxn_regions (inputs, output_size, mode='max') output_size x output_size.
Used by spatial_pyramid_pool. Refer to appendix A in [1].
Args
- inputs: A 4D Tensor (B, H, W, C)
- output_size: The output size of the pooling operation.
- mode: The pooling mode {max, avg}
Returns
A list of tensors, for each output bin. The list contains output_size * output_size elements, where each elment is a Tensor (N, C).
Performs spatial pyramid pooling (SPP) over the input
tefla.core.special_layers.spatial_pyramid_pool (inputs, dimensions=[2, 1], mode='max', implementation='kaiming') It will turn a 2D input of arbitrary size into an output of fixed dimenson. Hence, the convlutional part of a DNN can be connected to a dense part with a fixed number of nodes even if the dimensions of the input image are unknown.
The pooling is performed over :math:l
pooling levels.
Each pooling level :math:i
will create :math:M_i
output features.
:math:M_i
is given by :math:n_i * n_i
, with :math:n_i
as the number
of pooling operations per dimension level :math:i
.
The length of the parameter dimensions is the level of the spatial pyramid.
Args
- inputs: A 4D Tensor (B, H, W, C).
- dimensions: The list of :math:
n_i
's that define the output dimension - of each pooling level :math:
i
. The length of dimensions is the level of - the spatial pyramid.
- mode: Pooling mode 'max' or 'avg'.
- implementation: The implementation to use, either 'kaiming' or 'fast'.
- kamming is the original implementation from the paper, and supports variable
- sizes of input vectors, which fast does not support.
Returns
A fixed length vector representing the inputs.


{% extends "base_template.html" %} {% block content %}
This Mobile Device Management platform is open-source and awesome. Check it out !


|
BitMagic-C++
|
| ▼BitMagic Library | BitMagic C++ Library For more information please visit: http://bitmagic.io |
| ▼bvector<> container | The Main bvector<> Group bvector<> template: front end of the BitMagic library |
| bvector<> iterators | Iterators for compressed bit-vector traversal |
| ▼bvector<> algorithms | |
| Binary-distance metrics | |
| bvector<> serialization | |
| Allocator | |
| Small sets functionality | |
| ▼Sparse and compressed vectors | Sparse vector for integer types using bit transposition transform |
| Sparse vector algorithms | Sparse vector algorithms |
| Sparse vector serialization | Sparse vector serialization |
| sparse_vector<> | Sparse vector for integer types using bit transposition transform |
| GAP functions | |
| BIT functions | |
| SSE2 functions | Processor specific optimizations for SSE2 instructions (internals) |
| SSE4.2 funcions (internal) | Processor specific optimizations for SSE4.2 instructions (internals) |
| Elias Gamma Code (internal) |


Ex-INEC boss, Nwosu hails Obiano over Zik's holiday
Emma Elekwa, Onitsha
Former chairman, National Electoral Commission of Nigeria (NECON), Prof Humphrey Nwosu has commended Anambra state Governor, Willie Obiano for declaring a one-day public holiday in the state in memory of former President of Nigeria, Dr. Nnamdi Azikiwe.
Nwosu spoke via Skype in his base in America, describing the maiden celebration of Zik’s day as memorable.
He praised the Governor for immortalizing one of the great sons of Anambra state who left unmatchable legacies for the country.
Nwosu who was also former commissioner for local government in the Old Anambra also commended Obiano for introducing operation light up Anambra which has reduced crimes in the state.
He said, “I’m also excited for the launching of operation Kpochapu phase II and the introduction of Africa’s first super smart close circuit cameras for the state.”
READ ALSO: Anambra declares Monday public holiday in honour of Zik
Nwosu, a native of Ajali in Orumba North of Anambra state, known for operation A4 electoral system lauded the Governor’s procurement and distribution of security gadgets fitted 110 vehicles to security agencies in the state was unique for safer Christmas.
He said he was particularly challenged over the Governor commitment to security of lives and property amidst paucity of funds, urging him to mobilize resources to intervene in some of the deplorable roads ahead the Christmas season.


The abundance of tourist guides and tourist promotions created by tourism authorities or by municipalities includes mainly cultural, accommodation, and food and nightlife options. The disadvantage of those guides is the lack of information about which areas are the most attractive and famous according to the preferences as well as the spatial and temporal distribution of tourists.However, geosocial data gives the solution to this problem providing information about tourists that can be analyzed and contributed to the tourism decision-making process.
This web-GIS project is created within the framework of the MSc program in GIS of the Department of Physical Geography of Lund University, as a result of the final semester dissertation and aims to disclose spatial and temporal patterns of tourists by mining big spatial data from Flickr social media platform.
The results depicted in this page are all derived from an API specific created for this thesis.The Top Attraction pins were provided by a local tourism agency Travel Genius as well as from famous travel sites such as Lonely Planet and Visit Greece . Through the API, geotagged photos with additional information were requested from Flickr's API, for the years 2009-2019. Then the received geosocial data were cleaned, analyzed and clustered in order to produce the most visited areas in Athens. The resulted Areas Of Interest are presented in the map as circles and they are visual images of the traces, visitors left behind, by uploading photos in Flickr, from 2009 to 2019.


The Event class provides utilities for working with the browser event object, listening to and capturing events, and decorating Framework Objects with an API for scoping handlers back to the object.
Utilities for DOM Events.
See Using event utilities for an example of implementating the script on a page.
This example shows how to use the event buffer and scopeHandler mechanisms to preserve the event handler context to a specific object instance.

Test paragraph

A developer specified event handler that is invoked after binding an event to the _prehandle_event handler, and which has the context specified by the scopeHandler method. Method is virtual and can be overridden.
v = _handle_event( )
v as variant: Returns developer specified value.
Internal event handler used to establish context and to invoke the custom handler.
v = _prehandle_event( )
v as variant: Returns value from
Creates the scopeHandler method on the specified object.
void addScopeBuffer( e )
Cancels the event.
void cancelEvent( o )
Returns the event object, where the specified parameter may or may not be the event object depending on the browser.
e = getEvent( o )
e as object: The event object.
Returns the event destination or target object.
e = getEventDestination( o )
e as object: The event destination object.
Returns the event origination object.
e = getEventOrigination( o )
e as object: The event origination or source object.
Returns the event source object.
e = getEventSource( o )
e as object: The event source object.
Creates a custom event handler, _prehandle_event, which invokes _handle_event for the specified object, using the specified context. This method is created by addScopeBuffer. Method is virtual and can be overridden.
f = scopeHandler( s, r, x, l )
f as function: Custom event handler function.
[ Hemi JavaScript Framework - Stephen W. Cote, 2002 - 2013. ]


We started designing and selling neckties in 1971.
After 44 years, we're still family-owned and operated.
VIEW OUR STORY
Black
Blue
Collegiate
Cotton
Black
Blue
Collegiate
Cotton
Striped
VIEW OUR STORY
Tightly knotted or hanging loose? Fitted suit or selvedge denim? Share your style with us.
Our newsletter is simple and brief for the hard-pressed gentleman.
There are eighty-five ways to knot a tie. We'll show you the essentials.
<EMAIL_ADDRESS>877-687-8437
Contact Us


(
no frames
)
Class List
Method List
File List
Documentation by YARD 0.6.1
Alphabetic Index
File Listing
README
Namespace Listing A-Z
A
Api
(Reddit)
B
Base
(Reddit)
C
ClassMethods
(Reddit::JsonListing)
Comment
(Reddit)
I
InstanceMethods
(Reddit::JsonListing)
J
JsonListing
(Reddit)
M
Message
(Reddit)
R
Reddit
S
Submission
(Reddit)
T
Thing
(Reddit)
U
User
(Reddit)
V
Vote
(Reddit)


Preparation time
overnight
Cooking time
10 to 30 mins
Serves
Serves 4-6
Dietary
Fragrant spicy brioche buns baked into a wreath, drizzled with orange icing, with four smaller buns filled with homemade orange curd.
Make the brioche dough the day before serving. For the dough, put the flour, sugar, yeast, salt and spices into the mixing bowl of a stand mixer with the dough hook fitted.
Add the eggs and knead on a low speed for five minutes.
Scrape down the sides of the bowl, then knead at medium speed for 10 minutes. The dough will be smooth, elastic and well amalgamated.
Start adding the butter to the dough a few pieces at a time, whilst mixing at low speed. When all the butter has been added, work the dough at a higher speed for 6-10 minutes until dough is smooth, shiny and elastic and comes away from the sides of the bowl.
Cover the dough and leave in a cool place overnight (10-12C/50-54F is best).
Soak the sultanas in the orange flower water, for the filling, and leave overnight also.
The next day, allow the dough to come back up to room temperature and finish proving.
Roll out the dough into a square and scatter over the soaked sultanas, pistachios, orange zest and marzipan.
Divide the dough into approximately 90g/3¼oz pieces and form into balls.
Generously butter a 28cm/11in pie tin and four small brioche moulds.
Place 11 balls in a circle in the pie dish, just slightly apart.
Form the remaining dough into four brioche à tête by pressing with the edge of your hand into the ball two-thirds of the way across and ‘sawing’ the dough to make a small head. Lift the head to stretch it from the ‘body’, then press the head into the body. Place the shaped brioche into the buttered moulds.
Cover the dough and leave to prove for up to 2½ hours.
Preheat the oven to 190C/375F/Gas 5.
Brush the brioche with egg wash and bake the buns and wreath for 10 minutes at 190C/375F/Gas 5. Reduce the oven temperature to 180C/350F/Gas 4 and continue to bake the small brioche for five minutes more, until dark golden-brown, then remove from the oven. When the small brioche come out of the oven, cover the wreath with aluminium foil and continue to bake for 15-20 minutes more. Remove from the oven when dark golden-brown.
Remove the brioche from the tins and cool on a wire rack.
For the orange curd, heat the juices, zest, salt, sugar, butter and eggs in a heavy saucepan, or in a bain marie, over a low heat. Stir the mixture constantly until it thickens and coats the back of a spoon.
Sieve the orange curd and add the orange liqueur and leave in the fridge to firm up.
When the orange curd has cooled, cut a cone out of the brioche à tête and place a small amount of curd into each brioche. Return the brioche tops and dust with icing sugar.
Mix the orange juice with the icing sugar to make icing. Drizzle the orange icing over the wreath in a random pattern and sprinkle with the toasted flaked almonds, pistachios and decorate with edible gold stars and green and red icing decorations.
Mix the orange juice with the icing sugar to make icing. Drizzle the orange icing over the wreath in a random pattern and sprinkle with the toasted flaked almonds, pistachios and decorate with edible gold stars and green and red icing decorations.


Test an insecure registry
読む時間の目安: 4 分このページでは、オープンソースである Docker Registry を使って、独自にレジストリを提供する情報を示しています。 Docker Hub はホスト提供込みの Registry であり、さまざまな機能を追加することができます。 たとえばチーム、組織、ウェブフック、自動ビルドなどです。 詳しくは Docker Hub を参照してください。
While it’s highly recommended to secure your registry using a TLS certificate issued by a known CA, you can choose to use self-signed certificates, or use your registry over an unencrypted HTTP connection. Either of these choices involves security trade-offs and additional configuration steps.
Deploy a plain HTTP registry
Warning: It’s not possible to use an insecure registry with basic authentication.
This procedure configures Docker to entirely disregard security for your registry. This is very insecure and is not recommended. It exposes your registry to trivial man-in-the-middle (MITM) attacks. Only use this solution for isolated testing or in a tightly controlled, air-gapped environment.
-
Edit the
daemon.json
file, whose default location is/etc/docker/daemon.json
on Linux orC:\ProgramData\docker\config\daemon.json
on Windows Server. If you use Docker Desktop for Mac or Docker Desktop for Windows, click the Docker icon, choose Preferences, and choose +Daemon.If the
daemon.json
file does not exist, create it. Assuming there are no other settings in the file, it should have the following contents:{ "insecure-registries" : ["myregistrydomain.com:5000"] }
Substitute the address of your insecure registry for the one in the example.
With insecure registries enabled, Docker goes through the following steps:
- First, try using HTTPS.
- If HTTPS is available but the certificate is invalid, ignore the error about the certificate.
- If HTTPS is not available, fall back to HTTP.
- First, try using HTTPS.
-
Restart Docker for the changes to take effect.
Repeat these steps on every Engine host that wants to access your registry.
Use self-signed certificates
Warning: Using this along with basic authentication requires to also trust the certificate into the OS cert store for some versions of docker (see below)
This is more secure than the insecure registry solution.
-
Generate your own certificate:
$ mkdir -p certs $ openssl req \ -newkey rsa:4096 -nodes -sha256 -keyout certs/domain.key \ -x509 -days 365 -out certs/domain.crt
Be sure to use the name
myregistrydomain.com
as a CN. -
Use the result to start your registry with TLS enabled.
-
Instruct every Docker daemon to trust that certificate. The way to do this depends on your OS.
-
Linux: Copy the
domain.crt
file to/etc/docker/certs.d/myregistrydomain.com:5000/ca.crt
on every Docker host. You do not need to restart Docker. -
Windows Server:
-
Open Windows Explorer, right-click the
domain.crt
file, and choose Install certificate. When prompted, select the following options:Store location local machine Place all certificates in the following store selected -
Click Browser and select Trusted Root Certificate Authorities.
-
Click Finish. Restart Docker.
-
-
Docker Desktop for Mac: Follow the instructions on Adding custom CA certificates. Restart Docker.
-
Docker Desktop for Windows: Follow the instructions on Adding custom CA certificates. Restart Docker.
-
Troubleshoot insecure registry
This section lists some common failures and how to recover from them.
Failing...
Failing to configure the Engine daemon and trying to pull from a registry that is not using TLS results in the following message:
FATA[0000] Error response from daemon: v1 ping attempt failed with error:
Get https://myregistrydomain.com:5000/v1/_ping: tls: oversized record received with length 20527.
If this private registry supports only HTTP or HTTPS with an unknown CA certificate, add
`--insecure-registry myregistrydomain.com:5000` to the daemon's arguments.
In the case of HTTPS, if you have access to the registry's CA certificate, no need for the flag;
simply place the CA certificate at /etc/docker/certs.d/myregistrydomain.com:5000/ca.crt
Docker still complains about the certificate when using authentication?
When using authentication, some versions of Docker also require you to trust the certificate at the OS level.
Ubuntu
$ cp certs/domain.crt /usr/local/share/ca-certificates/myregistrydomain.com.crt
update-ca-certificates
Red Hat Enterprise Linux
cp certs/domain.crt /etc/pki/ca-trust/source/anchors/myregistrydomain.com.crt
update-ca-trust
Oracle Linux
$ update-ca-trust enable
Restart Docker for the changes to take effect.
Windows
Open Windows Explorer, right-click the certificate, and choose Install certificate.
Then, select the following options:
- Store location: local machine
- Check place all certificates in the following store
- Click Browser, and select Trusted Root Certificate Authorities
- Click Finish
Learn more about managing TLS certificates.
After adding the CA certificate to Windows, restart Docker Desktop for Windows.
registry, on-prem, images, tags, repository, distribution, insecure


- YANG is a very extensible data modeling language
- YANG is not an API
- Openconfig is an industry effort to define data models
napalm-yang
aims to help transitioning to YANG/Openconfig modelsnapalm-yang
integrates with the usual suspects;ansible
,salt
, etc.


Before Change
Segment breakpoints are not the same across samples, so samples are listed
in serial with the sample ID as the left column.
outrows = []
chrom_ids = None
for fname in sample_fnames:
segments = CNA.read(fname)
if chrom_ids is None:
// Create & store
chrom_ids = create_chrom_ids(segments)
else:
// Verify
core.assert_equal("Segment chromosome names differ",
previous=chrom_ids.keys(),
current=create_chrom_ids(segments).keys())
if "probes" in segments:
outheader = ["ID", "Chromosome", "Start", "End", "NumProbes", "Mean"]
def row2out(row):
return (segments.sample_id, chrom_ids[row["chromosome"]],
row["start"], row["end"], row["probes"],
row["log2"])
else:
outheader = ["ID", "Chromosome", "Start", "End", "Mean"]
def row2out(row):
return (segments.sample_id, chrom_ids[row["chromosome"]],
row["start"], row["end"], row["log2"])
outrows.extend(row2out(row) for row in segments)
return outheader, outrows
def create_chrom_ids(segments):
Map chromosome names to integers in the order encountered.
After Change
Segment breakpoints are not the same across samples, so samples are listed
in serial with the sample ID as the left column.
out_tables = []
chrom_ids = None
for fname in sample_fnames:
segments = CNA.read(fname)
if chrom_ids is None:
// Create & store
chrom_ids = create_chrom_ids(segments)
else:
// Verify
core.assert_equal("Segment chromosome names differ",
previous=chrom_ids.keys(),
current=create_chrom_ids(segments).keys())
table = segments.data.loc[:, ["start", "end"]]
table["ID"] = segments.sample_id
table["mean"] = segments.data["log2"]
table["chromosome"] = [chrom_ids[chrom]
for chrom in segments["chromosome"]]
if "probes" in segments:
table["num_probes"] = segments["probes"]
sorted_cols = ["ID", "chromosome", "start", "end", "num_probes",
"mean"]
else:
sorted_cols = ["ID", "chromosome", "start", "end", "mean"]
out_tables.append(table.reindex(columns=sorted_cols))
return pd.concat(out_tables)
def create_chrom_ids(segments):
Map chromosome names to integers in the order encountered.


/*
* ====================================================================
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
* ====================================================================
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* <http://www.apache.org/>.
*
*/ /*...*/ |
||
| 27 | package org.apache.http.impl.client.cache.memcached; |
|
|
||
/**
* Default implementation of {@link MemcachedCacheEntry}. This implementation
* simply uses Java serialization to serialize the storage key followed by
* the {@link HttpCacheEntry} into a byte array.
*/ /*...*/ |
||
| 42 | public class MemcachedCacheEntryImpl implements MemcachedCacheEntry { |
|
| 44 | private String key; |
|
| 45 | private HttpCacheEntry httpCacheEntry; |
|
| 47 | 7 | public MemcachedCacheEntryImpl(final String key, final HttpCacheEntry httpCacheEntry) { |
| 48 | 7 | this.key = key; |
| 49 | 7 | this.httpCacheEntry = httpCacheEntry; |
| 50 | 7 | } |
| 52 | 3 | public MemcachedCacheEntryImpl() { |
| 53 | 3 | } |
/* (non-Javadoc)
* @see org.apache.http.impl.client.cache.memcached.MemcachedCacheEntry#toByteArray()
*/ /*...*/ |
||
| 58 | @Override |
|
| 59 | synchronized public byte[] toByteArray() { |
|
| 60 | 2 | final ByteArrayOutputStream bos = new ByteArrayOutputStream(); |
| 61 | ObjectOutputStream oos; |
|
| 62 | try { |
|
| 63 | 2 | oos = new ObjectOutputStream(bos); |
| 64 | 2 | oos.writeObject(this.key); |
| 65 | 2 | oos.writeObject(this.httpCacheEntry); |
| 66 | 2 | oos.close(); |
| 67 | 0 | } catch (final IOException ioe) { |
| 68 | 0 | throw new MemcachedSerializationException(ioe); |
| 69 | 2 | } |
| 70 | 2 | return bos.toByteArray(); |
| 71 | } |
|
/* (non-Javadoc)
* @see org.apache.http.impl.client.cache.memcached.MemcachedCacheEntry#getKey()
*/ /*...*/ |
||
| 76 | @Override |
|
| 77 | public synchronized String getStorageKey() { |
|
| 78 | 5 | return key; |
| 79 | } |
|
/* (non-Javadoc)
* @see org.apache.http.impl.client.cache.memcached.MemcachedCacheEntry#getHttpCacheEntry()
*/ /*...*/ |
||
| 84 | @Override |
|
| 85 | public synchronized HttpCacheEntry getHttpCacheEntry() { |
|
| 86 | 5 | return httpCacheEntry; |
| 87 | } |
|
/* (non-Javadoc)
* @see org.apache.http.impl.client.cache.memcached.MemcachedCacheEntry#set(byte[])
*/ /*...*/ |
||
| 92 | @Override |
|
| 93 | synchronized public void set(final byte[] bytes) { |
|
| 94 | 2 | final ByteArrayInputStream bis = new ByteArrayInputStream(bytes); |
| 95 | ObjectInputStream ois; |
|
| 96 | String s; |
|
| 97 | HttpCacheEntry entry; |
|
| 98 | try { |
|
| 99 | 2 | ois = new ObjectInputStream(bis); |
| 100 | 1 | s = (String)ois.readObject(); |
| 101 | 1 | entry = (HttpCacheEntry)ois.readObject(); |
| 102 | 1 | ois.close(); |
| 103 | 1 | bis.close(); |
| 104 | 1 | } catch (final IOException ioe) { |
| 105 | 1 | throw new MemcachedSerializationException(ioe); |
| 106 | 0 | } catch (final ClassNotFoundException cnfe) { |
| 107 | 0 | throw new MemcachedSerializationException(cnfe); |
| 108 | 1 | } |
| 109 | 1 | this.key = s; |
| 110 | 1 | this.httpCacheEntry = entry; |
| 111 | 1 | } |
| 113 | } |


{% load staticfiles %}
You have submitted a request!
We will send you an email when the result is ready :)


Accuracy
The accuracy of the energy monitor was tested by comparison with a cheap plug-in domestic energy monitor. A series of resistive and reactive loads were chosen to give 25 data points up to a maximum of 2238W. Voltage, Current and real power values for each load were read from the reference meter's display, the energy monitor serial terminal, and logged in a spreadsheet, from which the error, percentage error and standard deviation of the error were calculated.
It was impossible to record all the values for both meters simultaneously which is a significant source of experimental error. The values would vary significantly from second to second, and it's difficult to say how much of this second to second variation is due to voltage changes in the mains supply, load variations (e.g. as heaters heat up) or due to meter measurement resolution. It would be interesting to test the meter on a professional test apparatus.
That said, the results are an improvement on the previous meter design, and are as follows:
Current
The current was measured up to 9.28A. The absolute error maximum was: +0.01A and minimum was -0.03A
The standard deviation of the error: 0.011A
In the range of 0.6A to 9.28A the percentage error for current stays within 1%
Voltage
Voltage was measured in the range 241V-250V. The absolute error maximum was: +3.7V and minimum was -0.5V
The standard deviation of the error: 1.236V
The graph of voltage vs error shows a definite sloping trend which suggests the result can be improved with calibration.
Real Power
Real power was measured in the range 13.7W - 2238W. The absolute error maximum was: +9.6W and minimum was -2.1W
The standard deviation of the error: 2.624W
There appear to be two possible experimental errors at ~560W. Without these, the max absolute error would be: +3.50W
In the range of 170W to 2238W the percentage error stays within 2%
Apparent Power
Apparent power was measured in the range 39VA - 2239VA. The absolute error maximum was: +6.23VA and minimum was -7.54VA
The standard deviation of the error: 3.898VA
In the range of 150VA to 2239VA the percentage error stays within 2%
Power factor
Power factor was measured in the range 0.45 – 1.00. The absolute error maximum was: +0.03 and minimum was -0.02
The standard deviation of the error: 0.008
In the range of 0.45 – 1.00 the percentage error stays within 3.5%


HashMap<K extends Hashable, V> Interface
Hash map version of the Map interface. A HashMap does not
provide any guarantees on the order of keys and values in getKeys
and getValues
.
Default class
Extends
Subinterfaces
Implemented by
Constructors
Code new HashMap() #
Creates a map with the default implementation.
HashMap();


I have been obsessed by Prolog language recent weeks. While I first learned Prolog long time ago, and actually I was attracted, I have never used it fluently because it's too hard to get familiar without any practical necessity. Although, there are a lot of interesting literatures which require certain knowledge of logic programming in computer science. So, I decided to do another approach; writing a Prolog interpreter to learn Prolog.
I chose Haskell as the implementation language because of its succinctness. I'm a beginner Haskell programmer, and I thought it was also a good opportunity to learn Prolog and Haskell same time! The starting point was a Prolog implementation in Hug98 distribution http://darcs.haskell.org/hugs98/demos/prolog/. I think this is a great Haskell program, but its too difficult to me. Rewriting it as my level would be a good exercise.
Here is my version of Prolog in Haskell. Entire program is about 200+ lines. There is no cut operator but it has a list notation so that you can write [apple, orange | banana] stile literal. Let's take a look at the first part.
module Prolog (Term(..), Clause(..), w, s, cons, parse, parse', atom, variable, struct, list, nil, terms, arguments, term, clause, clauses, query, display, unify, unifyList, applyTerm, prove, rename, solveString) where import Text.ParserCombinators.Parsec import Data.Maybe import Char
I used Parsec as a parser, and defined some data structures.
infix 6 :- data Term = Var String Int | Struct String [Term] deriving (Show, Eq) data Clause = Term :- [Term] deriving (Show, Eq) data Command = Fact Clause | Query [Term] | ShowAll | Noop type Rules = [Clause] type Substitution = [(Term, Term)]
Term represents Prolog's term like "apple" or "father(abe,
homer)". It can be a variable, or a structure. A variable has an index
number which I used it later to distinct a same variable name in
different contexts. A simple term like "apple" is also represented as
a structure without elements like Struct "apple" []
.
Clause is a Prolog rule like "mortal(X) :- man(X)". I stole a user
defined operator constructor ":-" from original Hugs' Prolog to write
a Haskell expression in Prolog like. So "mortal(X) :- man(X)" in
Haskell expression becomes Struct "mortal" [Var "X" 0] :-
[(Struct "man" [Var "X" 0])]
. Well, it's not quite
nice. Although the parser will provide better notation later, I have
to use this expression when debugging the interpreter meanwhile. Its
cumbersome. So I made up tiny utility functions to make Prolog data
easier.
-- Utility constructors for debugging w :: String -> Term w s@(x:xs) | isUpper x = Var s 0 | otherwise = Struct s [] s :: String -> [Term] -> Term s n xs = Struct n xs cons s cdr = (Struct "cons" [w s, cdr])Using this functions, now "mortal(X) :- man(X)" is written as
s"mortal" [w"X"] :- [s"man" [w"X"]]
. It is much better, isn't
it?
By the way, I like the word unification. It sounds peace and spiritual! Unification is one of two most peculiar concept in Prolog (another one is the control structure by depth first search). Unification is solving a logical equation. For example, the answer of "[X, orange] = [apple, Y]" must be X = apple, and Y = orange. It is almost same as variable binding in a normal programming language, but tricky part is that a direction is symmetry, so X = Y and Y = X is same meaning. How can it be possibly implemented?? Think about the data structure of the answer at first.
---- Unification ---- type Substitution = [(Term, Term)] true = []
I used a list of tuples of terms, or an associate list to
represent a substitution. For example, "X = apple, Y = orange" is
represented as [(X, apple), (Y, orange)] (in actual Haskell
code, [(w"X", w"apple"), (w"Y", w"orange")]
). A tuple
of left hand side is always a variable name, and right hand side is
any term, concrete value preferably. The goal of unification is making
associations with variable and term. To make this process easier,
"transitive" substitution is allowed. Think about an equation "X = Y,
Y = banana". It is represented like [(X, Y), (Y, banana)], which is
solved as X = banana, and Y = banana in apply function. Let's look at
the implementation.
-- apply [(w"X", w"Y"), (w"Y", w"Z")] [(w"X"), (w"Y")] == [(w"Z"), (w"Z")] apply :: Substitution -> [Term] -> [Term] apply s ts = [applyTerm s t | t <- ts] applyTerm [] (Var y n) = Var y n applyTerm ((Var x i, t):s) (Var y j) | x == y && i == j = applyTerm s t | otherwise = applyTerm s (Var y j) applyTerm s (Struct n ts) = Struct n (apply s ts)
The function apply substitutes a variable name of its value. To support transitive apply, applyTerm is called recursively if the value is also a variable. But it can solve only one way. Think about opposite case "Y = banana, X = Y". Apply can't find the fact X = banana because "Y = banana" is appeared before. So what I should do is applying X = Y before adding the substitution.
| Equation | Substitution(solution) | |
| 1 | Y = banana, X = Y | |
| 2 | X = Y | Y = banana (append) |
| 3 | X = banana (apply: Y = banana) | Y = banana |
| 4 | Y = banana, X = banana (append) |
I suppose that this two fold way solve all of logical equation. Apply is always needed before append it to the solution. Actual source implementation seems to be complicated because there are cases where a variable can appears any side, and sometimes there is no solution. To represent no-answer case, a Maybe monad is used. So there are variations such as;
-- unify (w"X") (w"apple") == Just [(w"X", w"apple")] unify :: Term -> Term -> Maybe Substitution unify (Var x n) (Var y m) = Just [(Var x n, Var y m)] unify (Var x n) y = Just [(Var x n, y)] unify x (Var y m) = Just [(Var y m, x)] unify (Struct a xs) (Struct b ys) | a == b = unifyList xs ys | otherwise = Nothing unifyList :: [Term] -> [Term] -> Maybe Substitution unifyList [] [] = Just true unifyList [] _ = Nothing unifyList _ [] = Nothing unifyList (x:xs) (y:ys) = do s <- unify x y s' <- unifyList (apply s xs) (apply s ys) return (s ++ s')
Note that I just use append (++) to add a new substation in unifyList. But if you design carefully, recursive apply is not necessary. Using something like a map is a better idea.
As a programming language, Prolog is unique as it has no explicit control structure. Instead, a Prolog program can be seen as a big nested if then else statement. This find and branch functions are implemented of this behavior. While unification is a technique of how to solve a equation, solver deals with when each equation should be solved. There are two most important concepts to understand control structures in Prolog.
A proof's fate is decided by branch function, branch function returns a list of goals (with corresponding substitutions). If the list is empty, this branch is failed. If the list includes empty goal, it is actually succeed because empty goal means that it is unified against a fact like "food(apple).". Well, is it complicated?
---- Solver ---- prove :: Rules -> [Term] -> [Substitution] prove rules goals = find rules 1 goals -- Depth first search -- find (parse' clauses "p(X):-q(X). q(a).") 1 [parse' term "p(X)"] find :: Rules -> Int -> [Term] -> [Substitution] find rules i [] = [true] find rules i goals = do let rules' = rename rules i (s, goals') <- branch rules' goals solution <- find rules (i + 1) goals' return (s ++ solution) -- Find next branches. A branch is a pair of substitution and next goals. -- branch (parse' clauses "n(z). n(s(X)):-n(X).") (parse' query "?-n(X).") branch :: Rules -> [Term] -> [(Substitution, [Term])] branch rules (goal:goals) = do head :- body <- rules s <- maybeToList (unify goal head) return (s, apply s (body ++ goals))
Find function has an argument for index number to show the depth of the tree. This number is used to rename all variables used in whole rules. This is necessary because same variable name in different clauses are actually represented different variables.
-- Rename all variables in the rules to split namespaces. rename :: Rules -> Int -> Rules rename rules i = [ renameVar head :- renameVars body | head :- body <- rules] where renameVar (Var s _) = Var s i renameVar (Struct s ts) = Struct s (renameVars ts) renameVars ts = [renameVar t | t <- ts]I have only explained evaluator part of the REPL, but still there are reader, printer, and loop. You can browse and download whole source code from http://github.com/propella/prolog/tree. Someday I might write some of interesting topics in the program...


| Class and Description |
|---|
| PercentileRanksBuilder
Builder for the
PercentileRanks aggregation. |
| PercentilesBuilder
Builder for the
Percentiles aggregation. |
| Class and Description |
|---|
| AbstractPercentilesParser |
| Percentile |
| PercentileRanksBuilder
Builder for the
PercentileRanks aggregation. |
| PercentilesBuilder
Builder for the
Percentiles aggregation. |
| PercentilesMethod
An enum representing the methods for calculating percentiles
|
| Class and Description |
|---|
| Percentile |
| PercentileRanks
An aggregation that computes approximate percentiles given values.
|
| Percentiles
An aggregation that computes approximate percentiles.
|
| Class and Description |
|---|
| Percentile |
| PercentileRanks
An aggregation that computes approximate percentiles given values.
|
| Percentiles
An aggregation that computes approximate percentiles.
|
| Class and Description |
|---|
| Percentile |
| Percentiles
An aggregation that computes approximate percentiles.
|
Copyright © 2009–2016. All rights reserved.


Greed of a few leaders gives Jubo League a bad name, says Harun
by bdnews24.comBangladesh Awami Jubo League's outgoing General Secretary Harunur Rashid has blamed the misdeeds of a handful of leaders for tarnishing the image of the organisation.
He was addressing the opening session of the Jubo League's 7th National Congress at Dhaka's Suhrawardy Udyan on Saturday.
The ruling Awami League's youth wing has been marred by controversy in recent times after the involvement of its leaders in the casino scam and other irregularities came to the fore.
It led to the ouster of the organisation's chairman Omar Faruk along with several other influential leaders.
But past and present leaders hope a change in leadership through the council will help the beleagured organisation regain its glory.
According to Harunur, the 'excessive greed' and 'misconduct' of a few members have sullied the image of the entire organisation.
"Our ordinary workers and activists are good people who are not afflicted with greed and ambition. They work to implement the values of our leader Sheikh Hasina."
Praising the activists of Jubo League, Harunur added, "Our activists only want a bit of love and respect. But a few people like us suffer from greed."


It is a method that returns the data of the preformatted object.
wd(date).format(string, locale)
The string
argument (optional), if not defined, will return the same object result with the toString
method. The argument consists of a string where you can enter attributes of the object as format below:
The locale
argument (optional) consists of a string representing the location (e.g. pt-BR
). If not set, the location will be the one entered in the lang attribute of the html
tag, the provided browser value or en-US
wd(%today).toString(); wd(%today).format();
It is a method that returns the long name of the month.
wd(date).longMonth(locale)
The definition of locale
is the same as the format
method.
wd(%today).longMonth();
It is a method that returns the long name of the day of week.
wd(date).longWeek(locale)
The definition of locale
is the same as the format
method.
wd(%today).longWeek();
It is a method that gets the short name of the month.
wd(date).shortMonth(locale)
The definition of locale
is the same as the format
method.
wd(%today).shortMonth();
It is a method that returns the short name of the day of week.
wd(date).shortWeek(locale)
The definition of locale
is the same as the format
method.
wd(%today).shortWeek();


Containers in the C++ Standard Library can maintain a variety of different types of elements. These include the fundamental datatypes (int, char, and so on), pointers, or user-defined types. Containers cannot hold references. In general, memory management is handled automatically by the standard container classes through the allocator template parameter type.
An allocator type can be provided as a second template parameter when declaring any container. Of course, if the allocator template parameter is provided explicitly, then its type must match the contained type. By default, all containers use the standard default allocator. See Section 15.3 for a discussion of user-defined allocators.
Values are placed into a container using the copy constructor. Some operations on a container require a default constructor. Generic algorithms that copy into a container, like std::copy(), use the assignment operator.
When an entire container is duplicated by invoking a copy constructor or by assignment, for example, every value is copied into the new structure using either the copy constructor or the assignment operator. Whether a deep copy or a shallow copy results is controlled by the programmer, who can provide the assignment operator with whatever meaning is desired. Memory for structures used internally by the various container classes is allocated and released automatically and efficiently.
If a destructor is defined for the element type, this destructor is invoked when values are removed from a container. When an entire collection is destroyed, the destructor is invoked for each remaining value being held by the container.
A few words should be said about containers that hold pointer values. Such collections are not uncommon. For example, a collection of pointers is the only way to store values that can potentially represent either instances of a class or instances of a subclass. Such a collection is encountered in an example problem discussed in Section 11.3.
In these cases, the container is responsible only for maintaining the pointer values themselves. It is the responsibility of the programmer to manage the memory for the values being referenced by the pointers. This includes making certain that the memory values are properly allocated, usually by invoking operator new; that they are not released while the container holds references to them; and that they are properly released once they have been removed from the container.


The Orc User Guide has moved to URL: https://orc.csres.utexas.edu/documentation/html/userguide/userguide.html


Project: TunedIn
TunedIn is a free-to-use desktop application that brings to users the power of a full-fledged command line personal organizer, bundled together with a user-friendly interface and competence functions. It gives the user freedom to personalize the information in their most preferred way. The fundamental units of this organiser are Order, Group and List mechanisms. These primary units are the indispensable elements to build up the usability and improving the performance of an organiser. With numerous contacts in TunedIn, it is essential to categorise and present the wide range of information in an organised way, at the same time, not neglecting the intuitiveness of commands for users.
Code contributed: [Functional code] [Test code]
Enhancement Added: Order
Enhanced Order command to sort with Birthday, Tag and Group, and with multiple(2) person fields. (enhanced on the original Order command done by quanle1994)
Order contacts in Address Book by parameter(s): order
- Since V1.0
Order the list of persons according to a specified parameter. Parameters are case insensitive.
Format: order PARAMETER [MORE_PARAMETER]
Examples:
-
order NAME
Returns address list sorted by name in alphabetical order. -
'order BIRTHDAY name`
Returns address list sorted by birthday then by name.
Invalid command Example :
* order NAME GROUP
Justification
Ordering is essential to TunedIn. It provides the fundamental and a must-to-have functionality of an organizer. With the ordering mechanism, user will be able to order the list of contacts in 19 different ways with more than one ordering field.This is inline with our goal in making TunedIn as customizable as possible and, most importantly to allow the user to organize the contacts to their most preferred way.
Order(Sort) mechanism
The order mechanism is implemented by 'OrderCommand' and OrderCommandParser
in the Logic component.
It is facilitated by the UniquePersonList
which resides in Addressbook < ModelManager
.
It allows re-ordering of the person list that modifies the initial order of the list.
This mechanism inherits from the UndoableCommands
.
The implementation of the OrderCommand
constructor is as shown :
public OrderCommand(String orderParameter)
{
this.orderParameter = orderParameter;
}
As you can see from the implementation, the command requires user inputs in the form of String
as the parameter/s
to order. The inputs are restricted by the fields of Person
that only includes Name
, Address
,
Tag
and Birthday
. Before a new instance of OrderCommand
is being created, the OrderCommandParser
will ensure that the input from the user
is not empty string.
The execution of the command is done in the following method :
public CommandResult executeUndoableCommand() throws CommandException {
try {
model.orderList(orderParameter);
} catch (UnrecognisedParameterException upe) {
throw new CommandException(MESSAGE_ORDER_WRONG_PARAMETER);
}
return new CommandResult(MESSAGE_ORDER_SUCCESS + orderParameter);
}
After a series of function calls, the model.orderList() method will eventually call orderBy() method
in the UniquePersonList
.
UniquePersonList
deals with the list of persons that enforces uniqueness between its elements
and supports a set of list operations. The following diagram shows the UML diagram of the class.
orderBy() method is able to order the existing person list by a maximum of two parameters. It will order the list by the first parameter follow by the second parameter. The implementation of the orderBy() is shown below:
public void orderBy(String parameter) throws UnrecognisedParameterException {
switch (parameter) {
case "NAME":
internalList.sort(Person.getPersonNameComparator());
break;
...
case "NAME ADDRESS":
internalList.sort(Person.getPersonNameComparator().thenComparing(Person.getPersonAddressComparator()));
break;
case "ADDRESS NAME":
internalList.sort(Person.getPersonAddressComparator().thenComparing(Person.getPersonNameComparator()));
break;
...
default:
throw new UnrecognisedParameterException();
}
}
The comparators are implemented in the Person
as shown:
public static final Comparator<Person> getPersonNameComparator() {
return (Person a, Person b) -> a.getName().toString()
.compareToIgnoreCase(b.getName().toString());
}
public static final Comparator<Person> getPersonAddressComparator() {
return (Person a, Person b) -> a.getAddress().toString()
.compareToIgnoreCase(b.getAddress().toString());
}
public static final Comparator<Person> getPersonBirthdayComparator() {
return comparing(a -> a.getBirthday().getReformatDate(),
nullsLast(naturalOrder()));
}
public static final Comparator<Person> getPersonTagComparator() {
return (Person a, Person b) -> a.getTags().toString()
.compareToIgnoreCase(b.getTags().toString());
}
public static final Comparator<Person> getPersonGroupComparator() {
return (a, b) -> {
if (a.getGroup().toString().isEmpty()) {
return 1;
} else if (b.getGroup().toString().isEmpty()) {
return -1;
} else {
return a.getGroup().toString().compareToIgnoreCase(b.getGroup().toString());
}
};
}
As you can see,
5 Comparator
objects are constructed for each valid parameter to compare the list of contacts
and order according to natural order and null last.+
Birthday is ordered by yyyy-mm-dd instead of the dd-mm-yyyy format.
This is achieved by reformatting the
Birthday string as shown:
public String getReformatDate() {
if (value.isEmpty()) {
return null;
}
return new StringBuilder().append(value.substring(6, 10)).append(value.substring(3, 5))
.append(value.substring(0, 2)).toString();
}
Person(s) with empty Birthday field will be sorted to the last.
Suppose that the user has just launched the application and no previous orderCommand
has been called. The persons will
be listed according to the default ordering, in order of last added (Last contact added will appear as the last in the list).
The user executes another orderCommand
by typing order name
, to view the list of contacts ordered in alphabetical order
based on the Name
field of a person. With valid input the list of contacts will be ordered accordingly and
the ordered list will be shown.
The user executes another command by typing order tag name
to order the list by Tag
first then Name
of the person.
| If the order command fails its execution due to invalid order parameter, the list of contact will not be ordered. |
The following sequence diagram shows how the order operation works:
The following activity diagram models what happened when OrderCommand
is executed.
Design Considerations
Aspect: Implementation of sorting algorithm
Alternative 1 (current choice): Sort method inherited from List Interface with specified comparator
Pros: Easy to implement and has the advantage of mergesort.
Alternative 2: Implement the sorting with quicksort algorithm
Pros: Able to perform sorting faster than mergesort.
Cons: Not stable and tedious to implement.
Enhancement Added: Group
Added Group command to group one or multiple persons in a specified group and to show the name of existing groups.
Group person(s) : group
- Since V1.4
Grouping the person(s) in address book or view the existing groups.
Format: group INDEX [MORE_INDEX] g/GROUP_NAME
group showall
Examples:
-
group 2 g/Family
Group the 2nd person in the current list of address book to groupFamily
. -
group 1 3 4 5 g/NUS
Group the 1st, 3rd, 4th and 5th persons to groupNUS
. -
group showall
Show the name of existing groups in the command feedback box, on top of the calender.
Justification
Grouping is another fundamental unit in any organiser application. The function of grouping is imperative in TunedIn and allows user to classify the contacts into different category and thus more organised. The users are also able to specified the group name with no restriction on special characters. Additionally, it also consists of a command “showall” which displays all the group names in the feedback box, to allow users to check on the existing group easily and readily. These improves the user’s experience and achieve our goal in making TunedIn easy to use.
Group mechanism
The group mechanism is implemented by the GroupCommand
and GroupCommandParser
in the Logic component.
The group mechanism is facilitated by the UniquePersonList
and UniqueGroupList
, which resides inside the Addressbook
.
It supports adding a custom group to a number of contacts by utilizing the CLI commands in the TunedIn application.
The group mechanism also inherit from the UndoableCommands
.
In order to group persons, a new class Group
is implemented and has a composition association with Person
.
A Person
consist of the Group
object.
Group is optional, person is allow to have empty group. The following diagram shows the relationship between
Person
and Group
.
A UniqueGroupList
is also implemented to keep track of the existing groups.
It is a list of Group
that enforces no nulls and uniqueness between its elements and
supports a set of list operations.
The implementation of the Group
command constructor is shown below :
public GroupCommand(List<Index> indexes, String group) {
requireNonNull(indexes);
requireNonNull(group);
this.indexes = indexes;
this.group = group;
}
As you can see from the implementation, Group command requires two type of no null parameters
which are a list of Index and The first parameter provide the indexes of person(s) to be grouped. The
second input in the type of Group
stores the group name specified by the user or a showall String
to view
the existing group names. Before a new instance of GroupCommand
is being created,
the GroupCommandParser
will ensure that the input from the user is valid and is parsed to GroupCommand
in
correct data type.
The execution of the command is done in the following method :
public CommandResult executeUndoableCommand() throws CommandException {
CommandResult commandResult;
if (group.equalsIgnoreCase(SHOW_ALL_GROUP)) {
commandResult = showAllGroupName();
} else if (indexes.size() > 0) {
commandResult = setGroupToPerson();
} else {
throw new CommandException(MESSAGE__WRONG_SHOW_ALL_PARAMETER);
}
return commandResult;
}
As you can see from the implementation, the method will either call the showAllGroupName() or the setGroupToPerson to show the existing group names or to set the specified person(s) to a group.
showAllGroupName() is as shown :
private CommandResult showAllGroupName() {
return new CommandResult("Groups: " + model.getGroupList().toString()
.replaceAll("\\[", "").replaceAll("\\]", ""));
}
The mode.getGroupList() will eventually call the asObservableList() in the UniqueGroupList
which
returns back a list of group names.
Setting the group to person is as shown. It replaces the target person with a replicate of the same person that has an additional group field.
private CommandResult setGroupToPerson() throws CommandException {
List<ReadOnlyPerson> lastShownList = model.getFilteredPersonList();
for (Index index : indexes) {
if (index.getZeroBased() >= lastShownList.size()) {
throw new CommandException("Index " + index.toString() + " is invalid!");
}
ReadOnlyPerson personToGroup = lastShownList.get(index.getZeroBased());
try {
Person editedPerson = new Person(personToGroup.getName(), personToGroup.getPhone(),
personToGroup.getEmail(), personToGroup.getAddress(), personToGroup.getBirthday(),
new Group(group), personToGroup.getRemark(), personToGroup.getTags());
model.updatePerson(personToGroup, editedPerson);
} catch (DuplicatePersonException dpe) {
throw new CommandException(MESSAGE_DUPLICATE_PERSON);
} catch (IllegalValueException ive) {
throw new CommandException(ive.getMessage());
} catch (PersonNotFoundException pnfe) {
throw new CommandException("The target person cannot be missing");
}
}
model.updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS);
return new CommandResult(generateSuccessMessage());
}
After a series of function calls, the model.updatePerson() method will call the updateMasterGroupList() in the AddressBook
, and call setPerson() method in the UniquePersonList
.
UniquePersonList deals with the list of persons that enforces uniqueness between its elements
and supports a set of list operations. The following diagram shows the UML diagram of the class.
|
The updateMasterGroupList() method will update the list of Group
if the a new group is added or an old
group with no person.
It is implemented in the following way :
private void updateMasterGroupList(Group prevGroup) {
boolean isGroupPresent = false;
for (Person p : persons) {
if (p.getGroup().value.equals(prevGroup)) {
isGroupPresent = true;
}
}
if (!isGroupPresent) {
groups.delete(prevGroup);
}
}
The setPerson() method will check the validity of the target person and replicated person. It will only replace the target person if the target person exist and the replicated person is not a duplicate of another existing person.
setPerson() is implemented as shown :
public void setPerson(ReadOnlyPerson target, ReadOnlyPerson editedPerson)
throws DuplicatePersonException, PersonNotFoundException {
requireNonNull(editedPerson);
int index = internalList.indexOf(target);
if (index == -1) {
throw new PersonNotFoundException();
}
if (!target.equals(editedPerson) && internalList.contains(editedPerson)) {
throw new DuplicatePersonException();
}
internalList.set(index, new Person(editedPerson));
}
Suppose that the user has just launched the application.
Assuming a valid addressbook xml file exists (with numerous person data in it),
the UniquePersonList
and UniqueGroupList
will start storing a list of Person object with correspondence to the xml file.
Each person will either have a Group
or an empty Group
.
To view existing groups :
The user executes a GroupCommand
by calling group showall
, to view the existing groups. The name of the
groups will be displayed in the command feedback box.
To set group to person(s) :
The user executes a GroupCommand
by calling group 1 2 g/TEST1
, to set the 1st and 2nd person’s group to "TEST1" in the address book.
The existing group
will be replaced by the user input "TEST1" and the Persons’ object will be updated.
The user then executes another GroupCommand
by calling `group 2 3 4 5 g/ to ungroup the 2nd to 5th person.
| If the group command fails its execution due to invalid index(es), the list of person(s) will not be grouped. |
The following sequence diagram shows how the group operation works to show the names of all existing groups.
The following sequence diagram shows how the group operation works to group person(s):
The following activity diagram shows models what happened when GroupCommand
is executed.
Design Considerations
Aspect: Implementation of setting group to person
Alternative 1 (current choice): Replace and replicate the same Person
object with new Group
attribute
Pros: Make use of the existing method to update the person, no new method is needed to be
implement.
Cons: Replacing and replicate the person is unnecessary as group can be set to person directly.
Alternative 2: Set Group
to Person
with setter method in Person
class
Pros: Easy to implement.+
Cons: Implemented code is highly similar to existing method to update a person, since it is supposed
to check for exceptions and update associated group list.
Aspect: Update the list of existing groups
Alternative 1 (current choice): Update the list whenever a person’s group is being changed. Check then
delete the person’s previous group if it has no member.+
Pros: The list of groups id always readily updated
Cons: Has to iterate through the entire list of person to determine if the previous group is empty.
Alternative 2: Use Map to store the existing group and the number of associated persons
Pros: Easy to determine if the group is empty and easy to update the map of groups.
Cons: Maybe more tedious to implement.
Enhancement Added: List(group)
Enhanced List command to view a list of persons by specified group name.
Listing all persons : list
- Since V1.0
Shows a list of all persons or a specified group of persons in the address book.
Format: list [g/GROUP_NAME]
| This command is a view only command and ordering of persons in the listing of group is not reflected. |
Examples:
-
list
-
list g/Friends
Justification
List can be used to display the entire list of contacts.
It is further enhanced to complement the function of Group
by allowing user to
view a list of contacts by group. Instead of implementing the viewing of a group of contacts,
it is more intuitive for user to type list
command followed by the group name. Hence, making the command
intuitive for users.
List(group) mechanism
The list group mechanism is an enhanced feature of the original ListCommand
and ListCommandParser
.
It is facilitated by the ContainsKeywordsPredicate
in the Person > Model
package and
a FilteredList
of ReadOnlyPerson
, which resides inside the ModelManager
.
It allows the user to view a list of person in a user specified group.
The constructor of the enhanced ListCommand
requires a String
parameter predicate as shown :
public ListCommand(String predicate) {
this.listParameter = predicate;
predicate = predicate.isEmpty() ? predicate : predicate.substring(2).trim();
this.predicate = new ContainsKeywordsPredicate(Arrays.asList(predicate));
}
As you can see a new ContainsKeywordsPredicate()
object is instantiated to facilitate the filtering of the list of
persons.
ContainsKeywordsPredicate
implements the Predicate
interface and test if a person’s group or other fields
matches any of the keywords passed in. The code snippets follows show how the group keyword is being matched.
if (predicateType == 'g') {
assert keywords.size() == 1;
return (person.getGroup().value.equals(keywords.get(0).toString()));
}
The execution of command is implemented as shown :
public CommandResult execute() {
if (listParameter.isEmpty()) {
model.updateFilteredPersonList(PREDICATE_SHOW_ALL_PERSONS);
return new CommandResult(MESSAGE_LIST_ALL_SUCCESS);
}
model.updateFilteredPersonList(predicate);
if (model.getFilteredPersonList().size() == 0) {
return new CommandResult(getMessageForPersonListShownSummary(model.getFilteredPersonList().size())
+ " " + MESSAGE_LIST_WRONG_PARAMETER);
}
return new CommandResult(MESSAGE_LIST_GROUP_SUCCESS + listParameter.substring(2).trim());
}
As seen from the implementation, the ListCommand
will serve its original function to show a list of all persons if
the listParameter is empty, and get a list of filtered person if otherwise.
The mode.updateFilteredPersonList() will call the setPredicate method of the FilteredList
and update the list
persons displayed to user.
Suppose that the user has just launched the application. A list of all persons will be shown.
The user executes a ListCommand
by calling list g/groupname
to view a group of persons. The persons grouped in the specified will
be displayed in the contact tab.
The user executes another ListCommand
by calling list
, to view all persons stored in TunedIn.
The list of all persons will be displayed in the contact tab.
| If the list command fails its execution due to non-existence group, the current list view will remained unchanged. |
The following sequence diagram shows how the list operation works:
The following activity diagram models what happened when ListCommand
is executed.
Design Considerations
Aspect: Getting a list of persons in a particular group
Alternative 1 (current choice): Using FilteredList and Predicate
Pros: Make use of the existing logic and methods
Cons: Order Command dose not work directly on this filtered list
Alternative 2: Store a separate list of persons per group in xml format
Pros: Less complex logic, commands performed on this list will be saved and reflected
Cons: Implementation can be more tedious and duplicated records of persons will take up extra memory.
Enhancement Proposed:
-
Enhance Group command to show the list the existing group together with the name of group members and the respective number of members.
-
Add auto complete function to enhance the experience of CLI application.
-
Add relationship field to Person and Relationship command to show a relationship map between the contacts.
include::../UserGuide.adoc[tag=relationship] -
Set reminders to notify users about birthdays and events.
=== Reminder Map :remind
- Coming in V2.0
Allows the user to set reminders to be notified on important dates and events.
Format: remind d/DATE t/TIME e/EVENT
Examples:
* remind d/13-11-2017 t/2359 e/Party


No. It does not mention the base cases.
A recursive definition (or program) must have two parts:
Here is an expanded version of fib(N)
:
fib( ___ ) = _____ (base case) fib( ___ ) = _____ (base case) fib( N ) = fib( N-1 ) + fib( N-2 )
| Fibonacci Series | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| N | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| fib(N) | 1 | 1 | 2 | 3 | 5 | 8 | 13 | 21 | 34 | 55 |


?<^>IK
ACED
NEW
YORK
BOTANICAL:
GARDEN
01029195
^Ic—uJlu
AujLs.
/&
-cUs
,
7
THE
NE^V
YORK
BOTANICAL
GARDEN
mi
ÀO
exploration
of
PORTO
RICO
mona
Island
-À-ÀJo
fh
À/hctU
j
JfsŽeuUA^
N.
L.
Britton
J.
F.
Cowell
W.
E.
HESS
COLLECTORS
FEB.
20-26,
1914
01029195
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


Change Password
Error
×
Success
×
Update New Password
Current Password
New Password
Confirm New Password
Update Password
Updating…


| Name | Kind | Description |
| Object | class | |
| Observable | class | |
| Observer | class | |
| observers | attribute | |
| oggPlayers | attribute | |
| OggVorbisPlayer | class | |
| open | operation | |
| open | operation | |
| open | operation | |
| OpenGl | class diagram | |
| OpenGlFactory | class | |
| OpenGlManager | class | |
| OrientatedPoint | class | |
| orientatedPoints | attribute |


--- title: "Neural Networks in R with nnet package - Harry Rowe" slug: "jun2018" date: 2018-06-19 ---
The abstract of the talk and link to presented material are below.
This talk will cover a simple example of neural network using nnet package. The talk would show example of continuous output and classifier (using iris dataset) and show tuning of classifier with repeated cross validation.