|
Mini51 BSP
V3.02.002
The Board Support Package for Mini51 Series
|
#include <Mini51Series.h>
Data Fields | |
| union { | |
| __I uint32_t RBR | |
| __O uint32_t THR | |
| }; | |
| __IO uint32_t | IER |
| __IO uint32_t | FCR |
| __IO uint32_t | LCR |
| __IO uint32_t | MCR |
| __IO uint32_t | MSR |
| __IO uint32_t | FSR |
| __IO uint32_t | ISR |
| __IO uint32_t | TOR |
| __IO uint32_t | BAUD |
| __IO uint32_t | IRCR |
| __IO uint32_t | ALT_CSR |
| __IO uint32_t | FUN_SEL |
@addtogroup UART Universal Asynchronous Receiver/Transmitter Controller(UART) Memory Mapped Structure for UART Controller
Definition at line 8567 of file Mini51Series.h.
| union { ... } |
| UART_T::ALT_CSR |
| Bits | Field | Descriptions |
| [8] | RS485_NMM | RS-485 Normal Multi-drop Operation Mode (NMM) Control
0 = RS-485 Normal Multi-drop Operation Mode (NMM) Disabled. 1 = RS-485 Normal Multi-drop Operation Mode (NMM) Enabled. Note: This bit cannot be active with RS485_AAD operation mode. |
| [9] | RS485_AAD | RS-485 Auto Address Detection Operation Mode (AAD)
0 = RS-485 Auto Address Detection Operation Mode (AAD) Disabled. 1 = RS-485 Auto Address Detection Operation Mode (AAD) Enabled. Note: This bit cannot be active with RS485_NMM operation mode. |
| [10] | RS485_AUD | RS-485 Auto Direction Mode (AUD) Control
0 = RS-485 Auto Address Detection Operation Mode (AAD) Disabled. 1 = RS-485 Auto Address Detection Operation Mode (AAD) Enabled. Note: This bit cannot be active with RS485_NMM operation mode. |
| [15] | RS485_ADD_EN | RS-485 Address Detection Enable Control
This bit is used to enable RS-485 Address Detection mode. 0 = RS-485 address detection mode Disabled. 1 = RS-485 address detection mode Enabled. Note: This field is used for RS-485 any operation mode. |
| [31:24] | ADDR_MATCH | Address Match Value
This field contains the RS-485 address match values. Note: This field is used for RS-485 auto address detection mode. |
Definition at line 9466 of file Mini51Series.h.
| UART_T::BAUD |
| Bits | Field | Descriptions |
| [15:0] | BRD | Baud Rate Divider
The field indicates the baud rate divider. |
| [27:24] | DIVIDER_X | Divider X
The baud rate divider M = X+1. |
| [28] | DIV_X_ONE | Divider X Equal 1
0 = Divider M = X (the equation of M = X+1, but DIVIDER_X[27:24] must >= 8). 1 = Divider M = 1 (the equation of M = 1, but BRD [15:0] must >= 8). Refer to section "UART Controller Baud Rate Generator" for more information. |
| [29] | DIV_X_EN | Divider X Enable Control
The BRD = Baud Rate Divider, and the baud rate equation is: Baud Rate = Clock / [M * (BRD + 2)], The default value of M is 16. 0 = Divider X Disabled (the equation of M = 16). 1 = Divider X Enabled (the equation of M = X+1, but DIVIDER_X [27:24] must >= 8). Note: When in IrDA mode, this bit must be disabled. |
Definition at line 9464 of file Mini51Series.h.
| UART_T::FCR |
| Bits | Field | Descriptions |
| [1] | RFR | RX Field Software Reset
When RX_RST is set, all the byte in the receiver FIFO and RX internal state machine are cleared. 0 = No effect. 1 = The RX internal state machine and pointers reset. Note: This bit will auto clear needs at least 3 UART Controller peripheral clock cycles. |
| [2] | TFR | TX Field Software Reset
When TX_RST is set, all the byte in the transmit FIFO and TX internal state machine are cleared. 0 = No effect. 1 = The TX internal state machine and pointers reset. Note: This bit will auto clear needs at least 3 UART Controller peripheral clock cycles. |
| [7:4] | RFITL | RX FIFO Interrupt (RDA_INT) Trigger Level
When the number of bytes in the receive FIFO equals the RFITL then the RDA_IF will be set (if RDA_IEN in UA_IER register is enable, an interrupt will generated). 0000 = RX FIFO Interrupt Trigger Level is 1 byte. 0001 = RX FIFO Interrupt Trigger Level is 4 bytes. 0010 = RX FIFO Interrupt Trigger Level is 8 bytes. 0011 = RX FIFO Interrupt Trigger Level is 14 bytes. Other = Reserved. |
| [8] | RX_DIS | Receiver Disable Control
The receiver is disabled or not (setting 1 to disable the receiver). 0 = Receiver Enabled. 1 = Receiver Disabled. Note1: This field is only used for RS-485 Normal Multi-drop mode. It should be programmed firstly to avoid receiving unknown data before RS-485_NMM (UA_ALT_CSR [8]) is programmed. Note2: After RS-485 receives an address byte in RS-485 Normal Multi-drop mode, this bit (RX_DIS) will be cleared to "0" by hardware. |
| [19:16] | RTS_TRI_LEV | RTS Trigger Level (For Auto-flow Control Use)
0000 = RTS Trigger Level is 1 byte. 0001 = RTS Trigger Level is 4 bytes. 0010 = RTS Trigger Level is 8 bytes. 0011 = RTS Trigger Level is 14 bytes. Other = Reserved. Note: This field is used for RTS auto-flow control. |
Definition at line 9457 of file Mini51Series.h.
| UART_T::FSR |
| Bits | Field | Descriptions |
| [0] | RX_OVER_IF | RX Overflow Error Interrupt Flag
This bit is set when RX FIFO overflow. If the number of bytes of received data is greater than RX_FIFO (UA_RBR) size 16 bytes, this bit will be set. 0 = RX FIFO is not overflow. 1 = RX FIFO is overflow. Note: This bit is cleared by writing 1 to it. |
| [3] | RS485_ADD_DETF | RS-485 Address Byte Detection Flag
This bit is set to 1 while RS485_ADD_EN (UA_ALT_CSR[15]) is set to 1 to enable Address detection mode and receive detect a data with an address bit (bit 9 = 1). Note1: This field is used for RS-485 function mode. Note2: This bit is cleared by writing 1 to it. |
| [4] | PEF | Parity Error Flag (Read Only)
This bit is set to logic 1 whenever the received character does not have a valid "parity bit". 0 = No parity error is generated. 1 = Parity error is generated.Note: This bit is read only, but can be cleared by writing '1' to it . |
| [5] | FEF | Framing Error Flag (Read Only)
This bit is set to logic 1 whenever the received character does not have a valid "stop bit" (that is, the stop bit follows the last data bit or parity bit is detected as as logic 0). 0 = No framing error is generated. 1 = Framing error is generated. Note: This bit is read only, but can be cleared by writing '1' to it . |
| [6] | BIF | Break Interrupt Flag (Read Only)
This bit is set to logic 1 whenever the received data input (RX) is held in the "spacing state" (logic 0) for longer than a full word transmission time (that is, the total time of "start bit" + data bits + parity + stop bits). 0 = No Break interrupt is generated. 1 = Break interrupt is generated. Note: This bit is read only, but software can write 1 to clear it. |
| [13:8] | RX_POINTER | RX FIFO Pointer (Read Only)
This field indicates the RX FIFO Buffer Pointer. When UART receives one byte from external device, RX_POINTER increases one. When one byte of RX FIFO is read by CPU, RX_POINTER decreases one. The Maximum value shown in RX_POINTER is 15. When the using level of RX FIFO Buffer equal to 16, the RX_FULL bit is set to 1 and RX_POINTER will show 0. As one byte of RX FIFO is read by CPU, the RX_FULL bit is cleared to 0 and RX_POINTER will show 15. |
| [14] | RX_EMPTY | Receiver FIFO Empty (Read Only)
This bit initiate RX FIFO empty or not. 0 = RX FIFO is not empty. 1 = RX FIFO is empty. Note: When the last byte of RX FIFO has been read by CPU, hardware sets this bit high. It will be cleared when UART receives any new data. |
| [15] | RX_FULL | Receiver FIFO Full (Read Only)
This bit initiates RX FIFO full or not. 0 = RX FIFO is not full. 1 = RX FIFO is full. Note: This bit is set when the number of usage in RX FIFO Buffer is equal to 16, otherwise is cleared by hardware. |
| [21:16] | TX_POINTER | TX FIFO Pointer (Read Only)
This field indicates the TX FIFO Buffer Pointer. When CPU writes one byte into UA_THR, TX_POINTER increases one. When one byte of TX FIFO is transferred to Transmitter Shift Register, TX_POINTER decreases one. The Maximum value shown in TX_POINTER is 15. When the using level of TX FIFO Buffer equal to 16, the TX_FULL bit is set to 1 and TX_POINTER will show 0. As one byte of TX FIFO is transferred to Transmitter Shift Register, the TX_FULL bit is cleared to 0 and TX_POINTER will show 15. |
| [22] | TX_EMPTY | Transmitter FIFO Empty (Read Only)
This bit indicates TX FIFO is empty or not. 0 = TX FIFO is not empty. 1 = TX FIFO is empty. Note: When the last byte of TX FIFO has been transferred to Transmitter Shift Register, hardware sets this bit high. It will be cleared when writing data into THR (TX FIFO not empty). |
| [23] | TX_FULL | Transmitter FIFO Full (Read Only)
This bit indicates TX FIFO full or not. 0 = TX FIFO is not full. 1 = TX FIFO is full. Note: This bit is set when the number of usage in TX FIFO Buffer is equal to 16, otherwise is cleared by hardware. |
| [24] | TX_OVER_IF | TX Overflow Error Interrupt Flag
If TX FIFO (UA_THR) is full, an additional write to UA_THR will cause this bit to logic 1. 0 = TX FIFO is not overflow. 1 = TX FIFO is overflow. Note: This bit is cleared by writing 1 to it. |
| [28] | TE_FLAG | Transmitter Empty Flag (Read Only)
This bit is set by hardware when TX FIFO (UA_THR) is empty and the STOP bit of the last byte has been transmitted. 0 = TX FIFO is not empty. 1 = TX FIFO is empty and the STOP bit of the last byte has been transmitted. Note: This bit is cleared automatically when TX FIFO is not empty or the last byte transmission has not completed. |
Definition at line 9461 of file Mini51Series.h.
| UART_T::FUN_SEL |
| Bits | Field | Descriptions |
| [1:0] | FUN_SEL | Function Selection
00 = UART function mode. 01 = Reserved. 10 = IrDA function mode. 11 = RS-485 function mode. |
Definition at line 9467 of file Mini51Series.h.
| UART_T::IER |
| Bits | Field | Descriptions |
| [0] | RDA_IEN | Receive Data Available Interrupt Enable Control
0 = RDA_INT Masked off. 1 = RDA_INT Enabled. |
| [1] | THRE_IEN | Transmit Holding Register Empty Interrupt Enable Control
0 = THRE_INT Masked off. 1 = THRE_INT Enabled. |
| [2] | RLS_IEN | Receive Line Status Interrupt Enable Control
0 = RLS_INT Masked off. 1 = RLS_INT Enabled. |
| [3] | MODEM_IEN | Modem Status Interrupt Enable Control
0 = MODEM_INT Masked off. 1 = MODEM_INT Enabled. |
| [4] | RTO_IEN | RX Time-out Interrupt Enable Control
0 = TOUT_INT Masked off. 1 = TOUT_INT Enabled. |
| [5] | BUF_ERR_IEN | Buffer Error Interrupt Enable Control
0 = INT_BUF_ERR Masked Disabled. 1 = INT_BUF_ERR Enabled. |
| [6] | WAKE_EN | Wake-up CPU Function Enable Control
0 = UART wake-up function Disabled. 1 = UART Wake-up function Enabled. Note: when the chip is in Power-down mode, an external CTS change will wake-up chip from Power-down mode. |
| [11] | TIME_OUT_EN | Time-out Counter Enable Control
0 = Time-out counter Disabled. 1 = Time-out counter Enabled. |
| [12] | AUTO_RTS_EN | RTS Auto Flow Control Enable Control
0 = RTS auto flow control Disabled. 1 = RTS auto flow control Enabled. Note: When RTS auto-flow is enabled, if the number of bytes in the RX FIFO equals the RTS_TRI_LEV (UA_FCR [19:16]), the UART will de-assert RTS signal. |
| [13] | AUTO_CTS_EN | CTS Auto Flow Control Enable Control
0 = CTS auto flow control Disabled. 1 = CTS auto flow control Enabled. Note: When CTS auto-flow is enabled, the UART will send data to external device when CTS input assert (UART will not send data to device until CTS is asserted). |
Definition at line 9456 of file Mini51Series.h.
| UART_T::IRCR |
| Bits | Field | Descriptions |
| [1] | TX_SELECT | TX_SELECT
0 = IrDA receiver Enabled. 1 = IrDA transmitter Enabled. |
| [5] | INV_TX | INV_TX
0 = No inversion. 1 = Inverse TX output signal. |
| [6] | INV_RX | INV_RX
0 = No inversion. 1 = Inverse RX input signal. |
Definition at line 9465 of file Mini51Series.h.
| UART_T::ISR |
| Bits | Field | Descriptions |
| [0] | RDA_IF | Receive Data Available Interrupt Flag (Read Only)
When the number of bytes in the RX FIFO equals the RFITL then the RDA_IF will be set. If RDA_IEN (UA_IER [0]) is enabled, the RDA interrupt will be generated. 0 = No RDA interrupt flag is generated. 1 = RDA interrupt flag is generated. Note: This bit is read only and it will be cleared when the number of unread bytes of RX FIFO drops below the threshold level (RFITL). |
| [1] | THRE_IF | Transmit Holding Register Empty Interrupt Flag (Read Only)
This bit is set when the last data of TX FIFO is transferred to Transmitter Shift Register. If THRE_IEN (UA_IER [1]) is enabled, the THRE interrupt will be generated. 0 = No THRE interrupt flag is generated. 1 = THRE interrupt flag is generated. Note: This bit is read only and it will be cleared when writing data into THR (TX FIFO not empty). |
| [2] | RLS_IF | Receive Line Interrupt Flag (Read Only)
This bit is set when the RX receive data have parity error, framing error or break error (at least one of 3 bits, BIF, FEF and PEF, is set). If RLS_IEN (UA_IER [2]) is enabled, the RLS interrupt will be generated. 0 = No RLS interrupt flag is generated. 1 = RLS interrupt flag is generated. Note1: In RS-485 function mode, this field is set including "receiver detect and received address byte character (bit 9 = 1) bit". At the same time, the bit of RS485_ADD_DETF (UA_FSR[3]) is also set. Note2: This bit is read only and reset to 0 when all bits of BIF, FEF, PEF and RS485_ADD_DETF are cleared. |
| [3] | MODEM_IF | MODEM Interrupt Flag (Read Only)
This bit is set when the CTS pin has state change (DCTSF = 1). If UA_IER [MODEM_IEN] is enabled, the Modem interrupt will be generated. 0 = No Modem interrupt flag is generated. 1 = Modem interrupt flag is generated. Note: This bit is read only and reset to 0 when bit DCTSF is cleared by a write 1 on DCTSF. |
| [4] | TOUT_IF | Time-out Interrupt Flag (Read Only)
This bit is set when the RX FIFO is not empty and no activities occurred in the RX FIFO and the time-out counter equal to TOIC. If RTO_IEN (UA_IER [4]) is enabled, the Tout interrupt will be generated. 0 = No Time-out interrupt flag is generated. 1 = Time-out interrupt flag is generated. Note: This bit is read only and user can read UA_RBR (RX is in active) to clear it. |
| [5] | BUF_ERR_IF | Buffer Error Interrupt Flag (Read Only)
This bit is set when the TX/RX FIFO overflow flag (TX_OVER_IF or RX_OVER_IF) is set. When BUF_ERR_IF is set, the transfer is not correct. If BUF_ERR_IEN (UA_IER [5]) is enabled, the buffer error interrupt will be generated. 0 = No buffer error interrupt flag is generated. 1 = Buffer error interrupt flag is generated. Note: This bit is read only and reset to 0 when all bits of TX_OVER_IF and RX_OVER_IF are cleared. |
| [8] | RDA_INT | Receive Data Available Interrupt Indicator (Read Only)
This bit is set if RDA_IEN and RDA_IF are both set to 1. This bit is set if RDA_IEN and RDA_IF are both set to 1. 0 = No RDA interrupt is generated. 1 = RDA interrupt is generated. |
| [9] | THRE_INT | Transmit Holding Register Empty Interrupt Indicator (Read Only)
This bit is set if THRE_IEN and THRE_IF are both set to 1. 0 = No THRE interrupt is generated. 1 = THRE interrupt is generated. |
| [10] | RLS_INT | Receive Line Status Interrupt (Read Only)
This bit is set if RLS_IEN and RLS_IF are both set to 1. 0 = No RLS interrupt is generated. 1 = RLS interrupt is generated. |
| [11] | MODEM_INT | MODEM Status Interrupt Indicator (Read Only)
This bit is set if MODEM_IEN and MODEM_IF are both set to 1. 0 = No Modem interrupt is generated. 1 = Modem interrupt is generated. |
| [12] | TOUT_INT | Time-out Interrupt Indicator (Read Only)
This bit is set if RTO_IEN and TOUT_IF are both set to 1. 0 = No Time-out interrupt is generated. 1 = Time-out interrupt is generated. |
| [13] | BUF_ERR_INT | Buffer Error Interrupt Indicator (Read Only)
This bit is set if BUF_ERR_IEN and BUF_ERR_IF are both set to 1. 0 = No buffer error interrupt is generated. 1 = buffer error interrupt is generated. |
Definition at line 9462 of file Mini51Series.h.
| UART_T::LCR |
| Bits | Field | Descriptions |
| [1:0] | WLS | Word Length Selection
00 = Word length is 5-bit. 01 = Word length is 6-bit. 10 = Word length is 7-bit. 11 = Word length is 8-bit. |
| [2] | NSB | Number Of "STOP Bit"
0 = One "STOP bit" is generated in the transmitted data. 1 = When select 5-bit word length, 1.5 "STOP bit" is generated in the transmitted data. When select 6-, 7- and 8-bit word length, 2 "STOP bit" is generated in the transmitted data. |
| [3] | PBE | Parity Bit Enable Control
0 = No parity bit. 1 = Parity bit is generated on each outgoing character and is checked on each incoming data. |
| [4] | EPE | Even Parity Enable Control
0 = Odd number of logic 1's is transmitted and checked in each word. 1 = Even number of logic 1's is transmitted and checked in each word. This bit has effect only when PBE (UA_LCR[3]) is set. |
| [5] | SPE | Stick Parity Enable Control
0 = Stick parity Disabled. 1 = If PBE (UA_LCR[3]) and EBE (UA_LCR[4]) are logic 1, the parity bit is transmitted and checked as logic 0. If PBE (UA_LCR[3]) is 1 and EBE (UA_LCR[4]) is 0 then the parity bit is transmitted and checked as 1. |
| [6] | BCB | Break Control Bit
When this bit is set to logic 1, the serial data output (TX) is forced to the Spacing State (logic 0). This bit acts only on TX and has no effect on the transmitter logic. 0 = Break control Disabled. 1 = Break control Enabled. |
Definition at line 9458 of file Mini51Series.h.
| UART_T::MCR |
| Bits | Field | Descriptions |
| [1] | RTS | RTS (Request-to-send) Signal Control
This bit is direct control internal RTS signal active or not, and then drive the RTS pin output with LEV_RTS bit configuration. 0 = RTS signal is active. 1 = RTS signal is inactive. Note1: This RTS signal control bit is not effective when RTS auto-flow control (AUTO_RTS_EN) is enabled in UART function mode. Note2: This RTS signal control bit is not effective when RS-485 auto direction mode (RS485_AUD) is enabled in RS-485 function mode. |
| [9] | LEV_RTS | RTS Pin Active Level
This bit defines the active level state of RTS pin output. 0 = RTS pin output is high level active. 1 = RTS pin output is low level active. Note1: Refer to and UART function mode. Note2: Refer to and for RS-485 function mode. |
| [13] | RTS_ST | RTS Pin State (Read Only)
This bit mirror from RTS pin output of voltage logic status. 0 = RTS pin output is low level voltage logic state. 1 = RTS pin output is high level voltage logic state. |
Definition at line 9459 of file Mini51Series.h.
| UART_T::MSR |
| Bits | Field | Descriptions |
| [0] | DCTSF | Detect CTS State Change Flag
This bit is set whenever CTS input has change state, and it will generate Modem interrupt to CPU when MODEM_IEN (UA_IER [3]) is set to 1. 0 = CTS input has not change state. 1 = CTS input has change state. Note: This bit is cleared by writing 1 to it. |
| [4] | CTS_ST | CTS Pin Status (Read Only)
This bit mirror from CTS pin input of voltage logic status. 0 = CTS pin input is low level voltage logic state. 1 = CTS pin input is high level voltage logic state. Note: This bit echoes when UART Controller peripheral clock is enabled, and CTS multi-function port is selected. |
| [8] | LEV_CTS | CTS Pin Active Level
This bit defines the active level state of CTS pin input. 0 = CTS pin input is high level active. 1 = CTS pin input is low level active. Note: Refer to |
Definition at line 9460 of file Mini51Series.h.
| UART_T::RBR |
| Bits | Field | Descriptions |
| [7:0] | RBR | Receive Buffer Bits (Read Only)
By reading this register, the UART Controller will return an 8-bit data received from RX pin (LSB first). |
Definition at line 9453 of file Mini51Series.h.
| UART_T::THR |
| Bits | Field | Descriptions |
| [7:0] | THR | Transmit Holding Bits
By writing to this register, the UART sends out an 8-bit data through the TX pin (LSB first). |
Definition at line 9454 of file Mini51Series.h.
| UART_T::TOR |
| Bits | Field | Descriptions |
| [7:0] | TOIC | Time-out Interrupt Comparator
The time-out counter resets and starts counting (the counting clock = baud rate) whenever the RX FIFO receives a new data word. Once the content of time-out counter (TOUT_CNT) is equal to that of time-out interrupt comparator (TOIC), a receiver time-out interrupt (TOUT_INT) is generated if RTO_IEN (UA_IER [4]). A new incoming data word or RX FIFO empty clears TOUT_INT. In order to avoid receiver time-out interrupt generation immediately during one character is being received, TOIC value should be set between 40 and 255. So, for example, if TOIC is set with 40, the time-out interrupt is generated after four characters are not received when 1 stop bit and no parity check is set for UART transfer. |
| [15:8] | DLY | TX Delay Time Value
This field is used to program the transfer delay time between the last stop bit and next start bit. |
Definition at line 9463 of file Mini51Series.h.


