We appreciate the reviewer for recognizing our original approach, many useful suggestions as well as encouragement for future study. We will address some misunderstandings below.

The definitions are unusual and non-standard

To realize our approach, we indeed need to introduce unusual definitions. But since these definitions are helpful for the understanding of our approach, we believe that they are not a weakness of this work.

One of the main exciting things about automated mechanism design is its use in solving the wide-open problem of revenue-maximizing DSIC auction design. There are many auction design benchmark problems in the papers the authors cite (GemNet, RegretNet, AMA) but the authors choose to compare to none of these benchmarks.

In this work, we do not focus on auction design (Please refer to our general responses). Therefore, we do not compare multi-player auctions benchmarks.

I think any claimed competitor to GemNet must tackle some of those problems shown in the GemNet paper

We did not mean to claim a competitor to GemNet, though the menu mechanism approach is inspired by GemNet. Instead, we only focus on the mechanism design problems that do not face the menu compatibility issue, which excludes auction problem. We compare our results with baselines those originate from auction design, mainly because these approaches can be transplanted into our setting with simple modifications.

The main weakness they point out with GemNet is that it requires a costly post-processing step on a discrete grid.

Actually, we think that (though not pointing out directly) the main weakness of GemNet is that its menu representation needs a discretization on allocation space, which is costly and will result in a suboptimal performance when allocation space becomes high-dimensional. This issue is called "curse-of-dimensionality" in machine learning literature (Please refer to our general responses). Our both experiments also demonstrate this phenomenon.

Although they don’t deal with it in experiments, in principle their method can deal with supply constraints of the sort that show up in auctions. This is discussed quite briefly in section F.1 (I think it belongs in the main body or at least should be mentioned more prominently as it is very important).

We put this discussion in appendix because our primary focus is not auction setting. We believe that auction is an important problem so we make some attempts to include auctions within our model and try to answer the following question: Can this model express auction problems in an indirect way? Above all, we believe that this discussion is a by-product of this work.

Also, side note — equation 13 seems not to “type check” — a vector proj(x, X) is subtracted from a scalar

Thanks for pointing out this typo. It should be $v_0(proj(x, \mathcal{X});t) - M \cdot dist(x, \mathcal{X})$. We will fix this typo in the next version.

Thank you for your enthusiastic discussion. We will clarify some issues in this response.

• The "curse of dimensionality" of GemNet

We politely mention that the reviewer might have some misunderstanding about what we meant "discretization on allocation space". Though GemNet does not directly discretize the allocation space with menus, the insight shares the commonality with MenuNet, which discretize the allocation space by finite menus for the only one player. We're confident that our understandings about GemNet (its discretization nature on menus) is correct.

