haskell-jp / atcoder-lang-updates #3

すみません、tf-randomも欲しいのを完全に忘れてました。PullReqを投げようかと思います。ただ、このままだとmod_poppoさんのと(アルファベット順を考えると)conflictを起こしそうなので、……GitHubの使い方に慣れていません。マージ待ちをするのが良いのでしょうか?
今日作業する予定なので、一緒に更新しますね!
すみません、よろしくお願いします。
@minorinoki_haskjp merge しました。
@gettaplacetogo tf-random も追記しました。

インストール手順を再確認しドキュメントを少し微調整しました。
また、README に色々書いてあったのでドキュメントを分離しました。
https://github.com/haskell-jp/atcoder-haskell-resources

スプレッドシートへの反映もOKです。
ちょっと気になるのは、言語アップデートの実施日が伸びるとタイミング的に GHC 8.8 がリリースされて ghcup の手順が若干変わるのではないかという・・・。
確かに間もなく出るよ、と一昨日のHIWでいうてましたね
本当に間もなくだった :sweat_smile:
https://haskell-jp.slack.com/archives/C4M4TT8JJ/p1566812233010100
でもbuggyだったら困るし、8.6.5で様子見るのもいいんじゃないっすか。
8.6.5 を利用したいんですが、ghcup のコマンドをそのまま実行した際に落ちてくるバージョンが 8.8.1 に切り替わると困るので、やっぱりスクリプトをちょっと修正して明示的に 8.6.5 を使うようにした方が安全ですね。
cabal-install も 3.0.0.0 がリリースされたので同様に修正します。
https://hackage.haskell.org/package/cabal-install-3.0.0.0
tomitake.yokosekanemo
@tomitake.yokosekanemo has joined the channel
@addokoda has joined the channel
超今更なんですけど, bytestring-to-vector ( ByteString とStorable Vector の間の変換をcopylessに行う)ってどう思います? このパッケージ自体はnaiveに考えると文字列問題系のときに気軽に使えそうでちょっと欲しいな,とも思うんですが,申請しようかは迷っております. vector-bytestring ( ByteString reimplemented as Storable Vector of Word8 …しかし性能は追いついていないので代替にはならない)とかとモジュール名被りを起こしていたり,そのあとStream Fusionで連鎖的に変換することを前提にするなら unfoldrN n ByteString.uncons でもいいような気もしたり,で……
いつまで経ってもアップデート実施されないですね…。今更 vector-th-unbox (それに伴い template-haskell) , mutable-containers, hashable (`psqueues` の関係で) くらいあった方が良さそうだと気がついたので、明日か明後日あたりプルリク投げます
vector-th-unboxunboxing-vector があればいらなさそう、というのはありますが。
今プルリク投げる前にと思って仮想環境上でやってるんですけど、 bytestring, deepseq, transformers, containers 辺りのインストール済みパッケージが含まれるのは…まあ含まれても問題ないんだからいいんでしょうか? ghcupの既定ghcバージョンが上がった時にそこらへんでエラーが起きてくれそうでもありますし。
いや、というのも template-haskell はGHC付属パッケージに含まれるため、要望パッケージに追加しないつもりでいたので。追加した方がいいんですかね?
とりあえず含めて投げますね
亀ですが bytestring-to-vector 、DL数の少なさから、今後メンテされるか不安が。どうしても添え字アクセスがしたければ unsafeUseAsCStringpeekElemOff で似たような事が可能ですし
というか普通に index 関数ありましたね。 Vector にしかないアルゴリズムをどうしても使いたい、みたいなユースケースでしょうか
というか,
ByteString
-> Vector
-(`unsafeThaw`)-> MVector
-(modifications)-> MVector
-(`create`)-> Vector
-(Stream-fusible transformations)-> Vector
-> Output, みたいなユースケースを想定してました.
bytestring-to-vector も(容易に削除可能な形で)含めてプルリク投げたので,みなさまコメントをお願いします
https://github.com/haskell-jp/atcoder-haskell-resources/pull/3
不安の声があったので,とりあえずbytestring-to-vectorを除外しました.別のプルリクにします.
別のpull requestとして投げました.
@wado このプルリクには問題なさそうなのだけ残してあるので,確認の上mergeしてもらえると嬉しいです. https://github.com/haskell-jp/atcoder-haskell-resources/pull/3
index とかで処理するなら、実のところ Vector に変換する必要は感じてなくて、GCでTLEが嫌なので入力領域を可変配列でそのまま書き換えたい、という欲求がある場合を想定してるんですよね。
@wado いま確認したら,妙なところに改行があってspec.mdのレイアウトがおかしいことになっているのですが,追加コミットをして構いませんか?
どうぞー。今日の夜確認しますね。
@gettaplacetogo
以下のPRをマージしました。ありがとうございます。
https://github.com/haskell-jp/atcoder-haskell-resources/pull/3
@wado ありがとうございます。
https://github.com/haskell-jp/atcoder-haskell-resources/pull/4

