Evaluating the effects of increasing physical activity to optimize rehabilitation outcomes in hospitalized older adults (MOVE Trial): study protocol for a randomized controlled trial
Department of Physiotherapy, School of Allied Health, La Trobe University, Kingsbury Drive, Bundoora 3086, Victoria, Australia
Department of Physiotherapy, Austin Health, 145 Studley Rd, Heidelberg 3084, Victoria, Australia
Department of Physiotherapy, Melbourne School of Health Sciences, The University of Melbourne, Parkville 3010, Victoria, Australia
Department of Psychiatry & National Ageing Research Institute, The University of Melbourne, Parkville 3050, Victoria, Australia
Rehabilitation and Aged Services, Monash Health, Warrigal Rd, Cheltenham 3192, Victoria, Australia
Monash Ageing Research Centre (MONARC), Monash University, Warrigal Rd, Cheltenham 3192, Victoria, Australia
Melbourne EpiCentre, The University of Melbourne and Melbourne Health, Parkville 3050, Victoria, Australia
School of Physiotherapy and Exercise Science, Curtin University, Kent St, Bentley 6102, Western Australia, Australia
Aged Care Services, Austin Health, 300 Waterdale Rd, Heidelberg West 3081, Victoria, Australia
Department of Medicine, The University of Melbourne, Parkville 3010, Victoria, Australia
Statistics and Decision Analysis Academic Platform, The Florey Institute of Neuroscience & Mental Health, 245 Burgundy St, Heidelberg 3084, Victoria, Australia
Stroke Division, The Florey Institute of Neuroscience and Mental Health, 245 Burgundy St, Heidelberg 3084, Victoria, Australia
Older adults who have received inpatient rehabilitation often have significant mobility disability at discharge. Physical activity levels in rehabilitation are also low. It is hypothesized that providing increased physical activity to older people receiving hospital-based rehabilitation will lead to better mobility outcomes at discharge.
A single blind, parallel-group, multisite randomized controlled trial with blinded assessment of outcome and intention-to-treat analysis. The cost effectiveness of the intervention will also be examined. Older people (age >60 years) undergoing inpatient rehabilitation to improve mobility will be recruited from geriatric rehabilitation units at two Australian hospitals. A computer-generated blocked stratified randomization sequence will be used to assign 198 participants in a 1:1 ratio to either an ‘enhanced physical activity’ (intervention) group or a ‘usual care plus’ (control) group for the duration of their inpatient stay. Participants will receive usual care and either spend time each week performing additional physical activities such as standing or walking (intervention group) or performing an equal amount of social activities that have minimal impact on mobility such as card and board games (control group). Self-selected gait speed will be measured using a 6-meter walk test at discharge (primary outcome) and 6 months follow-up (secondary outcome). The study is powered to detect a 0.1 m/sec increase in self-selected gait speed in the intervention group at discharge. Additional measures of mobility (Timed Up and Go, De Morton Mobility Index), function (Functional Independence Measure) and quality of life will be obtained as secondary outcomes at discharge and tertiary outcomes at 6 months follow-up. The trial commenced recruitment on 28 January 2014.
This study will evaluate the efficacy and cost effectiveness of increasing physical activity in older people during inpatient rehabilitation. These results will assist in the development of evidenced-based rehabilitation programs for this population.
Australian New Zealand Clinical Trials Registry ACTRN12613000884707 (Date of registration 08 August 2013); ClinicalTrials.gov Identifier NCT01910740 (Date of registration 22 July 2013).
The aging population represents a significant and growing challenge to the Australian 1 , US 2 and other healthcare systems 3 . In Australia in 2011 and 2012, people aged over 65 years accounted for 48% of all hospital bed days and 39% of hospital discharges 4 , despite only representing 14.4% of the population 1 . Older people often require inpatient mobility rehabilitation after discharge from an acute hospital to enable them ‘to reach and maintain their optimal physical, sensory, intellectual, psychological and social functional levels’ 5 . In turn, this can help them to return to previous living arrangements and lifestyle.
Mobility outcomes following rehabilitation are often poor in older adults. Many older people are frail and have impaired mobility on admission to an inpatient geriatric rehabilitation unit, and evidence indicates that mobility outcomes remain suboptimal in many older people following discharge from these facilities 6 , 7 . For example, a recent study found that 14% of older people discharged from an inpatient geriatric rehabilitation unit were unable to walk 10 meters 6 . Of those who could walk 10 meters, only 31% were independent when walking up stairs. Gait speed was also reduced, with a very low median speed of 0.46 m/sec (IQR = 0.32), compared to a mean speed of 1.2 to 1.3 m/sec in healthy older adults 6 . Mobility problems commonly persist following discharge, with only 41% of older adults being able to walk 800 meters or climb a flight of stairs 3 months after discharge 7 . Poor mobility can have serious consequences for older adults. It is associated with the need for long-term care 8 , loss of functional independence and mortality 9 and falls 10 . It is therefore important to maximize recovery of mobility in older people with mobility disability.
While it is widely believed that bed rest and inactivity in hospital are detrimental for mobility and function 11 , there are no definitive clinical guidelines on optimum physical activity levels for older adults undergoing inpatient rehabilitation. Despite the publication of physical activity guidelines for older people 12 - 15 , a gap exists in guidelines for frail older people or those who have multiple chronic diseases and are undergoing rehabilitation. A number of studies indicate that activity levels in rehabilitation are low 16 - 18 and that physical activity levels in aged care rehabilitation are particularly low 19 . This raises the possibility that better outcomes could be achieved by adding interventions, strategies and systems to increase physical activity. Increasing physical activity is a simple intervention likely to have a positive impact on recovery of mobility.
Surprisingly, there is limited research examining the effect of increasing physical activity on mobility outcomes in hospitalized older people undergoing rehabilitation. These patients typically have a wide variety of admission diagnoses and multiple co-morbidities, which may include cognitive impairment 6 . As a consequence, they are often excluded from clinical trials. A recent systematic review 20 found providing hospitalized patients with an additional average of 19 minutes physiotherapy per day led to improvements in mobility and quality of life and reductions in length of stay. However, the average age of participants in the review was only 69.8 years. There is some evidence that a multidisciplinary exercise intervention in an acute hospital reduces acute length of stay and increases the proportion of older people who return home 21 . There is also promising evidence that increasing physical activity in a range of outpatient, home and residential care settings can improve outcomes in some older people 22 - 24 . A pilot study conducted by our group demonstrated the feasibility of utilizing a randomized controlled trial (RCT) to examine the impact of increased physical activity on mobility outcomes in older people receiving inpatient geriatric rehabilitation. A satisfactory recruitment and retention rate was achieved, protocols to increase physical activity were developed, increases in physical activity were obtainable, there was no evidence of group contamination, and there was no increase in adverse events 25 . Given the success of the pilot trial and the potential for mobility improvements via increasing physical activity, a larger and appropriately powered RCT to further explore the efficacy of increasing physical activity in older people on mobility and other outcomes is warranted.
The proposed study will test the primary hypothesis that increasing physical activity in older people during rehabilitation, compared with a control group, will lead to better mobility at discharge, as measured by self-selected gait speed. Secondary hypotheses follow concerning the increase of physical activity during rehabilitation:
1. It will lead to significantly greater improvements in secondary measures of mobility and function both at discharge and 6 months after discharge.
2. It will lead to a better quality of life 6 months after hospital discharge.
3. It will be cost effective compared to usual care.
An investigator and assessor-blinded, parallel group multisite RCT will be used to compare enhanced physical activity to ‘usual care plus’ provided to older people receiving in-hospital geriatric rehabilitation at hospitals in the Melbourne metropolitan area of Victoria, Australia. Figure
Figure 1
Participant flow-through study.
Participant flow-through study. TUG, Timed up and go; DEMMI, De Morton Mobility Index; FIM, Functional Independence Measure; EQ5D, Euro QoL Health Questionnaire; EQ-VAS, Euro QoL, Visual Analog Scale.
Older people will be recruited within 48 hours of admission to rehabilitation and geriatric evaluation and management wards of the participating hospitals. People admitted to these wards are medically stable, but may have chronic or complex health conditions that require treatment and management by a multidisciplinary team, or require a period of rehabilitation to maximize function. A member of the research team will screen each person upon admission and approach potential participants in person. To be included in the study, participants must be aged 60 years or older and have a goal of admission to ‘improve mobility or improve walking’ as determined by admission referral or the treating therapist. Participants will be excluded if (1) there are specific medical restrictions that limit mobilization, (2) mobility goals are limited to non-weight bearing mobility goals, (3) they are already enrolled in an RCT, or (4) the primary reason for admission is to await residential care or carer training. Informed consent will be obtained from the participant, or ‘responsible person’ if the participant is unable to give consent due to cognitive impairment. Interpreters will enable recruitment of people who are non-English speaking.
As study site and mobility on admission are potential confounders, randomization will be blocked and stratified by site and mobility level. At baseline, the mobility of participants will be classified as either non-ambulant (Level 1 or 2 as detailed in Table 1) or ambulant (Level 3 or 4 as detailed in Table 1) . This classification will be used for stratification by mobility level. Once consent has been obtained and baseline data collected, participants will be individually randomized to an intervention group (enhanced physical activity) or a control group (usual care plus) according to a computer generated randomization procedure performed by a third party. Group assignment will only be available to intervention staff and the project manager, and will be accessed online via a password protected site.
|
Level |
Function |
Intervention |
|
1 |
Patient is unable to transfer out of bed without maximum assistance (two persons or a hoist) and has poor static and dynamic sitting balance (unable to sit independently). |
Bed exercise program (including lower limb, upper limb and abdominal strength and bed mobility) and sitting balance exercises. |
|
2 |
Patient can transfer out of bed with assistance from one person, has independent sitting balance, but is unable to stand independently. Requires moderate assistance from two people to walk. |
Sitting exercise program including targeted lower limb strengthening exercises. Sit to stand exercises, standing balance exercises, stepping/marching on the spot as able (using rails/ gait aids for safety as indicated). Activities from the previous level may be included if specifically indicated. For example, if the participant is unable to perform full range movement against the effects of gravity, specific lower limb muscle strengthening exercises may be performed on the bed. |
|
3 |
Patient can walk with minimal assistance from one person. |
Walking exercises, sit to stand exercises, standing balance exercises, and step up exercises. Targeted lower limb strength exercises (where possible closed chain or functional strengthening exercises). |
|
4 |
Supervision only or independence with ambulation. Requires minimal assistance or supervision on stairs. |
Stairs exercises, walking exercises (including outdoor mobility), step up exercises, standing balance exercises. Targeted lower limb strength exercises as indicated (where possible closed chain or functional strengthening exercises). |
The primary outcome measure is mobility on discharge from hospital as assessed using gait speed. This will be measured using the 6-meter walk test 27 at self-selected speed by a trained assessor blinded to group allocation. Participants will be instructed to walk at self-selected speed along a 10-meter walkway, and a stopwatch will be used to measure speed over the middle 6 meters. Participants will be allowed to use a gait-aid if required, and this will be recorded. Up to three trials will be performed, and the best performance recorded. Participants unable to complete the test will be given a score of 0 m/sec. Gait speed was chosen as a primary outcome measure as it is associated with the need for long-term care 8 , functional dependence, mortality 9 and falls 10 . Gait speed can also predict activity levels at home and in the community 28 , 29 and increases in gait speed are associated with improvements in overall health status 30 . Furthermore, gait speed has good retest reliability 27 , 31 and is responsive to changes in walking ability 32 - 34 .
Secondary outcome measures include mobility on discharge from hospital as assessed using the Timed Up and Go (TUG) 31 , 35 and the De Morton Mobility Index (DEMMI) 36 - 38 . Gait speed will also be measured 6 months postdischarge as a secondary outcome measure. Additional secondary outcomes include function, as measured using the Functional Independence Measure (FIM TM) 39 , health-related quality of life, as measured by the EuroQol health questionnaire (EQ5D) and the EuroQol Visual Analog Scale (EQ-VAS) 40 and subacute length of stay (LOS). These tests will be administered in accordance with previously published protocols. If a participant is unable to complete the EQ5D or EQ-VAS due to cognitive impairment, a proxy will complete it on their behalf.
Tertiary outcomes of mobility, function and quality of life will be obtained 6 months postdischarge, using the TUG 31 , 35 , the DEMMI 36 - 38 , the FIM 39 , the EQ5D and the EQ-VAS.
Falls will be monitored throughout the study. Falls will be defined as ‘an unexpected event in which you come to rest on the ground, floor or lower level’ 41 . Data on falls during the period of hospitalization will be obtained via review of medical records and hospital incident reports. Falls in the 6 months postdischarge will be recorded prospectively via a monthly falls calendar provided to participants at discharge. Participants will be asked to record the date of any falls and whether or not advice or treatment from a health professional had been sought related to the fall. They will be asked to return the calendar at the end of each month, and will receive a telephone reminder if the falls calendar is not returned. This method of falls data collection is considered the ‘gold standard’ for collecting falls data 41 .
Each assessment will be completed at three time points by an assessor blinded to group allocation. All assessors will be trained to ensure the assessments are standardized and will be FIM TM credentialed.
The baseline assessment will be completed within 48 hours of admission. In addition to primary and secondary outcome measures collected at baseline, additional demographic and clinical data will be obtained. These data will include the participant’s age, sex, height and weight, acute LOS, mental state (measured by the Mini Mental State Examination 42 ), frailty (measured using the modified Fried Frailty Index) 43 , 44 , co-morbidities (age adjusted Charlson Comorbidity Score 45 ), depression (Geriatric Depression Scale 46 ), medications, self (or carer) reported falls in the last 12 months and social situation.
The second assessment will be completed within 48 hours of discharge. Self-selected gait speed (primary outcome) at this assessment will be the primary endpoint of the study. In addition to the primary and secondary outcome assessments, discharge destination and service referrals on discharge will also be collected. For participants discharged to residential care, the day the treating team determined that they required residential care placement and required paperwork was completed will be used in lieu of actual discharge date for this analysis.
The third and final assessment will be conducted 6 months postdischarge in the person’s residence. In addition to further secondary and tertiary outcome assessments, falls data and any associated health professional advice or treatment will be collected.
Both the intervention and control group will be provided with usual care, which will include ongoing therapy provided by a multidisciplinary team including nurses, medical staff, physiotherapists, occupational therapists and other allied health professionals as required throughout their in-patient rehabilitation. Both groups will receive additional therapy sessions, but the content of these sessions will differ depending on group allocation.
In addition to usual care, participants in the enhanced physical activity intervention group will undertake 1 to 2 sessions of additional physical activities on weekdays, and a further two sessions each weekend throughout their inpatient stay (anticipated average of 19 days, based on data from the participating hospitals). Programs will be individually tailored with the aim of increasing the amount of time participants spent performing mobility exercises, such as standing or walking. Intervention protocol guides, which were trialed in the pilot study, 25 will be specified for participants according to their functional level (summary provided in Table 1; full details provided in trial manual available from authors). Specific targets for activity levels on weekdays and weekends have been set, based on pilot data 19 , 25 . All sessions will be provided by a physiotherapist or physiotherapy assistant not involved in the provision of usual care to participants. At the end of each intervention session, the physiotherapist or allied health assistant will record the amount of time spent performing each activity in 5-minute increments. No specific program to be completed outside of these sessions will be provided.
To control for the extra hours of social interaction received by participants in the enhanced physical activity group, participants in the control group will undertake additional seated or resting social activities including card and board games, conversation and reading, as well as upper limb and other physical exercises that have minimal impact on mobility. These sessions will be provided by either a physiotherapist or physiotherapy assistant, and time involved in these sessions will be recorded.
All assessments will be performed by clinicians blinded to group allocation. All investigators, with the exception of the project manager (JW) will remain blinded to group assignment. Staff providing the intervention cannot be blinded. To minimize the risk of usual-care staff altering practice during the period of data collection, staff not directly involved in the research will not be told the specific aims of the study. As it is essential that activity delivered as part of the intervention is in addition to usual care, intervention staff will not be involved in other aspects of patient care. To monitor usual-care activities, usual-care physiotherapy staff will record the amount of time performing various activities in physiotherapy sessions for all participants in five minute increments. To ensure the correct ‘dosage’ of intervention activity is delivered, time spent performing upright activities will be monitored, and feedback on dose will be provided to intervention therapists by the project manager. To monitor for activity levels and contamination throughout the day, participants in both study groups will have their activity levels monitored over a 5-day period using a SenseWear armband 47 - 49 . Regular monitoring of activity will help identify deviations from protocol and potential contamination of usual care. These data will be reviewed monthly by the Project Management Committee and strategies to address any issues implemented.
There is a risk that the intervention may result in an increase in adverse events, although no differences between groups were reported in the pilot study 25 . In the event of a fall or medical event, standard hospital procedures will be followed. Falls during hospital stay, mortality and unplanned re-admissions to an acute service (during rehabilitation or within six months postdischarge) will be recorded on an incident form, monitored by an independent Data Safety and Monitoring Committee and reported to the relevant ethics committees.
All data will be stored in a confidential manner. Participants will be assigned a code, which will be used for all data management and analyses. Paper data will be stored at the local site in a locked filing cabinet. Coded electronic data will be stored on a computer server at The Florey Institute of Neuroscience and Mental Health for the duration of the study. Access to the computer files will be password-protected and accessible only to the research team. Data quality will be monitored by the project manager on a regular basis and reported to the management committee. The project manager will also conduct regular site visits to monitor trial conduct. All project investigators will have access to the final, de-identified data set.
The sample size for this study was calculated based on pilot data, which showed that the median gait speed of people discharged from aged care rehabilitation was 0.46 m/sec (range 0.1 to 1.2 m/sec) 6 , which allowed a mean gait speed (0.46 m/sec) and variance (0.18 m/sec) to be estimated 50 . Sample size estimation was based on the intervention group achieving an increase in gait speed of at least 0.1 m/sec compared with the control group, the recommended minimal clinically important difference for gait speed in older adults 30 , 51 . With a two-tailed significance threshold alpha of 0.05 and power to yield a statistically significant result set at 90%, a sample size of 69 participants in each group is required. To account for an estimated 25% dropout rate and 14% of participants being unable to complete the walk test on discharge, as observed in pilot data 6 , 25 , an estimated 198 participants will be required in total 52 . A recruitment rate of 34% was achieved in the pilot study. Based on average hospital admissions to the selected sites in this trial, and using a conservative recruitment rate of 20%, it is anticipated that the recruitment will be completed over 13 months.
The primary analysis will be conducted on an intention-to-treat basis using data from all randomized participants, although a ‘per protocol’ analysis of the primary outcome will also be reported. Primary outcome values missing due to participants’ death will be imputed as zero. An independent adjudication panel, blinded to group assignment, will review records for participants’ who were discharged to an acute facility as medically unwell. Based on the reasons for transfer, the adjudication panel will determine whether the participant was likely to be able to walk and complete a 6-meter walk test at the time of transfer. If the adjudication panel determines the person was unlikely to be able to walk, the missing value will be imputed as zero. If the adjudication panel determines the person was likely to be able to walk, the last measure will be carried forward. Following that, multiple imputation of other missing primary outcome values will be conducted subject to the satisfaction of relevant missingness assumptions. Baseline data will be examined to ensure that the intervention and control groups are comparable using descriptive statistics with 95% confidence intervals.
All outcomes and analyses have been prospectively categorized as primary, secondary, or tertiary. Differences in both primary and secondary endpoints between the two arms of the study will be tested independently at the 0.05 level of significance. No formal adjustments will be undertaken to constrain the overall type I error associated with the secondary analyses. Their purpose is to supplement evidence from the confirmatory primary analysis to help more fully characterize the treatment effect. Results from the secondary analyses will be interpreted in this context.
Between-group differences in the primary outcome measure, self-selected gait speed on discharge, will be assessed using a one-way ANCOVA model that will include self-selected gait speed at baseline as a covariate.
Between-group differences in gait speed 6 months postdischarge will be assessed using a one-way ANCOVA model that will include self-selected gait speed at baseline as a covariate;
Between-group differences in TUG on discharge will be assessed using a Cox regression model that will include self-selected gait speed at baseline as a covariate;
Between-group differences in DEMMI score on discharge will be assessed using a one-way ANCOVA model that will include DEMMI score at baseline as a covariate;
Between-group differences in FIM score on discharge will be assessed using a median regression model that will include the FIM score at baseline as a covariate;
Between-group differences in EQ5D score on discharge will be assessed using a median regression model that will include the EQ5D score at baseline as a covariate;
Between-group differences in subacute LOS will be assessed using a median regression model that will include the FIM score at baseline as a covariate.
Between-group differences in the outcomes at 6 months postdischarge will be assessed using appropriate regression models that will include relevant measures at baseline as covariates. The exploratory longitudinal analysis for all outcomes over the period from baseline until 6 months postdischarge will be conducted using a mixed model repeated measures approach subject to the satisfaction of the underlying model assumptions.
Health economic modelling will be undertaken to estimate the potential cost-effectiveness of the intervention arm compared to the control arm. Decision analysis 53 will be used to compare downstream consequences of enhanced physical care and Markov 54 and life-tabling 55 techniques will be applied to model outcomes beyond one year. The main output of interest will be incremental cost-effectiveness ratios in terms of net costs per unit of health gain. Net costs will comprise the costs of the enhanced physical activity program minus costs saved from the reduction in downstream health services utilization. Data on health services utilization will include clinical costing data provided by the hospitals, as well as data from the Australian Medical Benefits Scheme (MBS) and Pharmaceutical Benefits Scheme (PBS). The MBS and PBS are the programs through which clinical services and medications, respectively, are subsidized for Australians. Health gains can be measured in a variety of ways. For the proposed study, in addition to clinical outcomes, we will estimate years of life gained and quality-adjusted life years (QALYs) gained. Both will be enabled by the collection of time-to-outcome data and the latter also by collection of the EuroQoL Quality of Life data. All health economic analyses will be undertaken in accordance with recommended approaches, such as 5% discounting of estimated future costs and health gains. To account for any uncertainty in the data inputs for health economic modelling, sensitivity and uncertainty analyses will be undertaken using Monte Carlo simulation techniques 56 .
Authors CMS and MM are responsible for overseeing all aspects of the project. Project management support is provided by JW, and additional project management was provided by Neurosciences Trials Australia during the setup phase. The project will be overseen by the project management committee, which consists of CMS, MM, JMcG, CSz, BW, DL, KH, MW, JW and JB and a community representative. This committee meets on a monthly basis. Funding agreements will be entered into between the administering institution and all collaborating institutions. An independent Data Safety Monitoring Committee, comprising a geriatrician and a physiotherapist, both with significant clinical research expertise, will monitor the trial.
The results of the trial will be presented in international peer-reviewed journals and presented at conferences. Decisions about publications arising from the data set will be ratified by the Management Committee and all named investigators will be eligible to have authorship on publications arising from the trial. Trial staff will also provide workshops to clinicians to assist the translation of findings to clinical practice.
Loss of mobility is a major determinant of the need for inpatient rehabilitation for older adults 57 . However, there is currently little evidence to guide clinicians in the management for older people admitted to rehabilitation. It is hypothesized that optimizing physical activity will lead to improved mobility outcomes for this population. It has been established that programs designed to increase physical activity during inpatient rehabilitation can be delivered to most older patients, but whether increasing physical activity during hospitalization is efficacious or cost-effective has not been tested. This study will assess both the shorter and longer term (6 months following discharge) functional outcomes and healthcare utilization of participants who undergo a program to increase their physical activity in addition to usual rehabilitation compared to those who only receive usual rehabilitation plus social interaction. The results of this study will inform current rehabilitation practice in Australia and worldwide, and will contribute to the development of clinical practice guidelines.
The trial commenced recruitment on 28 January 2014 and is currently open for recruitment. Recruitment will cease when 198 participants have been randomized. It is anticipated this target will be reached by April 2015.
ACTRN: Australian New Zealand Clinical Trials Registry
CONSORT: Consolidated Standards of Reporting Trials
DEMMI: De Morton Mobility Index
EQ5D: Euro QoL Health Questionnaire
EQ-VAS: Euro QoL Visual Analog Scale
FIM: Functional Independence Measure
IQR: interquartile range
LOS: length of stay
NHMRC: National Health and Medical Research Council
QALYs: quality-adjusted life years
RCT: randomized controlled trial
TUG: timed up and go
The authors declare that they have no competing interests.
The protocol was developed by CMS, MM, JMcG, CSz, JB, KH, DL, MW, and BW. JW is the project manager and has contributed to the refinement of the protocol. LC provided advice on statistical analysis. CMS, CV and MM prepared the initial manuscript. All authors reviewed the final manuscript prior to submission. All authors read and approved the final manuscript.
The study has been funded by a National Health and Medical Research Council project grant (NHMRC) (App1042680).
Australian Bureau of Statistics
An aging population and growing disease burden will require alarge and specialized health care workforce by 2025
Australian Institute of Health and Welfare
Mobility on discharge from an aged care unit
Mobility-related disability three months after aged care rehabilitation can be predicted with a simple tool: an observational study
A prospective trial of serial gait speed as a measure of rehabilitation in the elderly
Mobility difficulties and physical activity as predictors of mortality and loss of independence in the community-living older population
The Patient Who Falls: “It’s Always a Trade-off”
Predictors of functional decline in hospitalized elderly patients: a systematic review
U.S. Department of Health and Human Services
Physical activity and public health in older adults: recommendation from the American College of Sports Medicine and the American Heart Association
Physical activity recommendations for older Australians
Stand up and be counted: measuring time spent upright after hip fracture and comparison with community dwelling older people
Stroke rehabilitation: are highly structured units more conducive to physical activity than less structured units?
Determinants of walking function after stroke: Differences by deficit severity
Physical activity by elderly patients undergoing inpatient rehabilitation is low: an observational study
Extra physical therapy reduces patient length of stay and improves functional outcomes and quality of life in people with acute or subacute conditions: a systematic review
Exercise for acutely hospitalised older medical patients
Rehabilitation for older people in long-term care
Interventions for promoting mobility in community-dwelling older adults
A randomized trial of a multicomponent home intervention to reduce functional difficulties in older adults
Mobility in older adults receiving hospital based rehabilitation: A phase II feasibility study
CONSORT 2010 Explanation and Elaboration: updated guidelines for reporting parallel group randomised trial
Group ftC
Retest reliability of the temporal and distance characteristics of hemiplegic gait using a footswitch system
Studies of gait and mobility in the elderly
Relationship of clinic-based gait speed measurement to limitations in community-based activities in older adults
Walking speed predicts health status and hospital costs for frail elderly male veterans
Test-retest reliability and minimal detectable change scores for the Timed “Up & Go” Test, the Six-Minute Walk Test, and gait speed in people with Alzheimer disease
Gait after stroke: Initial deficit and changes in temporal patterns for each gait phase
Responsiveness and predictability of gait speed and other disability measures in acute stroke
Does functional reach improve with rehabilitation?
The timed “Up and Go”: a test of basic functional mobility for frail elderly persons
The de Morton Mobility Index (DEMMI) provides a valid method for measuring and monitoring the mobility of patients making the transition from hospital to the community: an observational study
The de Morton Mobility Index (DEMMI): An essential health index for an ageing world
Validity and reliability of the de Morton Mobility Index (DEMMI) in the subacute hospital setting in a geriatric evaluation and management (GEM) population
The Functional Independence Measure: A new tool for rehabilitation
EuroQol- a new facility for the measurement of health related quality of life
Development of a common data set for fall injury prevention trials: the Prevention of Falls Network Europe Consensus
“Mini Mental State”. A practical method of grading the cognitive state of patients for the clinician
Frailty in older adults
Frailty Intervention Trial (FIT)
A new method of classifying prognostic comorbidity in longitudinal studies: development and validation
Geriatric Depression Scale (GDS): recent evidence and development of a shorter version
Physical activity measured by the SenseWear Armband in women with rheumatoid arthritis
Validity of a multi-sensor armband in estimating rest and exercise energy expenditure
Validation of an armband to measure daily energy expenditure in older adults
Health, Aging, and Body Composition Study Group
Estimating the mean and variance from the median, range, and the size of a sample
Meaningful change and responsiveness in common physical performance measures in older adults
Decision analysis and the implementation of research findings
An introduction to Markov modelling for economic evaluation
Life table analysis
Handling uncertainty in cost-effectiveness models
1: Rehabilitation and older people


