ご質問ありがとうございます。
運搬の発生確率は注文発生地点と注文目的地点それぞれで判定しており、双方に影響します。
Q: There is a description in the map information section that "the higher the population, the higher the probability of transportation requests occurring”.
Which one of the following do you mean by “the probability of transportation requests occurring”?
1. Probability of being selected as an order generation position
2. Probability of being selected as an order destination position
3. Probability of being selected as either an order start position or an order destination position
A: Thank you for your question. The probability of transportation requests occurring is determined at each of the order start position and the order destination position, and it affects both.
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
(1)問題文が誤っていたため、修正しました。
(2)ジャッジを修正しました。
ご確認宜しくお願い致します。
Q: I found something that seems to be a malfunction of the judge. Could you check the following points?
1. When multiple nanogrids are specified for “input and output format 2”, it seems that the nanogrid information for “input and output format 3” is supposed to be obtained in the specified order. However, the order of nanogrids seems to be changed and be notified to the order that the nanogrids installed in the power demand area become the first order.
2. It is recognized that the amount of electricity stored in the nanogrid at the start point of disaster response is usually the one at a randomly determined time for response, but even if a RB with a sufficient amount of electricity is placed, it will be 0 at the start point of disaster. It seems that acc_stat-> grid_cap [grid_data-> grid_id] on lines 2874 and 2909 of judge_B.cpp should be acc_stat-> grid_cap [grid_data-> vertex].
A.Thank you for pointing out.
(1)the statement of problem B has been updated.
(2)the judge system of problem B has been updated.
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
ジャッジを修正しました。
Q.At the time of submit, are the values of pw^actual and pw^exceed at t = 0 excluding the first day not 0 but the values based on the last time of the previous day?
A.Thank you for pointing out. The judge program is corrected. Please download the latest version of the program.
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
ジャッジを修正しました。
Q: When calculating S_env, η_FE is not divided by 1000, is this the correct behavior?
A.Thank you for pointing out. The judge program is corrected. Please download the latest version of the program.
ご質問ありがとうございます。
災害テストが開始されない条件は、いずれかの避難所にナノグリッドが置かれていない場合となります。
災害対応はいずれかのナノグリッド、避難所、または電力需要地で系統からの電力購入を行おうとしたターンで終了します。
Q: In order to terminate the program without waiting for input, please specify the conditions when disaster response "will not start" or "will end" in the middle.
A: Thank you for you question.
The disaster test "will not start" when the nanogrid is not placed at any of the shelters.
Disaster response "will end" with the turn you try to purchase power from your grid at any nanogrid, shelter, or power demand area.
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
ジャッジを修正しました。
ご確認宜しくお願い致します。
Q: Thank you for the answer and correction for my previous question related to alpha^trans_undelivered and alpha^trans_canceled. However, it seems that the judge program in the toolkit (ver. 2022.01.18) has not been corrected. Could you please check the program again?
A: Thank you for pointing out. The judge program is corrected. Please download the latest version of the program (ver. 2022.01.21)
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
ジャッジを修正しました(1000で割るのが正しい挙動となります)。
ご確認宜しくお願い致します。
Q: When calculating η_FE with the judge program, the score at the time of power generation is significantly worse than at the time of purchase because it is not divided by 100. Is this the correct behavior?
A: Thank you for you comment. The judge program is fixed (dividing by 1000 is the correct behavior).
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
前半に関しましては、ジャッジの不具合です。
ジャッジを修正しましたので、ご確認宜しくお願い致します。
後半に関しましては、同一のパラメータとなります。
問題文の方を修正しましたので、ご確認宜しくお願い致します。
Q: I have a question about work machines.
(1) Regarding the process of "charge_to", I think that "V_work_discharge" is applied to the upper limit of discharge, but "V_work_charge" is applied now. Is this a problem of the judge program?
(2) In the problem statement, the input example is described as "P_work_charge", "P_work_discharge", and in the explanation part, it is described as "V_work_charge", "V_work_discharge". Is it okay to recognize that these are the same parameters?
A: Thank you for your comments. (1) For the process of "charge_to", "V_work_discharge" is applied. The judge program is fixed according to the issue. (2) They are the same parameters. Problem statement is corrected.
ご質問ありがとうございます。
前時刻での\Delta_PV,t^actual - \Delta_demand,t^actualの値となります。
（変数は手順１をご参照下さい。）
Q: The power balance (pw^actual_i) given in the “input and output format 3” does not appear in the power supply and demand details, but at what point and what is the standard for calculating balance value?
A: Thank you for your question. It will be the value of \Delta_PV,t^actual - \Delta_demand,t^actual at the previous time. (Refer to Energy balance in detail: step 1.)
A.ご指摘頂きましてありがとうございます。
ご不便おかけして申し訳ございません。
問題文に合わせてジャッジを修正しました。
ご確認宜しくお願いします。
Q: In the problem details-query details-score information, it is stated that alpha^trans_undelivered and alpha^trans_canceled are entered in this order, but in the judge program, alpha^trans_canceled and alpha^trans_undelivered are entered in that order.
Which one is correct?
A: Thank you for pointing out. We apologize for any inconvenience.
We corrected the judge according to the problem statement.
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
ジャッジの出力に誤りがあったため、ジャッジを修正しました(問題文のとおりに発電量が出力されます）。
Q: I have a question about pw^FE, which is input as the fuel engine power generation amount at the previous time in the “input and output format 3”.
In the judge program (2022.01.13 version), the value output as the amount of power generation per FE step in the previous step multiplied by the fuel consumption rate * 100 is input as pw^FE.
Is this the correct behavior?
A:Thank your for pointing out the issue.
We are sorry for your inconvenience.
We have corrected the judge program because there was an error in the judge's output.
With this correction, the amount of power generation will be output according to the problem statement.
ご質問ありがとうございます。
move 命令の行先頂点として有効な頂点は以下の通りです。
1. EVがいずれかの頂点上に位置する場合(u == v & dist == 0) : グラフ上で頂点uと辺で結ばれた頂点。
2. EVが辺の上に位置する場合(u != v & dist > 0) : u または v。
Q: In “Input and output format 3-vehicle”, can vertices that are not adjacent to the current vehicle position be specified as the vertices to move?
A: Thank you for your question.
The vertices that are valid as the destination vertices of the move instruction are as follows.
1. If the EV is located on one of the vertices (u == v & dist == 0): The valid-destination vertices are vertices connected to the vertex u on the graph by an edge.
2. If the EV is on an edge (u != V & dist> 0): The valid-destination vertices are the vertex u and v.
ご質問ありがとうございます。
ご指摘いただいたような状態が発生しうることを確認致しました。このような場合、各作業注文の実行可能性を個別に判断した上で作業を実行するかどうかを決定していただければと思います。
Q: Is it a specification that there is a work demand that is clearly unattainable (eg, work demand at vertex No.7104 on day 1 of C.in)?
A: We have confirmed that the situation you pointed out may occur. In such cases, we would like you to judge the feasibility of each work order individually before deciding whether to perform the work.
ご質問ありがとうございます。作業需要を達成した作業需要地では、最小作業時間による制約でWAにはなりません。
Q: ・Once the work is started, it is necessary to continue the work for the specified number of steps or more in the minimum work time, otherwise it is WA. (Problem details-work)
・ If you try to do more work in the work demand area where the work demand is achieved, it is WA. (Answer to the question posted on 2022-01-13 21:56:51)
However, what happens if the difference between the amount of work demand and the cumulative total of work performed so far is less than the number of steps specified in the minimum work time?
A: Thank you for your question. In the work demand area where the work demand is achieved, WA is not achieved due to the constraint of the minimum work time.
ご指摘ありがとうございます。
過去にintのオーバーフロー対策で設定した制約条件となります。
通常の解答では、越えることはありません。
Q: As a constraint of the “input and output format 1”, 0 ≤ Ctotal ≤ 1000000000 is described.
However, it seems that Ctotal is not a response value in the “input and output format 1” but a value calculated by the judge after the output of “input and output format 2” is completed.
Also, due to restrictions on other values, it seemed that the total cost would be within this range no matter what arrangement was made.
What is the intention of the description?
A:Thank your for pointing out that.
This constraint was set to prevent int overflow.
The usual answer will not exceed this limit.
ご質問ありがとうございます。
WAとなります。
Q: Is it WA if you try to do more work in the work demand area that has achieved the work demand?
A: Thank you for your question. Yes, it is WA.
ご質問ありがとうございます。
WAとなります。
Q: In the “Input and output format 3”, if a "work" query is issued in a step included in the time interval when t work availability (A_i^work) is 0, is it WA?
A: Thank you for your question. Yes, it is WA.
ご指摘頂きましてありがとうございます。
ご不便おかけして申し訳ございません。
ジャッジとツールキットを再修正しましたので、ご確認宜しくお願いします。
Q. Thank you for correcting the judge program. Regarding to the correction of judge program (line 3660) in (2), I think that the charge amount (of work machine) is smaller than expected because the value is rounded down to integer after dividing by 100 and then multiplying by eta (I think it will make the value 0 if the charge is less than 100). It is probably a bug. Could you please fix the judge program again?
A. Thank your for pointing out the issue.
We are sorry for your inconvenience.
We corrected the judge program and the toolkit of problem B according to the issue (13th Jan 2022).
ご質問ありがとうございます。
Q.作業機械への充電は何から行われますか？
A.EVCを介して充電されます。
Q.作業地点のEVCが必要になりますか？
A.必要です。
Q.作業地点のEVから直接充電することは可能ですか？
A.作業地点にEVCが存在する場合、バッテリーがなくても作業機械に充放電が可能です。(EV-EVC-作業機械のパスで充放電可能です。)
Q.系外から購入した電力を使うことも可能ですか？
A.可能です。
Thank you for your questions.
Q: What is the source of charging the work machine?
A: It is charged via EVC.
Q: Do you need an EVC at your work site?
A: Yes, it is necessary to install EVC at a work site.
Q: Is it possible to charge directly from the EV at the work site?
A: If EVC is present at the work site, the work machine can be charged and discharged without a battery. (Work machine can be charged and discharged with the path of EV-EVC-work machine.)
Q: Is it possible to use electricity purchased from outside the system?
A: Yes, it is.
色々とご指摘頂き、ありがとうございます。
ご不便おかけして申し訳ございません。
(1) ジャッジの不具合です。ジャッジを修正しました。
(2) 問題文が正しいです。ジャッジを修正しました。
(3) ジャッジが正しいです。チェックされません。問題文に反映しました。
(4) Δ_tmpに合算されるという理解で合っています。問題文に反映しました。
(5) ジャッジの不具合です。ジャッジを修正し、問題文も一部修正しました(L^FE_i,tの定義とalpha^ele_FE,alpha^env_fuelの制約)
Q: I have questions about the problem statement and judge tool.
(1) In the input and output format 3, it seems that the amount of electricity stored in the work machine is increased by +2 and output, so I think it is probably a problem (line 3108).
(2) The increment when charging the work machine is supposed to be the value multiplied by η according to the problem statement, but it seems that it is the value divided by η in the judge tool (line 3661). which one is correct?
(3) The condition that Δ_actual_PV <pw_excess described in the energy balance in detail in the problem statement does not seem to be checked by the judge tool. Which is correct?
(4) Regarding the energy balance in detail in the problem statement, the handling of power generation by FE is not described. Is it correct to understand that it is added to Δ_tmp?
(5) The judge tool does not seem to use the values of η_FE_min, η_FE_max and C_FE_fuel. Is this correct?
A: Thank your for pointing out the issues. We are sorry for your inconvenience.
(1) It is a bug of the judge tool. The judge program is updated (12th Jan)
(2) The problem statement is correct. The judge program is updated (12th Jan)
(3) The judge program is correct. The condition was not checked. The problem statement is modified and updated.
(4) It is correct with the understanding that it is added to Δ_tmp. The problem statement is modified and updated.
(5) This is a malfunction of the judge program. The judge program is updated and the problem statement is modified and updated. (definition of L ^ FE_i, t and restrictions of alpha ^ ele_FE, alpha ^ env_fuel)
ご質問ありがとうございます。
N_dayの中から一様ランダムに選ばれた日付のものが参照されます。
どの日付かはコンテスタントには非公開となります。
Q: On what date is the predicted energy demand and predicted amount of solar radiation referenced during the disaster response test?
A: Thank you for your question. The date selected randomly from N_day is referenced. The selected date is non-disclosure information.
ご指摘ありがとうございます。
ご不便おかけして申し訳ございません。
不要な(使用しない)パラメータとなります。
入出力形式の変更は混乱を招きかねないので、読み捨てて頂ければと思います。
宜しくお願い致します。
Q: In the query details, it is stated that there is an alpha^env in the response by the query "score", but this value has not been input by the judge program. And, it does not appear in any of the scoring methods in the formula in the problem page.
What is this value?
A: Thank you for your advice. We apologize for any inconvenience.
It is an unnecessary parameter.
Since changing the input and output format can cause confusion, so please disregard it.
Thank you for your understanding.
ご指摘ありがとうございます。
テストケースを修正しました。
ご確認宜しくお願いします。
Q: Isn't the edge with the same start and end IDs in the second test case?
As a result, the function valid_charge returns false, and the judge's result become RE.
A: Thank you for pointing out. We corrected the testcase according to the issue (11th Jan).
ご指摘ありがとうございます。
ジャッジを修正致しました。
ご確認宜しくお願いします。
Q: I think the judge fall when the number of consecutive uninterruptible days exceeds N_day. Is that correct?
A: Thank you for your point. We corrected the judge program according to the issue (11th Jan 2022).
ご質問ありがとうございます。
連結グラフとなります。
Q: Is the graph given in the section "map information" a connected graph?
A: Yes, we provide map information as a connected graph.
What is "order capacity"? Cap^V_pop does not appear anywhere else within the statement, nor does the keyword "order capacity".
Thank you for your question.
The "order capacity" or Cap^V_pop represents the numbers of maximum order capacity of the vehicle (it also may be called as population capacity if the order to be carried/delivered is a person) .
For example, Cap^V_pop = 10 means that the vehicle can carry up to 10 orders.
1. コンテスタントが扱う頂点番号xは 1 <= x <= V だと思いますが、demand [day] [id]クエリとshelterクエリでのジャッジからコンテスタントへの出力では 0 <= x < V になっていないでしょうか？
2. ナノグリッドでのターン毎の電力供給の処理(valid_end_time())において、FEはコンテスタントの出力に依らずtype_FE = 1を使用するようになっていないでしょうか？
ご指摘ありがとうございます。
ご不便おかけし申し訳ございません。
1. についてジャッジコードにて 0-index と 1-index の取り違えが生じていたために発生した食い違いと確認できました。
また、2. についても状況を確認致しました。
11/29 現在のジャッジコード / toolkit では両方とも修正済みです。
Q:
1. I think the vertex number x handled by the contestant is 1 <= x <= V, but the judge-to-contestant output in the demand [day] [id] and shelter queries is 0 <= x <V. Isn't it?
2. Isn't FE supposed to use type_FE = 1 regardless of the constant output in the processing of power supply per turn (valid_end_time ()) in the nanogrid?
A: Thank you for your comments.
We apologize for your inconvenience.
Regarding to question 1., it was confirmed that there was a discrepancy caused by the mistake of 0-index and 1-index in the judge code. We also confirmed the situation regarding question 2.
Both issues have been fixed in the current judge code and toolkit on November 29th.
ご質問ありがとうございます。
問題Aの範囲では P^EVC_in = P^EVC_out となります。
Q: Is P^EVC_in equals to P^EVC_out ?
A: Thank you for your question.
For the problem A, yes, the P^EVC_in equals to P^EVC_out.
ご質問ありがとうございます。
問題Aの範囲では P^V_charge = P^V_discharge となります。
Q: Is P^V_charge equals to P^V_discharge ?
A: Thank you for your question.
For the problem A, yes, the P ^ V_charge equals to P ^ V_discharge.
ご指摘ありがとうございます。
ご迷惑をおかけし申し訳ございません。
11/29 現在で、更新版のtoolkit がアップロードされていることを確認致しました。
Q: It is a toolkit released as of 11/27, but if you look at the update date and time in the zip, 11/18 is the last update.
I was notified of the toolkit update on November 26th, but is the latest version currently available?
A: Thank you for your advice.
We apologize for your inconvenience.
As of 29th November, we have confirmed that the updated version of toolkit has been uploaded.
ご指摘ありがとうございます。
ご不便おかけし申し訳ございません。
事象の発生を確認致しました。
現在修正作業中です。
Q: I found some behavior related to the cost penalty of the score calculation formula in the judge program in the toolkit. When facilities is installed with excess cost, negative integer overflows and about +2 ^ 31 points is added.
I think this is an unsatisfied behavior, so please check the program including the program used in the actual contest.
A:Thank you for your advice.
We apologize for your inconvenience.
We have confirmed the situation.
Currently, we are now in the process of correction.
回答ありがとうございます。 1 つ前の質問と同じ主張を繰り返します。
1. ジャッジプログラムを自身の提出コードでシミュレーションすれば、実行中入力を受け取ってから command submit ... 前の間で一部挙動を実際に特定できています。（すべてを特定できるのかはわかりません）
例えば、
```
srand(1);
int Day_acc = rand() % N_day;
int T_acc = rand() % T_max;
```
2. T_acc などがランダムではない
testcase A B C D は T_max がいずれも 7500 で、 T_acc がいずれも 886 です。 T_max が同じであっても T_acc はバラバラになるのが、問題文中記載の `ランダムに選択される` ということではないですか？（command submit ... の挙動が特定できるとは別の指摘です）
ご指摘ありがとうございます。
非公開のseed値を読み込むよう、ジャッジを修正いたしました。
Q: Thank you for your response. I may repeat the same claim as in the previous question.
1. By simulating the judge program with its own submit code, we can identify some behavior between receiving the running input and before command submit .... (I don't know if I can identify everything)
for example,
`` ```
srand (1);
int Day_acc = rand ()% N_day;
int T_acc = rand ()% T_max;
`` ```
2. T_acc etc. are not random
Testcase A B C D have both T_max of 7500 and T_acc of 886. Even if T_max is the same, T_acc will be disjointed, isn't it the `randomly selected` described in the problem statement? (It is a different point that the behavior of command submit ... can be identified.)
A: Thank you for your advice.
The judge is fixed to read the disclosed seed value.
command submit ... 中の乱数 seed が 1 固定なため、 command submit ... 前に乱数や乱数に基づく結果や振る舞いを知ることができてしまいませんか？
また、 testcases A B C D はいずれも T_max が 7500 なため、 T_acc が同じではありませんか？ランダムになっていないのではないでしょうか？
ご指摘ありがとうございます。
1. ジャッジによる採点中の場合：
submit 以前、test を行っている間のseed値は1ではないため、submit 時の挙動を推定することは困難かと思います。
2. システムテスト時：
コンテストトップページのルールの項に記載があります通り、システムテストはプリテスト時とは
異なるテストケースが使用されます。乱数による振る舞いは各種パラメータの値によって変動するため、
システムテスト時の挙動を推定することは困難かと思います。
T_acc についての回答は上記2. の回答をもって代えさせていただければと存じます。
Q: Since the random number seed in submit command is fixed to 1…, isn't it possible to know the random number or the result or behavior based on the random number before command submit ...?
Also, testcases A B C D all have T_max of 7500, so aren't they the same to T_acc? Isn't it random?
A: Thank you for your advice.
1. During the judge is scoring:
Before executing submit command, the seed value during the test command is not 1, so it may be difficult to estimate the behavior at the time of submit.
2. During system test:
As stated in the rules section on the top page of the contest. The system test and pretest use different test cases. Since the behavior by random numbers fluctuates depending on the values of various parameters including T_acc, we think it is difficult to estimate the behavior during system testing.
We would like to replace the answer about T_acc with the answer in 2. above.
ご質問ありがとうございます。
申し訳ありません。
ご指摘の通り、alpha_fuel_env と alpha_buy_env の記述に不整合がありました。
正しくは、
0.00025 <= alpha_fuel_env <= 0.0012
0.0005 <= alpha_buy_env <= 0.0025
となり、丸めの影響で数字自体にも修正があります。
問題文を修正いたしました。
Q: Regarding the restrictions of α_fuel_env and α_env_buy
0.0008 ≤ α_fuel_env ≤ 0.00035 [float]
0.0015 ≤ α_buy_env ≤ 0.0006 [float]
In this description, the left and right magnitude relations do not match.
The following,
0.00035 ≤ α_fuel_env ≤ 0.0008 [float]
0.0006 ≤ α_buy_env ≤ 0.0015 [float]
is it correct, or the following,
0.0008 ≤ α_fuel_env ≤ 0.0035 [float]
0.0015 ≤ α_buy_env ≤ 0.006 [float]
is it correct?
Thank you.
A: Thank you for your question.
We are very sorry for inconsistency in the description.
As you pointed out, the correct constraints for alpha_fuel_env and alpha_buy_env are as following.
0.00025 <=α_fuel_env <= 0.0012
0.0005 <= α_buy_env <= 0.0025
In addition, the bug caused by number rounding was also fixed.
The problem statement has been corrected and updated.
ご質問ありがとうございます。
ご指摘の通り、alpha_env_grid は alpha_env_buy のことです。
問題文を訂正いたしました。
Q: In details of “Score related information (score)”, alpha_env_grid on the 6th line, is it alpha_env_buy?
I feel that the definition of the environmental score also confuses the two.
A: As you pointed out, the alpha_env_grid should be alpha_env_buy.
The problem statement has been corrected and updated.
ご質問ありがとうございます。
ナノグリッド 0 個、EV 0 台のパターンは許容されます。
Q: Is the behavior undefined when the number of nanogrids or the number of EVs to be installed is 0?
A: Thank you for your question.
A pattern of 0 nanogrids and 0 EVs is acceptable.
ご指摘ありがとうございます。
状況を確認致しました。
確かに現在、2つ返すはずのパラメータを4つ返してしまっている状態です。
入出力形式記載のパラメータは後ろ2つになります。
ジャッジ、toolkitを修正いたしました。
Q: In the problem statement, if you send the query of asset RB [rb_id] in the input and output format 1, two numbers will be returned, but if you do the same with the judge program, four numbers including charge / discharge speed will be returned....
Which is correct in the actual contest?
A: Thank you for your advice.
We have confirmed the situation.
The correct is that Judge program should return only two parameters described in the input and output format 1.
Judges program and toolkits have been fixed.
a9ua1i0n
rabot
siman
terry_u16
Terezi