Contents
Module
23: Machine Learning Toolkit (App)
23.2.3. Lasso (least absolute shrinkage and selection operator)
23.2.7. Support vector machine (SVM Regression)
23.2.8. Neural Network Regression.
23.3.2. Nearest neighbors (KNN)
23.4. Self-organizing Map (SOM)
23.4.1. Unsupervised SOM (Clustering model)
23.4.2. Supervised SOM (Classification model)
23.4.3. Distributed Ensemble SOM (Advanced Classification SOM)
23.4.4. Ensemble Boosting SOM (Advanced Classification SOM)
Machine
Learning Toolkit (MLT) is a critical app in i2G data analytics
workflow. MLT on i2G offers the most advanced predictive algorithms including
both regression and classification. It also contains non-linear predictor
functions to model non-linear relationship between the input curves and the
target curve. Self-organizing Map is another advanced module built specifically
for facies classification by both supervised and unsupervised algorithms.
Key values:
o
Extraction of meaningful insights from
your data and information sources
o
Robust algorithms designed by
geoscientists and machine learning experts
o
Reproducible results by allowing seed
number input
o
Flexibility in conﬁguring model inputs
and architectures
o
Easy-to-use and adjustable workflow
interface
o
Availability of different model
validation metrics: offer different ways to assess training and predicting
capacity: training/loss error/accuracy cross-plot as well as a confusion matrix
·
Machine Learning Toolkit on i2G
platform is an advanced tool that offers many state-of-the-art algorithms in
the industry. They are divided into 2 groups, namely Regression and
Classification.
·
Fundamentally, classification is about
predicting a label (discrete properties such as facies) and regression is about
predicting a quantity (continuous properties such as permeability).
·
Before running any ML technique, the
user is required to create a new ML
model.
Figure 23‑1 Interface of Machine
Learning Toolkit app
The interface of machine learning app contains
three main regions: Tool Bar, Working
Area (A and B) and Project List
(C). The Tool Bar has 7 buttons
Table 23‑1 Buttons in Tool Bar
of MLT app
|
No |
Name |
Note |
|
1 |
“DATA SELECTION” tab |
Open the tab to select input data, including
input curves, target curve and input dataset for training/verify/ prediction |
|
2 |
“MODEL SELECTION” tab |
Open the tab to select machine learning
algorithms |
|
3 |
“TRAINING AND PREDICTION” tab |
Open the tab to execute the training,
validation and prediction process |
|
4 |
“OPEN” button |
Open other project(s) |
|
5 |
“SAVE” button |
Save the current project(s) |
|
6 |
“NEW” button |
Create a new project(s) |
|
7 |
Setting button |
Open a form for setting the text size |
Table 23‑2 Three separate spaces in the working areas
|
Area |
Note |
|
A |
Select input curves and the target curve |
|
B |
Dataset for training, verification and
prediction. These datasets should be dragged and dropped from project data
tree on the right (C) |
|
C |
List of projects. The user needs to select a
dataset, drop them to area B |
To build a machine learning model:
Step 1.
Go to https://ai.i2g.cloud/
Step 2.
Go to DATA
SELECTION tab > go to project list > select dataset for getting
training, verification and prediction data, then drag and drop them to area B
in the middle
Step 3.
Go to input selection area A on the left and select
one “Target” curve and input curves. The user can select them by curves name , curve
family or family group . Users
can click on the button ( ) to add input curve.
Step 4.
Select MODEL
SELECTION tab > Select the type of model under “Type Selection”
> configure model architecture by adjusting model parameter
Figure 23‑2 configure model architecture in MLT
Step 5.
Select TRAINING
AND PREDICTION tab
Figure 23‑3 Training and Prediction tab in MLT
Table 23‑3 Buttons in Training and Prediction tab in MLT
|
Button |
Note |
|
Active |
Activate/deactivate the selected dataset |
|
Filter |
Open a form to discriminate the input data |
|
Input Curve |
Select the input curve from the dataset |
|
Train |
Tab for configuring training data |
|
Verify |
Tab for configuring verifying data |
|
Predict |
Tab for configuring prediction data |
|
Run Now |
Run the current tab: Train or Verify or Predict |
|
Run All |
Run all tabs: Train/Verify/Predict |
Figure 23‑4 The Discriminator dialog of the Training and
Prediction tab in MLT
Table 23‑4 Buttons in Discriminator dialog
|
Button |
Note |
|
Activated/inactive |
Select to activate/deactivate the filter |
|
Delete |
Delete the selected filter |
|
Add |
Add a filter. User can select either AND or OR |
To
create a filter before training a machine learning model:
Step 1.
Select filter icon in front of the dataset
Step 2.
Click this icon to set it to “Activated”
Step 3.
Select the curve used for discrimination > select
the comparison operators > input a value or select a curve to compare to
Step 4.
Click OK
This is a linear approach to modelling the relationship
between the input variables and output variable. The relationships are modeled
using linear predictor functions, so called linear models, whose unknown model
parameters are estimated from the data. Like all forms of regression analysis,
linear regression focuses on the conditional probability distribution of the outputs
given the values of the inputs, rather than on the joint probability
distribution of all of these variables, which is the domain of multivariate
analysis. All parameters of linear regression model are set as default and will
not be changed by the users.
Fit Intercept: (Boolean, default True) this parameter is used
to decide whether to calculate the intercept for this model. If set to False,
no intercept will be used in calculations (e.g. data is expected to be already
centered). In other words, the fitting line for the model is forced to pass the
origin (0, 0). If set to True, the line of best fit can "fit" the
y-axis. This means the line will not pass the origin.
Normalize: (Boolean, default True) this parameter is ignored
when the parameter Fit Intercept is set to False. If True, the inputs X will be
normalized to the range (-1, 1) before regression by subtracting the mean and
dividing by the standard deviation.
This is a regression method that finds the relationship
between inputs and outputs. Basically, that relationship is assumed to be a
model, which can be a mapping function, or some mapping rules, connecting the
two data. All parameters of the mapping model are ordinarily optimized based on
least squared error. This traditional approach will not work well if the
dataset is composed of outliers. In order to avoid the effect of outliers,
Huber loss function is introduced. Basically, Huber function is a penalty
function that is quadratic when the error is small, and is linear if the error
is large.
The input parameters are as follows.
Fit Intercept: (Boolean, default True) this parameter is used
to decide whether to calculate the intercept for this model. If set to False,
no intercept will be used in calculations (i.e. the data is already centered
around the origin.). In other words, the fitting curve for the model is forced
to pass the origin (0, 0). If set to True, the curve of best fit is allowed not
to pass the origin.
Tolerance: (real value, default 0.0001) is a threshold to
stop the training process. The iteration will stop if the maximum of projected
gradients with respect to all variables of the objective function is smaller
than Tol.
Alpha: (real value, default 1) this is the regularize
parameter, which is used to avoid overfitting. Increasing the value of alpha
results in less overfitting but also greater bias.
Epsilon: (real value greater than 1.0, default 2) this
parameter controls the number of samples that should be classified as outliers.
The smaller the epsilon, the more robust it is to outliers.
Max Number of Iterations: (integer, default 1000) this
parameter determines the maximum number of iterations that the fitting
algorithm should run for.
Warm Start: (Boolean, default True) This is useful if the
stored attributes of a previously used model has to be reused. If set to False,
then the coefficients will be rewritten for every call to fit.
23.2.3.
Lasso (least absolute shrinkage and selection operator)
This is a regression analysis method that performs both
variable selection and regularization in order to enhance the prediction
accuracy and interpretability of the statistical model it produces.
The input parameters for this model are as follows.
Random State: (integer) this parameter determines the seed of
the pseudo random number generator that selects a random feature to update.
Max Number of Iteration: (integer, default 1000) this is the
maximum number of iterations that the training process goes through.
Alpha: (real value, default 1) this is the coefficient
determining the relationship between output errors and the variance of the
inputs. Alpha = 0 is equivalent to an ordinary least square, solved by the
Linear Regression object. For numerical reasons, using Alpha = 0 with the Lasso
object is not advised. Given this, you should use the Linear Regression object.
Tolerance: (real value, default 0.0001) is the tolerance for
the optimization: if the updates are smaller than tolerance, the optimization
code checks the dual gap for optimality and continues until it is smaller than
Tolerance value.
This is a prediction model that uses a tree-like graph of
decisions and their possible consequences, including chance event outcomes,
resource costs, and utility. It breaks down a dataset into smaller and smaller
subsets while at the same time an associated decision tree is incrementally
developed. The final result is a tree with decision nodes and leaf nodes. A
decision node has two or more branches representing values for the attribute
tested. Each leaf node represents a decision on the numerical target. The
topmost decision node in a tree which corresponds to the best predictor is
called root node.
Input parameters for this model are as follows.
Max Depth of Trees: (integer, default 3) this parameter
determines the maximum depth of the tree. If “0”, then nodes are expanded until
all leaves are pure or until all leaves contain less than min_samples_split
samples.
Max Features: (integer, default 1) this is the number of
features to consider when looking for the best split.
Ranking Criterion: (integer, default “mse”) The function to
measure the quality of a split. Supported criteria are “mse” for the mean
squared error, which is equal to variance reduction as feature selection
criterion and minimizes the L2 loss using the mean of each terminal node,
“friedman_mse”, which uses mean squared error with Friedman’s improvement score
for potential splits, and “mae” for the mean absolute error, which minimizes
the L1 loss using the median of each terminal node.
Random State: (integer) this is the seed used by the random
number generator.
Splitter: (default “random”) The strategy used to choose the
split at each node. Supported strategies are “best” to choose the best split
and “random” to choose the best random split.
This is a regression method that constructs a multiple of
decision trees at training time and outputs the mean prediction of the
individual trees. This approach overcomes the overfitting behavior of single
decision trees. The collection of decision trees is generated such that each
individual tree is uncorrelated with the others by using different bootstrapped
samples from the training data.
The input parameters of the random forest regressor are as
follows.
Number of Estimators: (integer, default 150) is the number of
trees in the forest.
Max Depth: (integer, default 1) is the maximum depth of the
tree. If “0”, then nodes are expanded until all leaves are pure.
Max Features: the number of input features is used when
looking for the best split. The value of this parameter is the same as in
Decision tree.
Boostrap: (Boolean, default True) to determine whether
bootstrap samples are used when building trees. If False, the whole dataset is
used to build each tree.
Ranking Criterion: (default “mse”) The function to measure
the quality of a split. Supported criteria are “mse” for the mean squared
error, which is equal to variance reduction as feature selection criterion, and
“mae” for the mean absolute error.
Random State: is the seed used by the random number generator.
XGBoost stands for extreme gradient boosting method, which is
used for supervised learning problems, where we use the training data (with
multiple features) xi to predict a target variable yi. is an efficient and
scalable implementation of gradient boosting algorithm. Function estimation is
inspected from the aspect of numerical optimization in function space, rather
than parameter space. This is a more regularized model formalization to control
over-fitting, which gives it better performance than traditional gradient
boosting method.
Input parameters of this model are as follow.
Number of Estimators: (integer, default 150) number of trees
created.
Max Depth: (integer, default 5) Maximum depth of a tree.
Increasing this value will make the model more complex and more likely to
overfit. Beware that XGBoost aggressively consumes memory when training a deep
tree.
Gamma: (default 0.5) Minimum loss reduction required to make
a further partition on a leaf node of the tree. The larger gamma is, the more
conservative the algorithm will be. Range [0, ꝏ].
Booster: (Default “gbtree”) Which booster to use. Can be
gbtree, gblinear or dart; gbtree and dart use tree based models while gblinear
uses linear functions.
Regularization alpha: (integer, default 1) L1 regularization
term on weights. Increasing this value will make model more conservative.
Regularization lambda: (integer, default 1) L2 regularization
term on weights. Increasing this value will make model more conservative.
Random State: is the seed used by the random number
generator.
23.2.7.
Support vector machine (SVM Regression)
Support vector machine for regression works in a way that is
almost the same as for classification problems, except that the maxima margin
is added by a tolerance factor epsilon, which is set in approximation to the
SVM such that it can adapt to the real input values. Input parameters of SVM
regression model are as follows.
Kernel: (default “rbf”) name of kernel function
C: (default 2) this is the parameter for the soft margin cost
function, which controls the influence of each individual support vector. A
large C gives you low bias and high variance, which means you penalize the cost
of error a lot. A small C gives you higher bias and lower variance, which means
higher generalization.
Gamma: (default 0.1) kernel parameter for ‘rbf’, ‘poly’ and
‘sigmoid’. This parameter can affect the data transformation behavior.
Intuitively, a small gamma value means two points can be considered similar
even if are far from each other. In the other hand, a large gamma value means
two points are considered similar just if they are close to each other.
Degree: (default 2) is the degree of the polynomial kernel
function (‘poly’). Ignored by all other kernels.
Tolerance: (default 0.001) Tolerance for stopping criterion..
Max Number of Iterations: (default 100) Hard limit on
iterations within solver, or -1 for no limit.
23.2.8.
Neural Network Regression
It is a class of feedforward artificial neural network. A
neural network consists of three types of layers of nodes, including input
layer, hidden layers, and output layer. Except for the input nodes, each of
other nodes is a neuron that uses a nonlinear activation function. NN can be
used for both classification and regression problems. The supervised learning
technique utilized for NN is backpropagation algorithm. Input parameters for
this model are defined as follows.
Solver: (default “lbfgs”) The solver for weight optimization.
·
‘lbfgs’ is an optimizer in the family of quasi-Newton
methods.
·
‘sgd’ refers to stochastic gradient descent.
·
‘adam’ refers to a stochastic gradient-based optimizer
proposed by Kingma, Diederik, and Jimmy Ba
·
‘Cg’ is the conjugate-gradient optimization algorithm.
Apart from the well-known backpropagation algorithm, users can also use
Conjugate Gradient as a training algorithm for Neural networks. All input
parameters for conjugate gradient neural network have the same meaning as those
in MLP.
Note: The
default solver ‘adam’ works pretty well on relatively large datasets (with
thousands of training samples or more) in terms of both training time and
validation score. For small datasets, however, ‘lbfgs’ can converge faster and
perform better.
Activation Function: (default “relu”) is the name of
activation function for hidden nodes.
·
‘identity’, no-op activation, useful to implement
linear bottleneck, returns f(x) = x
·
‘logistic’, the
logistic sigmoid function, returns f(x) = 1 / (1 + exp(-x)).
·
‘tanh’, the
hyperbolic tan function, returns f(x) = tanh(x).
·
‘relu’, the
rectified linear unit function, returns f(x) = max(0, x)
Max number of iterations: (integer, default 500) is the
maximum number of iterations. The solver iterates until convergence (determined
by the parameter ‘tolerance’) or this number of iterations. For stochastic
solvers (‘sgd’, ‘adam’), note that this determines the number of epochs (how
many times each data point will be used), not the number of gradient steps.
Tolerance: (default 0.0003) Tolerance for the optimization.
When the loss or score is not improving by at least Tol for two consecutive
iterations, convergence is considered to be reached and training stops.
Learning rate initialization: (default 0.001) It controls the
step-size in updating the weights. Only used when solver is ’sgd’ or ‘adam’.
This is a non-parametric supervised learning method used for
classification or regression. The goal is to create a model that predicts the
value of a target variable by learning simple decision rules inferred from the
data features. The decision tree is built by recursively selecting the best
attribute to split the data and expanding the leaf nodes of the tree until the
stopping cirterion is met. The choice of best split test condition is
determined by comparing the impurity of child nodes and also depends on which
impurity measurement is used. If the decision trees are too large, overfitting
may occur. Input parameters for decision tree classifiers are defined as
follows.
Ranking Criterion: (default “entropy”) is the function to
measure the quality of split.
·
“gini”: is for the Gini impurity. This is a measure of
how often a randomly chosen element from the set would be incorrectly labeled
if it was randomly labeled according to the distribution of labels in the
subset. It reaches its minimum (zero) when all cases in the node fall into a
single target category.
·
“entropy”: is for the information gain. Information
gain is used to decide which feature to split on at each step in building the
tree. In order to keep the tree small, at each step we should choose the split
that results in the purest daughter nodes, which correspond to the feature with
highest information gain with the output labels. The split with the highest
information gain will be taken as the first split and the process will continue
until all children nodes are pure, or until the information gain is 0.
Min samples split: (integer, default 5) is the minimum number
of samples required to split an internal node. The larger the min_samples is,
the bigger trees can be created.
Min Impurity Decreases: (Real values, default 0.01) is the
threshold for early stopping in tree growth. A node will split if its impurity
is above the threshold, otherwise it is a leaf. This value will also determine
the size of trees.
23.3.2.
Nearest neighbors (KNN)
This is a non-parametric method used for classification. The
input consists of the k closest training examples in the feature space. The
output is a class membership. An object is classified by a majority vote of its
neighbors, with the object being assigned to the class most common among its K
nearest neighbors (K is a positive integer, typically small). If K = 1, then
the object is simply assigned to the class of that single nearest neighbor.
Input parameters for this model is defined as follows.
Number of Neighbors: (default 100) is the number of closest
training samples to the testing sample.
P: (default 1) is the power parameter for the Minkowski
metric. It determines how to calculate the distance between samples. When p =
1, this is equivalent to using manhattan_distance (l1), and euclidean_distance
(l2) for p = 2. For arbitrary p, minkowski_distance (l_p) is used.
Distance Metric: (minkowski distance) determines the method
to calculate the distance between samples
This classification algorithm is named for the function used
at the core of the method, the logistic function. The logistic function, also
called the sigmoid function is an S-shaped curve that can take any real-valued
number and map it into a value between 0 and 1, but never exactly at those limits.
f = 1 / (1 + e^-value), where e is the base of the natural logarithms. There
can be many different equations used for logistic regression, for example: y =
e^(b0 + b1*x) / (1 + e^(b0 + b1*x)), where y is the predicted output, b0 is the
bias or intercept term and b1 is the coefficient for the single input value
(x). Each column in your input data has an associated b coefficient (a constant
real value) that must be learned from your training data.
Logistic regression is a linear method, but the predictions
are transformed using the logistic function. The impact of this is that we can
no longer understand the predictions as a linear combination of the inputs as
we can with linear regression.
Logistic regression models the probability of the default
class. In this model we use 30 logistic regression classifiers corresponding to
30 different default classes. For each classifier, the default class is fitted
against all the other classes, resulting in the probability of the data sample
being 1 of the 30 classes. In the prediction phase, the class with the highest
output probability will be assigned to the testing sample.
The setting parameters for this model are described as
follows.
C: (default 20) is the inverse of regularization strength.
Like in support vector machines, smaller values specify stronger
regularization.
Max Number of Iterations: (default 10000) Maximum number of
iterations taken for the solvers to converge.
Solver: (default “liblinear”) is the name of the algorithm to
use in the optimization problem.
A random forest is a meta estimator that fits a number of
decision tree classifiers on various sub-samples of the dataset and use
averaging to improve the predictive accuracy and control over-fitting. The
sub-sample size is always the same as the original input sample size but the
samples are drawn with replacement if bootstrap=True (default).
Input parameters for this method are defined as follows.
Number of Trees: (default 150) The number of decision trees
in the forest
Ranking Criterion: (default “entropy”) The function to
measure the quality of a split. This is the same as in decision tree.
Min Samples Split: (default 5) The minimum number of samples
required to split an internal node. This is the same as in decision tree.
Min Impurity Decrease: (default 0.0003) Threshold for early
stopping in tree growth. This is the same as in decision tree.
This is a multilayer perceptron network for classification
problem. This model optimizes the log-loss function using LBFGS or stochastic
gradient descent. Input parameters for this model are defined as follows.
Activation Function: (default “relu”) is the name of
activation function for hidden layers.
Optimization Algorithm: (default “backprop”) is the name of
training algorithm, which is either backpropagation or evolution strategy
algorithm.
Backpropagation algorithm works best with a large number of
epochs.
Evolution algorithm is preferable with smaller number of
epochs, about 1000.
Learning Rate: (default 0.001) It controls the step-size in
updating the weights.
Number of Epochs: (default 1000) maximum number of training
iterations.
Optimizer: (default “adam”) is the solver for weight
optimization.
Warm up: (default “false”) is to determine the initial values
of weights. When set to True, the model will run with batch_size = 1 and
num_epochs = 1 to get the initial weights, otherwise, it just randomizes the
initial weights. After this process, the model will run the training process as
set by other parameters.
Boosting Ops: (default 0) this parameter is only used for
evolution algorithm. This parameter determines the number of times that the
weights are further updated based on the accuracy after the training process
based on the loss function finishes. Default is 100.
Sigma: (default 0.01) this parameter is only used for
evolution algorithm. This parameter determines the variance size of the
Gaussian distribution used for randomizing the weights.
Population: (default 50) is the number of sets of randomized
weights for each epoch. This parameter is only used for evolution algorithm.
Decay: (default 0.000001) is to determine the decaying rate
of weight updates.
23.4.
Self-organizing Map (SOM)
Self-Organizing Maps (SOMs) is a type of artificial neural
network that is trained using unsupervised learning to produce a
low-dimensional (typically two-dimensional), discretized representation of the
input space of the training samples, called a map, and is therefore a method to
do dimensionality reduction. Self-organizing maps apply competitive learning in
the sense that they use a neighborhood function to preserve the topological
properties of the input space. This makes SOMs useful for visualization by
creating low-dimensional views of high-dimensional data.
SOM can provide an interpretation of the dataset about data
distribution, the number of clusters and some other visualizations. Thus, SOM
is traditionally considered as both a dimensional reduction tool and a
clustering tool. It has been shown that while self-organizing maps with a small
number of nodes behave in a way that is similar to the K-means algorithm,
larger self-organizing maps rearrange data in a way that is fundamentally
topological in character.
In general, the weights of the neurons are initialized either
to small random values, or by randomly choosing samples from the training data
to initialize the weights of neurons, or sampled evenly on the plane formed by
the two largest principal component eigenvectors.
The self-organizing system in SOM is a set of nodes (or
neurons) connected to each other via a topology of rectangle. This set of nodes
is called a map. Each neuron has several nearest neighbors (4 or 8 with
rectangular topology). At each training step, an input vector Xi is introduced
to the map, using the Euclidean distance, the different between Xi and each
neuron in the map is calculated. The most similar neuron to the selected sample
is called the winning node or the best-matching unit (BMU). The weight vector
of the BMU is then updated by a learning rule:
W_i (t+1)= W_i (t)+
θ(t).α(t).(X_i - W_i (t))
Where W_i (t+1) is the newly updated weight vector of BMU at
time t+1. α(t) is the learning rate which decreases over each training
iteration. By this learning rule, the BMU is moved closer to the chosen input
vector. Instead of applying the winner-takes-all principal, the BMU’s
neighboring neurons can also be updated. The neighborhood of BMU is determined
by BMU’s radius. The learning rate of BMU, α(t), is decaying after each
updating iteration as follows:
α(t)=α_0/(1+ decay_rate *t)
Where, t is the maximum number of update iterations; α_0 is
the initial learning rate.
θ(t) is the neighboring index determining how much a
neighboring neuron is updated in each iteration. Depending on different
neighboring methods, θ(t) can be calculated differently as:
·
Bubble method: all neurons inside the distance from
the BMU will be updated.
θ(t)={■(1 if dist≤σ(t)@0 if
dist>σ(t))┤
Where, σ(t) is the distance function between BMU and other
neurons, which also decays during the update process.
·
Gaussian method: all neurons will be updated with the
distance index defined as
θ(t)=e^(-〖dist〗^2/(2〖σ(t)〗^2 ))
Where, “dist” is the Euclidean distance between the BMU and
other neurons.
tIn those methods, The distance function σ(t) is defined as
σ(t)=σ_0/(1+sigma_decay_rate *t)
Where σ_0 is the initial neighboring radius, and the
sigma_decay_rate determines how much the distance function decays after each
iteration.
23.4.1.
Unsupervised SOM (Clustering model)
This is a traditional use of the SOM as discussed above. The
input data samples are clustered using SOM. Users can manage following
parameters:
Number of Columns: (integer, default 10) This is the number
of columns of neurons in the topology of rectangle of the SOM.
Number of Rows: (integer, default 10) This is the number of
rows of neurons in the topology of rectangle of the SOM.
Random State: (integer) this is the seed used by the random
number generator.
Learning Decay Rate: (real) is the decay_rate.
Learning Rate: (real, in range (0, 1)) is the initial
learning rate α_0.
Neighborhood: (bubble or Gaussian) is the method to determine
the neighboring index θ(t).
Weight Initialization: (random, sample, or PCA) is the method
to initialize the weights of all neurons in the SOM.
Random: the weights are generated as small random values,
Sample: the weights are generated by randomly choosing
samples from the training data
PCA: the weights are sampled evenly on the plane formed by
the two largest principal component eigenvectors of the training data.
Sigma: (real) is the initial neighboring radius, σ_0.
Sigma Decay Rate: (real) is the rate for the neighboring
radius to decay over updating iterations.
Batch Size: (integer) is the number of samples in the same
batch during learning phase.
Number of Clusters: (integer) is the number of clusters that
users want to divide the data using SOM.
23.4.2.
Supervised SOM (Classification model)
This is a combination method between the traditional SOM and
the Learning Vector Quantization (LVQ) algorithm to form a classification
version of SOM. SOM will be supervised trained using labeled training data to
create a classification model.
The supervised training process for SSOM includes two phases
as depicted in the below figure
Figure 23‑5 Two phases of the supervised training process for
SSOM
Unsupervised SOM training phase follows traditional SOM
algorithm. The input training dataset is used to generate the clustering model
of the SOM.
After the first phase, all neurons in the SOM are labeled
based on the closest training samples.
Supervised training phase is based on LVQ algorithm, which
moves the labeled neurons closer to the training samples having the same
labels, or moves the neurons further to the sample having different labels.
Users can manage following parameters:
Number of Columns: (integer, default 10) This is the number
of columns of neurons in the topology of rectangle of the SOM.
Number of Rows: (integer, default 10) This is the number of
rows of neurons in the topology of rectangle of the SOM.
Random State: (integer) this is the seed used by the random
number generator.
Learning Decay Rate: (real) is the decay_rate.
Learning Rate: (real, in range (0, 1)) is the initial learning
rate α_0.
Neighborhood: (bubble or Gaussian) is the method to determine
the neighboring index θ(t).
Weight Initialization: (random, sample, or PCA) is the method
to initialize the weights of all neurons in the SOM.
Random: the weights are generated as small random values,
Sample: the weights are generated by randomly choosing
samples from the training data
PCA: the weights are sampled evenly on the plane formed by
the two largest principal component eigenvectors of the training data.
Sigma: (real) is the initial neighboring radius, σ_0.
Sigma Decay Rate: (real) is the rate for the neighboring
radius to decay over updating iterations.
Sup Batch Size: (integer) is the number of samples in the
same batch during supervised learning phase.
Sup Number of Iterations: (integer) is maximum number of
supervised training iterations.
Sup Batch Size: (integer) is the number of samples in the
same batch during supervised learning phase.
Sup Number of Iterations: (integer) is maximum number of
supervised training iterations.
Unsup Batch Size: (integer) is the number of samples in the
same batch during unsupervised learning phase.
Unsup Number of Iterations: (integer) is maximum number of
unsupervised training iterations.
23.4.3.
Distributed Ensemble SOM (Advanced Classification SOM)
This is an improved classification model based on supervised
SOM. In this model, multiple SOM ensembles are generated based on multiple
subsets of input features. Each feature subset is selected either by random or
by weighting method. One feature subset is used to create a classification SOM
model. Since the size of feature subset is much smaller than the original
feature set, the complexity of each ensemble SOM structure can be reduced.
Moreover, if the original data is divided into multiple subsets with different
feature sets, the information of the training data can be closer analyzed under
different angles. This results in a better performance of the classification
algorithm. Also, the combination of multiple ensemble SOM may help reduce the variance
of the classification errors. From a set of local decisions provided my
multiple ensemble SOMs, the test sample is assigned a label based on the
majority voting rule.
In this method, the training feature set is divided into
multiple feature subset. This looks like a system managed by multiple
distributed sensors, each of which contributes a different set of measurements.
The name of this method is motivated from this implication.
In this method, users can manage following parameters:
Number of Estimator: (integer, default 30) is the number of
ensemble SOMs created in the algorithm.
Random State: (integer) this is the seed used by the random
number generator.
Size of Estimator: (integer, default 4) is the size of the
ensemble SOMs with a square topology. Here, “Size” is the number of rows as
well as the number of columns of each ensemble SOM.
Learning Decay Rate: (real) is the decay_rate.
Learning Rate: (real) is the initial learning rate α_0.
Neighborhood: (bubble or Gaussian) is the method to determine
the neighboring index θ(t).
Sigma: (real) is the initial neighboring radius, σ_0.
Sigma Decay Rate: (real) is the rate for the neighboring
radius to decay over updating iterations.
Sup Batch Size: (integer) is the number of samples in the
same batch during supervised learning phase.
Sup Number of Iterations: (integer) is maximum number of
supervised training iterations.
Subset Size: (real, in the range (0, 1]) is the size of
training data selected for SOM learning processes.
Sup Number of Iterations: (integer) is maximum number of
supervised training iterations.
Unsup Batch Size: (integer) is the number of samples in the
same batch during unsupervised learning phase.
Unsup Number of Iterations: (integer) is maximum number of
unsupervised training iterations.
Feature Selection: (random or weights) is the method to
generate feature subsets
Random: each feature subset is generated by uniformly
selection from a pool of original feature set.
Weights: the features are first assigned weights according to
their correlation coefficients with the labels. Each feature set is made from a
weighted selection from the original feature set. Features with higher weights
tend to be selected more often into feature subsets than the ones with smaller
weights.
23.4.4.
Ensemble Boosting SOM (Advanced Classification SOM)
Motivated from boosting algorithm using multiple ensembles.
This approach aims at creating multiple simple SOM models, each of which is
created from a subset of training data. In general, each training subset is randomly
selected from the training dataset. Each training subset is used to train a
supervised SOM model. Decisions from multiple SOMs will be fused based on the
majority voting rule. This approach may produce a better performance than
single supervised SOM model since it helps reduce the variance of the
classification errors.
In this method, users can manage following parameters:
Number of Estimator: (integer, default 50) is the number of
ensemble SOMs created in the algorithm.
Random State: (integer) this is the seed used by the random
number generator.
Size of Estimator: (integer, default 4) is the size of the
ensemble SOMs with a square topology. Here, “Size” is the number of rows as
well as the number of columns of each ensemble SOM.
Weight Initialization: (random, sample, or PCA) is the method
to initialize the weights of all neurons in the SOM.
Random: the weights are generated as small random values,
Sample: the weights are generated by randomly choosing
samples from the training data
PCA: the weights are sampled evenly on the plane formed by
the two largest principal component eigenvectors of the training data.
Learning Decay Rate: (real) is the decay_rate of the learning
rate.
Learning Rate: (real) is the initial learning rate α_0.
Neighborhood: (bubble or Gaussian) is the method to determine
the neighboring index θ(t).
Sigma: (real) is the initial neighboring radius, σ_0.
Sigma Decay Rate: (real) is the rate for the neighboring
radius to decay over updating iterations.
Sup Batch Size: (integer) is the number of samples in the
same batch during supervised learning phase.
Sup Number of Iterations: (integer) is maximum number of
supervised training iterations.
Subset Size: (real, in the range (0, 1]) is the size of
training data selected for SOM learning processes.
Sup Number of Iterations: (integer) is maximum number of
supervised training iterations.
Unsup Batch Size: (integer) is the number of samples in the
same batch during unsupervised learning phase.
Unsup Number of Iterations: (integer) is maximum number of
unsupervised training iterations.
This is a nonlinear approach to model the relationship
between the input curves and the target curve. The relationships are modeled
using nonlinear predictor functions, so called nonlinear models, whose unknown
model parameters are estimated from the data. The nonlinear relationship
function is defined by the user, where the variables x1, x2, … correspond to
the input curves from top to bottom, respectively.
Table 23‑5 Guides to input nonlinear functions
|
Algebra expression |
Input Syntax |
Meaning |
|
a . x |
a*x |
a multiplied by x |
|
a : x |
a/x |
a divided by x |
|
a + x |
a+x |
a plus x |
|
a - x |
a-x |
a minus x |
|
|
a**x |
a power x |
|
Ln(x) |
log(x) |
Natural logarithm of x |
|
Log(x) |
log(x)/log(10) |
Base 10 logarithm of x |
|
Loga(x) |
log(x)/log(a) |
Base a logarithm of x |
|
e |
e |
Natural number (2.71828). No other
parameter named e is permitted. |


Must be at least 3 characters
Must be less than 25 characters
Must be at least 5 characters
Must be less than 35 characters


85 VIII. OOP with Procedures The idea of object oriented programming is often taught in a way that makes it seem as if a special object oriented programming language is necessary. In fact, any language with ﬁrst class procedures and lexical scope allows objects to be implemented explicitly; this is a useful exercise to help demystify objects. The central idea of this implementation is that an object is represented as a dispatch procedure that takes a message as input and reports the corresponding method. In this section we start with a stripped-down example to show how local state works, and build up to full implementations of class/instance and prototyping OOP. A. Local State with Script Variables This script implements an object class, a type of object, namely the counter class. In this ﬁrst simpliﬁed version there is only one method, so no explicit message passing is necessary. When the make a counter block is called, it reports a procedure, the ringed script inside its body. That procedure implements a speciﬁc counter object, an instance of the counter class. When invoked, a counter instance increases and reports its count variable. Each counter has its own local count: This example will repay careful study, because it isn’t obvious why each instance has a separate count. From the point of view of the make a counter procedure, each invocation causes a new count variable to be created. Usually such script variables are temporary, going out of existence when the script ends. But this one is special, because make a counter returns another script that makes reference to the count variable, so it remains active.


Invoke-TaskFromISE.ps1, Show-BuildGraph.ps1, Show-BuildTree.ps1
Show-BuildTree.ps1
Upstream
tells to show upstream tasks for each task.Minor inner changes.
/?
file
- fixed propagation of the sourceGet-Variable
with $PSBoundParameters
Users ask for a common cmd.exe helper. I was reluctant for some reasons but now is a good time, perhaps. Here is the proposal based on my own practice.
ib
.Note that scripts should continue to use the command Invoke-Build
. The ib
commands should be used with cmd.exe (ib.cmd) and in interactive PowerShell
(alias of Invoke-Build.ps1 defined in the profile).
Custom tasks
file
. It is not a big deal but it
still may be useful. Besides, it comes with examples of incremental tasks.Task help (experimentally). The Jobs is an array, not a text. With many jobs this avoids dropped Synopsis on default formatting.
New script Convert-psake.ps1 converts psake build scripts to Invoke-Build.
Fixed text of error messages on explicitly set task errors.
Revised errors
Errors
contains error objects, not messages.Custom tasks
retry
so that the function Invoke-RetryAction
may be used on its own, see an example in Retry.build.ps1.Custom tasks retry
and test
Inputs
and Outputs
are supported, Partial
is not.Jobs
.test
: an upstream error is propagated.Property Jobs
Jobs
of internal task objects is documented and can be used
for reading by custom tasks and by external tools for task analysis.Corrected internal processing order. Because Done
still may fail a task it
should be invoked before storing a checkpoint for a persistent build.
New sample custom task retry
, see Tasks\Retry. Special parameters are
RetryTimeout
and RetryInterval
, similar to Set-BitsTransfer
.
Revised build output
Summary
was not originally introduced.Explicitly set task errors
$Task.Error
then it is still treated as
failed. The build does not stop in this case. This can be used effectively is
special cases, e.g. in tasks like test
.Sample custom task test
test
-
Test-tasks are allowed to fail without breaking the build. Errors are counted
and written as usual. test
's jobs are optional simple references followed
by a single action. If a reference fails an action is skipped.Package
Fixed incorrect build time written with Summary
.
This release introduces new task programming techniques and sample tools.
Added new task
parameters Data
, Done
, and Source
. They are designed for
custom tasks, wrappers which add extra features and introduce new DSL commands.
Data
and Done
may be useful in normal tasks. Source
is for wrappers only.
Sample custom tasks:
check
-
Build scripts with check
tasks represent sort of check-lists. As soon as a
check
passes it is never invoked again, even in next builds. Scripts are
invoked repeatedly until all checks are passed (desired state achieved).
repeat
-
Build scripts with repeat
tasks represent sort of schedules. They are invoked
periodically. Each repeat
task is invoked or skipped according to its defined
time span and stored last done time.
DSL commands check
and repeat
are defined in scripts *.tasks.ps1
. They
are dot-sourced in build scripts before the first use of new custom tasks.
Commands check
and repeat
are used almost in the same way as task
.
These tools are ready to use in scripts but not included to the package. They are extensions, not parts of the engine. The engine only makes them possible. Q: Should they be included to the package anyway?
TODO: Think of a custom task test
which is allowed to fail without breaking
the build. Some minor support from the engine may be needed for proper error
counting and reporting.
P.S. Imagine, one may want to request a new feature, say, -Retry...
for tasks.
Perhaps this will not be accepted after investigation. Well, it is now up to an
author to define such a task with another DSL name and any required parameters:
# Import task library for "retry".
. Retry.tasks.ps1
# Synopsis: Note that help comments are possible for custom tasks.
retry TaskName -RetryCount 5 -RetrySec 60 -ConfirmRetry {
...
}
Task help comments
Documentation comments
Help task ? returns objects describing tasks. Properties:
{}
# Synopsis: ...
Returned objects are formatted as three column table by default. If default formatting is not good enough use custom formatting, e.g.:
Invoke-Build ? | Format-Table -AutoSize
Invoke-Build ? | Format-List Name, Synopsis
Show-BuildTree.ps1
$Task, step 2. Potentially incompatible
$Task
is now constant, Enter|Exit-BuildTask
and Enter|Exit-BuildJob
cannot override it, say, accidentally.Enter|Exit-BuildTask
do not accept a task as an argument,
use the automatic variable $Task
instead.Enter|Exit-BuildJob
do not accept a task as the first
argument, use $Task
instead. The job number became the first argument.With this step integration of the automatic variable $Task
is complete.
Default script resolution
The script specified by $env:InvokeBuildGetFile
(gets a non standard default
build file) is invoked with the full directory path as an argument. It may be
invoked several times during the directory branch search with each path passed
in. Old scripts should work fine but some of them may be simplified now.
Automatic variable $Task. Step 1
A new automatic variable $Task
represents the current task instance. It is
available for the task script blocks defined by parameters If
, Inputs
,
Outputs
, Jobs
and the event functions Enter|Exit-BuildTask
and
Enter|Exit-BuildJob
.
Why? Some advanced task scripts need this instance (e.g. shared between tasks).
A common variable $Task
seems to be simpler than use of a parameter in each
of 8 above code pieces. Let's keep parameters available for something else.
Potentially incompatible
Build scripts with the parameter $Task
or script variable $Task
may fail.
Rename this variable. The parameter $Task
is not good anyway because it
conflicts with Invoke-Build and cannot be used as the dynamic parameter.
As far as Enter|Exit-*
are invoked in the scope where $Task
is defined,
make sure they do not change it. Other task code may change it in its own
scope. But such hiding of the system variable is not recommended.
Step 2. The next version
Enter|Exit-BuildTask
and Enter|Exit-BuildJob
will not be accepting the task
as the first argument. The new variable $Task
should be used instead. Most of
scripts may be prepared now. Change of Enter|Exit-BuildJob
may be breaking,
the second parameter will become first.
Added missing Invoke-TaskFromISE.ps1.
Minor tweaks in code and help.
This version mostly completes changes announced for v2.7.
Invoke-Build
Summary
tells to write summary after build.Show-BuildTree.ps1
*
tells to show all root task trees.TabExpansionProfile.Invoke-Build.ps1
Persistent builds, incompatible change
Invoke-Build uses the new switch Resume
in order to resume persistent builds.
It makes use of persistent builds easier and avoids conflicts with dynamic
parameters and coming soon changes.
The new switch must be added to old commands which resume builds. Hopefully it should not break much because resuming is often supposed to be done manually.
Dynamic parameters
As far as Build.ps1 dynamic parameters work well, Invoke-Build.ps1 adopts them, too. Dynamic parameters make command lines simple and neat. Compare:
New way, it really cannot be simpler:
Invoke-Build -Configuration Release -Platform x64
Old way, still used in special cases:
Invoke-Build -Parameters @{Configuration = 'Release'; Platform = 'x64'}
Mind an extra bonus: TabExpansion works fine with dynamic parameters.
Coming soon in v2.7
Build.ps1 features to be moved to Invoke-Build:
Summary
to write summary after build.NoExit
will be dropped.Build.ps1: Adjusted for the new common parameter PipelineVariable.
Invoke-TaskFromISE.ps1 also supports the form task [...] -Name TaskName
.
Still, not all possible forms are recognized, see the script help notes.
Avoided a recently introduced internal variable exposed to tasks.
Invoke-TaskFromISE.ps1
This new script invokes the current task from the build script being edited in PowerShell ISE. It is invoked either in ISE or in PowerShell console. See the script help comments for the details, e.g. how to associate with shortcuts.
Easier persistent builds
Build script parameters are automatically exported and imported on persistent
builds. Custom Export-Build
and Import-Build
do not have to care of them.
Moreover, some script variables may be declared as parameters simply in order
to be persistent and Export-Build
and Import-Build
may be dropped if they
deal with these variables and do nothing else.
Reminder: checkpoint files from other versions must not be used.
Minor tweaks in help.
Build.ps1 - There was a subtle conflict between the parameter Checkpoint
and advanced resolution of File
. Instead of introducing caveats for File
and making things more complex we drop Checkpoint
, i.e. it should be used
with Invoke-Build.ps1, not with the command line helper Build.ps1.
Notes:
Function and variable names starting with *
are reserved for the engine. For
technical reasons they cannot be completely hidden from scripts. Scripts should
not use functions and variables with such names. It is unlikely that they ever
do this but this is possible and should be avoided.
Some changes in terminology and syntax, not breaking for now. Allowed to fail task references are now called "safe". They are created by the new command job (New-BuildJob) with the switch Safe. In other words,
DO (new):
task Task2 (job Task1 -Safe), { ... }
DON'T (old):
task Task2 @{ Task1 = 1 }, { ... }
The new syntax is less cryptic, self describing, and easy to extend.
The old syntax for now works as well. But it is deprecated, not documented, and very likely will stop working if the command job introduces more options.
Issue #1. Per user request, reduced density of the source code of Invoke-Build.ps1, for better readability, easier debugging, etc.
Joined two internal functions *U1
and *U2
.
Amended documentation.
The first line "Build ...": write resolved task names, i.e. write the actual
default task name instead of nothing or '.'
and task list instead of '*'
.
Demo scripts are excluded. They are more boring tests than useful examples. In any case they are available online at the project site.
Build.ps1: fixed issues on scripts with cmdlet binding parameters.
Replaced dark yellow build messages with cyan. Dark yellow looks like white or gray in Microsoft PowerShell "noble blue" consoles. Besides, MSBuild prints similar build messages as cyan.
Amended TabExpansionProfile.Invoke-Build.ps1. If it is used in ISE then
completion lists should show proper icons. If the referenced
TabExpansions2.ps1
is used then update it, too.
Fixed
Invoke-Build ** missing-directory
.**
.Amended TabExpansionProfile.Invoke-Build.ps1.
Finishing touches on dynamic parameters of Build.ps1.
Updated the wiki with information about recently added features.
Dynamic build script parameters in Build.ps1
If a build script parameters do not intersect with Build.ps1 parameters then they can be specified directly for Build.ps1.
Example. If a build script parameters are
param
(
$Platform = 'Win32',
$Configuration = 'Release'
)
then it is fine to call it naturally
Build -Platform x64 -Configuration Debug
instead of not so easy to type
Build -Parameters @{Platform = 'x64'; Configuration = 'Debug'}
Note that TabExpansion works with dynamic parameters.
TabExpansionProfile.Invoke-Build.ps1
This new script is TabExpansion2
profile with custom completers for
Invoke-Build.ps1 and Build.ps1. It can be used either directly with
TabExpansion2.ps1
or slightly adapted for other replacements of build-in TabExpansion2
.
It completes arguments of parameters Task (task names from a build file) and
File (normally suggests available .build.ps1 and .test.ps1 files).
Warning on script output
Output from scripts on adding tasks is treated as unexpected. It is intercepted and written as a warning. Firstly, this catches a common mistake. Example: the script outputs a script block instead of adding a task with it
task Task1
{
...
}
Secondly, this avoids noise data on getting tasks for analysis.
New special task ??
The task ??
is used to get tasks without invoking. It replaces the old not so
easy to use approach. This new simple code
$tasks = Invoke-Build ??
is used instead of
$null = Invoke-Build ? -Result result
$tasks = $Result.All
The task ?
is now used only to show brief task information.
This change does not affect normal build script scenarios. But wrapper scripts which get tasks for analysis like Build.ps1, Show-BuildGraph.ps1 should be upgraded.
Combined special tasks
?
and ??
can be combined with **
.
Show all tasks from all .test.ps1 files:
Invoke-Build ?, **
Get task dictionaries for all .test.ps1 files:
Invoke-Build ??, **
Note that the helper Build.ps1 supports these new features. In particular it can be used now for getting task dictionaries (it was able only to display, analyse, and etc. but not to return).
Other changes
The Get-BuildFileHook
is dropped. Wrapper scripts should provide a file if
the default is missing. They can use a copy of the function Get-BuildFile
.
This approach seems to be simple and natural comparing with a callback. For
example, see how Build.ps1 uses Get-BuildFile
and extends it.
Build.ps1
New switch NoExit
tells to prompt "Press enter to exit".
use
(Use-BuildAlias
) accepts MSBuild version strings (e.g. '4.0'
,
'2.0'
) and resolves them to paths using information from the registry.
Adapted Invoke-Build for Set-StrictMode -Version Latest
New special task **
invokes *
(all tasks, normally tests) for all files
*.test.ps1
found recursively in the current directory or a directory
specified by the parameter File
. It simplifies invocation of tests
represented by tasks in several scripts in a directory tree.
Renamed some test scripts to *.test.ps1
and made them called automatically
with the new special task **
.
Minor improvements in Invoke-Builds.ps1. The key File
in parameters is now
optional. The omitted one is resolved to the usual default build script. Added
a test.
Changed color of messages Build < tasks > < file > to dark green.
This version introduces major but mostly cosmetic changes in advanced features. Scripts using these features should be upgraded. If some scripts are not going to be upgraded then an old copy of tools can be used for building them. See Portable Build Scripts.
Renamed Write-BuildText
to Write-Build
.
Renamed Assert-BuildTrue
to Assert-Build
. This change is not breaking if
this function is used by its recommended alias assert
.
Renamed Enter-BuildScript
, Exit-BuildScript
to Enter-Build
, Exit-Build
.
Old names are misleading, events are invoked before and after a build, not a
build script.
Use-BuildAlias (use)
does not support the empty Path
as a shortcut for
[System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
.
Changed syntax of incremental tasks to less cryptic and more like MSBuild.
Replaced parameters Incremental
, Partial
with Inputs
, Outputs
, and
[switch]Partial
.
It is allowed to add two or more tasks with the same name. The last added wins. So it is possible to redefine existing tasks. Well, it is also possible to use the same name by mistake. Flexibility or safety? MSBuild chooses flexibility, Invoke-Build follows.
Task parameter After
tells to add a task to the end of job lists. It used to
be inserted after the last script job - this is often the same but not always.
Removed Invoke-Build.ps1
's parameter Hook
. If the default script is not
found the command Get-BuildFileHook
is called if it exists. See Build.ps1
.
Changed build results of Invoke-Build.ps1
and Invoke-Builds.ps1
in order to
avoid excessive and duplicated data. See help.
Invoke-Build.ps1
's parameter Result
always returns an instance of build
information. Its new property All
contains all defined task objects.
Replaced exposed internal variables BuildInfo
, BuildList
, and BuildHook
with a new variable *
. Build scripts should not use it. This change is not
breaking unless internal variables are used (illegal) or ${*}
is used in
scripts (unlikely).
Renamed the help file Invoke-Build.ps1-Help.xml
to Invoke-Build-Help.xml
.
Potentially breaking but minor change. Dropped support of nested lists in job lists. Value of this feature is low because such cases are very rare and unrolling is simple right in task definitions, see Dynamic.build.ps1.
Simplified checkpoint files. Do not use old checkpoints with the new engine.
Fixed false positive recoveries on protected task failures. Added tests.
Other mostly cosmetic changes in scripts, messages, and tests.
The engine sets the current location to the build root directory before calling event functions. Amended Checkpoint.build.ps1 and Events.build.ps1 in order to cover this.
Persistent builds are enabled by the new parameter Checkpoint
. They can be
resumed at a failed task after fixing problems which are not critical for
repeating a failed task and processing remaining others.
New event functions Export-Build
and Import-Build
are used for persistent
builds with tasks that share some data, normally script scope variables.
New test Checkpoint.build.ps1
shows main features of persistent builds. The
details are explained in its code comments.
Added the wiki page about persistent builds.
The internal Write-Warning
(warning counter) is converted the true wrapper.
That is, it calls the native cmdlet instead of Write-BuildText
. As a result:
The build engine defines and calls the following empty functions:
* Enter-BuildScript - before the first task
* Exit-BuildScript - after the last task
* Enter-BuildTask - before each task
* Exit-BuildTask - after each task
* Enter-BuildJob - before each script job
* Exit-BuildJob - after each script job
Any of them can be redefined in scripts. See help Invoke-Build.ps1
, section
EVENT FUNCTIONS for details. These events can be used for advanced logging,
initialization and releasing resources, etc.
Invoke-Build.ps1. Fixed use of not initialized $BuildHook
in strict mode.
Show-BuildGraph.ps1. With the Number
switch task script blocks are also
counted and their numbers are shown in task boxes. Note that this script is
still under construction, some changes based on the feedback are expected.
Show-BuildGraph.ps1
Graph
with Code
. Any proper DOT code is allowed.Number
tells to show task call numbers on graph edges.New script Show-BuildGraph.ps1 builds and shows build task graphs using Graphviz. For an example see Wiki.
Partial incremental tasks. Automatic variable $$
is not supported, use $2
.
Adapted tests to PowerShell V3 Beta (changed error messages).
Adapted to PowerShell V3 CTP2.
Got rid of easy to type but controversial variable $$
. There are issues in
PowerShell V3, bugs or not, Invoke-Build does not use this variable anymore.
As a result, it is recommended to replace automatic variables $$
with $2
in
all partial incremental task code (if any). This version supports both $2
(new) and $$
(deprecated). $$
will not be supported in vNext.
Refactoring of tests for decoupling and better grouping. Error cases moved from ErrorCases.build.ps1 and .build.ps1 to other scripts (test sets, in fact).
Removed the questionable trick with empty Write-Host
defined internally for
scripts invoked as parallel builds. This is up to scripts to decide how to
avoid host commands: remove, redefine, replace with Write-Verbose
, ...
Parallel builds: code clean-up, minor fixes, new tests.
Parallel builds. Amended summary messages. Log files are UTF8. Added some non ASCII output to parallel build tests.
Tests. Custom Format-Error is used instead of Out-String which does not work in strict mode with some hosts due to internal errors.
New parameter switch Safe
. It tells to catch/store build errors and return
quietly. It is needed for parallel builds (instead of a hack used before) but
it can be useful for regular builds, too.
Parallel builds use log files always, either specified by Log
or temporary.
As a result, output is not discarded on timeout and less memory is used, too.
Parallel builds. New parameter Timeout
and ability to log build outputs to
files. New test Timeout in Parallel.build.ps1 shows how it works.
Removed some noise from logged errors and added the prefix "ERROR:" to make it easier to search for error records in logs. Included position messages to final build messages shown before the summary line.
Internal task object: renamed property Info
to InvocationInfo
. This may
break code performing task analysis.
Output of parallel builds produced before failures used to disappear, only failure information was shown. Fixed, build output should be always shown.
New script Invoke-Builds.ps1 invokes parallel builds by Invoke-Build.ps1. Invoke-Builds.ps1 expects Invoke-Build.ps1 to be in the same directory. Such script tandems should work without conflicts with others, say, newer versions in the path. See also: Portable Build Scripts
The engine script Invoke-Build.ps1 does not require this new script. But the
engine is aware of it (creates an alias Invoke-Builds
) and helps it to get
results from other runspaces easier:
Result
provides more ways to get results.Error
contains an error that stopped the build.New demo/test script Parallel.build.ps1 shows how parallel builds are used.
Fixed a subtle issue: special aliases should be set always, not just on the first call. Use case: a build is invoked by a new engine but it explicitly calls an old engine, for example, frozen together with some sources.
Errors
Improved source information of some errors thrown by the engine, for example,
incremental inputs/outputs errors. Instead of pointing to not useful internal
throw
they show where Invoke-Build.ps1 or the wrapper Build.ps1 is invoked,
this is more useful for troubleshooting. Errors with amended information are
created in addition, initial errors can be found in the $Error
list.
Removed target objects from some errors as presumably redundant. They are shown in error messages anyway. Other use of them is unlikely practical.
Exposed variables
The special variable $_
is now visible. Scripts and tasks can use it as their
own, that is assign at first and then use. They must not make any assumptions
about its incoming value and use it without assignment.
See also: Special Variables.
Slightly changed output. Minor engine and test changes.
This release is the outcome of 1.0 series (stabilization of the tool set and concepts). From now on new features will be normally associated with minor version numbers. This release itself contains just improvements.
Found and fixed a case when the internal alias Invoke-Build was not set. See also: Portable Build Scripts.
Work around "Default Host" exceptions on setting colors in scenarios like
[PowerShell]::Create().AddScript("Invoke-Build ...").Invoke()
New test TestSelfAlias covers both issues. New test TestStartJob invokes build as a background job.
Initial task checks process all tasks regardless of If
conditions. This finds
issues earlier and also makes checks useful in more scenarios.
The helper task ?
(show/get tasks) now checks tasks in order to find issues
earlier. Wrappers using ?
may assume that tasks are valid. As a result, the
wrapper Build.ps1 is simplified.
The helper task *
(invoke all) was able to miss tasks with cyclic references.
This is fixed and covered by tests.
Cosmetic changes in the engine and help.
Removed some redundancies from tests.
New special task *
(in addition to ?
). *
tells to invoke all independent
tasks, i.e. all tasks starting with roots. This is very useful for scripts with
test tasks, one does not have to have a master task that calls all the others.
Besides, *
ensures that there is no test not called by mistake.
Thus, some obsolete/redundant tasks were removed from scripts in Demo.
New Invoke-Build parameter Hook for extensions. The only hook for now is GetFile which is used by Build.ps1. Get-BuildFile is exposed for this.
More info in invalid task errors and more such tests.
Script processing checks for "no tasks" first and fails if this is the case. If it is not a build script then other checks and messages can be confusing.
Add-BuildTask
(task
) uses named parameter sets Incremental and Partial.
This should not affect build scripts but, just in case, some errors changed.
Tweaks in scripts and tests.
Adapted Invoke-Build.ps1, Build.ps1, and tests for notorious paths with square brackets. Caution: this is done to some reasonable extent, some paths choke PowerShell anyway, like this weird but valid directory name:
] [ `] `[
Moved log messages "Task skipped" from preprocessing to processing phase. As a result, a task with false condition is logged every time when a task is called.
Internal engine functions now use weird names, just in case, to avoid clashes.
Build.ps1: fixed not standard PowerShell line separators in messages with InvocationInfo. Added two more tests to Demo/Wrapper.build.ps1.
Minor tweaks.
task
: the job list is unrolled internally. Thus, it is fine to mix single
jobs and job collections in the same list. See new Demo/Dynamic.build.ps1
which shows dynamic task creation and also covers unrolling.
Removed do-not-dot-source check from Use-BuildAlias
(use
). Otherwise for
consistency such paranoia checks should be in all functions, this is too much.
Amended checks of varying output in Demo/Wrapper.build.ps1, task Summary.
Demo tests: replaced some culture specific checks of core error messages with neutral checks. Tests are supposed to work on any machine and with any culture.
Amended error message on a script block returned by a build script.
Build.ps1
property
: variables with null values are treated as not existing. In other
words, property
never gets nulls. There is a little chance that this breaks.
Write-BuildText
uses try/finally to restore colors on Ctrl-C as well.
Tweaks of the engine, output, and documentation.
If the parameter Task
is '.' and the the task '.' is not defined then the
first added task is invoked. In other words, the argument '.' has the same
effect as if the parameter is not specified.
Build.ps1
?
when it is used with the switch -Tree
.-Comment
: Fixed extra empty lines. It works on its own, too.Build.ps1: New switch Comment (with Tree) tells to include comments:
# show the task tree for Pack and include task comments
Build Pack -Tree -Comment
Amended default file resolution and built-in help.
Invoke-Build ? -Result ...
- gets the task collection without invoking tasks.
New switch Tree
of Build.ps1 is used to show task parents and trees.
Tweaks in default file discovery and path resolution.
New script Build.ps1 - Invoke-Build wrapper, mostly for command prompt.
Build scripts are allowed to alter $BuildRoot
. Use cases: 1) when it is not
suitable to keep a file where it works; 2) the same file is used for several or
variable directories.
$WhatIf
is set to $true
when ?
is specified as a task (view tasks).
Alias Invoke-Build
is set internally to the full path of the invoked script.
Reasons: faster nested calls, ability to use Invoke-Build.ps1 copies, not in
the path, too.
assert
: allow any object as the condition, to require [bool]
is too much.
Amended the first line of the build output.
Amended error messages in Use-BuildAlias
and other tweaks. New tests.
Scripts can change $ErrorActionPreference
at the script level once for all
their tasks. Reminder: the default value is Stop.
The special command [. Invoke-Build
] also shows the current version. Tip: for
scripts there is Get-BuildVersion
.
Amended error messages and source information in several error cases.
Breaking changes
Invoke-Build main parameters are Task
, File
, Parameters
, as they used to
be. The removed combined parameter Script
was not intuitive, according to the
feedback.
Replaced task parameters Inputs
and Outputs
with Incremental
and
Partial
. New parameters are hashtables with a single entry: key is the
inputs, value is the outputs. As a result, the outputs can be defined as a
script block for any kind of incremental task, partial or not. (NB: script
blocks are lazy and preferable in some cases for better performance).
v1.0.20 continued. Build scripts are not allowed to output script blocks. It makes no sense and, more likely, indicates a script job defined after a task, not as a parameter. As a result, this script fails:
task task2 task1
{
...
}
As a result, null or missing job lists in tasks are allowed again.
Tasks still may have empty job lists (e.g. jobs can be created dynamically and nothing is actually created). But null or missing job lists are not allowed. As a result, this known mistake is now an error:
task Name
{
...
}
Fixed a bug in Invoke-Build ?
.
Documentation moved to the external file Invoke-Build.ps1-Help.xml. It should be copied to the same directory where Invoke-Build.ps1 is located.
New parameter Result
, the optional name of variable to be created with build
statistics: invoked task list, messages, error count, and warning count. It can
be used for analysis of failed tasks and their errors, task durations, and etc.
Slightly changed build result messages.
Breaking changes
Revised Invoke-Build parameters. New approach makes it easier to invoke build scripts with many parameters. It also enables TabExpansion of script parameters and ability to invoke tasks in scripts located somewhere in the path.
Build scripts and task scripts are now invoked with $ErrorActionPreference
set to Stop
. Otherwise it is too easy to miss serious errors. Scripts and
tasks can set their own local $ErrorActionPreference
.
Dropped support of master scripts and removed related function Start-Build
.
Master scripts have pros and cons but after all they are basically not better
than classic scripts.
Introduced the function Get-BuildProperty
and its alias property
.
Amended the error message on a build script with no tasks.
Fixed a bug dealing with splatting and the first parameter default value.
Empty/dummy tasks with no jobs are allowed (just like MSBuild empty targets with no dependencies and tasks). They are used in rare but possible scenarios.
Amended error messages in Use-BuildAlias
.
More tests in Use.build.ps1.
Task names are logged exactly as they are defined by task
, not as referenced
by the parameters or other tasks.
Use-BuildAlias
uses -ErrorAction Stop
and fails if a directory is missing.
Before
tasks are added before the first script job. After
tasks are added
after the last script job. If there is not a script job they are just added.
This is somewhat similar to what MSBuild does.
Tasks support After
and Before
parameters, analogues of AfterTargets
and
BeforeTargets
of MSBuild targets.
If build tasks are not specified and the "." task does not exist then the first added task is invoked.
At this point Invoke-Build concepts become quite similar to MSBuild, see Comparison with MSBuild.
Simplified assert
. Minor engine and test tweaks.
Task errors in If
, Inputs
, and Outputs
are not treated as build fatal if
a tasks is called protected. Really, they are not different from other task job
errors, any can be either a programming bug or a build issue. A task that calls
a culprit task can analyse its errors by error
and decide to fail or not.
Introduced automatic helper variables for incremental task scripts. See the
task
help, tests in Incremental.build.ps1, and the task ConvertMarkdown
in Build.ps1.
Breaking changes
Use-BuildFramework
(alias framework
) is transformed into Use-BuildAlias
(alias use
). For .NET frameworks it works as it used to, only the command
names have to be updated. But now it can be used with any tool directory, not
necessarily .NET (for example a directory with scripts).
Incremental build: full input paths are piped, not file system items. It just
looks more practically useful to deal with full paths. Example: Build.ps1,
task ConvertMarkdown
.
Added support of incremental and partial incremental builds with new task
parameters Inputs
and Outputs
.
Errors in task If
blocks should be fatal even if a task call is protected.
Task If
conditions are either expressions evaluated on task creation or
script blocks evaluated on task invocation. In the latter case a script is
invoked as many times as the task is called until it gets true
and the task
is invoked.


V8(expression) → retVal
No-operation that enforces the usage of the V8 JavaScript engine. There is no need to call this function explicitly, it is mainly used for internal testing.
// differences in execution plan (explain)
FOR i IN 1..3 RETURN (1 + 1) // const assignment
FOR i IN 1..3 RETURN V8(1 + 1) // simple expression


BigBlueButton
This is the BigBluebutton Deskshare Extension.
Published by BigBlueButton Inc.
(c) 2015 BigBlueButton Inc. [build X]
For more information visit
http://www.bigbluebutton.org


|
AppDynamics IoT C++ SDK
AppDynamics IoT C++ library contains code that facilitates capturing availability, usage, network performance and errors of an IoT Application.
|
| Cappd_iot_custom_event_t | AppDynamics Custom Event Mandatory: type, summary and timestamp_ms Fields |
| Cappd_iot_data_t | AppDynamics Associative Array Data Structure Underlying implementation is a Sequential List of <key, value> pairs |
| Cappd_iot_device_config_t | AppDynamics Device Information Mandatory: Device Type and Device ID Fields |
| Cappd_iot_error_event_t | AppDynamics Error Event This structure can be used to send error or exception or a crash. Mandatory: name and timestamp_ms Fields |
| Cappd_iot_http_cb_t | AppDynamics HTTP Callback list Mandatory: http_req_send_cb and http_resp_done_cb fields |
| Cappd_iot_http_req_t | AppDynamics HTTP Request Structure Mandatory: All Fields Data is provided in raw format. If data is sent in gzip format then add the http request header "Content-Encoding: gzip". It is recommended to gzip data for efficient use of resources |
| Cappd_iot_http_resp_t | AppDynamics HTTP Response Structure Mandatory: One of the resp_code or error fields should be populated |
| Cappd_iot_network_request_event_t | AppDynamics Network Request Event Mandatory: url and timestamp_ms Fields |
| Cappd_iot_sdk_config_t | AppDynamics SDK Configuration Mandatory: All Fields |
| Cappd_iot_stack_frame_t | AppDynamics Stack Frame This structure captures a single element in the stack frame Each stack frame should have atlease one of symbol_name, package_name or file_name |
| Cappd_iot_stack_trace_t | AppDynamics Stack Trace This structure captures the strack trace |
| Cappd_sdk_config_t | |
| Cbeacon_t | |
| Ccustom_event_t | |
| Cdata_t | |
| Cdevice_cfg_t | |
| Cerror_event_t | |
| Cjson_t | JSON struct which holds json string in a buffer |
| Cnetwork_request_event_t | |
| Cstack_frame_t | |
| Cstack_trace_t |


Could we be any more excited? Friends props and costumes to go under the hammer
An invitation to Monica Geller and Chandler Bing’s wedding, Joey Tribbiani’s stuffed penguin Hugsy and Rachel Green’s Hawaiian print dress are some of the items of Friends memorabilia set to go under the hammer.
Fans of the hit sitcom can bid on props, costumes and items of set decoration for the first time ever, as well as authorised reproductions of other key items as part of the 25th anniversary celebrations.
The auction, organised by Prop Store, will offer more than 100 lots spanning all 10 seasons of Friends, which have previously been held in the Warner Bros archive.
The wedding invitation set is expected to fetch between 1,000 and 1,500 US dollars (£750-£1,150), as is Hugsy.
The Hawaiian dress, worn by Jennifer Aniston in the show, is likely to sell for up to 5,000 dollars (£3,800), while Joey and Chandler’s wood canoe and two paddles could sell for up to 6,000 dollars (£4,600).
The VHS of the spoof porn film made by Phoebe Buffay’s sister Ursula, Buffay The Vampire Layer, is slated to raise between 1,500 and 2,500 dollars (£1,150-£1,900).
Among the authorised reproductions set to go under the hammer are a recreation of the Holiday Armadillo costume worn by Ross Geller, the Central Perk orange sofa, the picture frame handing on the back of the front door and the turkey wearing sunglasses and a fez.
Brandon Alinger, COO of Prop Store, said: “Prop Store is thrilled to be working with Warner Bros to auction some incredible material from all 10 seasons of Friends.
“The series gave us so many laughs during its original run and continues to entertain and inspire fans around the world.
“It’s an honour to be able to bring some amazing original pieces to the fans, such as Joey’s original Hugsy doll.
We’re also happy to offer detailed studio-edition reproductions, including the Holiday Armadillo costume, Central Perk couch and 10 copies of Monica’s peephole door frame, straight from the Warner Bros props department.”
Proceeds from the auction will benefit The Trevor Project, the world’s largest suicide prevention and crisis intervention organisation for LGBTQ young people.
Bidding will begin on December 3, known as Giving Tuesday, and runs until December 17. Bidders can register at propstore.com/Friends.


Hello!
My name is Miguel Sosa and I'm an UX Designer and (in a soon future) a Front-end Developer.
I've always been interested in the emotion and experience that design can give you, after all, good design is focused on giving the best experiences. With this in mind, I decided to make an UX Design course at Treehouse, where I learned topics such as Critiquing design, Visual Design, and UX Research and Test, etc.
It always baffled me how many extensions design has: industrial, product, graphic, game, web design, etc. How can we design something good with so many ways to do it?
This is where UX Design shines: it puts the focus on the user instead of the object. When we design with the user in mind, we can give him everything he wants and needs, even if he doesn't know himself.
UX Design is the reason why companies like Google and Apple got so far: by researching and testing products with their audiences they can create the best design possible.
Now, this is why I learned UX Design, It's the purest form of design. As an UX Designer, I can work with anything that produces experience and I'll make sure yours it's fantastic.
And for who is reading this, think about it, how does the current device your using right now makes you feel? How does your favorite app make you feel? Have you ever considered why is your preferred app? I invite you to give it some thought, maybe you'll find surprising results.


Unfortunately, your current browser is not supported at this time.
For PC users, please reopen this page in Google Chrome, Mozilla Firefox, Microsoft Edge, or Opera to participate.
For Mac users, please reopen this page in Mozilla Firefox to participate.
Thanks for your time!


{{qns.qnsTitle}}
Save all changes
Delete Challenge
Cancel
Challenge Title
This is required.
Image Link
This is required.
Accompanying Text (shown at the bottom of the slide)
Add New Slide


Lorem, ipsum dolor sit amet consectetur adipisicing elit. Debitis molestias minima fugiat, soluta voluptate repellat! Corrupti, nobis necessitatibus similique dolor impedit blanditiis labore nam quibusdam deserunt ad! Deserunt, debitis iure? Lorem ipsum dolor sit amet consectetur adipisicing elit. Natus nisi suscipit officia. Iure, quasi. Eveniet asperiores placeat fuga, sit officiis incidunt architecto esse quibusdam pariatur commodi non, sed, accusantium aliquid. Lorem ipsum dolor, sit amet consectetur adipisicing elit. Dicta, quibusdam repellat! Cupiditate recusandae quam at illum, unde sunt quod dolores eaque odit. Alias ducimus doloremque nihil voluptatum sed culpa veniam. Lorem ipsum dolor sit amet, conlam dolores itaque non exercitationem optio quasi enim, sit expedita iste odio.
this are the services we offer to our users
Buy agricultural produce directly from the fammers in bulk for wholesale
Buy agricultural produce directly from the fammers in bulk for wholesale
Buy agricultural produce directly from the fammers in bulk for wholesale
Buy agricultural produce directly from the fammers in bulk for wholesale
a brief about us
DTECH SUPPORT SERVICE has a robust and experienced workforce in engineering, construction, procurement and quality installation.
We deliver quality projects in Nigeria and the West African sub-region. Today, Dtech support services has evolved into a promising company with enourmus potential.
At DTECH, we work with our customers to provide turnkey services in Global marine, Oilfield Procurement, Manpower Supply, Security Services, Automotion, Energy, Aviation Services etc.
With a phone call or e-mail you can have access to unrivalled services, with the strength of specialist procurement personnel.
We pride ourselves in meeting your requirements and exceeding your expectaions.
We are commited to Quality, Health, Safty and Good environmental policies.
We view the satisfaction of our customers as the fundamental drive of our service so that we make every effort to provide high quality, competitive and innovative solutions to meet and exceed their requirements and expectaions for quality.
To be the leading African technical service provider that can be trusted by every household by delivering value that are affordable and reliable without compromising quality using the most effective tool based on a thourough understanding of our customer needs and requirements.
for questions and inquiries please contact us.
(operational HQ): 18B, Chris Ali Crescent, Abacha Estate Ikoyi Lagos, Nigeria.
Address: Plot 3, Block C Ateniwijo Layout, Ayepe New Ife Road Ibadan, Nigeria.
Phone: +234<PHONE_NUMBER>
Phone: +234<PHONE_NUMBER>
Email: coming soon
Website dtechsupportservice.com


Ozzy Osbourne Will Perform With Post Malone And Travis Scott At The American Music Awards
The Prince Of Darkness will perform Take What You Want, the track he did with rapper Post Malone.
Earlier this year, heavy metal godfather Ozzy Osbourne performed guest vocals on Take What You Want, a new track by rap sensation Post Malone which The Prince Of Darkness later said was his “favorite since Black Sabbath.” Now, it appears that Ozzy will take the song to the stage, as it’s been announced that he will perform the track live with Post and rapper Travis Scott later this year.
Ozzy will join the two rappers at the American Music Awards on Sunday, November 24, at the Microsoft Theater in Los Angeles. The show will air on ABC, and is also set to feature performances by Green Day, Lizzo, Cristina Aguilera, and more.
READ THIS: Goth in the front: How Marilyn Manson became a hip-hop icon
All of this is leading up to the release of Ordinary Man, Ozzy’s 11th studio album (not including 2005’s covers collection Under Cover), which is scheduled to drop in early 2020 on Epic Records.
Ozzy has an ambitious year of touring up ahead of him, with Marilyn Manson joining him on his U.S. dates and Judas Priest playing alongside him in the UK. Catch Ozzy’s live spectacle at one of the dates below:
May 2020
27 Atlanta, GA State Farm Arena
29 Sunrise, FL BB&T Center
31 Tampa, FL MIDFLORIDA Credit Union
June 2020
02 Charlotte, NC PNC Music Pavilion
04 Cincinnati, OH Riverbend Music Center
06 Hershey, PA Hershey Park Stadium
11 Pittsburgh, PA KeyBank Pavilion
13 Bangor, ME Darling’s Waterfront Pavilion
16 Montreal, QC Bell Centre
18 Hamilton, ON First Ontario Centre
20 Uncasville, CT Mohegan Sun Arena
22 New York, NY Madison Square Garden Arena
24 St Louis, MO Hollywood Casino Amphitheater
26 Kansas City, MO Sprint Center
28 Des Moines, IA Wells Fargo Arena
July
01 Milwaukee, WI Amer. Family Ins. Amp — Summerfest
03 St Paul, MN Xcel Energy Center
07 Edmonton, AB Rogers Place
09 Vancouver, BC Pepsi Live at Rogers Arena
11 Tacoma, WA Tacoma Dome
15 Portland, OR Moda Center
17 Sacramento, CA Golden 1 Center
23 Phoenix, AZ Ak-Chin Pavilion
25 San Francisco, CA Shoreline Amphitheatre
29 San Diego, CA North Island Credit Union Amphitheatre
31 Las Vegas, CA MGM Grand Garden Arena
October
23 Newcastle, Utilita Arena, UK
25 Glasgow, SSE Hydro, UK
28 London, The O2, UK
31 Birmingham, Resorts World Arena, UK
November
02 Manchester, Manchester Arena, UK
05 Dublin, 3Arena, Ireland
08 Nottingham, Motorpoint Arena, UK
11 Dortmund, Westfalenhalle, Germany
13 Prague, O2 Arena, Czech Republic
16 Vienna, Stadthalle, Austria
19 Bologna, Unipol Arena, Italy
22 Madrid, WiZink Arena, Spain
24 Zurich, Hallenstadion, Switzerland
26 Munich, Olympiahalle, Germany
28 Mannheim, SAP Arena, Germany
30 Berlin, Mercedes-Benz Arena, Germany
December
03 Hamburg, Barclaycard Arena, Germany
05 Stockholm, Friends Arena, Sweden
07 Helsinki, Hartwall Arena, Finland
READ THIS: Zakk Wylde isn’t involved in the new Ozzy album


def foo() { print("Hello") }
It was the best of timesIt was a dark and stormy nightIt was a dark and stormy nightIt was the best of times
It was the best of timesIt was a dark and stormy nightIt was the best of times
*asdf* 'ghkl' _xyz_
It was the best of timesIt was the best of timesIt was a dark and stormy nightGoogle
It was a dark and stormy nightIt was the best of timesFacebook
It was the best of timesGoogleGoogle
It was a dark and stormy nightIt was a dark and stormy nightIt was a dark and stormy nightIt was a dark and stormy nightFacebook
def foo() { print("Hello") }
FacebookIt was a dark and stormy nightGoogleFacebookIt was a dark and stormy night
def foo() { print("Hello") }
def foo() { print("Hello") }
def foo() { print("Hello") }
def foo() { print("Hello") }
It was a dark and stormy nightIt was the best of timesIt was the best of timesGoogle
It was the best of timesFacebookIt was a dark and stormy nightIt was a dark and stormy nightIt was the best of times
GoogleIt was the best of timesIt was a dark and stormy nightIt was a dark and stormy nightGoogle
It was a dark and stormy nightIt was a dark and stormy nightIt was a dark and stormy nightIt was a dark and stormy nightFacebook
It was a dark and stormy nightIt was a dark and stormy nightIt was a dark and stormy nightFacebook
FacebookIt was the best of timesFacebookGoogleFacebook
def foo() { print("Hello") }
It was the best of timesIt was a dark and stormy nightIt was a dark and stormy night
It was a dark and stormy nightIt was a dark and stormy nightIt was a dark and stormy night
It was the best of timesIt was the best of timesIt was a dark and stormy night
*asdf* 'ghkl' _xyz_
It was a dark and stormy nightIt was the best of timesIt was a dark and stormy night
GoogleFacebookIt was a dark and stormy night
It was a dark and stormy nightIt was the best of timesIt was the best of times
*asdf* 'ghkl' _xyz_
It was the best of timesIt was the best of timesIt was the best of timesGoogle
It was the best of timesIt was a dark and stormy nightFacebook
It was a dark and stormy nightIt was a dark and stormy nightIt was the best of timesIt was the best of times
*asdf* 'ghkl' _xyz_
FacebookIt was a dark and stormy nightIt was the best of timesIt was the best of timesIt was the best of times
GoogleIt was the best of timesGoogleIt was a dark and stormy night
*asdf* 'ghkl' _xyz_


This API partially implements the OGC API DGGS specification.
Please see the automatically generated OpenAPI documentation at docs for details on how to use this API. Alternate documentation is available at redoc.
It utilises the rhealpix-sf and rhealpix-geo for spatial calculations.
The rhealpix-geo library borrows from (but does not depend on) rHEALPixDGGS for some low level Cell relationships.
Contact:


Category:
{{election.category}}
Description:
{{election.description}}
This transaction allows you to vote (or change your vote) on an open Election.