Class AuthPanel
- MvcCore\Ext\Debug\Tracy\AuthPanel implements Tracy\IBarPanel
Namespace: MvcCore\Ext\Debug\Tracy
Located at ext-debug-tracy-auth/src/MvcCore/Ext/Tracy/AuthPanel.php
Located at ext-debug-tracy-auth/src/MvcCore/Ext/Tracy/AuthPanel.php
public
string
|
|
public
string
|
|
public
string
|
|
public static
object
|
#
setUpViewData( )
Set up view data, if data are completed, return them directly. - complete basic \MvcCore core objects to complere other view data - complete user and authorized boolean - set result data into static field |
string |
VERSION
MvcCore Extension - Debug - Tracy Panel - Auth - version: Comparation by PHP function version_compare(); |
#
'4.2.0'
|
public static
string
|
$Id
Debug panel id |
#
'auth-panel'
|
protected static
stdClass
|
$viewData
Prepared view data, only once, to render debug tab and debug panel content. |
#
NULL
|


|
QuantLib: a free/open-source library for quantitative finance
Fully annotated sources - version 1.30
|
#include <ql/processes/gsrprocesscore.hpp>
Public Member Functions | |
| GsrProcessCore (const Array ×, const Array &vols, const Array &reversions, Real T=60.0) | |
| Real | expectation_x0dep_part (Time w, Real xw, Time dt) const |
| Real | expectation_rn_part (Time w, Time dt) const |
| Real | expectation_tf_part (Time w, Time dt) const |
| Real | variance (Time w, Time dt) const |
| Real | y (Time t) const |
| Real | G (Time t, Time w) const |
| Real | sigma (Time t) const |
| Real | reversion (Time t) const |
| void | flushCache () const |
Protected Attributes | |
| const Array & | times_ |
| const Array & | vols_ |
| const Array & | reversions_ |
Private Member Functions | |
| int | lowerIndex (Time t) const |
| int | upperIndex (Time t) const |
| Real | time2 (Size index) const |
| Real | cappedTime (Size index, Real cap=Null< Real >()) const |
| Real | flooredTime (Size index, Real floor=Null< Real >()) const |
| Real | vol (Size index) const |
| Real | rev (Size index) const |
| bool | revZero (Size index) const |
Private Attributes | |
| std::map< std::pair< Real, Real >, Real > | cache1_ |
| std::map< std::pair< Real, Real >, Real > | cache2a_ |
| std::map< std::pair< Real, Real >, Real > | cache2b_ |
| std::map< std::pair< Real, Real >, Real > | cache3_ |
| std::map< std::pair< Real, Real >, Real > | cache5_ |
| std::map< Real, Real > | cache4_ |
| Time | T_ |
| std::vector< bool > | revZero_ |
Definition at line 39 of file gsrprocesscore.hpp.
| GsrProcessCore | ( | const Array & | times, |
| const Array & | vols, | ||
| const Array & | reversions, | ||
| Real | T = 60.0 |
||
| ) |
Definition at line 68 of file gsrprocesscore.cpp.
Definition at line 85 of file gsrprocesscore.cpp.
Definition at line 158 of file gsrprocesscore.cpp.
Definition at line 236 of file gsrprocesscore.cpp.
Definition at line 266 of file gsrprocesscore.cpp.
Definition at line 290 of file gsrprocesscore.cpp.
Definition at line 94 of file gsrprocesscore.hpp.
Definition at line 98 of file gsrprocesscore.hpp.
| void flushCache | ( | ) | const |
Definition at line 52 of file gsrprocesscore.cpp.
|
private |
Definition at line 314 of file gsrprocesscore.cpp.
|
private |
Definition at line 319 of file gsrprocesscore.cpp.
Definition at line 337 of file gsrprocesscore.cpp.
Definition at line 328 of file gsrprocesscore.cpp.
Definition at line 332 of file gsrprocesscore.cpp.
Definition at line 347 of file gsrprocesscore.cpp.
Definition at line 353 of file gsrprocesscore.cpp.
|
protected |
Definition at line 73 of file gsrprocesscore.hpp.
|
protected |
Definition at line 73 of file gsrprocesscore.hpp.
|
protected |
Definition at line 73 of file gsrprocesscore.hpp.
Definition at line 85 of file gsrprocesscore.hpp.
Definition at line 85 of file gsrprocesscore.hpp.
Definition at line 85 of file gsrprocesscore.hpp.
Definition at line 86 of file gsrprocesscore.hpp.
Definition at line 86 of file gsrprocesscore.hpp.
Definition at line 87 of file gsrprocesscore.hpp.
|
private |
Definition at line 88 of file gsrprocesscore.hpp.
|
mutableprivate |
Definition at line 89 of file gsrprocesscore.hpp.


