Input Data¶
The Catalog class¶
-
class
treecorr.
Catalog
(file_name=None, config=None, num=0, logger=None, is_rand=False, x=None, y=None, z=None, ra=None, dec=None, r=None, w=None, wpos=None, flag=None, g1=None, g2=None, k=None, **kwargs)[source]¶ A set of input data (positions and other quantities) to be correlated.
A Catalog object keeps track of the relevant information for a number of objects to be correlated. The objects each have some kind of position (for instance (x,y), (ra,dec), (x,y,z), etc.), and possibly some extra information such as weights (w), shear values (g1,g2), or kappa values (k).
The simplest way to build a Catalog is to simply pass in numpy arrays for each piece of information you want included. For instance:
>>> cat = treecorr.Catalog(x=x, y=y, k=k, w=w)
Each of these input paramters should be a numpy array, where each corresponding element is the value for that object. Of course, all the arrays should be the same size.
In some cases, there are additional required parameters. For instance, with RA and Dec positions, you need to declare what units the input values are given:
>>> cat = treecorr.Catalog(ra=ra, dec=dec, g1=g1, g2=g2, ... ra_units='hour', dec_units='deg')
For (ra,dec) positions, these units fields are required to specify the units of the angular values. For (x,y) positions, the units are optional (and usually unnecessary).
You can also initialize a Catalog by reading in columns from a file. For instance:
>>> cat = treecorr.Catalog('data.fits', ra_col='ALPHA2000', dec_col='DELTA2000', ... g1_col='E1', g2_col='E2', ra_units='deg', dec_units='deg')
This reads the given columns from the input file. The input file may be either a FITS catalog or an ASCII catalog. Normally the file type is determined according to the file’s extension (e.g. ‘.fits’ here), but it can also be set explicitly with file_type.
Finally, you may store all the various parameters in a configuration dict and just pass the dict as an argument after the file name:
>>> config = { 'ra_col' : 'ALPHA2000', ... 'dec_col' : 'DELTA2000', ... 'g1_col' : 'E1', ... 'g2_col' : 'E2', ... 'ra_units' : 'deg', ... 'dec_units' : 'deg' } >>> cat = treecorr.Catalog(file_name, config)
This can be useful for encapsulating all the TreeCorr options in a single place in your code, which might be used multiple times. Notably, this syntax ignores any dict keys that are not relevant to the Catalog construction, so you can use the same config dict for the Catalog and your correlation objects, which can be convenient.
See also Configuration Parameters for complete descriptions of all of the relevant configuration parameters, particularly the first section Parameters about the input file(s).
You may also override any configuration parameters or add additional parameters as kwargs after the config dict. For instance, to flip the sign of the g1 values after reading from the input file, you could write:
>>> cat1 = treecorr.Catalog(file_name, config, flip_g1=True)
After construction, a Catalog object will have the following attributes:
Attributes: x – The x positions, if defined, as a numpy array (converted to radians if x_units was given). (None otherwise)
y – The y positions, if defined, as a numpy array (converted to radians if y_units was given). (None otherwise)
z – The z positions, if defined, as a numpy array. (None otherwise)
ra – The right ascension, if defined, as a numpy array (in radians). (None otherwise)
dec – The declination, if defined, as a numpy array (in radians). (None otherwise)
r – The distance, if defined, as a numpy array. (None otherwise)
w – The weights, as a numpy array. (All 1’s if no weight column provided.)
wpos – The weights for position centroiding, as a numpy array. (All 1’s if neither weight column provided.)
g1 – The g1 component of the shear, if defined, as a numpy array. (None otherwise)
g2 – The g2 component of the shear, if defined, as a numpy array. (None otherwise)
k – The convergence, kappa, if defined, as a numpy array. (None otherwise)
ntot – The total number of objects (including those with zero weight)
nobj – The number of objects with non-zero weight
sumw – The sum of the weights
varg – The shear variance (aka shape noise) (0 if g1,g2 are not defined) Note: If there are weights, this is really \(\sum(w^2 |g|^2)/\sum(w)\), which is more like \(\langle w \rangle \mathrm{Var}(g)\). In finalize, we divide this by the weight in each bin, so this is the right quantity to use there.
vark – The kappa variance (0 if k is not defined) Note: If there are weights, this is really \(\sum(w^2 \kappa^2)/\sum(w)\).
name – When constructed from a file, this will be the file_name. It is only used as a reference name in logging output after construction, so if you construct it from data vectors directly, it will be ‘’. You may assign to it if you want to give this catalog a specific name.
coords – What kind of coordinate system is defined for this catalog? The possibilities for this attribute are:
- ‘flat’ = 2-dimensional flat coordinates. Set when x,y are given.
- ‘spherical’ = spherical coordinates. Set when ra,dec are given.
- ‘3d’ = 3-dimensional coordinates. Set when x,y,z or ra,dec,r are given.
field – If any of the get?Field methods have been called to construct a field from this catalog (either explicitly or implicitly via a corr.process() command), then this attribute will hold the most recent field to have been constructed. Note: it holds this field as a weakref, so if caching is turned off with
resize_cache(0)
, and the field has been garbage collected, then this attribute will be None.
Parameters: - file_name (str) – The name of the catalog file to be read in. (default: None, in which case the columns need to be entered directly with x, y, etc.)
- config (dict) – A configuration dict which defines attributes about how to read the file. Any optional kwargs may be given here in the config dict if desired. Invalid keys in the config dict are ignored. (default: None)
- num (int) – Which number catalog are we reading. e.g. for NG correlations the catalog for the N has num=0, the one for G has num=1. This is only necessary if you are using a config dict where things like x_col have multiple values. (default: 0)
- logger – If desired, a Logger object for logging. (default: None, in which case one will be built according to the config dict’s verbose level.)
- is_rand (bool) – If this is a random file, then setting is_rand to True will let them skip k_col, g1_col, and g2_col if they were set for the main catalog. (default: False)
- x (array) – The x values. (default: None; When providing values directly, either x,y are required or ra,dec are required.)
- y (array) – The y values. (default: None; When providing values directly, either x,y are required or ra,dec are required.)
- z (array) – The z values, if doing 3d positions. (default: None)
- ra (array) – The RA values. (default: None; When providing values directly, either x,y are required or ra,dec are required.)
- dec (array) – The Dec values. (default: None; When providing values directly, either x,y are required or ra,dec are required.)
- r (array) – The r values (the distances of each source from Earth). Note that r is invalid in conjunction with x,y. (default: None)
- w (array) – The weights to apply when computing the correlations. (default: None)
- wpos (array) – The weights to use for position centroiding. (default: None, which means to use the value weights, w, to weight the positions as well)
- flag (array) – An optional array of flags, indicating objects to skip. Rows with flag != 0 (or technically flag & ~ok_flag != 0) will be given a weight of 0. (default: None)
- g1 (array) – The g1 values to use for shear correlations. (g1,g2 may represent any spinor field.) (default: None)
- g2 (array) – The g2 values to use for shear correlations. (g1,g2 may represent any spinor field.) (default: None)
- k (array) – The kappa values to use for scalar correlations. (This may represent any scalar field.) (default: None)
Keyword Arguments: - file_type (str) – What kind of file is the input file. Valid options are ‘ASCII’ or ‘FITS’ (default: if the file_name extension starts with .fit, then use ‘FITS’, else ‘ASCII’)
- delimiter (str) – For ASCII files, what delimiter to use between values. (default: None, which means any whitespace)
- comment_marker (str) – For ASCII files, what token indicates a comment line. (default: ‘#’)
- first_row (int) – Which row to take as the first row to be used. (default: 1)
- last_row (int) – Which row to take as the last row to be used. (default: -1, which means the last row in the file)
- x_col (str or int) – The column to use for the x values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column. When reading from a file, either x_col and y_col are required or ra_col and dec_col are required.)
- y_col (str or int) – The column to use for the y values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column. When reading from a file, either x_col and y_col are required or ra_col and dec_col are required.)
- z_col (str or int) – The column to use for the z values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column.)
- ra_col (str or int) – The column to use for the ra values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column. When reading from a file, either x_col and y_col are required or ra_col and dec_col are required.)
- dec_col (str or int) – The column to use for the dec values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column. When reading from a file, either x_col and y_col are required or ra_col and dec_col are required.)
- r_col (str or int) – The column to use for the r values. This should be an integer for ASCII files or a string for FITS files. Note that r_col is invalid in conjunction with x_col/y_col. (default: 0 or ‘0’, which means not to read in this column.)
- x_units (str) – The units to use for the x values, given as a string. Valid options are arcsec, arcmin, degrees, hours, radians. (default: radians, although with (x,y) positions, you can often just ignore the units, and the output separations will be in whatever units x and y are in.)
- y_units (str) – The units to use for the y values, given as a string. Valid options are arcsec, arcmin, degrees, hours, radians. (default: radians, although with (x,y) positions, you can often just ignore the units, and the output separations will be in whatever units x and y are in.)
- ra_units (str) – The units to use for the ra values, given as a string. Valid options are arcsec, arcmin, degrees, hours, radians. (required when using ra_col or providing ra directly)
- dec_units (str) – The units to use for the dec values, given as a string. Valid options are arcsec, arcmin, degrees, hours, radians. (required when using dec_col or providing dec directly)
- g1_col (str or int) – The column to use for the g1 values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column.)
- g2_col (str or int) – The column to use for the g2 values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column.)
- k_col (str or int) – The column to use for the kappa values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column.)
- w_col (str or int) – The column to use for the weight values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column.)
- wpos_col (str or int) – The column to use for the position weight values. This should be an integer for ASCII files or a string for FITS files. (default: 0 or ‘0’, which means not to read in this column.)
- flag_col (str or int) – The column to use for the flag values. This should be an integer for ASCII files or a string for FITS files. Any row with flag != 0 (or technically flag & ~ok_flag != 0) will be given a weight of 0. (default: 0 or ‘0’, which means not to read in this column.)
- ignore_flag (int) – Which flags should be ignored. (default: all non-zero flags are ignored. Equivalent to ignore_flag = ~0.)
- ok_flag (int) – Which flags should be considered ok. (default: 0. i.e. all non-zero flags are ignored.)
- flip_g1 (bool) – Whtether to flip the sign of the input g1 values. (default: False)
- flip_g2 (bool) – Whtether to flip the sign of the input g2 values. (default: False)
- hdu (int) – For FITS files, which hdu to read. (default: 1)
- x_hdu (int) – Which hdu to use for the x values. (default: hdu)
- y_hdu (int) – Which hdu to use for the y values. (default: hdu)
- z_hdu (int) – Which hdu to use for the z values. (default: hdu)
- ra_hdu (int) – Which hdu to use for the ra values. (default: hdu)
- dec_hdu (int) – Which hdu to use for the dec values. (default: hdu)
- r_hdu (int) – Which hdu to use for the r values. (default: hdu)
- g1_hdu (int) – Which hdu to use for the g1 values. (default: hdu)
- g2_hdu (int) – Which hdu to use for the g2 values. (default: hdu)
- k_hdu (int) – Which hdu to use for the k values. (default: hdu)
- w_hdu (int) – Which hdu to use for the w values. (default: hdu)
- wpos_hdu (int) – Which hdu to use for the wpos values. (default: hdu)
- flag_hdu (int) – Which hdu to use for the flag values. (default: hdu)
- verbose (int) –
If no logger is provided, this will optionally specify a logging level to use.
- 0 means no logging output
- 1 means to output warnings only (default)
- 2 means to output various progress information
- 3 means to output extensive debugging information
- log_file (str) – If no logger is provided, this will specify a file to write the logging output. (default: None; i.e. output to standard output)
- split_method (str) –
How to split the cells in the tree when building the tree structure. Options are:
- mean: Use the arithmetic mean of the coordinate being split. (default)
- median: Use the median of the coordinate being split.
- middle: Use the middle of the range; i.e. the average of the minimum and maximum value.
- random: Use a random point somewhere in the middle two quartiles of the range.
- cat_precision (int) – The precision to use when writing a Catalog to an ASCII file. This should be an integer, which specifies how many digits to write. (default: 16)
-
checkForNaN
(col, col_str)[source]¶ Check if the column has any NaNs. If so, set those rows to have w[k]=0.
Parameters: - col (array) – The input column to check.
- col_str (str) – The name of the column. Used only as information in logging output.
-
clear_cache
()[source]¶ Clear all field caches.
The various kinds of fields built from this catalog are cached. This may or may not be an optimization for your use case. Normally only a single field is built for a given catalog, and it is usually efficient to cache it, so it can be reused multiple times. E.g. for the usual Landy-Szalay NN calculation:
>>> dd.process(data_cat) >>> rr.process(rand_cat) >>> dr.process(data_cat, rand_cat)
the third line will be able to reuse the same fields built for the data and randoms in the first two lines.
However, this also means that the memory used for the field will persist as long as the catalog object does. If you need to recover this memory and don’t want to delete the catalog yet, this method lets you clear the cache.
There are separate caches for each kind of field. If you want to clear just one or some of them, you can call clear separately for the different caches:
>>> cat.nfields.clear() >>> cat.kfields.clear() >>> cat.gfields.clear() >>> cat.nsimplefields.clear() >>> cat.ksimplefields.clear() >>> cat.gsimplefields.clear()
-
getGField
(min_size=0, max_size=None, split_method=None, brute=False, min_top=3, max_top=10, coords=None, logger=None)[source]¶ Return a
GField
based on the g1,g2 values in this catalog.The
GField
object is cached, so this is efficient to call multiple times. cf.resize_cache
andclear_cache
.Parameters: - min_size (float) – The minimum radius cell required (usually min_sep). (default: 0)
- max_size (float) – The maximum radius cell required (usually max_sep). (default: None)
- split_method (str) – Which split method to use (‘mean’, ‘median’, ‘middle’, or ‘random’) (default: ‘mean’; this value can also be given in the Catalog constructor in the config dict.)
- brute (bool) – Whether to force traversal to the leaves. (default: False)
- min_top (int) – The minimum number of top layers to use when setting up the field. (default: 3)
- max_top (int) – The maximum number of top layers to use when setting up the field. (default: 10)
- coords (str) – The kind of coordinate system to use. (default self.coords)
- logger – A Logger object if desired (default: self.logger)
Returns: A
GField
object
-
getGSimpleField
(logger=None)[source]¶ Return a
GSimpleField
based on the g1,g2 values in this catalog.The
GSimpleField
object is cached, so this is efficient to call multiple times. cf.resize_cache
andclear_cache
Parameters: logger – A Logger object if desired (default: self.logger) Returns: A GSimpleField
object
-
getKField
(min_size=0, max_size=None, split_method=None, brute=False, min_top=3, max_top=10, coords=None, logger=None)[source]¶ Return a
KField
based on the k values in this catalog.The
KField
object is cached, so this is efficient to call multiple times. cf.resize_cache
andclear_cache
Parameters: - min_size (float) – The minimum radius cell required (usually min_sep). (default: 0)
- max_size (float) – The maximum radius cell required (usually max_sep). (default: None)
- split_method (str) – Which split method to use (‘mean’, ‘median’, ‘middle’, or ‘random’) (default: ‘mean’; this value can also be given in the Catalog constructor in the config dict.)
- brute (bool) – Whether to force traversal to the leaves. (default: False)
- min_top (int) – The minimum number of top layers to use when setting up the field. (default: 3)
- max_top (int) – The maximum number of top layers to use when setting up the field. (default: 10)
- coords (str) – The kind of coordinate system to use. (default self.coords)
- logger – A Logger object if desired (default: self.logger)
Returns: A
KField
object
-
getKSimpleField
(logger=None)[source]¶ Return a
KSimpleField
based on the k values in this catalog.The
KSimpleField
object is cached, so this is efficient to call multiple times. cf.resize_cache
andclear_cache
Parameters: logger – A Logger object if desired (default: self.logger) Returns: A KSimpleField
object
-
getNField
(min_size=0, max_size=None, split_method=None, brute=False, min_top=3, max_top=10, coords=None, logger=None)[source]¶ Return an
NField
based on the positions in this catalog.The
NField
object is cached, so this is efficient to call multiple times. cf.resize_cache
andclear_cache
Parameters: - min_size (float) – The minimum radius cell required (usually min_sep). (default: 0)
- max_size (float) – The maximum radius cell required (usually max_sep). (default: None)
- split_method (str) – Which split method to use (‘mean’, ‘median’, ‘middle’, or ‘random’) (default: ‘mean’; this value can also be given in the Catalog constructor in the config dict.)
- brute (bool) – Whether to force traversal to the leaves. (default: False)
- min_top (int) – The minimum number of top layers to use when setting up the field. (default: 3)
- max_top (int) – The maximum number of top layers to use when setting up the field. (default: 10)
- coords (str) – The kind of coordinate system to use. (default: self.coords)
- logger – A Logger object if desired (default: self.logger)
Returns: An
NField
object
-
getNSimpleField
(logger=None)[source]¶ Return an
NSimpleField
based on the positions in this catalog.The
NSimpleField
object is cached, so this is efficient to call multiple times. cf.resize_cache
andclear_cache
Parameters: logger – A Logger object if desired (default: self.logger) Returns: An NSimpleField
object
-
makeArray
(col, col_str, dtype=<class 'float'>)[source]¶ Turn the input column into a numpy array if it wasn’t already. Also make sure the input in 1-d.
Parameters: - col (array-like) – The input column to be converted into a numpy array.
- col_str (str) – The name of the column. Used only as information in logging output.
- dtype (type) – The dtype for the returned array. (default: float)
Returns: The column converted to a 1-d numpy array.
-
read_ascii
(file_name, num=0, is_rand=False)[source]¶ Read the catalog from an ASCII file
Parameters: - file_name (str) – The name of the file to read in.
- num (int) – Which number catalog are we reading. (default: 0)
- is_rand (bool) – Is this a random catalog? (default: False)
-
read_fits
(file_name, num=0, is_rand=False)[source]¶ Read the catalog from a FITS file
Parameters: - file_name (str) – The name of the file to read in.
- num (int) – Which number catalog are we reading. (default: 0)
- is_rand (bool) – Is this a random catalog? (default: False)
-
resize_cache
(maxsize)[source]¶ Resize all field caches.
The various kinds of fields built from this catalog are cached. This may or may not be an optimization for your use case. Normally only a single field is built for a given catalog, and it is usually efficient to cache it, so it can be reused multiple times. E.g. for the usual Landy-Szalay NN calculation:
>>> dd.process(data_cat) >>> rr.process(rand_cat) >>> dr.process(data_cat, rand_cat)
the third line will be able to reuse the same fields built for the data and randoms in the first two lines.
However, if you are making many different fields from the same catalog – for instance because you keep changing the min_sep and max_sep for different calls – then saving them all will tend to blow up the memory.
Therefore, the default number of fields (of each type) to cache is 1. This lets the first use case be efficient, but not use too much memory for the latter case.
If you prefer a different behavior, this method lets you change the number of fields to cache. The cache is an LRU (Least Recently Used) cache, which means only the n most recently used fields are saved. I.e. when it is full, the least recently used field is removed from the cache.
If you call this with maxsize=0, then caching will be turned off. A new field will be built each time you call a process function with this catalog.
If you call this with maxsize>1, then mutiple fields will be saved according to whatever number you set. This will use more memory, but may be an optimization for you depending on what your are doing.
Finally, if you want to set different sizes for the different kinds of fields, then you can call resize separately for the different caches:
>>> cat.nfields.resize(maxsize) >>> cat.kfields.resize(maxsize) >>> cat.gfields.resize(maxsize) >>> cat.nsimplefields.resize(maxsize) >>> cat.ksimplefields.resize(maxsize) >>> cat.gsimplefields.resize(maxsize)
Parameters: maxsize (float) – The new maximum number of fields of each type to cache.
-
write
(file_name, file_type=None, cat_precision=None)[source]¶ Write the catalog to a file.
Note that the position columns are output using the same units as were used when building the Catalog. If you want to use a different unit, you can set the catalog’s units directly before writing. e.g.:
>>> cat = treecorr.Catalog('cat.dat', ra=ra, dec=dec, ra_units='hours', dec_units='degrees') >>> cat.ra_units = coord.degrees >>> cat.write('new_cat.dat')
The output file will include some of the following columns (those for which the corresponding attribute is not None):
Column Description ra self.ra if not None dec self.dec if not None r self.r if not None x self.x if not None y self.y if not None z self.z if not None w self.w if not None and self.nontrivial_w wpos self.wpos if not None g1 self.g1 if not None g2 self.g2 if not None k self.k if not None meanR The mean value <R> of pairs that fell into each bin. meanlogR The mean value <logR> of pairs that fell into each bin. Parameters: - file_name (str) – The name of the file to write to.
- file_type (str) – The type of file to write (‘ASCII’ or ‘FITS’). (default: determine the type automatically from the extension of file_name.)
- cat_precision (int) – For ASCII output catalogs, the desired precision. (default: 16; this value can also be given in the Catalog constructor in the config dict.)


