Machine learning appears at first glance to be the science of devising and answering pure statistical questions on real-life data sets. In practice, a lot of it ends up being data janitor work.
Turning the data cleaning and feature engineering process into a quick workflow and as pleasant a task as trying out different modeling methodologies will eventually address this problem.
Since parsing and merging of data is not typically R's forte let's restrict the discussion to transforming one messy, raw dataset into a clean, ready-to-model dataset before proceeding with more complicated modeling topologies.
The initial abstraction offered by the Syberia modeling engine is that of mungebits: atomic production-ready feature engineering templates that can be used to quickly clean a dataset without having to write separate code when it comes time to replicate the cleaning process on single rows of data.
Why would we want to replicate the entire process? That's precisely one of the difficulties that emerges when it comes time to "productionize" the model! The trained classifier expects a certain type of covariate matrix, namely the one in exactly the preprocessed format you generated by cleaning the data set.
But why would we want to think about "productionizing" right away when we are experimenting? Because if we don't, we will spend weeks or months on the long, error-prone translation process of turning an experimental result into one that can be applied on new data in the real world.
It's worth investing a little bit more time now instead of far more time later when we have to replicate the cleaning work on new data. Note this does not just apply to streaming systems! If someone gave you a new validation set from their data warehouse and asked to verify the performance on some new data points it would be equivalent to solving the streaming problem: we would have to replicate the entire cleaning process on the raw validation set.
For example, if you replaced messed up values with the correct values, imputed missing values, dropped certain columns, or derived some new features from the existing data, you will have to re-do that work when a single data point comes in--otherwise the trained classifier will be confused.
Operations that take one data.frame
and return another data.frame
come
in two types: narrow and wide transformations. You can
delegate the narrow transformations to an ETL engineer or other
data curation role. However, this might not be feasible if we are deploying
a model, because they will have to provide a way to replicate their
process in real-time as well, for example through an API.
Narrow transformations, operations that can be done row-by-row without looking at the other rows, almost by definition do not need to store metadata to be reproduced on a single row. However, many of the most useful cleaning operations on a dataset—like sure independence screening, principal component analysis, imputation, discretization, aggregation and computation of ratios, numericalization of categorical features, and so on—are wide transformations.
The abundance of useful wide transformations is the reason why feature engineering cannot be separated from statistical modeling. It is impossible to have one person's role be maintaining a data pipeline while another person independently maintains a statistical model without running into a messy combinatorial explosion: they are inseparable aspects of the same task, in the same way database operations cannot be separated from a web application but instead compose its heart.
Let's convince ourselves that this is true.
Every time you write a script that begins with read.csv("data.csv")
and ends with a clean data set you have actually produced an
endomorphism on the space of dataframes, that is, a function
which takes one dataframe and yields another dataframe. Functions that
have the same domain and co-domain are really cool because they can
be trivially composed: if I have several such functions, I can just
apply them one after the other without worrying about setting up a complex
input/output graph since I know the input and the result will always be
a dataframe. (For the mathematically inclined, endomorphisms of any space form
a monoid under composition.)
In algebra class we were able to prove beautiful facts about parabolas and
the other conic sections because we looked at the most general cases, like
y = a * x^2 + b * x + c
. Here, a
,
b
, and c
are parameters:
for any combination of such three constants drawn from the real numbers we
get a different parabola.
Parametrization is powerful because it means we don't have to repeat our work every time a special case comes along. Finding the quadratic equation can be done once; the other times we simply plug in the parameters! Every time you write the type of code below you are re-deriving the quadratic formula by hand.
# Uncomment the line below if you want to run this on an example.
# raw_data <- data.frame(occupation = c("Doctor", rep("Waiter", 200)), stringsAsFactors = FALSE)
raw_data$occupation <- ave(raw_data$occupation, raw_data$occupation, FUN = function(x) {
if (length(x) / NROW(raw_data) < 0.01) { # Percentage of population with this occupation.
"Other"
} else {
x[1L]
}
})
If we later decide to perform the same operation on another variable, the path of lowest resistance will be copying the above and replacing "occupation" with the other variable name. If instead we had parametrized this as a function that took a dataset, the variables to alter, and a minimal threshold for replacing the value with "Other," we could easily re-use it for a variety of datasets.
What about when it comes time to replay the operation on a single row of data or a new validation set? The above code won't run! With a single row of data, all values will always have trivially 100% incidence and nothing will ever be replaced with "Other," which might lead to unexpected results when it comes to our classifier. Now imagine this problem amplified by 100 more feature engineering steps on a dataset with 1000s of variables. This is why data cleaning is seen as a combinatorial nightmare.
But it does not have to be. Mungebits solve this problem, and a proper generalization of mungebits solves any problem of taking raw, messy data sets, joining and munging them until there's a clean covariate matrix on which we can train a model—without having to ever write a custom data pipeline, instead making the process part of the explorative data science journey.
So what does a mungebit for the above step look like?
# lib/mungebits/remove_uncommon_values.R
train <- function(dataframe, variables, threshold = 0.01, replacement = "Other") {
replacements <- list()
for (v in variables) {
dataframe[[v]] <- ave(dataframe[[v]], dataframe[[v]], FUN = function(x) {
if (length(x) / NROW(dataframe) < threshold) {
replacements[[v]] <<- c(replacements[[v]], x[1L])
"Other"
} else {
x[1L]
}
})
}
# We'll learn about the "input" helper shown below later on.
input$replacements <- replacements
dataframe
}
predict <- function(dataframe, variables, threshold = 0.01, replacement = "Other") {
variables <- intersect(colnames(dataframe), variables)
for (v in names(input$replacements)) {
dataframe[[v]][dataframe[[v]] %in% input$replacements[[v]]] <- replacement
}
dataframe
}
So we had to do a little more work. The advantage is that we will never
have to think about the problem of replacing columns with rare values again:
we will be able to pass different parameters to the mungebit, and when it is
trained we will be able to re-use it on arbitrary future data sets, including
single rows for new data points. We can grab our mungebit within the
Syberia session using resource("lib/mungebits/remove_uncommon_values")
.
Let's see what happens when we run it on a simple example.
bit <- resource("lib/mungebits/remove_uncommon_values")
iris$Species <- as.character(iris$Species)
iris[1, "Species"] <- "Bumblebee"
head(bit$run(iris, "Species"), 2)
# Sepal.Length Sepal.Width Petal.Length Petal.Width Species
# 1 5.1 3.5 1.4 0.2 Other
# 2 4.9 3 1.4 0.2 setosa
What happens when we run it on a single row of iris data?
bit$run(iris[1:2, ], "Species") # We never modified iris.
# Sepal.Length Sepal.Width Petal.Length Petal.Width Species
# 1 5.1 3.5 1.4 0.2 Other
# 1 5.1 3.5 1.4 0.2 setosa
Our feature engineering step is now "production ready"! We can replay it on streaming rows of new data or on new validation sets to determine whether our classifier is behaving as expected.
bit$train(iris[1, ])
# Error:
# This mungebit has already been trained, cannot re-train.
Training a mungebit is like flipping a one-time switch: once we do it, we can't undo it; we would need a new fresh mungebit. This way, we can be sure that once we have fed in our initial training set its specific characteristics will be used to replay the feature engineering example as it happened.
For example, if a rare
value was on the border of the 0.01 threshold then certain subsamples
of the training set might consider it rare and replaceable with
"Other" whilst different subsamples do not. If we didn't have mungebits, we would
need to write a separate data pipeline for each model as to be
very careful about these sorts of edge cases. Incorrectly failing
to replace a value could lead to bizarre bugs in our classifier
when the column gets converted to a categorical feature.
Let's write some tests to convince ourselves our implementation is valid.
# test/lib/mungebits/remove_uncommon_values.R
test_that("it does not replace a common value", {
bit <- resource()
iris$Species <- as.character(iris$Species)
# Test the mungebit when it is training.
expect_equal(as.character(bit$run(iris, "Species")[1, 5]), "setosa")
stopifnot(bit$trained())
# And when it is predicting.
expect_equal(as.character(bit$run(iris, "Species")[1, 5]), "setosa")
})
Looking pretty good! Note we used stest
, a helper
provided by the Syberia modeling engine, to test our "resource", in this case the mungebit.
The point of good tests is to anticipate not only the example for which you wrote the code, but every possible input anyone could ever throw at it, so there are no surprises if someone uses your code in a way you did not expect.
 Our first test failure. Writing tests is about stepping outside of the box of how you think about the work you have created and considering every possible scenario for how other people may use it. In this case, if we had encountered a new data point with a value that was not observed during the training process, we would have failed to replace it with "Other" — even though its incidence in the original data was 0%!