The prescribed dosage for ambien is normally anywhere from 5-10 mg. at night & I was on 5 mg. when needed for sleep, because I really do have sleeping problems, but knew you could (ab)use this drug to get stoned.
I read up on it a little bit & doubled up on my dose one night. I have taken anywhere from 10-25 mg. in one sitting, but I can get stoned from just 10 mg. It kicks in really fast (I can normally start to feel its effects in a few minutes) and when it has registered I feel sort of tingly, everything gets a little fuzzy and I have become very relaxed. A bit later I usually get a big urge to eat and end up bingeing on sweets or whatever but the ambien seems to heighten my sense of taste or something, because whatever I am eating tastes so amazing at the time I am consuming it. I feel like I am in a dream but in reality I am awake, walking around, talking, etc.
It can be scary because I will often times wake up in the morning & not have a damned clue what happened the night before. Try as I might the next day, I cannot remember. I've had conversations with people & I can't even recall what was said. I would never take this drug in an unfamiliar setting with people I didn't know well &/or trust, because I know it would be risky and one could get themselves into a lot of trouble doing that, no doubt. It is now very hard for me to sleep without it, and 5 mg. doesn't help like it used to anymore. All in all, it has been more trouble for me than it has been recreational. However, I continue to take it because it is the only sleep aid I have tried that does not make me feel exhausted and 'hung over' the next day. If you have sleeping problems to begin with I would not recommended taking more than has been prescribed for you.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Here at Swag Doctors we are committed to providing you with a total "wing to wing" solution for your enterprise infrastructure at a cost you'll love and always with a smile!
Find Out More"Ever since we started using the services provided by Swag Doctors we have not only saved a ton of money as a business, but we have also never had another missed SLA or have we had any downtime... EVER!" - SuperDopeYo Corp
Get Started!We have a reporting strategy that gets you insight on anything you may have at extremyly granular levels.
We have techincal packages for any environment small or extra-large
We provide SMEs for all of our customers regardless of size of the environment.
Our customers always come first! We have 24/7 staff to handle any requests no matter the size!
If our FAQ section cannot help please feel free to call or email us with any questions you may have!
1-800-SWAG-4-US


