すでに、学習用の大量のデータを用意しなくても、学習だけで強くなるプログラムは発表されていて、たった数日でプロに圧勝したAlphaGoよりも強い AlphaGo Zero が発表されている。 今回の発表は、チェスも、将棋も、囲碁も、それぞれのゲームのルールなどを用意するだけで、同じアルゴリズムで(たぶん同じプログラムでかつ同じハードで)ゼロから学習して強くなってしまうことに成功したようだ。
![世界最強のチェス・将棋・囲碁プログラムのAlphaZero | Webシステム開発/教育ソリューションのタイムインターメディア](https://cdn-ak-scissors.b.st-hatena.com/image/square/8c6921472d09ee1bfc0e71d2b32cae6673c22aa8/height=288;version=1;width=512/https%3A%2F%2Fwww.timedia.co.jp%2Fwp-content%2Fuploads%2F2022%2F03%2FAlphaZero_LearningGraph.png)
$ git rebase master Applying: Add GeneratedColumn Applying: Add EnumerateGeneratedColumns Applying: Use EnumerateGeneratedColumns to CreateQuery Using index info to reconstruct a base tree... M AAA/BBB/Summary.cs Falling back to patching base and 3-way merge... Auto-merging AAA/BBB/Summary.cs CONFLICT (content): Merge conflict in AAA/BBB/Summary.cs Failed to merge in the changes. Patch failed at 0
問題 gitで誤ったブランチに対して行った変更を正しいブランチへ移す(cherry-pick編) では一度コミットしてしまった変更を別のブランチへ付け変える方法について紹介しました。 この例では誤ったブランチに対して一度コミットしてしまいましたが、 コミットする前に誤ったブランチで作業していたことに気付くこともよくあります。 例えば以下のような状態です: $ git branch master * topic-y $ git branch topic-x master $ $EDITOR # git checkout topic-x を忘れて作業してしまった。 $ git status # On branch topic-y # Changed but not updated: # (use "git add <file>..." to update what will be commit
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 gitでマージ作業を中止して元の状態に戻すではマージに際してよくある問題の対処方法について紹介しました。 運用をきちんとしていればトピックブランチのマージでコンフリクトが発生することは稀です。 しかし稀とはいえコンフリクトが発生するときは発生します。 例えば新機能Xの実装を始めるとしましょう: $ git checkout -b topic-x master $ $EDITOR $ git commit -am 'Fix outdated comments' $ $EDITOR $ git commit -am 'Revise existing API' $ $EDITOR $ git commit -am 'Implement X' o---o---o <- topic-x / o---o---o <- m
gitでは様々な方法でコミットログを書き換えることができます。 その一例として誤ったブランチに対して行った変更を正しいブランチへ移す方法を紹介します。 問題 これまで「新機能Xを追加する」という設定で以下のトピックについて解説していました: gitでコミットの順序を入れ替えるgitで複数のコミットを1つにまとめるgitで1つのコミットを複数のコミットに分割する これにはまず としてこの作業用のトピックブランチを作成してそちらで作業を行うのが普通です。 しかし git branch を実行したところで安心してしまい、 git checkout を忘れて全く違うブランチで作業を行ってしまう というミスは時々やってしまいます (git checkout -b という方法もありますがここではそれも忘れていたとしましょう)。 例えば以下のような状況だったとしましょう: $ git branch ma
他人の開発画面、覗いてみた事ありますか。 覗いてみた事が無い方は、是非見せてもらってください。意外と面白いですよ。 gitのコミットの仕方ひとつとっても、人によって全く違うんだなと思うはずです。 git使いが10人いれば、使い方も10通りなんだなと、他人のコンソール覗きこむたびに感じます。 私の場合、プロジェクトが数ヶ月から半年に一度変わる(または並行して複数のプロジェクトに入る)という事が多く、いろんなgit使いの方に触れる 機会が多いです。 コンソール上でgitを操作する人、SourceTreeやEclipseプラグイン等のGUIツールで操作する人、git rebaseを多様する人、全くしない人、コミットグラフが綺麗な人、汚い人(そもそもあんまりこだわりを持っていない人?)、コミットメッセージを日本語で書く人、英語で書く人。。。 私は、「git pull」というコマンドを使う事はほぼ無
Git を使用していると特定のコミットを指定したいことが多々あります。 例えば: コミットされる内容を確認したり(git diff)、コミットされた内容を確認したり(git show)、pull request された内容を確認したり(git log -p)、アレやコレを元に戻したり(git reset 等)コミットの順序を入れ替えたり(git rebase -i 等)1つのコミットを複数のコミットに分割したり(git rebase -i 等) 等々です。 この時、一番確実なのは git log でコミットのIDを調べて、そのIDで指定することです。 ただ、これは確実ではあるものの、40文字もの英数字の羅列をコピーするのは面倒です。 どうにかして簡単に指定できないものでしょうか。 現在のブランチの最新のコミットを指定する HEAD で指定できます。 これ単品だと面白くありませんが、他の記法
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く