  |
はてなキーワード: interpreterとは
↓
Reports: Shohei Ohtani’s interpreter fired after being accused of ‘massive theft’
https://edition.cnn.com/2024/03/20/sport/shohei-ohtani-interpreter-fired/index.html
Shohei Ohtani's Interpreterで検索するといいと思う
日本のメディア減らしたかったら、The issue with Shohei Ohtani’s interpreter
↓
こっわ
https://edition.cnn.com/2024/03/20/sport/shohei-ohtani-interpreter-fired/index.html
Shohei Ohtani's Interpreterで検索するといいと思う
日本のメディア減らしたかったら、The issue with Shohei Ohtani’s interpreter
ChatGPTも一時期すごく盛り上がったけど、最近はあまり感動するような使い方を聞かない。
一方で、今年7月から日本でも使えるようになったChatGPTのCode Interpreterと言う機能は、手元のファイルをアップロードして読み込ませた上で、ものすごい精度でプログラミングを行ってくれるので、なかなか良さそう。
しかし、ちゃんとした使い方を解説した記事に出会えない。みんな、ちょっと試して、統計分析のグラフ作ったり、超シンプルなゲームを作ったというような浅い紹介はあるのだが、ちゃんと使い込んで強みや弱みを含めて実践的な使い方を教えてくれるものはないだろうか。
Googleでの検索結果に出てくる記事は大体読んだ。たまに良い記事もあったが、ここで紹介したいと思うまでのものはなかった。
Youtubeでも動画がたくさん上がっているが、初心者向けで時間の無駄というものが多い。
Kindle本では、少し解説本が出ている。以下の本あたりは、ちょっと参考になった。
・ChatGPT Code Interpreter 詳細研究 https://www.amazon.co.jp/dp/B0CCMVBHT5
・ChatGPT Code Interpreter 実践解説 ２ アプリ作成 https://www.amazon.co.jp/dp/B0CFT2SW66/
・ChatGPT Code Interpreter 実践解説 ３地図情報検索 https://www.amazon.co.jp/dp/B0CFZRWYYS/
そういう人は企業の中で活動していて、対外的に成果を出してくれないのかなあ。
Code Interpreterは素晴らしい機能で、今後もかなり注目されるはずなので、しっかりフォローしておきたい。
Code Interpreterでランダムな音節から英単語を作り、その意味を解説してもらう。
音節のリストは与えなくても良いが、あったほうがあり得ない音の並びができて楽しくなる。
https://chat.openai.com/share/30b4acd9-3eac-41ba-a37b-71e6bbe7d1b0
ランダムな音節を2〜4個繋げて英語の単語を20個作って、その意味を考えてください。
シンプルで美しい。「現在のイングアクトは〜」って仕事で言いたい。
ChatGPTくん日本語に引っ張られてない？
かっこいい
岩路…？
ドイツ語？
増田は、chatGPTでプログラム書いたり、論文書いたりして、無茶苦茶能率上がった情報系の研究者です。
最近、新機能のcode interpreterなるものが出て、本日使ってみました。
これまでは、プログラムをchatGPTに作ってもらっても、信用性がイマイチで、結局自分がデバッグすることが多かったのですが。
今回は、あっさり正しいプログラムが出てきやすい、なぜなら、プログラムをchatGPTが実行して、その結果をchatGPTも知ることができるから、正しさがわかりやすい。
グラフとかも、いちいち自分で実行してたのが、chatGPT上でささっとグラフが書かれると、なるほどなあと速攻で納得できる。
いやあ、こりゃすごいわ。プログラミング能力に関して、今までデバッグで煩わしいから、chatGPTまだまだだなとか思ってたけど。こりゃすごい。
これ、自分が知らないだけで、もっとすごい使い方で便利になるんだろうね。
え〜っと、PDFも読めるらしいから、自分の論文の査読とかもやってもらえるのかね。
なんなら、chatGPTくんが、リライトとかしてくれるのかな。
今までは、chatGPTの字数制限とかあって、論文全体を提示できないから、部分ごとにchatGPTに投げて文章を校閲してもらってたけど、
PDFを渡して、chatGPTが全体を読んだ上で、部分部分の文章表現を訂正してくれるわけだから、全体に統一感とかまで出ちゃうのかな。
凄すぎやろ。。。
論文書くのがこんな楽しみになるとは思わなかった。
When you suffer a disaster and need a personal interpreter in Japan, please try "Voicetra", the translation app developed by the National Institute of Information and Communications Technology. https://t.co/rgePN4F9Ct— 総務省消防庁 (@FDMA_JAPAN) 2019年7月3日
sdkmanagerでインストールされるツールのバイナリがことごとく以下の通り
$ file `which emulator` /data/Android_SDK/tools/emulator: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.15, stripped $ emulator bash: /data/Android_SDK/tools/emulator: cannot execute binary file: 実行形式エラー ・Android Studioなどでエミュ動かそうとすると Syntax error: ")" unexpected とか謎のエラー
つまり64bitバイナリなのである。32bitバイナリは提供されない(Won't Fix (Intended behavior))。
逐一バージョン戻してもいいのだが仕様だし他のも32bit切り始めてるしメモリ4GBもしんどいし64bitやろう。うん。おかねください
http://b.hatena.ne.jp/entry/kenokabe-techwriting.blogspot.com/2015/04/blog-post_30.html
http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html
この記事自体はどうでも良いのだけど、以前「クロージャ」という言葉の初期の使用例を探したことがあったのを思い出したので、参考までに。
Landin "A λ-Calculus Approach" (1966)
We represent the value of a λ-expression by a bundle of information called a "clusure", comprising the λ-expression and the environment relative towhich it was evaluated.
我々は、ラムダ式の値を「クロージャ」と呼ばれる情報の束で表す。「クロージャ」はラムダ式とそのラムダ式の評価に関する環境から成る。
Moses "The Function of FUNCTION in LISP,or Why the FUNARG Problem Should be Called the Environment Problem" (1970)
A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porpous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering(hence the term "closure" used by Landin).
LISPでのFUNCTIONとQUOTEの違いについては、次のように考えるのが有用な比喩になる。QUOTEは多孔的または開放的に関数をおおっていて、自由変数は現在の環境へと脱出できる。FUNCTIONは閉鎖的(closed)または非多孔的に関数をおおっている(このことからLandinはクロージャ(閉包)という用語を使っている)。
(訳はhttp://kreisel.fam.cx/webmaster/clog/img/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/funarg/funarg.html から)
Sussman and Steele "SCHEME: An Interpreter for Extended Lambda Calculus" (1975)
In order to solve this problem we introduce the notion of a closure which is a data structure containing a lambda expression, and an environment to be used when that lambda expression is applied to arguments.
この問題を解決するためにクロージャという概念を導入する。クロージャはラムダ式とそのラムダ式が引数に適用されるときに使われる環境から成るデータ構造である。
Steele and Sussman "The Art of the Interpreter" (1978)
We say that the procedure is closed in the current environment, and the ＆PROCEDURE-object is therefore called a closure of the procedure, or a closed procedure.
この手続きは現在の環境に閉じられている(closed)と言い、それゆえ＆PROCEDUREオブジェクトはその手続きの「クロージャ」あるいは「閉手続き」と呼ばれる。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
コンパイラ作ったりCPU作ったりシェル作ったりは普通じゃね？
CPUの原理やコンパイラの構造が、大きく変化することは無いから、授業しやすい
俺もやったし
凄いなと思ったのはこれかな
http://d.hatena.ne.jp/kzhk/20091202/p2
suffix array くらい習うけど、実際に意味のあるプログラムまで考えられているのが、課題として良くできている
自分が所属している専攻だと、昔CLU（くるー）って言語を教えていたらしい
初めてADTを実装した言語で、当時としては先進的だった、って先生がよく自慢してる
保守的な授業だな、とは思った
尖った授業はあるとは思うけど
あと、scheme やっていないの？
SICP 読みながら meta circular interpreter 作るのは価値がある行為だとおもう。
I finally understood something. A cliche, but something that is important to me.
I've seen nine counselors and four psychiatrists since I was eighteen. I've been sexually and verbally abused by my family, had eating problems, both anorexia and bulimia, and have also been abused by two of the therapists. I'm also a returnee, as the Japanese label me, so I've been bullied at school, and never really felt like I fit in anywhere, including my family. Yes, I had a whole lot of problems.
I always though about killing myself, and it was a ritual to think about whether to die and how to live at the top of a building on my birthday night. The air was always cold and clear, and stars just seem so near. Up there, rationality just seemed to blur, and wrong or right became so dull with all the pain. As a person who believes Christ, or perhaps in any other religion, suicide is a sin, but it literally felt like living in hell.
Nevertheless, now I finally understand. It was the sense of isolation and hunger of being accepted, that had been eating me after all. It's such a cliche, but I guess it's true. It irritates me because not one of the therapists were capable of handling a bilingual, abused and wounded person, and I myself never realized how much trouble I had when the other person was only capable of handling Japanese, although I am as good as a native after living here twenty years. Some of the therapists were trained and licensed in U.S. and spoke English, but I also didn't notice the huge difference of them and myself -- I can't give an explicit example, but I guess being a returnee and a natural interpreter gives people a different sense. Now, I clearly see the difference is not ignorable. And, it's almost unbelievable that it took me so long to come to this point.
I hate myself. I hate myself for not realizing all these years, for all the money I spent on therapy, for being abused, for being abused again by a therapist, for not being able to communicate my feelings and for even ignoring my own senses just to be accepted by my therapists themselves.
Perhaps being bilingual to me is much more troublesome than others say. Hopefully I can now be more comfortable by accepting that I'm like a gypsy. I've always been an outlaw, anyway. And I hope I can be able to connect with people and have real relationships. All the things I wanted from a therapist are the same things I wanted from normal other human beings. I know there are things that need to be covered by professionals, but now that I realize even professionals can't help, and I can't be really accepted by any professional, as long the relationship is kept "professional."
I hope I can sometime make a real relationship, accept and be accepted, by another person, maybe another gypsy.
一発で動いてしまった場合は多分何かおかしいので、悦に入る前に必ずエラーになる入力とかやってみて確認したほうがいいよ！
無駄なinterpreterパターンとかハマると確かに気持ち良い。
