This defines the observation of the index used to obtain the FX reset rate.
An FX index is a daily rate of exchange between two currencies. Note that the order of the currencies in the index does not matter, as the conversion direction is fully defined by the currency of the reference amount.
DayCount dayCount
This is used to convert dates to a numerical value.
When building, this will default to the day count of the index if not specified.
IborIndex index
The rate to be paid is based on this index It will be a well known market index such as 'GBP-LIBOR-3M'.
ResetSchedule resetPeriods
Most swaps have a single fixing for each accrual period. This property allows multiple fixings to be defined by dividing the accrual periods into reset periods.
If this property is not present, then the reset period is the same as the accrual period. If this property is present, then the accrual period is divided as per the information in the reset schedule, multiple fixing dates are calculated, and rate averaging performed.
FixingRelativeTo fixingRelativeTo
The fixing date is relative to either the start or end of each reset period.
Note that in most cases, the reset frequency matches the accrual frequency and thus there is only one fixing for the accrual period.
DaysAdjustment fixingDateOffset
The offset is applied to the base date specified by fixingRelativeTo
.
The offset is typically a negative number of business days.
Note that in most cases, the reset frequency matches the accrual frequency and thus there is only one fixing for the accrual period.
When building, this will default to the fixing offset of the index if not specified.
NegativeRateMethod negativeRateMethod
This is used when the interest rate, observed or calculated, goes negative.
It does not apply if the rate is fixed, such as in a stub or using firstRegularRate
.
Defined by the 2006 ISDA definitions article 6.4.
Double firstRegularRate
In certain circumstances two counterparties agree the rate of the first fixing when the contract starts. The rate is applicable for the first reset period of the first regular accrual period. It is used in place of an observed fixing. Other calculation elements, such as gearing or spread, still apply. After the first reset period, the rate is observed via the normal fixing process.
If the first floating rate applies to the initial stub rather than the regular accrual periods
it must be specified using initialStub
.
If this property is not present, then the first rate is observed via the normal fixing process.
IborRateStubCalculation initialStub
The initial stub of a swap may have different rate rules to the regular accrual periods. A fixed rate may be specified, a different floating rate or a linearly interpolated floating rate. This may not be present if there is no initial stub, or if the index during the stub is the same as the main floating rate index.
If this property is not present, then the main index applies during any initial stub. If this property is present and there is no initial stub, it is ignored.
IborRateStubCalculation finalStub
The final stub of a swap may have different rate rules to the regular accrual periods. A fixed rate may be specified, a different floating rate or a linearly interpolated floating rate. This may not be present if there is no final stub, or if the index during the stub is the same as the main floating rate index.
If this property is not present, then the main index applies during any final stub. If this property is present and there is no final stub, it is ignored.
ValueSchedule gearing
This defines the gearing as an initial value and a list of adjustments. The gearing is only permitted to change at accrual period boundaries.
When calculating the rate, the fixing rate is multiplied by the gearing. A gearing of 1 has no effect. If both gearing and spread exist, then the gearing is applied first.
If this property is not present, then no gearing applies.
Gearing is also known as leverage.
ValueSchedule spread
This defines the spread as an initial value and a list of adjustments. The spread is only permitted to change at accrual period boundaries. Spread is a per annum rate.
When calculating the rate, the spread is added to the fixing rate. A spread of 0 has no effect. If both gearing and spread exist, then the gearing is applied first.
If this property is not present, then no spread applies.
Defined by the 2006 ISDA definitions article 6.2e.
Double fixedRate
In certain circumstances two counterparties agree a fixed rate for the stub. It is used in place of an observed fixing. Other calculation elements, such as gearing or spread, still apply.
If the fixed rate is present, then knownAmount
, index
and
indexInterpolated
must not be present.
CurrencyAmount knownAmount
If the known amount is present, then fixedRate
, index
and
indexInterpolated
must not be present.
IborIndex index
This will be used throughout the stub unless indexInterpolated
is present.
If the index is present, then fixedRate
and knownAmount
must not be present.
IborIndex indexInterpolated
This will be used with index
to linearly interpolate the rate.
This index may be shorter or longer than index
, but not the same.
If the interpolated index is present, then index
must also be present,
and fixedRate
and knownAmount
must not be present.
String name
boolean active
Over time some indices become inactive and are no longer produced. If this occurs, this flag will be set to false.
LocalTime fixingTime
ZoneId fixingZone
FixedIborSwapTemplate template
PriceIndex index
The pay-off is computed based on this index
The most common implementations are provided in PriceIndices
.
Period lag
A price index is typically published monthly and has a delay before publication. The lag is subtracted from the accrual start and end date to locate the month of the data to be observed.
For example, the September data may be published in October or November. A 3 month lag will cause an accrual date in December to be based on the observed data for September, which should be available by then.
PriceIndexCalculationMethod indexCalculationMethod
This specifies how the reference index calculation occurs.
Double firstIndexValue
This optional field specifies the initial value of the index. The value is applicable for the first regular accrual period. It is used in place of an observed fixing. Other calculation elements, such as gearing or spread, still apply. After the first accrual period, the rate is observed via the normal fixing process.
The method InflationRateCalculation.createRateComputation(LocalDate)
allows this field to be used as the base for any end date, as typically seen
in capital indexed bonds.
If this property is not present, then the first value is observed via the normal fixing process.
ValueSchedule gearing
This defines the gearing as an initial value and a list of adjustments.
When calculating the index, the gearing acts as a overall factor of pay-off.
The pay-off is Gearing_Factor * (Index_End / Index_Start - 1)
.
A gearing of 1 has no effect.
If this property is not present, then no gearing applies.
Gearing is also known as leverage.
Payment payment
This includes the payment date and amount. If the schedule adjusts for business days, then the date is the adjusted date.
LocalDate startDate
This is the first date in the period. If the schedule adjusts for business days, then this is the adjusted date.
LocalDate endDate
This is the last date in the period. If the schedule adjusts for business days, then this is the adjusted date.
LocalDate unadjustedStartDate
The start date before any business day adjustment is applied.
When building, this will default to the start date if not specified.
LocalDate unadjustedEndDate
The end date before any business day adjustment is applied.
When building, this will default to the end date if not specified.
CurrencyAmount notionalAmount
The notional amount applicable during the period.
The currency of the notional is typically the same as currency
.
However, if FX reset applies, the currency will differ.
FxIndexObservation fxResetObservation
This property is used when the defined amount of the notional is specified in a currency other than the currency of the swap leg. When this occurs, the notional amount has to be converted using an FX rate to the swap leg currency.
The FX reset definition must be valid. The payment currency and the currency of the notional must differ, and the currency pair must be that of the observation.
Payment payment
This includes the payment date and amount. If the schedule adjusts for business days, then the date is the adjusted date.
LocalDate startDate
This is the first date in the period. If the schedule adjusts for business days, then this is the adjusted date.
LocalDate endDate
This is the last date in the period. If the schedule adjusts for business days, then this is the adjusted date.
LocalDate unadjustedStartDate
The start date before any business day adjustment is applied.
When building, this will default to the start date if not specified.
LocalDate unadjustedEndDate
The end date before any business day adjustment is applied.
When building, this will default to the end date if not specified.
PayReceive payReceive
A value of 'Pay' implies that the resulting amount is paid to the counterparty. A value of 'Receive' implies that the resulting amount is received from the counterparty. Note that negative interest rates can result in a payment in the opposite direction to that implied by this indicator.
PeriodicSchedule accrualSchedule
This is used to define the accrual periods. These are used directly or indirectly to determine other dates in the swap.
PaymentSchedule paymentSchedule
This is used to define the payment periods, including any compounding. The payment period dates are based on the accrual schedule.
ValueSchedule amount
This defines the schedule of known amounts, relative to the payment schedule. The schedule is defined as an initial amount, with optional changes during the tenor of the swap. The amount is only permitted to change at payment period boundaries.
Note that the date of the payment is implied by the payment schedule. Any dates in the known amount schedule refer to the payment schedule, not the payment date.
For example, consider a two year swap where each payment period is 3 months long.
This schedule could define two entries, one that defines the payment amounts as GBP 1000 for
the first year and one that defines the amount as GBP 500 for the second year.
In this case there will be eight payments in total, four payments of GBP 1000 in the first
year and four payments of GBP 500 in the second year.
Each payment will occur on the date specified using the offset in PaymentSchedule
.
Currency currency
This is the currency of the known payments.
LocalDate paymentDate
Each payment event has a single payment date. This date has been adjusted to be a valid business day.
CurrencyAmount paymentAmount
This is the amount of the notional exchange.
Currency currency
This is the currency of the swap leg and the currency that interest calculation is made in.
The amounts of the notional are usually expressed in terms of this currency,
however they can be converted from amounts in a different currency.
See the optional fxReset
property.
FxResetCalculation fxReset
This property is used when the defined amount of the notional is specified in a currency other than the currency of the swap leg. When this occurs, the notional amount has to be converted using an FX rate to the swap leg currency. This conversion occurs at each payment period boundary and usually corresponds to an actual exchange of money between the counterparties.
When building the notional schedule, if an FxResetCalculation
is present,
then the notional exchange flags will be set to true.
ValueSchedule amount
This defines the notional as an initial amount and a list of adjustments. The notional expressed here is intended to always be positive.
The notional is only allowed to change at payment period boundaries.
As such, the ValueSchedule
steps are defined relative to the payment schedule.
boolean initialExchange
Setting this to true indicates that the notional is transferred at the start of the trade. This should typically be set to true in the case of an FX reset swap, or one with a varying notional.
boolean intermediateExchange
Setting this to true indicates that the notional is transferred when it changes during the trade. This should typically be set to true in the case of an FX reset swap, or one with a varying notional.
boolean finalExchange
Setting this to true indicates that the notional is transferred at the end of the trade. This should typically be set to true in the case of an FX reset swap, or one with a varying notional.
DayCount dayCount
This is used to convert dates to a numerical value.
When building, this will default to the day count of the index if not specified.
OvernightIndex index
The rate to be paid is based on this index It will be a well known market index such as 'GBP-SONIA'.
OvernightAccrualMethod accrualMethod
Two methods of accrual are supported - compounding and averaging. Averaging is primarily related to the 'USD-FED-FUND' index.
NegativeRateMethod negativeRateMethod
This is used when the interest rate, observed or calculated, goes negative.
It does not apply if the rate is fixed, such as in a stub or using firstRegularRate
.
Defined by the 2006 ISDA definitions article 6.4.
int rateCutOffDays
When a rate cut-off applies, the final daily rate is determined this number of days before the end of the period, with any subsequent days having the same rate.
The amount must be zero or positive. A value of zero or one will have no effect on the standard calculation. The fixing holiday calendar of the index is used to determine business days.
For example, a value of 3
means that the rate observed on
(periodEndDate - 3 business days)
is also to be used on
(periodEndDate - 2 business days)
and (periodEndDate - 1 business day)
.
If there are multiple accrual periods in the payment period, then this will only apply to the last accrual period in the payment period.
ValueSchedule gearing
This defines the gearing as an initial value and a list of adjustments. The gearing is only permitted to change at accrual period boundaries.
When calculating the rate, the fixing rate is multiplied by the gearing. A gearing of 1 has no effect. If both gearing and spread exist, then the gearing is applied first.
If this property is not present, then no gearing applies.
Gearing is also known as leverage.
ValueSchedule spread
This defines the spread as an initial value and a list of adjustments. The spread is only permitted to change at accrual period boundaries. Spread is a per annum rate.
When calculating the rate, the spread is added to the fixing rate. A spread of 0 has no effect. If both gearing and spread exist, then the gearing is applied first.
If this property is not present, then no spread applies.
Defined by the 2006 ISDA definitions article 6.2e.
Frequency paymentFrequency
Regular payments will be made at the specified periodic frequency. The frequency must be the same as, or a multiple of, the accrual periodic frequency.
Compounding applies if the payment frequency does not equal the accrual frequency.
BusinessDayAdjustment businessDayAdjustment
Each date in the calculated schedule is determined relative to the accrual schedule. Normally, the accrual schedule is adjusted ensuring each date is not a holiday. As such, there is typically no reason to adjust the date before applying the payment date offset.
If the accrual dates are unadjusted, or for some other reason, it may be desirable to adjust the schedule dates before applying the payment date offset. This optional property allows that to happen. Note that the payment date offset itself provides the ability to adjust dates after the offset is applied.
PaymentRelativeTo paymentRelativeTo
The payment date is relative to either the start or end of the payment period.
DaysAdjustment paymentDateOffset
The offset is applied to the unadjusted date specified by paymentRelativeTo
.
Offset can be based on calendar days or business days.
CompoundingMethod compoundingMethod
Compounding is used when combining accrual periods.
LocalDate startDate
This is the first accrual date in the period. If the schedule adjusts for business days, then this is the adjusted date.
LocalDate endDate
This is the last accrual date in the period. If the schedule adjusts for business days, then this is the adjusted date.
LocalDate unadjustedStartDate
The start date before any business day adjustment is applied.
When building, this will default to the start date if not specified.
LocalDate unadjustedEndDate
The end date before any business day adjustment is applied.
When building, this will default to the end date if not specified.
double yearFraction
The value is usually calculated using a DayCount
which may be different to that of the index.
Typically the value will be close to 1 for one year and close to 0.5 for six months.
The fraction may be greater than 1, but not less than 0.
RateComputation rateComputation
The value of the period is based on this rate.
Different implementations of the RateComputation
interface have different
approaches to computing the rate, including averaging, overnight and interpolation.
For example, it might be a well known market index such as 'GBP-LIBOR-3M'.
double gearing
This defines the gearing, which is used to multiply the observed rate.
When calculating the rate, the observed rate is multiplied by the gearing. If both gearing and spread exist, then the gearing is applied first. A gearing of 1 has no effect.
Gearing is also known as leverage.
double spread
This defines the spread, which is used to add an amount the observed rate.
When calculating the rate, the spread is added to the observed rate. If both gearing and spread exist, then the gearing is applied first. A spread of 0 has no effect.
Defined by the 2006 ISDA definitions article 6.2e.
NegativeRateMethod negativeRateMethod
This is used when the interest rate, observed or calculated, goes negative.
When observing or calculating the rate, the value may go negative. If it does, then this method is used to validate whether the negative rate is allowed. It is applied after any applicable gearing or spread.
Defined by the 2006 ISDA definitions article 6.4.
PayReceive payReceive
A value of 'Pay' implies that the resulting amount is paid to the counterparty. A value of 'Receive' implies that the resulting amount is received from the counterparty. Note that negative interest rates can result in a payment in the opposite direction to that implied by this indicator.
PeriodicSchedule accrualSchedule
This is used to define the accrual periods. These are used directly or indirectly to determine other dates in the swap.
PaymentSchedule paymentSchedule
This is used to define the payment periods, including any compounding. The payment period dates are based on the accrual schedule.
NotionalSchedule notionalSchedule
The notional amount schedule, which can vary during the lifetime of the swap. In most cases, the notional amount is not exchanged, with only the net difference being exchanged. However, in certain cases, initial, final or intermediate amounts are exchanged.
RateCalculation calculation
Different kinds of swap leg are determined by the subclass used here.
See FixedRateCalculation
, IborRateCalculation
and OvernightRateCalculation
.
LocalDate paymentDate
The date that payment is made for the accrual periods. If the schedule adjusts for business days, then this is the adjusted date.
ImmutableList<E> accrualPeriods
Each accrual period includes the applicable dates and details of how to observe the rate. In most cases, there will be one accrual period. If there is more than one accrual period then compounding may apply.
DayCount dayCount
Each accrual period contains a year fraction calculated using this day count. This day count is used when there is a need to perform further calculations.
Currency currency
This is the currency of the swap leg and the currency that interest calculation is made in.
The amounts of the notional are usually expressed in terms of this currency,
however they can be converted from amounts in a different currency.
See the optional fxReset
property.
FxReset fxReset
This property is used when the defined amount of the notional is specified in a currency other than the currency of the swap leg. When this occurs, the notional amount has to be converted using an FX rate to the swap leg currency.
The FX reset definition must be valid. It must have a reference currency that is different to that of this period, and the currency of this period must be one of those defined by the FX reset index.
double notional
The notional amount applicable during the period.
The currency of the notional is specified by currency
unless there
is the fxReset
property is present.
CompoundingMethod compoundingMethod
Compounding is used when combining accrual periods.
SwapLegType type
This provides a high level categorization of the swap leg.
PayReceive payReceive
A value of 'Pay' implies that the resulting amount is paid to the counterparty. A value of 'Receive' implies that the resulting amount is received from the counterparty. Note that negative interest rates can result in a payment in the opposite direction to that implied by this indicator.
The value of this flag should match the signs of the payment period notionals.
ImmutableList<E> paymentPeriods
Each payment period represents part of the life-time of the leg. In most cases, the periods do not overlap. However, since each payment period is essentially independent the data model allows overlapping periods.
The start date and end date of the leg are determined from the first and last period. As such, the periods should be sorted.
boolean initialExchange
Setting this to true indicates that the notional is transferred at the start of the trade. This should typically be set to true in the case of an FX reset swap, or one with a varying notional.
This flag controls whether a notional exchange object is created when the leg is resolved.
It covers an exchange on the initial payment date of the swap leg, treated as the start date.
If there is an FX reset, then this flag is ignored, see intermediateExchange
.
If there is no FX reset and the flag is true, then a NotionalExchange
object will be created.
boolean intermediateExchange
Setting this to true indicates that the notional is transferred when it changes during the trade. This should typically be set to true in the case of an FX reset swap, or one with a varying notional.
This flag controls whether a notional exchange object is created when the leg is resolved.
It covers an exchange on each intermediate payment date of the swap leg.
If set to true, the behavior depends on whether an FX reset payment period is defined.
If there is an FX reset, then an FxResetNotionalExchange
object will be created.
If there is no FX reset, then a NotionalExchange
object will be created.
boolean finalExchange
Setting this to true indicates that the notional is transferred at the end of the trade. This should typically be set to true in the case of an FX reset swap, or one with a varying notional.
This flag controls whether a notional exchange object is created when the leg is resolved.
It covers an exchange on the final payment date of the swap leg.
If there is an FX reset, then this flag is ignored, see intermediateExchange
.
If there is no FX reset and the flag is true, then a NotionalExchange
object will be created.
ImmutableList<E> paymentEvents
Payment events include fees. Notional exchange may also be specified here instead of via the dedicated fields.
BusinessDayAdjustment paymentBusinessDayAdjustment
The business day adjustment is applied to period, exchange and event payment dates.
Currency currency
Frequency resetFrequency
Reset dates will be calculated within each accrual period based on unadjusted dates. The frequency must be the same as, or smaller than, the accrual periodic frequency. When calculating the reset dates, the roll convention of the accrual periods will be used. Once the unadjusted date calculation is complete, the business day adjustment specified here will be used.
Averaging applies if the reset frequency does not equal the accrual frequency.
BusinessDayAdjustment businessDayAdjustment
This adjustment is applied to each reset date to ensure it is a valid business day.
IborRateAveragingMethod averagingMethod
This is used when more than one fixing contributes to the accrual period.
Averaging may be weighted by the number of days that the fixing is applicable for. The number of days is based on the reset period, not the period between two fixing dates.
Defined by the 2006 ISDA definitions article 6.2a.
ImmutableList<E> legs
A swap consists of one or more legs. The legs of a swap are essentially unordered, however it is more efficient and closer to user expectation to treat them as being ordered.
ImmutableSet<E> currencies
ImmutableSet<E> indices
SwapLegType type
This provides a high level categorization of the swap leg.
PayReceive payReceive
A value of 'Pay' implies that the resulting amount is paid to the counterparty. A value of 'Receive' implies that the resulting amount is received from the counterparty. Note that negative interest rates can result in a payment in the opposite direction to that implied by this indicator.
The value of this flag should match the signs of the payment period notionals.
ImmutableList<E> paymentPeriods
Each payment period represents part of the life-time of the leg. In most cases, the periods do not overlap. However, since each payment period is essentially independent the data model allows overlapping periods.
The start date and end date of the leg are determined from the first and last period. As such, the periods should be sorted.
ImmutableList<E> paymentEvents
Payment events include notional exchange and fees.
Currency currency
TradeInfo info
This allows additional information to be attached to the trade.
ResolvedSwap product
The product captures the contracted financial details of the trade.
ImmutableList<E> legs
A swap consists of one or more legs. The legs of a swap are essentially unordered, however it is more efficient and closer to user expectation to treat them as being ordered.
Period periodToStart
This is often zero, but can be greater if the swap if forward starting. This must not be negative.
Tenor tenor
This is the period from the first accrual date to the last accrual date.
FixedIborSwapConvention convention
Tenor tenor
This is the period from the first accrual date to the last accrual date.
FixedInflationSwapConvention convention
Period periodToStart
This is often zero, but can be greater if the swap if forward starting. This must not be negative.
Tenor tenor
This is the period from the first accrual date to the last accrual date.
FixedOvernightSwapConvention convention
Currency currency
This is the currency of the swap leg and the currency that payment is made in.
DayCount dayCount
This is used to convert schedule period dates to a numerical value.
Frequency accrualFrequency
Interest will be accrued over periods at the specified periodic frequency, such as every 3 months.
BusinessDayAdjustment accrualBusinessDayAdjustment
Each date in the calculated schedule is determined without taking into account weekends and holidays. The adjustment specified here is used to convert those dates to valid business days.
The start date and end date may have their own business day adjustment rules. If those are not present, then this adjustment is used instead.
BusinessDayAdjustment startDateBusinessDayAdjustment
The start date property is an unadjusted date and as such might be a weekend or holiday. The adjustment specified here is used to convert the start date to a valid business day.
This will default to the accrualDatesBusinessDayAdjustment
if not specified.
BusinessDayAdjustment endDateBusinessDayAdjustment
The end date property is an unadjusted date and as such might be a weekend or holiday. The adjustment specified here is used to convert the end date to a valid business day.
This will default to the accrualDatesBusinessDayAdjustment
if not specified.
StubConvention stubConvention
The stub convention is used during schedule construction to determine whether the irregular remaining period occurs at the start or end of the schedule. It also determines whether the irregular period is shorter or longer than the regular period.
This will default to 'ShortInitial' if not specified.
RollConvention rollConvention
The schedule periods are determined at the high level by repeatedly adding the frequency to the start date, or subtracting it from the end date. The roll convention provides the detailed rule to adjust the day-of-month or day-of-week.
This will default to 'None' if not specified.
Frequency paymentFrequency
Regular payments will be made at the specified periodic frequency. The frequency must be the same as, or a multiple of, the accrual periodic frequency.
Compounding applies if the payment frequency does not equal the accrual frequency.
This will default to the accrual frequency if not specified.
DaysAdjustment paymentDateOffset
The offset is applied to the unadjusted date specified by paymentRelativeTo
.
Offset can be based on calendar days or business days.
This will default to 'None' if not specified.
CompoundingMethod compoundingMethod
Compounding is used when combining accrual periods.
This will default to 'None' if not specified.
Period periodToStart
This is often zero, but can be greater if the swap if forward starting. This must not be negative.
Tenor tenor
This is the period from the first accrual date to the last accrual date.
IborIborSwapConvention convention
IborIndex index
The floating rate to be paid is based on this index It will be a well known market index such as 'GBP-LIBOR-3M'.
Currency currency
This is the currency of the swap leg and the currency that payment is made in. The data model permits this currency to differ from that of the index, however the two are typically the same.
This will default to the currency of the index if not specified.
DayCount dayCount
This is used to convert dates to a numerical value. The data model permits the day count to differ from that of the index, however the two are typically the same.
This will default to the day count of the index if not specified.
Frequency accrualFrequency
Interest will be accrued over periods at the specified periodic frequency, such as every 3 months.
This will default to the tenor of the index if not specified.
BusinessDayAdjustment accrualBusinessDayAdjustment
Each date in the calculated schedule is determined without taking into account weekends and holidays. The adjustment specified here is used to convert those dates to valid business days.
The start date and end date may have their own business day adjustment rules. If those are not present, then this adjustment is used instead.
This will default to 'ModifiedFollowing' using the index fixing calendar if not specified.
BusinessDayAdjustment startDateBusinessDayAdjustment
The start date property is an unadjusted date and as such might be a weekend or holiday. The adjustment specified here is used to convert the start date to a valid business day.
This will default to the accrualDatesBusinessDayAdjustment
if not specified.
BusinessDayAdjustment endDateBusinessDayAdjustment
The end date property is an unadjusted date and as such might be a weekend or holiday. The adjustment specified here is used to convert the end date to a valid business day.
This will default to the accrualDatesBusinessDayAdjustment
if not specified.
StubConvention stubConvention
The stub convention is used during schedule construction to determine whether the irregular remaining period occurs at the start or end of the schedule. It also determines whether the irregular period is shorter or longer than the regular period.
This will default to 'ShortInitial' if not specified.
RollConvention rollConvention
The schedule periods are determined at the high level by repeatedly adding the frequency to the start date, or subtracting it from the end date. The roll convention provides the detailed rule to adjust the day-of-month or day-of-week.
This will default to 'None' if not specified.
FixingRelativeTo fixingRelativeTo
The fixing date is relative to either the start or end of each reset period.
Note that in most cases, the reset frequency matches the accrual frequency and thus there is only one fixing for the accrual period.
This will default to 'PeriodStart' if not specified.
DaysAdjustment fixingDateOffset
The offset is applied to the base date specified by fixingRelativeTo
.
The offset is typically a negative number of business days.
The data model permits the offset to differ from that of the index,
however the two are typically the same.
This will default to the fixing date offset of the index if not specified.
Frequency paymentFrequency
Regular payments will be made at the specified periodic frequency. The frequency must be the same as, or a multiple of, the accrual periodic frequency.
Compounding applies if the payment frequency does not equal the accrual frequency.
This will default to the accrual frequency if not specified.
DaysAdjustment paymentDateOffset
The offset is applied to the unadjusted date specified by paymentRelativeTo
.
Offset can be based on calendar days or business days.
This will default to 'None' if not specified.
CompoundingMethod compoundingMethod
Compounding is used when combining accrual periods.
This will default to 'None' if not specified.
boolean notionalExchange
If 'true', the notional there is both an initial exchange and a final exchange of notional.
This will default to 'false' if not specified.
String name
FixedRateSwapLegConvention fixedLeg
IborRateSwapLegConvention floatingLeg
DaysAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
String name
FixedRateSwapLegConvention fixedLeg
InflationRateSwapLegConvention floatingLeg
BusinessDayAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
DaysAdjustment paymentDateOffset
String name
FixedRateSwapLegConvention fixedLeg
OvernightRateSwapLegConvention floatingLeg
DaysAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
String name
IborRateSwapLegConvention spreadLeg
The spread is the market price of the instrument. It is added to the observed interest rate.
IborRateSwapLegConvention flatLeg
DaysAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
String name
OvernightRateSwapLegConvention overnightLeg
IborRateSwapLegConvention iborLeg
DaysAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
String name
FixedRateSwapLegConvention spreadLeg
This is to be applied to floatingSpreadLeg
.
IborRateSwapLegConvention spreadFloatingLeg
IborRateSwapLegConvention flatFloatingLeg
DaysAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
String name
IborRateSwapLegConvention spreadLeg
The spread is the market price of the instrument. It is added to the observed interest rate.
IborRateSwapLegConvention flatLeg
DaysAdjustment spotDateOffset
The offset is applied to the trade date to find the start date. A typical value is "plus 2 business days".
PriceIndex index
The floating rate to be paid is based on this price index It will be a well known price index such as 'GB-HICP'.
Period lag
A price index is typically published monthly and has a delay before publication. The lag is subtracted from the accrual start and end date to locate the month of the data to be observed.
For example, the September data may be published in October or November. A 3 month lag will cause an accrual date in December to be based on the observed data for September, which should be available by then.
PriceIndexCalculationMethod indexCalculationMethod
This specifies how the reference index calculation occurs.
This will default to 'Monthly' if not specified.
boolean notionalExchange
If 'true', the notional there is both an initial exchange and a final exchange of notional.
This will default to 'false' if not specified.
Period periodToStart
This is often zero, but can be greater if the swap if forward starting. This must not be negative.
Tenor tenor
This is the period from the first accrual date to the last accrual date.
OvernightIborSwapConvention convention
OvernightIndex index
The floating rate to be paid is based on this index It will be a well known market index such as 'GBP-SONIA'.
OvernightAccrualMethod accrualMethod
Two methods of accrual are supported - 'Compounded' and 'Averaged'. Averaging is primarily related to the 'USD-FED-FUND' index.
Integer rateCutOffDays
When a rate cut-off applies, the final daily rate is determined this number of days before the end of the period, with any subsequent days having the same rate.
The amount must be zero or positive. A value of zero or one will have no effect on the standard calculation. The fixing holiday calendar of the index is used to determine business days.
For example, a value of 3
means that the rate observed on
(periodEndDate - 3 business days)
is also to be used on
(periodEndDate - 2 business days)
and (periodEndDate - 1 business day)
.
If there are multiple accrual periods in the payment period, then this will only apply to the last accrual period in the payment period.
This will default to the zero if not specified.
Currency currency
This is the currency of the swap leg and the currency that payment is made in. The data model permits this currency to differ from that of the index, however the two are typically the same.
This will default to the currency of the index if not specified.
DayCount dayCount
This is used to convert dates to a numerical value. The data model permits the day count to differ from that of the index, however the two are typically the same.
This will default to the day count of the index if not specified.
Frequency accrualFrequency
Interest will be accrued over periods at the specified periodic frequency, such as every 3 months.
This will default to the term frequency if not specified.
BusinessDayAdjustment accrualBusinessDayAdjustment
Each date in the calculated schedule is determined without taking into account weekends and holidays. The adjustment specified here is used to convert those dates to valid business days.
The start date and end date may have their own business day adjustment rules. If those are not present, then this adjustment is used instead.
This will default to 'ModifiedFollowing' using the index fixing calendar if not specified.
BusinessDayAdjustment startDateBusinessDayAdjustment
The start date property is an unadjusted date and as such might be a weekend or holiday. The adjustment specified here is used to convert the start date to a valid business day.
This will default to the accrualDatesBusinessDayAdjustment
if not specified.
BusinessDayAdjustment endDateBusinessDayAdjustment
The end date property is an unadjusted date and as such might be a weekend or holiday. The adjustment specified here is used to convert the end date to a valid business day.
This will default to the accrualDatesBusinessDayAdjustment
if not specified.
StubConvention stubConvention
The stub convention is used during schedule construction to determine whether the irregular remaining period occurs at the start or end of the schedule. It also determines whether the irregular period is shorter or longer than the regular period.
This will default to 'ShortInitial' if not specified.
RollConvention rollConvention
The schedule periods are determined at the high level by repeatedly adding the frequency to the start date, or subtracting it from the end date. The roll convention provides the detailed rule to adjust the day-of-month or day-of-week.
This will default to 'None' if not specified.
Frequency paymentFrequency
Regular payments will be made at the specified periodic frequency. The frequency must be the same as, or a multiple of, the accrual periodic frequency.
Compounding applies if the payment frequency does not equal the accrual frequency.
This will default to the accrual frequency if not specified.
DaysAdjustment paymentDateOffset
The offset is applied to the unadjusted date specified by paymentRelativeTo
.
Offset can be based on calendar days or business days.
This will default to 'None' if not specified.
CompoundingMethod compoundingMethod
Compounding is used when combining accrual periods.
This will default to 'None' if not specified.
Period periodToStart
This is often zero, but can be greater if the swap if forward starting. This must not be negative.
Tenor tenor
This is the period from the first accrual date to the last accrual date.
ThreeLegBasisSwapConvention convention
Period periodToStart
This is often zero, but can be greater if the swap if forward starting. This must not be negative.
Tenor tenor
This is the period from the first accrual date to the last accrual date.
XCcyIborIborSwapConvention convention
LocalDate settlementDate
The payoff of the option is settled at this date.
CashSettlementMethod cashSettlementMethod
The settlement rate of the cash settled swaption is specified by respective cash settlement methods.
LongShort longShort
Long indicates that the owner wants the option to be in the money at expiry. Short indicates that the owner wants the option to be out of the money at expiry.
SwaptionSettlement swaptionSettlement
The settlement of the option is specified by SwaptionSettlement
.
ZonedDateTime expiry
The option is European, and can only be exercised on the expiry date.
ResolvedSwap underlying
At expiry, if the option is exercised, this swap will be entered into. The swap description is the swap as viewed by the party long the option.
TradeInfo info
This allows additional information to be attached to the trade.
ResolvedSwaption product
The product captures the contracted financial details of the trade.
Payment premium
The premium sign should be compatible with the product Long/Short flag. This means that the premium is negative for long and positive for short.
LongShort longShort
Long indicates that the owner wants the option to be in the money at expiry. Short indicates that the owner wants the option to be out of the money at expiry.
SwaptionSettlement swaptionSettlement
The settlement of the option is specified by SwaptionSettlement
.
AdjustableDate expiryDate
The option is European, and can only be exercised on the expiry date.
This date is typically set to be a valid business day.
However, the businessDayAdjustment
property may be set to provide a rule for adjustment.
LocalTime expiryTime
The expiry time is related to the expiry date and time-zone.
ZoneId expiryZone
The expiry time-zone is related to the expiry date and time.
Swap underlying
At expiry, if the option is exercised, this swap will be entered into. The swap description is the swap as viewed by the party long the option.
TradeInfo info
This allows additional information to be attached to the trade.
Swaption product
The product captures the contracted financial details of the trade.
Payment premium
The premium sign should be compatible with the product Long/Short flag. This means that the premium is negative for long and positive for short.
Copyright 2009-Present by OpenGamma Inc. and individual contributors
Apache v2 licensed
Additional documentation can be found at opengamma.github.io/StrataDocs.


