This document defines a set of standard high-level data types to aid interoperability of peers at the application level of an EPICS V4 network.
The abstract type definition and function of each such standard type is described. For instance, one such type defined here, named "NTTable", defines a structure for expressing (in pvData) and communicating (using pvAccess) a table of numeric or string data.
The data types described here are approximately equivalent to EPICS V3 Database Request types (commonly known as "DBR" types), although Normative Types extend the concept to structured data and operate at a higher level in a complex control system, or data exchange, than DBR types. Also, Normative Types may be used purely for data exchange though the dynamic data exchange interfaces offered by EPICS V4's pvAccess and pvData modules, such as pvDatabase or pvAccess RPC servers.
For more information about EPICS, please refer to the home page of the Experimental Physics and Industrial Control System, and to the homepage of EPICS Version 4.
This revision of the Normative Types document is a minor modification to the 16 Mar 2015 version. This revision adds minor clarifications to the description of NTTable.
The 16 Mar 2015 version updates the definitions of time_t, control_t, display_t, and alarmLimit_t and changes the order of optional fields in a number of Normative Types. It replaces NTImage with NTNDArray, adds NTAttribute, NTMultiChannel, NTUnion and NTScalarMultiChannel and removes NTVariantArray and a number of types proposed in earlier drafts.
This version contains a number of types which use pvData unions.
It describes the new conventions for Normative Type IDs including versioning and namespaces. Type IDs for Normative Type structure fields are given.
The linguistic conventions used in the document have been overhauled.
See Appendix A for items that may be added to future revisions of this specification.
This version is an Editors Draft towards the First Public Working Draft. The First Public Working Draft will be intended for the EPICS community to review and comment. Resulting comments will drive subsequent revisions of the Normative Types specification and the EPICS V4 Working Group's reference implementations of software that helps create, populate and exchange Normative Type pvData.
Comments are welcome, though bear in mind this is a pre-public release version.
The terms MUST, MUST NOT, SHOULD, SHOULD NOT, REQUIRED, and MAY when highlighted (through style sheets, and in uppercase in the source) are used in accordance with RFC 2119 [RFC2119]. The term NOT REQUIRED (not defined in RFC 2119) indicates exemption.
The Normative Types described in this document are a set of software designs for high-level composite data types suitable for the application-level data exchange between EPICS V4 network endpoints. In particular, they are intended for use in online scientific data services. The intention is that where the endpoints in an EPICS V4 network use only Normative Types, each peer in the network should be able to understand all the data transmitted to it, at least syntactically, and be able to take processing steps appropriate to that data.
We call these types the Normative Types, to emphasize their role as the prescriptions of abstract data structures, whose role and intended semantics are described in this document, as opposed to implemented software; and that conformance to these semantics is a necessary condition for interoperability of using systems.
The EPICS version 4 module pvData bib:pvdata supplies a typing mechanism and object management API for efficiently defining, creating, accessing and updating memory resident structured data. EPICS V4 module pvAccess bib:pvaccess supports the efficient exchange of pvData defined data between EPICS V4 network peers. The EPICS V4 Normative Types specification defines some general purpose data types that build on pvData. These are designed to be generally applicable to the process control, and the software applications level, of scientific instruments.
A simple example of a Normative Type described in this document is the one for exchanging any single scalar value, such as one floating point number, one integer or one string. That Normative Type is named "NTScalar". When a client receives a pvData datum which identifies itself as being of type NTScalar, the client will know to expect that the structure which carries the NTScalar will include the scalar value in question (along with its type), and that value may be accompanied by up to 5 additional fields: a description of the quality in question, a timestamp, an indication of alarm severity, fields that help in how to display the value, and data about its operating limits. See the example below.
An example of a simple Normative Type is the NTScalar:
NTScalar := structure scalar_t value string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt display_t display :opt control_t control :opt
A more complex example: If a client receives a pvData datum which identifies itself as being of type NTTable, this document specifies that it should expect the datum to contain 0 or more arrays of potentially different types. The description of NTTable in this document will say that the client should interpret the arrays as the columns of a table, and should render such a datum appropriately as a table, with row elements being taken from the same numbered elements of each array.
NTTable := structure string[] labels // The field names of each field in value structure value {scalar_t[] colname}0+ // 0 or more scalar array type // instances, the column values. string descriptor : opt alarm_t alarm : opt time_t timeStamp : opt
All the EPICS V4 Normative Types are defined as particular structure instance definitions of a pvData structure. This is true even of the Normative Types describing simple values like a single int, since all Normative Types optionally include descriptor, alarm and timestamp. The fields of any given Ntype datum instance can be ascertained at runtime using the pvData Field introspection interface bib:pvdata.
See the Normative Type instance self-identification section below for more on how to examine a given pvData instance to see which fields it includes. That section also includes how to mark a pvData instance as a Normative Type, and how to look for that mark.
Definition: Normative Type
The Normative Types definitions in this document each have the following general form:
A Normative Type can be used both for sending data from client to service and from service to client. In this document we refer generally to an agent, being either a client or a server. If the agent is specifically at the user's end, we call it the user agent. Client and server refer to the directionality of the transaction, server being the agent that is doing the sending.
The word "Ntype" is used as a short form of "Normative Type".
The Normative Type data descriptions are given with the syntactic conventions and grammar given below. The types are described in the pvData "Meta" Language. A BNF-like syntax is used in order to add clear distinctions between symbol types, particularly terminality, recurrence, which names a user is expected to add and which are predefined. This syntax is essentially Extended Backus-Naur Form (EBNF), with some slight modifications to preserve the order of terms and the rules for line ends and indentation in the pvData Meta language.
The syntactic conventions are as follows.
First, the conventions for terminal and non-terminal types are:
So, for example, scalar_t is non-terminal as it stands for a choice of pvData type and time_t is non-terminal because it stands for a particular structure. On the other hand, in the definition of time_t, long and secondsPastEpoch are a keyword and a label respectively, and so are terminal, and the columns of NTTable, colname, are user-provided labels.
In this section <> will also be used for describing patterns of definitions or meta rules such as production rules of the grammar to indicate a choice of terminal or non-terminal terms in the pattern or rule.
The EBNF-like syntax for definitions is used. A description consists of 3 terms - a left-hand side (LHS), a right-hand side (RHS), and the symbol ":=" separating them, which is to be interpreted as "LHS is defined as RHS". The LHS will be the non-terminal being defined. The RHS will be a sequence of terminal or non-terminal terms.
Note that in the definitions below line-ends (EOLs) are not explicitly specified. They are implied except when multiple lines are used to specify alternatives separated by |, where only the final EOL is implied.
The following EBNF symbols are also used:
The following production rules are employed:
In the case of structure and union fields, to preserve the order of terms in the pvData Meta language, as well as obtaining appropriate indentation, the usual EBNF rule of replacing a non-terminal by its definition requires the following modification:
Suppose a non-terminal term has a definition of the form
<non-terminal>:= structure fieldList
where:
<non-terminal> fieldNameare replaced by
structure fieldName fieldList
The result of the any substitution is suitably indented to preserve the logic of the pvData meta language.
Thus the structure derived from the definition of NTEnum below, with all optional fields present, is
structure structure value int index string[] choices string descriptor structure timeStamp long secondsPastEpoch int nanoseconds int userTag structure alarm int severity int status string message
The same rule also applies with union in place of structure.
The grammar for a Normative Type definition follows the pattern below. That is, a Normative Type is defined as a structure composed of fields. A field may be optional, and may be described along with a comment:
<NormativeType>:= structure { pvDataField [:opt] [// commentText]] }1+
where:
In most cases a Normative Type definition will be of the form
<NTname>:= structure { ntfieldChoice fieldName [:opt] [// commentText] }1+
where:
NTExample := structure enum_t | scalar_t value int N // this field has a comment string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
This section defines the fields that may appear in a Normative Type's definition.
Each field of a Normative Type will typically be one of the following:
ntfield := scalar_t // a simple numerical, boolean, or string value | scalar_t[] // an array of simple values | enum_t // an enumeration | enum_t[] // an array of enumerations | time_t // a point in time, used for timestamps | time_t[] // an array of points in time | alarm_t // a summary diagnostic of a control system event | alarm_t[] // an array of summary diagnostics | alarmLimit_t // value thresholds for a control system diagnostic report | alarmLimit_t[] // an array of threshold values | display_t // metadata of displayed data | display_t[] // an array of display metadata | control_t // control setpoint range boundaries | control_t[] // an array of control setpoint range boundaries | any // a variant union type | any[] // an array of variant unions fields | ntunion_t // a regular union storing ntfields only | ntunion_t[] // a regular union array storing ntfields only | union_t // any regular union | union_t[] // any regular union array | anyunion_t // any variant or regular union | anyunion_t[] // any variant or regular union array
although some examples may have fields of other types.
Note that of all the Normative Type fields only scalar_t and scalar_t[] are of simple type, that is, having a single scalar or scalar array value of a fixed type. All the others are represented by a complex type, i.e. a structure or union or arrays of structures or unions (see Structured Normative Type fields and Union Normative Type fields below).
The field is a scalar value. Scalar fields would be implemented with pvData field Type "scalar":
scalar_t :=
boolean // true or false
| byte // 8 bit signed integer
| ubyte // 8 bit unsigned integer
| short // 16 bit signed integer
| ushort // 16 bit unsigned integer
| int // 32 bit signed integer
| uint // 32 bit unsigned integer
| long // 64 bit signed integer
| ulong // 64 bit unsigned integer
| float // single precision IEEE 754
| double // double precision IEEE 754
| string // UTF-8 *
The field is an array of scalars. Scalar array fields would be implemented with a pvData field of type "scalarArray":
scalar_t[] :=
boolean[] // array of true or false
| byte[] // array of 8 bit signed integer
| ubyte[] // array of 8 bit unsigned integer
| short[] // array of 16 bit signed integer
| ushort[] // array of 16 bit unsigned integer
| int[] // array of 32 bit signed integer
| uint[] // array of 32 bit unsigned integer
| long[] // array of 64 bit signed integer
| ulong[] // array of 64 bit unsigned integer
| float[] // array of single precision IEEE 754
| double[] // array of double precision IEEE 754
| string[] // array of UTF-8 *
This subsection defines those fields of a Normative Type structure definition that are themselves structures or arrays of structures.
The structured Normative Type fields would be implemented with type pvData field type "structure" or "structureArray".
An enum_t describes an enumeration. The field is a structure describing a value drawn from a given set of valid values also given. It is implemented as a pvData Field of type "structure" of type ID "enum_t" with the following form:
enum_t :=
structure
int index
string[] choices
where:
An enum_t[] describes an array of enumerations. The field is an array of structures each describing a value drawn from a given set of valid values also given in each. It is implemented as a pvData field of type "structureArray", each element of which is a structure of the form enum_t above.
A time_t describes a defined point in time. The field is a structure describing a time relative to midnight on January 1st, 1970 UTC. It is implemented as a pvData field of type "structure" of type ID "time_t" and with the following form:
time_t :=
structure
long secondsPastEpoch
int nanoseconds
int userTag
where:
Interpretation: The point in time being identified by a time_t, is given by Jan 1, 1970 00:00:00 UTC plus some nanoseconds given by its secondsPastEpoch times 109 plus its nanoseconds.
A time_t[] describes an array of points in time. The field is an array of structures each describing a time relative to January 1st, 1970 UTC. It is implemented as a pvData field of type "structureArray", each element of which is a structure of the form time_t above.
An alarm_t describes a diagnostic of the value of a control system process variable. It indicates essentially whether the associated value is good or bad, and whether agent systems should alert people to the status of the process.
Processes in EPICS V3 and V4 IOCs include extensive support for evaluating alarm conditions. The definition of the fields in an alarm are given in bib:epicsrecref. The field is a structure describing an alarm. It is implemented as a pvData field of type "structure" of type ID "alarm_t" with the following form:
alarm_t :=
structure
int severity
int status
string message
where:
Interpretation MUST be as with V3 IOC record processing, as described in the EPICS Reference Manual bib:epicsrecref.
An alarm_t[] is an array of alarm conditions. The field is an array of structures each describing an alarm condition. It is implemented as a pvData field of type "structureArray", each element of which is a structure of the form alarm_t above.
An alarmLimit_t is a structure that gives the numeric intervals to be used for the high and low limit ranges of an associated value field. The specific value to which the alarmLimit refers, is not specified in the alarmLimit structure. It is usually a value field of type double that appears in the same structure as the alarmLimit. alarmLimit_t is implemented as a pvData field of type "structure" of type ID "alarmLimit_t" with the following form:
alarmLimit_t :=
structure
boolean active
double lowAlarmLimit
double lowWarningLimit
double highWarningLimit
double highAlarmLimit
int lowAlarmSeverity
int lowWarningSeverity
int highWarningSeverity
int highAlarmSeverity
double hysteresis
where:
Code that checks for alarms should use code similar to the following:
boolean active = pvActive.get(); if(!active) return; double val = pvValue.get(); int severity = pvHighAlarmSeverity.get(); double level = pvHighAlarmLimit.get(); if(severity>0 && (val>=level)) { raiseAlarm(level,val,severity,"highAlarm"); return; } severity = pvLowAlarmSeverity.get(); level = pvLowAlarmLimit.get(); if(severity>0 && (val<=level)) { raiseAlarm(level,val,severity,"lowAlarm"); return; } severity = pvHighWarningSeverity.get(); level = pvHighWarningLimit.get(); if(severity>0 && (val>=level)) { raiseAlarm(level,val,severity,"highWarning"); return; } severity = pvLowWarningSeverity.get(); level = pvLowWarningLimit.get(); if(severity>0 && (val<=level)) { raiseAlarm(level,val,severity,"lowWarning"); return; } raiseAlarm(0,val,0,"");
NOTE: The current pvData implementations have a structure named valueAlarm_t instead of alarmLimit_t. valueAlarm_t is similar to alarmLimit_t, except that the former's alarm limit fields (lowAlarmLimit, lowWarningLimit, highWarningLimit and highAlarmLimit) can be any integer or floating point scalar type (the same type for all the limit fields in each case), rather than only double. There is also a separate form for alarm limits for boolean values. alarmLimit_t is identical to the valueAlarm_t for type double, except that the type ID of valueAlarm_t is "valueAlarm_t"). Normative types only defines alarmLimit since this is what clients like plot tools use.
An alarmLimit_t[] is an array of alarm limit conditions. The field is an array of structures each describing an alarm limit. It is implemented as a pvData field of type "structureArray", each element of which is a structure of the form alarmLimit_t above.
A display_t is a structure that describes some typical attributes of a numerical value that are of interest when displaying the value on a computer screen or similar medium. The units field SHOULD contain a string representation of the physical units for the value, if any. The description field SHOULD contain a short (one-line) description of what the value represents, such as can be used as a label in a display. The fields limitLow and limitHigh represent the range in between which the value should be presented as adjustable.
The field is a structure describing a display_t. It is implemented as a pvData field of type "structure" of type ID "display_t" with the following form:
display_t :=
structure
double limitLow
double limitHigh
string description
string format
string units
where:
Where an display_t structure instance is present in a Normative Type structure, it MUST be interpreted as referring to that Normative Type's field named "value". Therefore it is only used in Normative Types that have a single numeric "value" field.
A display_t[] is an array of display_t. The field is an array of structures each describing the display media oriented metadata of some corresponding process variable value, as described by display_t above. It is implemented as a pvData field of type "structureArray", each element of which is a structure of the form display_t above.
A control_t is a structure that describes a range, given by the interval (limitLow,limitHigh), within which it is expected some control software or hardware shall bind the control PV to which this Normative Type instance's value field refers as well as a minimum step change of the control PV.
The field is a structure describing a control_t. It is implemented as a pvData field of type "structure" of type ID "control_t" with the following form:
control_t :=
structure
double limitLow
double limitHigh
double minStep
where:
A control_t[] is an array of control_t. The field is an array of structures each describing the setpoint range interval of some process variable. It is implemented as a pvData field of type "structureArray", each element of which is a structure of the form control_t above.
This subsection defines those fields of a Normative Type structure definition that are unions or arrays of unions.
The union NormativeType fields are implemented with pvData fields of type "union" or "unionArray".
The union Normative Type fields consist of the variant union any and variant union array any[] as well as a number of non-terminal terms:This is a field which is a variant union and is implemented using the pvData field type "union".
This is a field that is an array of any, implemented using the pvData field type "unionArray".
ntunion_t stands for any regular union of ntfields and is implemented using the pvData field type "union":
ntunion_t := union {ntfield field-name}1+ // 1 or more ntfields.
An ntunion_t[] stands for an array of unions, where the union is any regular union of 1 or more ntfields. It is implemented as a pvData field of type "unionArray" each element of which is a union (the same one in each case) of the form ntunion_t above.
union_t stands for any regular union of pvData fields and is implemented using the pvData field of type "union":
union_t := union {pvDataField}1+ // 1 or more pvData fields.
where:
A union_t[] stands for an array of unions, where the union is any regular union of 1 or more pvData fields. It is implemented as a pvData field of type "unionArray" each element of which is a union (the same one in each case) of the form union_t above.
anyunion_t stands for a variant union or any regular union of pvData fields and is implemented using the pvData field type "union":
anyunion_t:= any | union_t
An anyunion_t[] stands for a variant union array or a regular union array of any type an array of unions, where the union is any regular union of 1 or more pvData fields. It is implemented as a pvData field of type "unionArray" each element of which is a union (the same one in each case) of the form anyunion_t above:
anyunion_t[]:= any[] | union_t[]
Metadata are included in runtime instances of Normative Types. The metadata includes to which Normative Type the structure instance conforms, version information, and other data to aid efficient processing, diagnostics and displays.
Normative Type instance data MUST identify themselves as such by including an identifying string. That is the Normative Type Identifier, or "Ntype Identifier" string for short. In the pvData binding of Normative Types, this string is carried in the type ID, added automatically to every pvData structure.
A Normative Type Identifier MUST be considered to be "case sensitive."
The namespace Name of EPICS Normative Types (which is used as the prefix for their pvData type ID), is the following:
epics:nt
The normative list of the Normative Type Identifiers corresponding to this draft of the EPICS V4 Normative Types specification document (this document), is given in Appendix B
As an example, one of the simplest Normative Types is NTScalar. It has formal Type Name "NTScalar". Therefore, the Normative Type Identifier for an NTScalar, is presently epics:nt/NTScalar:1.0.
At present it is envisaged that the same namespace value shall be used for all versions of this document prior to Recommendation, including all Public Working Drafts of this document and those marked Last Call or similar.
In the EPICS v4 pvData/pvAccess binding, the structure identification string (ID) of pvData structures is used to communicate the Normative Type of the datum carried by the pvData structure. Every pvData datum which is intended to conform to a Normative Type, MUST identify the Normative Type to which it conforms through its type ID. Its ID MUST have the value of its Normative Type Identifier. For instance, a pvData structure conforming to NTScalar, must have ID equal to "epics:nt/NTScalar:1.0". Every EPICS V4 agent which is encoding or decoding pvData data that is described by Normative Types, SHOULD examine the ID of such data, to establish the Normative Type to which each datum conforms.
Recall that in the pvData system, data variables are constructed in two equally important parts; the introspection interface, in which data types are defined, and the data interface, in which instance variables are created and populated. The introspection interface can be used to examine an existing instance, to see what fields it possesses. Getting and setting values, is done through the data interface. As a programmer, you have to define both parts, the introspection interface of your type, and its data interface. Both the data and the introspection interfaces are exchanged by pvAccess. That is, when a sender constructs a data type, such as one conforming to an Normative Type, plus an instance of that type, and it sends the instance to a receiver, the receiver can check that the instance indeed contains the member fields it should find for that type, using the type's introspection interface.
The following Java code snippets give an example of the use of a pvData structure of Normative Type NTScalar, as defined below. in this example we show code as may be included in a trivial "multiplier" service, and a client of the multiplier service.
The sender typically first creates an introspection definition, using the pvData introspection interfaces (Field, Structure etc.). It then creates an instance of the type and populates it with the pvData data interfaces (PVField, PVStructure etc.).
// Create the data type definition, using the pvData introspection interface (Structure etc.). FieldCreate fieldCreate = FieldFactory.getFieldCreate(); Structure resultStructure = fieldCreate.createStructure( "epics:nt/NTScalar:1.0", new String[] { "value", "descriptor" }, new Field[] { fieldCreate.createScalar(ScalarType.pvDouble), fieldCreate.createScalar(ScalarType.pvString) } );
Subsequently, the sender would create an instance of the type, and populate it.
// If a and b were arguments to this service, the following creates an instance of // a resultStructure, which conforms to the NTScalar Normative Type definition, // and populates it. It would then return this PVStructure instance. PVStructure result = PVDataFactory.getPVDataCreate().createPVStructure(resultStructure); result.getDoubleField("value").put(a * b); result.getStringField("descriptor").put("The product of arguments a and b");
The PVStructure instance, in the example called "result" would be returned to the receiver.
Having in some way done a pvAccess get, the receiver could simply extract the primary value:
PVStructure result = easyPVA.createChannel("multiplierService").createRPC().request(request); double product = result.getDoubleField("value").get();
A well written receiver would check that the introspection interface (Structure etc.) says that the received instance is indeed of the type it expects. It may extract the data fields individually, checking their type. Importantly, it can also see which optional fields it received, before attempting to access them. Here is a more complete receiver example for the NTScalar sent above. This code might be in the client side of the Multiplier service.
// Call the multiplier service sending the request in a structure PVStructure result = easyPVA.createChannel("multiplierService").createRPC().request(request); // Examine the returned structure via its introspection interface, to check whether its // identifier says that it is a Normative Type, and the type we expected. if (!result.getStructure().getID().equals("epics:nt/NTScalar:1.0")) { System.err.println("Unexpected data identifier returned from multiplierService: " + "Expected Normative Type ID epics:nt/NTScalar:1.0, but got " + result.getStructure().getID()); System.exit(-1); } // Get and print the required value member field as a Double. System.out.println( "value = " + result.getDoubleField("value").get()); // See if there was also the descriptor subField, and if so, get it and print it. PVString descriptorpv = (PVString)result.getSubField("descriptor"); if ( descriptorpv != null) System.out.println( "descriptor = " + descriptorpv.get()); // Or just print everything we got: System.out.println("\nWhole result structure toString =\n" + result);
In future drafts of this specification, a pattern to create extensions to the EPICS V4 Normative Types may be presented. It may be based on a formalized link to the XML namespace and XML Schema system, whereby the namespace part of the Normative Type Identifier of a datum whose type is an extension of one of these Normative Types, is replaced by another namespace that extends this one through an XML Schema out of band. In that case, the type name part would identify a type in that other namespace, though it may extend a type in this namespace.
All of the Normative Types defined below, optionally include a descriptor, alarm and timestamp. There is no required interpretation of these fields, and therefore their meaning is not further described in the Normative Type definitions. Additionally, Normative Types may have other optional fields, as defined individually below.
An object of Normative Type may optionally include a field named "descriptor" and of type string, to be used to give identity, name, or sense information. For instance, it may be valued with the name of a device associated with control data, or the run number of a table of model data.
string descriptor :opt // Contextual information
An object of Normative Type may optionally include an alarm field.
alarm_t alarm :opt // Control system event summary
An object of Normative Type may optionally include a timeStamp field.
time_t timeStamp :opt // Event time
The General Normative Types are for encapsulating data of any kind of application or use case. Compare to Specific Normative Types, defined later in this document, which are oriented to particular use cases.
NTScalar is the EPICS V4 Normative Type that describes a single scalar value plus metadata:
NTScalar := structure scalar_t value string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt display_t display :opt control_t control :opt
where:
NTScalarArray is the EPICS V4 Normative Type that describes an array of values, plus metadata. All the elements of the array of the same scalar type.
NTScalarArray := structure scalar_t[] value string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt display_t display :opt control_t control :opt
where:
NTEnum is an EPICS V4 Normative Type that describes an enumeration (a closed set of possible values each described by an n-tuple).
NTEnum := structure enum_t value string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
where:
NTMatrix is an EPICS V4 Normative Type used to define a matrix, specifically a 2-dimensional array of real numbers.
NTMatrix := structure double[] value int[2] dim :opt string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt display_t display :opt
where:
User agents that print or otherwise render an NTMarix SHOULD print row vector, column vector, and non-vector matrices appropriately.
NTURI is the EPICS V4 Normative Type that describes a Uniform Resource Identifier (URI) bib:uri. Specifically, NTURI carries the four parts of a "Generic URI", as described in bib:uri as the subset of URI that share a common syntax for representing hierarchical relationships within the namespace. As such, NTURI is intended to be able to encode any generic URI scheme's data. However, NTURI's primary purpose in the context of EPICS, is to offer a well formed and standard compliant way that EPICS agents can make a request for an identified resource from a channel, especially an EPICS V4 RPC channel. See ChannelRPC.
The "pva" scheme is introduced here for EPICS V4 interactions. The pva scheme implies but does not require use of the pvAccess protocol. A scheme description for Channel Access (implying the ca protocol) will be added later. What follows is a description of the syntax and semantics for the pva scheme.
NTURI :=
structure
string scheme
string authority : opt
string path
structure query : opt
{string | double | int <field-name>}0+
{<field-type> <field-name>}0+
The following describes how the fields of the NTURI must be interpreted when the scheme is "pva":
The channel name given in the path MAY BE the name of an RPC channel. In that case, it's important to note that this specification makes no normative statement about where in the NTURI is encoded the name of the entity about which the RPC service is being called. For instance, an archive service, that gives the historical values of channels, may advertise itself as being on a single channel called say "archive service" (so the NTURI path field in that case would be set to "archiveservice", and in that case, the name of the EPICS channel about which archive data is wanted might well be encoded into one of the NTURI's query field parameters. Alternatively, the archive service might advertise a number of channels, each named perhaps after the channels whose historical data is being requested. For instance, a path may be "quad45:bdes;history", if that was the name of one of the channels offered by the archive service. An example of this second form is given below.
Use of NTURI may be explained by example. The following is an example client side of Channel RPC exchange, where a notional archive service, is asked for the data for a PV between two points in time. In this example, the archive service is advertising the channel name "quad45:bdes;history". Presumably, that service knows the archive history of a (second) channel, named probably, "quad45:bdes".
Construct the introspection interface (i.e. type definition) of the NTURI conformant structure that will be used to make requests to the archive service.
// Construct an NTURI for making a request to a service that understands // query arguments named "starttime" and "endtime". FieldCreate fieldCreate = FieldFactory.getFieldCreate(); Structure queryStructure = fieldCreate.createStructure( new String[] {"starttime", "endtime"}, new Field[] { fieldCreate.createScalar(ScalarType.pvString), fieldCreate.createScalar(ScalarType.pvString)}); Structure uriStructure = fieldCreate.createStructure("epics:nt/NTURI:1.0", new String[] { "path", "query" }, new Field[] { fieldCreate.createScalar(ScalarType.pvString), queryStructure } );
Populate our uriStructure (conformant to NTURI) with a specific request.
// Get a EasyPVA singleton. EasyPVA easyPVA = EasyPVAFactory.get(); // Construct an NTURI with which to ask for the archive data of quad45:bdes PVStructure request = PVDataFactory.getPVDataCreate(). createPVStructure(uriStructure); request.getStringField("path").put("quad45:bdes;history"); PVStructure query = request.getStructureField("query"); query.getStringField("starttime").put("2011-09-16T02.12.55"); query.getStringField("endtime").put("2011-09-16T10.01.03"); // Ask for the data, using the NTURI PVStructure result = easyPVA.createChannel(request.getStringField("path").get()).createRPC().request(request); if ( result != null ) System.out.println("The URI request structure:\n" + request +"\n\nResulted in:\n" + result);
The server side is not illustrated, but clearly its code would have registered a number of ChannelRPC services, each named after the PV whose historical data it offered.
NTNameValue is the EPICS V4 Normative Type that describes a system of name and scalar values.
Use cases: In a school, a single NTNamedValue might describe the grades from a number of classes for one student.
NTNameValue := structure string[] name scalar_t[] value string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
where:
Each name (or "key") in the array of names, MUST be interpreted as being associated with its same indexed element of the value array.
NTTable is the EPICS V4 Normative Type suitable for column-oriented tabular datasets.
An NTTable is made up of a number of arrays. Each array can be thought of as a column. Each array MUST be of a scalar type and all the arrays MUST be of the same length. Each array may be of a different scalar type. The set of the ith array members of all the columns make up one row, or n-tuple. The number of elements of labels MUST be equal to the number of fields of value.
Use case examples: a table of the Twiss parameters of all the lattice elements in an accelerator section. Another example, where the columns might vary call-to-call to an RPC setting, would be that of an EPICS V4 SQL database service. In that example one NTTable returned by the service would contain the tabular results of a SQL SELECT, essentially a recoded JDBC or ODBC ResultSet - see the rdbservice.
NTTable := structure string[] labels // Very short text describing each field below, i.e. column labels structure value {scalar_t[] colname}0+ // 0 or more scalar array instances, the column values. string descriptor : opt alarm_t alarm : opt time_t timeStamp : opt
where:
An NTTable instance represents a table of data. The column data is given in scalar arrays in the structure field value, and the column headings are given in field labels. Each colname scalar array field of value contains the data for the column corresponding to the same indexed element of the labels field. Agents SHOULD use the elements of labels as the column headings. There is no normative requirement that the field names of value match the strings in labels.
Note that the above description is given in terms of a table and its columns, but there is nothing specifically columnar about how this data may be rendered. A user may choose to print the fields row wise if, for instance, if there are many fields in value, but each has only length 1 or 2. For example, if one wanted to give all the scalar data related to one device, then one might use an NTTable rendered in such a way.
The number of scalar_t[] fields in the value structure, and the length of labels MUST be the same. All scalar_t[] fields in the value structure MUST have the same length, which is the number of "rows" in the table.
NTAttribute is the EPICS V4 Normative Type for a named attribute of any type. It is is essentially a key-value pair which optionally can be tagged with additional strings.
This allows, for example, a collection of attributes to be queried on the basis of attribute name or tags.
NTAttribute := structure string name any value string[] tags : opt string descriptor : opt alarm_t alarm : opt time_t timeStamp : opt
where:
The "Specific Normative Types" below are types oriented towards application-level scientific and engineering use cases. Compare to General Normative Types defined above. The currently defined types are each described in a section below.
Unless otherwise stated:
NTMultiChannel is an EPICS V4 Normative Type that aggregates an array of values from different EPICS Process Variable (PV) channel sources, not necessarily of the same type, into a single variable.
NTMultiChannel := structure anyunion_t[] value // The channel values string[] channelName // The channel names string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt int[] severity :opt int[] status :opt string[] message :opt long[] secondsPastEpoch :opt int[] nanoseconds :opt int[] userTag :opt
where:
NTNDArray is an EPICS Version 4 Normative Type designed to encode data from detectors and cameras, especially areaDetector applications. The type is heavily modeled on areaDetector's NDArray class. One NTNDArray gives one frame.
The definition of NTNDArray in full is:
NTNDArray := structure value_t value codec_t codec long compressedSize long uncompressedSize dimension_t[] dimension int uniqueId time_t dataTimeStamp NTAttribute[] attribute string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt display_t display :opt
The meaning of the above fields, the definition of value_t and of dimension_t and the additional requirements for NDAttribute are described below. To simplify this the NTNDArray can be regarded as being composed of the following parts:
NTNDArray := structure Image data and codec Data sizes Dimensions Unique ID and data timestamp Attributes Optional fields
Each of these will be discussed separately.
The Image data and codec parts of an NTNDArray are composed of the following fields:
value_t value // Image data codec_t codec // Codec
where:
A value_t is implemented as a pvData Field of type "union" with the following form:
value_t:=
union
boolean[] booleanValue
byte[] byteValue
short[] shortValue
int[] intValue
long[] longValue
ubyte[] ubyteValue
ushort[] ushortValue
uint[] uintValue
ulong[] ulongValue
float[] floatValue
double[] doubleValue
A codec_t is implemented as a pvData Field of type "structure" of type ID "codec_t" with the following form:
codec_t :=
structure
string name
any parameters
where:
The value field stores a scalar array of one of the scalar types permitted by the definition of value above whose value MUST represent an N-dimensional scalar array of one of the permitted scalar types whose dimensions are given by the dimension field (see below). Note that the scalar type of the array stored in value MAY be different from that of the array it represents.
The codec field is a structure which describes how the N-dimensional scalar array is represented by the value of the scalar array stored in the value field.
The name field of the codec field (codec.name) is a string which identifies the scheme by which the data in value is encoded, such as an algorithm used to compress the data. If it is not the empty string, the value of the codec.name field SHOULD be namespace qualified.
The parameters field of the codec field (codec.parameters) is a field which contains any additional information required to interpret the data in value. The format and meaning of codec.parameters is codec.name-dependent.
When the value of the codec.name field is the empty string the data in value MUST represent an N-dimensional array of the same scalar type as the scalar array stored in value whose dimensions are given by the dimension field. The elements of the array stored in value MUST be the elements of the N-dimensional array laid out in row major order. In this case the length of the value array SHOULD equal the product of the dimensions and MUST be greater than or equal to it.
When the codec.name field value is not the empty string the interpretation of the data in the value field is dependent on the codec field. Any requirements on the type or length of the array stored in the value field are codec-dependent.
Any endianness information associated with a compression algorithm or other encoding SHOULD be encoded via the codec field, either through the codec.name or codec.parameters fields.
Similarly any information required to determine the scalar type of the N-dimensional array when the value of codec.name field is non-empty SHOULD also be encoded in the codec field.
Except for the above requirements, the meaning of the codec field, beyond the case of the empty codec.name string, is not currently specified.
The Data sizes part of an NTNDArray is composed of the following fields:
long compressedSize long uncompressedSize
where:
The value of the compressedSize field MUST be equal to the product of the length of the scalar array field stored in the value field and the size of the scalar type in bytes (i.e. 1, 2, 4 or 8 for signed or unsigned byte, short, int or long respectively, 1 for boolean, 4 for float and 8 for double).
The value of the uncompressedSize field MUST be equal to the product of the value of the size field of each element in the structure array dimension field (described below) and the size in bytes of the scalar type of the scalar array represented by value. If the number of elements of the dimension field is 0 the value of the uncompressedSize MUST be 0.
The Dimensions part of an NTNDArray is composed of the dimension field
dimension_t[] dimension
A dimension_t is implemented as a pvData Field of type "structure" of type ID "dimension_t" with the following form:
dimension_t :=
structure
int size
int offset
int fullSize
int binning
boolean reverse
where:
The number of elements in the value of the dimension field MAY be 0. A client SHOULD check for this case and take appropriate action.
If an NTNDArray represents a subregion of a larger region of interest of an original image, its offset, binning and reversefield values SHOULD be relative to the original image and its fullSize field value SHOULD be the size of the original.
dimension_t is analogous to NDDimension_t in areaDetector.The Unique ID and data timestamp parts of an NTNDArray are composed of the following fields:
int uniqueId time_t dataTimeStamp
where:
The value of dataTimeStamp MAY be different from that of the (optional) timeStamp field below.
The uniqueId and dataTimeStamp fields of NTNDArray correspond to the uniqueId and timeStamp fields respectively of an NDArray.
The Attributes part of an NTNDArray is composed of the field:
NTAttribute[] attribute
where NTAttribute is as defined by this standard, but is extended in this case as follows:
NTAttribute := structure string name any value string[] tags : opt string descriptor alarm_t alarm : opt time_t timeStamp : opt int sourceType string source
where:
NDAttrSourceDriver = 0, /** Attribute is obtained directly from driver */ NDAttrSourceParam = 1, /** Attribute is obtained from an asyn parameter library */ NDAttrSourceEPICSPV = 2, /** Attribute is obtained from an EPICS PV */ NDAttrSourceFunct = 3 /** Attribute is obtained from a user-specified function */
Note that the optional descriptor field of NTAttribute is mandatory for attributes of an NTNDArray.
NTAttribute here is extended by the addition of the sourceType and source fields. source is a string which gives the origin of the attribute according to the value of the integer sourceType field as follows:
The extension of NTAttribute is analogous to NDAttribute in areaDetector. The name, descriptor, sourceType and source fields correspond to the pName, pDescription, sourceType, pSource members of an NDAttribute respectively.
The attributes themselves are not defined by this standard.
For areaDetector applications the attribute field encodes the linked list of NDAttributes in an NDArray.
[Note: areaDetector currently defines two integer attributes, colorMode and bayerPattern, with descriptions "Color mode" and "Bayer pattern" respectively:NDColorModeMono = 0, /** Monochromatic image */ NDColorModeBayer = 1, /** Bayer pattern image, 1 value per pixel but with color filter on detector */ NDColorModeRGB1 = 2, /** RGB image with pixel color interleave, data array is [3, NX, NY] */ NDColorModeRGB2 = 3, /** RGB image with row color interleave, data array is [NX, 3, NY] */ NDColorModeRGB3 = 4, /** RGB image with plane color interleave, data array is [NX, NY, 3] */ NDColorModeYUV444 = 5, /** YUV image, 3 bytes encodes 1 RGB pixel */ NDColorModeYUV422 = 6, /** YUV image, 4 bytes encodes 2 RGB pixel */ NDColorModeYUV411 = 7 /** YUV image, 6 bytes encodes 4 RGB pixels */
NDBayerRGGB = 0, /** First line RGRG, second line GBGB... */ NDBayerGBRG = 1, /** First line GBGB, second line RGRG... */ NDBayerGRBG = 2, /** First line GRGR, second line BGBG... */ NDBayerBGGR = 3 /** First line BGBG, second line GRGR... */
NTContinuum is the EPICS V4 Normative Type used to express a sequence of point values in time or frequency domain. Each point has N values (N>=1) and an additional value which describes the index of the list. The additional value is carried in the base field. The value field carries the values which make up the point in index order.
An additional units field gives a units string for the N values and the additional value.
NTContinuum := structure double[] base double[] value string[] units string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
The number of values in a point must be derived as:
Nvals = len(value)/len(base)And the following invariant must be preserved:
len(units)-1 == NvalsFor points (Ai, Bi, Ci) for indices i = 1, 2, 3 the value array is:
[A1, B1, C1, A2, B2, C2, A3, B3, C3]NTHistogram is the EPICS V4 Normative Type used to encode the data and representation of a (1 dimensional) histogram. Specifically, it encapsulates frequency binned data.
For 2d histograms (i.e. both x and y observations are binned) and n-tuple data (e.g. land masses of different listed countries) see NTMatrix or NTTable.
NTHistogram := structure double[] ranges // The start and end points of each bin (short[] | int[] | long[]) value // The frequency count, or otherwise value, of each bin string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
One NTHistogram gives the information required to convey a histogram representation of some underlying observations. It does not convey the values of each of the observations themselves.
The number of bins is given by the length of the value array. ranges indicates the low value and high value of each bin. The range for bin(i) is given by ranges(i) to ranges(i+1). Specifically, since we want end points of both the first bin and last bin included, all bin intervals except the last one, MUST be right half open; from that bin's low value ranges(i) (included) to that bin's high value ranges(i+1) (excluded). The last bin MUST be fully open (low and high value included).
A log plot histogram (in which the independent variable x is binned on a log scale), would be communicated using a range array of decades (1.0E01, 1.0E02, 1.0E03 etc).
The array length of ranges MUST be the array length of value + 1.
NTAggregate is the EPICS V4 Normative Type to compactly convey data which combines several measurements or observation. NTAggregate gives simple summary statistic bib:agg about the central tendency and dispersion of a set of data points.
Use cases: for instance, an NTAggregate could be used to summarize the value of one beam position offset reading over some number of pulses (N). It also includes the time range of the sampled points, so it could be used for time domain rebasing. For instance, an FPGA sending data at 10KHz, and you want to display its output, but you don't want to display at the native rate. Also, it could be used for transmitting or storing compressed archive data.
NTAggregate doesn't cover the shape of a distribution so it only reasonably helps you do symmetrical distributions (no skewness or kurtosis), and it doesn't include any help for indicating the extent of dependency on another variable (correlation).
NTAggregate := structure double value // The center point of the observations, // nominally the mean. long N // Number of observations double dispersion :opt // Dispersion of observations; // nominally the Standard Deviation or RMS double first :opt // Initial observation value time_t firstTimeStamp :opt // Time of initial observation double last :opt // Final observation value time_t lastTimeStamp :opt // Time of final observation double max :opt // Highest value in the N observations double min :opt // Lowest value in the N observations string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
where:
One NTAggregate instance describes some number (given by N) of observations. If firstTimeStamp and lastTimeStamp are given, then the N observations MUST have been taken over the period of time specified. If first, last, max or min are given, they MUST refer to the actual values of the N observations being summarized.
The value field value computed by server agents may be the arithmetic mean of the observation data being summarized by this NTAggregate, but NTAggregate does not normatively define that. Other measures of mean (geometric, harmonic) may be assigned. Indeed other measures of central tendency may be used. The interpretation to give an instance of an NTAggregate SHOULD be conveyed in the descriptor.
Where dispersion is a measure of the standard deviation, which estimator of the standard deviation [1/N or 1/(N-1)] was used, is also not defined normatively.
NTUnion would be a Normative Type for interoperation of essentially any data structure, plus description, alarm and timestamp fields.
NTUnion := structure anyunion_t value string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt
NTScalarMultiChannel is an EPICS V4 Normative Type that aggregates an array of values from different EPICS Process Variable (PV) channel sources of the same scalar type into a single variable.
Use cases: In a particle accelerator, a single NTScalarMultiChannel might include the data of a number of Beam Position Monitors' X offset values, or of a number of quadrupoles' desired field values.
NTScalarMultiChannel := structure scalar_t[] value // The channel values string[] channelName // The channel names string descriptor :opt alarm_t alarm :opt time_t timeStamp :opt int[] severity :opt int[] status :opt string[] message :opt long[] secondsPastEpoch :opt int[] nanoseconds :opt int[] userTag :opt
where:
This Appendix describes the Normative Type Identifiers of the abstract data types defined by this document. These are the strings which identify the type carried by a structure. In the pvAccess binding (which is at present the only one implemented for EPICS V4), the type ID of the structure MUST carry one of these identifier strings. In doing so, the structure instance declares itself to conform to the corresponding definition carried in this specification document.
The syntax of the Normative Type identifier is:
namespacename/typename:versionnumber
The Normative Type Identifier "Namespace Name" part, is:
epics:nt
The Normative Type Identifier "Type Name" and version number parts corresponding to this draft of the Normative Types Document (this document), MUST be valued as following:
| Type Name | Version | Depends on | Short Description |
|---|---|---|---|
| NTScalar | 1.0 | (none) | A single scalar value. |
| NTScalarArray | 1.0 | (none) | An array of scalar values of some single type. |
| NTEnum | 1.0 | (none) | An enumeration list and a value of that enumeration. |
| NTMatrix | 1.0 | (none) | A real number matrix. |
| NTURI | 1.0 | (none) | A structure for encapsulating a Uniform Resource Identifier (URI). |
| NTNameValue | 1.0 | (none) | An array of scalar values where each element is named. |
| NTTable | 1.0 | (none) | A table of scalars, where each column may be of different scalar array type |
| NTAttribute | 1.0 | (none) | A key-value pair, with optional string tags, where the value is of any type. |
| NTMultiChannel | 1.0 | (none) | An array of PV names, their values, and metadata. |
| NTNDArray | 1.0 | NTAttribute 1.0 | A pixel and metadata type, designed to encode a frame of data from detectors and cameras. |
| NTContinuum | 1.0 | (none) | Expresses a sequence of data points in time or frequency domain. |
| NTHistogram | 1.0 | (none) | An array of real number intervals, and their frequency counts. Expresses a 1D histogram. |
| NTAggregate | 1.0 | (none) | A mean value, standard deviation, and other metadata. Expresses the central tendency and dispersion of a set of data points. |
For example, the type ID of a structure describing an NTScalar, must be valued "epics:nt/NTScalar:1.0". The type ID of a structure describing an NTNDArray, must be valued "epics:nt/NTNDArray:1.0".
Following drafts of this document MAY well correspond to the same Namespace Name and Type Names as used in this draft. Also note that the same namespace may well be used for a different collection of types or Type Names, as this document matures.


--- layout: page gh-repo: JuanFMontesinos/y-net gh-badge: [star, watch, fork, follow] share-description: Official website of A cappella: Audio-visual Singing Voice Separation ---
The task of isolating a target singing voice in music videos has useful applications. In this work, we explore the single-channel singing voice separation problem from a multimodal perspective, by jointly learning from audio and visual modalities. To do so, we present Acappella, a dataset spanning around 46 hours of a cappella solo singing videos sourced from YouTube. We also propose an audio-visual convolutional network based on graphs which achieves state-of-the-art singing voice separation results on our dataset and compare it against its audio-only counterpart, U-Net, and a state-of-the-art audiovisual speech separation model. We evaluate the models in the following challenging setups: i) presence of overlapping voices in the audio mixtures, ii) the target voice set to lower volume levels in the mix, and iii) combination of i) and ii). The third one being the most challenging evaluation setup. We demonstrate that our model outperforms the baseline models in the singing voice separation task in the most challenging evaluation setup. The code, the pre-trained models, and the dataset are publicly available at https://ipcv.github.io/Acappella/
These authors contributed equally to this work.
@inproceedings{montesinos2021cappella, title={A cappella: Audio-visual Singing Voice Separation}, author={Montesinos, Juan F and Kadandale, Venkatesh S and Haro, Gloria}, booktitle={32nd British Machine Vision Conference, BMVC 2021}, year={2021} }
The authors acknowledge support by MICINN/FEDER UE project, ref. PGC2018-098625-B-I00; H2020-MSCA-RISE-2017 project, ref. 777826 NoMADS; ReAViPeRo network, ref. RED2018-102511-T; and Spanish Ministry of Economy and Competitiveness under the María de Maeztu Units of Excellence Program (MDM-2015-0502) and the Social European Funds. J. F. M. acknowledges support by FPI scholarship PRE2018-083920. V. S. K. has received financial support through “la Caixa” Foundation (ID 100010434), fellowship code: LCF/BQ/DI18/11660064. V.S.K has also received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie SkłodowskaCurie grant agreement No. 713673. We gratefully acknowledge NVIDIA Corporation for the donation of GPUs used for the experiments. We thank Emilia Gómez and Olga Slizovskaia for insightful discussions on the subject.