.flaticon-construction-10
.flaticon-construction-12
.flaticon-construction-13
.flaticon-construction-14
.flaticon-construction-15
.flaticon-construction-16
.flaticon-construction-17
.flaticon-construction-18
.flaticon-construction-19
.flaticon-construction-20
.flaticon-construction-21
.flaticon-construction-22
.flaticon-construction-23
.flaticon-construction-24
.flaticon-construction-25
.flaticon-construction-26
.flaticon-construction-27
.flaticon-construction-28
.flaticon-construction-29
.flaticon-construction-30
.flaticon-construction-helmet
.flaticon-construction-worker
.flaticon-pipeline-with-wheel
.flaticon-vacuum-cleaner-3


--- title: Can Symptoms Surveys Improve COVID-19 Forecasts? author: Ryan Tibshirani date: 2020-09-21 tags: - symptom surveys - forecasting - COVIDcast - R authors: - ryan heroImage: blog-Lg-img_can symptoms surveys improve covid-19.jpg heroImageThumb: blog-thumbnail_can symptoms surveys improve covid-19.jpg summary: | Building on our previous two posts (on our COVID-19 symptom surveys through Facebook and Google) this post offers a deeper dive into empirical analysis, examining whether the % CLI-in-community indicators from our two surveys can be used to improve the accuracy of short-term forecasts of county-level COVID-19 case rates. acknowledgements: | Delphi's forecasting effort involves many people from our modeling team, from forecaster design, to implementation, to evaluation. The broader insights on forecasting shared in this post certainly cannot be attributable to Ryan's work alone, and are a reflection of the work carried out by all these team members. related: - 2020-09-18-google-survey - 2020-08-26-fb-survey output: html_document: code_folding: hide blogdown::html_page: toc: true ---
In our past two posts, we wrote about the COVID-19 symptom surveys that Delphi runs through {{< reflink "2020-08-26-fb-survey" "Facebook" >}} and {{< reflink "2020-09-18-google-survey" "Google" >}}. These surveys have asked millions of people in the United States whether they (or people they know) are experiencing COVID-like symptoms, allowing us to calculate a “% CLI-in-community” signal for counties across the United States: an estimate of the percentage of people who know someone who is currently sick with COVID-like illness. Because these surveys run daily and aren’t subject to the reporting delays and lag that can affect other data, such as COVID test results, they promise to be a valuable tool to monitor the spread of COVID-19. This post offers a deeper dive into empirical analysis than our past posts about the surveys, examining whether the % CLI-in-community indicators from our two surveys can be used to improve the accuracy of short-term forecasts of county-level COVID-19 case rates.
Forecasting has long been a primary initiative of the Delphi research group (in the past for flu, and currently for COVID-19). Each week since mid-July we’ve been submitting forecasts to the COVID Forecast Hub, which serves as the official data source for the CDC’s communications on COVID-19 forecasts.
At the outset, we should state that this post is neither a report on Delphi’s current COVID-19 forecasters nor an authoritative take on cutting-edge COVID-19 forecasting. Instead, our purpose here is to study the Facebook and Google % CLI-in-community signals, and demonstrate their value, when used as features, to add predictive power beyond what we can achieve with (fairly simple) time series models trained on case rates alone. In a future blog post, we’ll follow up with details on our “production” forecasters.
While we focus here on forecasting, there are a number of other important prediction problems that arise as part of the pandemic response. For example, we also work on hotspot detection, where the goal is to predict whether case rates will rise significantly, rather than to predict the future case rates directly, as in forecasting. To motivate why we might be optimistic about the utility of incorporating our survey signals into forecasting or hotspot detection models, you can check out our {{< reflink "2020-08-26-fb-survey#some-interesting-examples" "previous exploratory investigations" >}}, which suggested that they can serve as early indicators of COVID-19 activity. Stay tuned to the Delphi blog for a post on hotspot detection soon.
Next we explain the forecasting setup and results in detail. Some parts may get a bit technical, but we’ve tried to make the post accessible enough that you can catch the main points even if you skip the technical details.
Formally, our goal here is to predict county-level COVID-19 case incidence rates, 1 and 2 weeks ahead. Specifically, we wish to predict the number of new COVID-19 cases per capita, both over the next 1-7 days and over the next 8-14 days. One convenient (and equivalent) way to phrase this problem is to predict the smoothed COVID-19 case incidence rate 7 days ahead and 14 days ahead, where the smoothing is performed via a 7-day trailing average. We restrict our attention to the 440 counties that had at least 200 confirmed cases by May 14, 2020 (the end of the Google survey data) and in which both the Facebook and Google % CLI-in-community signals are available (there were 604 counties in total with at least 200 confirmed cases by May 14, and we dropped 164 of them due to a lack of Facebook or Google survey data).
To fix notation, let \(Y_{\ell,t}\) denote the smoothed COVID-19 case incidence rate for location (county) \(\ell\) and time (day) \(t\). Let \(F_{\ell,t}\) and \(G_{\ell,t}\) denote the Facebook and Google % CLI-in-community signals, respectively, for location \(\ell\) and time \(t\). (We rescale all these signals from their given values in our API so that they are true proportions: between 0 and 1.) We evaluate the following four models:
\[ \begin{aligned} h(Y_{\ell,t+d}) &\approx \alpha + \sum_{j=0}^2 \beta_j h(Y_{\ell,t-7j}) \\ h(Y_{\ell,t+d}) &\approx \alpha + \sum_{j=0}^2 \beta_j h(Y_{\ell,t-7j}) + \sum_{j=0}^2 \gamma_j h(F_{\ell,t-7j}) \\ h(Y_{\ell,t+d}) &\approx \alpha + \sum_{j=0}^2 \beta_j h(Y_{\ell,t-7j}) + \sum_{j=0}^2 \gamma_j h(G_{\ell,t-7j}) \\ h(Y_{\ell,t+d}) &\approx \alpha + \sum_{j=0}^2 \beta_j h(Y_{\ell,t-7j}) + \sum_{j=0}^2 \gamma_j h(F_{\ell,t-7j}) + \sum_{j=0}^2 \tau_j h(G_{\ell,t-7j}). \end{aligned} \]
Here \(d=7\) or \(d=14\), depending on the target value (number of days we predict ahead), and \(h\) is a transformation to be specified later.
Informally, the first model, which we’ll call the “Cases” model, bases its predictions of future case rates on the following three features: current COVID-19 case rates, and those 1 and 2 weeks back. The second model, “Cases + Facebook”, additionally incorporates the current Facebook signal, and the Facebook signal from 1 and 2 weeks back. The third model, “Cases + Google”, is exactly the same but substitutes the Google signal instead of the Facebook one. Finally, the fourth model, “Cases + Facebook + Google”, uses both Facebook and Google signals. For each model, in order to make a forecast at time \(t_0\) (to predict case rates at time \(t_0+d\)), we fit a linear model using least absolute deviations (LAD) regression, training over all locations \(\ell\) (all 440 counties), and all time \(t\) that are within the most recent 14 days of data available up to and including time \(t_0\).
Forecasts are transformed back to the original scale (we apply \(h^{-1}\) to the predictions from the fitted LAD model), and denoted \(\hat{Y}_{\ell,t_0+d}\). For an error metric, we consider scaled absolute error (or just scaled error for short):
\[ \frac{|\hat{Y}_{\ell,t_0+d} - Y_{\ell,t_0+d}|} {|Y_{\ell,t_0} - Y_{\ell,t_0+d}|}, \]
where the error in the denominator is the error of the “strawman” model, which for any target always simply predicts the most recent available case rate.
This normalization helps for two reasons. First, it gives us an interpretable scale, as we can understand the scaled error as a fraction improvement over the strawman’s error (so numbers like 0.8 or 0.9 would be favorable, and numbers like 2 or 5 or 10 would be increasingly disastrous). Second, in our forecasting problem, there turns out to a considerable amount of county-to-county variability in forecasting difficulty, and normalizing by the strawman’s error helps adjust for this (so that the aggregate results aren’t dominated by county-to-county differences).
We investigated three transformations \(h\): identity, log, and logit (the latter two being common variance-stabilizing transforms for proportions). The results in all three cases were quite similar and the qualitative conclusions don’t change at all (the code below supports all three, so you can check this for yourself). For brevity, we’ll just show the results for the logit transform (actually, a “padded” version \(h(x) = \log\left(\frac{x+a}{1-x+a}\right)\), where the numerator and denominator are pushed away from zero by a small constant, which we took to be \(a=0.01\)).
The code below marches the forecast date \(t_0\) forward, one day at a time (from April 11 to September 1), fits the four models, makes predictions 7 and 14 days ahead, and records errors. It takes a little while to run1, the culprit being LAD regression: the training sets in our forecasting problem get moderately large (aggregating the data over 440 counties and 14 days results in over 6000 training samples), and at this scale LAD regression is much slower than least squares regression. We ran this R code separately and saved the results in an RData file; you can find this in the same GitHub repo as the Rmd source for this blog post.
library(covidcast)
library(dplyr)
library(tidyr)
#### Functions #####
# Function to append shift values (lags or leads) to data frame
append_shifts = function(df, shifts) {
# Make sure that we have a complete record of dates for each geo_value (fill
# with NAs as necessary)
df_all = df %>% group_by(geo_value) %>%
summarize(time_value = seq.Date(as.Date(min(time_value)),
as.Date(max(time_value)),
by = "day")) %>% ungroup()
df = full_join(df, df_all, by = c("geo_value", "time_value"))
# Group by geo value, sort rows by increasing time
df = df %>% group_by(geo_value) %>% arrange(time_value)
# Load over shifts, and add lag value or lead value
for (shift in shifts) {
fun = ifelse(shift < 0, lag, lead)
varname = sprintf("value%+d", shift)
df = mutate(df, !!varname := fun(value, n = abs(shift)))
}
# Ungroup and return
return(ungroup(df))
}
# Some useful functions for transformations
Log = function(x, a = 0.01) log(x + a)
Exp = function(y, a = 0.01) exp(y) - a
Logit = function(x, a = 0.01) log((x + a) / (1 - x + a))
Sigmd = function(y, a = 0.01) (exp(y) * (1 + a) - a) / (1 + exp(y))
Id = function(x) x
#### Parameters #####
# Transforms to consider, in what follows
trans = Logit
inv_trans = Sigmd
# Rescale factors for our signals: bring them all down to proportions (between
# 0 and 1)
rescale_g = 1e-2 # Originally a percentage
rescale_f = 1e-2 # Originally a percentage
rescale_c = 1e-5 # Originally a count per 100,000 people
n = 14 # Number of trailing days to use for training set
lp_solver = "glpk" # LP solver to use in quantile_lasso()
verbose = TRUE # Print intermediate progress to console?
#### Data #####
# Consider only counties with at least 200 cumulative cases by Google's end
case_num = 200
geo_values = covidcast_signal("jhu-csse", "confirmed_cumulative_num",
"2020-05-14", "2020-05-14") %>%
filter(value >= case_num) %>% pull(geo_value)
# Fetch county-level Google and Facebook % CLI-in-community signals, and JHU
# confirmed case incidence proportion
start_day = "2020-04-11"
end_day = "2020-09-01"
g = covidcast_signal("google-survey", "smoothed_cli") %>%
filter(geo_value %in% geo_values) %>%
select(geo_value, time_value, value)
f = covidcast_signal("fb-survey", "smoothed_hh_cmnty_cli",
start_day, end_day) %>%
filter(geo_value %in% geo_values) %>%
select(geo_value, time_value, value)
c = covidcast_signal("jhu-csse", "confirmed_7dav_incidence_prop",
start_day, end_day) %>%
filter(geo_value %in% geo_values) %>%
select(geo_value, time_value, value)
# Find "complete" counties, present in all three data signals at all times
geo_values_complete = intersect(intersect(g$geo_value, f$geo_value),
c$geo_value)
# Filter to complete counties, transform the signals, append 1-2 week lags to
# all three, and also 1-2 week leads to case rates
lags = 1:2 * -7
leads = 1:2 * 7
g = g %>% filter(geo_value %in% geo_values_complete) %>%
mutate(value = trans(value * rescale_g)) %>%
append_shifts(shifts = lags)
f = f %>% filter(geo_value %in% geo_values_complete) %>%
mutate(value = trans(value * rescale_f)) %>%
append_shifts(shifts = lags)
c = c %>% filter(geo_value %in% geo_values_complete) %>%
mutate(value = trans(value * rescale_c)) %>%
append_shifts(shifts = c(lags, leads))
# Rename columns
colnames(g) = sub("^value", "goog", colnames(g))
colnames(f) = sub("^value", "fb", colnames(f))
colnames(c) = sub("^value", "case", colnames(c))
# Make one big matrix by joining these three data frames
z = full_join(full_join(g, f, by = c("geo_value", "time_value")),
c, by = c("geo_value", "time_value"))
##### Analysis #####
# Use quantgen for LAD regression (this package supports quantile regression and
# more; you can find it on GitHub here: https://github.com/ryantibs/quantgen)
library(quantgen)
res_list = vector("list", length = length(leads))
# Loop over lead, forecast dates, build models and record errors (warning: this
# computation takes a while)
for (i in 1:length(leads)) {
lead = leads[i]; if (verbose) cat("***", lead, "***\n")
# Create a data frame to store our forecast results. Code below populates its
# rows in a way that breaks from typical dplyr operations, done for efficiency
res_list[[i]] = z %>%
filter(between(time_value, as.Date(start_day) - min(lags) + lead,
as.Date(end_day) - lead)) %>%
select(geo_value, time_value) %>%
mutate(err0 = as.double(NA), err1 = as.double(NA), err2 = as.double(NA),
err3 = as.double(NA), err4 = as.double(NA), lead = lead)
valid_dates = unique(res_list[[i]]$time_value)
for (k in 1:length(valid_dates)) {
date = valid_dates[k]; if (verbose) cat(format(date), "... ")
# Filter down to training set and test set
z_tr = z %>% filter(between(time_value, date - lead - n, date - lead))
z_te = z %>% filter(time_value == date)
inds = which(res_list[[i]]$time_value == date)
# Create training and test responses
y_tr = z_tr %>% pull(paste0("case+", lead))
y_te = z_te %>% pull(paste0("case+", lead))
# Strawman model
if (verbose) cat("0")
y_hat = z_te %>% pull(case)
res_list[[i]][inds,]$err0 = abs(inv_trans(y_hat) - inv_trans(y_te))
# Cases only model
if (verbose) cat("1")
x_tr_case = z_tr %>% select(starts_with("case") & !contains("+"))
x_te_case = z_te %>% select(starts_with("case") & !contains("+"))
x_tr = x_tr_case; x_te = x_te_case # For symmetry wrt what follows
ok = complete.cases(x_tr, y_tr)
if (sum(ok) > 0) {
obj = quantile_lasso(as.matrix(x_tr[ok,]), y_tr[ok], tau = 0.5,
lambda = 0, lp_solver = lp_solver)
y_hat = as.numeric(predict(obj, newx = as.matrix(x_te)))
res_list[[i]][inds,]$err1 = abs(inv_trans(y_hat) - inv_trans(y_te))
}
# Cases and Facebook model
if (verbose) cat("2")
x_tr_fb = z_tr %>% select(starts_with("fb"))
x_te_fb = z_te %>% select(starts_with("fb"))
x_tr = cbind(x_tr_case, x_tr_fb)
x_te = cbind(x_te_case, x_te_fb)
ok = complete.cases(x_tr, y_tr)
if (sum(ok) > 0) {
obj = quantile_lasso(as.matrix(x_tr[ok,]), y_tr[ok], tau = 0.5,
lambda = 0, lp_solver = lp_solver)
y_hat = as.numeric(predict(obj, newx = as.matrix(x_te)))
res_list[[i]][inds,]$err2 = abs(inv_trans(y_hat) - inv_trans(y_te))
}
# Cases and Google model
if (verbose) cat("3")
x_tr_goog = z_tr %>% select(starts_with("goog"))
x_te_goog = z_te %>% select(starts_with("goog"))
x_tr = cbind(x_tr_case, x_tr_goog)
x_te = cbind(x_te_case, x_te_goog)
ok = complete.cases(x_tr, y_tr)
if (sum(ok) > 0) {
obj = quantile_lasso(as.matrix(x_tr[ok,]), y_tr[ok], tau = 0.5,
lambda = 0, lp_solver = lp_solver)
y_hat = as.numeric(predict(obj, newx = as.matrix(x_te)))
res_list[[i]][inds,]$err3 = abs(inv_trans(y_hat) - inv_trans(y_te))
}
# Cases, Facebook, and Google model
if (verbose) cat("4\n")
x_tr = cbind(x_tr_case, x_tr_fb, x_tr_goog)
x_te = cbind(x_te_case, x_te_fb, x_te_goog)
ok = complete.cases(x_tr, y_tr)
if (sum(ok) > 0) {
obj = quantile_lasso(as.matrix(x_tr[ok,]), y_tr[ok], tau = 0.5,
lambda = 0, lp_solver = lp_solver)
y_hat = as.numeric(predict(obj, newx = as.matrix(x_te)))
res_list[[i]][inds,]$err4 = abs(inv_trans(y_hat) - inv_trans(y_te))
}
}
}
# Bind results over different leads into one big data frame, and save
res = do.call(rbind, res_list)
save(list = ls(), file = "demo.rda")
We first compare the results across all four models. For this analysis, we filter down to common forecast dates available for the four models (to set an even footing for the comparison), which ends up being May 6 through May 14 for 7-day-ahead forecasts, and only May 13 through May 14 for 14-day-ahead forecasts. (The reason for this shortened period: we paused running the Google survey on May 14 so its data ends there, but as we explained in our last post, we {{< reflink "2020-09-18-google-survey#google-survey-redux" "plan to bring it back" >}} later this fall.) Hence we skip studying the 14-day-ahead forecasts results in this four-way model discussion, as they’re only based on 2 days of test data.
Below we compute and print the median scaled errors for each of the four models over the 9-day test period (recall that the scaled error is the absolute error of the model’s forecast relative to that of the strawman; and each test day actually comprises 440 forecasts, over the 440 counties being considered). We can see that adding either or both of the survey signals improves on the median scaled error of the model that uses cases only, with the biggest gain achieved by the “Cases + Google” model. We can also see that the median scaled errors are all close to 1 (with all but that from “Cases + Google” model exceeding 1), which speaks to the difficulty of the forecasting problem.
load("forecast-demo/demo.rda")
library(dplyr)
library(tidyr)
library(ggplot2)
model_names = c("Cases", "Cases + Facebook", "Cases + Google",
"Cases + Facebook + Google")
# Restrict to common period for all 4 models, then calculate the scaled errors
# for each model, that is, the error relative to the strawman's error
res_all4 = res %>%
drop_na() %>% # Restrict to common time
mutate(err1 = err1 / err0, err2 = err2 / err0, # Compute relative error
err3 = err3 / err0, err4 = err4 / err0) %>% # to strawman model
mutate(dif12 = err1 - err2, dif13 = err1 - err3, # Compute differences
dif14 = err1 - err4) %>% # relative to cases model
ungroup() %>%
select(-err0)
# Calculate and print median errors, for all 4 models, and just 7 days ahead
res_err4 = res_all4 %>%
select(-starts_with("dif")) %>%
pivot_longer(names_to = "model", values_to = "err",
cols = -c(geo_value, time_value, lead)) %>%
mutate(lead = factor(lead, labels = paste(leads, "days ahead")),
model = factor(model, labels = model_names))
knitr::kable(res_err4 %>%
group_by(model, lead) %>%
summarize(err = median(err), n = length(unique(time_value))) %>%
arrange(lead) %>% ungroup() %>%
rename("Model" = model, "Median scaled error" = err,
"Target" = lead, "Test days" = n) %>%
filter(Target == "7 days ahead"),
caption = paste("Test period:", min(res_err4$time_value), "to",
max(res_err4$time_value)),
format = "html", table.attr = "style='width:70%;'")
| Model | Target | Median scaled error | Test days |
|---|---|---|---|
| Cases | 7 days ahead | 1.0393350 | 9 |
| Cases + Facebook | 7 days ahead | 1.0111709 | 9 |
| Cases + Google | 7 days ahead | 0.9838905 | 9 |
| Cases + Facebook + Google | 7 days ahead | 1.0168668 | 9 |
Are these differences in median scaled errors significant? It’s hard to say, but some basic hypothesis testing suggests that they probably are: below we conduct a sign test2 for whether the difference in the “Cases” model’s scaled error and each other model’s scaled error is centered at zero. The sign test is run on the 9 test days x 440 counties = 3960 pairs of scaled errors. The p-values from the “Cases” versus “Cases + Facebook” and the “Cases” versus “Cases + Google” tests are tiny; the p-value from the “Cases” versus “Cases + Facebook + Google” test is much bigger but still below 0.01.
# Compute p-values using the sign test against a one-sided alternative, for
# all models, and just 7 days ahead
res_dif4 = res_all4 %>%
select(-starts_with("err")) %>%
pivot_longer(names_to = "model", values_to = "dif",
cols = -c(geo_value, time_value, lead)) %>%
mutate(lead = factor(lead, labels = paste(leads, "days ahead")),
model = factor(model,
labels = c("Cases vs Cases + Facebook",
"Cases vs Cases + Google",
"Cases vs Cases + Facebook + Google")))
knitr::kable(res_dif4 %>%
group_by(model, lead) %>%
summarize(p = binom.test(x = sum(dif > 0, na.rm = TRUE),
n = n(), alt = "greater")$p.val) %>%
ungroup() %>% filter(lead == "7 days ahead") %>%
rename("Comparison" = model, "Target" = lead, "P-value" = p),
format = "html", table.attr = "style='width:50%;'")
| Comparison | Target | P-value |
|---|---|---|
| Cases vs Cases + Facebook | 7 days ahead | 0.0000048 |
| Cases vs Cases + Google | 7 days ahead | 0.0000006 |
| Cases vs Cases + Facebook + Google | 7 days ahead | 0.0088436 |
We should read these with a grain of salt: the sign test here assumes independence of observations, which clearly can’t be true, given the spatiotemporal structure of our forecasting problem. To mitigate the dependence across time (which intuitively seems to matter more than that across space), we recomputed these tests in a stratified way, where for each day we run a sign test on the scaled errors between two models over all 440 counties. The results are plotted as histograms below; the “Cases + Facebook” and “Cases + Google” models appear to deliver some decently small p-values, but the story is not as clear with the “Cases + Facebook + Google” model.
# Red, blue (similar to ggplot defaults), then yellow
ggplot_colors = c("#FC4E07", "#00AFBB", "#E7B800")
ggplot(res_dif4 %>%
group_by(model, lead, time_value) %>%
summarize(p = binom.test(x = sum(dif > 0, na.rm = TRUE),
n = n(), alt = "greater")$p.val) %>%
ungroup() %>% filter(lead == "7 days ahead"), aes(p)) +
geom_histogram(aes(color = model, fill = model), alpha = 0.4) +
scale_color_manual(values = ggplot_colors) +
scale_fill_manual(values = ggplot_colors) +
facet_wrap(vars(lead, model)) +
labs(x = "P-value", y = "Count") +
theme_bw() + theme(legend.pos = "none")
Next we focus on comparing results between the “Cases” and “Cases + Facebook” models only. Restricting to a common available forecast dates yields a much longer test period, May 6 through August 25 for 7-day-ahead forecasts, and May 13 through August 18 for 14-day-ahead forecasts. The median scaled errors over the test period are computed and reported below. Now we see a decent improvement in median scaled error for the “Cases + Facebook” model, and this is true for both 7-day-ahead and 14-day-ahead forecasts.
# Restrict to common period for just models 1 and 2, then calculate the scaled
# errors, that is, the error relative to the strawman's error
res_all2 = res %>%
select(-c(err3, err4)) %>%
drop_na() %>% # Restrict to common time
mutate(err1 = err1 / err0, err2 = err2 / err0) %>% # Compute relative error
# to strawman model
mutate(dif12 = err1 - err2) %>% # Compute differences
# relative to cases model
ungroup() %>%
select(-err0)
# Calculate and print median errors, for just models 1 and 2, and both 7 and 14
# days ahead
res_err2 = res_all2 %>%
select(-starts_with("dif")) %>%
pivot_longer(names_to = "model", values_to = "err",
cols = -c(geo_value, time_value, lead)) %>%
mutate(lead = factor(lead, labels = paste(leads, "days ahead")),
model = factor(model, labels = model_names[1:2]))
knitr::kable(res_err2 %>%
select(-starts_with("dif")) %>%
group_by(model, lead) %>%
summarize(err = median(err), n = length(unique(time_value))) %>%
arrange(lead) %>% ungroup() %>%
rename("Model" = model, "Median scaled error" = err,
"Target" = lead, "Test days" = n),
caption = paste("Test period:", min(res_err2$time_value), "to",
max(res_err2$time_value)),
format = "html", table.attr = "style='width:70%;'")
| Model | Target | Median scaled error | Test days |
|---|---|---|---|
| Cases | 7 days ahead | 0.9579517 | 112 |
| Cases + Facebook | 7 days ahead | 0.9397304 | 112 |
| Cases | 14 days ahead | 1.0011765 | 98 |
| Cases + Facebook | 14 days ahead | 0.9753763 | 98 |
Thanks to the extended length of the test period, we can also “unravel” these median scaled errors over time and plot their trajectories, as we do below, with the left plot concerning 7-day-ahead forecasts, and the right 14-day-ahead forecasts. These plots reveal something at once interesting and bothersome: the median scaled errors are quite volatile over time, and for some periods in July, forecasting became much “harder”, with the scaled errors reaching above 1.25 for 7-day-ahead forecasts, and above 1.5 for 14-day-ahead forecasts. Furthermore, towards the positive, we can see a clear visual difference between the median scaled errors from the “Cases + Facebook” model in red and the “Cases” model in black. The former appears to be below the latter pretty consistently over time, with the possible exception of periods where forecasting becomes “hard” and the scaled errors shoot above 1.
# Plot median errors as a function of time, for models 1 and 2, and both 7 and
# 14 days ahead
ggplot(res_err2 %>%
group_by(model, lead, time_value) %>%
summarize(err = median(err)) %>% ungroup(),
aes(x = time_value, y = err)) +
geom_line(aes(color = model)) +
scale_color_manual(values = c("black", ggplot_colors)) +
geom_hline(yintercept = 1, linetype = 2, color = "gray") +
facet_wrap(vars(lead)) +
labs(x = "Date", y = "Median scaled error") +
theme_bw() + theme(legend.pos = "bottom", legend.title = element_blank())
Again, basic hypothesis testing suggests that the results we’re seeing here are likely significant, though it’s hard to say definitively given the complicated dependence structure present in the data. Below we perform a sign test for whether the difference in scaled errors from the “Cases” and “Cases + Facebook” models is centered at zero. Given the large sample size: 112 test days for 7-day-ahead forecasts and 98 test days for 14-day-ahead forecasts (times 440 counties for each day), the p-values are basically zero.
# Compute p-values using the sign test against a one-sided alternative, just
# for models 1 and 2, and both 7 and 14 days ahead
res_dif2 = res_all2 %>%
select(-starts_with("err")) %>%
pivot_longer(names_to = "model", values_to = "dif",
cols = -c(geo_value, time_value, lead)) %>%
mutate(lead = factor(lead, labels = paste(leads, "days ahead")),
model = factor(model, labels = "Cases > Cases + Facebook"))
knitr::kable(res_dif2 %>%
group_by(model, lead) %>%
summarize(p = binom.test(x = sum(dif > 0, na.rm = TRUE),
n = n(), alt = "greater")$p.val) %>%
ungroup() %>%
rename("Comparison" = model, "Target" = lead, "P-value" = p),
format = "html", table.attr = "style='width:50%;'")
| Comparison | Target | P-value |
|---|---|---|
| Cases > Cases + Facebook | 7 days ahead | 0 |
| Cases > Cases + Facebook | 14 days ahead | 0 |
Once we stratify and recompute p-values by forecast date, as shown in the histograms below, the bulk of p-values are still quite small.
ggplot(res_dif2 %>%
group_by(model, lead, time_value) %>%
summarize(p = binom.test(x = sum(dif > 0, na.rm = TRUE),
n = n(), alt = "greater")$p.val) %>%
ungroup(), aes(p)) +
geom_histogram(aes(color = model, fill = model), alpha = 0.4) +
scale_color_manual(values = ggplot_colors) +
scale_fill_manual(values = ggplot_colors) +
facet_wrap(vars(lead, model)) +
labs(x = "P-value", y = "Count") +
theme_bw() + theme(legend.pos = "none")
Hypothesis tests (like the sign tests conducted above) tell us whether the differences in errors (between the forecasters) are statistically significant, but not about their practical significance. For example, for 7-day-ahead forecasts, what does an improvement of 0.018 units on the scaled error scale really mean, when comparing the “Cases + Facebook” model to the “Cases” model (over the test period May 6 through August 25)? Is this a meaningful gain?
To answer questions like this,
we can look at the way that the median scaled errors
behave as a function of the number of days ahead
at which we’re making the forecasts.
Previously, we considered forecasting case rates
just 7 and 14 days ahead;
now we systematically examine 5, 6, 7, etc., through 20 days ahead.
As before, we ran the code for this separately
and saved the results in an RData file,
which you can find in the same GitHub
repo
as the Rmd source for this blog post.
(It’s exactly the same code as that above,
but with leads = 5:20
.)
Below, we compute and plot the median scaled errors for the “Cases” and “Cases + Facebook” models for different number of days ahead for the forecast target. This is done over all forecast dates common to the two models (May 6 through August 27, or earlier—the end date gets decremented each time we increase the number of days ahead). A first glance shows that the “Cases + Facebook” model, in red, gives better median scaled errors at all ahead values; and the vertical gap between the two curves is consistently in the range of what we were seeing before (for 7 and 14 days ahead), around 0.02 units or more on the scaled error scale.
load("forecast-demo/demo-extended.rda")
# Compute and plot median errors as function of number of days ahead
err_by_lead = res %>%
select(-c(err3, err4)) %>%
drop_na() %>% # Restrict to common time
mutate(err1 = err1 / err0, err2 = err2 / err0) %>% # Compute relative error
# to strawman model
ungroup() %>%
select(-err0) %>%
pivot_longer(names_to = "model", values_to = "err",
cols = -c(geo_value, time_value, lead)) %>%
mutate(model = factor(model, labels = model_names[1:2])) %>%
group_by(model, lead) %>%
summarize(err = median(err)) %>%
ungroup()
ggplot(err_by_lead, aes(x = lead, y = err)) +
geom_line(aes(color = model)) +
geom_point(aes(color = model)) +
scale_color_manual(values = c("black", ggplot_colors)) +
geom_hline(yintercept = err_by_lead %>%
filter(lead %in% 7, model == "Cases") %>% pull(err),
linetype = 2, color = "gray") +
labs(title = "Forecasting errors by number of days ahead",
subtitle = sprintf("Over all counties with at least %i cumulative cases",
case_num),
x = "Number of days ahead", y = "Median scaled error") +
theme_bw() + theme(legend.pos = "bottom", legend.title = element_blank())
But if we look at it from a different angle, and consider the horizontal gap between the curves, then we can infer something quite a bit more interesting: for 7-day-ahead forecasts, the median scaled error of the “Cases” model (marked by a horizontal gray line) is comparable to that of 12-day-ahead forecasts from the “Cases + Facebook” model. So you could say that using the % CLI-in-community signal from our Facebook survey buys us 5 extra days of lead time for this forecasting problem, which seems pretty nontrivial. Different forecast targets yield different lead times (for 14-day-ahead forecasts, for example, it appears to be more like 3 or 4 days of lead time), but the added value of the survey signal is clear throughout.
We’ve seen that either of the Facebook or Google % CLI-in-community signals can improve the accuracy of short-term forecasts of county-level COVID-19 case incidence rates. The significance of these improvements is more apparent with the Facebook signal, thanks to the much longer test period available. With either signal, of the magnitude of the improvement offered seems modest but nontrivial, especially because the forecasting problem is so hard in the first place.
We reiterate that this was just a demo. Our analysis was fairly simple and lacks a few qualities that we’d expect in a truly comprehensive, realistic forecasting analysis. To name three:
The models we considered are simple autoregressive structures from standard time series, and could be improved in various ways (including, considering other relevant dimensions like mobility measures, county health metrics, etc.).
The forecasts we produced are point rather than distributional forecasts (that is, we predict a single number, rather than an entire distribution, for what happens 7 and 14 days ahead). Distributional forecasts portray uncertainty in a transparent way, which is important in practice.
The way we trained our forecast models does not account for data latency and revisions, which are critical issues. For each (retrospective) forecast date \(t_0\), we constructed forecasts by training on data that we fetched from the API today, “as of” the day we wrote this blog post, and not “as of” the forecast date \(t_0\). This matters because nearly all signals are subject to latency (they are only available at some number of days lag) and go through multiple revisions (past data values get updated as time goes on).
On the flip side, our example here was not that “far away” from being realistic.
The models we examined are actually not too different from Delphi’s forecasters
“in production”.3 Also, the way we fit LAD regression models in the code
extends immediately to multiple quantile regression
(just requires changing the parameter tau
in the call to quantile_lasso()
),
which would give us distributional forecasts.
And lastly, it’s fairly easy to change the data acquisition step in the code
so that data gets pulled “as of” the forecast date
(requires specifying the parameter as_of
in the call to covidcast_signal()
).
Hopefully these preliminary findings have gotten you excited about the possible uses of our symptom survey data. To get started playing with our data yourself, take a look at our {{< reflink "covidcast" "interactive COVIDcast map" >}}, or our {{< apireflink "api/covidcast.html" "COVIDcast API" >}}, through our R client or Python client. And if you’re feeling adventurous, consider competing in the COVID-19 Symptom Data Challenge, and trying your hand at developing novel analytic approaches to extract insights from our Facebook symptom survey data. We’ve made extensive data aggregate data from our survey (beyond CLI indicators) available for the Challenge, and submissions are due September 29, with finalists eligible for cash prizes. We look forward to seeing how you put our data to use!
Note: This post was updated on September 25, 2020 to include the section Varying the Number of Days Ahead.
The R package quantgen allows you to choose between Gurobi or GLPK as the underlying LP solver. The default is GLPK, since it’s open source; but if you can use Gurobi (which is free for academic use), then this forecast demo will run much faster.↩
As far as nonparametric tests of medians go, Wilcoxon’s signed-rank test (for paired data, as we have here) is more popular, because it tends to be more powerful than the sign test. Applied here, it does indeed give smaller p-values pretty much across the board. However, it assumes symmetry of the distribution in question (in our case, the difference in scaled errors), whereas the sign test does not, and thus we show results from the latter.↩
Delphi’s “production” forecasters are still based on relatively simple times series models, though to be clear they’re distributional, and we add a couple of extra layers of complexity on top of standard structures. For short-term forecasts, we’ve found that simple statistical models can be competitive with compartmental models (like SIR and its many variants), even fairly complicated ones. Being statisticians and computer scientists, we find these statistical models are easier to build, debug, and most importantly, calibrate.