ARCHITECTURE & DESIGN
Architecture and design in Miami consists of a strong portfolio of Art Deco, Tropical Modernism, and contemporary motifs. Each neighborhood represents a different story based on the communities and individuals who first settled there.
Learn MoreDEMOGRAPHICS
Since the 1900’s, we see a drastic shift in the way the Miami has evolved demographically. Immigration from Latin America and the Caribbean is prevalent throughout the city’s history, especially after the 1965 hart-cellar act.
Learn MoreLOCAL LEGENDS
As a hub for creative people, Miami is home to many homegrown legends. Ranging from astrologers to singers, to larger than life personalities, there’s obviously no better creative influencer than the 305.
Learn More
CULTURAL INSTITUTIONS
Miami has been at the forefront of culture for some time. From landmarks to widely recognized museums, Miami’s institutional journey has been as remarkable as they are elaborate.
Learn More


SUST ADMISSION RESULT PROCESSING SYSTEM
Unit : Group
Unit Name
Group
Position Type
Position Type
Quota
Quota Name


Prem Rawat
About Prem Rawat
Prem Rawat also known as Maharaji began speaking about peace at very young age. As a child, he astounded and delighted audiences with his wisdom and clarity.
At the age of thirteen, his message of peace had reached beyond his native India, and he was invited for the first time to travel to the West. This was the beginning of over four decades of nearly non-stop travel throughout the world, touching the lives of millions of people as he spoke to audiences, both large and small. His message is simple yet profound and available in more than 90 countries and 70 languages.
Prem Rawat is a respected international speaker, attracting audiences from all walks of life. The honorary title Ambassador of Peace has been granted to him by a number of governmental and academic institutions because of his ability to inspire audiences to see personal peace as a possibility for everyone.
As a speaker, Prem Rawat is both accessible and humorous, using stories, analogies, and even poetry to reach his diverse audience. At the same time he has an important message, that personal peace is a fundamental right for all.
He speaks from the heart, without script or rehearsal, bringing simplicity to important issues that people often find complex. His life's goal is to offer his message of peace to all seven billion of the world's population.
In pursuit of this goal, he maintains a challenging travel schedule, often flying over 100,000 nautical miles in a year. In 2012 alone he spoke to over 730,000 people at 102 live events worldwide. During that time, there were over a million downloads of his videos. He receives no recompense for his speaking engagements.
In addition to speaking in front of intimate audiences and vast crowds-sometimes exceeding 300,000 in India- he has been invited to speak at a number of important institutional venues and forums. These include the European parliament, the United Nations (UN), the Italian Senate, the Parliament of Australia, Argentina and New Zealand, the IIT Delhi, the Young Presidents' Organization, and the Guildhall in London, as well as numerous universities across the world .
Honoured as the 'Ambassador of Peace'
2006: Title first conferred by Pierre Weil, rector of the International University of Peace, UNIPAZ Florianopolis, Brazil
2007: Designated Ambassador of Peace for the Basilicata Region of Italy by the governor, and the City of Sondrio, Italy
2011: Appointed by Gianni Pittella MEP, 1st Vice President of the European Parliament, as "Ambassador for Peace" on behalf of the Brussels Declaration Pledge to Peace, signed at the European Parliament in 2011
2012: Acknowledgement as Brussels Declaration Ambassador of Peace, Italian Senate
2013: Acknowledgement as Ambassador of Peace, National Agrarian University, La Molina, Peru
International Achievement Awards
2006: Distinguished International Humanitarian Achievement Award by Mary Singletary, President of the National Council of Women, New York, New York
2012: Lifetime Achievement Award granted by Asia Pacific Brands Foundation, Kuala Lumpur, Malaysia
2013: Bharat Gaurav Award and Certificate awarded by India International Friendship Society, New Delhi, India
2015: Order for International Merit of Blood from International Federation of Blood Donor Organizations
He is a man of such standard and excellence we cannot but help love that man for all that he has given to the world. Most importantly, he inspires, he impacts, and influences lives all over the world. The wonderful thing about this man is that this is the man for the 21st century. He has the message for the 21st century. We just thank him, 7 billion reasons to thank him for championing and supporting peace all over the world. Dr. KK. Johan
Chairman of the Brand Laureate organization