This is a very common oversight. While writing the original code, we assumed that we wish to replace values that are uncommon. We stored them for later so that we could repeat the same process when new data came in. However, we failed to take into account that future data could have an infinite number of possible values. We should have instead stored the very finite list (by the pigeonhole principle, at most 100) of common values: those with incidence more than 1%.
# lib/mungebits/remove_uncommon_values.R
train <- function(dataframe, variables, threshold = 0.01, replacement = "Other") {
common_values <- list()
for (v in variables) {
dataframe[[v]] <- ave(dataframe[[v]], dataframe[[v]], FUN = function(x) {
if (length(x) / NROW(dataframe) < threshold) {
"Other"
} else {
common_values[[v]] <<- c(common_values[[v]], x[1L])
x[1L]
}
})
}
# We'll learn about the "input" helper shown below later on.
input$common_values <- common_values
dataframe
}
predict <- function(dataframe, variables, threshold = 0.01, replacement = "Other") {
variables <- intersect(colnames(dataframe), variables)
for (v in names(input$common_values)) {
dataframe[[v]][!is.element(dataframe[[v]], input$common_values[[v]])] <- replacement
}
dataframe
}
The more tests we write, the more coverage we have. You can think of test coverage (how much of your code is covered by test cases) as insurance on future changes to the code base. As the amount of code we write increases and the project becomes more complex, it will be harder and harder to track what everyone's assumptions are about the inputs and outputs to all the functions and resources used throughout the project. If someone ever fixes a bug or refactors anything, having lots of tests means it will be very easy to tell if they broke something in the process. At Avant we have used this approach to create data science collaboration repositories with tens of thousands of commits, thousands of models, and dozens of collaborators without stumbling on complexity: tests pay off.
Continue reading below for the more advanced and thorough mungebits section, or proceed with stagerunners if you'd like the abbreviated tour. You can always come back to finish the more advanced use cases.
The purpose of mungebits is to give a syntax for rapidly cleaning data and experimenting with feature engineering without having to rewrite anything when it comes time to productionize. To write a data pipeline after having experimentally munged the data in the R console would be a wasted effort: the R munging should give you a data pipeline for free.
The primary abstractions provided by the mungebits2 package are:
Mungebit R6 class.
A mungebit has the members c("train_function", "predict_function", "input")
,
where the first two are both functions that take and return a dataframe (with possibly
more parameters) and the last one is an environment object used by the train function
to store metadata required by the predict function.
Mungebits are meant to record the most abstract feature cleaning and engineering ideas: filter irrelevant columns, replace values, convert to a categorical, discretize, impute, apply PCA, etc. They are connected to a specific dataset through a mungepiece.
Although the Syberia modeling engine gives you a syntax for creating mungepieces to include in your data preparation, let's see what the process would look like when performed by hand.
We'll use Kaggle's Titanic data set.
data <- read.csv(stringsAsFactors = FALSE, "https://raw.githubusercontent.com/haven-jeon/introduction_to_most_usable_pkgs_in_project/master/bicdata/data/titanic.csv")
dim(data) # [1] 1309 15
home.dest
representing
their home destination.
head(data$home.dest)
# [1] "St Louis, MO" "Montreal, PQ / Chesterville, ON"
# [3] "Montreal, PQ / Chesterville, ON" "Montreal, PQ / Chesterville, ON"
# [5] "Montreal, PQ / Chesterville, ON" "New York, NY"
extract_state <- function(strings) {
has_state <- grepl("[A-Z]{2}", strings)
output <- rep(NA_character_, length(strings))
output[has_state] <- gsub(".*([A-Z]{2}).*", "\\1", strings[has_state])
output
}
table(extract_state(data$home.dest))
# AB BC CA CO CT DC DE FL IA IL IN KS KY MA MB ME MI MN MO
# 2 4 12 3 13 6 1 1 4 26 3 4 2 28 12 3 21 20 4
# MT ND NE NH NI NJ NM NS NY OH ON OR PA PQ RI SA SD UT VA
# 4 4 1 1 1 34 1 2 145 24 20 6 28 18 5 2 3 1 3
# VT WA WI WV
# 4 4 8 2
library(mungebits2) # devtools::install_github("syberia/mungebits2")
bit <- mungebit$new(function(dataframe, from, to) {
extract_state <- function(strings) {
has_state <- grepl("[A-Z]{2}", strings)
output <- character(length(strings))
output[has_state] <- gsub(".*([A-Z]{2}).*", "\\1", strings[has_state])
output
}
dataframe[[to]] <- extract_state(dataframe[[from]])
dataframe
})
# This call will set from = "home.dest" and to = "state".
states <- bit$run(data, "home.dest", "state")$state
stopifnot(identical(extract_state(data$home.dest), states)) # Passes.
We've already gained some clarity: we can re-use this mungebit for any dataset that has a character feature containing state as a substring and create a new feature representing that state.
In the modeling engine, the above would instead become one line of code in the model file with a separate file for the mungebit definition. This makes it clear the mungebit can be re-used on multiple datasets for a variety of purposes.
# One line of code in some models/dev/some_model.R
list(...,
data = list(
...
, "Parse out state" = list(extract_state, "home.dest", "state")
...
)
)
# lib/mungebits/extract_state.R
# Note that the function "extract_state" in models/dev/some_model.R
# gets *injected*: we don't have to define it anywhere, since
# the modeling engine figures it out from the filename.
# We'll discuss the point of setting train = predict later.
train <- predict <- function(dataframe, from, to) {
extract_state <- function(strings) {
has_state <- grepl("[A-Z]{2}", strings)
output <- character(length(strings))
output[has_state] <- gsub(".*([A-Z]{2}).*", "\\1", strings[has_state])
output
}
dataframe[[to]] <- extract_state(dataframe[[from]])
dataframe
}
# test/lib/mungebits/extract_state.R
# Our test suite won't run without a test for the mungebit.
test_that("it can parse a simple state example", {
data <- data.frame(location = c("Birmingham, AL", "Chicago, IL", "Mars"),
stringsAsFactors = FALSE)
# resource() will build us the mungebit: same as mungebit$new(train)
expect_equal(resource()$run(data, "location", "state")$state,
c("AL", "IL", ""))
})
# Running stest("lib/mungebits/extract_state") should convince you
# the test suite passes.
This is a narrow transformation.
We can compute state on a passenger-by-passenger
basis. Narrow transformations are usually straightforward. This
is why we set train <- predict
in the
mungebit definition. We are making it clear that we can use
the same code for cleaning the data offline versus running
it on new data. This is not always the case.
We stumble when we hit wide transformations,
where we must use information about other passengers to do the feature engineering step.
Different passengers will be on board the Titanic in different cabins and what cabin they're in (a good proxy for first class, second class, and third class) may be correlated with their state: passengers from one state may be on average more affluent than those in another and it may be unusual for a passenger from a certain state to be in a certain cabin. We can measure this by creating a feature that asks whether a passenger is in a cabin that the majority of the passengers from the state are in, i.e., does the passenger's cabin equal the mode (most frequently occuring value) of the cabins of the passengers in the same state?
head(data$cabin) # "B5" "C22 C26" "C22 C26" "C22 C26" "C22 C26" "E12"
# We probably need something less granular.
data$cabin_class <- gsub("[^A-Z]*", "", data$cabin) # "B" "C" "C" ...
string_mode <- function(x) {
counts <- table(x)
names(counts)[which.max(counts)]
} # string_mode(c("A", "A", "A", "B", "C")) = "A"
data$is_mode_of_cabin_class_by_state <- as.logical(
ave(data$cabin_class, data$state, FUN = function(cabin_class) {
# Mode doesn't make sense if everyone's in the same cabin
# so for those values we set NA.
if (length(unique(cabin_class)) == 1) { NA }
# A lot of passenger's records don't have a cabin, so exclude those.
else { cabin_class == string_mode(Filter(function(x) x != "", cabin_class)) }
}))
table(data$is_mode_of_cabin_class_by_state) # FALSE - 1160, TRUE - 110
sum(is.na(data$is_mode_of_cabin_class_by_state)) # [1] 39
In practice, it may be very difficult to tell what will work and what won't work. We've certainly had our fair share of counter-intuitive variables that don't seem significant but, for example, may end up in many branches of a tree model. Comparing complex aggregations against concrete values is a good source of wide transformations and in many cases improves model performance. When in-the-flow trying out features like this, it is easy to forget how complex it may be to implement the features when new validation sets come along or streaming one-row data sets come through in production.
In the above example, the problem stems from the fact that we used
R's ave
function. If we had fed different
subsamples of the dataset to the code, different feature engineering
could result depending on whether certain states have two top contenders
for most popular cabin! What if we want different models for different
groups of the passenger population? Should we use the cabin class mode of the
entire universe of passengers or restrict to each group? Both approaches
work, and the former is usually solved through ETL, while the latter
leads to a combinatorial explosion of data pipelines: we would need
to create a separate feature for each group of passengers we're
interested in modeling separately.
Not only that, but we won't be able to run the same code above when
a new data point comes in. We can't run ave
on a single row of data! We would need to remember the cabin class mode
for each state and then compare it against the state of the single row
when we stream (replay on one data point) the feature engineering step.
This is where mungebits shine. They allow you to unify your narrow and wide transformations, which together compose all transformations you could ever perform on any dataset in the universe, without introducing the technical debt that is typically associated with most ETL workflows. All of the feature engineering stays experimental, within the console, interactive, is replayable, and when it's all over with you have a very customized data pipeline for performing the same cleaning steps on a new row of data.
# models/dev/is_mode_in_group.R
# Generally, the data scientist will only need to play with this file.
list(...,
data = list(
...
, "Parse out state" = list(extract_state, "home.dest", "state")
# We'll cover multi_column_transformation later.
, "Cabin class var" = list(multi_column_transformation(gsub), "cabin", "cabin_class", pattern = "[^A-Z]*", replacement = "")
, "Is pop cabin by state" = list(is_mode_in_group, "cabin_class", "state", exclude = c("", NA))
...
)
)
# Move your mouse here -> x <- and scroll to the right.
# We take the one line per munge step approach and violate the
# typical column length developer sanity concern
# (lots of text on one row of a file is a nuisance to read and violates
# most style guides). This is so that when it gets too long, we can use
# our annoyance as a weapon to refactor the step into its own mungebit
# or condense the parametrization.
#
# It also makes it frictionless to comment out certain steps if you're
# experimenting and makes the full modeling procedure a joy to read.
# lib/mungebits/is_mode_in_group.R
# We're going to show you what a thorough implementation of this might
# look like. Feel free to breeze through this and come back to it when
# you feel fresh later.
variable_name <- function(target_variable, grouping_variable) {
paste0("is_mode_of_", target_variable, "_by_", grouping_variable)
}
train <- function(data, target_variable, grouping_variable, name, exclude = NA_character_) {
stopifnot(is.character(target_variable),
is.character(grouping_variable), is.character(exclude),
length(target_variable) == 1, length(grouping_variable) == 1,
target_variable %in% colnames(data), grouping_variable %in% colnames(data))
if (missing(name)) name <- variable_name(target_variable, grouping_variable)
stopifnot(is.character(name) && length(name) == 1 && !is.na(name) && nzchar(name))
if (!is.character(data[[target_variable]])) {
stop("The is_mode_in_group mungebit currently only supports character features.")
}
string_mode <- function(x) {
if (length(x) == 0) NA_character_
else {
counts <- table(x)
names(counts)[which.max(counts)]
}
}
input$modes <- list() # Store each mode by grouping variable.
data[[name]] <- as.logical(
ave(seq_len(NROW(data)), data[[grouping_variable]], FUN = function(ix) {
var <- data[ix, target_variable]
group <- as.character(data[ix[1L], grouping_variable])
if (length(unique(var)) == 1) {
input$modes[[group]] <- NA
NA
} else {
input$modes[[group]] <- mode <-
string_mode(Filter(function(x) !x %in% exclude, var))
ifelse(var %in% exclude, NA, var == mode)
}
})
)
data
}
predict <- function(data, target_variable, grouping_variable, name, exclude = NA_character_) {
if (missing(name)) name <- variable_name(target_variable, grouping_variable)
groups <- match(as.character(data[[grouping_variable]]), names(input$modes))
var <- logical(NROW(data))
var[is.na(groups)] <- NA
var[!is.na(groups)] <- as.logical(
ave(seq_len(NROW(data)), data[[grouping_variable]], FUN = function(ix) {
slice <- data[ix, target_variable]
ifelse(slice %in% exclude, NA,
slice == input$modes[[as.character(data[ix[1L], grouping_variable])]])
}))
data[[name]] <- var
data
}
# test/lib/mungebits/is_mode_in_group.R
test_that("it can tell whether a target is in the mode of a group on a simple example", {
data <- data.frame(stringsAsFactors = FALSE,
target = c("A", "A", "A", "B", "C"), group = rep(1, 5))
mb <- resource()
expect_equal(
mb$run(data, "target", "group")$is_mode_of_target_by_group,
c(TRUE, TRUE, TRUE, FALSE, FALSE)
)
# Check that it works on one-row data as well.
expect_true (mb$run(data[1, ], "target", "group")$is_mode_of_target_by_group)
expect_false(mb$run(data[4, ], "target", "group")$is_mode_of_target_by_group)
})
test_that("it keeps track of different modes for different groups", {
data <- data.frame(stringsAsFactors = FALSE,
target = c("A", "A", "A", "B", "C", "C", "C", "C", "B", "A"),
group = rep(c(1, 2), each = 5))
mb <- resource()
expect_equal(
mb$run(data, "target", "group")$is_mode_of_target_by_group,
c(TRUE, TRUE, TRUE, FALSE, FALSE, TRUE, TRUE, TRUE, FALSE, FALSE)
)
# Check that it works on one-row data as well.
expect_true (mb$run(data[1, ], "target", "group")$is_mode_of_target_by_group)
expect_false(mb$run(data[4, ], "target", "group")$is_mode_of_target_by_group)
expect_true (mb$run(data[6, ], "target", "group")$is_mode_of_target_by_group)
expect_false(mb$run(data[9, ], "target", "group")$is_mode_of_target_by_group)
})
test_that("it assigns NA to excluded labels", {
data <- data.frame(stringsAsFactors = FALSE,
target = c("A", "A", "A", "B", ""), group = rep(1, 5))
mb <- resource()
expect_equal(
mb$run(data, "target", "group", exclude = "")$is_mode_of_target_by_group,
c(TRUE, TRUE, TRUE, FALSE, NA)
)
# Check that it works on one-row data as well.
expect_true (mb$run(data[1, ], "target", "group", exclude = "")$is_mode_of_target_by_group)
expect_false(mb$run(data[4, ], "target", "group", exclude = "")$is_mode_of_target_by_group)
expect_equal(mb$run(data[5, ], "target", "group", exclude = "")$is_mode_of_target_by_group, NA)
})
Wide transformations can be tricky to reproduce in future scenarios when new data comes in. By acknowleding this distinction and tackling the hidden complexity head-on through a convention with built-in testing, we can avoid headaches down the road when we find useful but difficult to procure features that will have to be replicated for future records.
By using mungebits—modular production-ready data preparation—you can stop wasting time cleaning data and get back to work on math and stats. If someone else finds a general feature engineering or data cleaning idea, and they have parametrized and tested it well, they can easily share it and you just have to plug in the parameters relevant to your data set.
Let's take a step back and look at a simpler wide transformation.
normalize <- function(variable, mean, stdev) {
(variable - mean) / stdev
}
normalizer <- mungebit$new(function(data, variables) {
input$means <- lapply(data[variables], mean, na.rm = TRUE)
input$stdev <- lapply(data[variables], stats::sd, na.rm = TRUE)
names(input$means) <- names(input$stdev) <- variables
data[variables] <- Map(normalize, data[variables], input$means, input$stdev)
data
}, function(data, variables) {
# We should be careful since the variables may not be in the
# same order when we're looking at new data.
data[variables] <-
Map(normalize, data[match(variables, names(input$means))],
input$means, input$stdev)
data
})
head(normalizer$run(iris, "Sepal.Length")$Sepal.Length)
# [1] -0.8976739 -1.1392005 -1.3807271 -1.5014904 -1.0184372 -0.5353840
head(normalizer$run(iris[1, ], "Sepal.Length")$Sepal.Length)
# [1] -0.8976739
We used the mungebit$new
constructor to build
a new mungebit. The first argument is the train function, the
code that will be run the first time the run
method is called (i.e., during training) and has access to an environment
called input
which will be stored on the
mungebit object and used during subsequent calls to run
.
The second time we call that method it will execute the predict function,
the second argument that was passed to the normalizer.
You can think of the mungebit as a switch that, once flipped (trained), cannot be unflipped: it captures the essence of the feature engineering or data cleaning step and can be replayed on arbitrary subsets (including single rows or future single rows) of the same raw, messy data set.
Even normalizing your features is non-trivial to reproduce, in the sense that you have to be careful to recall the means and standard deviations to achieve the same normalization on single rows of data.
normalizer <- mungebit$new(column_transformation(function(variable) {
if (!trained) {
input$mean <- mean(variable, na.rm = TRUE)
input$stdev <- stats::sd(variable, na.rm = TRUE)
} # column_transformation keeps track of the mean and standard
# deviation of each column separately by "shadowing" the input helper.
(variable - input$mean) / input$stdev
}))
# Running the above example will achieve the same results.
The column_transformation
helper function is exported by the mungebits2 library to deal with
a common type of operation: one that only touches one column.
For these column-shardable operations, you can restrict
your computation to each column individually and pass in the list
of columns to execute on later.
head(normalizer$run(iris, 1:4), 2) # Run the normalizer on the first four columns.
# Sepal.Length Sepal.Width Petal.Length Petal.Width Species
# 1 -0.8976739 1.01560199 -1.335752 -1.311052 setosa
# 2 -1.1392005 -0.13153881 -1.335752 -1.311052 setosa
normalizer$run(iris[1, ], 1:4)
# Sepal.Length Sepal.Width Petal.Length Petal.Width Species
# 1 -0.8976739 1.015602 -1.335752 -1.311052 setosa
You may also have noticed we didn't need a predict function
when defining the normalizer mungebit in the second format. The
trained
helper logical is injected into any
mungebit train or predict function in case there is a large
amount of re-usable shared logic. Generally, if your code
for training and predicting varies by more than a few lines
you should split them up into two functions. Otherwise, you
can have a simple if (!trained)
switch
to record the metadata you'll need in input
(e.g., means and standard deviations) to replay the munge step later.