WITNESS LIST Public Safety Committee March 21, 2000-12:30P Truck Inspections For: Denholm, John (Harris County Sheriff's Dept.) Lindsey, Gary (Dallas County Sheriff's Dept.) West, Mike (Self) Zacharias, Larry (City of Richardson) On: Branton, John (Dallas Police Department) Lopez, Carlos (Dept. of Transportation) Mills, Lester (Dept. of Public Safety) Ormsto, Keith (Self) Webb, Bill (Texas Motor Transportation Association) For: Klausner, C.J. (Houston Police Department)


{% extends "insights_base.html" %} {% import "match_partials/match_table_macros.html" as mtm %} {% block title %}{{selected_year}} Insights - The Blue Alliance{% endblock %} {% block meta_description %}FIRST Robotics Competition insights from {{selected_year}}.{% endblock %} {% block detailed_content %}
Last updated on
{% endif %} {% if match_highscore or match_averages_by_week or score_distribution %}| Number | Teams |
|---|---|
| {{number}} | {% for team in team_list %} {{team|digits}}{% if not loop.last %},{% endif %} {% endfor %} |
| Number | Teams |
|---|---|
| {{number}} | {% for team in team_list %} {{team|digits}}{% if not loop.last %},{% endif %} {% endfor %} |
| # Correct | # Matches | % Correct | Brier Score | |
|---|---|---|---|---|
| All Qual | {{match_predictions.data.qual.correct_matches_count}} | {{match_predictions.data.qual.total_matches_count}} | {{'%0.2f' % (100 * match_predictions.data.qual.correct_matches_count / match_predictions.data.qual.total_matches_count|float)}} % | {{'%0.5f' % (match_predictions.data.qual.mean_brier_score|float)}} |
| All Playoff | {{match_predictions.data.playoff.correct_matches_count}} | {{match_predictions.data.playoff.total_matches_count}} | {{'%0.2f' % (100 * match_predictions.data.playoff.correct_matches_count / match_predictions.data.playoff.total_matches_count|float)}} % | {{'%0.5f' % (match_predictions.data.playoff.mean_brier_score|float)}} |
| Champs Qual | {{match_predictions.data.qual.correct_matches_count_cmp}} | {{match_predictions.data.qual.total_matches_count_cmp}} | {{'%0.2f' % (100 * match_predictions.data.qual.correct_matches_count_cmp / match_predictions.data.qual.total_matches_count_cmp|float)}} % | {{'%0.5f' % (match_predictions.data.qual.mean_brier_score_cmp|float)}} |
| Champs Playoff | {{match_predictions.data.playoff.correct_matches_count_cmp}} | {{match_predictions.data.playoff.total_matches_count_cmp}} | {{'%0.2f' % (100 * match_predictions.data.playoff.correct_matches_count_cmp / match_predictions.data.playoff.total_matches_count_cmp|float)}} % | {{'%0.5f' % (match_predictions.data.playoff.mean_brier_score_cmp|float)}} |
No insights are currently available for {{selected_year}}.
{% endif %} {% endblock %}