Trader Weber:
Ah, I didn't recognize you! All I know is that the
Attribute Master Yang
here in Township is in trouble. You'll need to ask him for more details.
"I understand."


--- layout: event title: Fender Bender datetime: 2016-12-13 (Tue) 18:00 location: Sprout, 339R Summer St, Somerville (home to SBK) description: learn how to install fenders ---
Welcome to winter: Swampy streets, wet wheels, and dirty derailuers. Fear not! Come install fenders with the Somerveille Bike Kitchen on Dec 13. Use some of our many donated fenders or bring your own to install or modify - we have material for flaps and reflecting stripes as well to make your fenders really shine. See you there!


Sweet Free Stuff
///////////////////////////////////////////
2 Free Overland Bound Stickers
Posted: 01 Mar 2015 10:39 AM PST
http://feedproxy.google.com/&edburner&utm_medium=email
Add to cart, view cart, and check out. 2 Free Overland Bound Stickers
The post 2 Free Overland Bound Stickers appeared first on Sweet Free Stuff.
///////////////////////////////////////////
Free Subscription to Cosmopolitan
Posted: 01 Mar 2015 02:30 AM PST
http://feedproxy.google.com/&edburner&utm_medium=email
Free Subscription to Cosmopolitan
The post Free Subscription to Cosmopolitan appeared first on Sweet Free
Stuff.
///////////////////////////////////////////
Free John Frieda Luxurious Volume 7 Day Volume Sample
Posted: 01 Mar 2015 01:22 AM PST
http://feedproxy.google.com/&edburner&utm_medium=email
Free John Frieda Luxurious Volume 7 Day Volume Sample
The post Free John Frieda Luxurious Volume 7 Day Volume Sample appeared
first on Sweet Free Stuff.
CommentsThank you John Frieda. I’m going to have luxurious volume. by
DebraOk Thank You! by Brian SSite does no work. Click “fine” and submit and
= no response by cn
///////////////////////////////////////////
Free Subscription to OK! Magazine
Posted: 28 Feb 2015 09:00 PM PST
http://feedproxy.google.com/&edburner&utm_medium=email
Free Subscription to OK! Magazine
The post Free Subscription to OK! Magazine appeared first on Sweet Free
Stuff.
CommentsExpired by C
///////////////////////////////////////////
Free Subscription to Muscle & Fitness Magazine
Posted: 28 Feb 2015 09:00 PM PST
http://feedproxy.google.com/&edburner&utm_medium=email
The post Free Subscription to Muscle Fitness Magazine appeared first on
Sweet Free Stuff.