Toggle navigation
SRJNA
Home
Contacts
SRJNA Online Test Score
Total Marks
Correct Answers
Attempted
To see the complete Analytics click Below
Complete Analysis


|
His dad ran Florida. In 1942, Pops sent sonny boy down to Cuba to start up some casino's in Havana. After about four years of preparing, designing, and building the first of what was to become a long string of gambling houses, Lucky Luciano arrived with a cavalcade of Syndicate goons. The Havana conference of 1946 was portrayed in The Godfather, but the outcome was a bit different from Santos' perspective. He was forced to split his profits. This was a tremendous blow to the Trafficante family income. They had spent their own money to build and decorate the facilities in Havana, but now the profits were being slashed. But the Trafficante clan was beholden to Lucky Luciano. Everyone was. He controlled the entire North American continent, after all. Santos gritted his teeth and bore the brunt of the finacial wrath. Things chugged along pretty well for him until Fidel Castro came to power in 1952. Castro threw Santos in jail and took over all the mafia's casinos and opperations on the island. Santos remained there until Castro called him into his office in 1958. No one knows what the two talked about. But by the end of the week, Santos was sent back to the US. During the early sixties, Santos became part of the CIA"s underground mafia opperations, the main goal of which was to assasinate Castro. There were a number of attempts on Castro's life, but they continually failed. Santos was placced relatively highly on totem pole of these opperations. After the third failed attempt was reported, the CIA began to suspect that Santos was a double agent. It was later revealed that he had diluted some poison the CIA had sent to be placed in Castro's drinking water. In 1965, it became even more appherent that Santos was working both sides when a commrade in arms mentioned under oath that in 1962, Santos had told him "Kennedy's gonna get whacked." Of course, that information could easily have come from the CIA, Castro, or the mafia itself. |


LineJoint constraining anchor of one body, to a line segment of the other.
The equation for this constraint could be written like:
0 = dir.cross(delta)
= 0
jointMin <= dor.dot (delta)
<= jointMax
where:
dir = body1.localVectorToWorld(direction).unit();
delta = body2.localPointToWorld(anchor2).sub(body1.localPointToWorld(anchor1));
This is a 2 dimensional constraint, and is (when at the limits) solved as a
block constraint for better stability. This is however not the most stable
of joint when chained and put under stress and is a rather rare case where
using a non-stiff joint can actually be more stable than
using a stiff one.
When
jointMin = jointMax
, it would be better to use a PivotJoint
instead with suitable
placed anchors.
The line segment is defined implicitly via the
anchor1, direction, jointMin and jointMax
properties with end
points defined in local coordinate system of body1 like:
start = anchor1.add(direction.unit().mul(jointMin))
end = anchor1.add(direction.unit().mul(jointMax))
The reason for this more general description of a line segment is that one or
both of jointMin, jointMax are permitted to be infinite and a line segment
defined with a start and end point is not sufficient to describe such lines.


| State | Typical Payday Loan APR |
| Oregon | 140% |
| Oklahoma | 424% |
| Maine | 228% |
| Rhode Island | 261% |
| Wyoming | 316% |
| Florida | 293% |
| Iowa | 247% |
| Michigan | 356% |
| Indiana | 372% |
| Delaware | 639% |
| Kansas | 391% |
| Washington | 391% |
| South Carolina | 391% |
| Alaska | 424% |
| Alabama | 456% |
| California | 460% |
| Tennessee | 460% |
| Kentucky | 450% |
| Louisiana | 410% |
| Wisconsin | 537% |
| Mississippi | 572% |
| North Dakota | 521% |
| Missouri | 652% |
| Idaho | 475% |
| Nevada | 548% |
| Utah | 543% |
| Texas | 662% |


The following are the educational concepts we work to bring to our members:
- The thought processes surrounding the decision-making of surgery
- How surgery can be used to treat disease
- How surgery is integrated into other components of clinical medicine
- Ethical challenges faced by physicians and surgeons
- Significant paradigms and advances that characterize the history of medicine
- How surgery can be viewed as a form of art
- Preparing for a changing surgical field increasingly enriched with advances in robotics and biomedical engineering
- The revolution in gene-targeted therapies and surgery’s future role in combination therapies
- Socioeconomic disparities in healthcare access
- Surgical training and practice in refugee settings
- Integrating surgery as a part of holistic, structural, and sustainable solutions to global health crises


1. He reads a book.(quick)
2. Mandy is a girl.(pretty)
3. The class is loud today.(terrible)
4. Max is a singer.(good)
5. You can open this tin.(easy)
6. It's a day today.(terrible)
7. She sings the song .(good)
8. He is a driver.(careful)
9. He drives the car .(careful)
10. The dog barks .(loud)


|
| file | dsp_config.h |
| | This file contains the API prototypes for DSP configuration.
|
| |
| file | dsp_ecc.h |
| | ECC API declarations for DSP Internal memory (L1P and L2) ECC.
|
| |
| file | dsp_icfg.h |
| | This file contains the prototypes of the APIs present in the device abstraction layer file of ICFG in the C66x DSP subsytems. This also include related macro definitions. All APIs should be called with interrupts disabled to ensure coherency.
|
| |
| file | dsp_usrSpvSupport.h |
| | This file contains the API prototypes for configuring mode of DSP (User/Supervisor)
|
| |
| file | dsp_wugen.h |
| | This file contains the API prototypes for configuring DSP_WUGEN for DSP.
|
| |
| file | dsp_xmc.h |
| | This file contains the implementation of the APIs present in the device abstraction layer file of Extended Memory Controller (XMC) in the C66x DSP subsytems. This also include related macro definitions. All APIs should be called with interrupts disabled to ensure coherency.
|
| |
| file | hw_dsp_icfg.h |
| | register-level header file for DSP
|
| |
| file | hw_dsp_system.h |
| | register-level header file for DSP
|
| |
| file | hw_xmc.h |
| |
| file | c66x/interrupt.h |
| | This file contains the API prototypes for configuring INTC for DSP.
|
| |


“For me, it’s like a rock band. A single musician on their own can be something good, but sometimes a group comes together where everything lines up - complementary skills, harmony and unified intention - then something extraordinary happens; a creative powerhouse emerges. Linda and I brought out the best in one another and everyone who has come on board has added to that.”


--- layout: post title: Lush Angel’s Delight Soap tags: - Lush status: publish type: post published: true meta: _edit_last: '2' wp_plus_one_redirect: '' _graphene_slider_img: global _graphene_slider_imgurl: '' _graphene_show_addthis: global _graphene_post_date_display: global al2fb_facebook_image_id: '2523' _aioseop_keywords: ! 'Lush Angel’s Delight Soap ' _aioseop_title: ! 'Lush Angel’s Delight Soap ' al2fb_facebook_link_id: '218440691518395_351796768182786' al2fb_facebook_link_time: '2012-01-23T14:55:57+00:00' al2fb_facebook_link_picture: meta=http://missenchanted.com/wp-content/uploads/2012/01/Angel_s_Delight_4f02a61abdd68-150x135.png _yoast_wpseo_linkdex: '0' _thumbnail_id: '2362' _yoast_wpseo_focuskw: '' _yoast_wpseo_title: '' _yoast_wpseo_metadesc: '' _yoast_wpseo_metakeywords: '' _yoast_wpseo_meta-robots-noindex: '0' _yoast_wpseo_meta-robots-nofollow: '0' _yoast_wpseo_meta-robots-adv: none _yoast_wpseo_sitemap-include: ! '-' _yoast_wpseo_sitemap-prio: ! '-' _yoast_wpseo_canonical: '' _yoast_wpseo_redirect: '' ---
LUSH has been my all time favorite brand for skin care, but recently I have been hitting dud products with them, first came the Celebrate lip tint and then Australian Igloo scrub. I happen to pick up Angel's delight soap from LUSH online store at 50% off as post Christmas offer.
LUSH says: A soap that is bursting with colour and a sweet fruity smell. One of our Christmas bestsellers that returns year after year, by popular demand. A huge golden man on the moon sits atop this soap and wraps around a huge pink block of soap, with more decorations than a Christmas tree. With random blocks of colours, silver glitter, gold glitter, iridescent glitter and a lovely gold lustre, you never know just what your slice is going to look like. But what you do know is that you’ll get a soap that is universally appealing, with sweet orange essential oil, tangerine oil and a fruity fragrance. It brings a little bit of summer sunshine into the winter and makes you feel like you’ve been visited by angels. If you want a stunning centrepiece to your family Christmas, then why not phone us to ask about the price of a whole block. My Experiece: I had an experience of soap melting and evaporation with My LUSH Karma earlier, so this time I sliced the soap into several pieces :) This is a very glittery and colorful soap, I got the cream and blue part of it. It smells good like any other LUSH soap. My only concern with the product is that it doesnt lather much, no foam at all, and neither is it very moisturizing although its neither very dying. Ok I dont want to confuse you any more :P straight to pros and cons, What I like:What I did not like:
There are some great LUSH soaps out there, but this isn't one of them. Its more of a fun and celebration oriented soap with the colors and smells. But for skin care this doesn't deliver much. I won't be picking this up again :(
Have you tried LUCH Christmas collection.


