{% trans %} You're done! {% endtrans %}
{% else %}{% if new_version_number %} {% trans addon_name=addon.name, group_name=promoted_group.name %} You're done! A new version {{ new_version_number }} of your add-on {{ addon_name }} will be published as {{ group_name }} and should become available shortly. {% endtrans %} {% if existing_version_pending %} {{ _('A newer version of your add-on is currently pending review.') }} {% endif %} {{ _('If you have any questions, don’t hesitate to contact us.') }} {% else %} {% trans %} Your payment has been recorded, but there are currently no published versions of your add-on. Please upload a new public version in order to complete this process. {% endtrans %} {% endif %}
{% endif %} {% else %} {% if stripe_checkout_cancelled %}{% trans email=settings.VERIFIED_ADDONS_EMAIL %} There was an error while setting up payment for your add-on. If you're experiencing problems with this process or you've changed your mind, please contact us at {{ email }}. {% endtrans %}
{% trans %} Thank you for joining the Promoted Add-ons Program! {% endtrans %}
{% endif %}{% trans addon_name=addon.name %} Your add-on {{ addon_name }} will be included in the program once payment is set up through the Stripe system. Click on the button below to continue: {% endtrans %}
{% endif %}


Class std.optparse
Parse and process command line options.
Prototype Chain
table `-> Object `-> OptionParser
Objects
| std.optparse.OptionParser | OptionParser prototype object. |
Functions
| std.optparse.OptionParser_Init (spec) | Signature for initialising a custom OptionParser. |
| std.optparse.boolean (opt[, optarg="1"]) | Return a Lua boolean equivalent of various optarg strings. |
| std.optparse.file (opt, optarg) | Report an option parse error unless optarg names an existing file. |
| std.optparse.finished (arglist, i) | Finish option processing
This is the handler automatically assigned to the option written as
|
| std.optparse.flag (arglist, i[, value]) | Option at arglist[i] is a boolean switch. |
| std.optparse.help () | Option should display help text, then exit. |
| std.optparse.opterr (msg) | Report an option parse error, then exit with status 2. |
| std.optparse.optional (arglist, i[, value=true]) | Option at arglist[i] can take an argument. |
| std.optparse.required (arglist, i[, value]) | Option at arglist[i} requires an argument. |
| std.optparse.version () | Option should display version text, then exit. |
Tables
| std.optparse.boolvals | Map various option strings to equivalent Lua boolean values. |
| std.optparse.opts | Parsed options table, with a key for each encountered option, each with value set by that option's on_handler. |
Methods
| std.optparse:on (name, handler, value) | Add an option handler. |
| std.optparse:on_handler (arglist, i[, value=nil]) | Function signature of an option handler for on. |
| std.optparse:parse (arglist[, defaults]) | Parse an argument list. |
Objects
- std.optparse.OptionParser
-
OptionParser prototype object.
Most often, after instantiating an OptionParser, everything else is handled automatically.
Then, calling
parser:parse
as shown below saves unparsed arguments into_G.arg
(usually filenames or similar), and_G.opts
will be a table of successfully parsed option values. The keys into this table are the long-options with leading hyphens stripped, and non-word characters turned to_
. For example if--another-long
had been found in the initial_G.arg
, then_G.opts
will have a key namedanother_long
, with an appropriate value. If there is no long option name, then the short option is used, i.e._G.opts.b
will be set.The values saved against those keys are controlled by the option handler, usually just
true
or the option argument string as appropriate.Fields:
- _init OptionParser_Init initialisation function
- program string the first word following "Usage:" from spec
- version string the last white-space delimited word on the first line of text from spec
- versiontext string everything preceding "Usage:" from spec, and which will be displayed by the version on_handler
- helptext string everything including and following "Usage:" from spec string and which will be displayed by the help on_handler
Usage:
local std = require "std" local optparser = std.optparse [[ any text VERSION Additional lines of text to show when the --version option is passed. Several lines or paragraphs are permitted. Usage: PROGNAME Banner text. Optional long description text to show when the --help option is passed. Several lines or paragraphs of long description are permitted. Options: -b a short option with no long option --long a long option with no short option --another-long a long option with internal hypen -v, --verbose a combined short and long option -n, --dryrun, --dry-run several spellings of the same option -u, --name=USER require an argument -o, --output=[FILE] accept an optional argument --version display version information, then exit --help display this help, then exit Footer text. Several lines or paragraphs are permitted. Please report bugs at<EMAIL_ADDRESS>]] -- Note that std.io.die and std.io.warn will only prefix messages -- with `parser.program` if the parser options are assigned back to -- `_G.opts`: _G.arg, _G.opts = optparser:parse (_G.arg)
Functions
Methods- std.optparse.OptionParser_Init (spec)
-
Signature for initialising a custom OptionParser.
Read the documented options from spec and return custom parser that can be used for parsing the options described in spec from a run-time argument list. Options in spec are recognised as lines that begin with at least two spaces, followed by a hyphen.
Parameters:
- spec string option parsing specification
Returns:
-
OptionParser
a parser for options described by spec
Usage:
customparser = std.optparse (optparse_spec)
- std.optparse.boolean (opt[, optarg="1"])
-
Return a Lua boolean equivalent of various optarg strings.
Report an option parse error if optarg is not recognised.
Pass this as the
value
function to on when you want various "truthy" or "falsey" option arguments to be coerced to a Luatrue
orfalse
respectively in the options table.Parameters:
Returns:
-
bool
true
orfalse
Usage:
parser:on ("--enable-nls", parser.optional, parser.boolean)
- std.optparse.file (opt, optarg)
-
Report an option parse error unless optarg names an
existing file.
Pass this as the
value
function to on when you want to accept only option arguments that name an existing file.Parameters:
Returns:
-
string
optarg
Usage:
parser:on ("--config-file", parser.required, parser.file)
- std.optparse.finished (arglist, i)
-
Finish option processing
This is the handler automatically assigned to the option written as
--
in the OptionParser spec argument. You can also pass it as thehandler
argument to on if you want to manually add an end of options marker without writing it in the OptionParser spec.This handler tells the parser to stop processing arguments, so that anything after it will be an argument even if it otherwise looks like an option.
Parameters:
- arglist table list of arguments
- i
int
index of last processed element of
arglist
Returns:
-
int
index of next element of
arglist
to processUsage:
parser:on ("--", parser.finished)
- std.optparse.flag (arglist, i[, value])
-
Option at
arglist[i]
is a boolean switch.This is the handler automatically assigned to options that have
--long-opt
or-x
style specifications in the OptionParser spec argument. You can also pass it as thehandler
argument to on for options you want to add manually without putting them in the OptionParser spec.Beware that, unlike required, this handler will store multiple occurrences of a command-line option as a table only when given a
value
function. Automatically assigned handlers do not do this, so the option will simply betrue
if the option was given one or more times on the command-line.Parameters:
- arglist table list of arguments
- i int index of last processed element of arglist
- value either a function to process the option argument, or a value to store when this flag is encountered (optional)
Returns:
-
int
index of next element of arglist to process
Usage:
parser:on ({"--long-opt", "-x"}, parser.flag)
- std.optparse.help ()
-
Option should display help text, then exit.
This is the handler automatically assigned tooptions that have
--help
in the specification, e.g.-h, -?, --help
.Usage:
parser:on ("-?", parser.version)
- std.optparse.opterr (msg)
-
Report an option parse error, then exit with status 2.
Use this in your custom option handlers for consistency with the error output from built-in std.optparse error messages.
Parameters:
- msg string error message
- std.optparse.optional (arglist, i[, value=true])
-
Option at
arglist[i]
can take an argument. Argument is accepted only if there is a following entry that does not begin with a '-'.This is the handler automatically assigned to options that have
--opt=[ARG]
style specifications in the OptionParser spec argument. You can also pass it as thehandler
argument to on for options you want to add manually without putting them in the OptionParser spec.Like required, this handler will store multiple occurrences of a command-line option.
Parameters:
- arglist table list of arguments
- i int index of last processed element of arglist
- value either a function to process the option argument, or a default value if encountered without an optarg (default true)
Returns:
-
int
index of next element of arglist to process
Usage:
parser:on ("--enable-nls", parser.option, parser.boolean)
- std.optparse.required (arglist, i[, value])
-
Option at
arglist[i}
requires an argument.This is the handler automatically assigned to options that have
--opt=ARG
style specifications in the OptionParser spec argument. You can also pass it as thehandler
argument to on for options you want to add manually without putting them in the OptionParser spec.Normally the value stored in the
opt
table by this handler will be the string given as the argument to that option on the command line. However, if the option is given on the command-line multiple times,opt["name"]
will end up with all those arguments stored in the array part of a table:$ cat ./prog ... parser:on ({"-e", "-exec"}, required) _G.arg, _G.opt = parser:parse (_G.arg) print std.string.tostring (_G.opt.exec) ... $ ./prog -e '(foo bar)' -e '(foo baz)' -- qux {1=(foo bar),2=(foo baz)}
Parameters:
- arglist table list of arguments
- i int index of last processed element of arglist
- value either a function to process the option argument, or a forced value to replace the user's option argument. (optional)
Returns:
-
int
index of next element of arglist to process
Usage:
parser:on ({"-o", "--output"}, parser.required)
- std.optparse.version ()
-
Option should display version text, then exit.
This is the handler automatically assigned tooptions that have
--version
in the specification, e.g.-V, --version
.Usage:
parser:on ("-V", parser.version)
Tables
- std.optparse.boolvals
-
Map various option strings to equivalent Lua boolean values.
Fields:
- false false
- 0 false
- no false
- n false
- true true
- 1 true
- yes true
- y true
- std.optparse.opts
-
Parsed options table, with a key for each encountered option, each
with value set by that option's on_handler. Where an option
has one or more long-options specified, the key will be the first
one of those with leading hyphens stripped and non-alphanumeric
characters replaced with underscores. For options that can only be
specified by a short option, the key will be the letter of the first
of the specified short options:
{"-e", "--eval-file"} => opts.eval_file {"-n", "--dryrun", "--dry-run"} => opts.dryrun {"-t", "-T"} => opts.t
Generally there will be one key for each previously specified option (either automatically assigned by OptionParser or added manually with on) containing the value(s) assigned by the associated on_handler. For automatically assigned handlers, that means
true
for straight-forward flags and optional-argument options for which no argument was given; or else the string value of the argument passed with an option given only once; or a table of string values of the same for arguments given multiple times../prog -x -n -x => opts = { x = true, dryrun = true } ./prog -e '(foo bar)' -e '(foo baz)' => opts = {eval_file = {"(foo bar)", "(foo baz)"} }
If you write your own handlers, or otherwise specify custom handling of options with on, then whatever value those handlers return will be assigned to the respective keys in
opts
.
Methods
- std.optparse:on (name, handler, value)
-
Add an option handler.
When the automatically assigned option handlers don't do everything you require, or when you don't want to put an option into the OptionParser
spec
argument, use this function to specify custom behaviour. If you write the option into thespec
argument anyway, calling this function will replace the automatically assigned handler with your own.When writing your own handlers for std.optparse:on, you only need to deal with normalised arguments, because combined short arguments (
-xyz
), equals separators to long options (--long=ARG
) are fully expanded before any handler is called.Parameters:
- name opts of the option, or list of option names
- handler on_handler function to call when any of opts is encountered
- value additional value passed to on_handler
Usage:
-- Don't process any arguments after `--` parser:on ('--', parser.finished)
- std.optparse:on_handler (arglist, i[, value=nil])
-
Function signature of an option handler for on.
Parameters:
- arglist table list of arguments
- i int index of last processed element of arglist
- value
additional
value
registered with on (default nil)
Returns:
-
int
index of next element of arglist to process
- std.optparse:parse (arglist[, defaults])
-
Parse an argument list.
Parameters:
Returns:


