3132. Find the Integer Added to Array II

You are given two integer arrays nums1 and nums2.

From nums1 two elements have been removed, and all other elements have been increased (or decreased in the case of negative) by an integer, represented by the variable x.

As a result, nums1 becomes equal to nums2. Two arrays are considered equal when they contain the same integers with the same frequencies.

Return the minimum possible integer x that achieves this equivalence.

Example 1:

Input: nums1 = [4,20,16,12,8], nums2 = [14,18,10]

Output: -2

Explanation:

After removing elements at indices [0,4] and adding -2, nums1 becomes [18,14,10].

Example 2:

Input: nums1 = [3,5,5,3], nums2 = [7,7]

Output: 2

Explanation:

After removing elements at indices [0,3] and adding 2, nums1 becomes [7,7].

Constraints:

  • 3 <= nums1.length <= 200
  • nums2.length == nums1.length - 2
  • 0 <= nums1[i], nums2[i] <= 1000
  • The test cases are generated in a way that there is an integer x such that nums1 can become equal to nums2 by removing two elements and adding x to each element of nums1.
class Solution {
public:
    int minimumAddedInteger(vector<int>& nums1, vector<int>& nums2) {
        sort(nums1.begin(), nums1.end());
        sort(nums2.begin(), nums2.end());
         for (int i = 2; i > 0; i--) {
            int x = nums2[0] - nums1[i];
            int j = 0;
            for (int k = i; k < nums1.size(); k++) {
                if (nums2[j] == nums1[k] + x && ++j == nums2.size()) {
                    return x;
                }
            }
        }
        return nums2[0] - nums1[0];
    }
};