POSIX_FADVISE
Section: Linux Programmer's Manual (2)
Updated: 2014-05-03
Index
Return to Main Contents
NAME
posix_fadvise - predeclare an access pattern for file data
SYNOPSIS
#include <fcntl.h>
int posix_fadvise(int fd, off_t offset, off_t len, int advice);
Feature Test Macro Requirements for glibc (see
feature_test_macros(7)):
posix_fadvise():
-
_XOPEN_SOURCE >= 600 || _POSIX_C_SOURCE >= 200112L
DESCRIPTION
Programs can use
posix_fadvise()
to announce an intention to access
file data in a specific pattern in the future, thus allowing the kernel
to perform appropriate optimizations.
The advice applies to a (not necessarily existent) region starting
at offset and extending for len bytes (or until the end of
the file if len is 0) within the file referred to by fd.
The advice is not binding;
it merely constitutes an expectation on behalf of
the application.
Permissible values for advice include:
- POSIX_FADV_NORMAL
-
Indicates that the application has no advice to give about its access
pattern for the specified data.
If no advice is given for an open file,
this is the default assumption.
- POSIX_FADV_SEQUENTIAL
-
The application expects to access the specified data sequentially (with
lower offsets read before higher ones).
- POSIX_FADV_RANDOM
-
The specified data will be accessed in random order.
- POSIX_FADV_NOREUSE
-
The specified data will be accessed only once.
- POSIX_FADV_WILLNEED
-
The specified data will be accessed in the near future.
- POSIX_FADV_DONTNEED
-
The specified data will not be accessed in the near future.
RETURN VALUE
On success, zero is returned.
On error, an error number is returned.
ERRORS
- EBADF
-
The fd argument was not a valid file descriptor.
- EINVAL
-
An invalid value was specified for advice.
- ESPIPE
-
The specified file descriptor refers to a pipe or FIFO.
(Linux actually
returns
EINVAL
in this case.)
VERSIONS
Kernel support first appeared in Linux 2.5.60;
the underlying system call is called
fadvise64().
Library support has been provided since glibc version 2.2,
via the wrapper function
posix_fadvise().
CONFORMING TO
POSIX.1-2001.
Note that the type of the
len
argument was changed from
size_t
to
off_t
in POSIX.1-2003 TC1.
NOTES
Under Linux, POSIX_FADV_NORMAL sets the readahead window to the
default size for the backing device; POSIX_FADV_SEQUENTIAL doubles
this size, and POSIX_FADV_RANDOM disables file readahead entirely.
These changes affect the entire file, not just the specified region
(but other open file handles to the same file are unaffected).
POSIX_FADV_WILLNEED initiates a
nonblocking read of the specified region into the page cache.
The amount of data read may be decreased by the kernel depending
on virtual memory load.
(A few megabytes will usually be fully satisfied,
and more is rarely useful.)
In kernels before 2.6.18, POSIX_FADV_NOREUSE had the
same semantics as POSIX_FADV_WILLNEED.
This was probably a bug; since kernel 2.6.18, this flag is a no-op.
POSIX_FADV_DONTNEED attempts to free cached pages associated with
the specified region.
This is useful, for example, while streaming large
files.
A program may periodically request the kernel to free cached data
that has already been used, so that more useful cached pages are not
discarded instead.
Pages that have not yet been written out will be unaffected, so if the
application wishes to guarantee that pages will be released, it should
call
fsync(2)
or
fdatasync(2)
first.
Architecture-specific variants
Some architectures require
64-bit arguments to be aligned in a suitable pair of registers (see
syscall(2)
for further detail).
On such architectures, the call signature of
posix_fadvise()
shown in the SYNOPSIS would force
a register to be wasted as padding between the
fd
and
offset
arguments.
Therefore, these architectures define a version of the
system call that orders the arguments suitably,
but otherwise is otherwise exactly the same as
posix_fadvise().
For example, since Linux 2.6.14, ARM has the following system call:
long arm_fadvise64_64(int fd, int advice,
loff_t offset, loff_t len);
These architecture-specific details are generally
hidden from applications by the glibc
posix_fadvise()
wrapper function,
which invokes the appropriate architecture-specific system call.
BUGS
In kernels before 2.6.6, if
len
was specified as 0, then this was interpreted literally as "zero bytes",
rather than as meaning "all bytes through to the end of the file".
SEE ALSO
readahead(2),
sync_file_range(2),
posix_fallocate(3),
posix_madvise(3)
Index
- NAME
-
- SYNOPSIS
-
- DESCRIPTION
-
- RETURN VALUE
-
- ERRORS
-
- VERSIONS
-
- CONFORMING TO
-
- NOTES
-
- Architecture-specific variants
-
- BUGS
-
- SEE ALSO
-
This document was created by
man2html,
using the manual pages.
Time: 02:54:46 GMT, September 18, 2014


Wear OS bug causes daylight savings mix-up w/ always-on display, here’s how to fix
by Ben SchoonGoogle’s Wear OS lags behind a lot of competitors when it comes to health and fitness features, but the smartwatches using the platform are usually genuinely good at being an actual wristwatch. However, thanks to daylight savings time, a bug has come up with Wear OS’s always-on display, but there’s an easy fix.
Android Police highlights an issue that seems relatively widespread on Reddit where some Wear OS users are noticing a discrepancy with their always-on display. Following Sunday’s time change to account for daylight savings, the always-on display stuck with the older time, while the watch as a whole shows the correct time.
It’s not entirely clear why this is happening, but it shouldn’t affect any alarms on the watch. It seems to only affect the always-on display and keeps it one hour off. Notably, this seems to be a somewhat common issue with the always-on display. I’ve noticed in the past when traveling across time zones, the always-on display sometimes takes a little while to sync back up.
Thankfully, there’s a very easy way to fix this daylight savings bug with Wear OS. Quickly rebooting both the affected watch and the connected smartphone should cause the two to re-sync.
Also, how is daylight savings time still a thing?
More on Wear OS:
- ‘Made by Google’ wearables are coming as Google invests in Wear OS’ future
- Google buys Fitbit for $2.1 billion with ‘opportunity to invest even more in Wear OS’
- The Moto 360 is being re-released for 2019 w/ new internals, familiar design
FTC: We use income earning auto affiliate links. More.


fossil rm path/to/file_or_directory- Remove a file or directory from Fossil version control, and also delete it from the disk:
fossil rm --hard path/to/file_or_directory- Re-add all previously removed and uncommitted files to Fossil version control:
fossil rm --reset


Mobiscroll
Theme
Windows Phone Light
Display
Inline
Language
English
Chinese
Demo
Time
Click here to try
Click here to try
Please Select
Atlanta
Berlin
Boston
Chicago
London
Los Angeles
New York
Paris
San Francisco


Suggest a resolution
You might be able to resolve this dispute without a hearing by reaching an agreement with Jan Clark.
This suggestion is ‘without prejudice’. If it’s rejected the other side can’t mention that you made them an offer if you do end up at a hearing.


Written by Supakorn Laohasongkram on August 14th, 2014
In our everday lifes, we almost unconciously define many things by class. For example, I am a class of Homo Sepian. (All I am saying is that I am a human! Am I?!) And within this class there are certain attributes and abilities which entails with being a Homo Sepia.
Similarly a Class in Ruby functions exactly the same way. Some of the pre-defined super classes in Ruby are Integer, String, Array, Hash and so on. And each of these classes have their own attributes and methods or functions.
You wouldn't ask a dog to speak because you know it can't. However, Homo Sepia has that function to speak; and in programming terms, human class has the method to speak. And you could very well "call" that method or its functions by telling someone to speak. This is much easier than telling a dog to speak right? Because if you do you are going to run into an argument error with the dog about how you are calling an undefined method. (This happens to me all the time, both when programming and when I am talking to my dogs. My dogs usually return me a default blank look and a wagging tail when I talk to them.)
Now, let's look some of the intricacies of how to use Class in Ruby and why. We will create a new class of alien!
Life Without Class...
ET_Name = ET ET_From_Outer_Space? = true ET_Alien? = true Superman_Name = Superman Superman_From_Outer_Space? = true Superman_Alien? = true Yoda_Name = Yoda Yoda_From_Outer_Space? = true Yoda_Alien? = true
As you can see, without class, if you want to define one alien. You always have to do it one by one. And that is not very efficient or very "DRY".
Life is Good with Class!
class Alien #Defining Alien class def initialize name @name = name #Store the instance variable of the Alien's name end def from_outer_space? # Method of Alien true end end ET = Alien.new 'ET' Superman = Alien.new 'Superman' Yoda = Alien.new 'Yoda'
Here, you can easily define ET, Superman, and Yoda have all the properties associated with being Alien by just setting each to the Alien class. So the simple point here is to demonstrate how class can be use to reproduce object which are similar to one another in a more effective manner.
Things one should know about class
Now that we learn a little bit about Class in Ruby. There are some important points which should be further mention.
Conclusion
Class is a very important subject that one should get themselves comfortable with especially when using object-oriented programming like Ruby. For further information about Classes Ruby, you can go to the links on the Reference to your right! Keep calm and code on!