Best Snow
Searching for the best snowpack for your next outdoor adventure?
Look no further!
- Search by City
- See weather station locations on map
- See if snowpack (snow depth) is low, average, or above-average
- See how todays snowpack compares to past seasons
Find the Best Snow in the west!
= Not great
= Better
= Best


Automates how object collections interact with other objects.
The Hub collection is used for containing a collection of objects. The Hub is observable, meaning that it sends events whenever a change is made. Hubs can be configured to automatically work together to form powerful relationships.
The hub package is made up of delegate classes that handle specific functionality and Hub subclasses that add automated features.


Tools for the simulation, analysis and sampling of spatial biodiversity data (May et al. 2017) <doi:10.1101/209502>. In the simulation tools user define the numbers of species and individuals, the species abundance distribution and species aggregation. Functions for analysis include species rarefaction and accumulation curves, species-area relationships and the distance decay of similarity.
| Version: | 0.1.0 |
| Imports: | Rcpp, vegan, sads (≥ 0.4.1), grDevices, utils, graphics, stats |
| LinkingTo: | Rcpp |
| Suggests: | rmarkdown, spatstat, testthat, knitr |
| Published: | 2017-11-02 |
| Author: | Felix May [aut, cre] |
| Maintainer: | Felix May <felix.may at posteo.de> |
| BugReports: | https://github.com/MoBiodiv/mobsim |
| License: | GPL-3 |
| URL: | http://github.com/MoBiodiv/mobsim |
| NeedsCompilation: | yes |
| Materials: | README |
| CRAN checks: | mobsim results |
| Reference manual: | mobsim.pdf |
| Vignettes: |
Analysis of biodiversity patterns Introduction to mobsim Sampling communities Simulating communities |
| Package source: | mobsim_0.1.0.tar.gz |
| Windows binaries: | r-devel: mobsim_0.1.0.zip, r-release: mobsim_0.1.0.zip, r-oldrel: mobsim_0.1.0.zip |
| OS X binaries: | r-release: mobsim_0.1.0.tgz, r-oldrel: mobsim_0.1.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=mobsim to link to this page.