Compatibility types
Java API
Hadoop interfaces and classes are annotated to describe the intended audience and stability in order to maintain compatibility with previous releases. See Hadoop Interface Classification for details.
- InterfaceAudience: captures the intended audience, possible values are Public (for end users and external projects), LimitedPrivate (for other Hadoop components, and closely related projects like YARN, MapReduce, HBase etc.), and Private (for intra component use).
- InterfaceStability: describes what types of interface changes are permitted. Possible values are Stable, Evolving, Unstable, and Deprecated.
Use Cases
- Public-Stable API compatibility is required to ensure end-user programs and downstream projects continue to work without modification.
- LimitedPrivate-Stable API compatibility is required to allow upgrade of individual components across minor releases.
- Private-Stable API compatibility is required for rolling upgrades.
Policy
- Public-Stable APIs must be deprecated for at least one major release prior to their removal in a major release.
- LimitedPrivate-Stable APIs can change across major releases, but not within a major release.
- Private-Stable APIs can change across major releases, but not within a major release.
- Classes not annotated are implicitly “Private”. Class members not annotated inherit the annotations of the enclosing class.
- Note: APIs generated from the proto files need to be compatible for rolling-upgrades. See the section on wire-compatibility for more details. The compatibility policies for APIs and wire-communication need to go hand-in-hand to address this.
Semantic compatibility
Apache Hadoop strives to ensure that the behavior of APIs remains consistent over versions, though changes for correctness may result in changes in behavior. Tests and javadocs specify the API’s behavior. The community is in the process of specifying some APIs more rigorously, and enhancing test suites to verify compliance with the specification, effectively creating a formal specification for the subset of behaviors that can be easily tested.
Policy
The behavior of API may be changed to fix incorrect behavior, such a change to be accompanied by updating existing buggy tests or adding tests in cases there were none prior to the change.
Wire compatibility
Wire compatibility concerns data being transmitted over the wire between Hadoop processes. Hadoop uses Protocol Buffers for most RPC communication. Preserving compatibility requires prohibiting modification as described below. Non-RPC communication should be considered as well, for example using HTTP to transfer an HDFS image as part of snapshotting or transferring MapTask output. The potential communications can be categorized as follows:
- Client-Server: communication between Hadoop clients and servers (e.g., the HDFS client to NameNode protocol, or the YARN client to ResourceManager protocol).
- Client-Server (Admin): It is worth distinguishing a subset of the Client-Server protocols used solely by administrative commands (e.g., the HAAdmin protocol) as these protocols only impact administrators who can tolerate changes that end users (which use general Client-Server protocols) can not.
- Server-Server: communication between servers (e.g., the protocol between the DataNode and NameNode, or NodeManager and ResourceManager)
Use Cases
- Client-Server compatibility is required to allow users to continue using the old clients even after upgrading the server (cluster) to a later version (or vice versa). For example, a Hadoop 2.1.0 client talking to a Hadoop 2.3.0 cluster.
- Client-Server compatibility is also required to allow users to upgrade the client before upgrading the server (cluster). For example, a Hadoop 2.4.0 client talking to a Hadoop 2.3.0 cluster. This allows deployment of client-side bug fixes ahead of full cluster upgrades. Note that new cluster features invoked by new client APIs or shell commands will not be usable. YARN applications that attempt to use new APIs (including new fields in data structures) that have not yet been deployed to the cluster can expect link exceptions.
- Client-Server compatibility is also required to allow upgrading individual components without upgrading others. For example, upgrade HDFS from version 2.1.0 to 2.2.0 without upgrading MapReduce.
- Server-Server compatibility is required to allow mixed versions within an active cluster so the cluster may be upgraded without downtime in a rolling fashion.
Policy
- Both Client-Server and Server-Server compatibility is preserved within a major release. (Different policies for different categories are yet to be considered.)
- Compatibility can be broken only at a major release, though breaking compatibility even at major releases has grave consequences and should be discussed in the Hadoop community.
- Hadoop protocols are defined in .proto (ProtocolBuffers) files. Client-Server protocols and Server-Server protocol .proto files are marked as stable. When a .proto file is marked as stable it means that changes should be made in a compatible fashion as described below:
- The following changes are compatible and are allowed at any time:
- Add an optional field, with the expectation that the code deals with the field missing due to communication with an older version of the code.
- Add a new rpc/method to the service
- Add a new optional request to a Message
- Rename a field
- Rename a .proto file
- Change .proto annotations that effect code generation (e.g. name of java package)
- The following changes are incompatible but can be considered only at a major release
- Change the rpc/method name
- Change the rpc/method parameter type or return type
- Remove an rpc/method
- Change the service name
- Change the name of a Message
- Modify a field type in an incompatible way (as defined recursively)
- Change an optional field to required
- Add or delete a required field
- Delete an optional field as long as the optional field has reasonable defaults to allow deletions
- The following changes are incompatible and hence never allowed
- Change a field id
- Reuse an old field that was previously deleted.
- Field numbers are cheap and changing and reusing is not a good idea.
Java Binary compatibility for end-user applications i.e. Apache Hadoop ABI
As Apache Hadoop revisions are upgraded end-users reasonably expect that their applications should continue to work without any modifications. This is fulfilled as a result of supporting API compatibility, Semantic compatibility and Wire compatibility.
However, Apache Hadoop is a very complex, distributed system and services a very wide variety of use-cases. In particular, Apache Hadoop MapReduce is a very, very wide API; in the sense that end-users may make wide-ranging assumptions such as layout of the local disk when their map/reduce tasks are executing, environment variables for their tasks etc. In such cases, it becomes very hard to fully specify, and support, absolute compatibility.
Use cases
- Existing MapReduce applications, including jars of existing packaged end-user applications and projects such as Apache Pig, Apache Hive, Cascading etc. should work unmodified when pointed to an upgraded Apache Hadoop cluster within a major release.
- Existing YARN applications, including jars of existing packaged end-user applications and projects such as Apache Tez etc. should work unmodified when pointed to an upgraded Apache Hadoop cluster within a major release.
- Existing applications which transfer data in/out of HDFS, including jars of existing packaged end-user applications and frameworks such as Apache Flume, should work unmodified when pointed to an upgraded Apache Hadoop cluster within a major release.
Policy
- Existing MapReduce, YARN & HDFS applications and frameworks should work unmodified within a major release i.e. Apache Hadoop ABI is supported.
- A very minor fraction of applications maybe affected by changes to disk layouts etc., the developer community will strive to minimize these changes and will not make them within a minor version. In more egregious cases, we will consider strongly reverting these breaking changes and invalidating offending releases if necessary.
- In particular for MapReduce applications, the developer community will try our best to support providing binary compatibility across major releases e.g. applications using org.apache.hadoop.mapred.
- APIs are supported compatibly across hadoop-1.x and hadoop-2.x. See Compatibility for MapReduce applications between hadoop-1.x and hadoop-2.x for more details.
REST APIs
REST API compatibility corresponds to both the requests (URLs) and responses to each request (content, which may contain other URLs). Hadoop REST APIs are specifically meant for stable use by clients across releases, even major ones. The following are the exposed REST APIs:
Policy
The APIs annotated stable in the text above preserve compatibility across at least one major release, and maybe deprecated by a newer version of the REST API in a major release.
Metrics/JMX
While the Metrics API compatibility is governed by Java API compatibility, the actual metrics exposed by Hadoop need to be compatible for users to be able to automate using them (scripts etc.). Adding additional metrics is compatible. Modifying (e.g. changing the unit or measurement) or removing existing metrics breaks compatibility. Similarly, changes to JMX MBean object names also break compatibility.
Policy
Metrics should preserve compatibility within the major release.
File formats & Metadata
User and system level data (including metadata) is stored in files of different formats. Changes to the metadata or the file formats used to store data/metadata can lead to incompatibilities between versions.
User-level file formats
Changes to formats that end-users use to store their data can prevent them from accessing the data in later releases, and hence it is highly important to keep those file-formats compatible. One can always add a “new” format improving upon an existing format. Examples of these formats include har, war, SequenceFileFormat etc.
Policy
- Non-forward-compatible user-file format changes are restricted to major releases. When user-file formats change, new releases are expected to read existing formats, but may write data in formats incompatible with prior releases. Also, the community shall prefer to create a new format that programs must opt in to instead of making incompatible changes to existing formats.
System-internal file formats
Hadoop internal data is also stored in files and again changing these formats can lead to incompatibilities. While such changes are not as devastating as the user-level file formats, a policy on when the compatibility can be broken is important.
MapReduce
MapReduce uses formats like I-File to store MapReduce-specific data.
Policy
MapReduce-internal formats like IFile maintain compatibility within a major release. Changes to these formats can cause in-flight jobs to fail and hence we should ensure newer clients can fetch shuffle-data from old servers in a compatible manner.
HDFS Metadata
HDFS persists metadata (the image and edit logs) in a particular format. Incompatible changes to either the format or the metadata prevent subsequent releases from reading older metadata. Such incompatible changes might require an HDFS “upgrade” to convert the metadata to make it accessible. Some changes can require more than one such “upgrades”.
Depending on the degree of incompatibility in the changes, the following potential scenarios can arise:
- Automatic: The image upgrades automatically, no need for an explicit “upgrade”.
- Direct: The image is upgradable, but might require one explicit release “upgrade”.
- Indirect: The image is upgradable, but might require upgrading to intermediate release(s) first.
- Not upgradeable: The image is not upgradeable.
Policy
- A release upgrade must allow a cluster to roll-back to the older version and its older disk format. The rollback needs to restore the original data, but not required to restore the updated data.
- HDFS metadata changes must be upgradeable via any of the upgrade paths - automatic, direct or indirect.
- More detailed policies based on the kind of upgrade are yet to be considered.
Command Line Interface (CLI)
The Hadoop command line programs may be used either directly via the system shell or via shell scripts. Changing the path of a command, removing or renaming command line options, the order of arguments, or the command return code and output break compatibility and may adversely affect users.
Policy
CLI commands are to be deprecated (warning when used) for one major release before they are removed or incompatibly modified in a subsequent major release.
Web UI
Web UI, particularly the content and layout of web pages, changes could potentially interfere with attempts to screen scrape the web pages for information.
Policy
Web pages are not meant to be scraped and hence incompatible changes to them are allowed at any time. Users are expected to use REST APIs to get any information.
Hadoop Configuration Files
Users use (1) Hadoop-defined properties to configure and provide hints to Hadoop and (2) custom properties to pass information to jobs. Hence, compatibility of config properties is two-fold:
- Modifying key-names, units of values, and default values of Hadoop-defined properties.
- Custom configuration property keys should not conflict with the namespace of Hadoop-defined properties. Typically, users should avoid using prefixes used by Hadoop: hadoop, io, ipc, fs, net, file, ftp, s3, kfs, ha, file, dfs, mapred, mapreduce, yarn.
Policy
- Hadoop-defined properties are to be deprecated at least for one major release before being removed. Modifying units for existing properties is not allowed.
- The default values of Hadoop-defined properties can be changed across minor/major releases, but will remain the same across point releases within a minor release.
- Currently, there is NO explicit policy regarding when new prefixes can be added/removed, and the list of prefixes to be avoided for custom configuration properties. However, as noted above, users should avoid using prefixes used by Hadoop: hadoop, io, ipc, fs, net, file, ftp, s3, kfs, ha, file, dfs, mapred, mapreduce, yarn.
Directory Structure
Source code, artifacts (source and tests), user logs, configuration files, output and job history are all stored on disk either local file system or HDFS. Changing the directory structure of these user-accessible files break compatibility, even in cases where the original path is preserved via symbolic links (if, for example, the path is accessed by a servlet that is configured to not follow symbolic links).
Policy
- The layout of source code and build artifacts can change anytime, particularly so across major versions. Within a major version, the developers will attempt (no guarantees) to preserve the directory structure; however, individual files can be added/moved/deleted. The best way to ensure patches stay in sync with the code is to get them committed to the Apache source tree.
- The directory structure of configuration files, user logs, and job history will be preserved across minor and point releases within a major release.
Java Classpath
User applications built against Hadoop might add all Hadoop jars (including Hadoop’s library dependencies) to the application’s classpath. Adding new dependencies or updating the version of existing dependencies may interfere with those in applications’ classpaths.
Policy
Currently, there is NO policy on when Hadoop’s dependencies can change.
Environment variables
Users and related projects often utilize the exported environment variables (eg HADOOP_CONF_DIR), therefore removing or renaming environment variables is an incompatible change.
Policy
Currently, there is NO policy on when the environment variables can change. Developers try to limit changes to major releases.
Build artifacts
Hadoop uses maven for project management and changing the artifacts can affect existing user workflows.
Policy
- Test artifacts: The test jars generated are strictly for internal use and are not expected to be used outside of Hadoop, similar to APIs annotated @Private, @Unstable.
- Built artifacts: The hadoop-client artifact (maven groupId:artifactId) stays compatible within a major release, while the other artifacts can change in incompatible ways.
Hardware/Software Requirements
To keep up with the latest advances in hardware, operating systems, JVMs, and other software, new Hadoop releases or some of their features might require higher versions of the same. For a specific environment, upgrading Hadoop might require upgrading other dependent software components.
Policies
- Hardware
- Architecture: The community has no plans to restrict Hadoop to specific architectures, but can have family-specific optimizations.
- Minimum resources: While there are no guarantees on the minimum resources required by Hadoop daemons, the community attempts to not increase requirements within a minor release.
- Operating Systems: The community will attempt to maintain the same OS requirements (OS kernel versions) within a minor release. Currently GNU/Linux and Microsoft Windows are the OSes officially supported by the community while Apache Hadoop is known to work reasonably well on other OSes such as Apple MacOSX, Solaris etc.
- The JVM requirements will not change across point releases within the same minor release except if the JVM version under question becomes unsupported. Minor/major releases might require later versions of JVM for some/all of the supported operating systems.
- Other software: The community tries to maintain the minimum versions of additional software required by Hadoop. For example, ssh, kerberos etc.


Improving an SDK With Core Bluetooth (Companion Repo)
This is a repo that will accompany a series of posts on introduction to Core Bluetooth.
The “working code” for the repo is in the SDK-Src
directory. This will be a simple framework project that implements a very simple “Magic 8-Ball” application that runs on two different Apple devices.
One device acts as a Bluetooth Central device, and the other as a Bluetooth Peripheral device.
The user “asks a question” from the Central device, and “gets an answer” from a Peripheral device.
The communication between the devices is Bluetooth Low Energy, managed by Apple’s Core Bluetooth API.
The Apps-src
directory contains 4 applications. These are for each of the Apple platforms: Mac, iOS/iPadOS, Watch, and TV.