| I l@ve RuBoard |
9.7 PyClock: An Analog/Digital Clock WidgetOne of the first things I always look for when exploring a new computer interface is a clock. Because I spend so much time glued to computers, it's essentially impossible for me to keep track of the time unless it is right there on the screen in front of me (and even then, it's iffy). The next program, PyClock, implements such a clock widget in Python. It's not substantially different than clock programs you may be used to seeing on the X Windows system. Because it is coded in Python, though, this one is both easily customized, and fully portable among Windows, the X Windows system, and Macs, like all the code in this chapter. In addition to advanced GUI techniques, this example demonstrates Python math and time module tools. 9.7.1 A Quick Geometry LessonBefore I show you PyClock, though, a little background and a confession. Quick -- how do you plot points on a circle? This, along with time formats and events, turns out to be a core concept in clock widget programs. To draw an analog clock face on a canvas widget, you essentially need to be able to sketch a circle -- the clock face itself is composed of points on a circle, and the second, minute, and hour hands of the clock are really just lines from a circle's center out to a point on the circle. Digital clocks are simpler to draw, but not much to look at. Now the confession: when I started writing PyClock, I couldn't answer the last paragraph's opening question. I had utterly forgotten the math needed to sketch out points on a circle (as had most of the professional software developers I queried about this magic formula). It happens. After going unused for a few decades, such knowledge tends to be garbage-collected. I finally was able to dust off a few neurons long enough to code the plotting math needed, but it wasn't my finest intellectual hour. If you are in the same boat, I don't have space to teach geometry in depth here, but I can show you one way to code the point-plotting formulas in Python in simple terms. Before tackling the more complex task of implementing a clock, I wrote the plotterGui script shown in Example 9-21 to focus on just the circle-plotting logic. Its point function is where the circle logic lives -- it plots the (X,Y) coordinates of a point on the circle, given the relative point number, the total number of points to be placed on the circle, and the circle's radius (the distance from the circle's center to the points drawn upon it). It first calculates the point's angle from the top by dividing 360 by the number of points to be plotted, and then multiplying by the point number; in case you've forgotten, too, it's 360 degrees around the whole circle (e.g., if you plot 4 points on a circle, each is 90 degrees from the last, or 360/4). Python's standard math module gives all the required constants and functions from that point forward -- pi, sine, and cosine. The math is really not too obscure if you study this long enough (in conjunction with your old geometry text if necessary). See the book's CD for alternative ways to code the number crunching.[3]
Even if you don't care about the math, though, check out this script's circle function. Given the (X,Y) coordinates of a point on the circle returned by point, it draws a line from the circle's center out to the point and a small rectangle around the point itself -- not unlike the hands and points of an analog clock. Canvas tags are used to associate drawn objects for deletion before each plot. Example 9-21. PP2E\Gui\Clock\plotterGui.py# plot circles (like I did in high school) import math, sys from Tkinter import * def point(tick, range, radius): angle = tick * (360.0 / range) radiansPerDegree = math.pi / 180 pointX = int( round( radius * math.sin(angle * radiansPerDegree) )) pointY = int( round( radius * math.cos(angle * radiansPerDegree) )) return (pointX, pointY) def circle(points, radius, centerX, centerY, slow=0): canvas.delete('lines') canvas.delete('points') for i in range(points): x, y = point(i+1, points, radius-4) scaledX, scaledY = (x + centerX), (centerY - y) canvas.create_line(centerX, centerY, scaledX, scaledY, tag='lines') canvas.create_rectangle(scaledX-2, scaledY-2, scaledX+2, scaledY+2, fill='red', tag='points') if slow: canvas.update( ) def plotter( ): circle(scaleVar.get(), (Width / 2), originX, originY, checkVar.get( )) def makewidgets( ): global canvas, scaleVar, checkVar canvas = Canvas(width=Width, height=Width) canvas.pack(side=TOP) scaleVar = IntVar( ) checkVar = IntVar( ) scale = Scale(label='Points on circle', variable=scaleVar, from_=1, to=360) scale.pack(side=LEFT) Checkbutton(text='Slow mode', variable=checkVar).pack(side=LEFT) Button(text='Plot', command=plotter).pack(side=LEFT, padx=50) if __name__ == '__main__': Width = 500 # default width, height if len(sys.argv) == 2: Width = int(sys.argv[1]) # width cmdline arg? originX = originY = Width / 2 # same as circle radius makewidgets( ) # on default Tk root mainloop( ) The circle defaults to 500 pixels wide unless you pass a width on the command line. Given a number of points on a circle, this script marks out the circle in clockwise order every time you press Plot, by drawing lines out from the center to small rectangles at points on the circle's shape. Move the slider to plot a different number of points, and click the checkbutton to make the drawing happen slow enough to notice the clockwise order in which lines and points are drawn (this forces the script to update the display after each line is drawn). Figure 9-19 shows the result for plotting 120 points with the circle width set to 400 on the command line; if you ask for 60 and 12 points on the circle, the relationship to clock faces and hands starts becoming more clear. Figure 9-19. plotterGui in actionFor more help, the book CD also includes text-based versions of this plotting script that print circle point coordinates to the stdout stream for review, rather than rendering them in a GUI. See the plotterText scripts in the clock's directory. Here is the sort of output they produce when plotting 4 and 12 points on a circle that is 400 points wide and high; the output format is simply: pointnumber : angle = (Xcoordinate, Ycoordinate) and assumes that the circle is centered at coordinate (0,0): ---------- 1 : 90.0 = (200, 0) 2 : 180.0 = (0, -200) 3 : 270.0 = (-200, 0) 4 : 360.0 = (0, 200) ---------- 1 : 30.0 = (100, 173) 2 : 60.0 = (173, 100) 3 : 90.0 = (200, 0) 4 : 120.0 = (173, -100) 5 : 150.0 = (100, -173) 6 : 180.0 = (0, -200) 7 : 210.0 = (-100, -173) 8 : 240.0 = (-173, -100) 9 : 270.0 = (-200, 0) 10 : 300.0 = (-173, 100) 11 : 330.0 = (-100, 173) 12 : 360.0 = (0, 200) ---------- To understand how these points are mapped to a canvas, you first need to know that the width and height of a circle are always the same -- the radius x 2. Because Tkinter canvas (X,Y) coordinates start at (0,0) in the upper left corner, the plotter GUI must offset the circle's center point to coordinates (width/2, width/2) -- the origin point from which lines are drawn. For instance, in a 400-by-400 circle, the canvas center is (200,200). A line to the 90-degree angle point on the right side of the circle runs from (200,200) to (400,200) -- the result of adding the (200,0) point coordinates plotted for the radius and angle. A line to the bottom at 180 degrees runs from (200,200) to (200,400) after factoring in the (0,-200) point plotted. This point-plotting algorithm used by plotterGui, along with a few scaling constants, is at the heart of the PyClock analog display. If this still seems a bit much, I suggest you focus on the PyClock script's digital display implementation first; the analog geometry plots are really just extensions of underlying timing mechanisms used for both display modes. In fact, the clock itself is structured as a generic Frame object that embeds digital and analog display objects, and dispatches time change and resize events to both the same way. The analog display is an attached Canvas that knows how to draw circles, but the digital object is simply an attached Frame with labels to show time components. 9.7.2 Running PyClockApart from the circle geometry bit, the rest of PyClock is straightforward. It simply draws a clock face to represent the current time and uses widget after methods to wake itself up 10 times per second to check if the system time has rolled over to the next second. On second rollovers, the analog second, minute, and hour hands are redrawn to reflect the new time (or the text of the digital display's labels is changed). In terms of GUI construction, the analog display is etched out on a canvas, is redrawn whenever the window is resized, and changes to a digital format upon request. PyClock also puts Python's standard time module into service to fetch and convert system time information as needed for a clock. In brief, the onTimer method gets system time with time.time, a built-in tool that returns a floating-point number giving seconds since the "epoch" -- the point from which your computer counts time. The time.localtime call is then used to convert epoch time into a tuple that contains hour, minute, and second values; see the script and Python library manual for additional time-related call details. Checking the system time 10 times per second may seem intense, but it guarantees that the second hand ticks when it should without jerks or skips (after events aren't precisely timed), and is not a significant CPU drain on systems I use.[4] On Linux and Windows, PyClock uses negligible processor resources, and what it does use is spent largely on screen updates in analog display mode, not after events. To minimize screen updates, PyClock redraws only clock hands on second rollovers; points on the clock's circle are redrawn at startup and on window resizes only. Figure 9-20 shows the default initial PyClock display format you get when file clock.py is run directly.
Figure 9-20. PyClock default analog displayThe clock hand lines are given arrows at their endpoints with the canvas line object's arrow and arrowshape options. The arrow option can be "first", "last", "none", or "both"; the arrowshape option takes a tuple giving the length of the arrow touching the line, its overall length, and its width. Like PyView, PyClock also uses the widget pack_forget and pack methods to dynamically erase and redraw portions of the display on demand (i.e., in response to bound events). Clicking on the clock with a left mouse button changes its display to digital by erasing the analog widgets and drawing the digital interface; you get the simpler display captured in Figure 9-21. Figure 9-21. PyClock goes digitalThis digital display form is useful if you want to conserve real estate on your computer screen and minimize PyClock CPU utilization (it incurs very little screen update overhead). Left-clicking on the clock again changes back to the analog display. The analog and digital displays are both constructed when the script starts, but only one is ever packed at any given time. A right mouseclick on the clock in either display mode shows or hides an attached label that gives the current date in simple text form. Figure 9-22 shows a PyClock running with a digital display, a clicked-on date label, and a centered photo image object. Figure 9-22. PyClock extended display with an imageThe image in the middle of Figure 9-22 is added by passing in a configuration object with appropriate settings to the PyClock object constructor. In fact, almost everything about this display can be customized with attributes in PyClock configuration objects -- hand colors, clock tick colors, center photos, and initial size. Because PyClock's analog display is based upon a manually sketched figure on a canvas, it has to process window resize events itself: whenever the window shrinks or expands, the clock face has to be redrawn and scaled for the new window size. To catch screen resizes, the script registers for the <Configure> event with bind; surprisingly, this isn't a top-level window manager event like the close button.  Because the clock face is plotted in a square coordinate system, PyClock always expands in equal horizontal and vertical proportions, though; if you simply make the window only wider or taller, the clock is unchanged. Finally, like PyEdit, PyClock can be run either standalone or attached to and embedded in other GUIs that need to display the current time. To make it easy to start preconfigured clocks, a utility module called clockStyles provides a set of clock configuration objects you can import, subclass to extend, and pass to the clock constructor; Figure 9-23 shows a few of the preconfigured clock styles and sizes in action, ticking away in sync. Figure 9-23. A few canned clock styles (Guido's photo reprinted with permission from Dr. Dobb's Journal)Each of these clocks uses after events to check for system-time rollover 10 times per second. When run as top-level windows in the same process, all receive a timer event from the same event loop. When started as independent programs, each has an event loop of its own. Either way, their second hands sweep in unison each second. 9.7.3 PyClock Source CodePyClock source code all lives in one file, except for the precoded configuration style objects. If you study the code at the bottom of the file shown in Example 9-22, you'll notice that you can either make a clock object with a configuration object passed in, or specify configuration options by command line arguments (in which case, the script simply builds a configuration object for you). More generally, you can run this file directly to start a clock, import and make its objects with configuration objects to get a more custom display, or import and attach its objects to other GUIs. For instance, PyGadgets runs this file with command line options to tailor the display. Example 9-22. PP2E\Gui\Clock\clock.py############################################################################### # PyClock: a clock GUI, with both analog and digital display modes, a # popup date label, clock face images, resizing, etc. May be run both # stand-alone, or embbeded (attached) in other GUIs that need a clock. ############################################################################### from Tkinter import * import math, time, string ############################################################################### # Option configuration classes ############################################################################### class ClockConfig: # defaults--override in instance or subclass size = 200 # width=height bg, fg = 'beige', 'brown' # face, tick colors hh, mh, sh, cog = 'black', 'navy', 'blue', 'red' # clock hands, center picture = None # face photo file class PhotoClockConfig(ClockConfig): # sample configuration size = 320 picture = '../gifs/ora-pp.gif' bg, hh, mh = 'white', 'blue', 'orange' ############################################################################### # Digital display object ############################################################################### class DigitalDisplay(Frame): def __init__(self, parent, cfg): Frame.__init__(self, parent) self.hour = Label(self) self.mins = Label(self) self.secs = Label(self) self.ampm = Label(self) for label in self.hour, self.mins, self.secs, self.ampm: label.config(bd=4, relief=SUNKEN, bg=cfg.bg, fg=cfg.fg) label.pack(side=LEFT) def onUpdate(self, hour, mins, secs, ampm, cfg): mins = string.zfill(str(mins), 2) self.hour.config(text=str(hour), width=4) self.mins.config(text=str(mins), width=4) self.secs.config(text=str(secs), width=4) self.ampm.config(text=str(ampm), width=4) def onResize(self, newWidth, newHeight, cfg): pass # nothing to redraw here ############################################################################### # Analog display object ############################################################################### class AnalogDisplay(Canvas): def __init__(self, parent, cfg): Canvas.__init__(self, parent, width=cfg.size, height=cfg.size, bg=cfg.bg) self.drawClockface(cfg) self.hourHand = self.minsHand = self.secsHand = self.cog = None def drawClockface(self, cfg): # on start and resize if cfg.picture: # draw ovals, picture try: self.image = PhotoImage(file=cfg.picture) # bkground except: self.image = BitmapImage(file=cfg.picture) # save ref imgx = (cfg.size - self.image.width( )) / 2 # center it imgy = (cfg.size - self.image.height( )) / 2 self.create_image(imgx+1, imgy+1, anchor=NW, image=self.image) originX = originY = radius = cfg.size/2 for i in range(60): x, y = self.point(i, 60, radius-6, originX, originY) self.create_rectangle(x-1, y-1, x+1, y+1, fill=cfg.fg) # mins for i in range(12): x, y = self.point(i, 12, radius-6, originX, originY) self.create_rectangle(x-3, y-3, x+3, y+3, fill=cfg.fg) # hours self.ampm = self.create_text(3, 3, anchor=NW, fill=cfg.fg) def point(self, tick, units, radius, originX, originY): angle = tick * (360.0 / units) radiansPerDegree = math.pi / 180 pointX = int( round( radius * math.sin(angle * radiansPerDegree) )) pointY = int( round( radius * math.cos(angle * radiansPerDegree) )) return (pointX + originX+1), (originY+1 - pointY) def onUpdate(self, hour, mins, secs, ampm, cfg): # on timer callback if self.cog: # redraw hands, cog self.delete(self.cog) self.delete(self.hourHand) self.delete(self.minsHand) self.delete(self.secsHand) originX = originY = radius = cfg.size/2 hour = hour + (mins / 60.0) hx, hy = self.point(hour, 12, (radius * .80), originX, originY) mx, my = self.point(mins, 60, (radius * .90), originX, originY) sx, sy = self.point(secs, 60, (radius * .95), originX, originY) self.hourHand = self.create_line(originX, originY, hx, hy, width=(cfg.size * .04), arrow='last', arrowshape=(25,25,15), fill=cfg.hh) self.minsHand = self.create_line(originX, originY, mx, my, width=(cfg.size * .03), arrow='last', arrowshape=(20,20,10), fill=cfg.mh) self.secsHand = self.create_line(originX, originY, sx, sy, width=1, arrow='last', arrowshape=(5,10,5), fill=cfg.sh) cogsz = cfg.size * .01 self.cog = self.create_oval(originX-cogsz, originY+cogsz, originX+cogsz, originY-cogsz, fill=cfg.cog) self.dchars(self.ampm, 0, END) self.insert(self.ampm, END, ampm) def onResize(self, newWidth, newHeight, cfg): newSize = min(newWidth, newHeight) #print 'analog onResize', cfg.size+4, newSize if newSize != cfg.size+4: cfg.size = newSize-4 self.delete('all') self.drawClockface(cfg) # onUpdate called next ############################################################################### # Clock composite object ############################################################################### ChecksPerSec = 10 # second change timer class Clock(Frame): def __init__(self, config=ClockConfig, parent=None): Frame.__init__(self, parent) self.cfg = config self.makeWidgets(parent) # children are packed but self.labelOn = 0 # clients pack or grid me self.display = self.digitalDisplay self.lastSec = -1 self.onSwitchMode(None) self.onTimer( ) def makeWidgets(self, parent): self.digitalDisplay = DigitalDisplay(self, self.cfg) self.analogDisplay = AnalogDisplay(self, self.cfg) self.dateLabel = Label(self, bd=3, bg='red', fg='blue') parent.bind('<ButtonPress-1>', self.onSwitchMode) parent.bind('<ButtonPress-3>', self.onToggleLabel) parent.bind('<Configure>', self.onResize) def onSwitchMode(self, event): self.display.pack_forget( ) if self.display == self.analogDisplay: self.display = self.digitalDisplay else: self.display = self.analogDisplay self.display.pack(side=TOP, expand=YES, fill=BOTH) def onToggleLabel(self, event): self.labelOn = self.labelOn + 1 if self.labelOn % 2: self.dateLabel.pack(side=BOTTOM, fill=X) else: self.dateLabel.pack_forget( ) self.update( ) def onResize(self, event): if event.widget == self.display: self.display.onResize(event.width, event.height, self.cfg) def onTimer(self): secsSinceEpoch = time.time( ) timeTuple = time.localtime(secsSinceEpoch) hour, min, sec = timeTuple[3:6] if sec != self.lastSec: self.lastSec = sec ampm = ((hour >= 12) and 'PM') or 'AM' # 0...23 hour = (hour % 12) or 12 # 12..11 self.display.onUpdate(hour, min, sec, ampm, self.cfg) self.dateLabel.config(text=time.ctime(secsSinceEpoch)) self.after(1000 / ChecksPerSec, self.onTimer) # run N times per second ############################################################################### # Stand-alone clocks ############################################################################### class ClockWindow(Clock): def __init__(self, config=ClockConfig, parent=None, name=''): Clock.__init__(self, config, parent) self.pack(expand=YES, fill=BOTH) title = 'PyClock 1.0' if name: title = title + ' - ' + name self.master.title(title) # master=parent or default self.master.protocol('WM_DELETE_WINDOW', self.quit) ############################################################################### # Program run ############################################################################### if __name__ == '__main__': def getOptions(config, argv): for attr in dir(ClockConfig): # fill default config obj, try: # from "-attr val" cmd args ix = argv.index('-' + attr) except: continue else: if ix in range(1, len(argv)-1): if type(getattr(ClockConfig, attr)) == type(0): setattr(config, attr, int(argv[ix+1])) else: setattr(config, attr, argv[ix+1]) import sys config = ClockConfig( ) #config = PhotoClockConfig( ) if len(sys.argv) >= 2: getOptions(config, sys.argv) # clock.py -size n -bg 'blue'... myclock = ClockWindow(config, Tk( )) # parent is Tk root if standalone myclock.mainloop( ) And finally, Example 9-23 shows the module that is actually run from the PyDemos launcher script -- it predefines a handful of clock styles, and runs six of them at once attached to new top-level windows for demo effect (though one clock per screen is usually enough in practice, even for me).[5]
Example 9-23. PP2E\Gui\Clock\clockStyles.pyfrom clock import * from Tkinter import mainloop gifdir = '../gifs/' if __name__ == '__main__': from sys import argv if len(argv) > 1: gifdir = argv[1] + '/' class PPClockBig(PhotoClockConfig): picture, bg, fg = gifdir + 'ora-pp.gif', 'navy', 'green' class PPClockSmall(ClockConfig): size = 175 picture = gifdir + 'ora-pp.gif' bg, fg, hh, mh = 'white', 'red', 'blue', 'orange' class GilliganClock(ClockConfig): size = 550 picture = gifdir + 'gilligan.gif' bg, fg, hh, mh = 'black', 'white', 'green', 'yellow' class GuidoClock(GilliganClock): size = 400 picture = gifdir + 'guido_ddj.gif' bg = 'navy' class GuidoClockSmall(GuidoClock): size, fg = 278, 'black' class OusterhoutClock(ClockConfig): size, picture = 200, gifdir + 'ousterhout-new.gif' bg, fg, hh = 'black', 'gold', 'brown' class GreyClock(ClockConfig): bg, fg, hh, mh, sh = 'grey', 'black', 'black', 'black', 'white' class PinkClock(ClockConfig): bg, fg, hh, mh, sh = 'pink', 'yellow', 'purple', 'orange', 'yellow' class PythonPoweredClock(ClockConfig): bg, size, picture = 'white', 175, gifdir + 'pythonPowered.gif' if __name__ == '__main__': for configClass in [ ClockConfig, PPClockBig, #PPClockSmall, GuidoClockSmall, #GilliganClock, OusterhoutClock, #GreyClock, PinkClock, PythonPoweredClock ]: ClockWindow(configClass, Toplevel( ), configClass.__name__) Button(text='Quit Clocks', command='exit').pack( ) mainloop( ) |
| I l@ve RuBoard |


Christian O'Connell (born 1973-04-07[ref]) has appeared in 96 episodes between 2002-2014. Christian O'Connell on IMDB. Christian O'Connell on Wikipedia.


|
|
NIDRA SAHCHARANGAL
ARTICLES This book is a collection of some of his articles published in various periodicals over a period of time. |
The
book owes its existence to the loving encouragement of Poorna Publications.
The
book contains 13 articles as follows:
1.
Good Novel and Great Novel
2. C.V the Novelist. (On C.V. Raman Pillai)
3. Chandu Menon and the Social Background.
4. A Lead to Takazhi's "Kayar"(On Takazhi Sivasankara Pillai's novel
"Kayar")
5. Jane Austin - a new note.
6. A letter of Changampuzha and Some Obsevations on Changampuzha.
7. Daily life Through Moments (an article on Changampuzha)
8.  An Introduction to the Phenomenon of Ambedkar.
10. Kumaran Asan -The Political Worker.
11. Nehru- A poser to the Biographical Art.
12. The Wealth we Should Receive From Other Languages.
13. Works of Other Languages in Malayalam.
The first edition of the book contained an additional article 'Gandhiji and Ambedkar'.
Publisher: Poorna Publications, Calicut-1, Kerala State, India.
Price:Rs.20/-
First Published:1989