Landing Page
Special Projects
This story is part of a series of specially designed stories that represents some of the best journalism The Post has to offer. Check out the rest of the special projects here.
Kelsey Boeing
10/18/2018
While spending the usual Saturday night out on the town, watching students slur their words, dance on tables and make general fools of themselves, it is easy to forget the rich history that lies within the sticky floorboards of Athens’ bars.
Many bars on Court Street have been around for decades, but of all of them, The CI has been open the longest, according to records at the Southeast Ohio History Center.
Originally referred to by its full name, the College Inn, the CI was founded by Steve G. Tatalos in 1917, making the bar just over 100 years old. The dainty old college bar has seen more history than the majority of people living today.
“They would have seen a lot of changes,” Jessica Cyders, curator and assistant director of the Southeast Ohio History Center, said. “They would have seen things like the end of Prohibition, the Great Depression, the changes of the 1960s and ‘70s and a lot of changes at OU.”
The CI in 1979. (Provided via Phil Zarney)
Tatalos opened his restaurant-bar one year after moving to Athens from Turkey. He was 16 years old.
“In the 1940s, actually earlier than that, you see a lot of Greek families coming in to Athens and a lot of them owned restaurants,” Cyders said.
Given that Turkey is so close to Greece, Cyders believes Tatalos was part of a larger migration of Southeastern Europeans who moved to Athens in the early 1900s.
Tatalos owned and operated the College Inn for 50 years. He died on Dec. 18, 1969, two years after his retirement.
After a change in several owners, the College Inn was shortened to The CI in the 1960s. At about the same time, many fires were happening on Court Street, a darker side of Athens’ history.
“Athens saw a lot of fires uptown, especially in the ‘60s and ‘70s,” said Cyders. “But The CI is one of the only bars that — knock on wood — has not had a major fire.”
Those fires throughout the ‘60s and ‘70s were mostly due to faulty wiring throughout the older buildings on Court Street. The building The CI is in has been around since the 1820s, but it did not fall victim to old wiring.
The CI’s owner, Don Pepper, started working at the bar in 1976, while he studied organizational communication at Ohio University.
“I started as a bar back in 1976, started running it in 1979, bought it in 1979,” Pepper said.
Pepper enjoys the history behind his bar and likes its “rustic appeal.” Although he does not know what The CI was like back in the early 1900s, he said that not much has changed about the bar since he started working there in 1976.
“It was more mellow back in the day, but kids are more motivated now,” he said.
Pepper also mentioned that the type of alcohol he sold at the bar has changed since he first bought the bar. He said that when he first started, approximately 85 percent of what he sold was beer and 15 percent were drinks with liquor. Nowadays, approximately 20 percent of what he sells is beer and 80 percent of what he sells are drinks with liquor.
“That is really amazing that The CI has been open so long,” CI patron Joana Rittmayer said. “It’s amazing to think while standing in the bar buzzing with conversation that the same thing has been happening for decades.”
Landing Page
This story is part of a series of specially designed stories that represents some of the best journalism The Post has to offer. Check out the rest of the special projects here.