3.5 Edit the Script 1. Launch a text or code editor to create a new JavaScript file. 2. Review the script one function at a time. There are four functions that must be implemented in the script to support solicited ethernet communications. • onProfileLoad: Retrieves driver metadata • onValidateTag: Verifies the address and data type created in the configuration or any dynamic tags created in an OPC client are valid for the end device connected • onTagsRequest: Builds a packet of bytes to transmit to the device across the wire. • onData: Interprets the response from the device and updates tag values or indicates if the read or write operation was successful based on the data in the response. Note: onTagsRequest and onData can do much more then described in this example. These functions can be used to communicate with many kinds of protocols. For more information view the Profile Library Plugin Help documentation. 3. Build out the script one function at a time, use the following information to edit the script. Required function: onProfileLoad The onProfileLoad function is the first of these functions called by the driver. It retrieves driver metadata, identifying the interface between the script and the driver by specifying the version of Universal Device Driver with which it was created as well as the mode. For more information on the mode please view the Profile Library plug-in help. Note: The only supported version is 2.0. Any other value is rejected, leading to failure of all subsequent functions. Any exception thrown out of any of the “framework” functions is caught and results in failure of the current operation. An exception thrown out of: • onProfileLoad causes all subsequent operations to fail until corrected • onValidateTag causes the tag address to be treated as “invalid” • onTagsRequest causes the read or write operation on the current tag to fail • onData causes the read or write operation on the current tag to fail Below is the entire onProfileLoad function: function onProfileLoad() { return { version: “2.0”, mode: “Client” }; } Required function: onValidateTag The onValidateTag script function is to validate the address syntax of a tag and the data type, which is central to communicating with a device. In the case of a Modbus device, this function ensures that an address is a holding register in the supported range. If desired, add logic to this function to modify various tag fields, such as providing a valid default data type,r modifying an address format to enforce consistency among tag addresses, or assigning a bulkId to group specific tags together. For the onValidateTag function in this Modbus example, review the sections: www.ptc.com 6 ©2021-2023 PTC, Inc. All Rights Reserved. // Validate the address is a holding register in the supported range let tagAddress = info.tag.address; try { let numericAddress = parseInt(tagAddress, 10); if (numericAddress < MINREGISTERADDRESS || numericAddress > MAXREGISTERADDRESS || isNaN(numericAddress)) { info.tag.valid = false; return info.tag; } // If grouping tags into bulks, assign bulkId now. // Otherwise, the next bulkId is assigned by default. let bulkId = Math.floor((numericAddress - MINREGISTERADDRESS)/BULKREGISTERCOUNT); info.tag.bulkId = bulkId; log(`Modbus Ethernet onValidateTag: Bulk register count ${BULKREGISTERCOUNT}, address ${tagAddress}, bulkId ${info.tag.bulkId}`, VERBOSE_LOGGING); info.tag.valid = true; return info.tag; } catch (e) { // Use log to provide helpful information that can assist with error resolution log(`Unexpected error (onValidateTag): ${e.message}`, VERBOSE_LOGGING); info.tag.valid = false; return info.tag; } The code above offers a look at the JavaScript object info that the driver provides to the script writer. This object is meant to hold data to be exchanged between the script and the driver. It checks the address received from the driver (info.tag.address) and verifies it is in the expected range for a Modbus holding register as defined by constants MINREGISTERADDRESS, MAXREGISTERADDRESS. If it’s not in that range, fail the tag being added by setting the valid field of the tag to false: info.tag.valid = false. The script also defines the bulkId field for each tag. The register in the address along with the BULKREGISTERCOUNT constant facilitates assigning the bulkId that allows blocking together consecutive registers. Once the tags are blocked together, the Universal Device driver will then provide them in the tags object passed to the onTagsRequest and onData functions. // Provide a valid default data type based on register // Note: "Default" is an invalid data type let validDataTypes = {"3": "Word", "4": "Word"} if (info.tag.dataType === "Default") { let registerChar = info.tag.address.charAt(0); info.tag.dataType = validDataTypes[registerChar]; } /* www.ptc.com 7 ©2021-2023 PTC, Inc. All Rights Reserved. * The regular expression to compare address to. * ^4 starts with '4' * 0* find zero or more occurrences of '0' * 1$ ends with '1' */ let addressRegex = /^40*1$/; // Correct a "semi-correct" tag address (e.g. 401 or 400001 --> 40001) with regex if (addressRegex.test(info.tag.address)) { info.tag.address = "40001"; } The above code provides examples of logic to modify various tag fields. The first code block resets the data type if Default is initially selected. While Default is a Kepware server data type, it is an invalid return value for a tag data type (i.e., info.tag.dataType). As such, provide an appropriate and valid data type based on the register if the data type is set as Default. The second code block uses a regex to recognize semi-correct addresses and modify them accordingly. In the above implementation, this logic adjusts tag addresses with too few or too many zeros; for example, ‘401’ or ‘400001` is changed to ‘40001’. Below is the entire onValidateTag function: function onValidateTag(info) { // Provide a valid default data type based on register // Note: "Default" is an invalid data type let validDataTypes = {"3": "Long", "4": "DWord"} if (info.tag.dataType === "Default") { let registerChar = info.tag.address.charAt(0); info.tag.dataType = validDataTypes[registerChar]; } /* * The regular expression to compare address to. * ^4 starts with '4' * 0* find zero or more occurrences of '0' * 1$ ends with '1' */ let addressRegex = /^40*1$/; // Correct a "semi-correct" tag address (e.g. 401 or 400001 --> 40001) with regex if (addressRegex.test(info.tag.address)) { info.tag.address = "40001"; } // Validate the address is a holding register in the supported range let tagAddress = info.tag.address; try { www.ptc.com 8 ©2021-2023 PTC, Inc. All Rights Reserved. let numericAddress = parseInt(tagAddress, 10); if (numericAddress < MINREGISTERADDRESS || numericAddress > MAXREGISTERADDRESS || isNaN(numericAddress)) { info.tag.valid = false; return info.tag; } // If grouping tags into bulks, assign bulkId now. // Otherwise, the next bulkId is assigned by default. let bulkId = Math.floor((numericAddress - MINREGISTERADDRESS)/BULKREGISTERCOUNT); info.tag.bulkId = bulkId; log(`Modbus Ethernet onValidateTag: Bulk register count ${BULKREGISTERCOUNT}, address ${tagAddress}, bulkId ${info.tag.bulkId}`, VERBOSE_LOGGING); info.tag.valid = true; return info.tag; } catch (e) { // Use log to provide helpful information that can assist with error resolution log(`Unexpected error (onValidateTag): ${e.message}`, VERBOSE_LOGGING); info.tag.valid = false; return info.tag; } } Required function: onTagsRequest The onTagsRequest script function builds a packet of bytes that is sent to the target Modbus device. In the example implementation, the onTagsRequest function makes use of two helper functions to build action-specific packet: BuildReadMessage and BuildWriteMessage: function onTagsRequest(info) { let action = "Fail"; if (info.type === "Read") { let readData = BuildReadMessage(info.tags); // Evaluate if the data was successfully built if (readData.length === 12) { action = "Receive"; } return { action: action, data: readData }; } else if (info.type === "Write") { SENTWRITEDATA = BuildWriteMessage(info.tags); // Evaluate if the data was successfully built www.ptc.com 9 ©2021-2023 PTC, Inc. All Rights Reserved. if (SENTWRITEDATA.length === 12) { action = "Receive"; } return { action: action, data: SENTWRITEDATA }; } } Unlike the onTagsRequest function, these helper functions are not required; they help make the script more manageable. Let’s dive into these helper functions now. Helper Function: BuildReadMessage This function builds into the packet the function code for a Modbus read to ensure that the read is on the appropriate address(es). Most of the Modbus-specific pieces of this snippet are documented in code comments with the important parts called out. The Modbus protocol supports blocking / bulk read and write functionality. The Universal Device Driver supports blocking tags for reads but does not support blocking tags for writes. The tags parameter is an array containing at least one tag element. If, in onValidateTag, the script assigned the same bulkId to more than one tag, then those tags sharing a bulkId are included in the array when the request type is Read. function BuildReadMessage (tags) { // This should never happen, but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } // Sort the Modbus registers low to high let registers = []; for(let i=0; i<tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } registers.sort (sortNumber); // Find the lowest register, and the number of registers required to read the whole block let first = registers[0]; let count = registers[registers.length - 1] - first + 1; // Get the zero-based register index to make the request first -= 40001; The code above checks the tags component of the JavaScript object info (i.e. info.tags). This component holds an array of tags. Each tag has an address used to build a request packet for a read. The beginning of this section of code ensures that the driver has given a tag to build a request packet. If the length of the tags array is zero, it exits the function because there's no reason for the driver to build a request packet if no tag – and in turn, no address – is provided. www.ptc.com 10 ©2021-2023 PTC, Inc. All Rights Reserved. // Update the transaction ID in the stateful transaction object if (TXID === undefined) { TXID = 0; } else { TXID++; } JavaScript is not a strongly typed language, making it possible to modify a variable's type or composition at runtime. This is something to take advantage of within the BuildReadMessage function. The above code snippet updates the value of a global variable TXID, which represents a transaction ID exchanged between the script and the driver. Use this global variable to keep track of the number of times it is building packets to transmit to the device. It's important to keep track of this because the transaction ID is a necessary part of the Modbus protocol, as seen in the next step. TXID is stateful between transactions because it is shared between the script and driver and maintains state across transactions. Every time this function is called, the transaction ID value maintains the state it was the last time it was changed at runtime. // Build the Modbus Ethernet data let data = // ----Transaction ID------|-Protocol--|---Length--|Server|-Fxn-| [hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x03, ------Starting Address-------|-------Register count--------| hiByte(first), loByte(first), hiByte(count), loByte(count)] The above shows the packet being constructed. It is an array of bytes to be sent to the Modbus device. The code comments the different parts of the packet that are defined in the Modbus protocol; for instance, the TXID described earlier is used in the protocol as the top two bytes. Note: Only bytes are currently supported for the data array. Below is the entire BuildReadMessage function: function BuildReadMessage (tags) { // This should never happen, but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } // Sort the Modbus registers low to high let registers = []; for(let i=0; i<tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } registers.sort (sortNumber); // Find the lowest register, and the number of registers required to read the whole block let first = registers[0]; let count = registers[registers.length - 1] - first + 1; // Get the zero-based register index to make the request first -= 40001; www.ptc.com 11 ©2021-2023 PTC, Inc. All Rights Reserved. // Initialize or update the transaction ID in the stateful transaction object if (TXID === undefined) { TXID = 0; } else { TXID++; } // Build the Modbus Ethernet data let data = // ----Transaction ID------|-Protocol--|---Length--|Server|-Fxn-|------Starting Address--- - [hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x03, hiByte(first), ---|-------Register count--------| loByte(first), hiByte(count), loByte(count)] return data; } Helper Function: BuildWriteMessage The BuildWriteMessage function is similar to the BuildReadMessage function in that it assists with building an array of bytes to send the device. However, this function facilitates writing a value to, rather than reading a value from, a Modbus device. Note: Not all devices support writes. If the target device does support writes, the BuildWriteMessage function – in conjunction with the ParseWriteMessage function – provides an example of how to implement this functionality. // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for write request."; } // Sort the Modbus registers low to high let register = parseInt(tags[0].address, 10); register -= 40001; // Get the value to write which is located in the first // element in the tags[n].value object let value = parseInt(tags[0].value); The code above assigns the integer value of the tag address to the variable register. Additionally, is assigns the value of the first tag value to the variable value since KEPServerEX only allows single writes. // Build the Modbus Ethernet data let data = // ----Transaction ID-----|-Protocol--|---Length--|Server|-Fxn-| www.ptc.com 12 ©2021-2023 PTC, Inc. All Rights Reserved. [ hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x06, --------Starting Address----------|-------value to write--------| hiByte(register), loByte(register), hiByte(value), loByte(value) ]; return data; The above shows how to build up a write packet, which is very similar to building a read packet within the BuildReadMessage function. Required function: onData The onData script function parses the array of bytes received from a Modbus device. In the example implementation, as was the case with the onTagsRequest function, the onData function uses two helper functions to parse responses from a Modbus device: ParseReadMessage and ParseWriteMessage: function onData(info) { let action = ACTIONFAILURE; if (info.type === "Read") { let tags = ParseReadMessage(info.tags, info.data); // Evaluate if the data was successfully parsed from the packet if (tags[0].value != null || tags[0].quality != null) { action = ACTIONCOMPLETE; } return { action: action, tags: tags }; } else if (info.type === "Write") { action = ParseWriteMessage(info.data); return { action: action, tags: info.tags }; } } Helper Function: ParseReadMessage This function's purpose is to parse an incoming packet into a tag value to update the respective tag in the server. The incoming packet is passed to the script via the JavaScript object information as the returned byte array is contained in its data component (i.e. info.data). The function determines what information is important based on the protocol specification and extracts the value for the tag/address. This value is assigned to the value field of the tag (e.g. info.tags[0].value) and then returned from the function, which is how the tag is updated in the server. www.ptc.com 13 ©2021-2023 PTC, Inc. All Rights Reserved. function ParseReadMessage(tags, data) { // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } log(`Modbus Ethernet ParseReadMessage: data ${JSON.stringify(data)}`, VERBOSE_LOGGING); // Convert the string addresses to integers (eg 40001) let registers = []; for(let i=0; i < tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } // Find the lowest numbered register - this is the starting address let startingAddress = Array.min (registers); // MBE Response values start here: let offset = 9; // Enough bytes? if (data.length < offset + 2 * registers.length) { // Iterate the registers and set the quality of each tag to bad for (let i = 0; i < registers.length; ++i) { // Log message only once for this response if (i === 0) { if (data.length === offset){ log(`Modbus Ethernet ParseReadMessage: Device returned an error code ${data[7]}, ${data[8]}`); } else { log(`Modbus Ethernet ParseReadMessage: Invalid response from device`); } } tags[i].quality = "Bad"; } } The code above performs error checking and gathering some information about the transaction. If the number of bytes in the response is not the number of bytes expected, then the script sets the quality of each tag to Bad. If the response appears to include an error code from the device, then the script provides that information in the message passed to the log function. Otherwise, the script logs a message indicating an invalid response from the device. The result is an updated tags component of the JavaScript object info to be shared with the driver and ultimately used to update the tag qualities in the server. // Iterate the registers and lookup the response value for each for (let i = 0; i < registers.length; ++i) { // Calculate the index of this register's value in the response buffer let index = registers[i] - startingAddress; // Extract it from the response buffer www.ptc.com 14 ©2021-2023 PTC, Inc. All Rights Reserved. let hi = data[2*index + offset]; let lo = data[2*index + offset + 1]; tags[i].value = (wordFromBytes (hi, lo)); } return tags; The code above extracts the value returned from the device and assigns it to the appropriate tag to be used to update the tag value in the server. The result is an updated tags component of the JavaScript object info to be shared with the driver and ultimately used to update the tag values in the server. Below is the entire ParseReadMessage function. function ParseReadMessage(tags, data) { // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } log(`Modbus Ethernet ParseReadMessage: data ${JSON.stringify(data)}`, VERBOSE_LOGGING); // Convert the string addresses to integers (eg 40001) let registers = []; for(let i=0; i < tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } // Find the lowest numbered register - this is the starting address let startingAddress = Array.min (registers); // MBE Response values start here: let offset = 9; // Enough bytes? if (data.length < offset + 2 * registers.length) { // Iterate the registers and set the quality of each tag to bad for (let i = 0; i < registers.length; ++i) { // Log message only once for this response if (i === 0) { if (data.length === offset){ log(`Modbus Ethernet ParseReadMessage: Device returned an error code ${data[7]}, ${data[8]}`); } else { log(`Modbus Ethernet ParseReadMessage: Invalid response from device`); } } tags[i].quality = "Bad"; } www.ptc.com 15 ©2021-2023 PTC, Inc. All Rights Reserved. } else { // Iterate the registers and lookup the response value for each. // Assigning the quality of the tag is optional. If undefined, Good is assumed. for (let i = 0; i < registers.length; ++i) { // Calc the index of this register's value in the response buffer let index = registers[i] - startingAddress; // Extract the value from the response buffer let hi = data[2*index + offset]; let lo = data[2*index + offset + 1]; tags[i].value = (wordFromBytes (hi, lo)); } } return tags; } Helper Function: ParseWriteMessage The purpose of the ParseWriteMessage function is to determine if the write was successful. Most devices respond that the request was received and executed. In the case of Modbus, the response echoes the request, which makes it possible to compare the returned message with the sent message that was saved in the global variable SENTWRITEDATA. Below is the entire ParseWriteMessage function: function ParseWriteMessage(data) { // Modbus echoes a write request so if the data sent // does not match the data received, then the write fails SENTWRITEDATA.forEach((e1) => data.forEach((e2) => { if (e1 !== e2) { return "Fail"; } })); return "Complete"; } 以上分析总结出重点
09-30
3.5 Edit the Script 1. Launch a text or code editor to create a new JavaScript file. 2. Review the script one function at a time. There are four functions that must be implemented in the script to support solicited ethernet communications. • onProfileLoad: Retrieves driver metadata • onValidateTag: Verifies the address and data type created in the configuration or any dynamic tags created in an OPC client are valid for the end device connected • onTagsRequest: Builds a packet of bytes to transmit to the device across the wire. • onData: Interprets the response from the device and updates tag values or indicates if the read or write operation was successful based on the data in the response. Note: onTagsRequest and onData can do much more then described in this example. These functions can be used to communicate with many kinds of protocols. For more information view the Profile Library Plugin Help documentation. 3. Build out the script one function at a time, use the following information to edit the script. Required function: onProfileLoad The onProfileLoad function is the first of these functions called by the driver. It retrieves driver metadata, identifying the interface between the script and the driver by specifying the version of Universal Device Driver with which it was created as well as the mode. For more information on the mode please view the Profile Library plug-in help. Note: The only supported version is 2.0. Any other value is rejected, leading to failure of all subsequent functions. Any exception thrown out of any of the “framework” functions is caught and results in failure of the current operation. An exception thrown out of: • onProfileLoad causes all subsequent operations to fail until corrected • onValidateTag causes the tag address to be treated as “invalid” • onTagsRequest causes the read or write operation on the current tag to fail • onData causes the read or write operation on the current tag to fail Below is the entire onProfileLoad function: function onProfileLoad() { return { version: “2.0”, mode: “Client” }; } Required function: onValidateTag The onValidateTag script function is to validate the address syntax of a tag and the data type, which is central to communicating with a device. In the case of a Modbus device, this function ensures that an address is a holding register in the supported range. If desired, add logic to this function to modify various tag fields, such as providing a valid default data type,r modifying an address format to enforce consistency among tag addresses, or assigning a bulkId to group specific tags together. For the onValidateTag function in this Modbus example, review the sections: // Validate the address is a holding register in the supported range let tagAddress = info.tag.address; try { let numericAddress = parseInt(tagAddress, 10); if (numericAddress < MINREGISTERADDRESS || numericAddress > MAXREGISTERADDRESS || isNaN(numericAddress)) { info.tag.valid = false; return info.tag; } // If grouping tags into bulks, assign bulkId now. // Otherwise, the next bulkId is assigned by default. let bulkId = Math.floor((numericAddress - MINREGISTERADDRESS)/BULKREGISTERCOUNT); info.tag.bulkId = bulkId; log(`Modbus Ethernet onValidateTag: Bulk register count ${BULKREGISTERCOUNT}, address ${tagAddress}, bulkId ${info.tag.bulkId}`, VERBOSE_LOGGING); info.tag.valid = true; return info.tag; } catch (e) { // Use log to provide helpful information that can assist with error resolution log(`Unexpected error (onValidateTag): ${e.message}`, VERBOSE_LOGGING); info.tag.valid = false; return info.tag; } The code above offers a look at the JavaScript object info that the driver provides to the script writer. This object is meant to hold data to be exchanged between the script and the driver. It checks the address received from the driver (info.tag.address) and verifies it is in the expected range for a Modbus holding register as defined by constants MINREGISTERADDRESS, MAXREGISTERADDRESS. If it’s not in that range, fail the tag being added by setting the valid field of the tag to false: info.tag.valid = false. The script also defines the bulkId field for each tag. The register in the address along with the BULKREGISTERCOUNT constant facilitates assigning the bulkId that allows blocking together consecutive registers. Once the tags are blocked together, the Universal Device driver will then provide them in the tags object passed to the onTagsRequest and onData functions. // Provide a valid default data type based on register // Note: "Default" is an invalid data type let validDataTypes = {"3": "Word", "4": "Word"} if (info.tag.dataType === "Default") { let registerChar = info.tag.address.charAt(0); info.tag.dataType = validDataTypes[registerChar]; } /* * The regular expression to compare address to. * ^4 starts with '4' * 0* find zero or more occurrences of '0' * 1$ ends with '1' */ let addressRegex = /^40*1$/; // Correct a "semi-correct" tag address (e.g. 401 or 400001 --> 40001) with regex if (addressRegex.test(info.tag.address)) { info.tag.address = "40001"; } The above code provides examples of logic to modify various tag fields. The first code block resets the data type if Default is initially selected. While Default is a Kepware server data type, it is an invalid return value for a tag data type (i.e., info.tag.dataType). As such, provide an appropriate and valid data type based on the register if the data type is set as Default. The second code block uses a regex to recognize semi-correct addresses and modify them accordingly. In the above implementation, this logic adjusts tag addresses with too few or too many zeros; for example, ‘401’ or ‘400001` is changed to ‘40001’. Below is the entire onValidateTag function: function onValidateTag(info) { // Provide a valid default data type based on register // Note: "Default" is an invalid data type let validDataTypes = {"3": "Long", "4": "DWord"} if (info.tag.dataType === "Default") { let registerChar = info.tag.address.charAt(0); info.tag.dataType = validDataTypes[registerChar]; } /* * The regular expression to compare address to. * ^4 starts with '4' * 0* find zero or more occurrences of '0' * 1$ ends with '1' */ let addressRegex = /^40*1$/; // Correct a "semi-correct" tag address (e.g. 401 or 400001 --> 40001) with regex if (addressRegex.test(info.tag.address)) { info.tag.address = "40001"; } // Validate the address is a holding register in the supported range let tagAddress = info.tag.address; try {let numericAddress = parseInt(tagAddress, 10); if (numericAddress < MINREGISTERADDRESS || numericAddress > MAXREGISTERADDRESS || isNaN(numericAddress)) { info.tag.valid = false; return info.tag; } // If grouping tags into bulks, assign bulkId now. // Otherwise, the next bulkId is assigned by default. let bulkId = Math.floor((numericAddress - MINREGISTERADDRESS)/BULKREGISTERCOUNT); info.tag.bulkId = bulkId; log(`Modbus Ethernet onValidateTag: Bulk register count ${BULKREGISTERCOUNT}, address ${tagAddress}, bulkId ${info.tag.bulkId}`, VERBOSE_LOGGING); info.tag.valid = true; return info.tag; } catch (e) { // Use log to provide helpful information that can assist with error resolution log(`Unexpected error (onValidateTag): ${e.message}`, VERBOSE_LOGGING); info.tag.valid = false; return info.tag; } } Required function: onTagsRequest The onTagsRequest script function builds a packet of bytes that is sent to the target Modbus device. In the example implementation, the onTagsRequest function makes use of two helper functions to build action-specific packet: BuildReadMessage and BuildWriteMessage: function onTagsRequest(info) { let action = "Fail"; if (info.type === "Read") { let readData = BuildReadMessage(info.tags); // Evaluate if the data was successfully built if (readData.length === 12) { action = "Receive"; } return { action: action, data: readData }; } else if (info.type === "Write") { SENTWRITEDATA = BuildWriteMessage(info.tags); // Evaluate if the data was successfully built if (SENTWRITEDATA.length === 12) { action = "Receive"; } return { action: action, data: SENTWRITEDATA }; } } Unlike the onTagsRequest function, these helper functions are not required; they help make the script more manageable. Let’s dive into these helper functions now. Helper Function: BuildReadMessage This function builds into the packet the function code for a Modbus read to ensure that the read is on the appropriate address(es). Most of the Modbus-specific pieces of this snippet are documented in code comments with the important parts called out. The Modbus protocol supports blocking / bulk read and write functionality. The Universal Device Driver supports blocking tags for reads but does not support blocking tags for writes. The tags parameter is an array containing at least one tag element. If, in onValidateTag, the script assigned the same bulkId to more than one tag, then those tags sharing a bulkId are included in the array when the request type is Read. function BuildReadMessage (tags) { // This should never happen, but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } // Sort the Modbus registers low to high let registers = []; for(let i=0; i<tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } registers.sort (sortNumber); // Find the lowest register, and the number of registers required to read the whole block let first = registers[0]; let count = registers[registers.length - 1] - first + 1; // Get the zero-based register index to make the request first -= 40001; The code above checks the tags component of the JavaScript object info (i.e. info.tags). This component holds an array of tags. Each tag has an address used to build a request packet for a read. The beginning of this section of code ensures that the driver has given a tag to build a request packet. If the length of the tags array is zero, it exits the function because there's no reason for the driver to build a request packet if no tag – and in turn, no address – is provided. // Update the transaction ID in the stateful transaction object if (TXID === undefined) { TXID = 0; } else { TXID++; } JavaScript is not a strongly typed language, making it possible to modify a variable's type or composition at runtime. This is something to take advantage of within the BuildReadMessage function. The above code snippet updates the value of a global variable TXID, which represents a transaction ID exchanged between the script and the driver. Use this global variable to keep track of the number of times it is building packets to transmit to the device. It's important to keep track of this because the transaction ID is a necessary part of the Modbus protocol, as seen in the next step. TXID is stateful between transactions because it is shared between the script and driver and maintains state across transactions. Every time this function is called, the transaction ID value maintains the state it was the last time it was changed at runtime. // Build the Modbus Ethernet data let data = // ----Transaction ID------|-Protocol--|---Length--|Server|-Fxn-| [hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x03, ------Starting Address-------|-------Register count--------| hiByte(first), loByte(first), hiByte(count), loByte(count)] The above shows the packet being constructed. It is an array of bytes to be sent to the Modbus device. The code comments the different parts of the packet that are defined in the Modbus protocol; for instance, the TXID described earlier is used in the protocol as the top two bytes. Note: Only bytes are currently supported for the data array. Below is the entire BuildReadMessage function: function BuildReadMessage (tags) { // This should never happen, but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } // Sort the Modbus registers low to high let registers = []; for(let i=0; i<tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } registers.sort (sortNumber); // Find the lowest register, and the number of registers required to read the whole block let first = registers[0]; let count = registers[registers.length - 1] - first + 1; // Get the zero-based register index to make the request first -= 40001; www.ptc.com 11 ©2021-2023 PTC, Inc. All Rights Reserved. // Initialize or update the transaction ID in the stateful transaction object if (TXID === undefined) { TXID = 0; } else { TXID++; } // Build the Modbus Ethernet data let data = // ----Transaction ID------|-Protocol--|---Length--|Server|-Fxn-|------Starting Address--- - [hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x03, hiByte(first), ---|-------Register count--------| loByte(first), hiByte(count), loByte(count)] return data; } Helper Function: BuildWriteMessage The BuildWriteMessage function is similar to the BuildReadMessage function in that it assists with building an array of bytes to send the device. However, this function facilitates writing a value to, rather than reading a value from, a Modbus device. Note: Not all devices support writes. If the target device does support writes, the BuildWriteMessage function – in conjunction with the ParseWriteMessage function – provides an example of how to implement this functionality. // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for write request."; } // Sort the Modbus registers low to high let register = parseInt(tags[0].address, 10); register -= 40001; // Get the value to write which is located in the first // element in the tags[n].value object let value = parseInt(tags[0].value); The code above assigns the integer value of the tag address to the variable register. Additionally, is assigns the value of the first tag value to the variable value since KEPServerEX only allows single writes. // Build the Modbus Ethernet data let data = // ----Transaction ID-----|-Protocol--|---Length--|Server|-Fxn-| www.ptc.com 12 ©2021-2023 PTC, Inc. All Rights Reserved. [ hiByte(TXID), loByte(TXID), 0x00, 0x00, 0x00, 0x06, 0x00, 0x06, --------Starting Address----------|-------value to write--------| hiByte(register), loByte(register), hiByte(value), loByte(value) ]; return data; The above shows how to build up a write packet, which is very similar to building a read packet within the BuildReadMessage function. Required function: onData The onData script function parses the array of bytes received from a Modbus device. In the example implementation, as was the case with the onTagsRequest function, the onData function uses two helper functions to parse responses from a Modbus device: ParseReadMessage and ParseWriteMessage: function onData(info) { let action = ACTIONFAILURE; if (info.type === "Read") { let tags = ParseReadMessage(info.tags, info.data); // Evaluate if the data was successfully parsed from the packet if (tags[0].value != null || tags[0].quality != null) { action = ACTIONCOMPLETE; } return { action: action, tags: tags }; } else if (info.type === "Write") { action = ParseWriteMessage(info.data); return { action: action, tags: info.tags }; } } Helper Function: ParseReadMessage This function's purpose is to parse an incoming packet into a tag value to update the respective tag in the server. The incoming packet is passed to the script via the JavaScript object information as the returned byte array is contained in its data component (i.e. info.data). The function determines what information is important based on the protocol specification and extracts the value for the tag/address. This value is assigned to the value field of the tag (e.g. info.tags[0].value) and then returned from the function, which is how the tag is updated in the server. function ParseReadMessage(tags, data) { // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } log(`Modbus Ethernet ParseReadMessage: data ${JSON.stringify(data)}`, VERBOSE_LOGGING); // Convert the string addresses to integers (eg 40001) let registers = []; for(let i=0; i < tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } // Find the lowest numbered register - this is the starting address let startingAddress = Array.min (registers); // MBE Response values start here: let offset = 9; // Enough bytes? if (data.length < offset + 2 * registers.length) { // Iterate the registers and set the quality of each tag to bad for (let i = 0; i < registers.length; ++i) { // Log message only once for this response if (i === 0) { if (data.length === offset){ log(`Modbus Ethernet ParseReadMessage: Device returned an error code ${data[7]}, ${data[8]}`); } else { log(`Modbus Ethernet ParseReadMessage: Invalid response from device`); } } tags[i].quality = "Bad"; } } The code above performs error checking and gathering some information about the transaction. If the number of bytes in the response is not the number of bytes expected, then the script sets the quality of each tag to Bad. If the response appears to include an error code from the device, then the script provides that information in the message passed to the log function. Otherwise, the script logs a message indicating an invalid response from the device. The result is an updated tags component of the JavaScript object info to be shared with the driver and ultimately used to update the tag qualities in the server. // Iterate the registers and lookup the response value for each for (let i = 0; i < registers.length; ++i) { // Calculate the index of this register's value in the response buffer let index = registers[i] - startingAddress; // Extract it from the response buffer www.ptc.com 14 ©2021-2023 PTC, Inc. All Rights Reserved. let hi = data[2*index + offset]; let lo = data[2*index + offset + 1]; tags[i].value = (wordFromBytes (hi, lo)); } return tags; The code above extracts the value returned from the device and assigns it to the appropriate tag to be used to update the tag value in the server. The result is an updated tags component of the JavaScript object info to be shared with the driver and ultimately used to update the tag values in the server. Below is the entire ParseReadMessage function. function ParseReadMessage(tags, data) { // This should never happen but it's best practice if (tags.length === 0) { throw "No tags were requested for read request."; } log(`Modbus Ethernet ParseReadMessage: data ${JSON.stringify(data)}`, VERBOSE_LOGGING); // Convert the string addresses to integers (eg 40001) let registers = []; for(let i=0; i < tags.length; i++) { registers[i] = parseInt(tags[i].address, 10); } // Find the lowest numbered register - this is the starting address let startingAddress = Array.min (registers); // MBE Response values start here: let offset = 9; // Enough bytes? if (data.length < offset + 2 * registers.length) { // Iterate the registers and set the quality of each tag to bad for (let i = 0; i < registers.length; ++i) { // Log message only once for this response if (i === 0) { if (data.length === offset){ log(`Modbus Ethernet ParseReadMessage: Device returned an error code ${data[7]}, ${data[8]}`); } else { log(`Modbus Ethernet ParseReadMessage: Invalid response from device`); } } tags[i].quality = "Bad"; } www.ptc.com 15 ©2021-2023 PTC, Inc. All Rights Reserved. } else { // Iterate the registers and lookup the response value for each. // Assigning the quality of the tag is optional. If undefined, Good is assumed. for (let i = 0; i < registers.length; ++i) { // Calc the index of this register's value in the response buffer let index = registers[i] - startingAddress; // Extract the value from the response buffer let hi = data[2*index + offset]; let lo = data[2*index + offset + 1]; tags[i].value = (wordFromBytes (hi, lo)); } } return tags; } Helper Function: ParseWriteMessage The purpose of the ParseWriteMessage function is to determine if the write was successful. Most devices respond that the request was received and executed. In the case of Modbus, the response echoes the request, which makes it possible to compare the returned message with the sent message that was saved in the global variable SENTWRITEDATA. Below is the entire ParseWriteMessage function: function ParseWriteMessage(data) { // Modbus echoes a write request so if the data sent // does not match the data received, then the write fails SENTWRITEDATA.forEach((e1) => data.forEach((e2) => { if (e1 !== e2) { return "Fail"; } })); return "Complete"; } 把3.5以上各个代码段,整理成一段完整的代码,这段代码必须有合理性,可直接复制出来能运行的代码。
09-30
Network resource definitions of iLO 5 v3.04 For each data type provided by the HPE ilO Redfish service, find below its description including the list of possible instances (URIs), links to related other resources, described properties and many other details. Refer to the data types and collection section for more information on Redfish data types and collections. NetworkAdapterCollection @odata.type: "#NetworkAdapterCollection.NetworkAdapterCollection" A Collection of NetworkAdapter resource instances. Resource Instances Uri HTTP Allow /redfish/v1/chassis/{item}/networkadapters GET Links to other Resources Link Name Destination type Members[] NetworkAdapter Members (array) Member of NetworkAdapterCollection.NetworkAdapterCollection Members is an array containing elements of: Members[{item}].@odata.id Member of NetworkAdapterCollection.NetworkAdapterCollection Type string Read Only True Format uri-reference Members@odata.count Member of NetworkAdapterCollection.NetworkAdapterCollection Description The total number of collection members. Type integer Read Only True Oem.Hpe.MemberContents Member of NetworkAdapterCollection.NetworkAdapterCollection Description Provides the discovery status of this collection. For some server platforms, only partial device discovery is possible under auxiliary power. Type string or null Read Only True Added iLO 5 1.40 The following are the supported values: Value Description Null A value is temporarily unavailable AllDevices The server state allows complete device discovery. All installed devices are listed as members. AuxPowerDevices The server architecture may not support power to all installed devices in the current auxiliary power state. Only devices capable of operating in this power state are listed as members. Additional devices may be listed when the server is fully powered. NetworkAdapter @odata.type: "#NetworkAdapter.v1_5_0.NetworkAdapter" A NetworkAdapter represents the physical network adapter capable of connecting to a computer network. Examples include but are not limited to Ethernet, Fibre Channel, and converged network adapters. The Data Source is either DCi or RDE. HPE OEM section shall be present only for DCi Data Source. Resource Instances Uri HTTP Allow /redfish/v1/chassis/{item}/networkadapters/{item} GET POST PATCH /redfish/v1/chassis/{item}/networkadapters/{item}/settings GET POST PATCH @Redfish.Settings Member of NetworkAdapter.v1_5_0.NetworkAdapter See the Redfish standard schema and specification for information on common @Redfish properties. Controllers (array) Member of NetworkAdapter.v1_5_0.NetworkAdapter Controllers is an array containing elements of: Controllers[{item}].ControllerCapabilities Controllers[{item}].ControllerCapabilities.DataCenterBridging Controllers[{item}].ControllerCapabilities.DataCenterBridging.Capable Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The value of this property shall be a boolean indicating whether this controller is capable of Data Center Bridging (DCB). Type boolean or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.NPAR Controllers[{item}].ControllerCapabilities.NPAR.NparCapable Member of NetworkAdapter.v1_5_0.NetworkAdapter Description Indicates whether or not NIC function partitioning is supported by a controller. Type boolean or null Read Only True Added iLO 5 1.40 Controllers[{item}].ControllerCapabilities.NPAR.NparEnabled Member of NetworkAdapter.v1_5_0.NetworkAdapter Description When true, NIC function partitioning is active on this controller. Type boolean or null Read Only False Added iLO 5 1.40 Controllers[{item}].ControllerCapabilities.NPIV Controllers[{item}].ControllerCapabilities.NPIV.MaxDeviceLogins Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The maximum number of N_Port ID Virtualization (NPIV) logins allowed simultaneously from all ports on this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.NPIV.MaxPortLogins Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The maximum number of N_Port ID Virtualization (NPIV) logins allowed per physical port on this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.NetworkDeviceFunctionCount Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The maximum number of physical functions available on this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.NetworkPortCount Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The number of physical ports on this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.VirtualizationOffload Controllers[{item}].ControllerCapabilities.VirtualizationOffload.SRIOV Controllers[{item}].ControllerCapabilities.VirtualizationOffload.SRIOV.SRIOVVEPACapable Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The value of this property shall be a boolean indicating whether this controller supports Single Root Input/Output Virtualization (SR-IOV) in Virtual Ethernet Port Aggregator (VEPA) mode. Type boolean or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.VirtualizationOffload.VirtualFunction Controllers[{item}].ControllerCapabilities.VirtualizationOffload.VirtualFunction.DeviceMaxCount Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The maximum number of Virtual Functions (VFs) supported by this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.VirtualizationOffload.VirtualFunction.MinAssignmentGroupSize Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The minimum number of Virtual Functions (VFs) that can be allocated or moved between physical functions for this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].ControllerCapabilities.VirtualizationOffload.VirtualFunction.NetworkPortMaxCount Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The maximum number of Virtual Functions (VFs) supported per network port for this controller. Type number or null Read Only True Added iLO 5 1.20 Controllers[{item}].FirmwarePackageVersion Member of NetworkAdapter.v1_5_0.NetworkAdapter Description The version number of the user-facing firmware package. Type string or null Read Only True Added iLO 5 1.20 Controllers[{item}].Links Controllers[{item}].Links.NetworkDeviceFunctions (array) Member of NetworkAdapter.v1_5_0.NetworkAdapter NetworkDeviceFunctions is an array containing elements of: NetworkDeviceFunctions[{item}].@odata.id Member of NetworkAdapter.v1_5_0.NetworkAdapter 请学习HP官网的文档,然后再去给我取物理网卡名称
09-25
sample_object_model_3d (Operator) Name sample_object_model_3d — Sample a 3D object model. Signature sample_object_model_3d( : : ObjectModel3D, Method, SamplingParam, GenParamName, GenParamValue : SampledObjectModel3D) Description sample_object_model_3d creates a sampled version of the 3D object model ObjectModel3D and returns it in SampledObjectModel3D. Depending on the method used, SamplingParam controls the minimum distance or the number of points in SampledObjectModel3D. The created 3D object model is returned in SampledObjectModel3D. Using sample_object_model_3d is recommended if complex point clouds are to be thinned out for faster postprocessing or if primitives are to be converted to point clouds. Note that if the 3D object model is triangulated and should be simplified by preserving its original geometry as good as possible, simplify_object_model_3d should be used instead. If the input object model ObjectModel3D contains only points, several sampling methods are available which can be selected using the parameter Method: 'fast': The default method 'fast' adds all points from the input model which are not closer than SamplingParam to any point that was earlier added to the output model. If present, normals, XYZ-mapping and extended point attributes are copied to the output model. 'fast_compute_normals': The method 'fast_compute_normals' selects the same points as the method 'fast', but additionally calculates the normals for all points that were selected. For this, the input object model must either contain normals, which are copied, or it must contain a XYZ-mapping attribute from which the normals are computed. The z-component of the calculated normal vectors is always positive. The XYZ-mapping is created by xyz_to_object_model_3d. 'accurate': The method 'accurate' goes through the points of the 3D object model ObjectModel3D and calculates whether any other points are within a sphere with the radius SamplingParam around the examined point. If there are no other points, the original point is stored in SampledObjectModel3D. If there are other points, the center of gravity of these points (including the original point) is stored in SampledObjectModel3D. This procedure is repeated with the remaining points until there are no points left. Extended attributes of the input 3D object model are not copied, but normals and XYZ-mapping are copied. For this method, a noise removal is possible by specifying a value for 'min_num_points' in GenParamName and GenParamValue, which removes all interpolated points that had less than the specified number of neighbor points in the original model. 'accurate_use_normals': The method 'accurate_use_normals' requires normals in the input 3D object model and interpolates only points with similar normals. The similarity depends on the angle between the normals. The threshold of the angle can be specified in GenParamName and GenParamValue with 'max_angle_diff'. The default value is 180 degrees. Additionally, outliers can be removed as described in the method 'accurate', by setting the generic parameter 'min_num_points'. 'xyz_mapping': The method 'xyz_mapping' can only be applied to 3D object models that contain an XYZ-mapping (for example, if it was created using xyz_to_object_model_3d). This mapping stores for each 3D point its original image coordinates. The method 'xyz_mapping' subdivides those original images into squares with side length SamplingParam (which is given in pixel) and selects one 3D point per square. The method behaves similar to applying zoom_image_factor onto the original XYZ-images. Note that this method does not use the 3D-coordinates of the points for the point selection, only their 2D image coordinates. It is important to notice that for this method, the parameter SamplingParam corresponds to a distance in pixels, not to a distance in 3D space. 'xyz_mapping_compute_normals': The method 'xyz_mapping_compute_normals' selects the same points as the method 'xyz_mapping', but additionally calculates the normals for all points that were selected. The z-component of the normal vectors is always positive. If the input object model contains normals, those normals are copied to the output. Otherwise, the normals are computed based on the XYZ-mapping. 'furthest_point': The method 'furthest_point' iteratively adds the point of the input object to the output object that is furthest from all points already added to the output model. This usually leads to a reasonably uniform sampling. For this method, the desired number of points in the output model is passed in SamplingParam. If that number exceeds the number of points in the input object, then all points of the input object are returned. The first point added to the output object is the point that is furthest away from the center of the axis aligned bounding box around the points of the input object. 'furthest_point_compute_normals': The method 'furthest_point_compute_normals' selects the same points as the method 'furthest_point', but additionally calculates the normals for all points that were selected. The number of desired points in the output object is passed in SamplingParam. To compute the normals, the input object model must either contain normals, which are copied, or it must contain a XYZ-mapping attribute from which the normals are computed. The z-component of the calculated normal vectors is always positive. The XYZ-mapping is created by xyz_to_object_model_3d. If the input object model contains faces (triangles or polygons) or is a 3D primitive, the surface is sampled with the given distance. In this case, the method specified in Method is ignored. The directions of the computed normals depend on the face orientation of the model. Usually, the orientation of the faces does not vary within one CAD model, which results in a set of normals that is either pointing inwards or outwards. Note that planes and cylinders must have finite extent. If the input object model contains lines, the lines are sampled with the given distance SamplingParam. The sampling process approximates surfaces by creating new points in the output object model. Therefore, any extended attributes from the input object model are discarded. For mixed input object models, the sampling priority is (from top to bottom) faces, lines, primitives and points, i.e., only the objects of the highest priority are sampled. The parameter SamplingParam accepts either one value, which is then used for all 3D object models passed in ObjectModel3D, or one value per input object model. If SamplingParam is a distance in 3D space the unit is the usual HALCON-internal unit 'm'. Execution Information Multithreading type: reentrant (runs in parallel with non-exclusive operators). Multithreading scope: global (may be called from any thread). Processed without parallelization. This operator supports canceling timeouts and interrupts. Parameters ObjectModel3D (input_control) object_model_3d(-array) → (handle) Handle of the 3D object model to be sampled. Method (input_control) string → (string) Selects between the different subsampling methods. Default: 'fast' List of values: 'accurate', 'accurate_use_normals', 'fast', 'fast_compute_normals', 'furthest_point', 'furthest_point_compute_normals', 'xyz_mapping', 'xyz_mapping_compute_normals' SamplingParam (input_control) real(-array) → (real / integer) Sampling distance or number of points. Number of elements: SamplingParam == 1 || SamplingParam == ObjectModel3D Default: 0.05 GenParamName (input_control) string-array → (string) Names of the generic parameters that can be adjusted. Default: [] List of values: 'max_angle_diff', 'min_num_points' GenParamValue (input_control) number-array → (real / integer / string) Values of the generic parameters that can be adjusted. Default: [] Suggested values: 1, 2, 5, 10, 20, 0.1, 0.25, 0.5 SampledObjectModel3D (output_control) object_model_3d(-array) → (handle) Handle of the 3D object model that contains the sampled points. Number of elements: SampledObjectModel3D == ObjectModel3D
09-14
F. Attraction Theory time limit per test2 seconds memory limit per test256 megabytes Taylor Swift - Love Story (Taylor's Version) ⠀ There are 𝑛 people in positions 𝑝1,𝑝2,…,𝑝𝑛 on a one-dimensional coordinate axis. Initially, 𝑝𝑖=𝑖 for each 1≤𝑖≤𝑛. You can introduce an attraction at some integer coordinate 𝑥 (1≤𝑥≤𝑛), and then all the people will move closer to the attraction to look at it. Formally, if you put an attraction in position 𝑥 (1≤𝑥≤𝑛), the following changes happen for each person 𝑖 (1≤𝑖≤𝑛): if 𝑝𝑖=𝑥, no change; if 𝑝𝑖<𝑥, the person moves in the positive direction, and 𝑝𝑖 is incremented by 1; if 𝑝𝑖>𝑥, the person moves in the negative direction, and 𝑝𝑖 is decremented by 1. You can put attractions any finite number of times, and in any order you want. It can be proven that all positions of a person always stays within the range [1,𝑛], i.e. 1≤𝑝𝑖≤𝑛 at all times. Each position 𝑥 (1≤𝑥≤𝑛), has a value 𝑎𝑥 associated with it. The score of a position array [𝑝1,𝑝2,…,𝑝𝑛], denoted by 𝑠𝑐𝑜𝑟𝑒(𝑝), is ∑𝑛𝑖=1𝑎𝑝𝑖, i.e. your score increases by 𝑎𝑥 for every person standing at 𝑥 in the end. Over all possible distinct position arrays 𝑝 that are possible with placing attractions, find the sum of 𝑠𝑐𝑜𝑟𝑒(𝑝). Since the answer may be large, print it modulo 998244353. Input Each test contains multiple test cases. The first line contains the number of test cases 𝑡 (1≤𝑡≤104). The description of the test cases follows. The first line of each test case contains a single integer 𝑛 (1≤𝑛≤2⋅105). The second line of each test case contains 𝑛 integers — 𝑎1,𝑎2,…,𝑎𝑛 (1≤𝑎𝑖≤109) It is guaranteed that the sum of 𝑛 over all test cases does not exceed 2⋅105. Output For each test case, output a single line containing an integer: the sum of 𝑠𝑐𝑜𝑟𝑒(𝑝) over all possible distinct position arrays 𝑝 that are possible with placing attractions, modulo 998244353. Example inputCopy 7 1 1 2 5 10 3 1 1 1 4 1 1 1 1 4 10 2 9 7 5 1000000000 1000000000 1000000000 1000000000 1000000000 8 100 2 34 59 34 27 5 6 outputCopy 1 45 24 72 480 333572930 69365 Note In the first test case, the only possible result is that person 1 stays at 1. The score of that is 𝑎1=1. In the second test case, the following position arrays [𝑝1,𝑝2] are possible: [1,2], score 15; [1,1], score 10; [2,2], score 20. The sum of scores is 15+10+20=45. In the third test case, the following position arrays [𝑝1,𝑝2,𝑝3] are possible: [1,1,1]; [1,1,2]; [1,2,2]; [1,2,3]; [2,2,2]; [2,2,3]; [2,3,3]; [3,3,3]. Each has a score of 3, and thus the total sum is 24.解决这道题,用c++
09-25
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值