Amway
XS™ Sports Nutrition Use1Share1 Bundle...
Description
Amway XS™ Sports Nutrition Use1Share1 Bundle
*** NEW *** SEALED BRAND NEW!
Product Overview
Provides a broad sampling of XS™ Sports Nutrition products
XS™ Sports Protein Powder Designed for everyday athletes and those who want to get the most out of today, this bundle includes a solid range of products to Hydrate, Energize, and Recharge, along with an exclusive
XS™ stainless steel, insulated water bottle and XS™ 2 in 1 shaker cup.
The XS™ Sports Nutrition Bundle includes:
- 12 XS™ CocoWater Hydration Drink Mix Packets (6 Strawberry Watermelon and 6 Pineapple Coconut)
- 12 XS™ Intense Pre-Workout Boost Stick Packs (Citrus Burst)
- 12 XS™ Protein Crisps Bags (Barbeque)
- 10 XS™ Energy Bars (5 Chocolate Chip and 5 Peanut Butter Crunch)
- 12 XS™ Sports Protein Powder, Single-Serving Pouches (Chocolate Milkshake)
- 10 XS™ Sports Protein Bars (5 Chocolate Peanut Butter and 5 Chocolate Berry Blast)
Benefits
The XS™ Sports Nutrition Use1Share1 Bundle gives you:
- A broad sampling of XS™ Sports Nutrition products.
- Individually packaged samples that are perfect for on the go and sharing with friends.
- XS™ logo items that help you create more awareness of the XS™ brand.
Ingredients
XS™ CocoWater Hydration Drink Mix
SUCROSE, COCONUT WATER CONCENTRATE, TRIPOTASSIUM CITRATE MONOHYDRATE, NATURAL FLAVORS, CITRIC ACID, CALCIUM SILICATE (ANTI-CAKING AGENT), MALIC ACID, PURPLE CARROT (COLOR), REBAUDIOSIDE A (STEVIA EXTRACT).
XS™ Intense Pre-Workout Boost stick packs – Citrus Burst
BETA-ALANINE, MALTODEXTRIN, ISOMALTULOSE, DEXTROSE, WAXY MAIZE, CITRIC ACID, NATURAL FLAVORING, ENERGY BLEND (CAFFEINE [FROM GUARANA SEED EXTRACT AND COFFEE BEAN EXTRACT], ELEUTHERO ROOT, GINKGO LEAF, ASTRAGALUS ROOT, ASIAN GINSENG ROOT, SCHIZANDRA FRUIT AND SEED, SARGASSUM THALLUS, REISHI FRUIT, JUJUBE FRUIT, LYCIUM FRUIT, LUO HAN GUO FRUIT), MEDIUM CHAIN TRIGLYCERIDES (FROM COCONUT OIL). CONTAINS 2% OR LESS OF: SILICA, MALIC ACID, RHODIOLA ROOT EXTRACT, ASCORBIC ACID, PYRIDOXINE HYDROCHLORIDE, REB A (STEVIA), NIACIN (AS NICOTINIC ACID), CYANOCOBALAMIN, D-CALCIUM PANTOTHENATE, FOLIC ACID, THIAMINE MONONITRATE, RIBOFLAVIN.
XS™ Protein Crisps Bags – Barbeque
PEA PROTEIN ISOLATE, DEHYDRATED VEGETABLES (POTATO, TOMATO, ONION, GARLIC), POTATO STARCH, HIGH OLEIC SUNFLOWER OIL, SORBITOL, NATURAL FLAVORS, TORULA YEAST, CALCIUM CARBONATE, SALT, SODIUM DIACETATE, PAPRIKA, CITRIC ACID, YEAST EXTRACT, SPICE, POTASSIUM CHLORIDE, SODIUM GLUCOMATE, SILICON DIOXIDE (ANTI-CAKING AGENT).
XS™ Energy Bars - Chocolate Chip
ORGANIC BROWN RICE SYRUP, ORGANIC ROLLED OATS, SOY CRISPS (SOY PROTEIN ISOLATE, ORGANIC RICE FLOUR AND CALCIUM CARBONATE), ORGANIC CHOCOLATE CHIPS (ORGANIC CANE SUGAR, ORGANIC CHOCOLATE LIQUOR, ORGANIC COCOA BUTTER, SUNFLOWER LECITHIN, SALT, ORGANIC VANILLA EXTRACT), ORGANIC DATE PASTE, ORGANIC INVERT CANE SYRUP, ORGANIC SOY BUTTER (ORGANIC DRY ROASTED SOYBEANS, ORGANIC SOY OIL, SEA SALT), SOY PROTEIN ISOLATE, INULIN, PREBIOTIC SOLUBLE CORN FIBER, TAPIOCA SYRUP, ORGANIC SUNFLOWER OIL, NATURAL FLAVOR, ORGANIC AGAVE SYRUP, SEA SALT. CONTAINS SOY AND WHEAT.
XS™ Energy Bars – Peanut Butter Crunch
ORGANIC BROWN RICE SYRUP, ORGANIC PEANUT BUTTER (ROASTED PEANUTS), ORGANIC DATE PASTE, SOY CRISPS (SOY PROTEIN ISOLATE, RICE FLOUR, MALT EXTRACT), ORGANIC ROLLED OATS, ORGANIC INVERT CANE SYRUP, PEANUT FLOUR, ORGANIC PEANUTS, ORGANIC SOY BUTTER (ORGANIC DRY ROASTED SOYBEANS, ORGANIC SOY OIL, SEA SALT), SOY PROTEIN ISOLATE, PEANUT EXTRACT, PREBIOTIC SOLUBLE CORN FIBER, TAPIOCA SYRUP, ORGANIC SUNFLOWER OIL, ORGANIC AGAVE SYRUP, INULIN, SEA SALT. CONTAINS PEANUTS, SOY AND WHEAT.
XS™ Sports Protein Powder single-serving pouches – Chocolate Milkshake
WHEY PROTEIN CONCENTRATE (FROM MILK), MILK PROTEIN ISOLATE, FRUCTOSE, COCOA, GLYCINE, COCONUT OIL, CALCIUM CASEINATE (FROM MILK), NATURAL FLAVORS. CONTAINS 2% OR LESS OF: MICELLAR CASEIN (FROM MILK), WHEY PROTEIN HYDROLYSATE (FROM MILK), WHEY PROTEIN ISOLATE (FROM MILK), SODIUM CASEINATE (FROM MILK), BRANCHED CHAIN AMINO ACIDS (LEUCINE, ISOLEUCINE, VALINE), MALTODEXTRIN, MEDIUM CHAIN TRIGLYCERIDES, LECITHIN (SOY OR SUNFLOWER), PAPAIN, OLIGOFRUCTOSE, GUAR GUM, XANTHAN GUM, REB A (STEVIA), BROMELAIN, FRUCTOOLIGOSACCHARIDES, SALT, MONOGLYCERIDES, DIPOTASSIUM PHOSPHATE, SILICON DIOXIDE, PEA PROTEIN ISOLATE. CONTAINS SOY AND MILK.
XS™ Sports Protein Bars – Chocolate Peanut Butter
SUCROCHOCOLATE FLAVORED COATING (SUGAR, PALM KERNEL OIL, WHEY PROTEIN CONCENTRATE, COCOA POWDER, SOY LECITHIN [EMULSIFIER], VANILLA), XS™ PROTEIN BLEND (WHEY PROTEIN CONCENTRATE, WHEY PROTEIN ISOLATE, MILK PROTEIN CONCENTRATE, HYDROLYZED WHEY PROTEIN ISOLATE, CALCIUM CASEINATE), PEANUT BUTTER (PEANUTS, SE, PALM OIL, SALT, SEA SALT), GLYCERINE, GELATIN, WATER, WHEY CRISP (WHEY PROTEIN ISOLATE, WHEY PROTEIN CONCENTRATE, TAPIOCA STARCH, CALCIUM CARBONATE, SOY LECITHIN [PROCESSING AID]), PEANUT FLOUR, POWDERED SUGAR, MALTODEXTRIN, PEANUTS, PALM KERNEL OIL, SOY LECITHIN (EMULSIFIER), SALT, ALMONDS. CONTAINS PEANUTS, SOY, MILK AND ALMONDS.
 CONTAINS PEANUTS, ALMONDS, MILK AND SOY.