The simplest use of these classes is as follows:
::tycho::queryfont Times 12 Italic
9x15
and 10x20
, for
example, are particularly nice screen fonts -- the font manager
provides these as a pseudo font Screen
. When the user selects a
font, a sample is displayed.
The arguments passed to this procedure represent the initial font
to be displayed, as its family, size, and style. Any number may be
supplied (provided they remain in the right order). If none are
supplied, the font default to
Helvetica 12 Roman
.
The style can be one of Roman
, Italic
,
Bold
, or Bold Italic
-- if omitted, it
defaults to Roman
. Font family names and styles are all
case-insensitive.
OK
, or the name of the initial font if the used presses
Cancel
. This can be used to set fonts in any Tycho text
widget. For example, the following code will query the
user for a font selection:
::tycho::queryfont Lucida 14 BoldItalic
The FontDialog class returns only a symbolic representation of the
font. To convert this into a system-dependent font, use the
::tycho::font
procedure. For example:
set font [::tycho::queryfont Screen 14]
eval ::tycho::font $font
Screen
font in an italic style: you
will get a courier
font instead. The ::tycho::font
procedure will always return a valid system font, even if it cannot
find a reasonable one: as a last resort, it will return the font
fixed
.
The font manager provides procedures that give applications more
detailed control over fonts. Firstly, ::tycho::font
can
"shift" up or down by some number of sizes:
::tycho::font Screen 12 roman -2
::tycho::FontManager::size
:
::tycho::FontManager::size 11 +1
serif
, sans-serif
, and constant-width
.
To find out the families in a particular type, use
::tycho::FontManager::family
:
::tycho::FontManager::family serif
::tycho::queryfont
and ::tycho::font
, and the font manager will choose
a font of the given type. Unless your installation of
Tycho has changed the font manager settings, this window will
display the system-dependent name for 14-point Courier:
::tycho::font constant-width 14
::tycho::FontManager::family
again:
::tycho::FontManager::family serif Rockwell times
Family
menu.
FontManager class documentation
FontDialog class documentation
Tycho Home Page


Car crashes into home
by WFTX Digital TeamImmokalee Firefighters responded to a vehicle accident on Durso Court late Friday night.

North Collier Fire Rescue assisted with shoring up the home to prevent further damage. One person was transported to the hospital. The Collier County Sherrif's Office is investigating the cras


Product
Features
Pricing
Login
New
Monograph Dashboard
Powerful Insights Into Your Team
Project planning and time tracking
for agile teams.
Schedule a demo
to see a preview


Movie Pedia
Enter Title
Now you can click on Poster to check summary!
×
Movie Not Found!
Please Try typing the full Movie Title,
Remember Spaces are also considered
×
Title Can't Be Empty
×
Summary
X


ANTHELCIDE EQ- oxibendazole paste
Zoetis Inc.
DESCRIPTION: Anthelcide EQ Paste is a paste formulation of oxibendazole, a broad-spectrum benzimidazole anthelmintic. This formulation has been developed for ease of administration. Each syringe contains 0.85 oz (24 g) of paste.
| Anthelcide EQ Paste contains: | |
| Oxibendazole | 22.7% |
INDICATIONS: Anthelcide EQ Paste is indicated for removal and control of: large strongyles (Strongylus edentatus, S. equinus, S. vulgaris); small strongyles (species of the genera Cylicostephanus, Cylicocyclus, Cyathostomum, Triodontophorus, Cylicodontophorus, and Gyalocephalus); large roundworms (Parascaris equorum); pinworms (Oxyuris equi) including various larval stages; and threadworms (Strongyloides westeri).
CONTRAINDICATIONS: Anthelcide EQ is contraindicated in severely debilitated horses or horses suffering from infectious disease, toxemia, or colic.
PRECAUTIONS: Consult your veterinarian for assistance in the diagnosis, treatment, and control of parasitism.
Keep Out of Reach of Children.
DOSAGE AND ADMINISTRATION: The dosage of oxibendazole is 10 mg/kg (2.2 lb) of body weight (15 mg/kg for strongyloides). Each mark on the syringe delivers Anthelcide EQ to treat 100 lb (67 lb for strongyloides). Horses maintained on premises where reinfection is likely to occur should be retreated in 6–8 weeks.
| 10 mg/kg | 15 mg/kg | ||
|---|---|---|---|
| Syringe Mark | Horse Weight (lb) | Syringe Mark | Horse Weight (lb) |
| 100 | 100 | 300 | 200 |
| 200 | 200 | 600 | 400 |
| 400 | 400 | 900 | 600 |
| 600 | 600 | 1200 | 800 |
| 800 | 800 | ||
| 1000 | 1000 | ||
| 1200 | 1200 |
Anthelcide EQ is compatible with carbon disulfide, which can be used concurrently for bot control (Gasterophilus spp.) when administered by a veterinarian. Routine carbon disulfide cautions must be observed.
USE OF SYRINGE: Determine the weight of the horse and dial the correct setting on the plunger, having the side of the wheel nearest the barrel on the desired mark. Remove the cap from the syringe. Insert the tip of the syringe into the side of the animal's mouth between the incisor and molar teeth and press the plunger down as far as it will go, depositing the paste on the back of the tongue.
|
ANTHELCIDE EQ
oxibendazole paste | |||||||||||||||
| |||||||||||||||
| |||||||||||||||
| |||||||||||||||
|
| Labeler - Zoetis Inc. (828851555) |
| Establishment | |||
| Name | Address | ID/FEI | Business Operations |
|---|---|---|---|
| Zoetis LLC | 039055157 | MANUFACTURE |
| Establishment | |||
| Name | Address | ID/FEI | Business Operations |
|---|---|---|---|
| UQUIFA Mexico, S.A. DE C.V. | 810105874 | API MANUFACTURE |