Averette, Jardine lift Utah Valley past Ottawa (AZ) 101-70
OREM, Utah (AP) - Brandon Averette had 17 points to lead five Utah Valley players in double figures as the Wolverines routed Ottawa (AZ) 101-70 on Tuesday night.
Casdon Jardine added 15 points for the Wolverines. Jamison Overton and Trey Woodbury chipped in 14 apiece and Brandon Morley added 10 while pulling down 14 rebounds. Jardine also had eight rebounds for the Wolverines, while Overton grabbed eight rebounds.
Brian Carey had 18 points for the Spirit. Elijah Simmons added 15 points. Shazier Lawson had 14 points and nine rebounds.
Utah Valley (2-1) faces UAB on the road on Friday.
For more AP college basketball coverage: https://apnews.com/Collegebasketball and http://twitter.com/AP_Top25
Elements of this story were generated by Automated Insights, http://www.automatedinsights.com/ap, using data from STATS LLC, https://www.stats.com
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


PayPal to buy rewards platform Honey Science for US$4 billion
Payment processor PayPal Holdings Inc said on Wednesday it would buy privately held shopping and rewards platform Honey Science Corp for about US$4 billion (£3.10 billion).
REUTERS: Payment processor PayPal Holdings Inc said on Wednesday it would buy privately held shopping and rewards platform Honey Science Corp for about US$4 billion (£3.10 billion).
Honey has nearly 17 million monthly active users and notifies consumers about the lowest available price as well as a drop in prices.
(Reporting by Abhishek Manikandan in Bengaluru; Editing by Arun Koyyur)


Non Drug Management of Indigestion
Red Signs and Symptoms requiring urgent investigations
When any of the following is present, then there is need for urgent presentation to hospital for further investigations.
It is not recommended to embark on the non medical management strategies until
more sinister lesions have been ruled out. These include:
- New onset indigestion in someone 60 yrs and above
- Evidence of bleeding – vomiting of blood, passage of black stools or overt blood in stools
- Iron deficiency anaemia
- Loss of appetite
- Unexplained weight loss
- Difficulty in swallowing
- Persistent vomiting
- History of stomach or oesophageal cancer in first degree relatives
Non Drug Advice
The following are advisable for those that do not have above symptoms
- Avoid foods rich in sugars, soda, caffeine and alcohol
- Lose weight, if you are overweight
- Eat more bananas, melons, yoghurt, green vegetables and oatmeals
- Avoid foods that trigger symptoms such as cigarettes, caffeine and alcohol
- Try relaxation exercises
- Do not eat food 3 hours to bedtime
- Talk to a health personnel
- Small regular meals is better than large chunks of meals


1.1. NOTICE CONCERNING CHILDREN. PLEASE NOTE: We do not direct any of our content specifically at children under 13 years of age. We understand and are committed to respecting the sensitive nature of children’s privacy online. If we learn or have reason to suspect that a Site user is under age 13, we will promptly delete any personal information in that user’s account.
2.1. INFORMATION COLLECTED & USED (a) OPT-IN. Users can opt-in to the collection information regarding Angular domains you discover via use of the Angular Inspector extension, this information is not personally identifiable. The extension can be opt-ed out of data collection or uninstalled at any time.
3.1.
(a) If the user opts-in to sharing of domain details, this information will be used to identify Angular applications on the internet.
(b) DATA RETENTION. We will retain opt-in non-personally identifiable domain information indefinitely
5.1. UPDATES AND CHANGES. We may update this privacy statement to reflect changes to our information practices. If we make any material changes we will notify you by email (sent to the e-mail address specified in your account) or by means of a notice on this Site prior to the change becoming effective. We encourage you to periodically review this page for the latest information on our privacy practices.


#import <NTCartoMapsService.h>
Inherits NSObject.
A high-level interface for Carto Maps Service.
The service can be used to automatically configure layers using
anonymous map configurations or by using parametrized named maps.
| - (NTLayerVector *) buildMap: |
|
(NTVariant*) |
mapConfig |
|
Builds a list of layers given anonymous map configuration.
The map configuration specification can be found in CartoDB documentation page.
- Parameters
-
| mapConfig | The map configuration JSON deserialized as Variant type.
|
- Returns
- The list of created layers.
- Exceptions
-
| NSException | If IO error occured during the operation. |
| - (NTLayerVector *) buildNamedMap: |
|
(NSString*) |
templateId |
| templateParams: |
|
(NTStringVariantMap*) |
templateParams |
|
|
| |
Builds a list of layers given named map id and named map parameters.
- Parameters
-
| templateId | The named map id.
|
| templateParams | The map containing named map parameter names and their values.
|
- Returns
- The list of created layers.
- Exceptions
-
| NSException | If IO error occured during the operation. |
| - (NSString *) getAPITemplate |
|
|
|
Returns the API endpoint template of the online service.
- Returns
- The API endpoint template of the online service.
| - (NTStringVector *) getAuthTokens |
|
|
|
Returns the list of authentication tokens used when accessing online service.
- Returns
- The list of authentication tokens used when accessing online service.
| - (NSString *) getUsername |
|
|
|
Returns the user account name used when accessing the online service.
- Returns
- The user account name used when accessing the online service.
Returns the asset package used when decoding vector tiles.
By default, no asset package is used and null is returned.
- Returns
- The asset package used when decoding vector tiles.
Returns the hash value of this object.
- Returns
- The hash value of this object.
Constructs a new CartoMapsService instance with default settings.
| - (BOOL) isDefaultVectorLayerMode |
|
|
|
Returns true if the service configures layers as vector tile layers,
when possible. By default this is false. Vector layers
provide much better visual quality at the expense of performance.
- Returns
- True if vector layers should be used. False is raster layers are used.
| - (BOOL) isEqual: |
|
(id) |
object |
|
Checks if this object is equal to the specified object.
- Parameters
-
| object | The reference object. |
- Returns
- True when objects are equal, false otherwise.
Returns true is the service configures
layers as interactive by using UTF grids for click detection.
- Returns
- True if the service configures layers as interactive.
Returns true if 'strict mode' is enabled (the service throws exceptions whenever an error is encountered).
- Returns
- True if 'strict mode' is enabled.
| - (void) setAPITemplate: |
|
(NSString*) |
apiTemplate |
|
Sets the API endpoint template of the online service.
By default cartodb.com endpoint is used. This needs to be redefined only for on-premise services.
- Parameters
-
| apiTemplate | The API endpoint template of the online service. For example, "http://{user}.cartodb.com" |
| - (void) setAuthTokens: |
|
(NTStringVector*) |
authTokens |
|
Sets the list of authentication tokens used when accessing online service.
- Parameters
-
| authTokens | The list of authentication tokens used when accessing online service. |
| - (void) setDefaultVectorLayerMode: |
|
(BOOL) |
vectorLayerMode |
|
Sets the service to vector layer mode or raster layer mode.
By default service creates raster layers, but vector layers may
provide much better visual quality at the expense of performance.
- Parameters
-
| vectorLayerMode | True if vector layers should be used. False is raster layers are used. |
| - (void) setInteractive: |
|
(BOOL) |
interactive |
|
Sets the interactivity flag of the layers.
- Parameters
-
| interactive | True if layers should be configured as interactive. The default is false. |
| - (void) setStrictMode: |
|
(BOOL) |
strictMode |
|
Sets the 'strict mode' flag.
- Parameters
-
| strictMode | True if all errors result in exceptions. The default is false. |
| - (void) setUsername: |
|
(NSString*) |
username |
|
Sets the user account name used when accessing the online service.
- Parameters
-
| username | The user account name used when accessing the online service. |
Sets the asset package used when decoding vector tiles.
Asset package with fonts is needed when texts are used.
- Parameters
-
| assetPackage | The asset package to use for vector tiles. |
The documentation for this class was generated from the following files:
- /Users/Shared/Jenkins/Home/workspace/cartomobile sdk ios develop/build/doxygen/NTCartoMapsService.h
- /Users/Shared/Jenkins/Home/workspace/cartomobile sdk ios develop/build/doxygen/NTCartoMapsService.mm


1. Introduction
This section is not normative.
Some user-interface languages define elements which can have "toggleable state",
which can be modified by user interaction and selected using CSS Selectors.
For example, in HTML, the <input type=checkbox>
has a "checked" state
which toggles between true and false when the user activates the element,
and which is selected by the :checked pseudoclass.

<input type=checkbox>1 banana
<input type=checkbox>1 cup blueberries ...