Frequently Bought Together
Payment
We accept PayPal Only. All major credit cards are accepted through secure payment processor PayPal.
Shipping
PLEASE READ!!!
Feel Safe to Buy with us read our Feedback is our business!!!
Shipping out in next business day if you choose on weekend
Excludes: Alaska/Hawaii, APO/FPO, US Protectorates, South America, Puerto Rico, PO Box ARE NOT AVAILABLE!!!!!
It usually takes 2 - 3 days of handling time. For orders within the US it takes 5 - 7 business days maximum after handling.
When can you expect your order? Allow at least 2 to 3 days for tracking number to post.
When I know, you will know.
If you want cancel order we can do only before shipping...
Purchase Terms and Conditions
- Your order will be processed within 1 business day after receipt of cleared payment.
- We Only Provide Shipping to the 48 Contiguous United States.
- We are unable to ship PO Box.
- We do not combine shipping.
- 30 days in order to get your money back or item exchange*, buyer pays return shipping.
- Buyers Pay for Return Shipping Cost.
- All emails will be answered within 1 business day. If you do not receive our reply, please kindly re-sent your e-mail, and we will reply to you as soon as possible.
- All items sold by us are being described to the best of our abilities, as accurate as possible, and with utmost conscientiousness on our part. However, to avoid any potential oversights, I respectfully request your assistance in helping us to make this a mutually satisfactory transaction by Thoroughly reviewing item description and photos, and asking all questions Prior To Bidding.
- Please Note that size and color representation are subject to manufacturing variance and may not be exact. Also note that monitor settings may vary from computer to computer and may distort actual colors.
- Before you report any problem to Ebay wait for our answer.
- If there is something let you unsatisfy, please do not leave negative or neutral feedback we will try best to solve your problem and ensure your requirement.
- Please leave POSITIVE FEEDBACK after receiving the product