Robust estimation of Gaussian mixture models fitted by modified EM algorithm, robust clustering and classification.
| Version: | 1.0 |
| Depends: | mclust, mvtnorm |
| Published: | 2015-04-16 |
| Author: | Yichen Qin, Carey E. Priebe |
| Maintainer: | Yichen Qin <qinyn at ucmail.uc.edu> |
| License: | GPL-2 |
| URL: | http://homepages.uc.edu/~qinyn/qclust/ |
| NeedsCompilation: | no |
| In views: | Robust |
| CRAN checks: | qclust results |
| Reference manual: | qclust.pdf |
| Package source: | qclust_1.0.tar.gz |
| Windows binaries: | r-devel: qclust_1.0.zip, r-release: qclust_1.0.zip, r-oldrel: qclust_1.0.zip |
| OS X binaries: | r-release: qclust_1.0.tgz, r-oldrel: qclust_1.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=qclust to link to this page.


**BARC0130 AMMA Coursework 2: Fourier Series I & II**
**Fourier Series models of real world periodic processes**
*Deadline: Hardcopy submission @ 1000 on Monday, 29 October 2018*
*Please remember that coursework submission deadlines are strict. Late submissions will be penalised.*
# General definition for an arbitrary period $T$
The function, $f(t)$, can be expressed by its Fourier Series, $F(t)$ , at those points where $f(t)$ is continuous, if:
- it is a periodic function such that $f(t+T)=f(t)$, where $T$ is the period
- it defined and it is single-valued
- it is piecewise continuous (i.e. there are a finite number of finite discontinuities) over a single period
If these properties, the **Dirichlet conditions**, are satisfied, the Fourier Series of the function is:
\begin{equation}
f(t) = \frac{a_0}{2} + \sum\limits_{n=1}^\infty{a_n\cos(n \omega t)} + \sum\limits_{n=1}^\infty{b_n\sin(n \omega t)}
\end{equation}
where $\omega = \frac{2 \pi}{T}$ and the coefficients of $F(t)$ are:
\begin{equation}
a_0 = \frac{2}{T}\int_{0}^{T}{f(t)dt}
\end{equation}
\begin{equation}
a_n = \frac{2}{T}\int_{0}^{T}{f(t)\cos(n \omega t)dt}
\end{equation}
\begin{equation}
b_n = \frac{2}{T}\int_{0}^{T}{f(t)\sin(n \omega t)dt}
\end{equation}
# Question
Consider the number of people onsite at UCL Here East at any given time, $t$, to be a periodic variable, $f(t+T) = f(t)$, where the period, $T$, is 24 hours. The site is closed from 2200 to 1000 when there are only two members of security staff onsite. The doors open at 1000 at which point 12 eager students run straight into the building to work on their projects for 6 hours. Assume no one else goes in or out of the building during this time period. At 1600 some of the students begin to get tired and start leaving for home at a rate of 2 per hour until 2200, by which point all students have left and the security staff lock the doors, remaining inside.
- Sketch $f(t)$ over two full cycles.
- Write out the analytical expression for $f(t)$.
- Find the coefficients $a_0$, $a_n$ and $b_n$ of the Fourier Series of $f(t)$.
- Discuss the limitations of the model proposed in the question. In particular, consider our assumption that the number of people onsite at Here East can be represented by a variable with a repeat period of 24 hours and propose an enhanced model. You can do this using words, figures and equations.
## Guidance
There are a number of integrals to evaluate for this question. The integrals are very straightforward, but it will get messy and unduly complicated for you if you are not well organised. Think carefully about how you lay out your work on paper. If you have any questions about the coursework question, you can ask for clarfications on the Moodle Student Forum. We will not respond to coursework related questions by email, as this risks being unfair to other students. Good luck!