Last amended: 16 May 2023, app version 1.43
This privacy notice explains how your data is processed and what data protection rights you have when using the CovPass app to manage certain certificates – digital COVID Certificates proving coronavirus vaccinations, negative coronavirus test results, or that you have recovered from a confirmed case of coronavirus.
Please also note the data protection information that you receive when your digital COVID Certificate is issued (e.g. at a vaccination/testing centre, doctor’s surgery or pharmacy).
This privacy notice covers the following topics:
Do you have any questions about the CovPass-App? Answers to many common questions can be found on the RKI’s official CovPass website (www.digitaler-impfnachweis-app.de/faq).
This app is published by the Robert Koch Institute (RKI) for the German Federal Government. The RKI is also responsible for ensuring that your personal data is processed in compliance with data protection regulations.
The digital COVID Certificate is proof that a person has
Digital COVID Certificates have been valid within the entire European Union (EU) since 1 July 2021 as certification of COVID-19 vaccination and testing, and of recovery from a confirmed case of COVID-19. The official name is “EU Digital COVID Certificate” (certificate).
A certificate can be obtained on request from a competent entity (vaccination centres, testing points, doctor’s surgeries or pharmacies) after a vaccination, a test or after recovering from a confirmed case of COVID-19.
You can carry the certificate in paper form or in electronic form on your smartphone. Each certificate contains a QR code with an electronic signature from the RKI to protect against forgeries. If you would like to store a certificate on your smartphone, you can simply scan the QR code with the CovPass app. The app then securely stores an electronic version of the certificate on your smartphone.
More information about how the certificate works is available on the following websites:
Please note that the QR codes on the certificates contain health data (data about coronavirus vaccinations, coronavirus test results or your recovery from a confirmed case of coronavirus). You should only show the certificates and QR codes if you want to provide appropriate proof. Do not provide QR codes to anyone if you do not want the data to be read. To prevent unwanted access to the certificates stored on your smartphone, you should set up a code lock on the device.
Yes, using the app is voluntary. Each certificate can also be used in paper form as proof of vaccination, a test result or recovery. You will not suffer any disadvantages, because the paper version and the electronic version of the certificate are equivalent. You can decide at any time whether you want to scan the QR code and store the certificate in the app. You can also delete the certificate from the app at any time.
The RKI briefly processes the necessary personal data of certificate holders to technically create and sign the requested certificate (Sect. 22a (5)–(7) of the Infection Protection Act, IfSG). The personal data is deleted at the RKI immediately once the technical creation of the certificate is complete. There is no centrally administered registry of vaccinations or certificates.
You can use the CovPass app to scan your own printed certificates and those of family members and store them in encrypted form on your smartphone.
In order to prove to third parties – in the situations where this is required by law – that you have been vaccinated, have tested negative, or have recovered from COVID-19, you can show the relevant certificate to the person performing the check. If the person performing the check uses a special verification app (such as the RKI’s CovPassCheck app), it is sufficient to show the QR code of the certificate and have it scanned. The QR code is the certificate in digital form and contains only the information necessary for the specific type of certificate (see Section 5).
The verification app allows for example authorities, travel companies and other service providers in the EU to scan the QR code of certificates presented to them, in order to verify whether the certificates are valid and prove a complete vaccination protection. During the verification, the data contained in the certificate is read. For the certificate to be valid, it must meet the following technical and formal criteria:
The verification app will show whether the certificate provided is valid, if applicable whether another certificate needs to be scanned. If the certificate is valid, the name and date of birth of the certificate holder will also be disclosed, as will whether or not it is a test certificate. In the case of test certificates, the time of sampling will also be displayed.
The name and date of birth of the certificate holder are displayed so that the person performing the check can compare this information with an ID document (e.g. passport or ID card). A notification of whether the certificate is a test certificate, and the time of sampling, are necessary to enable the person performing the check to assess whether the test result on which the certificate is based is still valid.
To protect against forged certificates, it is necessary to verify the authenticity of the stored certificates. The electronic signature contained in a certificate’s QR code is used for this purpose. The electronic signature is generated by the RKI when creating the certificate, on the basis of the data contained in the certificate (see Section 5). The signature is a special type of encryption that allows the RKI to confirm that the certificate is an official digital document created by the RKI. The RKI also provides the corresponding public keys from the RKI. These public keys can be used to check whether a certificate’s electronic signature actually originates from the RKI and whether the certificate has been manipulated since being signed electronically.
To protect the health of certificate holders and the public, certain certificates may be revoked in special cases. This may be necessary, for example, if a competent entity (e.g. pharmacy, vaccination centre or doctor’s surgery) has issued an incorrect certificate. The competent hazard prevention authorities will decide on whether to revoke a certificate, and the revocation is then technically implemented by the RKI (Sect. 22a(8) IfSG). Revocation will result in the certificate becoming invalid and no longer being accepted when verified. It does not matter whether the certificate is presented in electronic form on a smartphone or on paper during the verification. If you have stored a revoked certificate in the app, it will show as “invalid”.
To be able to determine the validity of the electronic signature or whether stored certificates have been revoked, the app regularly downloads the RKI’s current public keys and revocation lists in the background and stores them locally on your smartphone. The public keys do not contain any personal data. The revocation lists only contain a revocation identifier for a revoked certificate in the form of special one-way encryption (what’s known as a hash value). The revocation identifier cannot be used to infer the certificate data or other information about a particular person. The RKI receives the revocation identifier of a certificate to be revoked from the competent hazard prevention authority, which has read this identifier from the incorrect certificate. If, in exceptional cases, it is necessary to revoke all certificates issued by the same competent entity (e.g. a specific pharmacy), only a small subsection from the unique certificate identifier of the issued certificates will be transferred to the revocation list instead of the individual revocation identifiers. This subsection is identical for all certificates issued by the same competent entity. The CovPass app then compares this with the unique certificate identifier of the certificates stored on the smartphone. If there is a match between the identifier of the stored certificates and the certificates on the revocation list, the certificate in question will show as “invalid” in the CovPass app. Both the verification of the electronic signature and the comparison with the revocation lists take place exclusively locally in the app and no data about this process is passed on to the RKI or other agencies.
The app can remind you to check stored vaccination certificates if you received your last vaccination a long time ago. To do this, the app downloads the current rules on booster vaccination recommendations from the app’s server system at regular intervals. The app then uses the data contained in the certificates to check whether a booster vaccination is recommended soon. This check also takes place exclusively offline in the app and no data about the vaccination is passed on to the RKI.
You have the option of exporting a certificate stored in the CovPass app, in order to print it out and use the paper version (e.g. when travelling for extended periods) or scan the certificate afterwards with a new smartphone and store it again as an electronic version in the CovPass app (e.g. if you get a new smartphone). The “Create PDF” feature uses the data of the certificate stored in the CovPass app in order to create a PDF file. This processing is performed only locally on your smartphone. You then have the option of storing this PDF file. The PDF document contains sensitive health data (data about coronavirus vaccinations, test results or recovery from confirmed cases of coronavirus). Therefore, please keep the stored or printed certificate safe and do not publish or share the document.
When you book a ticket with a travel or event company or other provider, you can use the app to submit a digital COVID certificate to the provider’s verification partner so that it can verify the validity of the certificate for your booking with the travel or event company.
To do this, you will need to have added a digital COVID certificate in the CovPass app. The app will ask the provider for the booking information to be used for verification and suggest a suitable certificate based on this information. You can then select this and send it to the verification partner together with the booking information made available by the provider (See Section 5 c.).
The verification partner will check whether the certificate’s electronic signature is genuine and that the technical expiration date has not passed. The verification partner will immediately inform the provider of the result of this verification. The only information communicated will be whether the verification was successful or not. You will also be shown the result of the verification in the CovPass app.
The booking information made available by the provider is only processed locally in the CovPass app. This means the RKI cannot tell which certificates you have selected and had verified or which trips or events you have booked.
The RKI is not responsible for the data processing performed by the provider and the verification partner. Please read their privacy notices so that you know what your data is used for and how it is used.
It may happen that the app offers you to update a valid certificate. If, for example, the EU Member States decide to change the content or structure of the certificate data (see Section 5 a.), then it may be necessary to apply that formal or technical change to your certificates so that you can continue to use them without any problems.
The app uses the data contained in the certificates to check whether it is possible to update a certificate via the app. If this is the case, you will then be advised of a possible update. For the update, with your consent, the certificate required for the update will be transmitted from the app to the app’s server system in encrypted form. If the certificate to be updated is a vaccination certificate proving a booster vaccination, then the certificates proving the basic immunisation or recovery prior to the booster vaccination will also be transmitted to the app’s server system in the process. The validity of the transmitted certificates will then be checked there (see Section 4 c.). A new version of the certificate for the booster vaccination will be generated using the data from the transmitted certificates. During the update, the contents of the transmitted certificates will be processed for a short time. The updated certificate will then be sent back to your app.
In order to be able to prevent users from using the update feature several times, which is not permitted, the signatures of the updated and new certificates are temporarily stored by means of special one-way encryption (what are known as hash values). The hash values cannot be used to infer the certificate data or other information about you. The hash values will be deleted again 365 days after the update.
The certificates contain health data and are stored in a secure area on your smartphone. The certificates contain the following data:
You can find out what specific information is stored in a certificate from the information provided on the certificate (in German and English). No information other than that indicated on the certificate is stored.
This data will be stored in the app as soon as you scan the QR code on the printed certificate. This data was collected previously by the entity that issued the certificate, and transmitted to the RKI so that the certificate could be signed.
When a certificate is updated, the hash values of the signatures of the updated and new certificates are temporarily stored on the app’s server system by means of special one-way encryption (see Section 4 e.).
In order to download the RKI’s public key for authenticating the electronic signature, the current revocation lists and the rules on booster vaccination recommendations, a connection needs to be established to an RKI server. The server has to process technical access data for this purpose. This data includes the following:
This access data is processed to enable and secure the connection and data exchange between the app and the server. You will not be identified personally as a user of the app and no user profile will be created. Your IP address will not be stored beyond the end of the individual usage procedure.
If you make a booking via the internet with a travel or event company or other provider, you can use the CovPass app to prove to the provider that you have a valid digital COVID certificate (verification of certificates for ticket bookings). To do this, you will need to have added a digital COVID certificate in the CovPass app. In addition, the provider must be connected to a verification service.
To check the certificate, you will require a special QR code which you will receive from the provider as part of the booking process. This QR code contains a unique transaction ID, a short description of the booking (e.g. “booking number 1234”) and an internet address (URL).
The CovPass app uses this information to retrieve technical specifications from the provider as well as the following booking information for consideration when verifying the COVID certificate:
The provider decides which specific information will be used to verify the COVID certificate, and which COVID certificates are permitted as proof.
The RKI processes the certificate data mentioned above in Section 5 a. for the purpose of technically creating and signing the requested certificate. The legal basis for the processing in each case is Art. 6(1) Sentence 1(c), Art. 9(2)(g) of the General Data Protection Regulation (GDPR) in conjunction with
According to Sect. 22a(5)–(7) IfSG, the RKI is obliged to technically create and sign the requested certificate, provided that the vaccinated, recovered or tested person requests the issuance of such a certificate.
Since 1 July 2021, there has also been a basis under European law for this processing. In this respect, the legal basis is Art. 6(1) Sentence 1(c), Art. 9(2)(g) GDPR in conjunction with Art. 10(2) of Regulation (EU) 2021/953 of the European Parliament and of the Council of 14 June 2021 on a framework for the issuance, verification and acceptance of interoperable COVID-19 vaccination, test and recovery certificates (EU Digital COVID Certificate) to facilitate free movement during the COVID-19 pandemic).
The processing of data in connection with the feature for verifying COVID certificates for ticket bookings is based on your consent. The legal basis is Art. 6 (1) lit. a, Art. 9 (2) lit. a DSGVO.
The legal basis for the processing of the access data mentioned above in Section 5 b. is Sect. 3 of the German Federal Data Protection Act (BDSG) and Art. 6(1) Sentence 1(e) GDPR.
When updating certificates (see Section 4 e.), the data of the certificates that have been submitted for updating is processed on the basis of your consent. The legal basis is Art. 6(1) Sentence 1(a), Art. 9(2)(a) GDPR. Temporary storage of the hash values of the signatures of the updated and new certificates is carried out on the basis of Sect. 22(1)(c) BDSG and Art. 9(2)(i) GDPR.
The legal basis for data processing in connection with certificate revocations is Sect. 22a(8) IfSG.
The CovPass app requires access to your smartphone camera when you scan the QR code to add a certificate in the app. The app also requires an internet connection in order to download up-to-date information from the RKI’s server system (e.g. the latest key information, revocation lists). For information about other permissions the app may request, please refer to the FAQ section in the app.
The certificates will only be stored in the app on your smartphone. The certificates are not automatically deleted in your app. If you wish to delete a certificate, you can remove a certificate from the app yourself at any time or delete the app. To add the certificate again later, you will need to rescan the QR code of the printed certificate.
The booking information required for the verification of certificates for ticket bookings will be deleted after the verification.
When a certificate has been created, the data is permanently deleted at the RKI immediately after the signed certificate has been provided to the issuing entity.
In the case of updating a certificate, the data will be deleted again at the RKI after the updated certificate has been sent to your app. Only the hash values of the signatures of the updated and new certificates will be stored on the RKI’s server system for 365 days.
The revocation identifiers of revoked certificates on the revocation lists are stored on the app’s server system until the technical expiration date of the respective certificates.
The RKI has commissioned the company KDO Service GmbH (KDO) to operate and maintain the server system. KDO processes the personal data on behalf and at the instruction of the RKI (meaning it is what’s known as a processor under data protection law). Contractual safeguards are in place to ensure that the data protection requirements are met.
If, in the situations where it is required by law, you present a certificate to other persons or entities (for example, European border authorities or service providers), they will become aware of all the data contained in the certificate.
You can prevent this by showing the QR code in the app, so that it can be scanned using a verification app. Then, the data contained in the QR code will be read. Here the verification app will only show whether the certificate shown is valid, an explanation of the result, and if applicable whether another certificate needs to be scanned. In the case of a valid certificate, the name and date of birth of the certificate holder are displayed additionally in the verification app, so that the person performing the check can compare this information with an ID document (e.g. passport or ID card). In addition, it is displayed whether the certificate is a test certificate or not. In the case of test certificates, the time of sampling is then also displayed so that the person performing the check can assess whether the underlying test result is still valid.
The verification app will only process the displayed data for a short time. Once the verification is complete, the displayed data is discarded, meaning the data that has been read is not permanently stored.
During certificate verification for ticket bookings, your COVID certificates and booking information are transmitted to a verification partner used by the provider. The specific verification partner is displayed in the CovPass app before transmitting the information. To retrieve the individual booking information, the CovPass app transmits to the provider the booking identifier contained in the provider’s booking QR code.
If the RKI processes your personal data, you have the following data protection rights:
Please note that the RKI can only fulfil the rights mentioned above if data to which the asserted claims relate is processed on an ongoing basis. This would only be possible if personal data were stored after being transmitted to the RKI server. This is not generally necessary for the purposes of the app. For this reason, the aforementioned data protection rights under Art. 15, 16, 17, 18 and 21 GDPR are largely redundant. If the hash values of the signatures are temporarily stored when a certificate is updated, this does not enable the RKI to determine the identity of certificate holders (see Section 4 e.).
If you have any questions or concerns regarding data protection in connection with the CovPass app, you are welcome to send them to the RKI’s official data protection officer by post to: Robert Koch-Institut, FAO the data protection officer, Nordufer 20, 13353 Berlin, or by emailing datenschutz@rki.de.