上記のPRについては、他の方の意見も聞いた方が良いということなのでまだマージしていません。個人的には以下の点が気になるのですが、みなさんご意見ありますか?

vector-bytestring とモジュール名被りを起こしている

また、実際の AtCoder の問題でこんな感じで使えそうです。というような実例とかってありますか?<@UL1HFJATE>
ちょっと待ってください.今探してます・・・.
「使える」… ByteString って,入力のタイミング以外ではほとんど使いません.だから,メリットって,使うと実行時間とメモリ使用量をO(N) [N:入力サイズ] 減少できる(精神衛生上良い)ぐらいしかないんですよね.Constant mutipleでTLE/MLEになるような問題で微妙に時間計算量を稼ぐとか,それくらいなんですよねえ.
実行時間を微妙に縮められる可能性がある,ということであれば,
https://atcoder.jp/contests/joi2008ho/submissions/3927679
とかが例になります.Storable Arrayとして入力を受け取っておいて,それをVectorとしてコピーしています.
名前かぶりは最悪PackageImportsを使うと言うことでいいんじゃないっすかね。
端から見るにそこまでするメリットがあるの、という気もしますが。
でもPackageImports使うことを周知しておけばいいと思います。
ちなみにさっきあげた点についてはさっきまで気がついていませんでした.コンテスト終わった後にC++レベルにまで実行時間縮めて悦に入るのが趣味の人間の悪いところが出た感じかなあ.[追記] 気が付いていなかったというよりは,入力時間を数ms縮めることを目的にものを考えることになんの疑いも持っていなかった.[/追記]
名前かぶりは最悪PackageImportsを使うと言うことでいいんじゃないっすかね。

方法論としては可能ですが、あまり得策ではない気がしています。
AtCoder にそのような注意点を書ける場所があれば良いのかもしれませんが、現状そうなっていないためコンテスト参加者への周知が難しいと思います。

端から見るにそこまでするメリットがあるの、という気もしますが。

僕も同じ意見です。(AtCoder の簡単な問題しか解いたことが無いので必要性に気づけていないだけなのかもしれませんが・・・)
O(入力サイズ)の高速化にしかならないのですから,もう別に入れなくてもいい感じはします.

*ちなみに*付言しておくと, vector-bytestring についてはそこまで気にしないでもいいという意見を持っています.というのも,正直, vector-bytestring には bytestring-to-vector に比べても全く使い道が見当たらないんですよね.

bytestring-to-vectorByteString と Storable Vector の代数的データ型としての違いを単純に吸収するだけなので,データ型としての定義が変更されない限りメンテナンスの必要がありません.しかし,
https://stackoverflow.com/questions/24517995/why-bytestring-is-not-vector-word8
を見るに, bytestring そのものの速度を得るには bytestring と同レベルの開発リソースが注がれる必要がありそうですが,メンテナンスは活発ではなさそうです.
ただ,逆にいうといきなり開発が活発になってStackageに vector-bytestring が導入されて bytestring-to-vector が除外されるレベルで vector-bytestring がポピュラーになるなんて未来もないではない(本当に?)し,最悪遊びがしたければdata型の書き換えを手でやっても良いんですよね.
なんか、こう、 VU.unfoldrN n BS.uncons と書くたびに生じる「無駄なコピーをしているときの強迫的な罪悪感」みたいなもの、から離れて競技に対する集中力を取り戻したい、みたいな動機が近い気がするので、正直、時間が経てば経つほどこのパッケージを強く推すのには躊躇が生まれてきてしまっています。
@a0 has joined the channel
言語アップデートの作業が始まったみたいです。(作業シートが追加された)
https://docs.google.com/spreadsheets/d/1PmsqufkF3wjKN6g1L0STS80yP4a6u-VdGiEv5uOHe0M/edit#gid=0
提案者も乗り気ではなくなっているし,賛同者もいないし,作業が開始した後に書き換えをするのはよほどのことがないとよくない気がするので, bytestring-to-vector のpull requestをcloseしようと思っているのですが,大丈夫ですよね?
了解しました。スプレッドシートの編集自体は作業が完了していなければ大丈夫?っぽい感じがします。(ちょくださいさんのツイート等から推測)
https://twitter.com/chokudai/status/1192261237049946112
オッケーです、closeします。それはそれとして、私も先ほど行った会話で、まだ一応書き換えが許されてそうな感じは受けました。
https://twitter.com/fine_sugar_hill/status/1193876967918948352?s=21
https://twitter.com/chokudai/status/1193883647889137665?s=12
そうなんですね!情報ありがとうございます!
近々もう一度手元でインストール方法を最終確認する予定なので、手順に変更があったら修正しておきます。
いまってなんかパッケージ群の中にPriority Queueとかって入ってましたっけ.まあIntMap (Sequence a)でいい気はしますが
あ、はいってました
@baavv914 has joined the channel
かなりの確率でインストールできないと・・・。大丈夫かな:thinking_face:
https://twitter.com/chokudai/status/1204660793410637824
Haskellの作業が開始したみたいですね。ライブラリ欄が空なのでPythonと同様後回しにしているように見えます。