Game's First Wave of Black Friday Deals Are Here
by Tom PritchardEvery retailer under the sun seemed to launch their Black Friday bargains last week, but what about GAME - the only high street retailer dedicated to video games? Its Black Friday subsite was suspiciously dead last week, but today things have changed a bit.
These deals are live now, and Game has promised that there will be new offers being added to its site every day this week. In other words, it might be the right time to try and save yourself money on a new Nintendo Switch, PS4, or some other things game sells. Does Game still sell Pop Vinyls? Maybe those will be on sale too [Don't buy those - Ed].
Here's the best of what's been discounted so far:
PS4
- £50 off PS4 Pro with FIFA 20 + Now TV - was £350, now £300
- £51 off PS4 Pro with COD Modern Warfare + Now TV - was £350, now £299
- Save £49 on PS4 Pro Death Stranding Limited Edition - was £379, now £329.99
Nintendo Switch
- £10 off Nintendo Switch Lite - now £189.99
- £10 off Nintendo Switch Lite with Mario and Rabbids or LEGO Jurassic World - now £205
- £10 off Nintendo Switch Lite + Pokemon Sword/Shield or Luigi’s Mansion or Mario Kart 8 - now £229.99
- £44 off Nintendo Switch + LABO Variety or Robot kit - now £279.99
- £34 off Nintendo Switch + LABO Vehicle kit or Mario and Rabbids or Lego Jurassic World - now £289.99
- £10 off Nintendo Switch + Pokemon Sword/Shield or Luigi’s Mansion or Mario Kart 8 - now £309.99
Xbox One
- £151 off Xbox One X 1TB Hyperspace Special Edition Console + NOW TV - now £299
- £150 off 1TB Xbox One X Forza Horizon 4 LEGO® Speed Champions Bundle + McLarren Senna LEGO Toy + Now TV - now £299.99
- £151 off Xbox One X with Star Wars Jedi: Fallen Order Bundle + NOW TV - now £299
- £151 off One X with Gears 5 Limited Edition+ NOW TV - now £299.99
Of course that's just a selection of what's available, and there are plenty of deals to be had on consoles, games, and accessories. So make sure to head over to Game and see what's what, and check back tomorrow for anything new.


Warehouse Chief Klump:
Huh? Looks like you've run out of red gems. Too bad!


I am Dakota Cousineau and this is my website. There are many like it, but this one is mine.
here is a picture of Gambit and Rogue because they are cool
you know what else is cool? click on the Doctor and find out.
I really enjoy reading. Some of my favorite books series are the Dresden files and the Saxon Tales
If you can't tell from my page so far I am a nerd that grew up a jock
This is a short paragraph and here is a link ESPN
This one is going to open in a new window ESPN"
This one will send me an email E-mail me!
go team and


| Field | Description | Type | Format |
|---|---|---|---|
| api_id | API ID | number | 10.2 |
| attribute_id | Attribute ID | number | 10.2 |
| bus_glossary_admin_status_cd | Business Glossary Administrative Status | string | |
| bus_glossary_background_txt | Business Glossary Background | string | |
| bus_glossary_bureau_nm | Business Glossary Bureau | string | |
| bus_glossary_abbrev | Business Glossary Business Term Abbreviation | string | |
| bus_glossary_definition | Business Glossary Definition | string | |
| bus_glossary_desc | Business Glossary Description | string | |
| bus_glossary_html_src_ref_url | Business Glossary HTML Source Reference URL | string | |
| bus_glossary_see_also_txt | Business Glossary See Also | string | |
| bus_glossary_source_txt | Business Glossary Source | string | |
| bus_glossary_src_doc_page | Business Glossary Source Document Page Number | string | |
| bus_glossary_src_doc_section | Business Glossary Source Document Section | string | |
| bus_glossary_term | Business Glossary Term Category | string | |
| bus_glossary_term_category | Business Glossary Term Category | string | |
| bus_glossary_term_dt | Business Glossary Term Date | date | YYYY-MM-DD |
| business_line_cd | Business Line | string | |
| context_name | Context Name | string | |
| report_pretty_nm | Report Pretty Name | string | |
| bus_glossary_id | Treasury Offset Program | number | 10.2 |


EPIC PIZZA
Place An Order
Prices:
Base / Per Topping
Small 11"
$10.00 / $2.50
Medium 13"
$15.00 / $2.75
Large 17"
$20.00 / $3.00
Choose Size
Small
Medium
Large
Choose Toppings
Meats
Pepperoni
Italian Sausage
Canadian Bacon
Salami
Chicken Sausage
Veggies
Onions
Mushrooms
Green Peppers
Olives
Pineapple
Garlic
Place Your Order
RECEIPT
Your pizza will cost: $
.


| Class | Spec::Rails::DSL::HelperBehaviour |
| In: |
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
|
| Parent: | Spec::DSL::Behaviour |
Helper Specs live in $RAILS_ROOT/spec/helpers/.
Helper Specs use Spec::Rails::DSL::HelperBehaviour, which allows you to include your Helper directly in the context and write specs directly against its methods.
HelperBehaviour also includes the standard lot of ActionView::Helpers in case your helpers rely on any of those.
class ThingHelper def number_of_things Thing.count end end describe "ThingHelper behaviour" do include ThingHelper it "should tell you the number of things" do Thing.should_receive(:count).and_return(37) number_of_things.should == 37 end end


:: com :: sun :: star :: drawing ::
|
| unpublished |
service CustomShape |
|
|
- Usage Restrictions
- not published
- Description
- This service is for a CustomShape
|
| Included Services - Summary |
| Shape |
- (referenced entity's summary:)
- This abstract service specifies the general characteristics of all
Shapes.
|
| FillProperties |
- (referenced entity's summary:)
- This is a set of properties to describe the style for rendering an area.
|
| LineProperties |
- (referenced entity's summary:)
- This is a set of properties to describe the style for rendering a Line.
|
| ShadowProperties |
- (referenced entity's summary:)
- This is a set of properties to describe the style for rendering a shadow.
|
| Text |
- (referenced entity's summary:)
- This abstract service specifies the general characteristics of an optional
text inside a Shape.
|
| RotationDescriptor |
- (referenced entity's summary:)
- This abstract service specifies the general characteristics of an optional
rotation and shearing for a Shape.
This service is depricated, instead please use the
Transformation
property of the service Shape.
|
| Properties' Summary |
string
CustomShapeEngine |
This property contains the CustomShapeEngine service name that has to
be used for rendering.
|
string
CustomShapeData |
[ OPTIONAL ]
This property can be used to store data that the CustomShapeEngine may
use for rendering
|
sequence< ::com::sun::star::beans::PropertyValue >
CustomShapeGeometry |
[ OPTIONAL ]
This property describes the geometry of the CustomShape. The CustomShapeEngine
that is used should be able to get on with the content of this property.
If the CustomShapeEngine property is "com.sun.star.drawing.EnhancedCustomShapeEngine",
then this property is containing properties as they are specified in the service
com.sun.star.drawing.EnhancedCustomShapeGeometry
|
string
CustomShapeReplacementURL |
[ OPTIONAL ]
This property describes the URL to a replacement graphic that could
be displayed if the CustomShape engine is not available.
|
| Included Services - Details |
Shape
- (referenced entity's summary:)
- This abstract service specifies the general characteristics of all
Shapes.
|
|
FillProperties
- (referenced entity's summary:)
- This is a set of properties to describe the style for rendering an area.
|
|
LineProperties
- (referenced entity's summary:)
- This is a set of properties to describe the style for rendering a Line.
|
|
ShadowProperties
- (referenced entity's summary:)
- This is a set of properties to describe the style for rendering a shadow.
|
|
Text
- (referenced entity's summary:)
- This abstract service specifies the general characteristics of an optional
text inside a Shape.
|
|
RotationDescriptor
- (referenced entity's summary:)
- This abstract service specifies the general characteristics of an optional
rotation and shearing for a Shape.
This service is depricated, instead please use the
Transformation
property of the service Shape.
|
|
| Properties' Details |
CustomShapeEngine
string CustomShapeEngine;
- Description
- This property contains the CustomShapeEngine service name that has to
be used for rendering.
|
|
CustomShapeData
string CustomShapeData;
- Usage Restrictions
- optional
- Description
- This property can be used to store data that the CustomShapeEngine may
use for rendering
|
|
CustomShapeGeometry
sequence< ::com::sun::star::beans::PropertyValue > CustomShapeGeometry;
- Usage Restrictions
- optional
- Description
- This property describes the geometry of the CustomShape. The CustomShapeEngine
that is used should be able to get on with the content of this property.
If the CustomShapeEngine property is "com.sun.star.drawing.EnhancedCustomShapeEngine",
then this property is containing properties as they are specified in the service
com.sun.star.drawing.EnhancedCustomShapeGeometry
|
|
CustomShapeReplacementURL
string CustomShapeReplacementURL;
- Usage Restrictions
- optional
- Description
- This property describes the URL to a replacement graphic that could
be displayed if the CustomShape engine is not available.
|
|
Top of Page
Copyright © 2013, The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Apache, the Apache feather logo, Apache OpenOffice and OpenOffice.org are trademarks of The Apache Software Foundation. Other names may be trademarks of their respective owners.


CrowdLogger Remote Module (CLRM)
User API Demo
Live interaction events
Recent Searches
Display recent searches!


The following text is rendered using Tangerine font.
Web Font is Beautiful.
These icons are from Font Awesome.


{% extends "layout.html" %} {% set active_page = 'vote' %} {% block body %}
Thank you. Your vote has been registered.


--- layout: default --- Photo Credit: thomas shellberg
Hello!
This site (perhaps obviously) is still a work-in-progress, so check back later (in a couple months?). I have quite a number of todos, including:
A bit about me: These days, I'm both a high school STEM teacher and a part-time researcher. I graduated from MIT with a B.S. in Physics in 2018, and am currently enrolled in a M.Ed. program at Woodrow Wilson Graduate School in Cambridge. I taught in Boston Public Schools for two years as a student teacher, completed the Scheller Teacher Education Program at MIT, and worked in informal learning spaces & educational summer programs since 2014.
I am interested in metacognition and ultimately helping learners to both achieve their goals & become their best selves. I began my higher education believing I would go into astrophysics, but officially transitioned from the physical sciences to secondary education in my undergraduate senior year. A generalist at heart, I have studied linguistics, earth sciences, astronomy, literature, biology, and behavioral sciences; that said, my enduring passion has been & continues to be learning about learning.
Laughter and tears are both responses to frustration and exhaustion. I myself prefer to laugh, since there is less cleaning do to do afterward.


Spotter is a JSONP polling library designed for browser-based real-time applications and mashups. It lets you easily add twitter (and other) JSON feeds to simple client-side web pages.
See the examples for more detailed code, but -- seriously -- this is all that's necessary:
//create your spotter var s = new Spotter("twitter.search",{q:"Justin Bieber"}); //register your observer s.register(function(tweets) { alert(tweets[0].text); //alert the first returned tweet }); //start BieberSpotting! s.start();
That's all there is to it!


Ruby Hashes vs. JavaScript Objects
Similarities and differences between Ruby and JavaScript
14 February 2016
As you progress to JavaScript from Ruby, you would probably realize that both languages actually share quite a bit of similarities. As long as you practice with the JavaScript syntax, you can actually apply the same logic from Ruby in JavaScript. In this post I will talk about one of the major differences between Ruby and JavaScript - Ruby Hashes vs. JavaScript Objects
Ruby hashes
In Ruby, you define a hash in this way:
athlete = { height: 180, weight: 90, sport: basketball}
And you access different values like this:
athlete[:height] #=> 190
athlete[:weight] #=> 90
athlete[:sport] #=> "basketball"
In Ruby hashes declaration, we need to define both hash keys and the corresponding hash values. In the above example we use symbol as the data type of hash keys.
JavaScript Objects
In JavaScript, instead of using a hash, we create an object like this:
var athlete = { height: 180, weight: 90, sport: basketball};
And you access different values of the properties like this:
athlete.height / athlete["height"] #=> 190
athlete.weight / athlete["weight"] #=> 90
athlete.sport / athlete["sport"] #=> "basketball"
As you may notice I have mentioned the word "property". Yes, in JavaScript everything is an object, and you can assign properties to different objects. In this case, instead of understanding it as a hash, we should rather say that we created an object called "athlete", which has 3 properties: "height", "weight" and "sport".


Front-end, Back-end, Designer, Do-er
Hi! My name is Nicholas Summers and I want to become a top web developer. My goal is to learn and know how to do just about everything when it comes to the web. No small aspirations here.


{% extends 'contents/_base.html' %}
{% load i18n %}
{% block title %}Sponsor{% endblock title %}
{% block body_class %}scroll-x{% endblock %}
{% block content %}
Sponsorship Prospectus
Contact<EMAIL_ADDRESS>to Sponsorship Team of PyCon Taiwan 2020
PyCon Taiwan 2020 Chair, Chun-Yu Tseng
PyCon Taiwan 2020 Program Chair, Wei Lee
PyCon Taiwan 2020 Sponsorship Director, You-Hao Chang
PyCon Taiwan is the largest annual gathering for the community using and developing the open-source Python programming language in Taiwan.
"PyCon Taiwan" is a trademark authorized according to "PSF PyCon Trademark Usage Policy", and is organized by the Taiwan Python community and Open Culture Foundation (OCF, GUI 38552170) for growing the local community.
PyCon Taiwan continues to connect with new community members locally, nationally, and globally.
Your sponsorship keeps PyCon Taiwan affordable and accessible to the widest potential audience. Having your support, we are able to provide financial aid to needed attendences.
We have several sponsor packages including but not limited to the list below:
We are eager to hear from you! Only you know your business and what your are looking for the best. We do provide cutomized sponsor packages and are more than willing to take your suggestions into build suitable packages.
Estimated attendance: 400+ (The first PyCon Taiwan in southern Taiwan!)
Quick stats from 2019:
Conference Schedule (Taiwan timezone (UTC+8) if not specified)
Sponsor Packages
| Diamond | Platinum | Golden | Silver | Bronze | |
|---|---|---|---|---|---|
| Speaker Banquets / Person | 200 | 200 | 200 | 200 | 200 |
| Luxury Booth (Limit: 2) | Included | Included | Included | 1,300 | - |
| Talks (30 Mins.) (Limit: 1 Per Community Track) |
Included | Included | 500 | - | - |
| Social Media / Post | 200 | 300 | 300 | 500 | 600 |
| Advertisement (APP and Website) |
Included | Included | Included | 1,700 | 1,700 |
| Ticket Discount | 10 % off 10% off at any quantity |
10 % off If more than 10 tickets |
10 % off If more than 20 tickets |
10 % off If more than 30 tickets |
10 % off If more than 40 tickets |


My research focuses on industrial organization and technological change. More specifically, my research investigates the impacts of consumer data collection (pricing strategies, market concentration), consumer countermeasures (ad blocking), distribution formats (digital distribution, pricing, and resale restrictions), and information disclosure / mechanism design (vehicle crashworthiness ratings).
Shiller 'at' brandeis 'dot' edu


VISION
The vision of ITC-Africa is to serve as the clearinghouse, marketplace and forum for countries and African nationals, people of African heritage and Africa’s partners to discuss, exchange ideas, monitor and evaluate the continent’s efforts and progress in innovation and technology..
MISSION
The mission of ITC-Africa is to promote, secure and sustain Africa’s progress in innovation, technology and socio-economic development.
CORE VALUES
At ITC-Africa, we believe in the and practice the following core values:
Apolitical : We do not engage in politics and are not a political organization or institution
Communication : We are focused on promoting and elevating Africa’s role and place in innovation and technology by ensuring that all citizens are connected and informed.
Integrity : We uphold professionalism and maintain a culture of respect self and for all.
Collaboration : We believe in and practice vigorous teamwork.
Creativity: We are place a premium on thinking outside the box. Identifying challenges and matching those with solutions are cornerstones of our mandate.


Fence Repair
问题描述 :
Farmer John wants to repair a small length of the fence around the pasture. He measures the fence and finds that he needs N (1 ≤ N ≤ 20,000) planks of wood, each having some integer length Li (1 ≤ Li ≤ 50,000) units. He then purchases a single long board just long enough to saw into the N planks (i.e., whose length is the sum of the lengths Li).
FJ sadly realizes that he doesn’t own a saw with which to cut the wood, so he mosies over to Farmer Don’s Farm with this long board and politely asks if he may borrow a saw.
Farmer Don, a closet capitalist, doesn’t lend FJ a saw but instead offers to charge Farmer John for each of the N-1 cuts in the plank. The charge to cut a piece of wood is exactly equal to its length. Cutting a plank of length 21 costs 21 cents.
Farmer Don then lets Farmer John decide the order and locations to cut the plank. Help Farmer John determine the minimum amount of money he can spend to create the N planks. FJ knows that he can cut the board in various different orders which will result in different charges since the resulting intermediate planks are of different lengths.
输入:
Lines 2..N+1: Each line contains a single integer describing the length of a needed plank
输出:
样例输入:
3 8 5 8
样例输出:
34
温馨提示:
The original board measures 8+5+8=21. The first cut will cost 21, and should be used to cut the board into pieces measuring 13 and 8. The second cut will cost 13, and should be used to cut the 13 into 8 and 5. This would cost 21+13=34. If the 21 was cut into 16 and 5 instead, the second cut would cost 16 for a total of 37 (which is more than 34).
解题代码:
import java.util.Arrays; import java.util.Scanner; public class Main { public static void main(String[] args) { Scanner sc = new Scanner(System.in); int n = sc.nextInt(); int[] nodes = new int[n]; for (int i = 0; i < n; i++) { nodes[i] = sc.nextInt(); } if (n == 1) System.out.println(nodes[0]); else System.out.println(get(nodes)); } private static long get(int[] nodes) { long sum = 0; int len = nodes.length; Arrays.sort(nodes); for (int i = 0; i < len - 1; i++) { sum += nodes[i] + nodes[i + 1]; nodes[i + 1] = nodes[i] + nodes[i + 1]; // System.out.println(nodes[i+1]); for (int j = i + 1; j < len - 1; j++) { if (nodes[j] > nodes[j + 1]) { int temp = nodes[j]; nodes[j] = nodes[j + 1]; nodes[j + 1] = temp; } else { break; } } } return sum; } }
惊艳了，没想到代码如此简洁
还真是，i7的cpu跑了3秒
多谢提醒。代码又编辑了一下
第二块代码if(it != mp.end())应改为if(it != mp.end() && (i+1)!=(it->second +1))；因为第二种解法如果数组有重复元素 就不正确
学习了
分析的很专业！
根本过不了。。。。
我表示楼主不要乱抄题，你写的另一个题吧，直接扒了代码没跑吧
正确性是关键，冲突是都会有的，主要是那种算法冲突的概率低
很好的题，还是能做出几道的，嘿嘿
[…] 如果此题没有要求 相对位置不变，可以参考文章：http://www.acmerblog.com/interview-9-2427/ […]
第一段代码中：
next = next ;
明显不对吧，应该是 next =j;才对


Cloud Poll
Cloud Poll
Create an account to create and modify your polls!
Sign Up
Name / Display Name:
Email:
(optional)
Password:
Confirm Password:
Sign Up


View Source
Class TypeTable
The repository which determines the order in which selectors are picked for any given type
Inheritance
System.Object
TypeTable
Namespace:Faker
Assembly:Faker.dll
Syntax
public sealed class TypeTable
Constructors
View Source
TypeTable(Boolean)
Declaration
public TypeTable(bool useDefaults = true)
Parameters
| Type |
Name |
Description |
| System.Boolean |
useDefaults |
|
Methods
View Source
AddSelector(ITypeSelector, SelectorPosition)
Add a strongly typed selector to the
Declaration
public void AddSelector(ITypeSelector selector, SelectorPosition position = SelectorPosition.First)
Parameters
| Type |
Name |
Description |
| ITypeSelector |
selector |
A ITypeSelector implementation for Type T
|
| SelectorPosition |
position |
Optional parameter - indicates whether you want this type selector to be used first or last in
the sequence of available selectors for this type
|
View Source
AddSelector<T>(TypeSelectorBase<T>, SelectorPosition)
Add a strongly typed selector to the
Declaration
public void AddSelector<T>(TypeSelectorBase<T> selector, SelectorPosition position = SelectorPosition.First)
Parameters
| Type |
Name |
Description |
| TypeSelectorBase<T> |
selector |
A TypeSelectorBase implementation for Type T
|
| SelectorPosition |
position |
Optional parameter - indicates whether you want this type selector to be used first or last in
the sequence of available selectors for this type
|
Type Parameters
| Name |
Description |
| T |
The type for which this selector is used |
View Source
ClearSelectors<T>()
Remove all of the selectors for a given type
Declaration
public void ClearSelectors<T>()
Type Parameters
| Name |
Description |
| T |
The type for which we want to clear all of the selectors |
View Source
Clone()
Clone a deep copy of TypeTable with the same settings as this instance.
Any modifications made to the new instance returned should not affect the parent instance.
Declaration
Returns
View Source
CountSelectors(Type)
Count all of the selectors for a given type
Declaration
public int CountSelectors(Type t)
Parameters
| Type |
Name |
Description |
| System.Type |
t |
A type object for which we want to know the number of available selectors
|
Returns
| Type |
Description |
| System.Int32 |
The number of selectors we have available for this type
|
View Source
CountSelectors<T>()
Count all of the selectors for a given type
Declaration
public int CountSelectors<T>()
Returns
| Type |
Description |
| System.Int32 |
The number of selectors we have available for this type
|
Type Parameters
| Name |
Description |
| T |
The type for which we need value selectors |
View Source
GetBaseSelector(Type)
Gets the base selector for a given datatype
Declaration
public ITypeSelector GetBaseSelector(Type t)
Parameters
| Type |
Name |
Description |
| System.Type |
t |
The type that we need to inject
|
Returns
| Type |
Description |
| ITypeSelector |
A matching selector, null otherwise
|
View Source
GetSelectors(Type)
Get all of the selectors for a given type
Declaration
public IEnumerable<ITypeSelector> GetSelectors(Type t)
Parameters
| Type |
Name |
Description |
| System.Type |
t |
|
Returns
| Type |
Description |
| System.Collections.Generic.IEnumerable<ITypeSelector> |
An enumerable list of selectors
|
View Source
GetSelectors<T>()
Get all of the selectors for a given type
Declaration
public IEnumerable<TypeSelectorBase<T>> GetSelectors<T>()
Returns
| Type |
Description |
| System.Collections.Generic.IEnumerable<TypeSelectorBase<T>> |
An enumerable list of selectors
|
Type Parameters
| Name |
Description |
| T |
The type for which we need value selectors |


If not blank, will deploy to this deployment slot instead of the default production slot.
See this article for more details.


Your browser's JavaScript is disabled or may not support scripting. Please
turn it on
or
Download a modern browser
that supports scripting otherwise, this web app will not function
properly
.
Nearby branches


Heatmap
Using Excel to illustrate whether the country is in the safe region, i.e. blue region, or in the “caution” region, i.e. red region.
For example, Purchasing Managers Index (PMI) measures the economic health of the private sector companies. PMI above 50 means expanding and below 50 means contracting. Thus, countries with PMI greater than 50 are in the safe region, i.e. blue region
Excel skills
- Conditional formatting
- Formulas such as sumproduct, sumifs, averageifs, vlookup, and aggregate calculation