In this markup, one can cross out ingredients as they’re used in the recipe by simply clicking on them.
This module generalizes this ability and allows it to be applied to any element via CSS.
Elements can be declared to have toggleable state,
with any number of states that can be toggled between.
Multiple elements can share access to the same toggleable state,
similar to HTML’s <input type=radio>
element.
This state can be manipulated by activating the element or other specified elements,
or by other user interactions.
2. Toggle Concepts
A toggle is a struct associated with an element, which represents something that can be toggled on or off by user action, and matched with Selectors. Toggles have the following items:
- name
-
A string.
In CSS, this name is provided as a <toggle-name>, which is either a <custom-ident> or as a <string>; in either case, the item’s value is the name.
<toggle-name> = <custom-ident> | <string>
For example, foo and "foo" are both valid ways to refer to the same toggle name.However, foo and FOO are two different names, since they’re not identical to each other.
- state
-
A non-negative integer: either 0 (the inactive state) or a value 1 or higher (the active states).
- state names
-
A list of state names, each of which are strings.
Like the toggle’s name, in CSS they are <toggle-name>s, with the value of the item giving the state name.
- group
-
A boolean indicating whether the toggle is part of a toggle group (of the same name) or not.
- scope
-
A string enum indicating what sort of scope the toggle uses. It can have two values:
-
"wide", indicating the toggle has wide scope (it’s visible to the element, its descendants, and its following siblings and their descendants).
-
"narrow", indicating the toggle has narrow scope (it’s visible to the element and its descendants only).
-
Toggles are persistent state on an element, and are not directly affected by any CSS properties. An element can have any number of toggles.
A toggle group is a struct associated with an element, which groups together toggles of the same name so that only one can be in an active state at a time. Toggle groups have the following items:
- name
-
A string, starting with two dashes (U+002D HYPHEN-MINUS).
Like a toggle’s name, in CSS they are given by a <toggle-name>, with the value of the item giving the name.
- scope
-
A string enum indicating what sort of scope the toggle group uses. It can have two values:
-
"wide", indicating the toggle has wide scope (it’s visible to the element, its descendants, and its following siblings and their descendants).
-
"narrow", indicating the toggle has narrow scope (it’s visible to the element and its descendants only).
-
Toggle groups are created by the toggle-group property; they are not persistent state on an element. An element can have any number of toggle groups.
A toggle is in a toggle group if its group boolean is true; if the element is in scope for a toggle group with the same name as the toggle, it’s in that group; otherwise, it’s in a document-wide implicit toggle group with the same name.
Toggles and toggle groups have a scope, defining what additional elements (beyond the element the toggle/toggle group is on) can see and interact with the toggle/toggle group.
If the toggle (toggle group) has wide scope, it’s visible to the element it’s defined on, its descendants its following siblings, and their descendants.
If the toggle (toggle group) has narrow scope, it’s visible to the element it’s defined on and its descendants.
Toggles of the same name "shadow" earlier ones; if multiple toggles of a given name would have overlapping scopes, an element is only in scope for the toggle created by the nearest preceding element in tree order. The same applies to toggle groups. However, toggles and toggle groups do not interfere with each other’s scopes; an element can "see past" a toggle to find a toggle group of the same name it’s in scope for, and vice versa.
A toggle specifier is a struct associated with an element, defining the initial state of a toggle if one needs to be created on the element, and how to respond to a toggle activation. It has the following items:
- name
- initial state
-
A non-negative integer specifying the toggle’s initial state upon creation.
- state names
-
A list of state names, each of which are strings, assigned to the toggle initially upon creation.
- group
-
A boolean, specifying the toggle’s initial group boolean upon creation.
- scope
-
A string (either "wide" or "narrow"), specifying the toggle’s initial scope upon creation.
- maximum state
-
A positive integer specifying the highest active state the toggle can reach.
- sticky
-
A boolean specifying how to react when a toggle activation would push the state past the specified maximum state: the state either stays within the active states and returns to 1 (if true) or cycles back to the inactive state (if false).
Toggle specifiers are created by the toggle-create property; they are not persistent state on an element. An element can have any number of toggle specifiers.
Note: This produces behavior similar to a checkbox.
2.1. Toggles and CSS Properties
To allow for toggles to be responded to by Selectors without causing any circularity issues, toggles themselves are invisible state on an element, separate from any CSS properties that might apply. The CSS properties merely define which elements can activate a toggle, and which elements can respond to a toggle activation (and how they do so).
.toggleable{ toggle-create : foo1 ; toggle-set : foo; } .toggleable:toggle ( foo) { toggle-create : none; toggle-set : none; }
In this example, the toggleable element declares that it can establish a foo toggle, and activate it. During a rendering update, the foo toggle is created on the element (initially with a value of 0, its inactive state); when the element is clicked, it’s incremented to its active state (1).
At this point, the :toggle(foo) rule begins to match, and removes the toggle-* properties. This does not remove the foo toggle or affect its value, however; it still exists and is still set to 1, so the :toggle() pseudo-class will continue matching. However, further activations of the element will no longer affect the foo toggle, since toggle-set was changed to none.
The foo toggle is thus "frozen" in the activated state (unless the author has other elements in the toggle’s scope that can also affect it, or tweaks the value manually via JS).
3. Creating a Toggle: the toggle-create property
| Name: | toggle-create |
|---|---|
| Value: | none | <toggle-specifier># |
| Initial: | none |
| Applies to: | all elements |
| Inherited: | no |
| Percentages: | n/a |
| Computed value: | as specified |
| Canonical order: | per grammar |
| Media: | interactive |
| Animatable: | no |
<toggle-specifier> = <toggle-name> [ [ <integer [0,∞]> / ]? <integer [1,∞]> || sticky || group || self ]?
The toggle-create property causes toggles to be created on an element, and controls how the toggles are updated when they are activated.
- none
-
The element has no toggle specifiers.
(This does not remove any toggles that have already been established on the element.)
- <toggle-specifier>#
-
The element has one or more toggle specifiers,
one per <toggle-specifier>,
which determine how toggles will be initially created,
and how they react to being activated.
Each <toggle-specifier> is composed of several parts, most of which are optional, corresponding to the items of a toggle specifier:
-
The initial <toggle-name> specifies the name, as the item’s value.
-
The first <integer>, if specified, specifies the initial state. If omitted, it’s set to 0.
It must be less than or equal to the second <integer>, or else the declaration is invalid.
-
The second <integer>, if specified, specifies the maximum state. If omitted, it’s set to 1.
-
The sticky keyword, if specified, sets the sticky boolean to true. If omitted, it’s set to false.
-
The group keyword, if specified, sets the group boolean to true. If omitted, it’s set to false.
-
The self keyword, if specified, sets the scope enum to "narrow". If omitted, it’s set to "wide".
-

 1 banana
 1 cup blueberries ...
 < style > li { toggle-create : check self ; } li : toggle ( check ) { color : silver ; text-decoration : line-through ; } </ style >
The effect is identical to what was specified in the Introduction example, except the markup is much simpler and more semantic.
TODO create the toggle-states property that defines state names for a toggle, and amend the various properties to allow them to take a <toggle-name> instead of an <integer>.
Define the precise point in update the rendering when toggles are created if toggle-create names a toggle that doesn’t exist on the element yet.
3.1. Linking Toggle States: the toggle-group property
| Name: | toggle-group |
|---|---|
| Value: | none | [ <toggle-name> self? ]# |
| Initial: | none |
| Applies to: | all elements |
| Inherited: | no |
| Percentages: | n/a |
| Computed value: | as specified |
| Canonical order: | per grammar |
| Media: | interactive |
| Animatable: | no |
By default, each toggle’s state is independent;
incrementing one has no effect an any other.
The toggle-group property allows elements to link their toggles together:
all toggles with the same name as the toggle group that are on elements in scope for the toggle group are linked,
such that only one can be in an active state at a time,
similar to HTML’s <input type=radio>
element.
- none
- The element does not define a toggle group.
- [<toggle-name> self?]#
-
The element defines one or more toggle groups,
one per comma-separated item:
-
The <toggle-name> specifies the name, as the item’s value.
-
The self keyword, if specified, sets the scope enum to "narrow". If omitted, it’s set to "wide".
Only one toggle in a toggle group can be in an active state at a time; see toggle-set for details.
-
< panel-set > < panel-tab > first tab</ panel-tab > < panel-card > first panel</ panel-card > < panel-tab > second tab</ panel-tab > < panel-card > second card</ panel-card > ...</ panel-set > < style > panel-set { /* The common ancestor sets up a group */ toggle-group : tab ; } panel-tab { /* Each tab creates a sticky toggle (so once it’s open, clicking again won’t close it), opts into the group, and declares itself a toggle activator */ toggle : tab 1 group sticky ; } panel-tab : first-of-type { /* The first tab also sets its initial state to be active */ toggle : tab 1 / 1 group sticky ; } panel-tab : toggle ( tab ) { /* styling for the active tab */ } panel-card { /* cards are hidden by default */ display : none ; } panel-card : toggle ( tab ) { display : block ; } </ style >
Clicking on any tab will increment its corresponding toggle’s state from 0 to 1 (and the sticky keyword will keep it at 1 if activated multiple times), while resetting the rest of the tabs' states to 0. Each panel is in scope for the toggle defined by its preceding tab, so it can respond to the state as well.
We probably want to add a bool to toggle groups dictating this; are there more than these two behaviors to deal with?
3.2. Activating a Toggle: the toggle-set property
| Name: | toggle-set |
|---|---|
| Value: | none | [ <toggle-name> <integer [0,∞]>? ]# |
| Initial: | none |
| Applies to: | elements without existing activation behavior (see prose) |
| Inherited: | no |
| Percentages: | n/a |
| Computed value: | as specified |
| Canonical order: | per grammar |
| Media: | interactive |
| Animatable: | no |
The toggle-set property specifies that an element can be activated to change the state of one or more toggles. It has the following values:
- none
-
The element does not manipulated any toggles.
- <toggle-name> <integer [0,∞]>?
-
If the element already has existing activation behavior from the host language, this value does nothing.
Otherwise, the element becomes activatable, and when activated, for each comma-separated entry in the list, fires a toggle activation with the given <toggle-name> and, if an <integer> is specified, a target state of that integer.
A toggle activation is a struct with the following items:
- name
- target state
-
An optional non-negative integer.
If specified, gives the state that this activation will attempt to put the toggle into. If unspecified, indicates that this activation will increment the toggle’s current state.
-
Let el initially be initial element.
-
If el has a toggle with the same name as activation, and initial element is in scope for the toggle, then:
-
Let toggle be the toggle.
-
If el has a toggle specifier with the same name, let specifier be it.
Otherwise, let specifier be a new default toggle specifier for activation’s name.
-
If activation’s target state is specified, set toggle’s state to the smaller of the target state and specifier’s maximum state.
Otherwise, increment toggle’s state by 1. If the state is now higher than specifier’s maximum state, then set the state to 1 if specifier’s sticky flag is true, and to 0 if it’s false.
-
If toggle’s state is now greater than zero and toggle is in a toggle group, then for each other toggle in the same toggle group, set their state to 0.
-
Return from this algorithm.
-
-
Otherwise, continue searching for a toggle:
-
If el has a previous sibling, set el to that element and return to step 2.
-
Otherwise, if el has a parent element, set el to that element and return to step 2.
-
Otherwise, return. (No toggle was found, so nothing happens.)
-
Define in much greater precision what it means to "become activatable". The element must become focusable (with a default spot in the focus order) and become capable of being activated by mouse/keyboard/etc. Similarly define the "already activatable" prose in more detail; we want to exclude things like text inputs, which would confuse a11y tooling, but include buttons that aren’t, like, submit buttons.
3.3. Creating and Activating Toggles Simultaneously: the toggle shorthand
| Name: | toggle |
|---|---|
| Value: | <'toggle-create'> |
| Initial: | see individual properties |
| Applies to: | see individual properties |
| Inherited: | see individual properties |
| Percentages: | see individual properties |
| Computed value: | see individual properties |
| Animation type: | see individual properties |
| Canonical order: | per grammar |
While some cases require setting up a toggle on an ancestor of the elements that will activate and respond to the toggle, in many cases the scope rules for toggles are such that it’s fine to create the toggle on the element intended to activate the toggle as well.
The toggle shorthand sets both the toggle-create and toggle-set properties on an element together. The entire value of the property is assigned to toggle-create, while toggle-set is assigned to just the <toggle-name>s specified in the list, if any.
spoiler-text
element,
the show/hide button precedes the content it will show and hide,
so we can just create the toggle on it as well:
< spoiler-text >  ... < content > ...</ content > </ spoiler-text > < style > spoiler-text > summary { toggle : show ; } spoiler-text > content { toggle-visibility : toggle show ; } </ style >
3.4. Accessibility Implications of Toggles
-
a toggle-set element needs to become activatable/focusable/etc, and communicate in the a11y tree that it’s a checkbox/radio/etc
-
we can infer what type of control it is by examining the properties of the toggle: if it’s part of a group, sticky, etc.
-
if toggle-visibility is in use, we can also automatically infer all the tab-set ARIA roles
4. Selecting Elements Based on Toggle State: the :toggle() pseudo-class
[SELECTORS-4] defines the :checked pseudo-class, which allows author to match certain elements (as defined by the host language) depending on their "checked" state.
Toggles provides a very similar functionality, allowing elements to be selected based on their toggle state, the :toggle() pseudo-class:
:toggle( <toggle-name> <integer>? )
An element matches :toggle() if the element is in scope for a toggle with the name given by <toggle-name>, and either the toggle’s state matches the provided <integer>, or the <integer> is omitted and the toggle is in any active state.
.ingredient{ toggle : used; } .ingredient:toggle ( used) { color : silver; text-decoration : line-through; }
.tristate-check{ toggle : check0 /2 ; } .tristate-check:toggle ( check1 ) { /* "checked" styles */ } .tristate-check:toggle ( check2 ) { /* "indeterminate" styles */ }
If this is inconvenient, only elements that actually know about a particular toggle can be targeted by specifying the inactive state specifically:
.card:toggle ( show0 ) { /* Definitely *not* shown */ }
5. Automatically Hiding With A Toggle
The content-visibility property allows an element to suppress the layout and rendering of its contents, similar to display: none; however, its auto value allows the contents to still be visible to various searching and accessibility features, like find-in-page, hash-navigation, or tab order, and then to automatically become visible when the element becomes relevant to the user.
A common use-case for toggles is also to control whether an element is shown or hidden, and in many cases it would also be useful to allow the contents of elements "hidden" in this way to be accessible in the same ways. To allow for this, the toggle-visibility property allows an element to both respond to and control a toggle with its visibility.
| Name: | toggle-visibility |
|---|---|
| Value: | normal | toggle <toggle-name> |
| Initial: | normal |
| Applies to: | all elements |
| Inherited: | no |
| Percentages: | n/a |
| Computed value: | as specified |
| Canonical order: | per grammar |
| Animation type: | not animatable |
The toggle-visibility property allows an element to automatically tie its display to a particular toggle bi-directionally, while still exposing its contents to be focused, found-in-page, etc., automatically showing itself when relevant.
- normal
-
The property has no effect.
- toggle <toggle-name>
-
If the element is in scope for a toggle of the given <toggle-name>, and that toggle is in the inactive state, the element and its descendants generate no boxes or text runs, similar to display: none, but must still be available to user-agent features such as find-in-page, tab order navigation, etc., and must be focusable as normal, similar to content-visibility: auto.
If the element starts being relevant to the user, it fires a toggle activation, with a name of the given <toggle-name> and a target state of 1.
Note: If the toggle is currently in an inactive state and thus not generating any boxes, it can’t become relevant to the user due to being "on-screen" but the other options are still possible.
Note: If the toggle is in an active state, or the element can’t see the specified toggle at all, the element renders normally.

 Question 1?
 Long answer......
 Question 2?
 Another long answer.....
 < style > . accordion > dt { toggle : show ; } . accordion > dd { toggle-visibility : toggle show ; } </ style >