- gain - Variable in class com.util.AudioPlayer
-
- GameController - Class in com.Game.controllers
-
Create and set the methods to manage the game in client and server side
- GameController(String, int, String) - Constructor for class com.Game.controllers.GameController
-
Constructor of the class GameController
- GameInterfaceController - Class in com.GUI.controllers
-
JavaFX controller of GameInterface interface
- GameInterfaceController(ArrayList<CartellaComponent>, GameController) - Constructor for class com.GUI.controllers.GameInterfaceController
-
- gameover - Variable in class com.Game.controllers.GameController
-
- gc - Variable in class com.GUI.controllers.StartingInterfaceController
-
- getAudioEffects() - Method in class com.util.TextToSpeech
-
Return a list of available audio effects for MaryTTS
- getAvailableVoices() - Method in class com.util.TextToSpeech
-
Available voices in String representation
- getCartella(int) - Method in class com.Game.controllers.Player
-
Get a card
- getCartellaAsArray(int) - Method in class com.Game.controllers.GameController
-
Convert a card in an Array of numbers
- getCartellaCount() - Method in class com.Game.controllers.GameController
-
Obtain the number of cards of a player
- getExtractions() - Method in class com.Game.controllers.GameController
-
Obtain the numbers that has been extracted
- getExtractions() - Method in class com.Game.Tomboliere
-
Get an ArrayList of extracted numbers
- getExtractions() - Method in class Server.Sessione
-
Get the number come out
- GetExtractionsServlet - Class in Server.servlets
-
(servlet) Manage the number extracted
- GetExtractionsServlet() - Constructor for class Server.servlets.GetExtractionsServlet
-
- getGainValue() - Method in class com.util.AudioPlayer
-
Returns the GainValue
- getLastWinningPhrase() - Method in class com.Game.controllers.GameController
-
Getter of lastWinningPhrase
- getLine() - Method in class com.util.AudioPlayer
-
- getMarytts() - Method in class com.util.TextToSpeech
-
- getNumber() - Method in class com.Game.Tomboliere
-
Number extractor
- getNumberForCallType(CallEnum) - Method in class com.Game.Tomboliere
-
Used to translate from CallEnum to Integer
- getNumeri() - Method in class com.Game.Cartella
-
Get the numbers of a card
- getPlayerName() - Method in class com.Game.controllers.GameController
-
Getter of an username
- getUsername() - Method in class com.Game.controllers.Player
-
Get the usarname of a player
- getWinnings() - Method in class com.Game.controllers.GameController
-
- getWinnings() - Method in class Server.Sessione
-
Get the winnings of a session
- goodUsername - Variable in class com.Game.controllers.GameController
-


Partnership with Guardian.gg!
We have recently made some friends over at Guardian.gg,
they love to collect all kinds of data and agreed to let us use anything we want to make our site more useful for you.
All they want in exchange is for you to visit and let them
know what kind of data and content you would like to see more of.
Right now nothing much has changed, we have replaced the Bungie rating with a custom
Elo rating that is calculated in-house by Guardian.gg
We are planning some big updates coming up so stay tuned and good luck this week Guardians!
As always, if you have any suggestions for us, or if you've found a bug, please feel free to send us a message.
Our contact info is below. See everyone soon!
If you come across any issue, error, or just want to send us a suggestion you can email us or open a ticket on GitHub.


|
Click
|
An IPv4 address. More...
Public Types | |
| typedef uninitialized_type | uninitialized_t |
| typedef IPAddress | parameter_type |
Public Member Functions | |
| IPAddress () | |
| Construct an IPAddress equal to <IP_ADDRESS>. More... | |
| IPAddress (unsigned x) | |
| Construct an IPAddress from an integer in network byte order. More... | |
| IPAddress (int x) | |
| IPAddress (unsigned long x) | |
| IPAddress (long x) | |
| IPAddress (struct in_addr x) | |
| Construct an IPAddress from a struct in_addr. More... | |
| IPAddress (const unsigned char *data) | |
| Construct an IPAddress from data. More... | |
| IPAddress (const String &x) | |
| Constructs an IPAddress from a human-readable dotted-quad representation. More... | |
| IPAddress (const uninitialized_type &unused) | |
| Construct an uninitialized IPAddress. More... | |
| bool | empty () const |
| Test if the address is <IP_ADDRESS>. More... | |
| uint32_t | addr () const |
| Return the address as a uint32_t in network byte order. More... | |
| operator uint32_t () const | |
| Return the address as a uint32_t in network byte order. More... | |
| bool | is_multicast () const |
| Return true iff the address is a multicast address. More... | |
| bool | is_link_local () const |
| struct in_addr | in_addr () const |
| Return a struct in_addr corresponding to the address. More... | |
| operator struct in_addr () const | |
| Return a struct in_addr corresponding to the address. More... | |
| unsigned char * | data () |
| Return a pointer to the address data. More... | |
| const unsigned char * | data () const |
| Return a pointer to the address data. More... | |
| uint32_t | hashcode () const |
| Hash function. More... | |
| int | mask_to_prefix_len () const |
| Returns the prefix length equivalent to this prefix mask, or -1 if this is not a prefix mask. More... | |
| bool | matches_prefix (IPAddress addr, IPAddress mask) const |
| Return true iff this address matches the address prefix addr/mask. More... | |
| bool | mask_as_specific (IPAddress mask) const |
| Return true iff this address, considered as a prefix mask, is at least as specific as mask. More... | |
| bool | mask_more_specific (IPAddress mask) const |
| Return true iff this prefix mask is more specific than mask. More... | |
| IPAddress & | operator &= (IPAddress) |
| IPAddress & | operator|= (IPAddress) |
| Assign this address to its bitwise-or with a. More... | |
| IPAddress & | operator^= (IPAddress) |
| Assign this address to its bitwise-xor with a. More... | |
| String | unparse () const |
| Unparses this address into a dotted-quad format String. More... | |
| String | unparse_mask () const |
| Unparses this address into IP address mask format: either a prefix length or unparse(). More... | |
| String | unparse_with_mask (IPAddress) const |
| Unparses an address prefix, specified by address and mask, into "address/mask" format. More... | |
| String | s () const |
| Unparse this address into a dotted-quad format String. More... | |
| operator String () const | |
| Unparse this address into a dotted-quad format String. More... | |
Static Public Member Functions | |
| static IPAddress | make_prefix (int prefix_len) |
| Return an IPAddress equal to the prefix mask of length prefix. More... | |
| static IPAddress | make_broadcast () |
| Return the broadcast IP address, <IP_ADDRESS>. More... | |
Related Functions | |
(Note that these are not member functions.) | |
| bool | operator== (IPAddress a, IPAddress b) |
| Compare two IPAddress objects for equality. More... | |
| bool | operator== (IPAddress a, uint32_t b) |
| Compare an IPAddress with a network-byte-order address value for equality. More... | |
| bool | operator!= (IPAddress a, IPAddress b) |
| Compare two IPAddress objects for inequality. More... | |
| bool | operator!= (IPAddress a, uint32_t b) |
| Compare an IPAddress with a network-byte-order address value for inequality. More... | |
| IPAddress | operator& (IPAddress a, IPAddress b) |
| Calculate the IPAddress representing the bitwise-and of a and b. More... | |
| IPAddress | operator| (IPAddress a, IPAddress b) |
| Calculate the IPAddress representing the bitwise-or of a and b. More... | |
| IPAddress | operator^ (IPAddress a, IPAddress b) |
| Calculate the IPAddress representing the bitwise-xor of a and b. More... | |
| IPAddress | operator~ (IPAddress a) |
| Calculate the IPAddress representing the bitwise complement of a. More... | |
An IPv4 address.
The IPAddress type represents an IPv4 address. It supports bitwise operations like & and | and provides methods for unparsing IP addresses into ASCII dotted-quad form.
|
inline |
Construct an IPAddress equal to <IP_ADDRESS>.
|
inline |
Construct an IPAddress from an integer in network byte order.
|
inlineexplicit |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
|
inlineexplicit |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
|
inlineexplicit |
This is an overloaded member function, provided for convenience. It differs from the above function only in what argument(s) it accepts.
|
inlineexplicit |
Construct an IPAddress from data.
| data | the address data, in network byte order |
Bytes data[0]...data[3] are used to construct the address.
|
explicit |
|
inline |
Construct an uninitialized IPAddress.
|
static |
Return an IPAddress equal to the prefix mask of length prefix.
| prefix_len | prefix length; 0 <= prefix_len <= 32 |
For example, make_prefix(0) is <IP_ADDRESS>, make_prefix(8) is <IP_ADDRESS>, and make_prefix(32) is <IP_ADDRESS>. Causes an assertion failure if prefix_len is out of range.
|
inlinestatic |
Return the broadcast IP address, <IP_ADDRESS>.
|
inline |
Test if the address is <IP_ADDRESS>.
|
inline |
Return the address as a uint32_t in network byte order.
|
inline |
Return the address as a uint32_t in network byte order.
Also suitable for use as an operator bool, returning true iff the address is not <IP_ADDRESS>.
|
inline |
Return true iff the address is a multicast address.
These are the class D addresses, <IP_ADDRESS>-<IP_ADDRESS>.
| struct in_addr IPAddress::in_addr | ( | ) | const |
Return a struct in_addr corresponding to the address.
|
inline |
Return a struct in_addr corresponding to the address.
|
inline |
|
inline |
|
inline |
Hash function.
Equal IPAddress objects always have equal hashcode() values.
| int IPAddress::mask_to_prefix_len | ( | ) | const |
Returns the prefix length equivalent to this prefix mask, or -1 if this is not a prefix mask.
Maintains the invariant that make_prefix(prefix_len).mask_to_prefix_len() == prefix_len.
Return true iff this address matches the address prefix addr/mask.
| addr | prefix address |
| mask | prefix mask |
Equivalent to (addr & mask) == (*this & mask). The prefix address addr may be nonzero outside the mask.
|
inline |
Return true iff this address, considered as a prefix mask, is at least as specific as mask.
| mask | prefix mask |
Longer prefix masks are more specific than shorter ones. For example, make_prefix(20).mask_as_specific(make_prefix(18)) is true, but make_prefix(10).mask_as_specific(make_prefix(14)) is false.
Equivalent to (*this & mask) == mask.
|
inline |
Return true iff this prefix mask is more specific than mask.
| mask | prefix mask |
Both this address and mask must be prefix masks – i.e., mask_to_prefix_len() returns 0-32. Returns true iff this address contains a longer prefix than mask. For example, make_prefix(20).mask_more_specific(make_prefix(18)) is true, but make_prefix(20).mask_more_specific(make_prefix(20)) is false.
Assign this address to its bitwise-or with a.
Assign this address to its bitwise-xor with a.
| String IPAddress::unparse | ( | ) | const |
| String IPAddress::unparse_mask | ( | ) | const |
Unparses this address into IP address mask format: either a prefix length or unparse().
If mask_to_prefix_len() >= 0, then returns that value as a base-10 String; otherwise, returns unparse(). Example results include "8" (for <IP_ADDRESS>) and "<IP_ADDRESS>".
Unparses an address prefix, specified by address and mask, into "address/mask" format.
| mask | the address mask |
Equivalent to unparse() + "/" + mask.unparse_mask().
|
inline |
Unparse this address into a dotted-quad format String.
|
inline |
Unparse this address into a dotted-quad format String.
|
related |
Compare an IPAddress with a network-byte-order address value for equality.
| a | an address |
| b | an address value in network byte order |
|
related |
Compare an IPAddress with a network-byte-order address value for inequality.
| a | an address |
| b | an address value in network byte order |
Calculate the IPAddress representing the bitwise-and of a and b.
Calculate the IPAddress representing the bitwise-or of a and b.
Calculate the IPAddress representing the bitwise-xor of a and b.
Calculate the IPAddress representing the bitwise complement of a.


