「サイゼリヤで1000円あれば最大何kcal摂れるのか」をSMTソルバー(Z3)で解いてみた。 - Qiita
前書き サイゼリヤ1000円ガチャをつくってみた(Heroku + Flask + LINEbot) 「サイゼリヤで1000円あれば最大何kcal摂れるのか」を量子アニーリング計算(Wildqat)で解いてみた。 完全に二番煎じですが、古典コンピューターが好きなので、個人的に古典コンピューター最強のなんだかよく分からないけどよく分からないものをよく分からないうちに解いてくれるソフト、z3を使ってサイゼリア問題を解いてみました。 問題 サイゼリヤのメニューを重複無しで合計1000円以下になるように選んだときに、最大の総カロリーになるようなメニューの組み合わせを求めよ。 サイゼリヤのメニューは https://github.com/marushosummers/Saizeriya_1000yen こちらを使わせて使わせて頂きました。メニューは100種類ぐらいみたいで、カロリーは整数値で、プロコ
関数プログラミング 珠玉のアルゴリズムデザイン
演算子以外の構文記号の一部については，GHCの言語拡張UnicodeSyntaxを有効にするとソースコード中に記述可能です． 詳細については，GHCユーザーガイド 9.3.1 Unicode syntaxをご覧ください． 演算子に関しては，Unicodeの記号が使えますので，たとえば，1章については，以下のような定義モジュールをインポートすれば，そのままコードで表現できます． {-# LANGUAGE UnicodeSyntax #-} module Operators where import qualified Data.List infixr 5 \\ (\\) ∷ Eq a ⇒ [a] → [a] → [a] (\\) = (Data.List.\\) infix 4 ∈, ∉ (∈) ∷ Eq a ⇒ a → [a] → Bool (∈) = elem (∉) ∷ Eq a ⇒
木(tree)で遊ぶ - 連載 Haskellプログラミング（『情報処理』46巻5号 2005年5月）
46 5 2005 5 564 n 1 4 4 -1 5 n data data DumbTree = Empty | Fork DumbTree DumbTree data DumbTree Empty ( ) 2 DumbTree Fork nobsun@sampou.org IPSJ Magazine Vol.46 No.5 May 2005 565 DumbTree ( ) Empty Fork ( ) -- trees (>0)DumbTree trees :: Int -> [DumbTree] trees 1 = [Empty] trees n = concat [ joins ls rs | (ls,rs) <- [ lrs xs ys | (xs,ys) <- splits1 n ]] -- splits1 (>0)(>0)2 splits1 :: Int -> [(In
Mutable Algorithms in Immutable Languages, Part 2 · tel.github.io
See also part 1. All of the code in this post is available in the blog repository on Github. Last time we saw a way to implement Union/Find, an algorithm which depends critically on observable mutable memory, within a particular abstract monad called Mem. Monads implementing Mem model mutable memory (say that 10 times fast) and we saw that’s sufficient to recover Union/Find. But we didn’t actually
手続き脳によるHaskell -- Sorting Algorithms
このページは手続き脳から脱却でいない筆者が、Haskell による各種 ソートティングアルゴリズムを実装してみた結果を紹介するページです。ソート はアルゴリズムの基本ですから、これで Haskell を攻略しようというわけ です。 ところで、Haskell に関するWebページを巡回していると、高階関数やモナド などを複雑に使ったアクロバチックでアブノーマルなコードに出会うことが しばしばあります。書いている超頭の良い人達は自らの変態さ加減が披露出来て 快感なのかもしれませんが、頭の悪い私にはそんなコードは理解できません... orz。 そこで私のページでは次のスローガンでプログラミングを行います 普通にやれ、普通に！ そんなわけで「モナドを理解したい」とか常人には不可能な無理難題を期待 している人は他のページを当たってください。筆者自身が分かってないので解説 できません。ごめんなさい。
なぜ Haskell ではキューが軽んじられているか？ - あどけない話
Haskell ではキューが欲しくなったら Data.Sequence を使えと言われる。Seq は両端キューだし、シーケンスとして使えば、連結(><)や分割(splitAt)が、ならし計算量で O(log N) という優れものである。しかし、内部がfinger treeなのでコードが複雑なのと、計算量が「ならし」なところが玉に傷である。 もっと単純で、最悪計算量を保証する(両端でない)キューが標準で提供されてもいい気がする。その候補には、リアルタイムキューがある。どうして標準でキューが提供されないのだろう？ 僕なりの答えは「需要がない」だ。 問題を解くときにスタックはよく使うが、キューが必要な問題はそんなに思いつかない。僕はネットワーク屋なので、もちろんルータにはキューが必要なことは知っているが、それ以外で有名どころと言えば幅優先探索ぐらいだ。 幅優先探索 でも、Haskellではキュー
Haskellの配列でクイックソート - あどけない話
Haskell の クイックソート としては、以下のようなコードがよく例に出てきます。 quickSortList :: [a] -> [a] quickSortList [] = [] quickSortList (x:xs) = quickSortList lt ++ [x] ++ quickSortList gt where lt = filter (<x) xs gt = filter (>=x) xs これは、小さなリストを何度も連結するので、効率が悪そうです。 そこで、一旦配列に直し、固定領域を使ってソートして、またリストに戻す方がいいのではないかと思い、実装して速度を比べてみました。配列を使うクイックソートのコードは、「珠玉のプログラミング」から拝借しました。ベンチマークも含むコードは、gist に上げています。 結果はこんな感じ(単位はms)： 入力のサイズ 10^4 10
Faster persistent data structures through hashing
hello mum");a.close()},find_slide_number:function(e){var c=e.indexOf("#");if(c<0){return 0}var b=unescape(e.substr(c+1));var f=document.getElementById(b);if(!f){var d=/\((\d)+\)/;if(b.match(d)){var a=parseInt(b.substring(1,b.length-1));if(a>this.slides.length){a=1}if(--a<0){a=0}return a}d=/\[(\d)+\]/;if(b.match(d)){var a=parseInt(b.substring(1,b.length-1));if(a>this.slides.length){a=1}if(--a<0){a=
純粋関数型アルゴリズム入門
純LISPから考える関数型言語のプリミティブ: Clojure, Elixir, Haskell, Scala
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
