SUM(3) - [ARRAY:REDUCTION] Sum the elements of an array
result = sum(array [,dim[,mask]] | [mask] )
TYPE(kind=KIND) function sum(array, dim, mask)TYPE(kind=KIND),intent(in) :: array(..) integer(kind=**),intent(in),optional :: dim logical(kind=**),intent(in),optional :: mask(..)
o a kind designated as ** may be any supported kind for the type o ARRAY may be of any numeric type - integer, real or complex. o DIM is an integer o MASK is logical and conformable with ARRAY. o The result is of the same type and kind as ARRAY. It is scalar if DIM is not present or ARRAY is a vector, else it is an array.
SUM(3) adds the elements of ARRAY.
When only ARRAY is specified all elements are summed, but groups of sums may be returned along the dimension specified by DIM and/or elements to add may be selected by a logical mask.
No method is designated for how the sum is conducted, so whether or not accumulated error is compensated for is processor-dependent.
o ARRAY : an array containing the elements to add o DIM : a value in the range from 1 to n, where n equals the rank (the number of dimensions) of ARRAY. DIM designates the dimension along which to create sums. When absent a scalar sum of the elements optionally selected by MASK is returned. o MASK : an array of the same shape as ARRAY that designates which elements to add. If absent all elements are used in the sum(s).
If DIM is absent, a scalar with the sum of all selected elements in ARRAY is returned. Otherwise, an array of rank n-1, where n equals the rank of ARRAY, and a shape similar to that of ARRAY with dimension DIM dropped is returned. Since a vector has a rank of one, the result is a scalar (if n==1, n-1 is zero; and a rank of zero means a scalar).
Sample program:
program demo_sum implicit none integer :: vector(5) , matrix(3,4), box(5,6,7)Results:vector = [ 1, 2, -3, 4, 5 ]
matrix(1,:)=[ -1, 2, -3, 4 ] matrix(2,:)=[ 10, -20, 30, -40 ] matrix(3,:)=[ 100, 200, -300, 400 ]
box=11
! basics print *, sum all elements:,sum(vector) print *, real :,sum([11.0,-5.0,20.0]) print *, complex :,sum([(1.1,-3.3),(4.0,5.0),(8.0,-6.0)]) ! with MASK option print *, sum odd elements:,sum(vector, mask=mod(vector, 2)==1) print *, sum positive values:, sum(vector, mask=vector>0)
call printi(the input array, matrix ) call printi(sum of all elements in matrix, sum(matrix) ) call printi(sum of positive elements, sum(matrix,matrix>=0) ) ! along dimensions call printi(sum along rows, sum(matrix,dim=1) ) call printi(sum along columns, sum(matrix,dim=2) ) call printi(sum of a vector is always a scalar, sum(vector,dim=1) ) call printi(sum of a volume by row, sum(box,dim=1) ) call printi(sum of a volume by column, sum(box,dim=2) ) call printi(sum of a volume by depth, sum(box,dim=3) )
contains ! CONVENIENCE ROUTINE; NOT DIRECTLY CONNECTED TO SPREAD(3) subroutine printi(title,a) use, intrinsic :: iso_fortran_env, only : stderr=>ERROR_UNIT,& & stdin=>INPUT_UNIT, stdout=>OUTPUT_UNIT implicit none
!@(#) print small 2d integer scalar, vector, matrix in row-column format
character(len=*),intent(in) :: title integer,intent(in) :: a(..)
character(len=*),parameter :: all=(" ",*(g0,1x)) character(len=20) :: row integer,allocatable :: b(:,:) integer :: i write(*,all,advance=no)trim(title) ! copy everything to a matrix to keep code simple select rank(a) rank (0); write(*,(a)) (a scalar); b=reshape([a],[1,1]) rank (1); write(*,(a)) (a vector); b=reshape(a,[size(a),1]) rank (2); write(*,(a)) (a matrix); b=a rank default; stop *printi* unexpected rank end select ! find how many characters to use for integers write(row,(i0))ceiling(log10(max(1.0,real(maxval(abs(b))))))+2 ! use this format to write a row row=(" > [",*(i//trim(row)//:,",")) do i=1,size(b,dim=1) write(*,fmt=row,advance=no)b(i,:) write(*,(" ]")) enddo write(*,all) >shape=,shape(a),,rank=,rank(a),,size=,size(a) write(*,*) end subroutine printi end program demo_sum
sum all elements: 9 real : 26.00000 complex : (13.10000,-4.300000) sum odd elements: 6 sum positive values: 12 the input array (a matrix) > [ -1, 2, -3, 4 ] > [ 10, -20, 30, -40 ] > [ 100, 200, -300, 400 ] >shape= 3 4 ,rank= 2 ,size= 12sum of all elements in matrix (a scalar) > [ 382 ] >shape= ,rank= 0 ,size= 1
sum of positive elements (a scalar) > [ 746 ] >shape= ,rank= 0 ,size= 1
sum along rows (a vector) > [ 109 ] > [ 182 ] > [ -273 ] > [ 364 ] >shape= 4 ,rank= 1 ,size= 4
sum along columns (a vector) > [ 2 ] > [ -20 ] > [ 400 ] >shape= 3 ,rank= 1 ,size= 3
sum of a vector is always a scalar (a scalar) > [ 9 ] >shape= ,rank= 0 ,size= 1
sum of a volume by row (a matrix) > [ 55, 55, 55, 55, 55, 55, 55 ] > [ 55, 55, 55, 55, 55, 55, 55 ] > [ 55, 55, 55, 55, 55, 55, 55 ] > [ 55, 55, 55, 55, 55, 55, 55 ] > [ 55, 55, 55, 55, 55, 55, 55 ] > [ 55, 55, 55, 55, 55, 55, 55 ] >shape= 6 7 ,rank= 2 ,size= 42
sum of a volume by column (a matrix) > [ 66, 66, 66, 66, 66, 66, 66 ] > [ 66, 66, 66, 66, 66, 66, 66 ] > [ 66, 66, 66, 66, 66, 66, 66 ] > [ 66, 66, 66, 66, 66, 66, 66 ] > [ 66, 66, 66, 66, 66, 66, 66 ] >shape= 5 7 ,rank= 2 ,size= 35
sum of a volume by depth (a matrix) > [ 77, 77, 77, 77, 77, 77 ] > [ 77, 77, 77, 77, 77, 77 ] > [ 77, 77, 77, 77, 77, 77 ] > [ 77, 77, 77, 77, 77, 77 ] > [ 77, 77, 77, 77, 77, 77 ] >shape= 5 6 ,rank= 2 ,size= 30
Fortran 95
fortran-lang intrinsic descriptions (license: MIT) @urbanjost
o ALL(3) - Determines if all the values are true o ANY(3) - Determines if any of the values in the logical array are true. o COUNT(3) - Count true values in an array o MAXVAL(3) - Determines the maximum value in an array o MINVAL(3) - Minimum value of an array o PRODUCT(3) - Product of array elements o MERGE(3) - Merge variables
| Nemo Release 3.1 | sum (3) | July 22, 2023 |


About
GitHub
2020
Narrow Victory for Biden Projected in 2020 US Presidential Election.
2020-11-02
Examining Canadians' Feelings of Life in the Context of Children, Age and Income
2020-10-13
Polling Survey: The Key of Winning Election
2020-10-02
COVID-19 on Diferent Aspects from Toronto Cases
2020-09-26


About this site
When connecting to a secure site, your browser automatically initiates a handshake with the server. The sequence diagram below shows you the TLS handshake that took place when your browser connected to this web server. We demonstrate it using tracing of our OCaml-TLS implementation. We chose the protocol version and ciphersuite at random for this demonstration server, we do not use the best one available.
The dotted lines represent messages which are unencrypted, while solid lines are encrypted messages. On the left you can see excerpts of the RFC 5246 describing the message you clicked on. On the right you can see further details about the message. Subsequent messages of the same type are condensed into a single one and marked with a trailing '*'.
The 'renegotiate' button below lets our server send a Hello Request message to the client, and after 500 milliseconds the JavaScript fetches a new trace. With some luck both requests use the same connection, and you will see another handshake in the sequence diagram.
For research purposes we retain the traces. These are solely on the TLS layer and no IP addresses nor port numbers are captured whatsoever. You can also view the source code of this server.
Please report any issues to GitHub issue tracker.
Showtime
Click inside the diagram!
7.1. Change Cipher Spec Protocol The change cipher spec protocol exists to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1. struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec; The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys. Reception of this message causes the receiver to instruct the record layer to immediately copy the read pending state into the read current state. Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state. (See Section 6.1.) The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent. Note: If a rehandshake occurs while data is flowing on a connection, the communicating parties may continue to send data using the old CipherSpec. However, once the ChangeCipherSpec has been sent, the new CipherSpec MUST be used. The first side to send the ChangeCipherSpec does not know that the other side has finished computing the new keying material (e.g., if it has to perform a time-consuming public key operation). Thus, a small window of time, during which the recipient must buffer the data, MAY exist. In practice, with modern machines this interval is likely to be fairly short.
<IP_ADDRESS>. Hello Request When this message will be sent: The HelloRequest message MAY be sent by the server at any time. Meaning of this message: HelloRequest is a simple notification that the client should begin the negotiation process anew. In response, the client should send a ClientHello message when convenient. This message is not intended to establish which side is the client or server but merely to initiate a new negotiation. Servers SHOULD NOT send a HelloRequest immediately upon the client's initial connection. It is the client's job to send a ClientHello at that time. This message will be ignored by the client if the client is currently negotiating a session. This message MAY be ignored by the client if it does not wish to renegotiate a session, or the client may, if it wishes, respond with a no_renegotiation alert. Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation will begin before no more than a few records are received from the client. If the server sends a HelloRequest but does not receive a ClientHello in response, it may close the connection with a fatal alert. After sending a HelloRequest, servers SHOULD NOT repeat the request until the subsequent handshake negotiation is complete. Structure of this message: struct { } HelloRequest; This message MUST NOT be included in the message hashes that are maintained throughout the handshake and used in the Finished messages and the certificate verify message.
<IP_ADDRESS>. Client Hello When this message will be sent: When a client first connects to a server, it is required to send the ClientHello as its first message. The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection. Structure of this message: The ClientHello message includes a random structure, which is used later in the protocol. struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; gmt_unix_time The current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, UTC, ignoring leap seconds) according to the sender's internal clock. Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements. Note that, for historical reasons, the data element is named using GMT, the predecessor of the current worldwide time base, UTC. random_bytes 28 bytes generated by a secure random number generator. The ClientHello message includes a variable-length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier MAY be from an earlier connection, this connection, or from another currently active connection. The second option is useful if the client only wishes to update the random structures and derived values of a connection, and the third option makes it possible to establish several independent secure connections without repeating the full handshake protocol. These independent connections may occur sequentially or simultaneously; a SessionID becomes valid when the handshake negotiating it completes with the exchange of Finished messages and persists until it is removed due to aging or because a fatal error was encountered on a connection associated with the session. The actual contents of the SessionID are defined by the server. opaque SessionID<0..32>; Warning: Because the SessionID is transmitted without encryption or immediate MAC protection, servers MUST NOT place confidential information in session identifiers or let the contents of fake session identifiers cause any breach of security. (Note that the content of the handshake as a whole, including the SessionID, is protected by the Finished messages exchanged at the end of the handshake.) The cipher suite list, passed from the client to the server in the ClientHello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each cipher suite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length), a MAC algorithm, and a PRF. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection. If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as usual. uint8 CipherSuite[2]; /* Cryptographic suite selector */ The ClientHello includes a list of compression algorithms supported by the client, ordered according to the client's preference. enum { null(0), (255) } CompressionMethod; struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello; TLS allows extensions to follow the compression_methods field in an extensions block. The presence of extensions can be detected by determining whether there are bytes following the compression_methods at the end of the ClientHello. Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined. client_version The version of the TLS protocol by which the client wishes to communicate during this session. This SHOULD be the latest (highest valued) version supported by the client. For this version of the specification, the version will be 3.3 (see Appendix E for details about backward compatibility). random A client-generated random structure. session_id The ID of a session the client wishes to use for this connection. This field is empty if no session_id is available, or if the client wishes to generate new security parameters. cipher_suites This is a list of the cryptographic options supported by the client, with the client's first preference first. If the session_id field is not empty (implying a session resumption request), this vector MUST include at least the cipher_suite from that session. Values are defined in Appendix A.5. compression_methods This is a list of the compression methods supported by the client, sorted by client preference. If the session_id field is not empty (implying a session resumption request), it MUST include the compression_method from that session. This vector MUST contain, and all implementations MUST support, CompressionMethod.null. Thus, a client and server will always be able to agree on a compression method. extensions Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section <IP_ADDRESS>. In the event that a client requests additional functionality using extensions, and this functionality is not supplied by the server, the client MAY abort the handshake. A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert. After sending the ClientHello message, the client waits for a ServerHello message. Any handshake message returned by the server, except for a HelloRequest, is treated as a fatal error.
<IP_ADDRESS>. Server Hello When this message will be sent: The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert. Structure of this message: struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello; The presence of extensions can be detected by determining whether there are bytes following the compression_method field at the end of the ServerHello. server_version This field will contain the lower of that suggested by the client in the client hello and the highest supported by the server. For this version of the specification, the version is 3.3. (See Appendix E for details about backward compatibility.) random This structure is generated by the server and MUST be independently generated from the ClientHello.random. session_id This is the identity of the session corresponding to this connection. If the ClientHello.session_id was non-empty, the server will look in its session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server will respond with the same value as was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the Finished messages. Otherwise, this field will contain a different value identifying the new session. The server may return an empty session_id to indicate that the session will not be cached and therefore cannot be resumed. If a session is resumed, it must be resumed using the same cipher suite it was originally negotiated with. Note that there is no requirement that the server resume any session even if it had formerly provided a session_id. Clients MUST be prepared to do a full negotiation -- including negotiating new cipher suites -- during any handshake. cipher_suite The single cipher suite selected by the server from the list in ClientHello.cipher_suites. For resumed sessions, this field is the value from the state of the session being resumed. compression_method The single compression algorithm selected by the server from the list in ClientHello.compression_methods. For resumed sessions, this field is the value from the resumed session state. extensions A list of extensions. Note that only extensions offered by the client can appear in the server's list.
7.4.2. Server Certificate When this message will be sent: The server MUST send a Certificate message whenever the agreed- upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the ServerHello message. Meaning of this message: This message conveys the server's certificate chain to the client. The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions. Structure of this message: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The same message type and structure will be used for the client's response to a certificate request message. Note that a client MAY send no certificates if it does not have an appropriate certificate to send in response to the server's authentication request. Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task of parsing the list more difficult. The following rules apply to the certificates sent by the server: - The certificate type MUST be X.509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]). - The end entity certificate's public key (and associated restrictions) MUST be compatible with the selected key exchange algorithm. Key Exchange Alg. Certificate Key Type RSA RSA public key; the certificate MUST allow the RSA_PSK key to be used for encryption (the keyEncipherment bit MUST be set if the key usage extension is present). Note: RSA_PSK is defined in [TLSPSK]. DHE_RSA RSA public key; the certificate MUST allow the ECDHE_RSA key to be used for signing (the digitalSignature bit MUST be set if the key usage extension is present) with the signature scheme and hash algorithm that will be employed in the server key exchange message. Note: ECDHE_RSA is defined in [TLSECC]. DHE_DSS DSA public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the server key exchange message. DH_DSS Diffie-Hellman public key; the keyAgreement bit DH_RSA MUST be set if the key usage extension is present. ECDH_ECDSA ECDH-capable public key; the public key MUST ECDH_RSA use a curve and point format supported by the client, as described in [TLSECC]. ECDHE_ECDSA ECDSA-capable public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the server key exchange message. The public key MUST use a curve and point format supported by the client, as described in [TLSECC]. - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are used to guide certificate selection. If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical. If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such as transport layer endpoint, local configuration and preferences, etc.). If the server has a single certificate, it SHOULD attempt to validate that it meets these criteria. Note that there are certificates that use algorithms and/or algorithm combinations that cannot be currently used with TLS. For example, a certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in SubjectPublicKeyInfo) cannot be used because TLS defines no corresponding signature algorithm. As cipher suites that specify new key exchange methods are specified for the TLS protocol, they will imply the certificate format and the required encoded keying information.
7.4.3. Server Key Exchange Message When this message will be sent: This message will be sent immediately after the server Certificate message (or the ServerHello message, if this is an anonymous negotiation). The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods: DHE_DSS DHE_RSA DH_anon It is not legal to send the ServerKeyExchange message for the following key exchange methods: RSA DH_DSS DH_RSA Other key exchange algorithms, such as those defined in [TLSECC], MUST specify whether the ServerKeyExchange message is sent or not; and if the message is sent, its contents. Meaning of this message: This message conveys cryptographic information to allow the client to communicate the premaster secret: a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret) or a public key for some other algorithm. Structure of this message: enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa /* may be extended, e.g., for ECDH -- see [TLSECC] */ } KeyExchangeAlgorithm; struct { opaque dh_p<1..2^16-1>; opaque dh_g<1..2^16-1>; opaque dh_Ys<1..2^16-1>; } ServerDHParams; /* Ephemeral DH parameters */ dh_p The prime modulus used for the Diffie-Hellman operation. dh_g The generator used for the Diffie-Hellman operation. dh_Ys The server's Diffie-Hellman public value (g^X mod p). struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ }; } ServerKeyExchange; params The server's key exchange parameters. signed_params For non-anonymous key exchanges, a signature over the server's key exchange parameters. If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. Note that there is a possibility for inconsistencies here. For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them. This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design. In addition, the hash and signature algorithms MUST be compatible with the key in the server's end-entity certificate. RSA keys MAY be used with any permitted hash algorithm, subject to restrictions in the certificate, if any. Because DSA signatures do not contain any secure indication of hash algorithm, there is a risk of hash substitution if multiple hashes may be used with any key. Currently, DSA [DSS] may only be used with SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use of other digest algorithms with DSA, as well as guidance as to which digest algorithms should be used with each key size. In addition, future revisions of [PKIX] may specify mechanisms for certificates to indicate which digest algorithms are to be used with DSA. As additional cipher suites are defined for TLS that include new key exchange algorithms, the server key exchange message will be sent if and only if the certificate type associated with the key exchange algorithm does not provide enough information for the client to exchange a premaster secret.
7.4.5. Server Hello Done When this message will be sent: The ServerHelloDone message is sent by the server to indicate the end of the ServerHello and associated messages. After sending this message, the server will wait for a client response. Meaning of this message: This message means that the server is done sending messages to support the key exchange, and the client can proceed with its phase of the key exchange. Upon receipt of the ServerHelloDone message, the client SHOULD verify that the server provided a valid certificate, if required, and check that the server hello parameters are acceptable. Structure of this message: struct { } ServerHelloDone;
7.4.7. Client Key Exchange Message When this message will be sent: This message is always sent by the client. It MUST immediately follow the client certificate message, if it is sent. Otherwise, it MUST be the first message sent by the client after it receives the ServerHelloDone message. Meaning of this message: With this message, the premaster secret is set, either by direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret. When the client is using an ephemeral Diffie-Hellman exponent, then this message contains the client's Diffie-Hellman public value. If the client is sending a certificate containing a static DH exponent (i.e., it is doing fixed_dh client authentication), then this message MUST be sent but MUST be empty. Structure of this message: The choice of messages depends on which key exchange method has been selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition. struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case dhe_dss: case dhe_rsa: case dh_dss: case dh_rsa: case dh_anon: ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange;
7.4.9. Finished When this message will be sent: A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. It is essential that a change cipher spec message be received between the other handshake messages and the Finished message. Meaning of this message: The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection. Structure of this message: struct { opaque verify_data[verify_data_length]; } Finished; verify_data PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1]; finished_label For Finished messages sent by the client, the string "client finished". For Finished messages sent by the server, the string "server finished". Hash denotes a Hash of the handshake messages. For the PRF defined in Section 5, the Hash MUST be the Hash used as the basis for the PRF. Any cipher suite which defines a different PRF MUST also define the Hash to use in the Finished computation. In previous versions of TLS, the verify_data was always 12 octets long. In the current version of TLS, it depends on the cipher suite. Any cipher suite which does not explicitly specify verify_data_length has a verify_data_length equal to 12. This includes all existing cipher suites. Note that this representation has the same encoding as with previous versions. Future cipher suites MAY specify other lengths but such length MUST be at least 12 bytes. handshake_messages All of the data from all messages in this handshake (not including any HelloRequest messages) up to, but not including, this message. This is only data visible at the handshake layer and does not include record layer headers. This is the concatenation of all the Handshake structures as defined in Section 7.4, exchanged thus far. It is a fatal error if a Finished message is not preceded by a ChangeCipherSpec message at the appropriate point in the handshake. The value handshake_messages includes all handshake messages starting at ClientHello up to, but not including, this Finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the CertificateVerify message (if sent). Also, the handshake_messages for the Finished message sent by the client will be different from that for the Finished message sent by the server, because the one that is sent second will include the prior one. Note: ChangeCipherSpec messages, alerts, and any other record types are not handshake messages and are not included in the hash computations. Also, HelloRequest messages are omitted from handshake hashes.
10. Application Data Protocol Application data messages are carried by the record layer and are fragmented, compressed, and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.
- Intentionally left blank