Note Created
ID_BINARY
Retrieve your note at: HOST_BINARY/ID_BINARY
Remember: No receipt, no message... and the receipt is not recoverable


01. Fresh Fruits
It has long been known that a diet that includes at least a few servings of fresh fruit every day will keep you healthy, fit and trim.


God fearing lady,loves music,now a Programming geek.
Am self driven.self motivated,Humble.i can work at any given time or place and also with diverse people regardless of there age,relion and tribe.I go to moringa School,whereby is a school of programming.i have learnt alot.
Below is the links of what i have done so in regards of studing at moringa:https://virginiah2020.github.io/virginiah2020/index.html
Below are some of the skills am good at :


Fork the repository on GitHub.
I'm happy to merge your pull requests once they proved fit against my investigation. If you've got a creative piece of brain that can help but cannot code, send me your ideas.
All the experiments available here are licensed under the MIT License.


--- template: mail ---
Your #openHSV account was just approved. That means that your listing is live on #openHSV right now.
Use your profile to find freelance opportunities, hire freelancers, meet advisors or mentors, or refer colleagues. In the future you'll be able to use your #openHSV profile as your digital identity for registering for and checking into local events. Stay tuned!
Thank you,
The #openHSV team


5. Given

, which of these two is the most performant way to select the inner div?
A. getElementById("outer").children[0]
B. getElementsByClassName("inner")[0]
Continue
Currently Selected: {{quiz}}


myCharitySearch makes it easier to donate to charities from around the world.
(U.S. only)
There was an error with your request. Please try again.
Loading Results...