Quick help:
- add planets by double clicking;
then click to place a velocity vector
- choose a planet by clicking on it or from the listbox or by clicking "next planet"
- modify planet and view properties at any time
from the side panel (try clicking everything!)
- remove planets by clicking "remove planet"
- move view around by dragging background
- zoom by using scrollwheel (zooms where
you point a la Google Maps)
- the direction is to the east when the
slider is at zero; it increases counter-clockwise
- you can set the default mass for new planets by setting the mass in the mass text box and pressing return
Known issues / non-issues:
- numerical integration is (by definition) inaccurate, and if planets experience extreme accelerations, they escape
- load and save can't be used in (unsigned) web start
- direction as a slider from 0 to 2*pi is unintuitive (but this arrangement is the best I could come up with; dividing velocity into components would be less useful)
- there's no collision detection (on purpose; it'd be stupid since the planets are drawn way bigger than they'd actually be)
- the app isn't very usable at small resolutions since the side panel takes some space
Possible upcoming features
- saving view parameters in .world files
- saving worlds in an XML based format instead of a comma-separated text file
- stabilizing orbits by changing mass or velocity
- a collection of interesting worlds to be distributed with nbody
- textured planets (easy, but I'd need to make the textures)
- altering simulation speed (but that's not possible with vanilla Verlet integration)


Crunch
Time
Crunch
Time
Quickly assemble weekly dinner menus from popular recipes all under 600 calories per serving.
Begin
Select a Diet:
Balanced
Pescatarian
Vegetarian
Vegan
Primal
Paleo
Select Any Intolerances
Dairy
Egg
Gluten
Peanut
Sesame
Shellfish
Soy
Sulfite
Tree Nut
Wheat
Create a Menu
Your Menu
Prepare Printable Menu
New Menu
Start Over


|
Panda3D
|
Public Member Functions | |
| def | __init__ (self) |
| def | __getitem__ (self, index) |
| def | addTag (self, tag) |
| def | dehighlightAll (self) |
| def | deselect (self, nodePath) |
| def | deselectAll (self) |
| def | forEachDeselectedNodePathDo (self, func) |
| def | forEachSelectedNodePathDo (self, func) |
| def | getDeselectedAsList (self) |
| def | getDeselectedDict (self, id) |
| def | getDirectNodePath (self, nodePath) |
| def | getNumSelected (self) |
| def | getSelectedAsList (self) |
| def | getSelectedDict (self, id) |
| def | getWrt (self, nodePath) |
| def | getWrtAll (self) |
| def | highlightAll (self) |
| def | isolateSelected (self) |
| def | moveWrtWidget (self, nodePath) |
| def | moveWrtWidgetAll (self) |
| def | removeAll (self) |
| def | removeSelected (self) |
| def | removeTag (self, tag) |
| def | reset (self) |
| def | select (self, nodePath, fMultiSelect=0, fSelectTag=1) |
| def | toggleVisAll (self) |
| def | toggleVisSelected (self) |
| Public Member Functions inherited from DirectObject | |
| def | accept (self, event, method, extraArgs=[]) |
| def | acceptOnce (self, event, method, extraArgs=[]) |
| def | addTask (self, *args, **kwargs) |
| def | detectLeaks (self) |
| def | doMethodLater (self, *args, **kwargs) |
| def | getAllAccepting (self) |
| def | ignore (self, event) |
| def | ignoreAll (self) |
| def | isAccepting (self, event) |
| def | isIgnoring (self, event) |
| def | removeAllTasks (self) |
| def | removeTask (self, taskOrName) |
Public Attributes | |
| deselectedDict | |
| last | |
| selectedDict | |
| selectedList | |
| tagList | |
Additional Inherited Members | |
| Static Public Attributes inherited from DirectObject | |
| def | accept_once = acceptOnce |
| def | add_task = addTask |
| def | detect_leaks = detectLeaks |
| def | do_method_later = doMethodLater |
| def | get_all_accepting = getAllAccepting |
| def | ignore_all = ignoreAll |
| def | is_accepting = isAccepting |
| def | is_ignoring = isIgnoring |
| def | remove_all_tasks = removeAllTasks |
| def | remove_task = removeTask |
| def __init__ | ( | self | ) |
Reimplemented from DirectObject.
| def __getitem__ | ( | self, | |
| index | |||
| ) |
| def addTag | ( | self, | |
| tag | |||
| ) |
| def dehighlightAll | ( | self | ) |
| def deselect | ( | self, | |
| nodePath | |||
| ) |
Deselect the specified node path
| def deselectAll | ( | self | ) |
| def forEachDeselectedNodePathDo | ( | self, | |
| func | |||
| ) |
Perform given func on deselected node paths. No node path connectivity verification performed
| def forEachSelectedNodePathDo | ( | self, | |
| func | |||
| ) |
Perform given func on selected node paths. No node path connectivity verification performed
| def getDeselectedAsList | ( | self | ) |
| def getDeselectedDict | ( | self, | |
| id | |||
| ) |
Search deselectedDict for node path, try to repair broken node paths.
| def getDirectNodePath | ( | self, | |
| nodePath | |||
| ) |
| def getNumSelected | ( | self | ) |
| def getSelectedAsList | ( | self | ) |
Return a list of all selected node paths. No verification of connectivity is performed on the members of the list
| def getSelectedDict | ( | self, | |
| id | |||
| ) |
Search selectedDict for node path, try to repair broken node paths.
| def getWrt | ( | self, | |
| nodePath | |||
| ) |
| def getWrtAll | ( | self | ) |
| def highlightAll | ( | self | ) |
| def isolateSelected | ( | self | ) |
| def moveWrtWidget | ( | self, | |
| nodePath | |||
| ) |
| def moveWrtWidgetAll | ( | self | ) |
| def removeAll | ( | self | ) |
| def removeSelected | ( | self | ) |
| def removeTag | ( | self, | |
| tag | |||
| ) |
| def reset | ( | self | ) |
| def select | ( | self, | |
| nodePath, | |||
fMultiSelect = 0 , |
|||
fSelectTag = 1 |
|||
| ) |
Select the specified node path. Multiselect as required
| def toggleVisAll | ( | self | ) |
| def toggleVisSelected | ( | self | ) |
| deselectedDict |
| last |
| selectedDict |
| selectedList |
| tagList |


pardon my dust. i am redesigning the site with more interactive features. in the mean time, you can read about me and follow my social media accounts.           —stephanie


Create custom playlists for YouTube whenever you want.
1. Load up your favorite artists, albums, and songs.
2. Hit Generate to get a preview for your playlist.
3. Click play and enjoy!
| Order | Song | Album | Artist |
|---|---|---|---|
| Press Generate to preview playlist |


We'll help you become your own mixologist in the comfort of your home!
You can find your favorite alcoholic and non-alcoholic cocktails on Express Bartender. Just input your drink of choice or submit one of your own! We'll provide you with a wide variety of options to quench your thirst.
- Users can search for a cocktail based on the name, main ingredient or alcohol preference they may already have on-hand.
- Discover and make new drinks!
- A special feature we added includes the user being able to enter their own drink into a database and store for future reference.
Our web application is designed to provide the user with a way to search for alcoholic and non-alcoholic cocktails that they are familiar with since our local bars are currently closed. Once you identify a cocktail of choice, we provide the ingredients and recipes to make your favorite drink from the comfort of your own home!
Cocktails
Pick Your Poison
- All Drinks
- Vodka
- Whiskey
- Rum
- Tequila
- Gin
Modal title
Spirit Guide
Getting to know your liquor
Vodka
Varieties originated in Russia, Poland, and Sweden.
- Traditionally made by fermenting the distilled liquid from cereal grains.
- Current distillers use potatoes and/or fruit as the base liquid.
- Typically consumed neat and served freezer chilled.
Whiskey
The birthplace of American whiskey can be traced back to Virginia, Maryland and Pennsylvania. In 1791, whiskey began to be brewed as a rye based product.
- Corn, the main ingredient of whiskey, making up 51% of its ingredients, was plentiful in its origin areas.
- Divided into two common brands: sour mash and bourbon.
- In 1897, the "Bottled In Bond" Act was passed into law stating that whiskey must be straight (50% alcohol by volume) and produced by one distillation season under one distiller and on the grounds of one distillery.
- It also must have been stored in a federally bonded warehouse under the supervision of the U.S. Government for at least four years. This bonded whiskey still holds a reputation for being the best of the best.
Gin
Gin, in its most basic terms, is a liquor of approximately 40% alcohol by volume (80 proof) or greater that is derived from grain distillation and primarily flavored with juniper berries (or juniper extract).
- Gin was originally produced as a medicine distributed by “chemists” for the treatment of ailments such as gout and dyspepsia..
- Certain types of gin can be enjoyed neat or on the rocks, or blended in a cocktail.
- Many distilleries have been producing the same type of gin since the early 1700s.
Tequila
Tequila is made from the blue agave plant, primarily in the Jaliscan Highlands of central western Mexico. Mexican laws state that tequila can only be produced in the state of Jalisco and limited municipalities in the states of Guanajuato, Michoacan, Nayarit, and Tamaulipas.
- Tequila is commonly served neat in Mexico and as a shot with salt and lime in the rest of the world.
- It is known for its sweet, fruity , and earthy flavor.
- Tequila must have between 35% and 55% alcohol content (70-110 US proof). It must contain at least 40% (80 US proof) alcohol to be sold in the US and Canada.
Rum
Rum is made by fermenting and then distilling sugarcane molasses or sugarcane juice, traditionally aged in oak barrels.
- Most rums are made in the Caribbean, and North and South America.
- Rums are produced in various grades, with light rums commonly used in cocktails, where golden and dark rums are served neat, straight, on the rocks, or used in cooking.
- The alcohol concentration of rum can range from 20%, as in coconut rum, 40% most commonly, and 75.5%, like in Bacardi 151.
- Some of the popular drinks containing rum are: The Daiquiri, Mojito, Pina Colada, and Cuba Libre.
Testimonials
What they're saying about us
After a long day working from home, I needed a cocktail to celebrate my new show on OWN. I logged onto Express Bartender and found the recipe for a Pink Champagne Margarita! I had the recipe right at my fingertips and started the weekend off right!
Oprah Winfrey
Ceo & Television Personality
On my trip to Vegas, I needed a pick me up after spending a long week being a TA for my bootcamp class. I had no idea what to make so I used Express Bartender to bring the party to me!
Wilson Lam
Web Developer
While my wife and I were stuck at home, I used Express Bartender to whip up a quick drink for my wife. I made a Negroni and surprised my wife. She loves it !
Stanley Tucci
Actor
Express Bartender saved the day for New Years Eve. We were able to find a recipe including champagne to ring in the new year!
Brittany Stephens
Entrepreneur
Gallery
Spirits For Any Occasion
Contact
Contact Us
Location:
2 Westwood Blvd, Los Angeles, CA 90095
Open Hours:
Monday-Saturday:
11:00 AM - 2300 PM
Email:
<EMAIL_ADDRESS>Call:
+1<PHONE_NUMBER>
Anissa Shanks, Kevin Fujimoto, Kevin Miller and Tim Hellman


Sharing R code in a workgroup of Mac/Windows/Linux users
10 May 2016In recent years there’s been a great deal of interest in, and work toward, creating more “reproducible” statistical code. I think this is a fantastic development. Looking at code I wrote in the late 90’s and early oughts, it’s clear how much a lot of my work from that period would have benefited from the coding habits I’ve developed over the last five or so years.
Working in R, a simple way to make code portable is to locate all data, functions, and scripts within a single directory/subdirectory which gets declared at the head of script and is followed by a series of relative paths in the lines to follow. This is standard process for projects you might find on Github.
But this is not always possible. Working in a corporate environment with protected/sensitive client data, I’m often forced to separate code from scripts, specifically, to keep certain sensitive data isolated on a particular server. I’m also not allowed to have any PII containing data in my git repositories. While I could exclude certain directories or file types from Git using, e.g., a .gitignore file, I’ve found it’s easier to just keep data in one place and scripts/functions in another. One more wrinkle: I work with Windows users, so simple references like “/data” will have different meanings if the Windows user is working from, say, the “D:\” drive.
I’ve tried and discarded a number of approaches to create a workflow that allows the same master code to run on a variety of computers which may have data stored in different places. Along the way I’ve refined my approach and have, in the last year or so, arrived at a process that allows me to work with others and with different types of OS’s in a reliable manner that requires little ongoing maintenance.
An added advantage the approach I’ve developed: if I want to move ALL of my main data sets, say from /data to /var/data, I can do this by changing one line of code in one file. After this change, all of my hundreds of scripts and markdown reports gracefully adapt to the change. They adapt because they all depend upon the same file to set up “the lay of the land” before any analysis. This requires a little extra work up front but, I find, saves a lot of headaches down the road — especially when working with other data scientists.
In short, my process is basically this:
1. The same (hopefully source controlled) file is sourced at the top of each analysis script. At the point of sourcing some parameters are declared which do the correct thing depending on whether the host is Linux, Mac, or Windows. Here’s an example:
2. The next step is to build your version of the file/directory parameter file that was sourced in step 1 by a script (in this post I’ll call this file “file_dir_params.R”).
3. Now add this function to the “file_dir_params.R”, which is used to save a simple string indicating the host’s OS type:
4. With our new environment loaded and knowledge of the computer’s OS, we’re ready to build platform agnostic variables that point to the most important shared directories in your group:
5. Depending on your setup you may have multiple project or data folders you want to declare. To keep my life simple on my development machine, I try and make all data a sub-directory of “prjdta” and all scripts a subdirectory of “prjdir”. Once you have these set using the platform agnostic pattern outlined in step 4, you’re ready to build out all your subdirectories. Because every sub-directory is a child of the root directories defined in step 4, make sure to always build new directory variables using one of the root directories (in my example, “prjdta” or “prjdir”). This is the key to making the code work across different platforms. It’s what allows the variable representing a folder to seamlessly shift between “C:/projects/some_folder” and “~/projects/some-folder” depending on the host which calls the script. One added and very useful bonus: if I move, say, my main data folder, I don’t have to rewrite 100 variable names in dozens of scripts. I just change the root data folder (in this example, “fdirs$prjdta”) once in one file and everything else takes care of itself in my batch environment. Here’s some examples:
6. Notice how, in the lines above, I reference the “show” and “build” flags we declared near the top of the “file_dir_params.R” script. What these do, respectively, is print the file location of the variable to standard output and build the folder if it does not exist. This can be useful but is not strictly necessary.
7. Our last step is to attach the “fdirs” environment (or safely reload it if it’s already attached):
Final Thoughts
Attaching the environment as we did in step 7 is a great time saver because your can omit the “fdirs$” prefix when you reference variables in your scripts. For example, to load a file in a data folder I now just write:
As opposed to:
But, as with everything, there’s a draw back: you’ll want to make sure the names of your variables don’t overlap with functions or other items you declare in a script. For this reason I use expressions like “prjdta” rather than “data”, and I avoid overly concise constructions that are used in a lot of example code, e.g. “x”, “y”, or “z”.
I hope some or all of the above is helpful to somebody, and feel free to drop me an email if you have any questions!