Loading...
pan
OALAudioTrack::pan()
ALSoundSource-p::pan()
panAction
OALAudioTrack::panAction()
ALSource::panAction()
panCompleteSelector
ALChannelSource
panCompleteTarget
ALChannelSource
panTo:duration:target:selector:
OALAudioTrack::panTo:duration:target:selector:()
ALSoundSource-p::panTo:duration:target:selector:()
paused
OALAudioTrack::paused()
OALAudioTracks::paused()
OALSimpleAudio::paused()
ALChannelSource::paused()
ALSoundSource-p::paused()
pCurrentActionComplete
OALSequentialActions
pCurrentActionDuration
OALSequentialActions
pDurations
OALSequentialActions::pDurations()
OALConcurrentActions::pDurations()
peakPowerForChannel:
OALAudioTrack
pendingLoadCount
OALSimpleAudio
pitch
ALChannelSource::pitch()
ALSoundSource-p::pitch()
pitchAction
ALSource
pitchCompleteSelector
ALChannelSource
pitchCompleteTarget
ALChannelSource
pitchTo:duration:target:selector:
ALSoundSource-p
pLastComplete
OALSequentialActions
play
OALAudioTrack::play()
ALSource::play()
play:
ALSoundSource-p
play:gain:pitch:pan:loop:
ALSoundSource-p
play:loop:
ALSoundSource-p
playAtTime:
OALAudioTrack
playBg
OALSimpleAudio
playBg:
OALSimpleAudio
playBg:loop:
OALSimpleAudio
playBg:volume:pan:loop:
OALSimpleAudio
playBgWithLoop:
OALSimpleAudio
playBuffer:volume:pitch:pan:loop:
OALSimpleAudio
playEffect:
OALSimpleAudio
playEffect:loop:
OALSimpleAudio
playEffect:volume:pitch:pan:loop:
OALSimpleAudio
player
OALAudioTrack
playFile:
OALAudioTrack
playFile:loops:
OALAudioTrack
playFileAsync:loops:target:selector:
OALAudioTrack
playFileAsync:target:selector:
OALAudioTrack
playing
OALAudioTrack::playing()
ALSoundSource-p::playing()
playUrl:
OALAudioTrack
playUrl:loops:
OALAudioTrack
playUrlAsync:loops:target:selector:
OALAudioTrack
playUrlAsync:target:selector:
OALAudioTrack
pool
ALSoundSourcePool
position
OALPlaceAction::position()
OALMoveToAction::position()
ALChannelSource::position()
ALListener::position()
ALSoundSource-p::position()
preloadBg:
OALSimpleAudio
preloadBg:seekTime:
OALSimpleAudio
preloadCache
OALSimpleAudio
preloadCacheCount
OALSimpleAudio
preloadCacheEnabled
OALSimpleAudio
preloaded
OALAudioTrack
preloadEffect:
OALSimpleAudio
preloadEffect:reduceToMono:
OALSimpleAudio
preloadFile:
OALAudioTrack
preloadFile:seekTime:
OALAudioTrack
preloadFileAsync:seekTime:target:selector:
OALAudioTrack
preloadFileAsync:target:selector:
OALAudioTrack
preloadUrl:
OALAudioTrack
preloadUrl:seekTime:
OALAudioTrack
preloadUrlAsync:seekTime:target:selector:
OALAudioTrack
preloadUrlAsync:target:selector:
OALAudioTrack
prepareWithTarget:
OALAction
process
ALContext
processContext:
ALWrapper
Searching...
No Matches