Time Locked Bitcoin Transactions w/ CLTV
What is "CLTV"?
CLTV is an op code in the Bitcoin scripting language that allows you to lock a UTXO (Unspent Transaction Output) by time. i.e. a coin cannot be spent until a certain time or blockchain height has been past. In this guide, we will have a function that creates a script that locks a UTXO for a predetermined amount of time using the CLTV op code as well as separately learn how to sign these types of special inputs.
Unlocking an Unspent TX Output (UTXO)
Sending funds in Bitcoin is really just about pointing to the output of a previous transaction, making that the input for a new transaction, and, then satisfying some locking condition on that previous output. "Scripts" are conditions that need to be satisfied on an output to prove ownership. You can have a Bitcoin script that is locked with the math problem "What is 2 + 5", and anyone that knows to answer "7" can "prove" ownership over that output (Check out this guide, Intro To Scripting to see how to write and redeem this simple script in bcoin, and this section in Mastering Bitcoin for a helpful walkthrough).
In the vast majority of Bitcoin and other cryptocurrency transactions, you prove ownership by signing a transaction input with the private key (basically a password that is stored in your wallet) that corresponds to the address that the source output was sent to. I.e. The UTXO is locked by the requirement that some signaturemust match a public key or public key hash that is on the execution stack.
An output that is locked with CLTV works more or less the same way but adds another condition that before the signature is even accepted, a certain amount of time must have passed.
In pseudo-code, the script will look like this:
Locktime (in blocks or Unix epoch time)
Check if locktime is less than nLocktime of transaction; execution fails if not
Check public key hash matches
Check if the signature validates
In Bitcoin, this locking script will look something like this:
<some amt of time> CHECKLOCKTIMEVERIFY DROP DUP HASH160
<Redeeming Public Key Hash> EQUALVERIFY CHECKSIG
To learn more about CLTV and how it works in Bitcoin, checkout chapter 07 in Mastering Bitcoin. See Chapter 06 for more information on how the stack and scripts operate.
This guide will be broken into two parts. First we will walk through creating and redeeming a mock transaction with no real coins. Next we will do the same thing on a live regtest network using the bcoin wallet and API.
(If you want to see the full code, checkout the repo here)
The Guide - Mock Transaction
Before moving on to the transaction there is some setup that will be useful for both approaches. Note that this guide assumes use with Segwit transactions so inputs and redeem scripts are stored in the witness field.
Setup
Let's first setup the constants and import the modules we will need to create and spend our transactions.
// first the modules we will be using from bcoin
const {
Amount,
Coin,
KeyRing,
MTX,
Network,
Outpoint,
Script,
ScriptNum,
Stack
} = require('bcoin');
// some NodeJS helpers
const fs = require('fs');
const assert = require('assert');
// a helper object with information
// about the regtest network
const network = Network.get('regtest');
Creating the Script
Let's create a function that takes a locktime and a publicKeyHash
that corresponds to the private key that can redeem the transaction
and returns an object of type Script
. This script is what will
ultimately be used to lock our UTXO, i.e. the locking script.
Note that for CLTV, the locktime can either be a block height or Unix Epoch timestamp (seconds since Jan-1-1970) if above 500 million ( See BIP-065 Specs).
/**
* @param {String} locktime - Time that the script can not
* be redeemed before
* @param {Buffer} public key hash
* @returns {Script}
**/
function createScript(locktime, publicKeyHash) {
let pkh;
if (typeof publicKeyHash === 'string')
pkh = Buffer.from(publicKeyHash);
else pkh = publicKeyHash;
assert(Buffer.isBuffer(pkh), 'publicKey must be a Buffer');
assert(
locktime,
'Must pass in a locktime argument, either block height or UNIX epoch time'
);
const script = new Script();
// lock the transactions until
// the locktime has been reached
script.pushNum(ScriptNum.fromString(locktime.toString(), 10));
// check the locktime
script.pushSym('CHECKLOCKTIMEVERIFY');
// if verifies, drop time from the stack
script.pushSym('drop');
// duplicate item on the top of the stack
// which should be.the public key
script.pushSym('dup');
// hash the top item from the stack (the public key)
script.pushSym('hash160')
// push the hash to the top of the stack
script.pushData(pkh);
// confirm they match
script.pushSym('equalverify');
// confirm the signature matches
script.pushSym('checksig');
// Compile the script to its binary representation
// (you must do this if you change something!).
script.compile();
return script;
}
This script is pretty long and could be expensive to send in a transaction. Similar to the way multisignature transactions are typically handled, let's create a method to embed the script into a P2WSH (Pay to Witness Script Hash) address.
/**
* @param {Script} script to get corresponding address for
* @param {Network} to determine encoding based on network
* @returns {Address} - p2wsh segwit address for specified network
**/
function getAddress(script, network) {
// get the hash of the script
// and derive address from that
const p2wsh = script.forWitness();
const segwitAddress = p2wsh.getAddress().toBech32(network);
return segwitAddress;
}
Making the transaction
Here are the steps we'll be walking through:
1) Setup keyrings - In order to mimic spending and receiving from a wallet, we're going to create some keyrings, which will manage the public-private keypairs needed to generate addresses and redeem UTXOs. Typically, these are managed by a wallet, but for the purposes of demonstration, we'll do this manually.
2) Make the script and save it to keychain. Note: when making P2SH or P2WSH scripts, you need to keep track of the script in order to redeem it later.
3) Create the P2WSH address to receive (and lock) the funds to
4) Create our fake tx that sends an output to our locking address
5) Setup our redeeming tx with the locked coin as our input, spending to another address, and the correct locktime
6) Sign and verify the input
// We'll use this as a reference for later.
// to get value in satoshis all you need is `amountToFund.toValue()`;
const amountToFund = Amount.fromBTC('.5');
// flags are for script and transaction verification
const flags = Script.flags.STANDARD_VERIFY_FLAGS;
// 1) Setup keyrings
const keyring = KeyRing.generate(true);
const keyring2 = KeyRing.generate(true);
// can only be redeemed after the 100th block has been mined
const locktime = '100';
keyring.witness = true;
keyring2.witness = true;
// 2) Get hash and save it to keyring
const pkh = keyring.getKeyHash();
const script = createScript(locktime, pkh);
keyring.script = script;
// 3) Create the address
const lockingAddr = getAddress(script, network);
// 4) Create our funding transaction that sends
// 50,000 satoshis to our locking address
const cb = new MTX();
cb.addInput({
prevout: new Outpoint(),
script: new Script(),
sequence: 0xffffffff
});
// Send 50,000 satoshis to our locking address.
// this will lock up the funds to whoever can solve
// the CLTV script
cb.addOutput(lockingAddr, amountToFund.toValue());
// Convert the coinbase output to a Coin object
// In reality you might get these coins from a wallet.
// `fromTX` will take an output from a previous
// tx and turn it into a coin object
// (the second param is the index of the target UTXO)
const coin = Coin.fromTX(cb, 0, -1);
// 5) Setup the redeeming transaction
// Start with an empty mutable transaction
let mtx = new MTX();
// add our cb coin as the input (i.e. the "funding" UTXO)
mtx.addCoin(coin);
// get an address to send the funds from the coin to
const receiveAddr = keyring2.getAddress('string', network);
// value of the input minus arbitrary amount for fee
// normally we could do this by querying our node to estimate rate
// or use the `fund` method if we had other coins to spend with
const receiveValue = coin.value - 1000;
mtx.addOutput(receiveAddr, receiveValue);
// So now we have an mtx with the right input and output
// but our input still hasn't been signed
console.log('mtx:', mtx);
Script and Sign the Inputs
We're going to create two custom methods to handle this part
since we can use it for the live transactions as well. The MTX
primitive in bcoin has its own version of these (see the code
here)
but out of the box they can only handle standard transaction types.
scriptInput
Roughly speaking what scriptInput
does is take the index of the input
you're scripting, the coin you're creating the input from, and
the keyring used to redeem it. It then templates the input (or witness
in this case), adding the full redeem script needed to verify the script hash
and putting OP_0 in the place of the signature.
The actual method has more checks in it to see what kind of input, (P2PKH, P2PK, P2SH, etc.) it is scripting for.
/* script the inputs w/ our custom script for an mtx
* This is modeled after the scriptInput method on
* the `MTX` class
* @param {MTX} mtx with unscripted input
* @param {Number} index - index of input to script
* @param {Coin} coin- UTXO we are spending
* @param {KeyRing} ring - keyring we are signing with
* @returns {MTX}
*/
function scriptInput(mtx, index, coin, ring) {
const input = mtx.inputs[index];
const prev = coin.script;
const wsh = prev.getWitnessScripthash();
assert(ring instanceof KeyRing, 'Must pass a KeyRing to scriptInput');
// this is the redeem script used to verify the p2wsh hash
wredeem = ring.getRedeem(wsh);
assert(wredeem, 'keyring has no redeem script');
const vector = new Stack();
// first add empty space in stack for signature and public key
vector.pushInt(0);
vector.pushInt(0);
// add the raw redeem script to the stack
vector.push(wredeem.toRaw());
input.witness.fromStack(vector);
mtx.inputs[index] = input;
return mtx;
}
signInput
signInput
takes the same parameters, simply verifies the input/witness,
replaces the OP_0 with a signature to satisfy the script.
This is a simplified version of the version of signInput
that is on
the MTX
class in bcoin.
/* This is modeled after the signInput method on
* the `MTX` class
* @param {MTX} mtx with unscripted input
* @param {Number} index - index of input to script
* @param {Coin} coin- UTXO we are spending
* @param {KeyRing} ring - keyring we are signing with
* @returns {MTX}
*/
function signInput(mtx, index, coin, ring) {
const input = mtx.inputs[index];
let witness, version;
const redeem = input.witness.getRedeem();
assert(
redeem,
'Witness has not been templated'
);
witness = input.witness;
// version is for the signing to indicate signature hash version
// 0=legacy, 1=segwit
version = 1;
const stack = witness.toStack();
// let's get the signature and replace the placeholder
// in the stack. We can use the MTX `signature` method
const sig =
mtx.signature(
index,
wredeem,
coin.value,
ring.privateKey,
null,
version
);
stack.setData(0, sig);
stack.setData(1, ring.getPublicKey());
witness.fromStack(stack);
return mtx;
}
Now that we can script and sign, let's finish off the transaction! In addition to signing, we also need to set the nLocktime parameter of the transaction. In a live blockchain environment this will be checked against the current state of the chain in the mempool. So, a transaction with an nLocktime later than the current block height or time, will be rejected as invalid.
mtx = scriptInput(mtx, 0, coin, keyring);
mtx = signInput(mtx, 0, coin, keyring);
// Now set the locktime
// You can test if the CLTV script is working or not
// by changing this to a value less than what our script requires
// which will cause the `mtx.verify` call to fail below
mtx.setLocktime(parseInt(locktime));
// if you console log the input being signed,
// you'll notice it now has a witness stack and redeem script
// before script, witness, and redeem were empty
console.log('signed mtx:', mtx);
assert(mtx.verify(flags), 'mtx did not verify');
// make tx immutable
const tx = mtx.toTX();
// it should still verify (need mtx's coin view to verify tx)
assert(tx.verify(mtx.view), 'tx did not verify');
console.log('Transaction verified!');
A Live CLTV Transaction
Let's test this on a regtest network that way we can easily mine our own blocks to verify whether or not everything is working.
Some of the key differences doing this live:
1) We need to use real UTXOs/Coins
2) We need to manually keep track of the redeem script
3) We will interact with the REST API for signing of our transaction
4) We will need to check against the real height of a blockchain in order to redeem
First we're going to need to setup our bcoin clients so we can talk to our node and wallet. Make sure you have bclient installed.
// make sure you've installed bclient to your project
// `npm install --save bclient`
const { WalletClient, NodeClient } = require('bclient');
const network = Network.get('regtest');
// if your node needs an API key for access
// you can import it like this for use in setting up your client
const apiKey = fs.readFileSync('./secrets.env');
const clientOptions = {
network: network.type,
apiKey: apiKey.toString()
}
const walletClient = new WalletClient({...clientOptions, port: network.walletPort});
const nodeClient = new NodeClient({ ...clientOptions, port: network.rpcPort });
Since the bcoin wallet doesn't natively support CLTV coins, we're going to implement our own naive persistent storage so that we can keep a reference to the redeem script, locking address (P2WSH address), locktime, and the redeem address. We'll do this by saving this information to a json object in a separate text file.
For this portion of the code, we're going to have two evaluation branches. We'll first check if we have this file with information saved to it. If we don't, then we need to make the locking transaction. If we do, then we check if the current block height meets the locktime requirement (saved in our document) and create, sign, and broadcast our redeeming transaction
async function lockAndRedeemCLTV(walletId) {
try {
const txInfoPath = './tx-info.json'; // this is where we'll persist our info
const wallet = walletClient.wallet(walletId); // instantiate a client for our wallet
let redeemScript, lockingAddr, locktime;
// check if file exists and if there is info saved to it
let txInfo = fs.existsSync(txInfoPath) ? fs.readFileSync(txInfoPath) : '';
if (!txInfo.length) {
// No saved transaction, so let's create it and then
// save the information for later
// Step 1: Setup wallet client and confirm balance
const { balance } = await wallet.getInfo();
assert(balance.confirmed > amountToFund.toValue(), 'Not enough funds!');
// Step 2: Setup keyring w/ pkh and create locking address
// that can be redeemed by our real wallet after a set locktime
const { publicKey, address } = await wallet.createAddress('default');
// create the keyring from the public key
// and get the public key hash for the locking script
const keyring = KeyRing.fromKey(Buffer.from(publicKey, 'hex'), true);
keyring.witness = true;
const pkh = keyring.getKeyHash();
// Get current height and set locktime to 10 blocks from now
const { chain: { height }} = await nodeClient.getInfo();
locktime = height + 10;
// create the script and address that can be redeemed by our wallet
redeemScript = createScript(locktime.toString(), pkh);
lockingAddr = getAddress(redeemScript, network);
// Step 3: use the wallet client to send funds to the locking address
const output = {
value: amountToFund.toValue(),
address: lockingAddr
};
const lockedTx = await wallet.send({ outputs: [output], rate: 7000 });
console.log('transaction sent to mempool');
// save the transaction information to to a file
txInfo = { lockedTx, lockingAddr, redeemScript, locktime, redeemAddress: address };
fs.writeFileSync(txInfoPath, JSON.stringify(txInfo, null, 2));
// mine one block to get tx on chain
// make sure you're doing this on regtest or simnet and
// not testnet or mainnet
// this method won't work if you don't have a
// coinbase address set on your miner
// you can also use bPanel and the @bpanel/simple-mining
// plugin to do this instead
const minedBlock = await nodeClient.execute('generate', [1]);
console.log('Block mined', minedBlock);
} else {
// if the txInfo file exists then we know we have a locked tx
// so let's get the information we need to start redeeming!
const {
lockedTx,
lockingAddr,
redeemScript,
locktime,
redeemAddress
} = JSON.parse(txInfo);
// 1) let's get the current block height to check if we can actually redeem
const { chain: { height }} = await nodeClient.getInfo();
// in reality this could be block height or Unix epoch time
assert(locktime <= height, `Too soon to redeem the UTXO. Wait until block ${locktime}`);
// Our locktime is less than or equal to height which means we can redeem
// 2) Prepare redeeming tx
// get index of utxo
const index = lockedTx.outputs.findIndex(
output => output.address === lockingAddr
);
// get the coin associated with our locked tx
// indicating the index of the UTXO
const coinJSON = await nodeClient.getCoin(lockedTx.hash, index);
// create a new coin object that references the UTXO we want to spend
// and add it as an input to a blank mutable transaction
const coin = Coin.fromJSON(coinJSON);
let mtx = new MTX();
mtx.addCoin(coin);
// For simplicity we'll redeem the locked tx to ourselves
// But if you have another wallet that might be easier
// since you can see the change in balance more easily
const { address } = await wallet.createAddress('default');
// send to the address the value of the coin minus the fee
mtx.addOutput(address, coin.value - 1500);
// set nLocktime field on transaction
// mempool and chain will check against this
// to verify finality for each input
mtx.setLocktime(height);
// 3) Setup a keyring to use for signing the input
// First get the script from our saved tx info
const script = Script.fromRaw(redeemScript, 'hex');
// Next we'll get the private key associated with the pkh
// that the timelocked UTXO is locked to
// Note it's generally not safe to transfer your private key
// unencrypted over the network like this, but we're doing it
// here for simplicity
const { privateKey } = await wallet.getWIF(redeemAddress);
const ring = KeyRing.fromSecret(privateKey, network);
ring.witness = true;
ring.script= script;
// 4) Script and sign the input
// Note that we can use the same methods as in the mock transaction
mtx = scriptInput(mtx, index, coin, ring);
mtx = signInput(mtx, index, coin, ring);
// 5) Verify and broadcast the tx
// Note that the `verify` won't check against current height
// of the blockchain and the node won't reject the tx but will
// still try and broadcast (you can check your node logs for
// mempool verification errors)
assert(mtx.verify(), 'MTX did not verify');
const tx = mtx.toTX();
assert(tx.verify(mtx.view), 'TX did not verify');
const raw = tx.toRaw().toString('hex');
// now we've got a signed raw transaction that we can broadcast to the network!
const result = await nodeClient.broadcast(raw);
assert(result.success, 'There was a problem broadcasting the tx');
// confirm the tx is in the mempool
// we need to do this because even if the mempool says there is a problem
// with your transaction, it will try and broadcast anyway
// and result will come back with `success: true`. If it made it into the
// mempool and/or chain and can be queried then you know it was successful
const txFromHash = await nodeClient.getTX(tx.rhash());
assert(txFromHash, 'The tx does not appear to be in the mempool or chain');
console.log('Success!');
console.log('Tx: ', tx);
// if it was successful then we can clear our saved tx info since it is now
// obsolete. Clearing this will re-enable the first evaluation branch above
fs.writeFileSync(txInfoPath, '');
}
} catch(e) {
console.error('There was an error with live solution:', e);
}
};
Now you can run lockAndRedeemCLTV
once to send the CLTV transaction and again to redeem it
on a live Regtest network! Feel free to play around with the different values to see how it works.
You can use different wallets, change the locktime, or change the redeem amount. Take a look
at the JSON file that is saved after creating the transaction to see what the raw information looks
like that is needed for redeeming.
Next Steps
What we built in this guide is basically a very basic smart contract that locks funds for a certain amount of time. This example though can serve as a building block for much more complicated scripts and contracts. Here are some ideas of other things you can build with CLTV transactions:
Hashed Time Locked Contracts- Aka HTLCs. These are a key part of enabling trustless payment channels in the Lightning Network and have the time locked script we built here at its base.
Kill Switch Transaction- You can create an application that uses CLTVs to enforce the condition where if some action isn't taken every 6 months (such as pressing a button or sending an email), a transaction will send all your funds to a multisig address controlled by your estate. You can use a version of an HTLC to either redeem the tx with your own key or redeem with the multisig account after the time period. When you take the action, it redeems with your key.
Authorization Levels by Time Lock- This idea comes from the Advanced Scripting chapter in Mastering Bitcoin. The rules of the transaction would follow this basic structure: "[T]hree partners make decisions based on a majority rule, so two of the three must agree. However, in the case of a problem with their keys, they want their lawyer to be able to recover the funds with one of the three partner signatures. Finally, if all partners are unavailable or incapacitated for a while, they want the lawyer to be able to manage the account directly." You can see why they're called Smart Contracts!