The Library
Home
Search
The Library
Book Name
Author
Type
fiction
programming
cooking
Add Book
Your Books
Name
Author
Type


Huawei to Launch Huawei Y9s and Band 4e in the Kenyan Market
They will be launched tomorrow
by Kiruti ItimuHuawei has invested quite heavily in the Kenyan market and we have seen them release phones at different price points. The key market in Kenya is the one below the Kshs 25,000 price tag and Huawei has a number of competitive phones below this price tag.
The Chinese giant is set to launch two new devices tomorrow: The Y9s and their activity tracker, the Band 4e.
Huawei Y9s
The Huawei Y9s is the latest smartphone from Huawei that was launched earlier this month in other markets.
It is a modest update on the Y9 Prime 2019 that they launched in Kenya some time back and they share a lot of features.
The Y9s has a 6.59 inch FHD+ (2340 x 1080) display that is similar to the one on the Y9 Prime 2019. They call it the Full View display and it has an impressive 91% screen to body ratio.
The back features curved glass with gradient colours that change with the light. You’ll also see the triple camera system and the lack of a fingerprint sensor near it. This is because Huawei decided to install the fingerprint sensor on the side.
Speaking of the cameras, the Y9S has a slightly different camera system compared to the Y9 Prime 2019. The selfie camera is on a motorized platform and it is a 16MP unit with an f/2.2 lens.
The primary camera system comprises of a 48MP main sensor with an f/1.8 lens, an 8MP ultra wide angle camera with a f/2.4 lens and a 2MP depth sensor. This is the same system as the P30 lite New Edition that they released recently.
The Huawei Y9s still features their own custom Kirin 710F processor which is a great and relatively powerful processor for this price range. It now has 6GB of RAM and 128GB of internal storage which you can expand further with a memory card slot.
Huawei phones have great battery life and the Y9s seems like it will continue this streak. It has a 4000mAh battery which will give you ample battery life. The Y9s features a USB-C port for the curious users out there.
Huawei Band 4e
The Huawei band 4e is one of the company’s suite of wearables that replaces the Band 3e. The Band 4e has some tricks up its sleeves unlike the 3e.
First, the 4e has a ‘Dual wearing’ mode. You can either wear the tracker on your wrist or better still, you can attach it on your shoe. Wearing it on your wrist will help you track activity such as sleep or activity tracking. On your shoe, it can help you collect “precise basketball or running performance statistics” according to Huawei. That is pretty cool.
Huawei promises that the 4e will provide you with upto 2 weeks of battery life with regular use and 21 days under standby mode. It is water resistant upto 50 metres which means you can use it during sweaty workouts or when you’re swimming.
The Band 4e tracks a variety of activities as well as inform you about various things that you engage in your life. This include:
- Steps
- Distance
- Calories
- Achievement reminders
- Moderate to high intensity workouts
- Single workout distance
- Single workout time
- Activity reminders
- Stand reminders
- Sleep time
- Alarms
- Messenger reminder
- Incoming call notifications
- Find phone
This band will pair well with the Huawei Health app that is sometimes pre-installed on Huawei phones.


