タグ

プログラミングと論理に関するomega314のブックマーク (19)

  • bitlaw_jp – version control for better laws.

    Concept 法令文はそれだけでは単なる文字列にすぎない。人が法をもとに思考することで初めてそれは意味を持つ。法律に関する議論は法律文そのものではなくその読み方について行われる。それは法的思考と呼ばれ、そこから生まれた解釈は一つの条文に対して複数存在し、文章化されず、いつの間にか更新される。 法の管理と編集を開かれたものにするGitLawという思想がある。しかし、現状の法令文はあまりにも複雑で高度に専門化されているため、その実現は難しいのではないだろうか。 bitlawは、法律文自体をコンピュータで処理できる形に書き換えることで、法的思考を用いずに結論を導き出すシステムの制作を目的とする。意味を持たないはずの法律文から取り出された結論は専門家から見れば間違っていることもある。それはアマチュアのシステムであるといえる。しかしそれによって、人々が法律文そのものについて議論することが可能になる

  • 大学でRustを教えた話 - 未完成な論を綴るブログ

    このブログ記事は、Advent Calender 2020, Rust 3、23日目の記事となります。自分は現在大学で教員をしていまして、セキュリティ系の研究室に所属しています。現在はセキュリティの講義を担当しており、そこでRust言語を教えているため、その内容を紹介しようと思います。 はじめに 皆さんご存知のようにソフトウェアの脆弱性は今でも大きな問題となっていますが、それを完全ではないにしろ根から解決するための技術的手法として型システムが注目されています。型システムの考え自体は古くからありますが、最近ではRust言語が登場し、OSなどいわゆる低レイヤーなソフトウェアも型システムの恩恵を預かることができるようになってきました。SMTソルバや定理証明などと言った難しい(かつ面白い)手法でC言語やC++言語で書かれたソフトウェアを解析する方法もありますが、セキュアソフトウェアを語る上では、

    大学でRustを教えた話 - 未完成な論を綴るブログ
  • テキシコー | NHK for School

    この番組は、思わず頭の中で手順を組み立て、先を予想したくなるような興味深い実験、手順の組み合わせを改善していく楽しさを伝えるアニメーション、さまざまな仕事や物の中にプログラミング的思考が活かされていることを伝えるコーナーなどで構成されています。番組の中では、実際にコンピューターを使ったプログラミングを体験するシーンは出てきません。コンピューターへの苦手意識やICT 環境を問わず、誰でも楽しくプログラミング的思考を育めます。コンピューターを使ったプログラミングへの導入としてはもちろん、実際のプログラミング体験をした後でも、活用できる番組です。

    テキシコー | NHK for School
  • ゼロから学んだ形式手法 - DeNA Testing Blog

    2020年1月に入社し、SWETの仕様分析サポートチームに加わったtakasek(@takasek)です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています(形式手法 カテゴリーの記事一覧)。 この記事では、加入3か月を経てようやく形式手法の輪郭が掴めてきた私の視点から、学習前後での理解の変化について振り返ります。想定読者として学習前の私と近い属性——すなわちコンピュータサイエンスや数学の専門教育を受けておらず、主に現場での実務と自習に頼ってきたソフトウェアエンジニアを想定しています。 形式手法を学ぶ前の認識と疑問 ソフトウェアエンジニアとしての私の一番の興味関心は設計手法です。設計は、なんらかの解決したい問題に対して、ある一面を切り取った構造(モデル)を与え、そのモデルを解決の機構に落

    ゼロから学んだ形式手法 - DeNA Testing Blog
  • なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記

    How do you imagine a building? You consciously create each aspect, puzzling over it in stages. Inception 型なし言語に馴染みはあるものの型付言語をいざ使ってみたらどういう気持ちで書いたらいいのかわからなかったと同僚から相談があり, それをきっかけにして社内の勉強会で以下の話をしました. よく型なし vs. 型付の文脈では「型を書くのは面倒だ」「安全の方が大事だ」「でも面倒だ」「それは型推論を前提にしていないからだ」などの議論になりがちな気がしますが、これはあくまで「計算ありきの型」を考えているからで, 「型ありきの計算」だと全く見え方が違います. 「型はある種の仕様」とおもえば, 型ファーストであることと, 型なし言語でテスト駆動開発(TDD)するときに最初にテストを書くこととは, 同じ

    なぜ型ファーストで考えるのか - 貳佰伍拾陸夜日記
  • 「厳密な共通言語」としての形式手法 #devsumi / Developers Summit 2020

    Developers Summit 2020 で使用したスライドです。 言葉というものは曖昧です。複数人が「ともにつくる」システムにおいて、メンバ間で仕様を正しく共有することは非常に重要ですが、一方で言葉の裏側に隠された「暗黙の仮定」を見抜くことは簡単ではありません。このような仕様の曖昧性への対抗手段として、セッションでは「形式手法」を紹介します。形式手法ではシステムの挙動を数学的に記述することにより、自然言語の持つ曖昧性を排除し、仕様が満たされるかどうかを厳密に検証することが可能になります。あなたの頭の中にある仕様がどのように「数学的な記述」に変換されるのか、具体例を通して体験してみませんか? イベント概要:https://event.shoeisha.jp/devsumi/20200213/session/2380/

    「厳密な共通言語」としての形式手法 #devsumi / Developers Summit 2020
  • Haskellの型と直観論理 - 朝日ネット 技術者ブログ

    開発部のxgotoです。Haskellの初級・中級者向けのトピックを取り上げたいと思います。 今回は型(Type)についてです。型はHaskellの入門書でも必ず最初のほうに説明されるもので、手元のによれば、 型とは、互いに関連する値の集合である。 ---- 『プログラミングHaskell』 Graham Hutton 著 / 山和彦 訳 だとか、 値の世界は型と呼ばれる系統的な集まりへと分割される。 ---- 『関数プログラミング入門 Haskellで学ぶ原理と技法』 Richard Bird 著 / 山下伸夫 訳 などのように書かれています。たとえば Bool は True と False の2つの値からなる集合だし、Intは整数の集合というように、型は値の集合というふうにみることができます。それならば型などと呼ばずに集合と呼べばいいと思いますが、「異なるものには異なる名前をつけろ

    Haskellの型と直観論理 - 朝日ネット 技術者ブログ
  • まともな型クラス への入門: 関数型とオブジェクト指向の垣根を越えて - 檜山正幸のキマイラ飼育記 (はてなBlog)

    2016年9月に次の記事を書きました。 関数型プログラミングとオブジェクト指向について、何か書く、かも タイトルからして引き続く記事を予告しているのですが、その予告を実行することができませんでした。タイトル中の「何か」とは「型クラス」のことです。上記の記事の最後の部分は: 関数型プログラミングにもオブジェクト指向にも関係があって、今後重要度を増すであろう「型クラス」ですが、今述べた(愚痴った)ような事情で(あと、C++のコンセプトは宙ぶらりんだし)、説明の方針も題材も定まりません。でも、いつか、何か書く、かも。 今回この記事で、予備知識をあまり仮定しないで型クラスの説明をします。言いたいことの1/3くらいは書きました。1/3でも長い記事なので、ぼちぼちと読んでもらえれば、と。書き残したことは最後に触れます。いつか、1年はたたないうちに(苦笑)、続きを書くつもりです。 内容: Haskell

    まともな型クラス への入門: 関数型とオブジェクト指向の垣根を越えて - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • Coqと少しの圏論が分かる人向けのhomotopy type theory(その1) -

    The HoTT Book http://homotopytypetheory.org/book/ が完成したらしいけど、どっちかというと、数学者向けに書かれてて500ページもある。homotopy type theoryで今できてることって、CoqやAgdaで書いたら、せいぜい数千行とか、そんなもんじゃないかと思うので、長すぎる気がする 一応、HoTTに関わる知識は、型理論の他に、ホモトピー論や圏論(モナドとかHaskell関連で出てくる類の知識はあまり知らなくてもいいけど、higher categoryとか教科書に書いてなさそうな話題や、モデル圏とかを知ってるといい)があって、全部真面目に勉強しようと思うと、それぞれのテーマで一冊以上のが書ける。ただ、実際には、ホモトピー論や圏論はアイデアや視点を提供しているだけで、あくまでCoqやAgdaで書かれてる部分が重要なので、ホモトピー論や

    Coqと少しの圏論が分かる人向けのhomotopy type theory(その1) -
  • 形式手法 - Wikipedia

    Z言語を使った形式仕様記述の例 形式手法(けいしきしゅほう、英: formal methods)は、ソフトウェア工学における数学を基盤としたソフトウェアおよびハードウェアシステムの仕様記述、開発、検証の技術である[1]。ソフトウェアおよびハードウェア設計への形式手法の適用は、他の工学分野と同様、適切な数学的解析を行うことで設計の信頼性と頑健性が向上するという予想によって動機付けられている[2]。 形式手法は理論計算機科学の様々な成果を基盤として応用したものであり、数理論理学、形式言語、オートマタ理論、プログラム意味論、型システム、代数的データ型などを活用して、ソフトウェアおよびハードウェアの仕様記述とその検証を行う[3]。 分類[編集] 形式手法はいくつかの水準で使用可能である: 水準0 形式仕様記述を行い、プログラム自体を非形式主義的に行う。「軽い形式手法」と呼ぶ。費用対効果が早く得るこ

    形式手法 - Wikipedia
  • 計算複雑性にまつわる10の誤解

    . . . . . . . 10 okamotoy@uec.ac.jp 2013 8 8 2013 . . . . . . . . . ▶ ▶ ▶ ▶ ▶ ▶ ▶ · · · . . . . . . . . . ▶ ▶ ▶ ▶ ▶ ▶ ▶ · · · = . . . . . . . . . ⇝ Garey & Johnson ’79 (1) Garey & Johnson ’79 (2) Garey & Johnson ’79 (3) . . . . . . . . . P vs NP . 1 . . . . . . . . P vs NP . . . . . . . . . P vs NP . 1 . . . . . . . . P vs NP P NP EXP . P . . . . . . . . P . NP . . . . . . . . NP . EXP . . . . . .

  • 汎用ソート殺し - d.y.d.

    00:26 12/12/18 BookLive! 7月に出会ってからずっと電子書籍ストアとして BookLive! をひいきにしているのですが、一体どこが好きなのか語りたくなりました。 ITMedia の これでもう迷わない、電子書店完全ガイド という一連の記事の、 電子書籍の端末の話よりストアの話をしましょうよというコンセプトに思いっきり影響されています。 といっても、第一印象が「普通のことが普通にできるので感激した!!」というもので、 つまり今年の前半に使っていた幾つかの電子書籍ストア/専用アプリが残念だっただけかもしれません。 買ったがどこをクリックすれば読めるのか理解するのに10分かかった、とか、 6冊以上買うと棚アプリから画面外にがはみ出るので手でいちいち棚を変えて整理しないと読めない、とか。 当に普通に使えるという以上に特筆することもないんですが、 あ、でも、今年になる

  • 複雑に絡んだ要因を論理の力で解きほぐす/PythonとJupyter でブール代数アプローチをやってみた

    計算は、慣れない人のアタマには負担だが、規則通りに進めていけばいいという利点がある。 たくさんの要素を扱ったり、複雑に込み入った推論を進めることもまた、人には負担の大きい作業だが、計算の形に変換することができれば、途中過程を規則的な繰り返し作業に置き換えることができる。たとえば機械に手伝ってもらえる。 今回、紹介するのは、数値化/統計的処理が難しい事象や、質的研究について、計算=演算の力を導入するとどんなことができるかという一例※である。 ※ 続くかどうかわからないが Sociology on Pythonシリーズの第一弾でもある。 ブール代数アプローチ(boolean algebra approach) ブール代数アプローチは、 Ragin(1989)によって、真理表とブール代数に依拠した比較分析の手法として、質的比較分析(Qualitative Comparative Analysi

    複雑に絡んだ要因を論理の力で解きほぐす/PythonとJupyter でブール代数アプローチをやってみた
  • カリー=ハワード同型対応 - Wikipedia

    関数型プログラムとして書かれた証明:自然数の加法に関する交換律のCoqによる証明。 カリー=ハワード同型対応(カリー=ハワードどうけいたいおう、英語: Curry–Howard correspondence)とは、プログラミング言語理論と証明論において、計算機プログラムと証明との間の直接的な対応関係のことである。「プログラム=証明」(proofs-as-programs)・「型=命題」(formulae-as-types)などとしても知られる。これはアメリカ数学者ハスケル・カリーと論理学者ウィリアム・アルヴィン・ハワード(英語版)により最初に発見された形式論理の体系とある種の計算の体系との構文論的なアナロジーを一般化した概念である。通常はこの論理と計算の関連性はカリーとハワードに帰属される。しかしながら、このアイデアはブラウワー、ハイティング、コルモゴロフらが定式化した直観主義論理の操作

    カリー=ハワード同型対応 - Wikipedia
  • 停止性問題 - Wikipedia

    この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。(このテンプレートの使い方) 出典検索?: "停止性問題" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL(2018年1月) 計算可能性理論において停止性問題(ていしせいもんだい、英: halting problem)または停止問題は、「どんなチューリングマシン[注 1]、あるいは同様な計算機構についても、それが有限時間で停止するかを判定できるアルゴリズム」は可能か、という問題。 アラン・チューリングは1936年、停止性問題を解くアルゴリズムは存在しないことをある種の対角線論法のようにして証明した。 すなわち、そのようなアルゴリズムを実行できるチューリングマシンの存在を仮定すると「自身

    omega314
    omega314 2016/05/04
    低姿勢じゃないよ停止性。
  • クワインと対角化定理 ~計算理論入門~ - いきるちから

    はじめに クワインとは この前プログラミングの教科書を読んでいたら面白い問題があった。大雑把には次のような感じ。*1 自分自身のソースコードを出力するプログラムを書け。 調べてみたところクワインというらしい。細かい話をすると入力を受け取るのもダメだそうなので上の問題文よりは厳しい。詳しい話はWikipediaにある。 クワイン (プログラミング) - Wikipedia 結構難しいし、SchemeとかHaskellはまだしもCのやつとか何やってるのか初見じゃ意味不明。頭がこんがらがるのが味わえるのでぜひ考えてみて欲しい。 クワインと計算理論 ところで、計算理論をかじったことある人は「これ対角化して不動点つくればいいんじゃね?」と気がつくと思う。実際その方針でこの問題は解けるし、Cとかのわけ分からん例もこのことを理解してるとすんなり分かる。もろに理屈っぽい計算理論が割と身近に思えるクワインに

  • 離散数学リンク集

    http://logic.cs.tsukuba.ac.jp/~kam/lecture/discrete2013/text/main.pdf

  • アルゴリズム - Wikipedia

    アルゴリズム(英: algorithm[注 1])とは、解が定まっている「計算可能」問題に対して、その解を正しく求める手続きをさす[注 2]。あるいはそれを形式的に表現したもの。 実用上は、アルゴリズムの実行に要する記憶領域の大きさや完了までに要する時間(空間計算量と時間計算量)が小さいこと、特に問題の規模を大きくした際に必要な記憶領域や計算量が急激に大きくならないことが重要となる。 アルゴリズムの実行は形態によらない。コンピュータプログラムはコンピュータ上に実装されたアルゴリズムの例である。 概要[編集] フローチャートはアルゴリズムの視覚的表現としてよく使われる。これはランプがつかない時のフローチャート。 岩波国語辞典「算法」に、まず「計算の方法」とした後に2番目の詳細な語義でalgorithmの訳として、 特に、同類の問題一般に対し、有限回の基的操作を、指示の順を追って実行すれば、

    アルゴリズム - Wikipedia
  • プログラム意味論とトポロジー 再帰,相互作用,結び目

    ��� � � ��� � � ��� � � Áº ��� ���� ��� �� ������ ������� �������� ���������� � ��� ��� �! ¯ ¯ ¯ ¯ ¯ ¯ ¯ "� �� ��# ��$�% & ¯ '�&(� )�����# ��*$ ¯ �� ���� # �� �����# ���+& � ¯ ¯ ¯ ¯ ¯ � � ¯ ¯ ¯ � � � � � ������ � �,� ������ � � � �,� � � � � � � � )����� � � � �� ��� �� � �� ÁÁº ���� ��� �� -��� � ��� � ��� -������ � �- � � ���� � �. � � �-����� �� � � ���� � ���� � ���� � ���� ������� � �- � � ��

  • 1