See: Description
| Class | Description |
|---|---|
| GlowScheduler |
A scheduler for managing server ticks, Bukkit tasks, and other synchronization.
|
| GlowTask |
Represents a task which is executed periodically.
|
| PulseTask | |
| WorldScheduler |
Manager for world thread pool.
|
Glowstone has 4 groups of threads:
Whenever a thread wishes to call an event or perform other interactions with Bukkit API, it
calls the GlowScheduler.syncIfNeeded(
java.util.concurrent.Callable)
.
The scheduler thread synchronizes the world threads, so that each world thread begins a tick at the beginning of a scheduler pulse.
Operation order:
Copyright © 2021. All rights reserved.


Melody Maestro Kantabilon:
Here are the Echo Crystals with the wedding march.
May this music bless you someday!


feedback
368
New Feedback
shopping_cart
152
New Order
monetization_on
21.5M $
Profit
show_chart
9623
Sales
Revenue
Monthly stats
- Revenue
- $12,450
- Tax
- $2,122
- Shipment
- $1,233
- Order
- $2,422
Tasks
-
Schedule Meeting
Opportunity for new customers -
Upload files to servers
Files must be shared to all board members -
Monthly sales report
As soon as possible -
Career applicants
Review and forward career aplications -
Quarter 3 Reports
Send Q3 Reports to CEO
Chats
2Order Review
Latest order
| Id | Product | Product Name | Price | Status | Date |
|---|---|---|---|---|---|
| 1 | iPhone 7 | $ 1500 | Shipped | 5 January 2016 | |
| 2 | Samsung S7 Edger | $2100 | Processing | 7 February 2016 | |
| 3 | Macbook Pro | $ 2300 | Pending | 11 September 2016 | |
| 4 | iPad Air | $ 410 | Delivered | 9 November 2016 | |
| 5 | iMac | $ 230 | Delivered | 21 Desember 2016 |
Comments
3Amara
5 days agoI have met some of candidate applicants yesterday. I want someone from HRD start to interview them as soon as possible and give me the report to my email. Thank you very much for your work hard team. Very much appreciated.
Simon
6 days agoI just want to inform you that I have interviewed all candidates yesterday, the result is pretty good. It's gonna be difficult to decide which candidates to take.
Amara
8 days agoGreat, to have a lot of good options is the problem I dont mind to have. Thank you for your hard work Simon.
Simon
10 days agoYou are welcome Amara, have a nice day. By the way your profile picture looks good.