Each dt
establishes a separate "show" toggle,
with all the defaults filling in to produce a standard "checkbox"-like behavior,
all initially in the inactive state.
Each dt
can be activated to show or hide the following answer.
Each dd
can see the toggle established by its preceding dt
,
and will start out not rendering.
If the user searches on the page for a term,
or visits the page from a link with an #anchor linking into one of the answers,
the relevant answer will automatically activate the toggle,
causing the dd
to become visible.
Define ordering of activations, so if multiple elements become relevant at the same time and they’re all part of a toggle group, which one "wins" is well-defined.
6. Scripting API
-
Expose a map of toggles on an element, with {name=>rest of toggle info}. (Or just a list of toggles, with name built into the object?)
-
Ability to create toggles manually. (Tho without an accompanying toggle-create, you just get the default toggle specifier when it’s activated.)
-
Ability to delete toggles manually. (Tho if you don’t remove the accompanying toggle-create, it’ll respawn on the next rendering tick.)
-
Ability to set toggle state manually.


{%extends 'awards/base.html'%} {% block content %}
{{project.description|safe}}
Published by {{project.publisher|safe}}


[[task | statusLabel]] [[task.display_name]] on [[task.build_variant_display]]
{{if .User}} {{end}}
{{if .ProjectData.Patch}}
{{else}}
{{end}}
| Estimated Time to Start: [[task.wait_time | stringifyNanoseconds]] ([[task.min_queue_pos | ordinalNum]] in queue) | |||||||
| [[timeTaken | stringifyNanoseconds]] [[0 | stringifyNanoseconds]] (cumulative) Not Started (ETA: [[timeToCompletion | stringifyNanoseconds]]) Estimated Runtime: [[timeToCompletion | stringifyNanoseconds]] | |||||||
| [[task.finish_time - task.start_time | stringifyNanoseconds]] (wall clock) | |||||||
| [[baseTimeTaken | stringifyNanoseconds]] on base commit | |||||||
| Latest of [[task.execution+1]] executions [[task.execution + 1 | ordinalNum]] execution Jump to latest | |||||||
| Generated by [[task.generated_by_name]] | |||||||
| [[task.host_id]] [[task.distro]] [[task.distro]] Spawn... | |||||||
| Aborted by [[task.abort_info.user]] because of failing task [[task.aborted_by_display.build_variant_display]]:[[task.aborted_by_display.task_display_name]] because of new version [[task.abort_info.new_version]] because the GitHub PR was closed | |||||||
| Started on [[task.start_time | dateFromNanoseconds | convertDateToUserTimezone:userTz:"MMM D, YYYY h:mm:ss a"]] | |||||||
| Finished on [[task.finish_time | dateFromNanoseconds | convertDateToUserTimezone:userTz:"MMM D, YYYY h:mm:ss a"]] | |||||||
| Failing Command: [[task.task_end_details.desc]] | |||||||
|
Reached
|
|||||||
| Priority: [[task.priority]] | |||||||
| Disabled (priority is less than 0) | |||||||
| Triggered from [[task.upstream_data.project_name]] | |||||||
| Parent display task | |||||||
| View All Tasks History | |||||||
|
|||||||
| Out of Memory Kill detected (PIDs: [[ task.task_end_details.oom_killer.pids.join(", ") ]]) |
Depends On
This task will not run because its dependencies are in an undesirable state.| [[dependency.display_name]] in [[dependency.build_variant]] | must fail must finish | [[dependency | statusLabel]] |
Dependencies for this task have been overridden. It will not wait for its dependencies to finish before running.
Pull Task Sync Command
evergreen pull --task [[task.id]]
Tests
No test results to show
[[(task.test_results | filter:isSuccessful).length]] Succeeded
[[(task.test_results | filter:hasTestFailureStatus).length]] Failed
[[totalTestTimeNano | stringifyNanoseconds]] total runtime
| Test | Time | Test Logs |
|---|---|---|
|
|
|
·
·
|
{{range .PluginContent.Panels.Center}}
{{.}}
{{end}}


Babies, especially newborns, are little, squishy, and fragile. This fragility scares more than a few people. What if you accidentally hurt the baby or drop the baby?
This trope happens when a character is nervous about holding a baby. They could be a first-time parent (usually a dad), a relative, or just someone who's told to hold a baby despite having no experience with them. There are various reasons why they could hate handling babies—usually it's because they're afraid of hurting them, however others just don't get along well with babies or consider it "beneath them" to handle one, and some don't want to hold a baby for fear that they will soil the holder's nice clothes.
Usually, however, nothing goes wrong... Usually. If the baby does fall then it's often Black Comedy and can result in Childhood Brain Damage.
Compare to Maternally Challenged.
Examples:
- Kyros from One Piece outright refused to hold his daughter unless he was wearing gloves out of fear that his past as a murderer would somehow taint her. After a decade or so where his daughter has grown up, the events of the story made him decide that he'll be the "dirty worker" of the peaceful kingdom of Dressrosa in order to defend it, even if her daughter has to see it.
- A humorous version appears in Volume II, Chapter 9 of Castle Waiting. While everyone else at the castle has had a turn watching Jain's infant son Pindar, Chess initially refuses to so much as hold the baby because he considers himself too manly to bother with children or childcare. (Chess softens up after Henry literally throws Pindar into his arms, and even ends up baby-talking to the little guy.)
Chess: N-O, Henry. This is the very thing I've dedicated my entire adult life to avoiding. I have battle-honed reflexes. I am undefeated in all forms of armed and unarmed combat. I rescue damsels. I do NOT tend babies! Forget it!
- One Zits strip has Connie fawning over her friend's newborn baby, then asking Jeremy if he wants to hold it. Suddenly, the phone rings and Connie answers to hear Jeremy on the other end, calling from a payphone across the street, saying "No thank you."
- It's a Fandom-Specific Plot in the Frozen2013 fandom that Elsa will initially be uncomfortable holding her sister Anna's first child:
- In the Frozen oneshot Love Will Thaw, Elsa is terrified to hold her newborn nephew. She's afraid that she'll accidentally freeze him if her powers go awry. It takes Anna and Kristoff all-but forcing her to babysit him for Elsa to get over her fear.
- In Darkness Burning, amongst Elsa's worries is the worry that she'll accidentally hurt her nephew with her powers.
- In the second part of beautifulpurpleflame's Little Cherub series, Starfire tries to convince Robin to hold Raven and Beastboy's newborn daughter, and he's afraid to. Then an argument starts when she tries to point out he should practice because once they get married they'll have their own babies, and it turns out that's yet another fear of his.
- Safehold: Shortly after Hektor and Iris' twins are born, there's a cute scene where Prince Daivyn is asked to hold one of the babies. He agrees, but is clearly terrified of doing something that might harm the child. To be fair, Daivyn is roughly 12 at the time and had zero experience with babies.
- In the Good Luck Charlie episode "Baby Steps", Bob is afraid to carry his youngest son Toby up and down the stairs after accidentally dropping Charlie in the series' first episode, as he's worried he might do the same to Toby. Gabe spends the episode trying to help Bob overcome this fear by having him practice carrying other things up and down the stairs. Near the end of the episode, Bob finally overcomes his fear, when P.J. bumps into him, causing him to drop Toby. Not only does Bob's fear come back, but it's now stronger than ever.
- In the Dollhouse episode "Instinct", Echo complains that "her" husband reacts to her handing him "their" child as if she were trying to get him to hold a loaded grenade.
- In the Friends episode "The One Where Old Yeller Dies", Ross tries to hand Ben over to Rachel to hold. She reluctantly holds him, out at arms length.
 Later, talking to a doctor, he confesses that every time he picks his son up, he has a terrible fear that he will drop him, and that eventually, he'll actually do it just so that he'll stop feeling that anticipation.
