keymoon

ありがとうございます。難易度の定義を引き継いでしまっていて、同様の問題が起きているというのはまさにその通りだと思います。 解答時間の切片が変わるのはおかしいというのは明らかにそうですね。上の式では ``` μ = C·discrim·(d−r)·|σ|+ log(t_{end}) ``` としていましたが、定義の式と取っている切片の位置が異なっていました……（申し訳ない） 式 `slope * r + intercept` に当てはめる場合は ``` μ = -C·discrim·|σ|·r+(C·discrim·|σ|·d+log(t_{end})) ``` として ``` slope = -C·discrim·|σ| intercept = C·discrim·|σ|·d+log(t_{end})=log(t_{end})-slope·d ```...

解答時間の情報を利用した難易度推定についてですが、この式自体がコンテスト中の最終難易度推定を研究している時に出てきた式なので少しだけ知見を提供できる気がします。これは別 issue を建てたほうが良さそうな気がするので、現状の進展を別途書かせて頂きます。

仕様についてなのですが、C#の特性上関数やコード片を外に出すことができません。 ライブラリ的にはやはり関数なども置けたほうが嬉しいため、対応をするのであればC# scripting形式のファイルとしてライブラリを扱うのが良いのかな、とおもったりしています。 そうすると`#load "[filepath]"`で別のライブラリをincludeのように参照できます。([例](https://github.com/key-moon/Library/blob/master/src/Math/combination/Factorial.csx))

Roslynは`.NET Core`で使われているコンパイラで、`Compiler as a Service`を掲げて構文解析等のAPIを提供しているものです。 C#のプロジェクトをライブラリにする場合はこれが方法となると思いますので、検討したいです。 パッと思いつくメリット・デメリットとしては、 # メリット - C#プロジェクトでライブラリが書ける - 依存関係等をあまり意識しなくてよくなる(プロジェクトについてコンパイラがよしなにしてくれるので) - 名前空間をつけられる(追記) - テストについて、`NUnit`等のテスト用フレームワークを用いたテストの記述ができる(?)(かなりめんどくさそうではある) - 別用途への適用ができるかも(提出ファイル自動生成等) # デメリット - 関数をライブラリ化する際に、Classで包まなければいけない(ボイラープレートが増える) - 同じClass名のライブラリを作るのが煩雑になりそう(同一名前空間に同名Classが存在できないため) - 実装が多分つらい くらいでしょうか

名前空間をつけている人がVerifyできなくなるのはあまり宜しくないので、生C#への対応は必須そうですね。それとは別にscriptでの手軽さは残したいので、簡単にできそうなscriptへの対応をまずは生やそうと思います。

`list_attributes`が表すものについて、C#ではどのようにして対応するかを検討したいです。 `list_attributes`はVerifyファイルの指定などに使われています。詳しくは以下の引用と、[C++での実装](https://github.com/kmyk/online-judge-verify-helper/blob/1ca9500f6f2361bf49050f78250c05ca0bffe6cf/onlinejudge_verify/languages.py#L47)を参考にしてください。(C++では`#define`マクロの値をkey-value辞書として返すようにしています) > `list_attributes` (設定情報の辞書を返す) だけは設計が自明でないんですが、うまくやってください。 実用的には「コンパイラが clang++ でかつ ulimit に失敗している場合のみ実行をスキップしたい」などの単純な条件分岐を含む設定が可能な仕様にする必要があります。 _Originally posted by @kmyk in https://github.com/kmyk/online-judge-verify-helper/issues/116#issuecomment-579569384_ C#の`#define`はシンボルの定義のみしか行えないので、他の方法を考える必要があります。 私は[`#pragma`](https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-pragma)ディレクティブを使うのが最適かな、と思っているのですが、他に良い方法があれば教えて下さい。

> 現状の判定条件が行頭に `#load` がある程度のゆるさなので これ、実は`dotnet script`での実装をほぼそのまま取ってきてます(`load`ディレクティブとかはifディレクティブの影響を受けないので、実はこれでもロードされる) ```cs //hoge.csx #if HOGE /* #load "fuga.csx" */ #endif ``` ```cs //fuga.csx System.Console.WriteLine("fuga"); ``` `C# script`の理想的な使い方/依存関係の解決法は(たぶん)`#load filepath`でのロードなので、usingでの解決やroslynに突っ込むといったことは(scriptでない)C#プロジェクトに対応する方で行うべきなので、いい加減やります。(テストもテストプロジェクトを作ってテストを書くことでいい感じになって欲しいと思っていますが、少し煩雑なのでたしかに共存可能だと嬉しいかもしれない) それとは別に、Roslynでの`C# script`のパースは1ファイルしか受け付けられない仕様になっているので、同一の解析器に突っ込むことはできなさそうです。なので、共存させる実装はかなり煩雑になりそうだなあという予測があります。

There are warnings about dead_code for many functions in `offset.rs`. This is due to the fact that most functions in `offset.rs` are only used in `lib.rs`. I have allowed dead_code...

Understood. I am new to Rust, so your help with the basics was very helpful. While applying the suggested fix, I ran into a problem caused by the fact that...

The error caused by the conflict has been resolved. It took some time to resolve, but now this PR is back to a problem-free state. One thing I discovered in...