Susan H Burrows
Democrat
8th grade social studies teacher (American History and Civics) at Campus Middle School, Cherry Creek School District, 8/2001 - 6/2016, when I retired.
BA in psychology from Allegheny College. Teachers license from Wright State University. Continuing education classes on teaching government, economics, and American history.
80112
As social studies department chair at Campus Middle School, Cherry Creeks School District, I advocated for improved civics and history education both within my district and the state.
Colorado Democratic Party, 2018
Colorado Education Association (through 8/2016); currently a tour guide with the Visitors Services office at the Colorado State Capitol
I firmly believe in the multi-party system and that voters and candidates should have equal chances to have their opinion heard. No party, whether I am a member of it or not, should be able to control the electoral chances in a district or a state. Especially with our Congressional districts, the repercussions nationwide are too important to be determined by a small handful of powerful individuals. This is especially true to protect the input of traditionally disenfranchised populations.
As a teacher, it was my responsibility to be sure each student's voice was heard and that the louder members of the class did not drown out those less popular. This skill at defusing the dominant personalities, and encouraging all opinions to be heard, could be important if party members band together instead of considering the needs of all citizens.
I do not tend to react emotionally to non-threatening situations. I have a dedication to data and logic - and the law. I can look at the big picture as well as the relevant small details.
Female