Oh, hello there!
My name is Jamie, and I currently study at Asia Pacific College. This is my first labwork. Yay!


| Date and Time | Speaker | Title & Abstract |
|---|---|---|
|
Jan. 27, 2014
10 - 11am Skurla 106 |
Jonathan Goldfarb
Math Sciences Department Florida Tech |
Title: Introduction to Sobolev Spaces I
Abstract: The seminar will introduce notation and concepts relevant to weak differentiation and Sobolev spaces, with applications to partial differential equations of mathematical physics. Source: Chapter 5 in Evans, Partial Differential Equations, with some others. |
|
Feb. 10, 2014
10 - 11am Quad 110 |
Jonathan Goldfarb
Math Sciences Department Florida Tech |
Title: Introduction to Sobolev Spaces II
Abstract: We continue with properties of weak differentiation and basic facts of Sobolev spaces. Source: Chapter 5 in Evans, Partial Differential Equations, with some others. |
|
Feb. 24, 2014
10 - 11am Quad 111 |
Bruno Poggi
Math Sciences Department Florida Tech |
Title: Introduction to Sobolev Spaces III
Abstract: We will discuss properties of Sobolev functions, and the completeness of the Sobolev space. Source: Chapter 5 in Evans, Partial Differential Equations. |
|
Mar. 17, 2014
10 - 11am Quad 111 |
Noha Aljaber
Math Sciences Department Florida Tech |
Title: Introduction to Sobolev Spaces IV
Abstract: In this talk, we continue our exploration of Sobolev functions by showing that the space of smooth functions is a dense subset of the Sobolev space. Source: Chapter 5 in Evans, Partial Differential Equations. |
|
Mar. 24, 2014
10 - 11am Quad 111 |
Noha Aljaber
Math Sciences Department Florida Tech |
Title: Convolution and Mollfication
Abstract: In this talk, we will look to the details of creating smooth approximations to badly behaved (integrable) functions. Source: Appendix C in Evans, Partial Differential Equations. |
|
Mar. 31, 2014
10 - 11am Quad 111 |
Jeremy Mandelkern
Assistant Professor Eastern Florida State College Mathematics Department |
Title: A Novel Method for Frobenius Type Problems Utilizing 4x4 Matrix Multiplication Recurrence Relations
Abstract: In Balser [1, p. 18-19] a matrix formulation of the Frobenius Theory, near a regular singular point, is given resulting in a 2x2 matrix of two linearly independent solutions together with their quasi-derivatives. In this paper we apply Balser’s 2x2 matrix formulation to the Bessel equation, \[ (xy')' + \left( -\frac{v^2}{x} + \lambda x\right)y=0\]We then show that with a slight reformulation of his 2x2 matrix recurrence relation, we can generate an equivalent recurrence relation through a “vectorization” procedure. This reformulated approach succeeds in overcoming the rather cumbersome coupling associated with Balser’s 2x2 matrix recursion. As a result of the vectorization procedure, the 2x2 matrix recurrence relation is replaced by a straightforward matrix multiplication of 4x4 matrices. |
|
Apr. 7, 2014
10 - 11am Quad 111 |
Ryan White
Math Sciences Department Florida Tech |
Title: Introduction to Sobolev Spaces V
Abstract: In this talk, we continue our exploration of Sobolev functions by establishing how Sobolev functions can be extended to larger domains while satisfying appropriate inequalities. This extension allows results established with the domain of the whole space to be appropriately generalized to smaller domains. Source: Chapter 5 in Evans, Partial Differential Equations. |
|
Apr. 14, 2014
10 - 11am Quad 111 |
Osita Onyejekwe
Math Sciences Department Florida Tech |
Title: Regression for Parametric and Nonparametric Estimation
Abstract: In this talk Linear, Polynomial, and Kernel Regression analysis will be introduced. It follows by application of regression method for parametric and nonparametric estimation through simulations. It will be concluded by addressing the important questions regarding selection of polynomial order in parametric estimation as well as selection of the bandwidth in nonparametric estimation. |
|
Apr. 21, 2014
10 - 11am Quad 111 |
Elvira Erhardt
Math Sciences Department Florida Tech |
Title: Statistical Multiple Testing for Analysis of Imaging Response in Simulated Brain Images
Abstract: In this talk different methods of multiple testing will be introduced. Voxel-wise test of significance will then be discussed by application of Bonferroni and FDR correction to imaging response in simulated brain images. It will be concluded by statistical estimation of background and standardizing the test statistics using the estimated parameters. |


NDC weeds Ghana today
Members of Ghana’s biggest opposition party, the National Democratic Congress (NDC), today, Saturday, 16 November 2019, undertook a nationwide weeding exercise in honour of their flag bearer Mr John Mahama who recently undertook a similar exercise in Accra, the national capital.
Last week, the former President cleared overgrown weeds in the median of the road that leads to the Military Cemetery.
Subsequently, statement signed by Mr Joshua Hamidu Akamba, the National Organiser of the NDC on Tuesday, 12 November said: “This is to bring to the attention of all constituency organisers that the party shall observe a nationwide weeding and clean-up up exercise on Saturday, 16 November 2019 in all regional and district capitals in honour of the flag bearer of the NDC, H.E. John Dramani Mahama.
“Last week, the flag bearer of the NDC re-summoned the spirit of the National Sanitation Day, which was introduced by him, when he led his security detail to weed the midsection of the road leading to the military cemetery in Accra to improve visibility along the road."
The NDC said it believes Mr Mahama's example must be replicated across the country in order to rid the country of the filth that has engulfed it "under the watch of Akufo-Addo and his failed Sanitation Minister."


Droponic: Growing Your Own Food Has Never Been Easier!
Droponic is proud to announce a revolutionary system for the average consumer to grow food right at home. Beautiful, smart, and elegant, Droponic incorporates techniques from traditional hydroponic fundamentals with a touch of modernism.
Through our “smart” planters paired with our intuitive smartphone app, users can track their plants’ progress, receive reminders to water and add nutrients, and perform light tests to provide the optimum requirements for your plants to flourish. Growing your very own indoor garden has never been easier.
Fire up your favorite dishes with fresh herbs grown directly from your kitchen, without the dirt and grime from traditional planters! We put a great amount of effort in forging the best design for Droponic that is both simple and practical. Droponic attaches effortless to your window, which provides sunlight and energy for its plants. Connected to your smartphone, the system shoots out notifications based on the requirements of individual plants.
 The effect this has on cooking can be huge; before you know it, you’ll find yourself experimenting with flavours with increasing success.” –Jamie Oliver, Top Chef.
Grow anything from kale to basil with ease. We carefully select the best variety vegetable and herbs. Take your cooking game to a whole new level with Droponic!
About Droponic
Droponic started at the hackaton of Draper University Spring 2015 Session. Our first working prototype was created in 48 hours and we had great results. We used a plunger to paste it in a normal window so it was space saving. Then we drilled 4 holes into the stick to insert threading screwing lights bulbs with dried seeds and nutrients inside. The idea was to put a small pump inside the sucker and pump water through the stick so the herbs start to grow with no soil needed.


Using a single line of code, you can set all of the reality models required for an Alpha Stream. This is done via a Brokerage Model. The brokerage model sets all your asset fees, slippage, and margin models to the required settings automatically. This should be called in your Initialize()
method.
# Set fee, slippage and margin models automatically. self.SetBrokerageModel(BrokerageName.AlphaStreams)
//Set fee, slippage and margin models automatically. SetBrokerageModel(BrokerageName.AlphaStreams);
Behind the scenes, this sets your models to the AlphaStreamsBrokerageModel
, AlphaStreamsFeeModel
, and AlphaStreamsSlippageModel
. In the following sections, we'll explore these models in more detail.


|
Biomedical Image Analysis Library
The Biomedical Image Analysis Library is a poweful tool for developers, physicians, researchers, engineers, and so on.
|
Functions | |
| template<class D > | |
| Image< D > | AffineTransform (const Image< D > &img, const Matrix< float > &transform) |
| Applies affine transformation to an image, using the matrix of transformation. More... | |
| template<class D > | |
| Image< D > | AffineTransform (const Image< D > &img, const Matrix< float > &transform, const PixelInterpolation &interpolation) |
| Applies affine transformation to an image, using the matrix of transformation. More... | |
| template<class D > | |
| Image< D > | Rotate (const Image< D > &img, float rad, size_t dms=2) |
| Rotates a image. More... | |
| template<class D > | |
| Image< D > | Rotate (const Image< D > &img, const PixelInterpolation &interpolation, float rad, size_t dms=2) |
| Rotates a image. More... | |
| Matrix< float > | Rotate (double rad, size_t dms=2) |
| Generates a transformation corresponding to a rotation. More... | |
| Matrix< float > | Rotate (Matrix< float > &source, double rad, size_t dms=2) |
| Generates a composite transformation of the rotation applyed over source matrix. More... | |
| template<class D > | |
| Image< D > | Scale (const Image< D > &img, double factor, bool resize=false) |
| Scales a image. More... | |
| template<class D > | |
| Image< D > | Scale (const Image< D > &img, const PixelInterpolation &interpolation, double factor, bool resize=false) |
| Scales a image. More... | |
| template<class D > | |
| Image< D > | Scale (const Image< D > &img, double fx, double fy, double fz=1.0, bool resize=false) |
| Scales a image. More... | |
| template<class D > | |
| Image< D > | Scale (const Image< D > &img, const PixelInterpolation &interpolation, double fx, double fy, double fz=1.0, bool resize=false) |
| Scales a image. More... | |
| template<class D > | |
| Image< D > | Scale (const Image< D > &img, const Vector< size_t > &dims) |
| Scales a image. More... | |
| template<class D > | |
| Image< D > | Scale (const Image< D > &img, const PixelInterpolation &interpolation, const Vector< size_t > &dims) |
| Scales a image. More... | |
| Matrix< float > | Scale (double fx, double fy, double fz=1.0) |
| Generates a transformation corresponding to a scaling. More... | |
| Matrix< float > | Scale (Matrix< float > &source, double fx, double fy, double fz=1.0) |
| Generates a composite transformation of the scaling applyed over source matrix. More... | |
| template<class D > | |
| Image< D > | Shear (const Image< D > &img, double s_xy, double s_yx, double s_xz=0.0, double s_yz=0.0, double s_zx=0.0, double s_zy=0.0) |
| Shears an image. More... | |
| template<class D > | |
| Image< D > | Shear (const Image< D > &img, const PixelInterpolation &interpolation, double s_xy, double s_yx, double s_xz=0.0, double s_yz=0.0, double s_zx=0.0, double s_zy=0.0) |
| Shears an image. More... | |
| Matrix< float > | Shear (double s_xy, double s_yx, double s_xz=0.0, double s_yz=0.0, double s_zx=0.0, double s_zy=0.0) |
| Generates a transformation corresponding to a shear. More... | |
| Matrix< float > | Shear (Matrix< float > &source, double s_xy, double s_yx, double s_xz=0.0, double s_yz=0.0, double s_zx=0.0, double s_zy=0.0) |
| Generates a composite transformation of the shear applyed over source matrix. More... | |
| template<class D > | |
| Image< D > | Translate (const Image< D > &img, double dx, double dy, double dz=0) |
| Translates a image. More... | |
| template<class D > | |
| Image< D > | Translate (const Image< D > &img, const PixelInterpolation &interpolation, double dx, double dy, double dz=0) |
| Translates a image. More... | |
| Matrix< float > | Translate (double dx, double dy, double dz=0) |
| Generates a transformation corresponding to a translation. More... | |
| Matrix< float > | Translate (Matrix< float > &source, double dx, double dy, double dz=0) |
| Generates a composite transformation of the translation applyed over source matrix. More... | |
| Image< D > Bial::Geometrics::AffineTransform | ( | const Image< D > & | img, |
| const Matrix< float > & | transform | ||
| ) |
Applies affine transformation to an image, using the matrix of transformation.
| img | Input image. |
| transform | Affine transformation matrix. |
| Image< D > Bial::Geometrics::AffineTransform | ( | const Image< D > & | img, |
| const Matrix< float > & | transform, | ||
| const PixelInterpolation & | interpolation | ||
| ) |
Applies affine transformation to an image, using the matrix of transformation.
| img | Input image. |
| transform | Affine transformation matrix. |
| interpolation | Pixel interpolation to be used. |
| Image< D > Bial::Geometrics::Rotate | ( | const Image< D > & | img, |
| float | rad, | ||
| size_t | dms = 2 |
||
| ) |
Rotates a image.
| img | Input image. |
| rad | Rotation in radians. |
| dms | Rotation dimension. Default: 2 to rotate around z axis. |
| Image< D > Bial::Geometrics::Rotate | ( | const Image< D > & | img, |
| const PixelInterpolation & | interpolation, | ||
| float | rad, | ||
| size_t | dms = 2 |
||
| ) |
Rotates a image.
| img | Input image. |
| interpolation | Pixel interpolation to be used. |
| rad | Rotation in radians. |
| dms | Rotation dimension. Default: 2 to rotate around z axis. |
| Matrix< float > Bial::Geometrics::Rotate | ( | double | rad, |
| size_t | dms = 2 |
||
| ) |
Generates a transformation corresponding to a rotation.
| rad | Rotation in radians |
| dms | Rotation dimension. Default: 2 to rotate around z axis. |
Generates a composite transformation of the rotation applyed over source matrix.
| source | Initial affine transformation over which rotation is applyed. |
| rad | Rotation in radians |
| dms | Rotation dimension. Default: 2 to rotate around z axis. |
| Image< D > Bial::Geometrics::Scale | ( | const Image< D > & | img, |
| double | factor, | ||
| bool | resize = false |
||
| ) |
Scales a image.
| img | Input image. |
| factor | Scaling factor. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| resize | resize the resultant image. |
| Image< D > Bial::Geometrics::Scale | ( | const Image< D > & | img, |
| const PixelInterpolation & | interpolation, | ||
| double | factor, | ||
| bool | resize = false |
||
| ) |
Scales a image.
| img | Input image. |
| interpolation | Pixel interpolation to be used. |
| factor | Scaling factor. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| resize | resize the resultant image. |
| Image< D > Bial::Geometrics::Scale | ( | const Image< D > & | img, |
| double | fx, | ||
| double | fy, | ||
| double | fz = 1.0 , |
||
| bool | resize = false |
||
| ) |
Scales a image.
| img | Input image. |
| fx | Scaling factor in X. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fy | Scaling factor in Y. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fz | Scaling factor in Z. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| resize | resize the resultant image. |
| Image< D > Bial::Geometrics::Scale | ( | const Image< D > & | img, |
| const PixelInterpolation & | interpolation, | ||
| double | fx, | ||
| double | fy, | ||
| double | fz = 1.0 , |
||
| bool | resize = false |
||
| ) |
Scales a image.
| img | Input image. |
| interpolation | Pixel interpolation to be used. |
| fx | Scaling factor in X. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fy | Scaling factor in Y. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fz | Scaling factor in Z. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| resize | resize the resultant image. |
| Image< D > Bial::Geometrics::Scale | ( | const Image< D > & | img, |
| const Vector< size_t > & | dims | ||
| ) |
Scales a image.
| img | Input image. |
| dims | Resulting image dimensions. |
| Image< D > Bial::Geometrics::Scale | ( | const Image< D > & | img, |
| const PixelInterpolation & | interpolation, | ||
| const Vector< size_t > & | dims | ||
| ) |
Scales a image.
| img | Input image. |
| interpolation | Pixel interpolation to be used. |
| dims | Resulting image dimensions. |
| Matrix< float > Bial::Geometrics::Scale | ( | double | fx, |
| double | fy, | ||
| double | fz = 1.0 |
||
| ) |
Generates a transformation corresponding to a scaling.
| img | Input image. |
| fx | Scaling factor in X. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fy | Scaling factor in Y. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fz | Scaling factor in Z. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| Matrix< float > Bial::Geometrics::Scale | ( | Matrix< float > & | source, |
| double | fx, | ||
| double | fy, | ||
| double | fz = 1.0 |
||
| ) |
Generates a composite transformation of the scaling applyed over source matrix.
| img | Input image. |
| source | Initial affine transformation over which scaling is applyed. |
| fx | Scaling factor in X. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fy | Scaling factor in Y. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| fz | Scaling factor in Z. If greater than 1.0, image is dilated. If lower than 1.0, image is compressed. |
| Image< D > Bial::Geometrics::Shear | ( | const Image< D > & | img, |
| double | s_xy, | ||
| double | s_yx, | ||
| double | s_xz = 0.0 , |
||
| double | s_yz = 0.0 , |
||
| double | s_zx = 0.0 , |
||
| double | s_zy = 0.0 |
||
| ) |
Shears an image.
| img | Input image. |
| s_xy | Shearing in axis X with respect to axis Y. |
| s_yx | Shearing in axis Y with respect to axis X. |
| s_xz | Shearing in axis X with respect to axis Z. |
| s_yz | Shearing in axis Y with respect to axis Z. |
| s_zx | Shearing in axis Z with respect to axis X. |
| s_zy | Shearing in axis Z with respect to axis Y. |
| Image< D > Bial::Geometrics::Shear | ( | const Image< D > & | img, |
| const PixelInterpolation & | interpolation, | ||
| double | s_xy, | ||
| double | s_yx, | ||
| double | s_xz = 0.0 , |
||
| double | s_yz = 0.0 , |
||
| double | s_zx = 0.0 , |
||
| double | s_zy = 0.0 |
||
| ) |
Shears an image.
| img | Input image. |
| interpolation | Pixel interpolation to be used. |
| s_xy | Shearing in axis X with respect to axis Y. |
| s_yx | Shearing in axis Y with respect to axis X. |
| s_xz | Shearing in axis X with respect to axis Z. |
| s_yz | Shearing in axis Y with respect to axis Z. |
| s_zx | Shearing in axis Z with respect to axis X. |
| s_zy | Shearing in axis Z with respect to axis Y. |
| Matrix< float > Bial::Geometrics::Shear | ( | double | s_xy, |
| double | s_yx, | ||
| double | s_xz = 0.0 , |
||
| double | s_yz = 0.0 , |
||
| double | s_zx = 0.0 , |
||
| double | s_zy = 0.0 |
||
| ) |
Generates a transformation corresponding to a shear.
| s_xy | Shearing in axis X with respect to axis Y. |
| s_yx | Shearing in axis Y with respect to axis X. |
| s_xz | Shearing in axis X with respect to axis Z. |
| s_yz | Shearing in axis Y with respect to axis Z. |
| s_zx | Shearing in axis Z with respect to axis X. |
| s_zy | Shearing in axis Z with respect to axis Y. |
| Matrix< float > Bial::Geometrics::Shear | ( | Matrix< float > & | source, |
| double | s_xy, | ||
| double | s_yx, | ||
| double | s_xz = 0.0 , |
||
| double | s_yz = 0.0 , |
||
| double | s_zx = 0.0 , |
||
| double | s_zy = 0.0 |
||
| ) |
Generates a composite transformation of the shear applyed over source matrix.
| s_xy | Shearing in axis X with respect to axis Y. |
| s_yx | Shearing in axis Y with respect to axis X. |
| s_xz | Shearing in axis X with respect to axis Z. |
| s_yz | Shearing in axis Y with respect to axis Z. |
| s_zx | Shearing in axis Z with respect to axis X. |
| s_zy | Shearing in axis Z with respect to axis Y. |
| Image< D > Bial::Geometrics::Translate | ( | const Image< D > & | img, |
| double | dx, | ||
| double | dy, | ||
| double | dz = 0 |
||
| ) |
Translates a image.
| img | Input image. |
| dx | Displacement in X |
| dy | Displacement in Y |
| dz | Displacement in Z |
| Image< D > Bial::Geometrics::Translate | ( | const Image< D > & | img, |
| const PixelInterpolation & | interpolation, | ||
| double | dx, | ||
| double | dy, | ||
| double | dz = 0 |
||
| ) |
Translates a image.
| img | Input image. |
| interpolation | Pixel interpolation to be used. |
| dx | Displacement in X |
| dy | Displacement in Y |
| dz | Displacement in Z |
| Matrix< float > Bial::Geometrics::Translate | ( | double | dx, |
| double | dy, | ||
| double | dz = 0 |
||
| ) |
Generates a transformation corresponding to a translation.
| source | Initial affine transformation over which translation is applyed. |
| dx | Displacement in X |
| dy | Displacement in Y |
| dz | Displacement in Z |
| Matrix< float > Bial::Geometrics::Translate | ( | Matrix< float > & | source, |
| double | dx, | ||
| double | dy, | ||
| double | dz = 0 |
||
| ) |
Generates a composite transformation of the translation applyed over source matrix.
| source | Initial affine transformation over which translation is applyed. |
| dx | Displacement in X |
| dy | Displacement in Y |
| dz | Displacement in Z |


CRUMPET: Collisional-Radiative UEDGE Model for Plasma-Edge Theory¶
What is CRUMPET?¶
CRUMPET is a versatile Python script for creating collisional-radiative models, originally developed for fusion plasma application, with the multi-fluid plasma-edge code UEDGE [1]. Collisional-radiative models are necessary under conditions where a system is under neither Saha/LT equilibrium, nor Coronal equilibrium. Under such conditions, the collisional and radiative processes of the system are competing, and the net effect of all such processes, which are often competing, need to be carefully evaluated. CRUMPET has the capability to consider molecular-assisted processes, such as recombination, dissociation, and ionization (MAR, MAD, and MAI, respectively) as well as Franck-Condon and potential energy sinks/sources and molecular and atomic line radiation.
Neutral dynamics involve a large set of electronically, vibrationally, and rotationally excited species, and a number of reactions associated with each such species. This creates a large number of species, and transitions if each species are to be tracked time-dependently. However, a large number of the species are so-called “conduit” species: their lifetimes are too short for any significant population to survive in the plasma. Rather, such conduit species mediate further reactions yielding more stable particles, which exist in significant populations in the plasma. Simulating all species and reactions, including conduit-species, time-dependently requires vast computational resources. Instead, a collisional-radiative model can be applied to the system, yielding effective reaction rates for only a subset of species which are to be simulated time-dependently.
Atomic CRMs have been widely applied to fusion plasmas for the last decades as they are straightforward to formulate. However, molecular CRMs impose additional conditions on the formulation of the CRM compared to atomic CRMs. These conditions are outlined in [2], and have been implemented in CRUMPET in order to create molecular collisional-radiative models.
Features¶
Versatile creation of collisonal-radiative models
CRM formulations only dependent on data supplied to the model
Not bound to a specific element or isotope
Capability to read rate data from ADAS and EIRENE data files
Capability to use custom rate data
Solve the full system of ODEs
Create a Greenland-style CRM [2] without any underlying assumptions of the background plasma
Solve the energy sinks and sources for a number of processes
Write rate coefficients to tabulated data files
Assess the accuracy of the current CRM
Use Greenland’s algorithm [2] to find the optimal CRM for a given plasmas temperature and density
Solve the steady-state CRM populations using external sinks and sources (e.g. from transport codes)
Create synthetic spectra for steady-state plasmas, which can be used for post-processing plasma-edge simulations
How is it used?¶
Crumpet reads a CRUMPET-specific input file where the CRM is set up. The CRM species, background species, and time-dependent/conduit species are defined in the input file, as are the reactions to be considered. The reactions use rate data supplied by the user: a nnumber of standard A&M databases, such as ADAS and EIRENE can also be read in. A number of options and settings can also be used to control the behavior and setup of the CRM.
Installation¶
CRUMPET is installed by downloading the git repository to either a location that is listed in PYTHONPATH, or by adding the path to the downloaded repository to PYTHONPATH.
Support¶
If you have issues, or would like to use CRUMPET for a certain task and need assistance, you can reach the author via andreas.holm{at}aalto.fi.
Contributions¶
Anyone is free to contribute to CRUMPET via github using personal forks or branches with a merge-request. - Issue tracker: github.com/holm10/CRUMPET/issues - Source code: github.com/holm10/CRUMPET
License¶
CRUMPET is licensed under the MIT License


Abstract
Widok is a reactive web framework for the JVM and Scala.js. Its key concepts are:
- Pages: Widok enforces modularisation of your web application. You split your application into pages. A router watches the browser query and loads the respective page.
- Widgets: The layout is specified in terms of composable widgets. Widgets are bound to dynamically changing values which are rendered on-the-fly in the browser.
- Bindings: Widok ships bindings for CSS frameworks like Bootstrap and Font-Awesome.
- Reactive programming: Reactive data structures, which implement a simple model of data propagation, are provided. Widok has reactive counterparts for variables, arrays, maps and sets. Instead of dealing with constant values, you specify the data flow as streams, on which you operate with higher-order functions like map() or filter().
Code example
The following example implements a single-page application that uses two-way binding:
package example
import org.widok._
import org.widok.html._
object App extends PageApplication {
val name = Var("")
val hasName = name.map(_.nonEmpty)
def view() = div(
h1("Welcome to Widok!")
, p("Please enter your name:")
, text().bind(name)
, p("Hello, ", name)
.show(hasName)
, button("Change my name")
.onClick(_ => name := "tux")
.show(name !=== "tux")
, button("Log out")
.onClick(_ => name := "")
.show(hasName)
)
def ready() { }
}
Live Scala Fiddle demo
Try it yourself here:
User manual
The user manual (v0.2.2) is available in three formats:
Showcase
- Client-server skeleton
- TodoMVC
- Poliglot-UI: Node.js application that uses the Bootstrap bindings
Project links
- API documentation (Scala.js)
- API documentation (JVM)
- Issue tracker
- Google Group
- Gitter
- Travis CI
- Source code


MAGIC IN THE MIRROR
USA. 1996. Director - Ted Nicolaou, Screenplay - Ken Carter Jr & Frank Dietz, Producers - Kevin Hyman & Vlad Paunescu, Photography - Adolfo Bartoli, Music - Richard Kozinski, Visual Effects Supervisor - MacKenzie Waggaman, Digital Visual Effects - OCS, Freeze Frame & Pixel Magic (Supervisor - Ray McIntyre Jr), Creature Effects - Mark Rappaport, Production Design - Cristian Niculescu, Art Direction - Viorel Ghenea. Production Company - Bibi Productions. Jamie Renee Smith (Mary Margaret Dennis), Saxon Trainor (Sylvia Dennis/Queen Hysop), David Brooks (Gilbert Dennis), Godfrey James (Melilot), Kevin Wixted (Tansy), Eileen T'Kaye (Dragora), Ion Haiduc (Admiral Dabble), Cristian Motriuc (Swanson/Dr Francis Schmott), Ileana Sandulescu (Bella), Daniela Marzavan (Donna)
Plot: Young parentally neglected Mary Margaret Dennis discovers some magical berries which open up a doorway to another world through her late aunt's mirror. But there, as she tries to find some more berries to get back home, she is sought by the crazed duck queen Dragora who has discovered a taste for tea made out of humans dunked in hot water and desires to find a way through the mirror in order to plunder the people world.
Although it is not produced under either the Full Moon or Moonbeam banners, this is another of Charles Band and director Ted Nicolau's low-budget fantasy films. Every now and again Band and Nicolaou manage to pull something quite unique and unexpected out of the hat - they did with `Dragonworld' - and do so here again. One sat down to watch `Magic in the Mirror' with no real expectations - after all the majority of the Band/Moonbeam children's films like `Pet Shop' and the `Prehysteria!' films are utter dross. But in no time at all the film manages to take one completely by surprise and one suddenly wonders exactly what sort of drug-induced hallucination they are in the midst of. It is quite a bewildering, head-spinning experience, not unakin to sitting down to watch something like `Pufnstuf' for the first time. Nicolaou creates a unique secondary world fabulation filled with journeys through magical mirrors and tyrannical duck queens threatening to dip young girls into giant boiling teapots to serve up as a rare delicacy. There are moments of bizarrely surreal imagery - armies of flying mallards ("I love the smell of duck gas in the morning," comments the duck general); a whole field of doors leading to magical mirrors; gardens of planted people. For once the usual Band low-budget does not show through too much and the duck costumes are surprisingly lavish and effective. The result is a unique fantasy which succesfully ventures into that rare arena of surreal fabulism that so few children's films get right - lone examples being `Willie Wonka and the Chocolate Factory' and `Pufnstuf'.
Copyright 1998 Richard Scheib
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


favorite Yay! Your Unicorn is on it's way! favorite We'll be contacting you soon for further details
So sad! We can't make your unicorn. Please check your information
5 cm
25 cm
warning


Buttons
Containers
Trees
- Node 1
- id: 3
- Name: London rename
- 2 Lines connected
- Line 1 delete
- Line 2 delete
- delete node
- Node 2
- id: 3
- Name: London rename
- 2 Lines connected
- Line 1 delete
- Line 2 delete
- delete node
- Node 3
- id: 3
- Name: London rename
- 2 Lines connected
- Line 1 delete
- Line 2 delete
- delete node


Anam1634.github.io
Suitable for all Schuchmann tricycles with free wheel and/or switchover to free wheel. For all 26 and 28 adult s bicycles, with and without rear suspension, with quick release wheel fixation. Wheels with full axle or wheel hub gears can be prepared using optionally available adaptors.
Schuchmann FollowMeMOMO Handbücher. PDF 00 Schuchmann Price list 2018 international Cover. Whether sitting, riding, walking or standing - our aids accompany and support you in everyday life. They help you get out to meet your friends and promote your development and health.
Preparation of the FollowMeMOMO - adjustment of the FollowMeMOMO to wheel size of the tricycle (at Schuchmann) Price / piece Net price o 39 01 109 22.00 € o 39 01 110 32.00 € Basic model FollowMeMOMO size 1 for 12 FollowMeMOMO size 2 for 16 + 20 FollowMeMOMO size 3 for 24 + 26 Price / piece Price / piece Price / piece. Want to know all the details? Our media library contains detailed information about our products that you can download. Select the required product category to filter the results.
Search among more than 1.000.000 user manuals and view them online Schuchmann: FollowMeMOMO - YouTube. Shop Plugin: Wrong parameters. GET/POST var tt_products product is missing or no item with uid = 23 found on allowed pages (609,610,611,765,613,618,615,617,616). Schuchmann GmbH Co. KG - YouTube. Sehr verehrte Kunden, seit mehr als 30 Jahren, und in zweiter Generation als Familienbetrieb, fertigen und vertreiben wir Rehahilfsmittel für Kinder, Jugendl.
MOMO series - Schuchmann Reha manualzz.com.
Suitable for all Schuchmann tricycles with free wheel and/or switchover to free wheel; For all 26 and 28 adult s bicycles, with and without rear suspension, with quick release wheel fixation (by request the Follow Me MOMO can be sold with an option for standard wheel axles). Dank unseres neuen FollowMeMOMOs für Dreiräder ist Ihre ganze Familie jederzeit sicher mit dem Rad unterwegs. Ganz egal, ob Sie Ihr Kind schnell an Ihr eigen. Just Juniors Disability - Follow


Thermodynamic Properties of the Quantum Harmonic Oscillator
The analysis of the quantum harmonic oscillator usually stops at finding the energy levels. In this post I take the analysis a little further, calculating some of the thermodynamic properties of a quantum harmonic oscillator.


THE SIEGE (20th Century Fox) Starring: Denzel Washington, Annette Bening, Bruce Willis, Tony Shalhoub, Sami Bouajila. Screenplay: Lawrence Wright and Menno Meyjes & Edward Zwick. Producers: Lynda Obst and Edward Zwick. Director: Edward Zwick.  Reviewed by Scott Renshaw.
The makers of THE SIEGE probably are throwing up their hands, baffled by the protests voiced by Arab-American groups. The basic set-up, understandably, could hit a nerve: Arab terrorists, incensed over U.S. involvement in the disappearance of an Islamic religious/political leader, begin a massive bombing campaign in New York City. Initially, a joint task force led by F.B.I. special agent Anthony Hubbard (Denzel Washington) is on the case, but tensions and animosities rise as they are unable to end the bombings. Eventually, the President imposes martial law in New York, charging U.S. Army General William Devereaux (Bruce Willis) with driving the perpetrators from hiding in Brooklyn's Arab-American community into the open -- even if it means imprisoning every young male of Arabic descent to find them.
You can feel co-writer/director Edward Zwick straining for every possible opportunity to make it clear that THE SIEGE is _not_ about Arab-bashing. Hubbard's partner Frank Haddad (Tony Shalhoub) is a Lebanese-born naturalized citizen; representatives from Arab-American anti-defamation groups stand up in meetings to voice their patriotism and to denounce terrorism; ominous music accompanies every shot of Arab-Americans trapped behind barbed wire fences; even the motivations of the terrorists are traced more to duplicitous U.S. foreign policy decisions than to fanatacism. As THE SIEGE builds to a series of speeches condemning the idea that extremism in the defense of security is no vice, you know that Zwick wants audiences to feel him championing the notion that Islam does not equal violent zealotry -- that Arab-Americans are people too.
There's one very important thing missing from THE SIEGE, however: a genuine connection to the people who are suffering. The film doesn't spend a second of personal time with a character actually interned in a detention camp, nor with individuals tortured by the military for information, nor with anyone victimized by anti-Arab hate crimes. They appear in forlorn masses, in news footage, or hidden behind doors. Yes, Shalhoub does get dialogue expressing outrage when his teenage son is taken prisoner, but the sentiment feels second-hand and token. During its final hour, THE SIEGE becomes a thoroughly generic thriller of chases and speeches -- more interested in being provocative than being empathetic, and more interested in the _idea_ of trampled rights than those whose rights are being trampled.
In fact, it's a shame THE SIEGE had to go there at all, because its first hour works so well as a crackling police procedure drama. Washington shares some exceptional scenes with Annette Bening as a secretive C.I.A. operative whose agenda may be very personal; their clashing tactics -- the rule of law vs. the rule of expediency -- make for first rate and surprisingly platitude-free sparring. Zwick directs the early action sequences with energy and economy, anchored by the always-satisfying images of determined people going about a difficult job with hard-nosed efficiency.
That exceptional first hour deteriorates into bloated nonsense as soon as Willis's General Devereaux starts marching his troops across the Brooklyn Bridge. Willis himself is a huge part of the problem, taking a potentially complex character and quickly turning him into a sneering caricature of military sadism. Even the fundamental honor and decency Washington brings to every role starts to seem like sanctimony, because the script isn't serious about getting into the gray areas of individual rights vs. societal needs. The concept deserves more than heroes and villains pointing guns at each other. Arab-Americans may be troubled by the idea that some Arab characters are portrayed as terrorists in THE SIEGE. They should be more troubled by the idea that, in a film with such an incendiary premise, Arab characters in general are more symbolic than substantial.
On the Renshaw scale of 0 to 10 siege mentalities: 5.
Visit Scott Renshaw's MoviePage http://www.inconnect.com/~renshaw/ *** Subscribe to receive new reviews directly by email! See the MoviePage for details, or reply to this message with subject line "Subscribe".
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


To color in a section of a construction, you "loft". Here, two line segments are defined
using four points on two lines. The "loft" command fills in the area between the two segments
with the color specified. This can result in a convex 4-sided figure, but if the segments
cross or pass close to each other, other shapes can be made.
Please look at the source code of this page for more information.


@* * Copyright 2019 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import config.FrontendAppConfig @import models.SchemeDetail @import views.formatters.Date @import controllers.invitations.routes @(appConfig: FrontendAppConfig, schemes: List[SchemeDetail], invitationsReceived: Boolean)(implicit request: Request[_], messages: Messages) @main_template( title = messages("messages__listSchemes__title"), appConfig = appConfig, bodyClasses = Some("full-width")) {
@messages("messages__listSchemes__noSchemes")


Reports any parameters of
java.util.Comparator.compare()
which are not used. Most likely this is the result of a typing mistake and one parameter is compared with itself or the method is not implemented correctly.
Powered by InspectionGadgets


SafetyCube (Safety CaUsation, Benefits and Efficiency) is a research project funded by the European Commission under the Horizons 2020, the EU Framework Programme for Research and Innovation, in the domain of Road Safety. The project started on May 1st, 2015 and will run for a period of three years.
The primary objective of the SafetyCube project is to develop the innovative road safety Decision Support System (DSS) that will enable policy-makers and stakeholders to select and implement the most appropriate strategies, measures and cost-effective approaches to reduce casualties of all road user types and all severities in Europe and worldwide.
More detailed information about the project activities and results are available at www.safetycube-project.eu
The information presented in the Road Safety DSS was collected, analysed and summarized by a multidisciplinary team of experienced road safety researchers, also on the basis of extensive stakeholders’ consultation. A well-defined, systematic and rigorous methodology was developed and applied, consisting of:
More detailed information about the methodology is available here.
For optimal use of the Road Safety DSS, some important information should be kept in mind, about the scope, the necessary research assumptions, as well as some limitations involved. These include, but are not limited to:
More detailed information about the Road Safety DSS scope and its limitations is available here.
The Glossary of the Road Safety DSS includes all the definitions of the terms and abbreviations used, and the related sources. Short definitions are provided for the key terms on the DSS pages by mousing-over the highlighted terms. All detailed definitions are available in the full Glossary.
The scientific quality of contents of the Road Safety DSS has been a top priority during the development phases. Strict quality assurance procedures were put in place, comprising four steps:
- Comprehensive guidelines, supported by workshops, webinars, Q&A sessions, and a help desk, assisted the SafetyCube researchers with their work.
- The selection and coding of studies, as well as the analyses and synopses of the findings were peer reviewed within the project.
- A small pool of independent experts checked both the outputs of individual coded studies and the overall contents of the synopses, applying a set of predefined quality criteria. One expert specifically looked at consistency within and between synopses.
- All synopses went through a language check by a native English speaker.
More information about the SafetyCube DSS Quality Assurance can be found here.


Prepare Athlete Monitoring Data
prepare( data, athlete, date, variable, value, day_aggregate = function(x) { sum(x) }, NA_session = NA, NA_day = NA, acute = 7, chronic = 28, rolling_fill = NA, rolling_estimators = function(x) { c(mean = mean(x, na.rm = TRUE), sd = stats::sd(x, na.rm = TRUE), cv = stats::sd(x, na.rm = TRUE)/mean(x, na.rm = TRUE), conf = sum(!is.na(x))/length(x)) }, posthoc_estimators = function(data) { return(data) }, group_summary_estimators = function(x) { c(median = stats::median(x, na.rm = TRUE), lower = stats::quantile(x, 0.25, na.rm = TRUE)[[1]], upper = stats::quantile(x, 0.75, na.rm = TRUE)[[1]]) }, iter = TRUE )
| data | Data frame |
|---|---|
| athlete | Name of the column in the |
| date | Name of the column in the |
| variable | Name of the column in the |
| value | Name of the column in the |
| day_aggregate | Function for aggregating multiple day entries. Defaults is |
| NA_session | What value should be imputed for missing values in |
| NA_day | What value should be imputed for missing days? Default is |
| acute | Duration of the acute rolling window. Default is 7 |
| chronic | Duration of the chronic rolling window. Default is 28 |
| rolling_fill | Value used to fill start of the rolling windows. Default is |
| rolling_estimators | Function providing rolling estimators. See Details |
| posthoc_estimators | Function providing post-hoc estimators. See Details |
| group_summary_estimators | Function providing group summary estimators. See Details |
| iter | Should progress be shown? Default is |
Object of class athletemonitoring
Extra arguments ...
involve use_counts
for nominal model
# Load monitoring data set data("monitoring") # Filter out only 'Training Load' monitoring <- monitoring[monitoring$Variable == "Training Load", ] # Convert column to date format (or use numeric) monitoring$Date <- as.Date(monitoring$Date, "%Y-%m-%d") # Run the athlete monitoring data preparation prepared_data <- prepare( data = monitoring, athlete = "Full Name", date = "Date", variable = "Variable", value = "Value", acute = 7, chronic = 42, # How should be missing entry treated? # What do we assume? Zero load? Let's keep NA NA_session = NA, # How should missing days (i.e. no entries) be treated? # Here we assume no training, hence zero NA_day = 0, # How should be multiple day entries summarised? # With "load", it is a "sum", witho other metrics that # do not aggregate, it can me "mean" day_aggregate = function(x) { sum(x, na.rm = TRUE) }, # Rolling estimators for Acute and Chronic windows rolling_estimators = function(x) { c( "mean" = mean(x, na.rm = TRUE), "sd" = sd(x, na.rm = TRUE), "cv" = sd(x, na.rm = TRUE) / mean(x, na.rm = TRUE) ) }, # Additional estimator post-rolling posthoc_estimators = function(data) { data$ACD <- data$acute.mean - data$chronic.mean data$ACR <- data$acute.mean / data$chronic.mean data$ES <- data$ACD / data$chronic.sd # Make sure to return the data return(data) }, # Group summary estimators group_summary_estimators = function(x) { c( "median" = median(x, na.rm = TRUE), "lower" = quantile(x, 0.25, na.rm = TRUE)[[1]], "upper" = quantile(x, 0.75, na.rm = TRUE)[[1]] ) } )#>#>#>#>#># Get summary prepared_data#> Athlete monitoring numeric data with the following characteristics: #> #> 10 athletes: #> Alan McDonald, Ann Whitaker, Eve Black, Frank West, John Doe, Michael Peterson, Mike Smith, Peter Jackson, Stuart Rogan, Susan Kane #> #> 363 days: #> From 18263 to 18625 #> #> 5200 total entries #> #> 0 missing entries #> 510 missing days #> #> 1 variables: #> Training Load #> #> 10 estimators: #> variable.value, acute.mean, acute.sd, acute.cv, chronic.mean, chronic.sd, chronic.cv, ACD, ACR, ES#> # A tibble: 10 x 15 #> athlete variable `Total entries` `Day entries` `Missing entrie… #> <chr> <chr> <dbl> <int> <dbl> #> 1 Alan McDonald Training Load 520 363 0 #> 2 Ann Whitaker Training Load 520 363 0 #> 3 Eve Black Training Load 520 363 0 #> 4 Frank West Training Load 520 363 0 #> 5 John Doe Training Load 520 363 0 #> 6 Michael Peterson Training Load 520 363 0 #> 7 Mike Smith Training Load 520 363 0 #> 8 Peter Jackson Training Load 520 363 0 #> 9 Stuart Rogan Training Load 520 363 0 #> 10 Susan Kane Training Load 520 363 0 #> # … with 10 more variables: Missing days <dbl>, Start date <date>, #> # Stop date <date>, Mean <dbl>, SD <dbl>, Min <dbl>, Max <dbl>, Median <dbl>, #> # IQR <dbl>, MAD <dbl>## Plots # Table plot # Produces formattable output with sparklines plot( prepared_data, type = "table", # Use to filter out estimators estimator_name = c("acute.mean", "chronic.mean", "ES", "chronic.sd", "chronic.cv"), # Use to filter out athlete # athlete_name = NULL, # Use to filter out variables # variable_name = NULL, # Show last entries last_n = 42, # Round numbers digits = 2 ) # Bar plot # To plot group average plot( prepared_data, type = "bar" )#>#> Warning: Removed 42 row(s) containing missing values (geom_path).#> Warning: Removed 42 row(s) containing missing values (geom_path).#> Warning: Removed 420 row(s) containing missing values (geom_path).#> Warning: Removed 420 row(s) containing missing values (geom_path).# To filter out athletem variable and add Acute and Chronic lines to the group average: plot( prepared_data, type = "bar", # To filter out athletes # athlete_name = NULL, # To filter out variable # variable_name = NULL, # Add acute mean acute_name = "acute.mean", # Add chronic mean chronic_name = "chronic.mean", # Plot last n entries/days last_n = 42 )#># If you want to plot for each athlete, use trellis=TRUE plot( prepared_data, type = "bar", acute_name = "acute.mean", chronic_name = "chronic.mean", last_n = 42, trellis = TRUE )# Line plots # These plots represent summary of the rollins estimators plot( prepared_data, type = "line", # To filter out athletes # athlete_name = NULL, # To filter out variables # variable_name = NULL, # To filter out estimators # estimator_name = NULL, # Tell graph where the lower group estimator is # which is in this case 25%th percentile of the group group_lower_name = "group.lower", # The name of the centrality estimator of the group group_central_name = "group.median", # Tell graph where the upper group estimator is # which is in this case 75%th percentile of the group group_upper_name = "group.upper", # Use trellis if you do not plot for a single individual trellis = TRUE )# Previous chart looks messy because it plot all athletes # To avoid that, filter out only one athlete plot( prepared_data, type = "line", # To filter out athletes athlete_name = "Ann Whitaker", group_lower_name = "group.lower", group_central_name = "group.median", group_upper_name = "group.upper", trellis = TRUE )# Calendar heatmap plot plot( prepared_data, type = "calendar", # To filter out athletes athlete_name = "Ann Whitaker", # To filter out variables variable_name = "Training Load", # To print estimator estimator_name = "variable.value", # Or use "entries" # To filter out last days last_n = 365, # To setup colors low_color = "white", high_color = "red", na_color = "grey50", # Should the whole year be plotted? # Otherwise full months are plotted full_year = FALSE, # Should year label be plotted? # in the case of multiple years involved # it is always plotted year_label = FALSE, # Short weekdays? short_weekday = TRUE, # Label size label_size = 2, # Aggregation function in the case multiple athletes/variables/levels are used aggregate_func = mean )# Nominal data # Create nominal variable monitoring$Value_nominal <- cut( monitoring$Value, breaks = 5, labels = c("Very Easy", "Easy", "Medium", "Hard", "Very Hard"), include.lowest = TRUE) # Run the athlete monitoring data preparation prepared_data <- prepare( data = monitoring, athlete = "Full Name", date = "Date", variable = "Variable", value = "Value_nominal", acute = 7, chronic = 42, # How should be missing entry treated? NA_session = "<<<Session Missed>>>", # How should missing days (i.e. no entries) be treated? NA_day = "<<<Day Missed>>>", # How should be multiple day entries summarised? # This is different with levels, for example # when there are two sessions, one is Low and one Hard # if you use mean, then Low and Hard will be 0.5, with sum # both will be 0.5, in which case the level probabilities will be # summed to 1 day_aggregate = function(x) { mean(x, na.rm = TRUE) }, # Rolling estimators for Acute and Chronic windows rolling_estimators = function(x) { c( "prop" = mean(x, na.rm = TRUE) ) }, # Additional estimator post-rolling posthoc_estimators = function(data) { data$ACD <- data$acute.prop - data$chronic.prop data$ACR <- data$acute.prop / data$chronic.prop # Make sure to return the data return(data) }, # Group summary estimators group_summary_estimators = function(x) { c( "median" = median(x, na.rm = TRUE), "lower" = quantile(x, 0.25, na.rm = TRUE)[[1]], "upper" = quantile(x, 0.75, na.rm = TRUE)[[1]] ) } )#>#>#>#>#>#>prepared_data#> Athlete monitoring nominal data with the following characteristics: #> #> 10 athletes: #> Alan McDonald, Ann Whitaker, Eve Black, Frank West, John Doe, Michael Peterson, Mike Smith, Peter Jackson, Stuart Rogan, Susan Kane #> #> 363 days: #> From 18263 to 18625 #> #> 34260 total entries #> #> 0 missing entries #> 510 missing days #> #> 1 variables: #> Training Load #> #> 6 levels: #> <<<Day Missed>>>, Easy, Hard, Medium, Very Easy, Very Hard #> #> 5 estimators: #> variable.value, acute.prop, chronic.prop, ACD, ACR#> # A tibble: 60 x 10 #> athlete variable level `Total entries` `Day entries` `Missing entrie… #> <chr> <chr> <fct> <int> <int> <int> #> 1 Alan McDo… Training … Very Ea… 571 363 0 #> 2 Alan McDo… Training … Easy 571 363 0 #> 3 Alan McDo… Training … Medium 571 363 0 #> 4 Alan McDo… Training … Hard 571 363 0 #> 5 Alan McDo… Training … Very Ha… 571 363 0 #> 6 Alan McDo… Training … <<<Day … 571 363 0 #> 7 Ann Whita… Training … Very Ea… 571 363 0 #> 8 Ann Whita… Training … Easy 571 363 0 #> 9 Ann Whita… Training … Medium 571 363 0 #> 10 Ann Whita… Training … Hard 571 363 0 #> # … with 50 more rows, and 4 more variables: Missing days <int>, #> # Start date <date>, Stop date <date>, Proportion <dbl># Plots plot( prepared_data, type = "line", # To filter out athletes athlete_name = "Ann Whitaker", # To filter out variables variable_name = "Training Load", # To filter out estimators estimator_name = "acute.prop", group_lower_name = "group.lower", group_central_name = "group.median", group_upper_name = "group.upper", trellis = TRUE )