  |
はてなキーワード: 文字列とは
「男性美容系Youtuber」という文字列を見てメンズ化粧品の広告を美容系インフルエンサーに出したら女性視聴者が大半だったため広告効果が全然なかったって増田を思い出してしまった
開発者AとBがいる。
開発者A「ビジネスモデル全体を最適化するための施策を実施中です」
開発者B「アイテムの重複を避けるために、アイテムの属性の文字列から固有の識別子を生成しています」
一見すると開発者Aのほうが全体を俯瞰していてデキそうに見える。開発者Bが無能のアスペのようだ。
しかし開発の進捗を確認すると、Aは全く進んでおらず、Bは「重複を排除するロジックが完了したので、これを効率的に実行できるようにしています」と言っている。
ご察しの通り、問題を細かく分解していかないと、開発というのは進まない。
全体を俯瞰してビジネスについて考えているふりをするだけではコードという形にはならないのである。
開発者Bは穴を掘り進めなければならないので、実際に掘っている。開発者Aは穴を掘る必要があるかどうかすらわかっていない。
別の言い方をすれば、巨大に見える問題も、適切に分解すればグイグイと進んでいくとも言える。開発者Aのように巨大なままで捉えていると、何も実装できない。
kjin 漫画云々より今もワイドショーて言葉が若い人に通用するのかが気になった。増田は対応とか好きに思ったらいいしＤＢで育ったけど鳥山明のマンガに与えた影響とかは思わなかったかなあ。当時自分が夢中になっただけで
元増田に「増田って呼ばれるの嫌」と書いてるのに、増田と書く意図はなんなんだろう？
故意の嫌がらせ？それとも「自称したコテハン」を二人称ないし三人称としてブコメ等に使っても、他のそのブコメを見た人がそのコテハン文字列がどういう文脈を持ってるのかさっぱりわからないことがあるのに対して(固有名詞か慣用句かすらわからないかもしれない)、
「増田」と書けば「増田に書かれた文章の書き手」ということを確実に伝えられるから、っていう配慮の意図が大きいのかな？
それともその趣旨を伝えた最後の文は明らかに本題と独立してるうえに、あまりにも通常の増田の価値観とは異質な文化圏から出てきてる言葉なので「ごちゃごちゃ何言ってるのかわかんねえ」って感じでスルーしてるのかな？
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
ここからは、気が狂った理解にはあたらず、定義の厳密さに疑義を挟む余地あり
その境界はどこなの？それこそ恣意的主観的じゃなく厳密に線を引けるのか？別の話っていうよりは分かちがたい問題に思えるが。
「"証明は自然言語で書きつつも, いざとなったら形式的に文字列に書き換えることができるという前提に立っています" 前提が共有されていない人との間では一意さは共有されない場合がある、ということをどう捉えるか」というのもある。
悪意のない、そして別に狂ってるわけでもない知性的存在(生命に限る必要ないだろう)が、前提を共有してないこと、というのは無理なく想定されることだと思うけどな(知的存在が人間以外にいるわけないじゃんという突っ込みはさておき)。
わかるなあ
メンタル落ちたなってときにここに来てくだらない文字列を読んでると、ちょっと回復して風呂に入って寝られるようになる
ドブ川ではあるけどガンジス川みたいな懐の深さがある
こっちには「横だけど」って書いてるのに、あっちにはかかないんだ？ｗ
まず数学的な内容の真偽の判断に納得感や権威などは関係ないです.
あくまで言及されている状況の場合は, 先生の方が想定している証明の体系では生徒が与えた記号列, 文字列が合致しなかったためそれが証明ではないと判定されたのではないでしょうか?
もちろん極論を言えば先生の方から公理や推論規則を全て提示すべきというのはそれはそうですが, そこは暗黙の了解や文脈に依存する話です.
まず数学的な内容の真偽の判断に納得感や権威などは関係ないです.
あくまで言及されている状況の場合は, 先生の方が想定している証明の体系では生徒が与えた記号列, 文字列が合致しなかったためそれが証明ではないと判定されたのではないでしょうか?
もちろん極論を言えば先生の方から公理や推論規則を全て提示すべきというのはそれはそうですが, そこは暗黙の了解や文脈に依存する話です.
おっさんずらぶを初めて見た。前のシーズンは見ておらず、今回のシーズンも数話見逃して、ど真ん中の話をみている。
おっさんとらぶしてなくて驚いた。最初の展開がわからなさ過ぎて、おっさんが何ポジションかわからなかったが重々片思いなことはわかった。
（この文字列はアニメ日常の曲を思い出す。オモオモ☆カタオモイ。）
ただドラマ見てTwitterをいじるだけだったので、感想を記述していこうと思う。読書感想文ならぬドラマおっさんずらぶ感想文。いや圧倒的中身のなさと文字数の少なさで再提出する未来が見えるな。以下感想。
・ドラマを見ていると、だんだん田中圭が可愛らしく見えてくる。まだ15分程度しか見ていないのに。なぜなのか。立ち振る舞いと作中での周りからの評価のおかげだろうか。
しかし、途中にちびまる子ちゃん的展開があり、恐怖しかない。鬱恋愛ドラマなのか？いや、そもそも恋愛ドラマがそのような〈試練→乗り越える→雨降って地固まるのように、より強固な絆につながる〉という形になっているから、仕方ないのか。いや、この展開は少年漫画も一緒だ。
・みんな熱いパッションがあってとても羨ましい。恋愛感情羨ましい。私も何かに執着したい。以前はゲームにはまったが、しっかり飽きた。次は何にはまろうかな。Excelマスターとかが良いんじゃないかと睨んでいる。
それにしても皆様笑顔が素敵である。幸せそうだね。みんな笑顔で幸せになってね、という気持ちになってくる。私の日々にはない種類の幸せを鑑賞している。
【その他】
・立ち振る舞いについては、かわいいとかっこいいは作れるね。やっぱり。と思った。アイドルのランキングや、夜の仕事の方々のランキングを見ると、正直私には刺さらないなーって思う方々がトップを取っていることもある。
それは、私が世間と好きな系統がずれているということでもあるかもしれないが、顔だけでなく中身勝負な部分も大きいからだと思っている。相手に「また会いたい！すき！素敵！」と思ってもらえるような対応って作れるんだよね。私も過去を思い出してみれば、つれない態度と甘い態度を交互に取られると執着的感情が芽生える。誰かに頼んでみようかな。
・周囲からの評価については、私は周囲からの評価を気にする、八方美人人間であるため、周りからの評価が高いとそれだけ信用もしてしまう。単純ミーハー。私の心の中にキリスト様等神様がいれば自分の心に問いかければ済むものを。それにしてもはるたんモテるな。
言及されている状況を(記号論理のような)推論規則を用いて何らかの証明を書いていると仮定します.
「証明」というものも特定の条件を満たす公理と推論規則を用いた操作の列として(数学的に)定義されています. ここで公理や推論規則などはあらかじめ固定されています.
与えれた記号列, 文字列が証明であるかどうかもその定義に基づいて判定することができます.
言及されている状況での会話ですが, あくまで推察ですがおそらく生徒の書いた証明が証明の体を成しておらず, 皮肉混じりに言ったのではないでしょうか?
哲学など数学以外のことは専門外のため, あくまで数学に関することだけ言及させていただきます.
ユークリッド幾何学に言及されているように数学の歴史は紀元前まで遡りますが, 数学の形式化が意識され始めたのは1900年代以降と最近の話です. 主にヒルベルトによって主導されたものだと私は理解しています. (もちろん多くの数学者がこのプログラムに関わってきました. ) 数学の形式化や形式主義で調べると参考になると思います.
数学的な内容に関して言及したいことは多くありますが, かいつまんで述べさせていただきます.
(あくまでこれは元の記事が間違っているなどと主張しているわけではないです. 現代の数学の考え方や雰囲気の一部を分かっていただければ幸いです. )
現代の形式化された数学は原理的には決められたルール(公理と推論規則)を用いて行われる一連の手続きです. それらの「意味」が何かは一旦全て忘れてください. ここで公理とはあらかじめ定められた記号列で, 推論規則とはいくつかの文字列を用いて新しい文字列を生み出す操作です, 例えば文字列A→BとAが与えられたときに文字列Bを得る操作があります. 定理(数学的命題)とはこの操作によって生み出される文字列です. これらの操作は数学における証明を形式的に記述したものになっています. 論理式などもこの形式化のもとで特定の条件を満たす文字列として定義されます. 例えば論理式Pの否定は¬Pという文字列です. (ここでは否定を表すための記号として¬という文字列を用いています. )
ここまで文字列だけを考えた形式的なものですが, 構造やモデルを使うことによってこれらの文字列を解釈する(つまり意味を与える)ことができます. (詳細は省きます. ) 構造やモデルを定めることによって論理式の意味が一意的に定まります. またそれらの取り方を変えることによって意味が変わることもあります.
これの考え方によって(数学的な)意味は形式から分離されています. さらに気になる場合はゲーデルの完全性定理などを見てください.
そして適切な公理と推論規則を定めることにより数学そのものを形式的に扱うことできます. その適切な公理はツェルメロ-フレンケル集合論(ZFC)と呼ばれており, 現在の数学者はこのZFCを用いて数学をしています. (一部, 圏論などでZFCに収まらない議論があると聞きますが, それらもZFCの適切な拡張を考えることで解決できます. )
つまり, これまでに書かれた数学の証明などは全てこのZFCを用いることで文字列の操作に書き換えることができます.
一方で数学の論文は普段の言葉(自然言語)を使って書かれます. これは本当に全て文字列に書き換えることをした場合, 可読性が著しく落ち, また分量も膨大になるため人が読めないためです. しかし証明は自然言語で書きつつも, いざとなったら形式的に文字列に書き換えることができるという前提に立っています. そしてこれは理論的には可能であり, 数学の厳密性を担保しています.
「定義の一意性」に関してですが私自身が元記事の要点を完全に理解しているわけではないのですが, 数学に関していうとある数学的概念の定義が複数あることはよくあります. もちろんその複数ある定義が同値であることを証明されなければなりません. ここで同値というのはある数学的対象Aが定義Pと定義Qで与えられていた時に, 「Aが定義Pを満たすならば, 定義Qを満たす. またAが定義Qを満たすならば定義Pを満たす. 」ということです. 実際に使う際には用途に合った定義を用いることになります. それらは同値なのでどれを選んでも問題ないです.
以上がざっくりとした形式化された数学に関してです. 参考になれば幸いです.
追記: これは筆者個人の考えですが, 数学と哲学の議論はしっかりと分離してなされるべきだと考えています. もちろん相互の交流はなされるべきですが, 両者を混同するのは誤解や誤りの原因になると思います.