- River: John River is afraid to hold his new partner Ira's baby out of fear that he'll drop it. This may be a Casting Gag as Stellan Skarsgård has eight children, but it also represents River's loneliness and isolation from others.
- How I Met Your Mother: Robin was afraid to hold Marshall and Lily's son, Marvin, as part of the fact that she has a discomfort with children in general.
- In the season one finale of The Mandalorian, Cara Dune was resistant to carry the Child, claiming she doesn't "do the whole baby thing."
- Star Trek: The Original Series: Near the end of "Friday's Child", Spock finds himself awkwardly holding Elaan's baby. Dr. McCoy tries showing him how to hold the infant properly; Spock responds by saying "I would rather not" and handing him off.
- ASDF Movie did their take on this, in true fashion.
Woman: Hey, can you hold my baby?
[hands her baby to a man, who promptly drops it]
Man: No, apparently not.
- This is the subject of the Mr Lovenstein comic "Holding the Baby".
- In the Arthur episode "Arthur's Baby" (and "D.W.'s Baby", which reuses this clip), Arthur doesn't think that his new baby sister Kate likes him. When his mother instructs him to hold Kate for a bit, he is very nervous about it. Kate starts crying, and Arthur's sister D.W. helps him take care of Kate. Arthur starts liking Kate after he burps her and causes her to feel better.
- In the Steven Universe episode "Steven's Birthday," Pearl reacts this way after Steven accidentally de-ages himself into a baby. Even though she's the most motherly of the Gems, neither she nor Garnet nor Amethyst have any idea of how to take care of baby Steven, because when he really was a baby, his father Greg did it all.


Hello World
Hello World
Blog posts, projects, and interesting finds will live here.
Info
This section of my site is in the works.
Duration
Check back soon for updates.
Blog posts, projects, and interesting finds will live here.
This section of my site is in the works.
Check back soon for updates.


Machine Learning: the Gathering
predicting your opponent's deck from the first few cards played
In Magic: the Gathering, a collectible card game, competitive players tend to gravitate towards a few dozen of the best decks made up out of a subset of all available cards. For instance in the Legacy format nearly all 18000 cards can be played, yet you’ll only see about 500 show up in tournaments with some cards (e.g. Brainstorm and Force of Will) showing up in > 50% of all high-ranking decks.
When playing in such an event it is key to quickly identify your opponent’s deck and adapt your own game plan accordingly. Top players are able to very quickly do this, bad ones like myself need a few more turns. Here we’ll see if we can train a model that takes in a few known cards and outputs a prediction which deck is being played.
In this blog-post I’ll show you how I made a classifier that can take a list of known cards in your opponent’s deck and return a list of possible decks they are playing. But let’s start with two examples of what it can do first.
Imagine this scenario, on the first turn your opponent leads with Wasteland, on his second turn he plays a Plains and uses it to cast Mother of Runes.
We can feed this information in a function like this:
predict_deck(["Plains", "Mother of Runes", "Wasteland"]).head(3)
And the result is a list of likely decks based on that combination of cards.
| Deck | Probability |
|---|---|
| Death & Taxes | 0.62 |
| Pikula | 0.34 |
| Other - Aggro | 0.04 |
That worked rather well! The most likely deck here is the mono-white Death & Taxes deck, with the Black-White Pikula (also known as Deadguy Ale) in second position. Death & Taxes I would have immediately picked as the likely deck as well, however Pikula is something I never encountered and wouldn’t have considered an option here.
predict_deck(["Arcum's Astrolabe", "Noble Hierarch", "Brainstorm", "Snow-Covered Forest"]).head(3)
| Deck | Probability |
|---|---|
| BUG Midrange | 0.56 |
| Bant Aggro | 0.32 |
| UWx Control | 0.06 |
So in case your opponent started with a Snow-Covered Forest and Noble Hierarch on turn one with an Arcum’s Astrolabe and Brainstorm on turn two, there are two rather likely decks they might be playing. A Black-Blue-Green Midrange deck or a Blue-Green-White Aggro deck. At this point there is no way to know for sure, yet.
As you can see, this classifier can do what top players can do as well. Based on very limited information make an educated guess what deck they are facing. You can find the full code how to do this on GitHub in this repository, the interesting parts I’ll discuss here.
Getting decklists
To start we’ll need a example decks for all types of decks, also called archetypes. There are several websites that store decklists, the one I’ve used is MTG Top 8. Using the requests library to download the site data, and Beautiful Soup to parse the html, I got all Legacy decklists from the last two weeks (downloaded 29/12/2019). You can find all code how to do this in the repo, collecting data and parsing it isn’t the most exciting thing to do though.
Building the training dataset
From each deck we’ll take samples with a few random cards, these are then turned into a presence-absence matrix. In such a matrix each column represents a card and each row a sample, if a card is present in the sample the corresponding cell is 1, if it is absent it is 0. Furthermore for each row we need to keep track of the archetype in another list. In practise we’ll generate for each deck, for a number of different subset sizes, 1500 random samples.
The result looks like this:
The card matrix with samples
This will be the X_train data.
| Sample | Abrupt Decay | Ad Nauseam | Aether Vial | Altar of Dementia | Ancient Tomb | Ancient Ziggurat | Angrath’s Rampage | Animate Dead | … | Watcher for Tomorrow | Waterlogged Grove | Wayward Servant | Whirlpool Rider | Wildborn Preserver | Windswept Heath | Wirewood Symbiote | Wishclaw Talisman | Wooded Foothills | Young Pyromancer |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | … | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 2 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | … | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | … | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 0 |
| 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | … | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| … | … | … | … | … | … | … | … | … | … | … | … | … | … | … | … | … | … | … | … |
The classes
The archetypes are the y_train data, essentially a list of categories for the fit function.
| Sample | archetype |
|---|---|
| 1 | Artifacts Blue |
| 2 | BUG Midrange |
| 3 | Bant Aggro |
| 4 | Bant Control |
| … | … |
Building a classifier
Once the data is in the right format building a classifier is easy. Here I selected a RandomForestClassifier and played around with the settings to end up with this.
from sklearn.ensemble import RandomForestClassifier
rfc = RandomForestClassifier(max_depth=None,
criterion= 'gini',
max_features= 5,
n_estimators= 50)
# Build the classifier
rfc.fit(X_train, y_train)
While this classifier will work, there is an issue! Since we are drawing a number of times random cards from each deck, decks that are popular will be over-represented in our dataset. This imbalance in the input data will negatively influence the classifier. We need to provide a training set with the same number of samples for each archetype. This can be done using pure python, but the library imbalanced-learn makes this easy. It is unfortunately not part of sklearn so you have to install it.
conda install -c conda-forge imbalanced-learn
Once the library is installed we can balance our dataset by randomly selecting a subset of samples from over-represented decklists. This process is called random undersampling.
from imblearn.under_sampling import RandomUnderSampler
from sklearn.ensemble import RandomForestClassifier
rus = RandomUnderSampler()
X_rus, y_rus = rus.fit_sample(X_train, y_train)
# Build a new classifier on the under sampled dataset
rfc = RandomForestClassifier(max_depth=None,
criterion= 'gini',
max_features= 5,
n_estimators= 50,
n_jobs=3)
rfc.fit(X_rus, y_rus)
Using the classifier
The final part we lack is a function that can take a list of known cards in the opponent’s deck, convert that to the right format, run the classifier and return us with a list of probable decks. To do this we need to have a list of all cards in the presence-absence matrix (the column names), which we’ll store in a variable all_cards.
import pandas as pd
def predict_deck(cards_known):
"""
This will take a list of known cards and convert it in a matrix compatible with the classifier.
Next, this classifier will be used to predict which deck the known cards are coming from and
return the results as a sorted pandas dataframe.
"""
cards_array = [[1 if c in cards_known else 0 for c in all_cards]]
cards_not_in_model = [c for c in cards_known if c not in all_cards]
if len(cards_not_in_model) > 0:
print("Some cards were not included when trainig the model, these will be ignored: %s" % ','.join(cards_not_in_model))
decks_proba = rfc.predict_proba(cards_array)[0]
decks = pd.DataFrame(list(zip(rfc.classes_, decks_proba)), columns=["Deck", "Score"])\
.sort_values("Score", axis=0, ascending=False)
return decks
That’s the function from the very beginning of this post. Again, on this page there are only bits and pieces of code highlighted, the notebook on GitHub contains a fully working example. This is a rather nice example how we could go from a set of decklists to a dataset to train the classifier to a working classifier.
Personally, I think it is awesome how you can, in a matter of minutes, pull a set of all decklists and train a classifier on any format you want. While I played a fair bit of Legacy, and currently play Standard, I have no experience with Modern and Pioneer. This classifier would very quickly give me a way to (gu)estimate what an opponent is playing without having to know each competitive deck in the format.
Update 21/02/2020: Imblearn deprecated the return_indices parameter. The code has been updated
Update 01/11/2022: The code has been updated to match mtgtop8’s change in layout
Legal
Parts of this post are unofficial Fan Content permitted under the Wizards of the Coast Fan Content Policy. The literal and graphical information presented on this site about Magic: The Gathering, including card images, the mana symbols, and Oracle text, is copyright Wizards of the Coast, LLC, a subsidiary of Hasbro, Inc. 4DCu.be is not produced by, endorsed by, supported by, or affiliated with Wizards of the Coast.
Liked this post ? You can buy me a coffee


Build
Jobs
Results
Built
Failed
Skipped
Ignored
Fetched
Queued
Remaining
Logs
All Logs
Error Logs
Dependency graph
Queued
Built
Failed
Skipped
Ignored
Fetched
Remaining
Load Averages
Swapinfo
Elapsed
Pkg/Hour
Impulse
Loading...
Build
Master
Build
Status
Jail
Set
Ports Tree
SVN
Jobs
Id
Package
Origin
Status
Elapsed
Built ports
#
Package
Origin
Log
Time
Failed ports
#
Package
Origin
Phase
Skipped
Log
Time
Skipped ports
#
Package
Origin
Reason
Ignored ports
#
Package
Origin
Skipped
Reason
Fetched ports
#
Package
Origin
Queued ports
#
Package
Origin
Reason
Remaining ports
#
Package
Status