I would love to get in touch with you, please Contact Me.
Needham, MA
B.S. in Engineering with Concentrations in Robotics expected in Spring 2023
Carson, CA
GPA: 3.96 UW
High School Diploma Received: June 2018
SAT: 1500, ACT: 35
Carson, CA
Concurrent Enrollment (2016-2018)
Credits Earned: 23.000
Junior Electrical Engineer
Motivo Engineering is a small engineering firm in Gardena, California that does contract work in three main fields: Mobility and Energy, Agricultural Technology, and Aerospace. In my time at Motivo, I have worked on a multitude of projects in the Autonomous Vehicle, Agricultural, and Consumer Electronic industries. My major projects include a Class 4 autonomous vehicle, where I developed code for the Low Level Controllers that featured full triple redundancy of the vehicle, an autonomous delivery vehicle, where I developed the firmware behind the cargo system that featured full control over ten actuators with active collision avoidance, and an AI powered computer vision system that autonomously cultivates crops in fields.
Mentor, Drive Coach
Team 4201, The Vitruvian Bots
, is a FIRST Robotics team based out of El Segundo, California. During my time on the team, I mentored students in the strategy, mechanical design, and controls aspects of the robot. I aided the students to complete the 2019 challenge, FIRST Deep Space, in a compressed 6 week timeline. This was the first year the team finished multiple iterations of prototypes throughout the build season, which led to the team's most sucessful year, where we finished as the 2019 FRC World Champions.
Mentor, Former Team Captain
Team 687, The Nerd Herd
, is a FIRST Robotics team based out of Carson, California. As Team Captain, I led the team every year in designing, building, and programming a fully functional 150-pound robot in six weeks. The robots range in size and shape, from a fourteen-inch tall ball shooter to a seven foot block stacker (it's cooler than I can make it sound) Now, as a mentor, I guide the students through the engineeirng design process.
Phantom Works Intern
Over the 2017 summer, I interned in the Phantom Works department at Boeing. I applied the skills and tools of Program Management to write a proposal document for a new program and pitched it to the site executive. I also worked alongside and learned from mechanical, systems, software, and quality engineers to create a technically sound proposal. In addition, I was invited to sit into weekly staff meetings with project managers to help evaluate the potential risks and opportunities each project in the department was facing.
Project Manager
CAMS Engineering Design and Development is the capstone program for the CAMS Engineering pathway. As Project Manager of Byte Technologies, I led the company that acted as the software contractor for two student engineering firms. Throughout the year, I headed a team of programmers to build a framework for twelve-robot suite that demonstrated swarm technology. The suite featured three autonomous aerial robots and nine autonomous ground-based robots that acted without a main leader, with all major decisions and task assignment distributed between the robots.
President
CAMS Computer Science Club (CAMSCSC) is a group of high school students passionate about the power of computers in the modern day. As club president, I taught and prepared the club for multiple computer science competitions, including picoCTF and NYU Poly's CSAW HSF. In addition, we host our own annual international computer science competition, CCTF, empowering over 2000 participants in 12 countries to practice their ethical hacking skills.
President
CAMS Computer Science Enrichment is a computer science summer camp for middle school students. Students learn the basic principles behind programming, forensics, exploitation, and cryptography and apply it to computer science challenge. As President of CAMS Computer Science Club (the club that runs the camp), I led the development of the lesson plan, challenges, and platform and the efforts to reach out to participants and sponsors.
Treasurer
CAMS Key Club is a service club that promotes student leadership and cooperation. During my time in Key Club, I hosted and participated in weekly community service events, gathering over 400 service hours. In addition, I also led efforts to fundraise for charitable causes, including Unicef's ELIMINATE project and CNH Key Club's PTP. During my year as treasurer, the club fundraised and donated over $4000.
FIRST Championship: Houston
FIRST Ventura Regional
FIRST Las Vegas Regional
FIRST Los Angeles Regional
OCRA Beach Blitz


The intersection of science, politics, personal opinion, and social policy can be rather complex. This junction of ideas and disciplines is often rife with controversies, strongly held viewpoints, and agendas that are often more based on belief than on empirical evidence. Data science is particularly important in this area since it provides a methodology for examining the world in a pragmatic fact-first manner, and is capable of providing insight into some of the most important issues that we face today.
The recent high-profile police shootings of unarmed black men, such as Michael Brown (2014), Tamir Rice (2014), Anton Sterling (2016), and Philando Castile (2016), have triggered a divisive national dialog on the issue of racial bias in policing.
These shootings have spurred the growth of large social movements seeking to raise awareness of what is viewed as the systemic targeting of people-of-color by police forces across the country. On the other side of the political spectrum, many hold a view that the unbalanced targeting of non-white citizens is a myth created by the media based on a handful of extreme cases, and that these highly-publicized stories are not representative of the national norm.
In June 2017, a team of researchers at Stanford University collected and released an open-source data set of 60 million state police patrol stops from 20 states across the US. In this tutorial, we will walk through how to analyze and visualize this data using Python.
The source code and figures for this analysis can be found in the companion Github repository - https://github.com/triestpa/Police-Analysis-Python
To preview the completed IPython notebook, visit the page here.
This tutorial and analysis would not be possible without the work performed by The Standford Open Policing Project. Much of the analysis performed in this tutorial is based on the work that has already performed by this team. A short tutorial for working with the data using the R programming language is provided on the official project website.
In the United States there are more than 50,000 traffic stops on a typical day. The potential number of data points for each stop is huge, from the demographics (age, race, gender) of the driver, to the location, time of day, stop reason, stop outcome, car model, and much more. Unfortunately, not every state makes this data available, and those that do often have different standards for which information is reported. Different counties and districts within each state can also be inconstant in how each traffic stop is recorded. The research team at Stanford has managed to gather traffic-stop data from twenty states, and has worked to regularize the reporting standards for 11 fields.
Most states do not have data available for every field, but there is enough overlap between the data sets to provide a solid foundation for some very interesting analysis.
We'll need to install a few Python packages to perform our analysis.
On the command line, run the following command to install the required libraries.
pip install numpy pandas matplotlib ipython jupyter
If you're using Anaconda, you can replace the
pip
command here withconda
. Also, depending on your installation, you might need to usepip3
instead ofpip
in order to install the Python 3 versions of the packages.
In the first cell of the notebook, import our dependencies.
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt
%matplotlib inline
figsize = (16,8)
We're also setting a shared variable figsize
that we'll reuse later on in our data visualization logic.
We'll start with analyzing the data set for Vermont. We're looking at Vermont first for a few reasons.
First, download the Vermont traffic stop data - https://stacks.stanford.edu/file/druid:py883nd2578/VT-clean.csv.gz
Load Vermont police stop data set into a Pandas dataframe.
df_vt = pd.read_csv('./data/VT-clean.csv.gz', compression='gzip', low_memory=False)
This command assumes that you are storing the data set in the
data
directory of the project. If you are not, you can adjust the data file path accordingly.
We can get a quick preview of the first ten rows of the data set with the head()
method.
df_vt.head()
We can also list the available fields by reading the columns
property.
df_vt.columns
Let's do a quick count of each column to determine how consistently populated the data is.
df_vt.count()
We can see that most columns have similar numbers of values besides search_type
, which is not present for most of the rows, likely because most stops do not result in a search.
For our analysis, it will be best to have the exact same number of values for each field. We'll go ahead now and make sure that every single cell has a value.
# Fill missing search type values with placeholder
df_vt['search_type'].fillna('N/A', inplace=True)
# Drop rows with missing values
df_vt.dropna(inplace=True)
When we count the values again, we'll see that each column has the exact same number of entries.
df_vt.count()
Let's get a list of all counties in the data set, along with how many traffic stops happened in each.
df_vt['county_name'].value_counts()
If you're familiar with Vermont's geography, you'll notice that the police stops seem to be more concentrated in counties in the southern-half of the state. The southern-half of the state is also where much of the cross-state traffic flows in transit to and from New Hampshire, Massachusetts, and New York. Since the traffic stop data is from the state troopers, this interstate highway traffic could potentially explain why we see more traffic stops in these counties.
Here's a quick map generated with Tableau to visualize this regional distribution.
We can also check out the distribution of traffic stop reasons.
df_vt['violation_raw'].value_counts()
df_vt['violation'].value_counts()
Unsurprisingly, the top reason for a traffic stop is Moving Violation
(speeding, reckless driving, etc.), followed by Equipment
(faulty lights, illegal modifications, etc.).
By using the violation_raw
fields as reference, we can see that the Other
category includes "Investigatory Stop" (the police have reason to suspect that the driver of the vehicle has committed a crime) and "Externally Generated Stop" (possibly as a result of a 911 call, or a referral from municipal police departments).
DUI
("driving under the influence", i.e. drunk driving) is surprisingly the least prevalent, with only 711 total recorded stops for this reason over the five year period (2010-2015) that the dataset covers. This seems low, since Vermont had 2,647 DUI arrests in 2015, so I suspect that a large proportion of these arrests were performed by municipal police departments, and/or began with a Moving Violation
stop, instead of a more specific DUI
stop.
We can also examine the traffic stop outcomes.
df_vt['stop_outcome'].value_counts()
A majority of stops result in a written warning - which goes on the record but carries no direct penalty. A bit over 1/3 of the stops result in a citation (commonly known as a ticket), which comes with a direct fine and can carry other negative side-effects such as raising a driver's auto insurance premiums.
The decision to give a warning or a citation is often at the discretion of the police officer, so this could be a good source for studying bias.
Let's break down the traffic stops by gender.
df_vt['driver_gender'].value_counts()
We can see that approximately 36% of the stops are of women drivers, and 64% are of men.
Let's also examine the distribution by race.
df_vt['driver_race'].value_counts()
Most traffic stops are of white drivers, which is to be expected since Vermont is around 94% white (making it the 2nd-least diverse state in the nation, behind Maine). Since white drivers make up approximately 94% of the traffic stops, there's no obvious bias here for pulling over non-white drivers vs white drivers. Using the same methodology, however, we can also see that while black drivers make up roughly 2% of all traffic stops, only 1.3% of Vermont's population is black.
Let's keep on analyzing the data to see what else we can learn.
It would be interesting to visualize how the frequency of police stops breaks down by both race and age.
df_vt = df_vt[df_vt['driver_race'] != 'Other']
fig, ax = plt.subplots(figsize=(20,8))
ax.set_xlim(15, 70)
for race in df_vt['driver_race'].unique():
s = df_vt[df_vt['driver_race'] == race]['driver_age']
s.plot.kde(ax=ax, label=race)
ax.legend()
# fig.savefig('images/race_age_dist.png', bbox_inches='tight')
We can see that young drivers in their late teens and early twenties are the most likely to be pulled over. Between ages 25 and 35, the stop rate of each demographic drops off quickly. As far as the racial comparison goes, the most interesting disparity is that for white drivers between the ages of 35 and 50 the pull-over rate stays mostly flat, whereas for other races it continues to drop steadily.
Now that we've got a feel for the dataset, we can start getting into some more advanced analysis.
One interesting topic that we touched on earlier is the fact that the decision to penalize a driver with a ticket or a citation is often at the discretion of the police officer. With this in mind, let's see if there are any discernable patterns in driver demographics and stop outcome.
In order to assist in this analysis, we'll define a helper function to aggregate a few important statistics from our dataset.
citations_per_warning
- The ratio of citations to warnings. A higher number signifies a greater likelihood of being ticketed instead of getting off with a warning.arrest_rate
- The percentage of stops that end in an arrest.def compute_outcome_stats(df):
"""Compute statistics regarding the relative quanties of arrests, warnings, and citations"""
n_total = len(df)
n_warnings = len(df[df['stop_outcome'] == 'Written Warning'])
n_citations = len(df[df['stop_outcome'] == 'Citation'])
n_arrests = len(df[df['stop_outcome'] == 'Arrest for Violation'])
citations_per_warning = n_citations / n_warnings
arrest_rate = n_arrests / n_total
return(pd.Series(data = {
'n_total': n_total,
'n_warnings': n_warnings,
'n_citations': n_citations,
'n_arrests': n_arrests,
'citations_per_warning': citations_per_warning,
'arrest_rate': arrest_rate
}))
Let's test out this helper function by applying it to the entire dataframe.
compute_outcome_stats(df_vt)
In the above result, we can see that about 1.17%
of traffic stops result in an arrest, and there are on-average 0.62
citations (tickets) issued per warning. This data passes the sanity check, but it's too coarse to provide many interesting insights. Let's dig deeper.
Using our helper function, along with the Pandas dataframe groupby method, we can easily compare these stats for male and female drivers.
df_vt.groupby('driver_gender').apply(compute_outcome_stats)
This is a simple example of the common split-apply-combine technique. We'll be building on this pattern for the remainder of the tutorial, so make sure that you understand how this comparison table is generated before continuing.
We can see here that men are, on average, twice as likely to be arrested during a traffic stop, and are also slightly more likely to be given a citation than women. It is, of course, not clear from the data whether this is indicative of any bias by the police officers, or if it reflects that men are being pulled over for more serious offenses than women on average.
Let's now compute the same comparison, grouping by race.
df_vt.groupby('driver_race').apply(compute_outcome_stats)
Ok, this is interesting. We can see that Asian drivers are arrested at the lowest rate, but receive tickets at the highest rate (roughly 1 ticket per warning). Black and Hispanic drivers are both arrested at a higher rate and ticketed at a higher rate than white drivers.
Let's visualize these results.
race_agg = df_vt.groupby(['driver_race']).apply(compute_outcome_stats)
fig, axes = plt.subplots(nrows=2, ncols=1, figsize=figsize)
race_agg['citations_per_warning'].plot.barh(ax=axes[0], figsize=figsize, title="Citation Rate By Race")
race_agg['arrest_rate'].plot.barh(ax=axes[1], figsize=figsize, title='Arrest Rate By Race')
# fig.savefig('images/citations_and_arrests_by_race.png', bbox_inches='tight')
We'll deepen our analysis by grouping each statistic by the violation that triggered the traffic stop.
df_vt.groupby(['driver_race','violation']).apply(compute_outcome_stats)
Ok, well this table looks interesting, but it's rather large and visually overwhelming. Let's trim down that dataset in order to retrieve a more focused subset of information.
# Create new column to represent whether the driver is White
df_vt['is_white'] = df_vt['driver_race'] == 'White'
# Remove violation with too few data points
df_vt_filtered = df_vt[~df_vt['violation'].isin(['Other (non-mapped)', 'DUI'])]
We're generating a new column to represent whether or not the driver is white. We are also generating a filtered version of the dataframe that strips out the two violation types with the fewest datapoints.
We not assigning the filtered dataframe to
df_vt
since we'll want to keep using the complete unfiltered dataset in the next sections.
Let's redo our race + violation aggregation now, using our filtered dataset.
df_vt_filtered.groupby(['is_white','violation']).apply(compute_outcome_stats)
Ok great, this is much easier to read.
In the above table, we can see that non-white drivers are more likely to be arrested during a stop that was initiated due to an equipment or moving violation, but white drivers are more likely to be arrested for a traffic stop resulting from "Other" reasons. Non-white drivers are more likely than white drivers to be given tickets for each violation.
Let's generate a bar chart in order to visualize this data broken down by race.
race_stats = df_vt_filtered.groupby(['violation', 'driver_race']).apply(compute_outcome_stats).unstack()
fig, axes = plt.subplots(nrows=1, ncols=2, figsize=figsize)
race_stats.plot.bar(y='arrest_rate', ax=axes[0], title='Arrest Rate By Race and Violation')
race_stats.plot.bar(y='citations_per_warning', ax=axes[1], title='Citations Per Warning By Race and Violation')
#
#fig.savefig('images/citations_and_arrests_by_race_and_violation.png', bbox_inches='tight')
We can see in these charts that Hispanic and Black drivers are generally arrested at a higher rate than white drivers (with the exception of the rather ambiguous "Other" category). and that Black drivers are more likely, across the board, to be issued a citation than white drivers. Asian drivers are arrested at very low rates, and their citation rates are highly variable.
These results are compelling, and are suggestive of potential racial bias, but they are too inconsistent across violation types to provide any definitive answers. Let's dig deeper to see what else we can find.
We can easily generate the same visualizations grouped by gender.
gender_stats = df_vt_filtered.groupby(['violation','driver_gender']).apply(compute_outcome_stats).unstack()
fig, axes = plt.subplots(nrows=1, ncols=2, figsize=figsize)
ax_gender_arrests = gender_stats.plot.bar(y='arrest_rate', ax=axes[0], title='Arrests By Gender and Violation', figsize=figsize)
ax_gender_citations = gender_stats.plot.bar(y='citations_per_warning', ax=axes[1], title='Citations By Gender and Violation', figsize=figsize)
#fig.savefig('images/citations_and_arrests_by_gender_and_violation.png', bbox_inches='tight')
Two of the more interesting fields available to us are search_conducted
and contraband_found
.
In the analysis by the "Standford Open Policing Project", they use these two fields to perform what is known as an "outcome test".
On the project website, the "outcome test" is summarized clearly.
In the 1950s, the Nobel prize-winning economist Gary Becker proposed an elegant method to test for bias in search decisions: the outcome test.
Becker proposed looking at search outcomes. If officers don’t discriminate, he argued, they should find contraband — like illegal drugs or weapons — on searched minorities at the same rate as on searched whites. If searches of minorities turn up contraband at lower rates than searches of whites, the outcome test suggests officers are applying a double standard, searching minorities on the basis of less evidence."
Findings, Stanford Open Policing Project
The authors of the project also make the point that only using the "hit rate", or the rate of searches where contraband is found, can be misleading. For this reason, we'll also need to use the "search rate" in our analysis - the rate at which a traffic stop results in a search.

We'll define a new function to compute the search rate and hit rate for the traffic stops in our dataframe.
0.20
would signify that out of 100 traffic stops, 20 resulted in a search.0.80
would signify that out of 100 searches, 80 searches resulted in contraband (drugs, unregistered weapons, etc.) being found.def compute_search_stats(df):
"""Compute the search rate and hit rate"""
search_conducted = df['search_conducted']
contraband_found = df['contraband_found']
n_stops = len(search_conducted)
n_searches = sum(search_conducted)
n_hits = sum(contraband_found)
# Filter out counties with too few stops
if (n_stops) < 50:
search_rate = None
else:
search_rate = n_searches / n_stops
# Filter out counties with too few searches
if (n_searches) < 5:
hit_rate = None
else:
hit_rate = n_hits / n_searches
return(pd.Series(data = {
'n_stops': n_stops,
'n_searches': n_searches,
'n_hits': n_hits,
'search_rate': search_rate,
'hit_rate': hit_rate
}))
We can test our new function to determine the search rate and hit rate for the entire state.
compute_search_stats(df_vt)
Here we can see that each traffic stop had a 1.2% change of resulting in a search, and each search had an 80% chance of yielding contraband.
Using the Pandas groupby
method, we can compute how the search stats differ by gender.
df_vt.groupby('driver_gender').apply(compute_search_stats)
We can see here that men are three times as likely to be searched as women, and that 80% of searches for both genders resulted in contraband being found. The data shows that men are searched and caught with contraband more often than women, but it is unclear whether there is any gender discrimination in deciding who to search since the hit rate is equal.
We can split the dataset into age buckets and perform the same analysis.
age_groups = pd.cut(df_vt["driver_age"], np.arange(15, 70, 5))
df_vt.groupby(age_groups).apply(compute_search_stats)
We can see here that the search rate steadily declines as drivers get older, and that the hit rate also declines rapidly for older drivers.
df_vt.groupby('driver_race').apply(compute_search_stats)
Black and Hispanic drivers are searched at much higher rates than White drivers (5% and 4% of traffic stops respectively, versus 1% for white drivers), but the searches of these drivers only yield contraband 60-70% of the time, compared to 80% of the time for White drivers.
Let's rephrase these results.
Black drivers are 500% more likely to be searched than white drivers during a traffic stop, but are 13% less likely to be caught with contraband in the event of a search.
Hispanic drivers are 400% more likely to be searched than white drivers during a traffic stop, but are 17% less likely to be caught with contraband in the event of a search.
Let's add in location as another factor. It's possible that some counties (such as those with larger towns or with interstate highways where opioid trafficking is prevalent) have a much higher search rate / lower hit rates for both white and non-white drivers, but also have greater racial diversity, leading to distortion in the overall stats. By controlling for location, we can determine if this is the case.
We'll define three new helper functions to generate the visualizations.
def generate_comparison_scatter(df, ax, state, race, field, color):
"""Generate scatter plot comparing field for white drivers with minority drivers"""
race_location_agg = df.groupby(['county_fips','driver_race']).apply(compute_search_stats).reset_index().dropna()
race_location_agg = race_location_agg.pivot(index='county_fips', columns='driver_race', values=field)
ax = race_location_agg.plot.scatter(ax=ax, x='White', y=race, s=150, label=race, color=color)
return ax
def format_scatter_chart(ax, state, field):
"""Format and label to scatter chart"""
ax.set_xlabel('{} - White'.format(field))
ax.set_ylabel('{} - Non-White'.format(field, race))
ax.set_title("{} By County - {}".format(field, state))
lim = max(ax.get_xlim()[1], ax.get_ylim()[1])
ax.set_xlim(0, lim)
ax.set_ylim(0, lim)
diag_line, = ax.plot(ax.get_xlim(), ax.get_ylim(), ls="--", c=".3")
ax.legend()
return ax
def generate_comparison_scatters(df, state):
"""Generate scatter plots comparing search rates of white drivers with black and hispanic drivers"""
fig, axes = plt.subplots(nrows=1, ncols=2, figsize=figsize)
generate_comparison_scatter(df, axes[0], state, 'Black', 'search_rate', 'red')
generate_comparison_scatter(df, axes[0], state, 'Hispanic', 'search_rate', 'orange')
generate_comparison_scatter(df, axes[0], state, 'Asian', 'search_rate', 'green')
format_scatter_chart(axes[0], state, 'Search Rate')
generate_comparison_scatter(df, axes[1], state, 'Black', 'hit_rate', 'red')
generate_comparison_scatter(df, axes[1], state, 'Hispanic', 'hit_rate', 'orange')
generate_comparison_scatter(df, axes[1], state, 'Asian', 'hit_rate', 'green')
format_scatter_chart(axes[1], state, 'Hit Rate')
return fig
We can now generate the scatter plots using the generate_comparison_scatters
function.
fig = generate_comparison_scatters(df_vt, 'VT')
#fig.savefig('images/search_scatters_VT.png', bbox_inches='tight')
The plots above are comparing search_rate
(left) and hit_rate
(right) for minority drivers compared with white drivers in each county. If all of the dots (each of which represents the stats for a single county and race) followed the diagonal center line, the implication would be that white drivers and non-white drivers are searched at the exact same rate with the exact same standard of evidence.
Unfortunately, this is not the case. In the above charts, we can see that, for every county, the search rate is higher for Black and Hispanic drivers even though the hit rate is lower.
Let's define one more visualization helper function, to show all of these results on a single scatter plot.
def generate_county_search_stats_scatter(df, state):
"""Generate a scatter plot of search rate vs. hit rate by race and county"""
race_location_agg = df.groupby(['county_fips','driver_race']).apply(compute_search_stats)
colors = ['blue','orange','red', 'green']
fig, ax = plt.subplots(figsize=figsize)
for c, frame in race_location_agg.groupby('driver_race'):
ax.scatter(x=frame['hit_rate'], y=frame['search_rate'], s=150, label=c, color=colors.pop())
ax.legend(loc='upper center', bbox_to_anchor=(0.5, 1.2), ncol=4, fancybox=True)
ax.set_xlabel('Hit Rate')
ax.set_ylabel('Search Rate')
ax.set_title("Search Stats By County and Race - {}".format(state))
return fig
fig = generate_county_search_stats_scatter(df_vt, "VT")
#fig.savefig('images/county_scatter_VT.png', bbox_inches='tight')
As the old idiom goes - a picture is worth a thousand words. The above chart is one of those pictures - and the name of the picture is "Systemic Racism".
The search rates and hit rates for white drivers in most counties are consistently clustered around 80% and 1% respectively. We can see, however, that nearly every county searches Black and Hispanic drivers at a higher rate, and that these searches uniformly have a lower hit rate than those on White drivers.
This state-wide pattern of a higher search rate combined with a lower hit rate suggests that a lower standard of evidence is used when deciding to search Black and Hispanic drivers compared to when searching White drivers.
You might notice that only one county is represented by Asian drivers - this is due to the lack of data for searches of Asian drivers in other counties.
Vermont is a great state to test out our analysis on, but the dataset size is relatively small. Let's now perform the same analysis on other states to determine if this pattern persists across state lines.
We've developed a solid reusable formula for reading and visualizing each state's dataset, so let's wrap the entire recipe in a new helper function.
fields = ['county_fips', 'driver_race', 'search_conducted', 'contraband_found']
types = {
'contraband_found': bool,
'county_fips': float,
'driver_race': object,
'search_conducted': bool
}
def analyze_state_data(state):
df = pd.read_csv('./data/{}-clean.csv.gz'.format(state), compression='gzip', low_memory=True, dtype=types, usecols=fields)
df.dropna(inplace=True)
df = df[df['driver_race'] != 'Other']
search_scatters = generate_comparison_scatters(df, state)
#search_scatters.savefig('images/search_scatters_{}.png'.format(state), bbox_inches='tight')
county_scatter = generate_county_search_stats_scatter(df, state)
#county_scatter.savefig('images/county_scatter_{}.png'.format(state), bbox_inches='tight')
return df.groupby('driver_race').apply(compute_search_stats)
We're making a few optimizations here in order to make the analysis a bit more streamlined and computationally efficient. By only reading the four columns that we're interested in, and by specifying the datatypes ahead of time, we'll be able to read larger datasets into memory more quickly.
First we'll generate the analysis for my home state, Massachusetts. This time we'll have more data to work with - roughly 3.4 million traffic stops.
Download the dataset to your project's /data
directory - https://stacks.stanford.edu/file/druid:py883nd2578/MA-clean.csv.gz
analyze_state_data('MA')
We can see here again that Black and Hispanic drivers are searched at significantly higher rates than white drivers. The differences in hit rates are not as extreme as in Vermont, but they are still noticeably lower for Black and Hispanic drivers than for White drivers. Asian drivers, interestingly, are the least likely to be searched and also the least likely to have contraband if they are searched.
If we compare the stats for MA to VT, we'll also notice that police in MA seem to use a much lower standard of evidence when searching a vehicle, with their searches averaging around a 50% hit rate, compared to 80% in VT.
The trend here is much less obvious than in Vermont, but it is still clear that traffic stops of Black and Hispanic drivers are more likely to result in a search, despite the fact the searches of White drivers are more likely to result in contraband being found.
Wisconsin and Connecticut have been named as some of the worst states in America for racial disparities. Let's see how their police stats stack up.
Again, you'll need to download the Wisconsin and Connecticut dataset to your project's /data
directory.
We can call our analyze_state_data
function for Wisconsin once the dataset has been downloaded.
analyze_state_data('WI')
The trends here are starting to look familiar. White drivers in Wisconsin are much less likely to be searched than non-white drivers (aside from Asians, who tend to be searched at around the same rates as whites). Searches of non-white drivers are, again, less likely to yield contraband than searches on white drivers.
We can see here, yet again, that the standard of evidence for searching Black and Hispanic drivers is lower in virtually every county than for White drivers. In one outlying county, almost 25% (!) of traffic stops for Black drivers resulted in a search, even though only half of those searches yielded contraband.
Let's do the same analysis for Connecticut
analyze_state_data('CT')
Again, the pattern persists.
We can generate each result rather quickly for each state (with available data), once we've downloaded each dataset.
analyze_state_data('AZ')
analyze_state_data('CO')
analyze_state_data('NC')
analyze_state_data('WA')
You might want to let this one run while you go fix yourself a cup of coffee or tea. At almost 24 million traffic stops, the Texas dataset takes a rather long time to process.
analyze_state_data('TX')
I highly recommend that you visit the Standford Open Policing Project results page for more visualizations of this data. Here you can browse the search outcome results for all available states, and explore additional analysis that the researchers have performed such as stop rate by race (using county population demographics data) as well as the effects of recreational marijuana legalization on search rates.
Do these results imply that police officers are overtly racist? No.
Do they show that Black and Hispanic drivers are searched much more frequently than white drivers, often with a lower standard of evidence? Yes.
What we are observing here appears to be a pattern of systemic racism. The racial disparities revealed in this analysis are a reflection of an entrenched mistrust of certain minorities in the United States. The data and accompanying analysis are indicative of social trends that are certainly not limited to police officers, and should not be used to disparage this profession as a whole. Racial discrimination is present at all levels of society from retail stores to the tech industry to academia.
We are able to empirically identify these trends only because state police deparments (and the Open Policing team at Stanford) have made this data available to the public; no similar datasets exist for most other professions and industries. Releasing datasets about these issues is commendable (but sadly still somewhat uncommon, especially in the private sector) and will help to further identify where these disparities exist, and to influence policies in order to provide a fair, effective way to counteract these biases.
To see the full official analysis for all 20 available states, check out the official findings paper here - https://5harad.com/papers/traffic-stops.pdf.
I hope that this tutorial has provided the tools you might need to take this analysis further. There's a lot more that you can do with the data than what we've covered here.
The source code and figures for this analysis can be found in the companion Github repository - https://github.com/triestpa/Police-Analysis-Python
To view the completed IPython notebook, visit the page here.
The code for this project is 100% open source (MIT license), so feel free to use it however you see fit in your own projects.


| Constructor and Description |
|---|
CatanMap() |
| Modifier and Type | Method and Description |
|---|---|
boolean |
canPlaceCityAtLocation(VertexLocation location,
int playerIndex,
java.lang.String status) |
boolean |
canPlaceRoadAtLocation(EdgeLocation location,
int playerIndex,
java.lang.String status) |
boolean |
canPlaceRobberAtLocation(HexLocation location) |
boolean |
canPlaceSettlementAtLocation(VertexLocation location,
int playerIndex,
java.lang.String status) |
java.util.List<ICommunity> |
getCities() |
java.util.List<IHex> |
getHexes() |
java.util.List<IPort> |
getPorts() |
int |
getRadius() |
java.util.List<IEdgeValue> |
getRoads() |
HexLocation |
getRobber() |
java.util.List<ICommunity> |
getSettlements() |
java.util.List<java.lang.Integer> |
getVictims(HexLocation robber) |
void |
setCities(java.util.List<ICommunity> cities) |
void |
setHexes(java.util.List<IHex> hexes) |
void |
setPorts(java.util.List<IPort> ports) |
void |
setRadius(int radius) |
void |
setRoads(java.util.List<IEdgeValue> roads) |
void |
setRobber(HexLocation robber) |
void |
setSettlements(java.util.List<ICommunity> settlements) |
public CatanMap()
public void setHexes(java.util.List<IHex> hexes)
public void setPorts(java.util.List<IPort> ports)
public java.util.List<IEdgeValue> getRoads()
public void setRoads(java.util.List<IEdgeValue> roads)
public java.util.List<ICommunity> getSettlements()
getSettlements
in interface ICatanMap
public void setSettlements(java.util.List<ICommunity> settlements)
setSettlements
in interface ICatanMap
public java.util.List<ICommunity> getCities()
public void setCities(java.util.List<ICommunity> cities)
public HexLocation getRobber()
public void setRobber(HexLocation robber)
public boolean canPlaceRoadAtLocation(EdgeLocation location, int playerIndex, java.lang.String status)
canPlaceRoadAtLocation
in interface ICatanMap
location
- an EdgeLocation where the player is trying to place a roadplayerIndex
- The index of the Current Playerstatus
- The status of the gamepublic boolean canPlaceSettlementAtLocation(VertexLocation location, int playerIndex, java.lang.String status)
canPlaceSettlementAtLocation
in interface ICatanMap
location
- an VertexLocation where the player is trying to place a settlementplayerIndex
- The index of the Current Playerstatus
- The status of the gamepublic boolean canPlaceCityAtLocation(VertexLocation location, int playerIndex, java.lang.String status)
canPlaceCityAtLocation
in interface ICatanMap
location
- an VertexLocation where the player is trying to place a cityplayerIndex
- The index of the Current Playerstatus
- The status of the gamepublic boolean canPlaceRobberAtLocation(HexLocation location)
canPlaceRobberAtLocation
in interface ICatanMap
location
- an HexLocation where the player is trying to place a robberpublic java.util.List<java.lang.Integer> getVictims(HexLocation robber)
getVictims
in interface ICatanMap
robber
- The HexLocation where the robber is located


Scenario I was given: You've been hired by some hipster-ass sandwich shop to design the tablet app their customers will use to order at the counter. This is for walk-in customers only, NOT for online ordering.
Here’s an annoying caveat: the client has requested that this be designed in such a way that the user doesn’t have to scroll up and down.
Returning users should have the option to get their regualr order, while new users should be able to put in a new order.
If a returing customer is registered in the system, all they have to do is plug in their number and their usual orders are there!
Keeping each screen simple will keep users moving along quickly, only making small descisons about menu items at a time. Keeping the line moving is a huge necessity in a SubStop.
For this project I made a prototype using Sketch & InVision. Check out the full prototype.


The NoiseTagging Framework for iOS
Table of Contents:
Important: For the full documentation, download the repository from Github (https://github.com/mindaffect/MindAffectSDKiOS) and open docs/index.html.
Developing this framework has been made possible by the generous support of the American, Belgian and Dutch ALS Associations, a.o. under Grants ATC20610 and 2017-57.
What is Noise Tagging?
MindAffect’s technology lets users control devices by simply looking at them. This system works as follows:
- One or multiple devices function as Presentation devices. Each of these devices shows one or multiple buttons. The goal of the system is to know to which button the user is looking, so it can press that button on behalf of the user and execute the corresponding action.
- The user wears an EEG headset. The system uses the EEG to deduce to which button the user is looking. For real? Yes for real! But we need to apply the following ‘trick'…
- Each button’s background color is controlled by a noise tag. For example a noise tag could be BWWBWBBW, which means that the button is black for a certain duration, then white for twice that duration, then black again, then white again, etcetera. As a result all buttons 'flicker’. When a user looks at a flickering button, this flickering can be found back in the EEG signal. Each button flickers in a unique way, so from the EEG we can deduce to which button the user is looking!
Noise Tagging can be used for various presentation devices, but in this document we focus on using an iPad or iPhone as the presentation device.
What Does the Framework Provide?
The NoiseTagging Framework for iOS makes it easy to develop iOS apps that can be controlled using noise tagging. To this end it offers the following functionality:
- Integration with other components of the MindAffect system;
- UI for letting users set everything up;
- Precise and effective flickering;
- Trial control;
- Generic UI components that work well with noise tagging;
- An in-app Developer screen with extra functionalities aimed at developers;
- Some supporting functionalities, like Text to Speech.
In upcoming Sections we discuss these in more detail.
Note: A small set of non-crucial functionalities only work correctly on an iPad screen, such as the Recordings screen, which allows developers to inspect collected log files within their own app.
System Integration
Here you find an overview of our system architecure: https://drive.google.com/open?id=1rmdK3u1Vxe78UVQbCRCWk8BVX6N4iisN
The ‘Presentation’ and ‘Output’ roles as depicted in this overview can be fulfilled by various devices. To this end a device needs to connect to the Decoder and implement a certain communication protocol. By using this framework you do not need to worry about this: the framework provides standard UI to let your users connect their iOS device to the Decoder and it handles all communication with the Decoder.
Setup Brain Control
Before users can start controlling your app using noise tagging, they need to perform a number of steps:
- Connect their iOS device with the Decoder;
- Check that the headset is fitted correctly;
- Calibrate the system.
The NoiseTagging framework provides two standard UIs in which the user can perform all of these tasks, as well as inspect the status of the system. For use cases where everything needs to brain-controllable – e.g. because users may be locked-in patients who want to be able to recalibrate the system without any help – the framework provides a number of screens which collectively we refer to as the Brain Control Layer. Alternatively a more streamlined – and prettier – UI is provided by the Simplified Brain Setup UI.
Flicker
For optimal recognition (that is: the best and fastest recognition of where the user is looking), it is important that:
- Buttons get assigned noise tags such that the EEG signal resulting from looking at them is optimally discernable;
- These noise tags are displayed as precisely as possible.
Clients of the NoiseTagging framework only need to tell it which buttons participate in noise tagging. The framework assigns appropriate noise tags.
Important: Noise tags are being displayed using a CADisplayLink
. When running in debug, this may lead to sub-optimal frame timing (assuming Xcode’s default build settings for debugging are used). Therefore we recommend to use a release configuration whenever using brain-control..
Trial Control
Applications that use noise tagging generally repeat these four steps, which together make up one trial:
- All buttons start to flicker.
- The user looks at the button that she wants to press. We call this button the ‘target’. Preferably the user is already looking at the target before the buttons start to flicker.
- At some point the system may decide that it is certain enough about to which button the user is looking. At this point the flickering stops and the button is pressed. Optionally there is a maximum to how long this may take. If time runs out, the flickering stops but no button is pressed. Instead the user will get feedback that the system failed to recognise to which button she was looking.
- There is a pause before the buttons start to flicker again, giving the user some time to take in the effects of the button press and to move her gaze towards the next target.
The NoiseTagging framework takes care of running trials. It starts running trials automatically once the system has been calibrated. Optionally users can also start or stop the running of trials manually by swiping up or down.
Design and Generic UI Components
Most iOS apps use generic UI components provided by iOS, such as UIButton, UITextField, UISlider, UIAlertController, etcetera. However, all of these rely on touch, so when designing a noise tagging app (an app that can be controlled using noise tagging) we need to take an alternative approach. The NoiseTagging framework provides a number of components to create UI that fits into the noise tagging paradigm. But before discussing these components, let us discuss some design aspects that determine the effectiveness of noise tagging.
Important Design Aspects
- Pushes only – iOS is based on multi-touch, which allows users to interact with stuff on the screen in a varied manner of ways. Using noise tagging we currently only have the equivalent to single taps. This means all controls must be made up out of simple push buttons.
- Button size – The degree to which the flickering of a target is visible in the EEG signal depends on the size of that target. Buttons need to be much larger than normal for noise tagging to work. On the other hand buttons can also be too large; e.g. if a button fills up the whole screen seeing it flicker is uncomfortable.
- On top of buttons – Most of the time buttons have titles or icons to tell the user what those buttons do. Note that in the case of noise tagging buttons there should not be too much on any button, because that would obscure the flickering! On the other hand something on top of a flickering button may actually help users keep their gaze focussed. For that reason any icon or title is best positioned in the button’s center.
- Button spacing – When the user looks at a flickering button, she may be distracted by nearby flickering buttons. Therefore buttons can better not be too close to each other.
- Size in general – In our experience the fact that the buttons need to be big, means that everything should be big for the design to be well-balanced.
- Number of buttons – This one follows from the previous ones: since UI components take up much more space than normally, the number of components that can be shown at any given moment is much smaller. Combined with the fact that pressing buttons using noise tagging is significantly slower than when using touch, this has BIG implications for designing your app. The number of things you can let your users do with just one ‘click’ is limited, so it becomes key to choose priorities wisely; for each functionality you add you should consider how that affects the speed by which users can access the other functionalities.
Generic UI Components
The NoiseTagging framework provides the following components, all specifically designed to be used with noise tagging:
- Simple button: a button with a title or icon.
- Labeled button: a button consisting of two parts: one with an icon, one with a title. Depending on the settings only the part with the icon flickers. Labeled buttons are especially fit for long button titles, or to provide the user with more state information by dynamically changing the button’s icon and/or title.
- Checkbox: a labeled button with a state that is either ON or OFF. The button’s icon and title match the button’s state.
- Popup button: a labeled button to select one out of a number of options. The button itself shows the currently selected option. If it is pressed, a popover is shown to choose from all possible options.
- Popover with buttons: a popover which can be populated with simple buttons. Optionally the popover also contains a button to close the popover without pressing any of the other buttons.
- Keyboard: a view controller which can be used to present a keyboard and let the user edit a text using noise tagging.
- Tree navigation: a controller that lets you create UI that is comparable to UINavigationController. It lets users navigate through a tree of pages, where each page can provide a list of sub pages for the user to navigate to. At the top the title of the current page is displayed and in the top left there is a button to go back to the previous page.
- Settings page: a page with automatically generated UI for editing settings.
- Alert: a popover similar to normal system alerts, but with buttons that can be pressed using noise tagging.
The Developer Screen
As the name already implies, the Developer Screen is not aimed at end users. But it does provide some things that can be handy during the development of your app.
In order to access the Developer Screen, double-press with two fingers. For now the only part of the Developer Screen relevant to clients is the Settings screen.
Next Steps
We recommend that you make your first brain-controllable app by going through our Quick Start
.
After that, we recommend to read the Main Programming Guide
, which should provide you with all the information to start developing your own great, brain-controllable iOS apps!


Program Class
Program class contains all the data of a nunuStudio program.
Program is also used to store and manage all available resources.
Constructor
Program
-
name
Parameters:
-
name
StringProgram name
Item Index
Methods
Methods
add
-
scene
Add new scene to this program.
On the program class only scenes can be added as children.
Parameters:
-
scene
Scene
addDefaultScene
-
material
Create a scene using a default template.
This is the scene used when creating a new program or scene inside the editor.
Parameters:
-
material
MaterialDefault material used by objects, if empty a new material is created
clone
()
Program
Clone program, keeping uuids and every identification attribute.
Clone method uses the ObjectLoad to serialize and create a new program instance with the same data.
Returns:
Cloned program
displayVR
()
Enter virtual reality mode.
To enter virtual reality mode a WebVR enabled browser is required.
When displaying VR content the display.requestAnimationFrame should be used to call the render method.
dispose
()
Dispose program data to avoid memory leaks.
Called when exiting the program.
exitVR
()
Exit virtual relity mode.
initialize
()
Select initial scene and initialize that scene.
Automatically called by the runtime.
receiveDataApp
-
data
Receive external data and pass it to all script instances.
Parameters:
-
data
Object
render
-
renderer
Render program to canvas.
Renderer passed as argument.
Parameters:
-
renderer
Renderer
resize
-
x
-
y
Resize program elements.
Called by the runtime every time the window is resized.
Parameters:
-
x
NumberWidth
-
y
NumberHeight
sendDataApp
-
data
Send data to external app instance.
Parameters:
-
data
Object
setInitialScene
-
uuid
Set a scene as initial scene using its uuid.
This method is used by the editor.
Parameters:
-
uuid
StringScene uuid
setMouseKeyboard
-
mouse
-
keyboard
Set program mouse and keyboard.
setRenderer
-
renderer
-
configure
Set program renderer to be used by this program.
Parameters:
-
renderer
WebGLRendererThree.js renderer to be used by this program
-
configure
BoolIf true also updates renderer configuration to match rendering quality specified in the program.
setScene
-
scene
Change scene during runtime, this method can receive booth a scene name or a scene object.
This method should be used inside of script objects during runtime.
Parameters:
-
scene
Scene | String
toJSON
-
meta
-
exportResources
Serialize object to JSON.
Parameters:
-
meta
Object -
exportResources
BooleanIf true all resouces in the program are exported, else only resources attached to objects are exported
Returns:
json
update
()
Update program state, this updated all current scene children elements.
Properties
antialiasing
Boolean
Antialiasing flag
Default: false
app
Unknown
NunuRuntime instance used to communication between nunu app and the host webpage
Default: null
canvas
DOM
Canvas being used to draw content.
Default: null
description
String
Program description
division
DOM
DOM Division element that can be used to add html content to the app.
Default: null
handlePixelRatio
Boolean
Flag to indicate if the runtime should handle device pixel ratio
Default: false
lockPointer
Boolean
Flag to control pointer locking
Default: false
renderer
WebGLRenderer
Threejs WebGLRenderer being used
Default: null
shadows
Boolean
If true the program is rendered with shadows
Default: true
shadowsType
Number
Shadow type
Default: PCFSoftShadowMap
toneMapping
Number
Tonemapping mode
Default: NoToneMapping
version
String
Program version
Default: "0"
vr
Boolean
Enable virtual reality flag
Default: false
vrScale
Number
Virtual reality movement scale
Default: 1.0


This package implements a simple alternative to the traditional Venn diagram. It depicts each overlap as a separate bubble with area proportional to the overlap size. Relation of the bubbles to input sets is shown by their their arrangement.
| Version: | 0.1 |
| Depends: | grid |
| Published: | 2012-08-09 |
| Author: | Raivo Kolde |
| Maintainer: | Raivo Kolde <rkolde at gmail.com> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: | no |
| CRAN checks: | bvenn results |
| Reference manual: | bvenn.pdf |
| Package source: | bvenn_0.1.tar.gz |
| Windows binaries: | r-devel: bvenn_0.1.zip, r-release: bvenn_0.1.zip, r-oldrel: bvenn_0.1.zip |
| OS X binaries: | r-release: bvenn_0.1.tgz, r-oldrel: bvenn_0.1.tgz |
Please use the canonical form https://CRAN.R-project.org/package=bvenn to link to this page.


Before Change
Returns:
:obj:`AssignResult`: The assign result.
if points.shape[0] == 0 or gt_bboxes.shape[0] == 0:
raise ValueError("No gt or bboxes")
points_xy = points[:, :2]
points_stride = points[:, 2]
points_lvl = torch.log2(
points_stride).int() // [3...,4...,5...,6...,7...]
After Change
num_points = points.shape[0]
num_gts = gt_bboxes.shape[0]
if num_gts == 0 or num_points == 0:
// If no truth assign everything to the background
assigned_gt_inds = points.new_full((num_points, ),
0,
dtype=torch.long)
if gt_labels is None:
assigned_labels = None
else:
assigned_labels = points.new_zeros((num_points, ),
dtype=torch.long)
return AssignResult(
num_gts, assigned_gt_inds, None, labels=assigned_labels)
points_xy = points[:, :2]
points_stride = points[:, 2]
points_lvl = torch.log2(
points_stride).int() // [3...,4...,5...,6...,7...]


Brand Logo
4:02 PM
Carrier
Filter your search with the following options...
Show Results For...
People
Activity
Refine Your Search...
By Distance
Start/End Weight Goal
Activity
Physical/Diet Limitations
Apply Filter
Cancel


This content is only shown to authenticated users.
This is an unsecured page, but you can access the secured pages after authenticating.


9.12.2. sklearn.pls.PLSCanonical¶
- class sklearn.pls.PLSCanonical(n_components=2, scale=True, algorithm='nipals', max_iter=500, tol=9.9999999999999995e-07, copy=True)¶
PLS canonical. PLSCanonical inherits from PLS with mode=”A” and deflation_mode=”canonical”.
Parameters : X: array-like of predictors, shape = [n_samples, p] :
Training vectors, where n_samples in the number of samples and p is the number of predictors.
Y: array-like of response, shape = [n_samples, q] :
Training vectors, where n_samples in the number of samples and q is the number of response variables.
n_components: int, number of components to keep. (default 2). :
scale: boolean, scale data? (default True) :
algorithm: string, “nipals” or “svd” :
The algorithm used to estimate the weights. It will be called n_components times, i.e. once for each iteration of the outer loop.
max_iter: an integer, (default 500) :
the maximum number of iterations of the NIPALS inner loop (used only if algorithm=”nipals”)
tol: non-negative real, default 1e-06 :
the tolerance used in the iterative algorithm
copy: boolean, default True :
Whether the deflation should be done on a copy. Let the default value to True unless you don’t care about side effect
Notes
For each component k, find weights u, v that optimize:: max corr(Xk u, Yk v) * var(Xk u) var(Yk u), such that |u| = |v| = 1
Note that it maximizes both the correlations between the scores and the intra-block variances.
The residual matrix of X (Xk+1) block is obtained by the deflation on the current X score: x_score.
The residual matrix of Y (Yk+1) block is obtained by deflation on the current Y score. This performs a canonical symetric version of the PLS regression. But slightly different than the CCA. This is mode mostly used for modeling.
References
Jacob A. Wegelin. A survey of Partial Least Squares (PLS) methods, with emphasis on the two-block case. Technical Report 371, Department of Statistics, University of Washington, Seattle, 2000.
Tenenhaus, M. (1998). La regression PLS: theorie et pratique. Paris: Editions Technic.
Examples
>>> from sklearn.pls import PLSCanonical, PLSRegression, CCA >>> X = [[0., 0., 1.], [1.,0.,0.], [2.,2.,2.], [2.,5.,4.]] >>> Y = [[0.1, -0.2], [0.9, 1.1], [6.2, 5.9], [11.9, 12.3]] >>> plsca = PLSCanonical(n_components=2) >>> plsca.fit(X, Y) PLSCanonical(algorithm='nipals', copy=True, max_iter=500, n_components=2, scale=True, tol=1e-06) >>> X_c, Y_c = plsca.transform(X, Y)
Attributes
x_weights_: array, shape = [p, n_components] X block weights vectors. y_weights_: array, shape = [q, n_components] Y block weights vectors. x_loadings_: array, shape = [p, n_components] X block loadings vectors. y_loadings_: array, shape = [q, n_components] Y block loadings vectors. x_scores_: array, shape = [n_samples, n_components] X scores. y_scores_: array, shape = [n_samples, n_components] Y scores. x_rotations_: array, shape = [p, n_components] X block to latents rotations. y_rotations_: array, shape = [q, n_components] Y block to latents rotations. Methods
fit(X, Y) predict(X[, copy]) Apply the dimension reduction learned on the train data. set_params(**params) Set the parameters of the estimator. transform(X[, Y, copy]) Apply the dimension reduction learned on the train data. - __init__(n_components=2, scale=True, algorithm='nipals', max_iter=500, tol=9.9999999999999995e-07, copy=True)¶
- predict(X, copy=True)¶
Apply the dimension reduction learned on the train data. Parameters ———- X: array-like of predictors, shape = [n_samples, p]
Training vectors, where n_samples in the number of samples and p is the number of predictors.- copy: boolean
- Whether to copy X and Y, or perform in-place normalization.
Notes
This call require the estimation of a p x q matrix, which may be an issue in high dimensional space.
- set_params(**params)¶
Set the parameters of the estimator.
The method works on simple estimators as well as on nested objects (such as pipelines). The former have parameters of the form <component>__<parameter> so that it’s possible to update each component of a nested object.
Returns : self :
- transform(X, Y=None, copy=True)¶
Apply the dimension reduction learned on the train data. Parameters ———- X: array-like of predictors, shape = [n_samples, p]
Training vectors, where n_samples in the number of samples and p is the number of predictors.- Y: array-like of response, shape = [n_samples, q], optional
- Training vectors, where n_samples in the number of samples and q is the number of response variables.
- copy: boolean
- Whether to copy X and Y, or perform in-place normalization.
Returns : x_scores if Y is not given, (x_scores, y_scores) otherwise. :


WITNESS LIST Appropriations-S/C on Duplication of Services Committee March 25, 1997-1:30P S/C ON DUPLICATION OF SERVICES On: COCKREHAM, PAUL (COMPTROLLER OF AUSTIN) HAGOOD, GARY (GENERAL LAND OFFICE) KIPLIN, KIM (TEXAS LOTTERY COMM.) MACBRIDE, CHERYL (GENERAL LAND OFFICE) MARQUEZ, RALPH (TNRCC) MAURO, GARRY (GENERAL LAND OFFICE) MEADOURS, STENNIE (TNRCC) REGAN, MIKE (RAILROAD COMMISSION) RINN, JAMES (TEXAS LOTTERY COMM.) RYLANDER, CAROLE (RAILROAD COMMISSION) TINTERA, JOHN (RAILROAD COMMISSION) YARBROUGH, RANDY (TABC)


I am an aspiring Graphic Designer born and raised in the Philippines. I moved to Lake Tahoe, California on April 2012 and earned my AA degree in Lake Tahoe Community College. Currently I am taking Graphic Design and Multimedia at California State University, East Bay.
I've been using Photoshop since 2008 during my freshman year in high school and through the years I've been able to develop my proficiency in other graphic design programs. I am also invested in becoming a Web Designer and apply the different design skills that i have learned while in University.
Email<EMAIL_ADDRESS>Email: vdatinguinoo@horizon.csueastbay.edu


- makePersistent(T) - Method in class org.judal.storage.table.RecordManager
-
- makePersistentAll(T...) - Method in class org.judal.storage.table.RecordManager
-
- makePersistentAll(Collection<T>) - Method in class org.judal.storage.table.RecordManager
-
- max(String, Predicate) - Method in interface org.judal.storage.relational.RelationalView
-
Get maximum value in a column for records matching a Predicate.
- MAX_ROWS - Static variable in interface org.judal.storage.keyvalue.ReadOnlyBucket
-
- MAXCONNECTIONS - Static variable in interface org.judal.storage.DataSource
-
Configuration property. int [MAXPOOLSIZE..n] Maximum number of allowed JDBC connections.
- maxDate(String, Predicate) - Method in class org.judal.storage.relational.AbstractRelationalOperation
-
Get maximum Date found in the given column for the results returned by a filter predicate.
- maxInt(String, Predicate) - Method in class org.judal.storage.relational.AbstractRelationalOperation
-
Get maximum Integer found in the given column for the results returned by a filter predicate.
- maxLong(String, Predicate) - Method in class org.judal.storage.relational.AbstractRelationalOperation
-
Get maximum Integer found in the given column for the results returned by a filter predicate.
- MAXPOOLSIZE - Static variable in interface org.judal.storage.DataSource
-
Configuration property. int [POOLSIZE..n] Maximum size of JDBC connection pool.
- MemberGroupDef - Class in org.judal.metadata
-
JDO FetchGroupMetadata interface implementation
- MemberGroupDef(String, String...) - Constructor for class org.judal.metadata.MemberGroupDef
-
Constructor
- METADATA - Static variable in interface org.judal.storage.DataSource
-
Configuration property.
- MetadataObjectFactory - Class in org.judal.metadata
-
Factory of metadata objects.
- MetadataObjectFactory() - Constructor for class org.judal.metadata.MetadataObjectFactory
-
- MetadataScanner - Interface in org.judal.metadata
-
Interface for SchemaMetaData scanners.
- min(String, Predicate) - Method in interface org.judal.storage.relational.RelationalView
-
Get minimum value in a column for records matching a Predicate.
- minDate(String, Predicate) - Method in class org.judal.storage.relational.AbstractRelationalOperation
-
Get minimum Date found in the given column for the results returned by a filter predicate.
- minInteger(String, Predicate) - Method in class org.judal.storage.relational.AbstractRelationalOperation
-
Get minimum Integer found in the given column for the results returned by a filter predicate.
- minLong(String, Predicate) - Method in class org.judal.storage.relational.AbstractRelationalOperation
-
Get minimum Integer found in the given column for the results returned by a filter predicate.
- MODE_APPEND - Static variable in interface org.judal.storage.ImportLoader
-
- MODE_APPENDUPDATE - Static variable in interface org.judal.storage.ImportLoader
-
- MODE_UPDATE - Static variable in interface org.judal.storage.ImportLoader
-


| Interface | Description |
|---|---|
| IUndoable |
Defines the functionality required to perform an undo operation on a particular component
|
| Class | Description |
|---|---|
| AbstractPileView |
Abstract representation of a pile view
|
| CardProxyView |
This view represents the outline of a normal card view
|
| CardView |
This view represents the representation of a single card
|
| DeckSelectionDialogView |
The deck selection dialog view shows the list of deck images that the user can choose from while playing the game
|
| FoundationPileView |
This view represents the foundation pile view
|
| GameView |
The game view wraps a draggable layout around the entire game
|
| OptionsDialogView |
The options view shows the settings that change the way the game is played
|
| ScoreView |
This view shows the game score
|
| StatusBarView | |
| StockView |
This view handles the functionality related to the Stock.
|
| TableauPileView |
This view represents a single Tableau pile
|
| TalonPileView |
This views represents the talon pile view.
|
| TimerView | |
| VegasScoreView |
This view shows the game score when playing in a vegas styled environment
|
| Enum | Description |
|---|---|
| TalonPileView.TalonCardState |
The available states of the talon
|


Refrigerant App
Select a refrigerant
R-22
Superheat or subcooling?
Superheat
Subcooling
Units of Temperature
°F
°C
Units of Pressure
PSI
kPa
|
gauge
absolute
I know my target superheat
Target Superheat
Condenser Air Dry-Bulb Temperature
Return Air Wet-Bulb Temperature
Suction Line Temperature (Low)
Suction Line Pressure (Low)
Target Subcooling
Discharge Line Temperature (High)
Discharge Line Pressure (High)


public static final class R.string
extends java.lang.Object
| Modifier and Type | Field and Description |
|---|---|
static int |
app_name |
static int |
bt_not_enabled_leaving |
static int |
button_scan |
static int |
connect
Options Menu
|
static int |
delete |
static int |
estSpeed |
static int |
hello |
static int |
none_found |
static int |
none_paired |
static int |
not_connected |
static int |
post |
static int |
request |
static int |
scanning
DeviceListActivity
|
static int |
select_device |
static int |
send
BluetoothChat
|
static int |
title_connected_to |
static int |
title_connecting |
static int |
title_not_connected |
static int |
title_other_devices |
static int |
title_paired_devices |
static int |
upload |
| Constructor and Description |
|---|
R.string() |
public static final int app_name
public static final int bt_not_enabled_leaving
public static final int button_scan
public static final int connect
public static final int delete
public static final int estSpeed
public static final int hello
public static final int none_found
public static final int none_paired
public static final int not_connected
public static final int post
public static final int request
public static final int scanning
public static final int select_device
public static final int send
public static final int title_connected_to
public static final int title_connecting
public static final int title_not_connected
public static final int title_other_devices
public static final int title_paired_devices
public static final int upload


Unordered lists
- First item
- Second item
- Third item
- First item
- Second item
- Third item
- First item
- Second item
- Third item
- First item
- Second item
- Third item
Ordered lists
- First item
- Second item
- Third item
- First item
- Second item
- Third item
- First item
- Second item
- Third item
- First item
- Second item
- Third item


with $five as 5 a big red circle: a bit left of center a small yellow circle: at $five pixels right of center


Python Data Scientist | Full Stack Dev
I make simple websites with HTML/CSS/Javascript and Fullstack websites with Node and React. My experiences are more focused on personal projects and events.
I have studied Artificial Intelligence since 2018 at the university with Scientific Initiation, having worked with Energy and Computer Vision. My experience is more focused in articles in Lattes
I'm a Physics Engineer Studend who loves technology and programming.
I have been studying technology since 2015 with an computer installation and maintenance technician. , where I had my first contact with programming logic. Since 2017, during university, I have experience with python, having already programmed for IoT and Deep Learning mainly.
I have also programmed in C/C++, HTML/CSS/Javascript and node for fullstack sites. In addition, I've made games using Engines like Gamemaker, Unity, Godot and Pygame.
A selection of my range of work
Still Working on It


3 implementations of IScriptCommandInfo
System.Management.Automation (3)
engine\ExternalScriptInfo.cs (1)
20
public class ExternalScriptInfo : CommandInfo,
IScriptCommandInfo
engine\FunctionInfo.cs (1)
13
public class FunctionInfo : CommandInfo,
IScriptCommandInfo
engine\ScriptInfo.cs (1)
12
public class ScriptInfo : CommandInfo,
IScriptCommandInfo
27 references to IScriptCommandInfo
System.Management.Automation (27)
engine\CommandDiscovery.cs (1)
705
private static CommandProcessorBase GetScriptAsCmdletProcessor(
IScriptCommandInfo
scriptCommandInfo, ExecutionContext context, bool useNewScope, bool fromScriptFile, SessionStateInternal sessionState)
engine\CommandInfo.cs (2)
528
IScriptCommandInfo
scriptCommand = this as
IScriptCommandInfo
;
engine\CommandProcessor.cs (6)
76
internal CommandProcessor(
IScriptCommandInfo
scriptCommandInfo, ExecutionContext context, bool useLocalScope, bool fromScriptFile, SessionStateInternal sessionState)
110
IScriptCommandInfo
scriptCommandInfo = CommandInfo as
IScriptCommandInfo
;
219
var
scriptCmdletInfo = this.CommandInfo as
IScriptCommandInfo
;
768
private void Init(
IScriptCommandInfo
scriptCommandInfo)
engine\CommandProcessorBase.cs (1)
41
if (commandInfo is
IScriptCommandInfo
scriptCommand)
engine\ErrorPackage.cs (3)
234
&& (_errorRecord.InvocationInfo.MyCommand is CmdletInfo || _errorRecord.InvocationInfo.MyCommand is
IScriptCommandInfo
)
1666
IScriptCommandInfo
scriptInfo = commandInfo as
IScriptCommandInfo
;
engine\GetCommandCommand.cs (1)
1323
&& current is not
IScriptCommandInfo
)
engine\hostifaces\LocalPipeline.cs (2)
943
IScriptCommandInfo
functionInfo = commandInfo as
IScriptCommandInfo
;
engine\ScriptCommandProcessor.cs (2)
29
protected ScriptCommandProcessorBase(
IScriptCommandInfo
commandInfo, ExecutionContext context, bool useLocalScope, SessionStateInternal sessionState)
78
new ScriptParameterBinderController(((
IScriptCommandInfo
)CommandInfo).ScriptBlock,
help\CommandHelpProvider.cs (6)
92
IScriptCommandInfo
scriptCommandInfo = commandInfo as
IScriptCommandInfo
;
155
IScriptCommandInfo
scriptCommandInfo = commandInfo as
IScriptCommandInfo
;
199
IScriptCommandInfo
scriptCommandInfo = commandInfo as
IScriptCommandInfo
;
help\HelpCommentsParser.cs (3)
647
string scriptFile = ((
IScriptCommandInfo
)commandInfo).ScriptBlock.File;
670
IScriptCommandInfo
scriptCommandInfo = (
IScriptCommandInfo
)commandInfo;


About 398 farmers in Kwahu South benefit from PFJ programme
by Eunice Tekie Tei, GNAKwahu- Mpraeso (E/R), Nov. 16, GNA - Over 398 farmers in the Kwahu South District have benefitted from the government's 'Planting for Food and Jobs'(PFJ) programme.
The farmers benefited from subsidised fertilizers and seeds and planted maize and vegetables.
Mr Emmanuel Atta- Ofori, the District Chief Executive (DCE), who disclosed this during the Assembly's meet-the- press forum at Mpraeso said the assembly would do its best to ensure that the people benefited from government's flagship programmes to enhance their lots.
The DCE said many of the farmers also signed onto the Planting for Export and Rural Development (PERD) initiative and were into coffee and coconut production.
He said the district agriculture extension officers also schooled farmers on the use of modern technologies such as proper application of fertilizers, diseases and pests control, planting in distance, planting in time and how to prevent post-harvest loses, resulting in high yields.
Mr Atta- Ofori said the assembly also procured 420,000 coffee seedlings out of which 187,989 had already been distributed to farmers.
He said PERD aimed at encouraging the farmers to cultivate tree crops such as mangoes, coffee, cocoa, oil palm, cassava, coconut and cashews as a form of investment and to produce raw materials to spur the establishment of factories in the District.
He said PFJ and 'PERD initiatives were making significant impacts on the economy as a result of which the country had reduced the importation of some food crops."
Mr Atta- Ofori therefore called on the citizenry to support the government in implementing the various initiatives for accelerated socio-economic development.
GNA


The [RenderHtml] attribute can be attached to a component or region to define the contents of that cmponent or region is localizable static Html.
The [RenderHtml()] attribute has the following properties you can set.
This name is passed to the localization system to retrieve the locale specific version of the Html to write. Every piece of localized text must have a unique name, so you should come up with a naming convention that makes this manageable.
This default Html to render when there is no locale specific version of the Html configured in the localization system.
.Net does not preserve the order of attributes attached to classes, but the order of rendering Html is obviously important in the case where multiple [RenderHtml()] attributes have been attached to an element.
This property is required when there are multiple [RenderHtml()] attributes attached to an element to define the order in which they will be rendered.


WITNESS LIST Appropriations-S/C on Education Committee February 15, 1999-8:00A Budget On: Adams, H. Richard (Texas A & M College of Veterinary Medicine) Avant, Robert (Texas Food and Fibers Commission) Bennett, G. Kemble (Texas Engineering Extension Service) Beverly, John (Texas Agricultural Experiment Station) Bowen, Ray (Texas A & M University) Brown, Don (Texas Higher Education Coordination Board) Calvert, Stanton (Texas A & M University System) Cisneros, Marc (Texas A & M University - Kingsville) DeBakey, Michael (Baylor College of Medicine) Eugster, Konrad (Texas Veterinary Medical Diagnostic Lab) Fehlis, Chester (Texas Agricultural Extension Service) Furgason, Robert (Texas A & M University - Corpus Christi) Garcia, Jose (Texas A & M International University) Haden, Clovis (Texas Engineering Experiment Station) Hensley, Stephen (Texas A & M University - Texarkana) Hiler, Edward (Texas Agricultural Experiment Station and Texas Agricultural Extension Service) Hines, Charles (Prairie View A & M University) Hull, James (Texas Forest Service) Jennett, Charles (Texas A & M International University) Kale, Tom (Texas A & M University System) Kemp, Mike (Texas A & M University - Galveston) Kirby, Robert (Texas A & M University - Kingsville) Long, Russell (West Texas A & M University) McCabe, Dennis (Tarleton State University) McFarland, Keith (Texas A & M University - Commerce) Noren, Jay (Texas A & M University Health Science Center) Nunley, Gary (Texas Wildlife Damage Management Service) Richardson, Herbert (Texas Transportation Institute) Sanford, William (Texas Higher Education Coordinating Board) Sayavedra, Leo (Texas A & M University System) Thompson, Barry (Texas A & M University System)


China, U.S. had 'constructive' phone call on trade - Xinhua
by ReutersBEIJING — China and United States had “constructive talks” on trade in a high-level phone call on Saturday, state media Xinhua said.
China’s Vice Premier Liu He, U.S. trade representative Robert Lighthizer and Treasury Secretary Steven Mnuchin were on the call. The two sides discussed each other’s core issues for the first phase of an initial trade agreement, and agreed to maintain dialog, according to Xinhua. (Reporting by Min Zhang and Norihiko Shirouzu; Editing by Kim Coghill)


App created by Luke Liukonen.
copyright 2020. MIT License
Developed as a quick string editor that has different bells and
whistles then say, notepad++. Implements some common one off items
that a developer might need for string editing
Info about FavIcon: Icon made by
Pixel perfect
from
www.flaticon.com
More information can be found at my homepage
https://liukonen.dev


The C++ language interface provides functions listed below for mixed-language operability. These functions provide for a seamless transition between C and C++. For the case where the C++ class corresponding to <CLASS> has derived classes, functions are also provided for converting between the derived classes and the C MPI_<CLASS>.
MPI::<CLASS>& MPI::<CLASS>::operator=(const MPI_<CLASS>& data)
MPI::<CLASS>(const MPI_<CLASS>& data)
MPI::<CLASS>::operator MPI_<CLASS>() const
These functions are discussed in Section Transfer of Handles .


Across: 1. Hospital gown is in the cupboard (8) 5. In two seconds fasten lots! (6) 9. Reluctant to put it back in centre (8) 10. Beat actor to the sea in France (6) 12. Order Pils as "Pilth"? (4) 13. Material for hard-wearing shoes? (10) 15. Organising speech about Rupert's first trunk (13) 19. Breach agreement about returning art (13) 23. Sharp training sessions with Peter and Vic (10) 25. Cleaner fish (4) 28. There, a mixture to warm up again (6) 29. Shortage found by Mark London (8) 30. Engineer's papers? (6) 31. Any saris from northern Iraq? (8) Down: 1. Splendid Scots turn to the French and sing! (6) 2. Charges and tears about (5) 3. Chip in about cereal (4) 4. Group get time for dressing (7) 6. Follow the bird in Yorkshire, maybe (5) 7. Firm proposal about money initially causes uproar! (9) 8. Harsh red tints! (8) 11. Cut and tie back about 500 (4) 14. Arcs over cliff (4) 15. Whisper "No possession!" (9) 16. Look at Bob with ease, we hear (3) 17. Bitter policemen chase one! (4) 18. Respects symbols of authority (8) 20. Checks out surgeons (4) 21. Squeaky-clean newcomers (7) 22. Cold material found in drawer (6) 24. Avoid being found in Geneva delicatessen (5) 26. I hit a problem in the country (5) 27. Wear for battle? (4)


Note
For a complete list of CLI Debug commands refer to the Debug CLI section of the Source Code Documents .
IP Route¶
Summary/Usage¶
ip route [add|del] [count <*n*>] <*dst-ip-addr*>/<*width*> [table <*table-id*>] via [next-hop-address[next-hop-interface] [next-hop-table <*value*>] [weight <*value*>] [preference <*value*>] [udp-encap-id <*value*>] [ip4-lookup-in-table <*value*>] [ip6-lookup-in-table <*value*>] [mpls-lookup-in-table <*value*>] [resolve-via-host] [resolve-via-connected] [rx-ip4 <*interface*>] [out-labels <*value value value*>]
Description¶
This command is used to add or delete IPv4 or IPv6 routes. All IP Addresses (‘<dst-ip-addr>/<width>’, ‘<next-hop-ip-addr>’ and ‘<adj-hop-ip-addr>’) can be IPv4 or IPv6, but all must be of the same form in a single command. To display the current set of routes, use the commands ‘show ip fib’ and ‘show ip6 fib’.
Example Usage¶
Example of how to add a straight forward static route:
vpp# ip route add <IP_ADDRESS>/32 via <IP_ADDRESS> GigabitEthernet2/0/0
Example of how to delete a straight forward static route:
vpp# ip route del <IP_ADDRESS>/32 via <IP_ADDRESS> GigabitEthernet2/0/0
Mainly for route add/del performance testing, one can add or delete multiple routes by adding ‘count N’ to the previous item:
vpp# ip route add count 10 <IP_ADDRESS>/24 via <IP_ADDRESS> GigabitEthernet2/0/0
Add multiple routes for the same destination to create equal-cost multipath:
vpp# ip route add <IP_ADDRESS>/32 via <IP_ADDRESS> GigabitEthernet2/0/0
vpp# ip route add <IP_ADDRESS>/32 via <IP_ADDRESS> GigabitEthernet2/0/0
For unequal-cost multipath, specify the desired weights. This combination of weights results in 3/4 of the traffic following the second path, 1/4 following the first path:
vpp# ip route add <IP_ADDRESS>/32 via <IP_ADDRESS> GigabitEthernet2/0/0 weight 1
vpp# ip route add <IP_ADDRESS>/32 via <IP_ADDRESS> GigabitEthernet2/0/0 weight 3
To add a route to a particular FIB table (VRF), use:
vpp# ip route add <IP_ADDRESS>/24 table 7 via GigabitEthernet2/0/0
Declaration and Implementation¶
Declaration: ip_route_command (src/vnet/ip/lookup.c line 641)
Implementation: vnet_ip_route_cmd
Ping¶
Summary/Usage¶
ping {<ip-addr> | ipv4 <ip4-addr> | ipv6 <ip6-addr>} [ipv4 <ip4-addr> | ipv6 <ip6-addr>] [source <interface>] [size <pktsize>] [interval <sec>] [repeat <cnt>] [table-id <id>] [verbose]
Description¶
This command sends an ICMP ECHO_REQUEST to network hosts. The address can be an IPv4 or IPv6 address (or both at the same time).
Example Usage¶
Example of how ping an IPv4 address:
vpp# ping <IP_ADDRESS> source GigabitEthernet2/0/0 repeat 2
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=.1090 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=.0914 ms
Statistics: 2 sent, 2 received, 0% packet loss
Example of how ping both an IPv4 address and IPv6 address at the same time:
vpp# ping <IP_ADDRESS> ipv6 fe80::24a5:f6ff:fe9c:3a36 source GigabitEthernet2/0/0 repeat 2 verbose
Adjacency index: 10, sw_if_index: 1
Adj: ip6-discover-neighbor
Adj Interface: 0
Forced set interface: 1
Adjacency index: 0, sw_if_index:<PHONE_NUMBER>
Adj: ip4-miss
Adj Interface: 0
Forced set interface: 1
Source address: <IP_ADDRESS>
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=.1899 ms
Adjacency index: 10, sw_if_index: 1
Adj: ip6-discover-neighbor
Adj Interface: 0
Forced set interface: 1
Adjacency index: 0, sw_if_index:<PHONE_NUMBER>
Adj: ip4-miss
Adj Interface: 0
Forced set interface: 1
Source address: <IP_ADDRESS>
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=.0910 ms
Statistics: 4 sent, 2 received, 50% packet loss
Declaration and Implementation¶
Declaration: ping_command (src/vnet/ip/ping.c line 899)
Implementation: ping_ip_address