The Life Simulator Game
How to Play
Click on the desired place you want to visit.
Click on the desired activities.
Every action you take will affect your health, happiness, hunger, or cash.
In this game, every place's access will vary on time.
Just make sure your health , happiness level is more than 20 and hunger level is less than 50.
You have a limit of 100 days to play the game.
OK
Health
Hunger
Happiness
Cash
$
Days
Time
:
Home
University
Job
Bank
Gym
Food and Grocery
:
Eat Meal
Rest/Sleep
Meet Family Members
Clean Your Room
Intelligence
:
Strength
:
Spirituality
:
Take Admission
Pay Fees
Attend Classes
Group Study
Club Meeting
Eat in Canteen
Play Games
Study In Library
Apply For Work
Work 1 Hour
Work 3+ Hours
Work 5+ Hours
Work 9+ Hours
Take Break
Attend Meeting
Apply for promotion
Balance
: $
Loan
: $
Bills
: $
Open Bank Account
Deposit Money
Withdraw Money
Take Out A Loan
Pay Loan
Pay Bills
Talk with Teller
Take Admission
Exercise 1 Hour
Exercise 2 Hours
Exercise 3 Hours
Take A Diet Plan
Talk To Trainer
Shopping
Watch Movies
Play In Gaming Zone
Eat In Food Court
Buy Food And Groceries
Pray
Serve
Charity
Dance
Drink/Eat
Meet New People
Eat Fast Food
Eat Sea Food
Eat Salad
Eat South Indian
Eat North Indian
Eat Italian Food
Eat Chinese Food
Take Massages
Manicure and Pedicure
Your Final Life Stats
Restart


Tech reviews & comparison of Hardware components, Software, Applications, smartphone, tablets, CPU, GPU - [ No-Ads & Simple UI ] | [ This website is a part of itsunknown.tk ]
->Why I developed this website?
Answer - When you search for tech products reviews | comparisons you will find websites with too many ads and a very dirty user interface but this website has no ads and a very clean UI.
Top 5 Best Mobile Phone Under 10k
When you buy a phone what did you want?
- is it that I want a phone that never hangs but every device has some problem | Every phone hangs | And even under 10k mobile are hang much more than an expensive phone? - So, this is not possible.
But it is possible that you can buy a phone that hangs very rarely.
We compared all the phone under 10k and we will find some phone that is better than other are given below -
Best Mid-Range Mobile Companies in the market.
Mid Range is the Price Range of 10K - 35K
All Company is best in their own in Mid-Range.
Click on Learn More for Read full article
Samsung Exynos 2100 Edition vs Qualcomm 888 Edition - Just for Samsung S21 Ultra
When do you compare two processors what will come to your mind?
is it specifications or benchmark
But today we will compare two mobile processor legends of the market with a live test
For Reading Full article click on Learn More.
Mi 11 Ultra Vs Samsung S21 Ultra [ Legends of Android Mobile Community. ]
Why Mi 11 Ultra? | Why Samsung s21 Ultra?
If you want to read full article click on Learn More.


I have had a few experiences with Salvia Divinorum, ranging from the subtle and relatively easy to define to the incredible and impossible to describe. Up until recently however, I had never witnessed somebody else under the influence of Salvia. When I did so earlier this week I made an important observation.
A friend had decided that the time was right to experience Salvia so I explained the importance of set and setting and asked him to lie down and relax, breathing deeply and slowly for a few minutes whilst I prepared the water pipe. Both of us were mildly stoned after vaporising some THC oil approximately an hour earlier.  I had explained earlier that Salvinorin A metabolises quite quickly in the body so that it's important to get as much into the lungs as possible and to hold it there. I had also mentioned that he would know after the first lungful whether he needed more, and he duly took a second hit as I lit the bowl again.
Then, within the space of a second all his muscles relaxed, his breathing became regular and sounded like snoring, and his eyes flickered rapidly from side to side under his eyelids. I'm betting that if an EEG (Electroencephalograph) machine were connected to his scalp his brain would have exhibited a predominant theta state, indicative of dreaming activity.
He found his experience typically hard to describe but did not say it was akin to a dream. The next time I take Salvia I will wear my Novadreamer (a device which measures and records eye movement to initiate lucid dreaming) to check whether the same effects occur, as I prefer taking Salvia on my own (although I advise anyone new to Salvia to always have a sitter present).
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.


Hello world!  See you around! Please enable JavaScript to view the comments.


Sonar
Find your perfect home
Search criteria
Price: min
max
Bedrooms: min
max
Enter your criteria and click 'Search' to see available properties
Click on the property to see the details


We will ask the finance contact to:
Please select the person responsible for finances in your organisation


Complete
http://adsecurity.org/?p=227 - Kerberos Primer
https://adsecurity.org/?p=483 - KRBTGT Account primer
https://adsecurity.org/?p=1640 - Golden tickets enhanced with SID History
https://adsecurity.org/?p=1667 - Kerb Unconstrained delegation
https://www.slideshare.net/gentilkiwi/abusing-microsoft-kerberos-sorry-you-guys-dont-get-it
https://web.archive.org/web/20150318223528/aorato.com/blog/active-directory-vulnerability-disclosure-weak-encryption-enables-attacker-change-victims-password-without-logged/
http://passing-the-hash.blogspot.com/2014/09/pac-validation-20-minute-rule-and.html


$def with (avatar, exists) $:{RENDER("common/stage_title.html", ["Edit Avatar", "Settings"])}
You may optionally select a portion of the image to use as your avatar. The final image will be resized to fit within 100×100px.
Do not upload an avatar that is not suitable for all audiences, as this content can be viewed by anyone.


set ()
Prev
Chapter 12. Session management
Next
set ()
void clear ($entry);
Removes entry $entry from the session.


--- layout: page title: "The Little Book on CoffeeScript" prev: OEBPS/ch06.html next: OEBPS/ch06s03.html book_path: books/alex-maccaw-the-little-book-on-coffeescript-_oeb/ --- {% include JB/setup %} {% raw %}
CoffeeScript tries to be a deeply pragmatic language. To be honest, it’s probably too pragmatic for its own good. The golden rule of CoffeeScript is: “It’s just JavaScript.”
We want to embrace the limitations of compiling to JavaScript by only implementing things that can be expressed in simple JS, and leaving fancier compilations to other languages. When you run a script, there is no CoffeeScript interpreter running within the browser, no core library you have to include on the page, and ideally (although we bend this rule in a few places) no special helper functions generated alongside your code.
The downside of this approach is that more invasive improvements to
JavaScript are impossible. For example, it would be nice if list[-1]
in CoffeeScript could return the last
item in the list. At first glance, it seems simple enough to implement,
and would be useful. Unfortunately, any expression may be used to index
into an array, so with negative array indices you would have to add a
special check to every list[x]
operation to ask if x
is a positive
number or a negative one. This would take CoffeeScript away from
JavaScript semantics, and more importantly, JavaScript levels of performance—the array accesses in your inner
loops would slow down considerably. For this reason, CoffeeScript doesn’t
add negative array indices to the language.
The upside of this approach is that CoffeeScript is inherently compatible with every JavaScript runtime. Because we can compile to efficient, lowest-common-denominator code, CoffeeScript runs as well as JavaScript in every browser, in Node.js, in Rhino, in Photoshop and Illustrator—in short, everywhere JavaScript can run. If you want to use CoffeeScript for a project, for a component, or even just for a single file, you don’t have to sacrifice performance or compatibility with other JavaScript libraries.


The BACCO bundle of packages is replaced by the BACCO package, which provides a vignette that illustrates the constituent packages (emulator, approximator, calibrator) in use.
| Version: | 2.0-9 |
| Depends: | emulator (≥ 1.2-13), calibrator (≥ 1.2-5), approximator (≥ 1.2-6) |
| Published: | 2013-12-12 |
| Author: | Robin K. S. Hankin |
| Maintainer: | Robin K. S. Hankin <hankin.robin at gmail.com> |
| License: | GPL-2 | GPL-3 [expanded from: GPL] |
| NeedsCompilation: | no |
| Citation: | BACCO citation info |
| In views: | Bayesian |
| CRAN checks: | BACCO results |
| Reference manual: | BACCO.pdf |
| Vignettes: |
BACCO |
| Package source: | BACCO_2.0-9.tar.gz |
| Windows binaries: | r-devel: BACCO_2.0-9.zip, r-release: BACCO_2.0-9.zip, r-oldrel: BACCO_2.0-9.zip |
| OS X binaries: | r-release: BACCO_2.0-9.tgz, r-oldrel: BACCO_2.0-9.tgz |
| Old sources: | BACCO archive |
Please use the canonical form https://CRAN.R-project.org/package=BACCO to link to this page.