Package for processing downloaded MODIS Cloud Product HDF files and derived files. Specifically, MOD35_L2 cloud product files, and the associated MOD03 geolocation files (for MODIS-TERRA); and MYD35_L2 cloud product files, and the associated MYD03 geolocation files (for MODIS-AQUA). The package will be most effective if the user installs MRTSwath (MODIS Reprojection Tool for swath products; https://lpdaac.usgs.gov/tools/modis_reprojection_tool_swath), and adds the directory with the MRTSwath executable to the default R PATH by editing ~/.Rprofile.
| Version: | 0.14 |
| Depends: | date, sp, sfsmisc, raster, rgdal |
| Published: | 2013-02-09 |
| Author: | Nicholas J. Matzke, Dept. of Integrative Biology, U.C. Berkeley |
| Maintainer: | Nicholas J. Matzke <matzke at berkeley.edu> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| URL: | http://phylo.wikidot.com/modiscloud |
| NeedsCompilation: | no |
| Citation: | modiscloud citation info |
| CRAN checks: | modiscloud results |
| Reference manual: | modiscloud.pdf |
| Package source: | modiscloud_0.14.tar.gz |
| Windows binaries: | r-devel: modiscloud_0.14.zip, r-release: modiscloud_0.14.zip, r-oldrel: modiscloud_0.14.zip |
| OS X binaries: | r-release: modiscloud_0.14.tgz, r-oldrel: modiscloud_0.14.tgz |
| Old sources: | modiscloud archive |
Please use the canonical form https://CRAN.R-project.org/package=modiscloud to link to this page.


| Interface | Description |
|---|---|
| Accessor |
An accessor of a property value.
|
| ArcProperty |
A Property that represents an "arc" connecting source node to the target node in the
graph.
|
| AttributeProperty |
Represents a simple object property.
|
| ClassDescriptor |
A runtime descriptor of an persistent class.
|
| ClassDescriptorFactory |
A factory of
ClassDescriptor instances. |
| EmbeddableDescriptor | |
| FaultFactory | |
| Property |
Defines bean property API used by Cayenne to access object data, do faulting and graph
maintenance tasks.
|
| PropertyVisitor |
A visitor for various types of properties in a ClassDescriptor.
|
| ToManyMapProperty |
A property representing a map of objects keyed by one of the object properties.
|
| ToManyProperty |
A property representing a collection of objects.
|
| ToOneProperty |
An ArcProperty that points to a single graph node.
|
| Class | Description |
|---|---|
| BaseArcProperty |
A base implementation of the
ArcProperty . |
| BaseProperty |
An abstract property descriptor that delegates property access to an
Accessor . |
| BaseToManyProperty |
A generic superclass of CollectionProperty implementations.
|
| BaseToOneProperty |
A convenience base superclass for
ToOneProperty implementors. |
| BeanAccessor |
A property accessor that uses set/get methods following JavaBean naming conventions.
|
| ClassDescriptorMap |
An object that holds class descriptors for mapped entities, compiling new descriptors
on demand using an internal chain of descriptor factories.
|
| EmbeddedFieldAccessor |
An accessor for fields storing embedded objects.
|
| FieldAccessor |
A PropertyAccessor that performs direct Field access.
|
| FieldEmbeddableDescriptor |
A default POJO embeddable descriptor.
|
| IdMapKeyAccessor |
A stateless read-only accessor of the map key value that is based on the Persistent
object id.
|
| LazyClassDescriptorDecorator |
A ClassDescriptor wrapper that compiles decorated descriptor lazily on first access.
|
| LifecycleCallbackRegistry |
A registry of lifecycle callbacks for all callback event types.
|
| PersistentDescriptor |
A default ClassDescriptor implementation for persistent objects.
|
| PersistentDescriptorFactory |
A convenience superclass for
ClassDescriptorFactory implementors. |
| PropertyAccessor |
A utility accessor class that wraps a simple property.
|
| PropertyUtils |
Utility methods to quickly access object properties.
|
| SimpleAttributeProperty |
A descriptor of an "attribute" persistent property.
|
| SingletonFaultFactory |
| Exception | Description |
|---|---|
| PropertyException |
An unchecked exception thrown on errors during property access, either within a
Accessor or a Property.
|
| UnresolvablePathException |
A runtime exception thrown when
PropertyUtils.getProperty() finds that
there is a null value in middle of the resolved path. |
Copyright © 2001–2014 Apache Cayenne. All rights reserved.


interns/full-time employees/post-docs
all over the globe; proficient in C++/python is a must
,
decent knowledge on DL/CV/3D vision/autonomous driving is bonus
.
博士联培名额
. If you are qualified, please contact us!
First
on
nuScenes detection benchmark, known as BEVFormer,
a camera-based solution inspired by Transformer and temporal design, surpassing the second by a large extent.
First
place
at CVPR Waymo Challenge 2022.


Loads the usual packages from my every-day workflow
usual_suspects(pkgs = NULL)
pkgs
A character vector containing the packages that should be loaded. The fedault ones include janitor, here, sf, and tidyverse
janitor
here
sf
tidyverse


Class Hierarchy
- java.lang.Object
- visibility.unrecognizedvoices.core.Action
- visibility.unrecognizedvoices.jobs.bills.jsons.Action
- visibility.unrecognizedvoices.api.ApiHelper
- io.dropwizard.Application<T>
- visibility.unrecognizedvoices.core.Bill
- visibility.unrecognizedvoices.jobs.bills.jsons.Bill
- visibility.unrecognizedvoices.mappings.BillMapper (implements org.skife.jdbi.v2.tweak.ResultSetMapper<T>)
- visibility.unrecognizedvoices.db.services.BillService
- visibility.unrecognizedvoices.resources.BillsResources
- visibility.unrecognizedvoices.jobs.bills.jsons.BillsResults
- visibility.unrecognizedvoices.jobs.bills.jsons.BillsSenateMappedJson
- visibility.unrecognizedvoices.core.Committee
- visibility.unrecognizedvoices.jobs.representatives.jsons.Committee
- io.dropwizard.Configuration
- com.codahale.metrics.health.HealthCheck
- visibility.unrecognizedvoices.core.Invoice
- de.spinscale.dropwizard.jobs.Job (implements org.quartz.Job)
- visibility.unrecognizedvoices.jobs.representatives.jsons.Member
- visibility.unrecognizedvoices.core.Party
- visibility.unrecognizedvoices.mappings.PartyMapper (implements org.skife.jdbi.v2.tweak.ResultSetMapper<T>)
- visibility.unrecognizedvoices.core.Representative
- visibility.unrecognizedvoices.mappings.RepresentativeMapper (implements org.skife.jdbi.v2.tweak.ResultSetMapper<T>)
- visibility.unrecognizedvoices.db.services.RepresentativeService
- visibility.unrecognizedvoices.resources.RepresentativesResources
- visibility.unrecognizedvoices.jobs.representatives.jsons.RepsMappedJson
- visibility.unrecognizedvoices.jobs.representatives.jsons.RepsResults
- visibility.unrecognizedvoices.core.Role
- visibility.unrecognizedvoices.jobs.representatives.jsons.Role
- visibility.unrecognizedvoices.core.State
Interface Hierarchy
Copyright © 2017. All rights reserved.


{% extends "global/Page.html" %} {% load staticfiles otree %} {% block title %} Intermediate results {% endblock %} {% block content %}
| Round | Player and outcome |
|---|---|
| {{ p.round_number }} | {% if p.role == 'Employer' %} You were the employer and proposed a wage of {{ p.wage }} for a desired effort level of {{ p.desired_effort_level }}. The employee did an effort level of {{ p.effort_level }} and you earned {{ p.payoff }} {% else %} You were the employee, were proposed a wage of {{ p.wage }} for a desired effort level of {{ p.desired_effort_level }}. You did an effort level of {{ p.effort_level }} and earned {{ p.payoff }} {% endif %} |
Your total payoff is therefore {{ total_payoff }}.
Average efforts and payoffs by wage:
Effort over time:
| Effort matching | Proportion |
|---|---|
| Effort level matching desired effort level | {{ effort_matching.matching|floatformat:2 }}% |
| Effort level greater than desired effort level | {{ effort_matching.greater|floatformat:2 }}% |
| Effort level below desired effort level | {{ effort_matching.below|floatformat:2 }}% |


TO BE
HERO
explore
login
HERO
Join now and Help your child to achieve dreams
Guardian
Mentor
Full name*
Email*
Password*
re-Password*
Phone
+20
*required
already registered?