To clarify this point, we will take our first experiment as an example ($n=1$ buyer and $m$ items). In this case, the network will not receive any input, and GemNet is equal to MenuNet. Therefore, the output of GemNet's network can be seen as separated variables. In GemNet's network representation, the output of network is represented as $K$ menus on the $m$-dimensional allocation space. (In their original paper $K$ is chosen as 1000 when $m>5$ and 300 when $m\le 5$) We think that such representation intrinsically discretizes the allocation space with $K$ menus. However, there have $2^m$ deterministic menus, which becomes exponentially large when $m$ increases. Besides, each deterministic menu among $2^m$ deterministic menus is indispensable in the SJA mechanism (if we translate SJA mechanism into menu mechanism), which is conjectured to be optimal until $m=10$ (please refer to Reviewer sVor's review). Therefore, at least in the one player, $U[0,1]^m$ setting, GemNet faces the problem of "curse of dimensionality". It is also natural to imagine that the "curse of dimensionality" issue will not disappear in multi-players setting.

• The position of this work

For this work, we did not focus on performing better performance on auctions problem. Our original goal lies in the right structures of automation approaches of mechanism design, which is more theoretical than empirical. We think we are one step closer to the answer, through delving into the functional perspectives rather than point-wise perspectives of menu mechanisms. It's acceptable that we add some assumptions even these assumptions exclude auction settings.

• The future of revenue-maximizing auction

We believe that revenue-maximizing auction is an interesting mechanism design problem, with unique structure (menu compatibility) compared with many other mechanism design settings. Though a post-processing mixed-integer program can resolve menu compatibility issue, we still believe that menu mechanism is not the right approach for efficient auction design. Yet it's still hopeful that some approach could perform better on larger settings compared with many current state-of-the-arts. Indeed we have some ideas about designing revenue-maximizing auctions under menu compatibility constraints that does not require discretization on allocation space or mixed-integer programming and thus has potential to perform well on large instance. We believe these works will be independent of this submission.

We appreciate the reviewer for suggestions on the organization of Section 4, more experiments as well as grammatical errors. We will address the confusions about the proof below.

On line 1018, it’s unclear what is meant by treating $x^d_i$ and $p^d_i$ as free variables $x_i$ and $p_i$.

On line 1022, I’m unsure what is meant by saying $\tilde{u}_i(t)$ is constant with respect to $x_i$ and $p_i$. By definition, $\tilde{u}_i(t)$ depends on $x^d_i$ and $p^d_i$, so it doesn’t appear to be constant with respect to these terms.

The statements between line 1018 to line 1029 are only the insight why we construct $p^f_i(x_i, t_{i})$ as the form in line 1032. Removing them does not affect the correctness of this proof.

The statements actually assume that we can replace $x^d_i$, $p^d_i$ with $x_i$, $p_i$, respectively.

In Equation (5), the supreme is taken over $t_i$, but the line before mentions $p_i$ should be minimized.

Since we want the inequality in Equation (4) always hold and take equality sometimes, then, we should choose $p_i$ such that $p_i$ is exactly the form in line 1032. The form of $p_i$ in line 1032 is also the minimum value such that Equation (4) always hold, because if $p_i$ get smaller, then by definition of supreme, there will be some $t_i$ that violates the inequality in Equation (4).

The paragraph titled “Prove the first statement” on line 1049 is also difficult to interpret. Since $\tilde{u}_i(t)$ is a function of $x^d_i$ and $p^d_i$, whether $\tilde{u}_i(t)$ is convex should depend on the properties of $x^d_i$ and $p^d_i$ (e.g., whether or not they themselves convexity).

We do not need to prove $\tilde{u} _i(t)$ is convex. What we should prove is that $p^f _i(x _i;t _{-i})$ is convex w.r.t. $x_i$. Our original proof says that, since $p^f _i(x _i;t _{-i})$ has the form in Equation (5), which is exactly the Fenchel conjugate form, then it is convex w.r.t. $x_i$ by nature.

We appreciate the reviewer for suggestions on the missing baselines and beta distribution settings. We will address some misunderstandings in this response.

About the problem studied in this paper

The reviewer seems to misunderstand that our paper focus on auction design. Actually, auction is not our focus, and unfortunately our model can not explicitly express auction problems (please refer to our general responses), and that's the reason why we do not conduct multi-bidder auction experiments

To fully demonstrate PFM-Net's advantages over regretnet, it would be beneficial to include tests with multiple agents and items (e.g., n,m≥2)

Our second experiments consider a multi-bidder, multi-item setting, though this setting is not a standard auction setting.

The similarity between PFM-Net and RegretNet

The reviewer thinks PFM-Net shares similarity with RegretNet. Actually, PFM-Net is far different from RegretNet due to following reasons.

• RegretNet is intrinsically untruthful (because the training process needs to minimize regret), while PFM-Net is intrinsically truthful (because PFM-Net is menu-based, and menu mechanism is intrinsically truthful). (Please refer to our general responses)
• RegretNet faces the problem of instability in finding misreport when the problem size becomes large, which we believe the main reason is that finding misreport is a high-dimensional non-convex optimization problem for RegretNet. In PFM-Net, the pricing rule is designated to be convex, so in the "computing the allocation" step, we face a convex optimization problem, and thus can be efficiently computed.

The truthfulness of PFM-Net

The reviewer seems to misunderstand the potential exact truthfulness of PFM-Net, and think PFM-Net might be untruthful in some cases.

The word potential arise from the rationality assumption about computing allocation: we assume that the mechanism/player has the ability to choose the allocation that maximizes players' utilities. (We need this assumption because the allocation set is an continuous set.) Under this reasonable assumption, PFM-Net is exact truthful.

In experiments, we find the optimal allocation by convex optimization that maximizes players' utilities. In this sense, we believe that testing the regret of PFM-Net is unnecessary since it is already truthful.

Thank you for the clarification. While your explanation resolves my concerns regarding the similarities and differences between this proposed approach and RegretNet, my other issues remain unaddressed (hence my decision to maintain my scores). To reiterate:

W1: The baselines are still missing in the paper!

W2: While it’s acceptable that your focus is not on multi-buyer auction settings, this needs to be clearly stated. However, note that if your approach only works for a specific mechanism design problem and cannot be extended to auction design, the contributions become quite narrow.

W3: The paper's writing could be significantly improved.

For these reasons, I will maintain my scores.

That said, I think this is a great idea overall. The biggest strength of the proposed approach is that it eliminates the need to enumerate and select from all possible menu options (as required by methods like RochetNet, MenuNet, AMANet, GemNet, etc.) and instead computes the allocation by solving a convex optimization problem. To strengthen this paper, I recommend the authors the following:

1. Focus on the strengths for the single-item setting. For example, in cases with $k > 20$ items, enumerating the deterministic menu ($2^k$) becomes intractable. Your approach has the potential to excel here.

2. Improve clarity and readability to make the paper more accessible to the audience.

3. Since there isn’t new theory, focus on experiments to demonstrate your approach’s superiority. For instance:

   • Include experiments showing that your approach can recover optimal solutions for known settings (both deterministic and with lotteries).
   • Provide experiments where your approach outperforms existing methods.

Thanks for the reviewer's comments. We will address some misunderstandings of this paper.

The problem being solved in this paper is a trivial extension of the MenuNet (Shen et al., 2018) to multiplayer setting with individual-wise allocation constraints.

The extension is not trivial. Even in the 1-buyer case, PFM-Net is far different from and performs better than MenuNet. (Please refer to our general responses.)

This paper, however, drops the only challenge of generalizing MenuNet to the multi-bidder setting

We indeed do not resolve the challenge of menu compatibility, but menu compatibility is not the focus of this paper.

However, there is one challenge that is missed in all automated mechanism design literature, which is called "curse of dimensionality''(Please refer to our general responses). MenuNet and GemNet suffer from curse of dimensionality inevitably, while our approach can escape from it. Both experiments validate this statement.

Please properly mention the key result of MenuNet in your second paragraph, and explicitly compare your approach with theirs.

GemNet, as an extension of MenuNet, degenerates to MenuNet when there is only one player. Therefore we believe that comparing with MenuNet separately is unnecessary, as long as we compare with GemNet.