We are here
We are team of FlowAway, we love to Design unique and clean responsive WordPress and HTML themes. We set new standarts in user experience.
Get in touch
Informations
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Praesent vitae arcu sed velit pharetra tempor a.
234/c Lucker Maker Street San Francisco, CA 92134 USA
(123) 768-66744
(123) 768-66745
[email protected]
themeforest.net


Interested in hearing more about Women In Coding or want to get involved? Fill out the form below to send us a message and we will try to get back to you within 24 hours!


Add FoldersClick on the plus button to add a project (if you don't see it, click on the file icon above search on the left)
Keyboard Shortcuts Search for Ace Editor or go to this address: https://goo.gl/Y5xXi9


Reports @GuardedBy annotations annotations where the guarding field
is not final. Guarding on a non-final field may result in unexpected race conditions, as locks will
be held on the value of the field (which may change), rather than the field itself.
Supported @GuardedBy annotations are:
- net.jcip.annotations.GuardedBy
- javax.annotation.concurrent.GuardedBy
- org.apache.http.annotation.GuardedBy
- com.android.annotations.concurrency.GuardedBy
- androidx.annotation.GuardedBy
- com.google.errorprone.annotations.concurrent.GuardedBy


This one of the few places on the south coast of Java offering good shelter from the monsoons. Unfortunately, it is rather industrial and so does not provide the most attractive of surroundings.
Position 007° 43.54' S, 108° 59.79' E
The approach channel is well marked and well lit but keep in the channel as there are shoals one each side.
If just a brief stop is required, there is an anchorage just behind theTanjung Karangbolong Peninsula.
There are several anchorages off the town and up the rivers. Be sure to keep clear of the channels.
There is a dinghy dock off the town.
Last updated February 2015.


CORS Bypasser
A simple API to bypass CORS.
How to use
Simply append https://cors-bypasser.glitch.me/bypass/
to your HTTP requests.
Example usage
Replace https://google.com
with https://cors-bypasser.glitch.me/bypass/https://google.com
to bypass Access to XMLHttpRequest at 'https://google.com' from origin 'YOUR ORIGIN' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.


Time to Shine!
Our mission is simple: We are here to Brighten your life. We empower you to be your best self. Let us be a part of your journey.
Scheduled Classes
We offer scheduled fitness classes. Our certified trainers are waiting to BrightenUp your day. We offer classes 7 days of the week in the morning and in the evening. Click here to see our current class schedule.
Event Offerings
Do you have an event that you think we can help with? We would love to hear more about what you have in mind. We have provided fitness courses during conferences, training seminars and more. Reach out and let us BrightenUp your event!
Business Sessions
We would love to learn more about your business and share what benefits we can provide through a partnership. We want to work with business owners to craft sessions to meet their needs. The only limit is your imagination.


Tom Hanks reads out Nottingham woman's tweet about her cat
'You named your cat Chips? Was there another one named Poker?'
by David WhitfieldWhen you tweet about something that's happened in in your everyday life, you probably hope it will get a few likes and maybe the occasional retweet.
What you don't expect is for Tom Hanks to read it out in a video which is seen by more than eight million people.
But that's exactly what has happened to a woman from Nottingham who posted a message about her cat six months ago.
Nottinghamshire Live reported back in May how Karen Miele had tweeted about a lady named Jean, who had taken a photo of Karen's cat, and then posted it through her letterbox for her.
The note read: "For you. Your lovely cat I always look for him. Jean."
Karen's tweet about her cat Chips and Jean went viral. And now Tom Hanks has read out the tweet in a collection of some of the nicest and best moments that can be found on Twitter around the world.
The star of Forrest Gump, Philadelphia, Cast Away and many more posted the video on the Twitter Movies account just ahead of Thanksgiving Day on Thursday, November 28.
He said of Karen's tweet: "Oh, my lord. Who doesn't love cats?"
He then added: "Chips, huh? You named your cat Chips? Was there another one named Poker?"
Karen is originally from St Austell in Cornwall but now works as an artist in Nottingham.
She tweeted her own response to the actor's message, writing: "No big deal, just @tomhanks reading out my tweets. “You called your cat Chips?!"
Karen's original tweet has been liked more than 235,000 times since it was posted in May.


Microsoft Cognitive Services APIs Documentation > API Reference POST Analyze Image POST Describe Image POST Get Thumbnail GET List Domain Specific Models POST OCR POST Recognize Domain Specific Content POST Tag Image Computer Vision API - v1.0 The Computer Vision API provides state-of-the-art algorithms to process images and return information. For example, it can be used to determine if an image contains mature content, or it can be used to find all the faces in an image. It also has other features like estimating dominant and accent colors, categorizing the content of images, and describing an image with complete English sentences. Additionally, it can also intelligently generate images thumbnails for displaying large images effectively. Analyze Image This operation extracts a rich set of visual features based on the image content. Two input methods are supported -- (1) Uploading an image or (2) specifying an image URL. Within your request, there is an optional parameter to allow you to choose which features to return. By default, image categories are returned in the response. A successful response will be returned in JSON. If the request failed, the response will contain an error code and a message to help understand what went wrong. Http Method POST Open API Testing Console Request URL https://api.projectoxford.ai/vision/v1.0/analyze[?visualFeatures][&details] Request parameters visualFeatures (optional) string A string indicating what visual feature types to return. Multiple values should be comma-separated. Valid visual feature types include: •Categories - categorizes image content according to a taxonomy defined in documentation. •Tags - tags the image with a detailed list of words related to the image content. •Description - describes the image content with a complete English sentence. •Faces - detects if faces are present. If present, generate coordinates, gender and age. •ImageType - detects if image is clipart or a line drawing. • Color - determines the accent color, dominant color, and whether an image is black&white. •Adult - detects if the image is pornographic in nature (depicts nudity or a sex act). Sexually suggestive content is also detected. details (optional) string A string indicating which domain-specific details to return. Multiple values should be comma-separated. Valid visual feature types include: •Celebrities - identifies celebrities if detected in the image. Request headers Content-Type (optional) string Media type of the body sent to the API. Ocp-Apim-Subscription-Key string Subscription key which provides access to this API. Found in your subscriptions. Request body Input passed within the POST body. Supported input methods: raw image binary or image URL. Input requirements: •Supported image formats: JPEG, PNG, GIF, BMP. •Image file size must be less than 4MB. •Image dimensions must be at least 50 x 50. application/json application/octet-stream multipart/form-data {"url":"http://example.com/images/test.jpg"} Response 200 The response include the extracted features in JSON format. Here is the definitions for enumeration types ClipartType •Non-clipart = 0, • ambiguous = 1, • normal-clipart = 2, • good-clipart = 3. LineDrawingType •Non-LineDrawing = 0, •LineDrawing = 1. application/json { "categories": [ { "name": "abstract_", "score": 0.00390625 }, { "name": "people_", "score": 0.83984375, "detail": { "celebrities": [ { "name": "Satya Nadella", "faceRectangle": { "left": 597, "top": 162, "width": 248, "height": 248 }, "confidence": 0.999028444 } ] } } ], "adult": { "isAdultContent": false, "isRacyContent": false, "adultScore": 0.0934349000453949, "racyScore": 0.068613491952419281 }, "tags": [ { "name": "person", "confidence": 0.98979085683822632 }, { "name": "man", "confidence": 0.94493889808654785 }, { "name": "outdoor", "confidence": 0.938492476940155 }, { "name": "window", "confidence": 0.89513939619064331 } ], "description": { "tags": [ "person", "man", "outdoor", "window", "glasses" ], "captions": [ { "text": "Satya Nadella sitting on a bench", "confidence": 0.48293603002174407 } ] }, "requestId": "0dbec5ad-a3d3-4f7e-96b4-dfd57efe967d", "metadata": { "width": 1500, "height": 1000, "format": "Jpeg" }, "faces": [ { "age": 44, "gender": "Male", "faceRectangle": { "left": 593, "top": 160, "width": 250, "height": 250 } } ], "color": { "dominantColorForeground": "Brown", "dominantColorBackground": "Brown", "dominantColors": [ "Brown", "Black" ], "accentColor": "873B59", "isBWImg": false }, "imageType": { "clipArtType": 0, "lineDrawingType": 0 } } Response 400 Possible Errors: •InvalidImageUrl Image URL is badly formatted or not accessible. •InvalidImageFormat Input data is not a valid image. •InvalidImageSize Input image is too large. •NotSupportedVisualFeature Specified feature type is not valid. •NotSupportedImage Unsupported image, e.g. child pornography. •InvalidDetails Unsupported domain-specific model. application/json { "code":"InvalidImageFormat", "requestId":"B8D802CF-DD8F-4E61-B15C-9E6C5844CCBC", "message":"The input file is not in a valid image format that the service can support. " } Response 415 Unsupported media type error. Content-Type is not in the allowed types: •For an image URL: Content-Type should be application/json •For a binary image data: Content-Type should be application/octet-stream or multipart/form-data application/json { "code":"BadArgument", "message":"Invalid Media Type" } Response 500 Possible Errors: •FailedToProcess Failed to process the image. •Timeout Image processing time out. •InternalServerError Internal server error. application/json { "code":"FailedToProcess", "requestId":"B8D802CF-DD8F-4E61-B15C-9E6C5844CCBC", "message":"Could not extract image features" } Code samples Curl C# Java JavaScript ObjC PHP Python Ruby


This structure contains configuration parameters for each sec_proxy thread. More...
#include <csl_sec_proxy.h>
Data Fields | |
| uint32_t | outboundMaxMsgCnt |
| uint32_t | outboundDstThread |
| uint32_t | queueNum |
| uint32_t | threshCnt |
| uint32_t | errEvtNum |
| uint32_t | threshEvtNum |
This structure contains configuration parameters for each sec_proxy thread.
| uint32_t CSL_SecProxyThreadCfg::errEvtNum |
Threshold count that causes proxy thread events
| uint32_t CSL_SecProxyThreadCfg::outboundDstThread |
Max message count allowed for an outbound proxy thread (valid only when dir==0)
| uint32_t CSL_SecProxyThreadCfg::outboundMaxMsgCnt |
Direction for the proxy thread: 0 = outbound, write only, 1 = inbound, read only
| uint32_t CSL_SecProxyThreadCfg::queueNum |
The proxy thread that is the destination of messages from this outbound proxy thread (valid only when dir==0)
| uint32_t CSL_SecProxyThreadCfg::threshCnt |
Queue number in the target to use for the proxy thread. Note that this value is relative to the queue # inferred by the sec_proxy TARGET address MMR.
| uint32_t CSL_SecProxyThreadCfg::threshEvtNum |
Event number for an error from the proxy thread


--- layout: page title: About Us description: This is who we are. background: '/img/bg-about.jpg' ---
We are a group of students from 2018-2019 UBC Master of Data Science (MDS) program. The program involves capstone projects during its last two months, when students work in teams with an external partner and a UBC mentor to address a question facing the partner using data science.
RStudio is interested in developing a new tool for Git users that improves and consolidates common Git workflows. Our partner, Dr. Greg Wilson from RStudio, suggested that to understand what should be included in the alternative tool, data analysis should be performed first on what is currently being done by Git users. This is where our project comes in.
Our project aims to identify common Git workflows, with the end goal of using our understanding of these workflows to provide recommendations for features that should or should not be included in an easy-to-use Git alternative.
Dr. Tiffany Timbers is our mentor for this project, who also teaches, develops curriculum and coordinates the MDS program. She has been providing constructive feedback and directional advice throughout our project.


This is a comma separated list (optional whitespace after commas) of email addresses
that should receive emails for this trigger. May contain references to build parameters.
To CC or BCC someone instead of putting them in the To list, add
cc: or bcc: before the email address
(e.g<EMAIL_ADDRESS>bcc:bob@example.com).


{lang qqconnect:connect_spacecp_qzone_subject}:
{lang qqconnect:connect_spacecp_qzone_reason}:
{lang qqconnect:connect_spacecp_qzone_picture}:
{lang qqconnect:connect_spacecp_qzone_to_friend}
{lang qqconnect:connect_spacecp_weibo_input} {lang qqconnect:connect_spacecp_weibo_reason}:
{lang qqconnect:connect_spacecp_weibo_share}
{lang qqconnect:connect_config_bindinfo}
{lang qqconnect:connect_config_unbind_desc1}
{lang qqconnect:connect_config_unbind_desc2}
{lang qqconnect:connect_config_unbind_desc3}
{lang qqconnect:connect_config_bind}


{% extends "base.html" %} {% block content %}
1) How to become a Publisher Member
2) Best practice guidelines for Open Access publishers
3) Applying for your journal to be in DOAJ
4) Uploading metadata to DOAJ
5) Failed XML uploads
6) How do I correct an error in article metadata?
7) FAQS for publishers
Support DOAJ and make a financial contribution
DOAJ relies entirely on voluntary donations from the community. We urge you to become a
Publisher Member, showing your support for DOAJ and for open access in general.
Publisher members may carry the DOAJ logo on their site to show their support.
Becoming a Publisher Member does not guarantee that your journals will be included in the DOAJ.
One URL for each journal, one PDF for each article
When a journal gets indexed it will have its own record in the directory.
To make our service comprehensible and user-friendly, the link from the directory must go to the URL for the specific journal and not to a collection of journals.
Please note that all necessary information (by 'necessary information', we are referring to the journal's aims and scope, the clear presence of the editorial board, the author guidelines, the description of the quality control system and the Open Access statement) about the specific journal should be available at its own URL to make it easier for users to interpret the information correctly.
We strongly recommend that your content is available article by article, one PDF for each article, and not one PDF per issue. This has multiple advantages, such as direct linking to articles, promotes findability, easier to navigate, read and download. When article metadata is uploaded to DOAJ, it should have a unique URL.
We strongly recommend that your content is preserved in a digital preservation or archiving service, sometimes referred to as Long Term Preservation and Archiving (LTPA). You can find a list some of these services here.
Please also read OASPA's Code of Conduct for more information.
Knowledge organization, commercials and ads
Please pay attention to the fact that having a clear structure when organizing your material makes it easier for users to navigate between articles.
Preferably articles will be gathered in volumes, marked with the year the articles were published, making it easier for scholars to cite them (and readers to find them).
If publishing different types of articles (for example original articles, review articles, case studies, essays or book reviews) please note that it is advantageous to display articles of the same type together in each volume and to mark each article with the specific article type.
If you find it necessary to have commercials or banner advertising on your journal's web site(s), make sure that the ad is not in any way offensive and doesn't include information that could decrease the credibility of your journal.
Blinking and/or moving objects will distract a reader and make your web site difficult to "read". This is discouraged.
Keep in mind that, in the long run, articles that are not clearly organised and/or too many commercials/ads/blinking or moving objects will decrease the usage of your web site.
Impact Factors
DOAJ does not condone the use of impact factors; does not recognise partial impact factors, and advocates any official, alternative measure of use, such as article level metrics. There is only one official, universally recognised impact factor that is generated by Thomson Reuters; it is a proprietary measure run by a profit making organisation. It runs against the ethics and principles of open access.
Unfortunately, there are many fake impact factor services now purporting to offer impact factors for new journals.  DO NOT submit papers to a journal based on its impact factor alone.
Transparent editorial boards
We believe that it increases the trustworthiness and credibility of a journal if the reader is able to find/contact the editor or members of the editorial board. For this reason we encourage you to be as transparent as possible when presenting your Editorial Board. Information of public interest is:
Quality control and author guidelines
To assure readers and potential authors that articles go through a quality control system before publication, we strongly recommend that you describe the process clearly on the web site.
Since Open Access is still a relatively young way of publishing research papers and scholarly materials, we believe that it is important to show that open access journals have the same, rigorous quality control systems as printed and subscription based journals.
Having detailed and comprehensive guidelines for authors is a good way of helping potential contributors and saves you time since it can prevent a lot of unnecessary paperwork and manuscript resubmissions.
We recommend all journals have author guidelines (Instructions for authors) and that the following are included:
Statement about Open Access and copyright
Since DOAJ is a collection of Open Access journals and articles, we strongly recommend that you not only mention but thoroughly describe the journal's Open Access policy on the web site. It should be clearly linked to from the home page.
Clearly stating exactly which rights readers have when they use the material is a way of showing that you are sharing your published material to support a greater global exchange of knowledge. It is also a way of protecting your material from illegal use (for example if you are stating that you prohibit reproduction or commercial use of your articles).
Here is an example of an Open Access statement, fitting our criteria, that could be published on your website:
This is an open access journal which means that all content is freely available without charge to the user or his/her institution. Users are allowed to read, download, copy, distribute, print, search, or link to the full texts of the articles in this journal without asking prior permission from the publisher or the author. This is in accordance with the BOAI definition of open access.
Please take care to identify any possible contradictions between your Open Access policy and your copyright policy.
Licensing your material with a CC-license
An additional way of showing in which form a journal is Open Access is through licensing it with a Creative Commons license. (Read more about the different forms of licenses.)
Such licensing is very beneficial for authors since it shows, for example, if there are any limits in creating derivative works.
If licensing old material, please make sure that your journal has the copyright permission of the published material. If you do not, you have to ask the original copyright holder for permission before licensing the articles. (More information can be found at the Creative Commons web site.)
Questions
If you have any questions on the content above or need advice on how to improve your web site to make it fit our selection criteria, please do not hesitate to contact us.
For a journal to be included in DOAJ, it must go through the new application process. Due to the nature of the information that we require to process an application, only publishers or journal owners may apply for their journal to be included. If you would like to see a journal listed that is not yet included in the DOAJ, contact the publisher and ask them to fill in the application form.
The new form requires a lot of information and completing it will take time. It will require you to collect all the necessary information before you start making your application. At this time, you are unable to save the form and come back to it later. We are working on a solution to facilitate that.
The new application form has been extended to enable the DOAJ team to make a comprehensive assessment of the journal's quality and dedication to Open Access. Each journal application is carefully assessed by a member of the DOAJ Team. Each of the 42 answers provided may be verified manually and this important process takes time. We therefore ask you not to chase journal applications as answering these emails takes time and stops us processing applications.
Any email sent about an application that is less than 3 months old will not be answered.
There are now three ways to get your metadata in to DOAJ. You must log in to your account before uploading metadata. The Publishers' Area now includes a 'Your Journals' tab which has a list of all your journals currently included in DOAJ and that are associated with your account. You may only upload metadata to those journals. If you upload metadata which is incorrect (for example contains an ISSN that is not in the journal list) the upload will be rejected. (Note that you should ensure that your journal record is up-to-date in DOAJ before you upload metadata to us. If you need to update a journal record, please contact us.)
The ways to get your metadata into DOAJ are:
For help with creating DOAJ XML and details on XML tags, read the File Upload Info section on our Features pages.
Below are some common reasons for failed xml uploads:
If you have any questions, please contact us.
If you need to correct an error, you must upload the metadata again. To make sure that your new upload overwrites the old one, at least one piece of key metadata in the new file must match the same piece of metadata in the old file. The 2 specific pieces of key metadata that we look for are, in priority order:
If there is no DOI, the script will look for the Full Text URL.
Some examples
Use case 1: a publisher wants to correct some article metadata because an author is missing. The publisher must
reupload the file. The article's DOI in the XML is the same as on the site so the site automatically overwrites the
older version.
Use case 2: a publisher wants to correct the URL for their full text articles because their site has moved.
The publisher does not use DOIs. The publisher must upload a new version. No automatic overwriting
will happen because no matching can occur so the publisher must contact us so we can remove the older version.
We would be delighted if you donate to DOAJ. We rely entirely on contributions. Please read our Support DOAJ page for further information.
Back to topOpen Access Journal:
We define open access journals as journals that use a funding model that does not charge readers or their institutions for access. From the BOAI definition[1] of 'open access' we take the right of users to "read, download, copy, distribute, print, search, or link to the full texts of these articles" as mandatory for a journal to be included in the directory.
[1] http://www.budapestopenaccessinitiative.org/read
Quality Control:
The journal must exercise peer-review or editorial review (particularly in the Humanities), led by an editor, or an editor and an editorial board.
Research Journal:
Journals that report primary results of research or overviews of research results to a scholarly community.
Periodical:
A serial appearing or intended to appear indefinitely at regular intervals, generally more frequently than annually, each issue of which is numbered or dated consecutively and normally contains separate articles, stories, or other writings.
Back to topDOAJ adheres to the Principles of Transparency and Best Practice in Scholarly Publishing, a joint statement published by COPE, DOAJ, OASPA and WAME. We advise that all applicants read through this statement before applying.
To facilitate a faster response time, applications are initially triaged to ensure they meet some basic criteria. These are:
Coverage:
Access:
Quality: The journal must exercise quality control on submitted papers using a peer-review system. The journal—and the manuscript review process specifically—must have either an editor, or an editor and an editorial board, in place. See our policy for Humanities journals.
Periodical: The journal must have at least one ISSN (International Standard Serial Number) registered at issn.org. In general, if a journal exists in print and online, then it should have both an ISSN for the print version and an ISSN for the electronic version.
Back to topApplication
We must receive an application for every journal wishing to be considered for inclusion. Due to the level of detail required, we recommend that the application is made by the journal's editor or publisher. Once submitted, the application passes through a triage process and is assigned to a DOAJ Associate Editor. There are over 40 pieces of information in every application that we will check and verify. As you complete the application form, remember to ensure that the journal's web site states clearly and accurately the information DOAJ is asking for in the application form. The things that we will check include but are not limited to:
If the information provided in the application is unclear or does not match what is on the site, or we think that it is incorrect, the member of our team handling your application will contact you for clarification.
Status updates
We are unable to provide status updates for any application that is less than THREE months old.
Acceptance into DOAJ
Upon acceptance into DOAJ, the journal is classified by the DOAJ team according to the Library of Congress Classification (LCC) system. An automatic confirmation email is sent to the person listed in Question 9; it contains details on how to log into your Publisher account. You will need these details to upload article metadata. The journal is then visible in DOAJ immediately.
Rejection of an Application
If your application is rejected, a member of the DOAJ team will let you know, along with the reason for the rejection. A rejected journal may reapply for inclusion once it has demonstrated clearly that it has made the improvements suggested by the DOAJ.
Uploading or creating metadata in DOAJ
We strongly recommend that ALL journals provide us with article metadata in XML format or create the data manually using our metadata entry form. A script looking for new articles to publish to the site runs every 30 minutes. DOAJ is OAI-PMH compliant and once the article is available in DOAJ it becomes automatically OAI harvestable.
Back to topOAI, Open Archives Initiative, supplies a common framework to web communities that allows them to gain access to content in a standard manner by means of metadata harvesting. Read the details of our OAI feature.
We do have an 'Indexed in DOAJ' logo, in both .eps and .png formats. Please use the Contact us form to request it and a member of our team will check that your journal qualifies.
Back to topIt maybe that the journal has not applied to be in the DOAJ, in which case, please use our Application form. It may be that the journal's application is pending or that it has been rejected. If your application has been rejected, the contact listed in Question 9 of the Application form will have received an email from a member of the DOAJ Team.
Back to topIt isn't possible to save your Application just yet; it's a feature that we will add in the future. In the meantime, you could try these two tips to help you keep a record of your application(s):
Once your journal has been accepted in to DOAJ then you can log in to your account. If the journal has been added to a publisher account that already has journals in DOAJ then the login credentials will be the same: the new journal will have been added to the existing account.
If a new account has been created, an automated email is sent to the contact in Question 9 of the application upon acceptance. The email contains your username and instructions on how to choose a password. The link is valid for 14 days only. Once you have logged in to your account, you will see your journal(s) listed in the 'Your Journals' tab.
If you have problems logging in, or you cannot see your journal listed, or you would like to merge two publisher accounts, then please Contact us.
Back to topOnce a journal has been accepted in to DOAJ, article metadata may be uploaded as XML or created manually. If the journal belongs to an existing DOAJ account, then the publisher must log in to their account and then add metadata via the Publisher Area. For more information go to the For publishers page and read the 'Uploading Metadata' section there.
Back to topIf you did not receive any error messages when you uploaded the metadata then it is likely that everything has worked OK. Remember that it may take up to 60 minutes for your articles to appear on the site and up to 12 hours for the tables of contents to show your latest uploads. You can check that the articles have uploaded correctly by doing a search on the full article title in inverted commas " ". If, after 12 hours, you see that the article is on the site but has not attached itself to the Table of Contents then one of two things has gone wrong:
Remember: articles are added to a journal's Tables of Contents over night so you will not see them there immediately.
If, after 24 hours, you still cannot find your article on the site, please Contact us.
Back to top(You may have an equivalent license in your country that is not a CC license. This is perfectly valid for DOAJ.)
How to choose the CC BY license:
Go to the Creative Commons (CC) web site (http://creativecommons.org/licenses/) and copy the CC BY icon - you can also consult this: http://wiki.creativecommons.org/Before_Licensing .
Put the CC BY icon on the homepage of your journal(s) and on EVERY article. Read how. Best Practice recommends that the license metadata is machine readable that is to say: embedded in the HTML, XML or in the PDF metadata.
Back to topYou can find information on the different types of licenses at the Creative Commons web site: http://creativecommons.org/licenses/ and there is even a page to help you choose the correct license for your content: http://creativecommons.org/choose/.
Both pages are available in 24 different languages.
Back to topWhen applying for a journal to be included in DOAJ, one of the questions asks whether or not you have machine-readable licensing information embedded in your article metadata. There are guidelines on the Creative Commons web site that tell you more about this. The information must be embedded in the HTML, the XML or the PDFs. The emphasis for DOAJ is not HOW the license is embedded but that there IS a machine-readable version of it. Here are a couple of examples:
Back to topWhen applying for a journal to be included in DOAJ, you should include case reports in your article count if they include the retrospective analysis of more than 3 clinical cases. When more than three cases are involved, the article constitutes "research." A journal that publishes only case reports
Back to topDOAJ recognises that some journals may not publish in a field where peer review is the established form of quality assurance. Instead a system of editorial review—either done by the editor(s) or the editors and members of the editorial board only—is in place. This is particularly relevant to the Humanities. 'Editorial review' will only be accepted as an answer to Question 35 of the Application Form if the journal publishes in some such field.
Back to topFunders, libraries and authors can all access deposit policy directories to get an overview of publishing channels that are compliant with, for instance, funder policies. This is one of our areas where we are encouraging Best Practice. A good example of a deposit policy directory is www.sherpa.ac.uk/romeo/.
Back to top {% endblock %}


The Cocos2d developers wanted the internal part of the game look like theater or movie: there is [the director(https://docs.cocos2d-x.org/api-ref/cplusplus/v4x/d7/df3/classcocos2d_1_1_director.html)] and some scenes. The director orders scenes to change one another.
Actually, the Director has following methods to change the scenes:
replaceScene()
changes current scene with a new onepopScene()
/pushScene()
works with some kind of stack of scenes. push freezes the current scene, adds it to the stack and then starts the new one. On the other side, pop deletes the current scene and takes another one from the stack.popToRootScene()
and popToSceneStackLevel(int level)
allows switching to root or arbitrary scene.Anyway, the new scene completely redraws everything that was on the screen before it. In most cases this behavior is good, but there are some exceptions. Let’s say you want to put the game on pause or display some message. In order to make this delay more obvious for the player it will be better to show the new scene over some content from the old one.
For example, the switch may look like this:
First there was a scene with candle animation and rotating UFO. Then it gets changed with a new scene, but this new scene has to use older background.
There is no exact method in Cocos2d to get this effect. However you can achieve it in two steps: first keep an image from the old scene and then use it as a background on the new one.
Like that:
void StaticInterruptScene::switchToInstantScene() {
const Size visibleSize = Director::getInstance()->getVisibleSize();
RenderTexture* rt = RenderTexture::create(visibleSize.width,
visibleSize.height);
rt->begin();
this->visit();
rt->end();
rt->getSprite()->setAnchorPoint(Vec2(0, 0));
Scene* ims = InstantMenuScene::create(rt);
Director::getInstance()->pushScene(ims);
}
}
Here the RenderTexture instance keeps an image generated for the old scene. The InstantMenuScene is a class for a new scene; it receives stored image as a constructor parameter and uses for a background. The usage itself is quite trivial, but you can find it here.


Ticket Price Determinator
Select the movie you want to watch
La La Land
Groundhog Day
Boyz in tha Hood
Pick a time
11:00 a.m.
6:00 p.m.
8:30 p.m.
Select your age range
Under 12
Whatever
65+
Hey
You forgot to choose something. Try again.
Based on your selections, your total price is $
.00. Click to pay.


{% include head.html %}
{% include nav.html %} {% include header.html %} {% include exec_signup.html %} {% include eyecatch.html %} {% include events.html %} {% include team.html %} {% include signup.html %} {% include sponsors.html %} {% include footer.html %} {% include modals.html %} {% include js.html %}


During this rotation we were tasked with producing 3 things with the laser cutter.
The first item I produced was the Drift Dialects Clock
I am a fan of the Drift Dialects company and I even contacted the owner.
The clock will be displayed in their show room and I will be receiving some goods from them in return.
This rotation we were also tasked with creating two other objects.
The first item I chose to do was a Ferrari glass. This glass was done with the rotarty tool within the laser cutter.
The rotary tool and the raster ability of the laser allowed the glass to be engraved.


This panel helps you to select another target device for the project. Only enrolled device can be selected.


Me Page
The name's Yousef Namazi.
I am 24 years old and I am studying at the University of Kristianstad.
I am currently taking the Web Development course and it is my favourite course.
I love hanging out with friends and meeting new people.
The name's Yousef Namazi.
I am 24 years old and I am studying at the University of Kristianstad.
I am currently taking the Web Development course and it is my favourite course.
I love hanging out with friends and meeting new people.


{{ partial "head.html" . }}
{{ partial "body-top" . }}
{{ partial "about.html" . }} {{ if not (eq (len (where .Site.RegularPages "Section" "posts")) 0) }} {{ partial "posts.html" . }} {{ end }} {{ partial "subscribe.html"}}
{{ partial "footer.html" . }} {{ partial "body-bottom" . }}


5. Fourier Analysis - Expert Mode!
As we observed in the previous labs and theory with their corresponding exercises, Fourier analysis is a very important tool in Signal Processing.
- 5. Fourier Analysis - Expert Mode!
- 5.1. IQ signals or What is up with all the Complex Numbers
- 5.2. Fast Fourier Transforms (FFT)
- 5.3. Fourier Analysis in Radio Astronomy: A Spectrometer
- 5.4. The Spectrometer’s purpose
- 5.5. The Window Field in the gnuradio FFT block
- 5.6. Spectral Leakage & Polyphase Filter Bank (PFB)
- 5.7. Final Upgrade: PFB Spectrometer
- 5.8. Saving Data - Image Credits
5.1. IQ signals or What is up with all the Complex Numbers
If you remember from the lab 2 introduction an SDR dongle passes the incoming signal through a mixer where the receiver sets the frequency you observe by setting the “LO” frequency which is mixed (multiplied) with the incoming signal. The signal is actually mixed with 2 LO’s, one cosine wave and one sine wave. This is called quadrature sampling, and is done so that it is possible to distinguish a signal that is some frequency(say 2MHz) below the “LO” frequency, or 2MHz above the LO frequency. With just a single mixing and one measurement, one just cannot distinguish between a signal at those two frequencies.
See this jupyter notebook for an introduction to the idea.
Now demonstrate IQ processing in gnuradio. We can demonstrate this at much lower frequencies as well. Set the sample-rate to 48kHz. Create 2 tones(cosine signals), one at 8kHz, one at 12kHz. Create your LO at 10kHz, one a cosine and one a sine.
Try using the two signals independently, and added together, this is the overall ‘signal’. Now multiply this signal by the cosine and the sine “LO’s”. This now will become your IQ signal. In gnuradio, this is passed into a “float to complex” block, where the cosine LO mixed signal is the real, and the sine multiplied is the imaginary. This can then be passed into a sink.
Add different sinks along the way, looking at just the cosine (“I”) or sine (“Q”) multiplied signals. With just the single incoming tone, demonstrate that you can in fact recover it after mixing. Do we need a filter? Where? Add one if needed.
5.2. Fast Fourier Transforms (FFT)
The Discrete Fourier Transform for N samples is given by:
Evaluating the DFT’s sums directly involves complex multiplications and N(N−1) complex additions, of which operations can be saved by eliminating trivial operations such as multiplications by 1. Multiplications are particularly expensive computations.
Fast Fourier transform algorithms drastically reduce the computational complexity. The radix-2 Cooley–Tukey algorithm is a widely used FFT algorithm. In comparison to the traditional DFT it can compute the same result with only complex multiplications (again, ignoring simplifications of multiplications by 1 and similar) and complex additions.
Check out this link for a derviation of the Cooley-Tukey Algorithm
5.2.1. 8 Point Fast Fourier Transform [OPTIONAL]
The DFT implemented through a Cooley-Tukey Decimation in frequency FFT algorithm has the flowgraph shown below.
Use appropriate Constant multiplies and and adders to construct the above in gnuradio ( Where W^{i} = $e^\frac{-2\pi ki}{8})$. Are the outputs the Valid frequency domain results?
5.3. Fourier Analysis in Radio Astronomy: A Spectrometer
You now have the tools necessary to create the digital signal processing for a Spectrometer for a radio telescope. A spectrometer:
- Separates the incoming radio signal into individual frequency components (breaks it into individual cosine wave amplitudes and phases at each frequency)
- Measures the power in each of the cosine waves.
- Integrates (Averages) to get get a more precise measurement of the power at each frequency.
Use GnuRadio to create the signal processing chain to achieve this. Use an osmocom airspy source. Use an FFT to separate frequency components.
5.4. The Spectrometer’s purpose
As mentioned above, A spectrometer is used to record and measure the spectral content of signals, such as radio waves received from astronomical sources. Specifically, a spectrometer measures the power spectral density (PSD, measured in units of ) of a signal. Analysis of spectral content can reveal details of radio sources, as well as properties of the intervening medium like galactic neutral hydrogen. The Power Spectral Density is given by the Wiener-Kinchin theorem for wide sense stationary signals as:
and in the fourier domain E[] stands for the expected value i.e. the mean
There are therefore two distinct classes of spectrometers: 1) ones that approximate by first forming the autocorrelation, then taking a Fourier transform and 2) those that first convert into the frequency domain to form X(k) before evaluating . These are Autocorrelation Spectrometers and Fourier Transform Filter banks respectively.
The one we made above is a Fourier transform filter bank. A filter bank is simply an array of band-pass filters, designed to split an input signal into multiple components . A spectrometer is referred to as a analysis filterbank where the output of each filter is squared and averaged.
5.5. The Window Field in the gnuradio FFT block
The spectrometer we constructed effectively works as a array of band-pass FIR filters. If you recall FIR filters their design involves something called window-functions designed to optimize the filter response. The Discrete Fourier transform as it were uses the rectangular window function across each frequency channel. The response is non-ideal leading to spectral leakage i.e. the signal showing up in neighboring frequency channels. Below is a Demonstration of DFT leakage - a tone at 5.1MHz, sampled at 128MHz, and Fourier-transformed with 64 points, appears to varying levels in all the output frequency bins.
This can be improveed by using better windowing functions to properly define the frequency channel. Below are some commonly used windowing functions.
Note the frequncy response, the main lobe width and the attenuation of the side lobes determine how well defined are the frequency channels. The figures below illustrate the difference. The second plot shows the window response in some frequency bins, the ones with the higher side-lobes as responses of boxcar windows and the the lower side-lobes are of the hann window.
In your spectrometer flowgraph, change the window field in the FFT block and observe how the response of a tone ( a sinusoud signal ) changes for different windows.
5.6. Spectral Leakage & Polyphase Filter Bank (PFB)
Despite the appropriate windowing, spectral leakage persists, moreover there is something called a scalloping loss. Scalloping loss is the loss in energy between frequency bin centers due to the non-flat nature of the single-bin frequency response.
The polyphase filter bank (PFB) technique is a mechanism for alleviating the aforementioned drawbacks of the straightforward DFT. The PFB produces a flat response across the channel and provides excellent suppression of out-of-band signals, as shown below.
“Instead of taking an N-point transform directly, a block of data of size N x P = M is read, and multiplied point-by-point with a window function (in other words, the data is ‘weighted’). As mentioned before, the shape of the window function determines the shape of the single-bin frequency response. Since we wish the single-bin frequency response to resemble a rectangular function as much as possible, we choose its Fourier Transform pair, the sinc function, as our window function. Once the multiplication is done, the block of data is split into P subsets of length N each, and added point-by-point. This array is then passed to a regular DFT routine to get an N-point transform that exhibits less leakage. This method is presented graphically below”1
The same process, mathematically:
Where, where the sub-filter coefficients correspond to what are called P-tap ‘polyphase sub-filters’. The N such polyphase sub-filters that make up this operation, together with the following DFT stage, are collectively called a ‘polyphase filter bank’ (‘PFB’). A realization of this filter bank is shown below:
5.7. Final Upgrade: PFB Spectrometer
Add the polyphase filters to your spectrometer just before taking the FFT. Refer to the diagram above, the dotted squares are simply band-pass FIR filters. Use a hann/hamming window.
The ployphase filter can be realized by implementing following flowgraph:
The constant muliplier
blocks are sections of the filter window as seen the diagram detailing the process above. The filter window is designed by using import block to import numpy
and assigning three constant variables as:
- sinc_sample_locations
np.arange(-np.pi*4/2.0, np.pi*4/2.0, np.pi/vec_length)
- sinc
np.sinc(sinc_sample_locations/np.pi)
- custom_window
sinc*np.hamming(4*vec_length)
Now
custom_window
are all the window co-efficients/taps you need to do the multiplications, your vector length samples at a time. The constants in the constant multiplier blocks from the top to bottom are as follows:custom_window[-vec_length:] custom_window[2*vec_length:3*vec_length] custom_window[vec_length:2*vec_length] custom_window[0:vec_length]
5.8. Saving Data
Save the spectrometer data for science! (Use File Sink)
NOTE: Our Low Noise Amplifier (LNA) needs to be powered to actually work. We can configure the airspy dongle by settign bias=1 in the device arguments field of the osmocom source block such as:
Image Credits
- The windows, the two types of spectrometers,fft vs hann resposnse https://arxiv.org/pdf/1607.03579.pdf
- The PFB flowgraph, spectral leakage demo, https://casper.berkeley.edu/wiki/The_Polyphase_Filter_Bank_Technique
- IQ diagram https://www.dsprelated.com/showarticle/192.php


About CS-10 Team Members
Work InstallationDashboard
DocumentStatus TrackStatus
ViaductStatus EHS
Issues Incidents
ProcurementStatus


I live in
the beautiful neighborhood of Williamsburg, in Brooklyn, New York City.
My favorite way to work is
at night when the whole world is fast asleep. It's kinda a false statement to make since I'm living in the city that never sleeps. I usually work while listening to the Grateful Dead if doing design work, or underground DJs when I need to be more pumped while coding. My MacBook Pro, Bose Headphones, and a few RedBulls are part of my mojo.
In my free time, I like to
read a lot of things, whether novels or articles, explore New York, meet with friends and go to concerts or restaurants, or work on a hardware project.


Liza Basden is a chemistry teacher in Illinois that I connected with earlier this year. Periodically, we’ll share resources with one another for labs or other activities that we run in our classes. Last week, I was browsing for a lab to run with students on the different types of chemical reactions when Liza sent me some awesome pictures from her own class:
@bennettscience Inspired by your How Big is a Mol activity to find more ways for my Ss to express their creativity pic.twitter.com/86J2ljP
— Liza Basden (@lbasden) February 1, 2013
I really like the fact that she pulls in inquiry to get the students thinking about similarities and differences in the chemical equations before the students begin to categorize them as single replacement, double replacement, etc. It forces the students to make connections between various chemical equations that are really quite obvious when we sit down to compare. Plus, asking them to draw out a representation of the reaction pushes critical thinking and analysis of what they’re learning, which increases retention and understanding.
She was kind enough to share the prep materials and the student papers and has given me permission to share these materials with anyone that may want to use them in their class.
If you end up using this activity, we’d love to see some photos of your student’s work shared either here in the comments or shared Twitter.
All photos in this post are from Liza Basden, used with permission.
Written on February 4th, 2013 by Brian Bennett Categorized in: All Creative Science Teaching
Leave a comment