オブジェクト指向の問題点 - ビスケットのあれこれ
オブジェクト指向プログラミングを神格化するような記事が流れてきたので，僕が知っている問題点について書いてみたいと思います．僕がまだ学生だったころは，オブジェクト指向の評価もまだそれほど定まっていなくて，オブジェクト指向の次はどんなパラダイムが出てくるかとか普通に学生レベルで議論していたものですが，ここまで強大になってしまうとそれを打ち負かそうなんて気にはならないのでしょうか．僕にはオブジェクト指向が普遍的な真理という感じは全然しなくて，ここまで使われてる理由は，現実的なテクノロジーで大きなシステムを作らなければならない必要性のほうを優先した結果であると認識しています．オブジェクト指向がその後の25年ほどもずっと安定してその地位を保てるほど素晴らしいものとは思えないのです． 以下で上げる問題点は，個別に解決している研究はあったりしますし，僕も論文を書いたりしましたけど，実際の言語に導入されて
都立大 自然言語処理研究室 - 自然言語処理を学ぶ推薦書籍
自然言語処理を学ぶ推薦書籍を紹介します。2021年03月現在、自然言語処理を勉強したい理工系の学生・エンジニアの人は、以下の本を推薦します。 （概要）自然言語処理（放送大学出版） （理論）言語処理のための機械学習入門＋深層学習による自然言語処理 （実装）Python 機械学習プログラミング 第3版 自然言語処理を勉強したい、非理工系・非エンジニアの人には、以下の本を推薦します。 （数式なし）自然言語処理の基本と技術 （数式あり）自然言語処理（放送大学出版） オライリーから出ている「入門 自然言語処理」は特殊な本（詳しい人がこれを使ってレクチャーしてくれるならともかく、独習に向いていない）で、Python 2 で書かれているだけでなく、すでに動かなくなったコードも多々あり、2019年時点では読まない方がいい本です。（それでもどうしても、意地でも読みたい人は、本家にある Python 3 対応
Rubyによる関数型プログラミング
古き良き小学校の時代、この行には困惑させられたものだった。 魔術的な x が、加算されたのに等しいままでいる事に。 どういうわけか、プログラミングを始めると、それに構わなくなる。 「やれやれ、それは重大な事柄じゃないし、プログラミングとは現実のビジネス行為なんだから、 数学的な純粋さについてあら探しなんて必要無い (その議論なら、大学にいる狂った髭面野郎どもにさせておけばいい)」と思っていた。 けれども、ただ知らなかっただけで、我々が間違っていて高い代償を支払っていたのは 明らかである。 Wikipedia によれば、「関数型プログラミング(functional programming, FP)とは、 計算を数学的な関数の評価とみなし、 状態や可変データを避けるプログラミングパラダイム」である。 言い換えると、関数型プログラミングは、 副作用が無く変数の値を変化させないコードを推奨する。
PHPで素数を数えて落ち着いてみた - hnwの日記
2,3,5,7,11,13,...と素数を順に列挙することで落ち着く人が世の中にはいるようです（参考：「素数を数えて落ち着くんだ…」）。とはいえ人力では素数を100個列挙するのさえつらいので、プログラミング言語に頼った方が落ち着けるはずです。PHPには、そんな状況で使えそうな関数が存在します。 gmp_nextprime ― 次の素数を見つける PHP: gmp_nextprime - Manual よし、この関数さえあれば落ち着けるぞ、と思いきや、マニュアルにはこんな記述もあります。 注意: この関数は素数を識別するのに確率的アルゴリズムを使用します。 誤って合成数を取得してしまうことは、まずありません。 PHP: gmp_nextprime - Manual えっ？「まずありません」ってことは少しくらいはあるんでしょうか。逆に不安で落ち着かなくなってしまいそうです。 本稿ではこの関数に
アルゴリズムと計算量
金庫破りと計算量膨張 n 桁の番号をもつ暗証ロックがあるとします。 2 桁であれば 00 〜 99 の 100 個の正解があるわけで、 0 番から順に入力していく解き方では、 最悪の場合は 100 手目に開きます。 99 が正解とは限らないので、平均的にはこれより早く解き終わります。 0 であるときの確率は 1/100 で、このときの手数は 1 手です。 1 であるときの確率は 1/100 で、このときの手数は 2 手です。 2 であるときの確率は 1/100 で、このときの手数は 3 手です。 3 であるときの確率は 1/100 で、このときの手数は 4 手です。 : 99 であるときの確率は 1/100 で、このときの手数は 100 手です。 つまり、平均手数は により、100 手目の約半分です。 ここでいう解き方をアルゴリズムといい、 問題を解くための手数 (てかず) のことを計算
コンプガチャの数理 -コンプに必要な期待回数の計算方法について- - doryokujin's blog
目次 1. 『コンプガチャの数理 -コンプに必要な期待回数の計算方法について-』 2. 『「数学的ゲームデザイン」というアプローチ』 3. 『コンプガチャの数理 -ガイドラインに基づいたゲームデザイン その1-』 4. 『コンプガチャの数理 -ガイドラインに基づいたゲームデザイン その2-』 目的 コンプガチャのコンプに必要な回数を求める問題は「The Coupon Collector's Problem」と呼ばれる数学モデルの枠組みに沿った美しい問題である事を述べ，いくつかの有用な結果を示す。 ※ あくまで個人研究のつもりで書いたので，色々不備があるかもしれません。その際は一言頂けると助かります。 定義 コンプガチャ問題を Coupon Collector's Problem に準じた形で書くと以下の様になる： 「全部で n 種類のアイテムがあって，1つのガチャの中にアイテムが1つ入って
入社試験の問題をつらつら考えた
下っ端にはぜんぜん知らされていなかったんですけれど，どうも職場で「人を入れよう」な話になっているらしく，選考試験を考えることになりました。うちの職場は規模が小さいので，選考試験も手作り。手間はかかるんですけど，SPI みたいに機械的に人を切るよりはマシだと思っています。 つことで，「なんか適当なのを考えてよ」と言われてたのでした。で，以下がいくつか考えたうちのひとつ。他の問題は割と専門的なので，一般的なプログラマ向けのものを。少なくともうちの基準ですけれど，「プログラミングできます」と他人に言うための必要最低条件という位置づけです。 【問題】 次の C++ で書かれたプログラムについて，以下の設問に答えてください。 #include <iostream> int factor(int n) { return (n > 0) ? n * factor(n - 1) : 1; } int ma
Javaで暗号化したデータをPerlで復号化しようとしたら大変だった件 - download_takeshi’s diary
JavaでRijndael(AES)で暗号化されたデータをPerlで復号化しようと思います。 「暗号方式と秘密鍵だけ聞いておけば簡単にデコードできるっしょ、余裕っしょ」とタカをくくっていたら、思いっきり天罰がくだりました。久しぶりにハマったのであります。 ちゃんと確認しておくべきだった情報 まずは暗号方式と秘密鍵だけでなく、以下の情報をしっかりと確認しておく必要アリでした。 暗号アルゴリズム 秘密鍵 秘密鍵の長さ ブロック暗号化モード IV（Initialization Vector：初期化ベクトル） padding方式 暗号のことちゃんと勉強した事がないので、なんだかよくわからんけど、必要らしい。 せめて事前にここらへんを読んで勉強しておけばよかった。 ぱせらんメモ http://d.hatena.ne.jp/pasela/20100612/crypto DESに代わる次世代暗号「AES
Digest::SHA1 - SHA-1アルゴリズムへのPerlインターフェース - perldoc.jp
名前¶ Digest::SHA1 - SHA-1アルゴリズムへのPerlインターフェース 概要¶ # 関数形式 use Digest::SHA1 qw(sha1 sha1_hex sha1_base64); $digest = sha1($data); $digest = sha1_hex($data); $digest = sha1_base64($data); # OO形式 use Digest::SHA1; $ctx = Digest::SHA1->new; $ctx->add($data); $ctx->addfile(*FILE); $digest = $ctx->digest; $digest = $ctx->hexdigest; $digest = $ctx->b64digest; 説明¶ Digest::SHA1モジュールはNIST SHA-1メッセージ・ダイジェスト・アル
PubSubHubbubでRSSもTwitter並にリアルタイムに － ＠IT
2009/08/19 「PubSubHubbub」（パブサブハブバブ）という奇妙な名前のプロトコルが注目だ。2009年8月5日にグーグルはRSSリーダーサービスのGoogle ReaderでPubSubHubbub対応を明らかにしたほか、国内ではライブドアが、同じくRSSリーダー「livedoor Reader」とブログサービスの「livedoor Blog」でPubSubHubbubに初対応したことを8月18日に発表している。まだ対応サービスは少なく、その“効能”も「ブログの更新がRSSリーダーに反映されるのが、ほぼリアルタイムになりました」というだけで小さく見えるかもしれない。しかしPubSubHubbubは、ネット全体のリアルタイムコミュニケーションプラットフォーム化を促す重要なキーとなるかもしれない。 Twitterが見せつけた“リアルタイム”のテンポの良さ Twitter人気が高
タグクラウドのアルゴリズム (それなりブログ)
それなりブログ 20台後半からWebエンジニアに転生した人が書く、プログラム・無駄口とかのそれなりのブログ 管理人: kjirou 座右の銘: 「三度の飯より、四度の飯」 タグクラウドの大きさを決めているアルゴリズムはどうなってるのかなと、PHPのTagCloud.phpと、Rubyのtagcloud-rubyを読んみました。 両方ともCSSセレクタ生成等が処理の中に入ってしまっており、ライブラリとしてはやや微妙な感じ。（元のPerlの実装に合わせているからだと思いますが） なので、アルゴリズムだけ貰おうかと。 【最も基本的なアルゴリズム】 最終的に、各タグの大きさは25段階の範囲で区分される。 ソース内ではこれを level と読んでおり、0-24の範囲で指定している。 level算出方法は以下の通り 1. 最もタグ付けされている回数が多いタグの回数を取得し、それの平方根を求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Algorithms with Python