Writerを使ってはならない - Qiita
2022-05-20追記: mtl-2.3, transformers-0.5.6以降においてリークの起こらないCPS版Writerが提供されているのでそちらを用いてください: https://hackage.haskell.org/package/mtl-2.3/docs/Control-Monad-Writer-CPS.html https://hackage.haskell.org/package/transformers-0.5.6.0/docs/Control-Monad-Trans-Writer-CPS.html Writer Monadの問題点 Haskell スペースリーク アドベントカレンダーX日目(X ~ 360)です。 Writer Monadを使ってはならないという話があります。 理由は単純で、スペースリークが発生するためです。 以下の単純なアクションを評価してみま
スペースリーク、その傾向と対策
スペースリークの傾向とその対策を見ていきます。 ここでは3つのパターンを取り上げます。他のパターンがまだ見つかりそうな気がしているので、気がついた方は是非記事を書いてください。 注意事項 「サンクを積む」という表現を多用していますが、「関数適用によってサンクを大きくする」と言った意味合いで使っています。多分に誤用なので外では使わない方がいいと思います（と思ったらそういう表現を使うこともあるそうです） 以前の記事もそうですが、「簡約」は「評価」に統一してます 基本方針 追記: 正格評価 無限ループをしない 必要ない式は評価しない 遅延評価 無限ループをしない 必要ある式はサンクを積まない サンクの必要とする空間と、潰した後の空間 サンクは必ずしも悪いものではありません。非常に大きなサンクの場合とそれを潰した場合に、どちらがメモリを消費するかは一概には言えないのです。 少し違いますが、わかりや
nginxを自己満足でセキュリティ強化する（TLSv1.3） - Qiita
おことわり 以下を読んで「は？」って思う方々が読み進むことは推奨できません。 俺は下位互換性なんて知らねぇ！ 最新に対応していないユーザーが悪いんだ！ ゆっくりしていってね！！！ モダンに行こうぜ 僕の趣味は最新に頑張ってついていくことです。 ですので自分しか見ないWebサーバーですが最新のTLSv1.3だけに対応させて悦に浸ろうと思います。 しかし、致命的なことに猿と同じ哺乳類なのでビルドとか難しいことはできません。 aptで手に入るバージョンだけを使って簡単に無駄にハイセキュアな自己満環境を作っていきたいと思います。 幸い現行バージョンではそれが可能です。 雛形 MozillaさんがSSL Configuration Generatorという素晴らしいものを公開してくださっています。 こちらでサーバーとセキュリティレベル、環境、オプションを選択すると自動で最適な設定を教えてくれます。
[小ネタ] SQLの GROUP BY / ORDER BY には数字 (1, 2...) を指定しよう - Qiita
-------------------------------------------------------- -- users テーブルについて、部署・役職・作成日ごとに件数を集計する -- (MySQL用) -------------------------------------------------------- SELECT u.department_code `部署コード`, u.role_code `役職コード`, DATE_FORMAT(u.created_at, '%Y-%m-%d') `作成日`, COUNT(*) `人数` FROM users u GROUP BY u.department_code, u.role_code, DATE_FORMAT(u.created_at, '%Y-%m-%d') ORDER BY u.department_code ASC
![[小ネタ] SQLの GROUP BY / ORDER BY には数字 (1, 2...) を指定しよう - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/df7a32ffb8e562dfe0678d701a1eb4d8a4f7969b/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU1JUIwJThGJUUzJTgzJThEJUUzJTgyJUJGJTVEJTIwU1FMJUUzJTgxJUFFJTIwR1JPVVAlMjBCWSUyMCUyRiUyME9SREVSJTIwQlklMjAlRTMlODElQUIlRTMlODElQUYlRTYlOTUlQjAlRTUlQUQlOTclMjAlMjgxJTJDJTIwMi4uLiUyOSUyMCVFMyU4MiU5MiVFNiU4QyU4NyVFNSVBRSU5QSVFMyU4MSU5NyVFMyU4MiU4OCVFMyU4MSU4NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9ODUwOGYxZDE3YzZhN2I1YTk5NzU4NzkxNjhhNmRiMjc%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzc2Mta3NhaXRvdSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MzhjNGQzYzhlM2QxYzU5YzFkNjE3M2I2NWNiMjMyNTM%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4gU1NDIFImRA%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D9ffdf1c689130de3ed7e5b18c77600c2)
Python 3.12で増えた並列処理と、これまでの並列処理の挙動を比べてみる - Qiita
この記事ですることを3行で Pythonの標準ライブラリでできる並列実行を、あらためて総当たりで速度比較しよう ウォーターフォールチャートで、それぞれの並列処理の処理時間の特徴を可視化しよう boto3の実行をモデルケースにして、どの並列処理が一番早いのかを調べよう この記事の結論を先に Python 3.12から本格的に使えるようになったサブインタープリターは、CPUで実行する処理について言えば、従来のサブプロセスよりも高速 boto3の実行は、サブインタープリターよりも署名付きURLの非同期実行のほうが速い → S3からの10ファイルの取得であれば、実行時間を90%削減できます → Bedrockの3回実行であれば、実行時間を60%削減できます 今回使ったソースコードはこちらに置いています。 お手持ちの環境で再実行できるようにしていますので、気になる方はぜひ。 どうしてこの記事を書くの
金子勇さんのED法を実装してMNISTを学習させてみた - Qiita
追記：続きを書きました。 はじめに 先日以下の記事が投稿され、その斬新な考え方に個人的ながら衝撃を受けました。 内容をざっくり言うと、ニューラルネットワークの学習を現在の主流であるBP法（誤差逆伝播法）ではなく、ED法（誤差拡散法）という新しい学習手法を提案しているものです。 もし記事の内容が本当ならニューラルネットワークの学習がO(1)でできてしまう事になり、まさしく革命が起きてしまいます。 （結論からいうと速度面はそこまででもなかったです（それでも早くなる可能性あり）） （ただこの新手法のポテンシャルは革命を起こす可能性は秘めているといっても過言ではありません） ED法に関してネットを探すとインターネットアーカイブに情報が少し残っていました。 このページですがED法のサンプルプログラム（C言語）が残っており、このサンプルプログラムをベースにpythonで書き起こしたものが本記事となりま
機械学習による株価予想の十八手 - Qiita
1. 株価はサプライズによって動く 株式相場には常にプロの投資家がうごめいており、各銘柄の各種業績数値を常に予想して投資活動をしている。そんな状況下において、仮に「売上が前年比2倍」という決算が発表されても、株価が2倍になるわけではない。むしろ3倍が予想されていたのに、2倍だったら失望売りとなる。つまり事前予想と比較してこそ意味があり、staticな値や過去実績との比較を特徴量にすることはあまり意味がない。事前予想と決算の乖離、または前回予想と今回予想の乖離こそが意味のある特徴量であると言える。 2. 業績数値の単純な変化率では株価インパクトは測れない 営業利益の事前予想100億円に対し、決算が200億円の場合、 変化率 = （ 実績 - 予想 ) / 予想 の計算式を使うと、変化率は100%となる。 この変化率を特徴量にするのは一見もっともらしいが、株においてはこれは使いづらい。 営業利
たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話： この記事の本旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは？リファクタリング耐性低くない？みたいな話は度外視してます。
Numpyが18年ぶりのメジャーアップデート！ 改善点、変更点まとめ - Qiita
NumPy 2.0.0の主要な変更点 皆さんもお世話になっているであろう科学計算ライブラリNumPyが、2006年以降初めてのメジャーアップデートを発表しました。そこで、変更点をざっくりとまとめてみました。以下は変更点の一部であり、それ以外については実際のドキュメントを参照してください。 免責事項：この記事は、NumPy 2.0.0の変更点について個人的な見解を述べたものであり、NumPyの開発チームや関係者の公式な見解を代表するものではありません。変更点の影響や対応方法については、必ず公式のリリースノートと移行ガイドを参照してください。また、この記事には不正確な情報が含まれている可能性があります。記事の内容を実際のプロジェクトに適用する前に、必ず公式ドキュメントで情報を確認してください。 概要 2006年以来の最初のメジャーリリース 破壊的な変更あり 多くの新機能とPython/C AP
XXmallocのメモリ管理アルゴリズムについてわかりやすい記事 - Qiita
dlmalloc, tcmalloc, jemallocについて，以下の各記事を読めば各mallocのアルゴリズムはわかるはず． dlmalloc Linuxの一部やAndroidのDalvik VMで利用されている．シンプルながらうまく考えられている． チャンク(連続空き領域1つ)の境界と構造体の境界が違う所が罠． http://g.oswego.edu/dl/html/malloc.html http://mkosaki.blog46.fc2.com/blog-entry-241.html にわかりやすい講演資料が，と思ったら動画がprivateになってる… tcmalloc thread-caching malloc. Googleで利用されている． スレッドがキャッシュ持つのでfreeしてもメモリ利用量が減らない!のが罠． http://goog-perftools.sourcef
2024東大理系数学第3問をsympyで解く - Qiita
2024東大理系数学第3問 連立漸化式を行列表示する (1)で答える，とりうる点を反時計回りに点$\mathrm{C}_0, \mathrm{C}_1, \ldots, \mathrm{C}_7$とおきます。 そして，$n$秒後に点$\mathrm{P}$ が $C_k$ にいる確率を $p_{n,k}$ とおくと，$n$秒後から$n+1$秒後への推移は次の行列で表されます。 \begin{pmatrix} p_{n+1,0}\\ p_{n+1,1}\\ p_{n+1,2}\\ p_{n+1,3}\\ p_{n+1,4}\\ p_{n+1,5}\\ p_{n+1,6}\\ p_{n+1,7} \end{pmatrix} =\frac{1}{6} \left( \begin{array}{cccccccc} 0 & 1 & 0 & 2 & 0 & 1 & 0 & 2 \\ 1 & 0 & 2
個人的に利用しているBashの機能紹介 - Qiita
この記事はMicroAd Advent Calendar 2021の13日目の記事です。 概要 この記事では，Bashで利用できるシェルの機能について，個人的に最低限必要に感じるものについて紹介します． 必要かどうかや，便利かどうかは筆者の主観的ですので，参考までにしていただければ幸いです． コマンド履歴を使いやすくする シェルの実行履歴に関する設定は以下のようなものがあります． メモリに保存する履歴数(HISTSIZE) ファイルに保存する履歴数(HISTFILESIZE) 履歴のフォーマット(HISTTIMEFORMAT) 履歴に残さないコマンド(HISTIGNORE) これらは，以下のように環境変数で設定可能です． export HISTSIZE=10000 export HISTFILESIZE=10000 export HISTTIMEFORMAT="%Y/%m/%d %H:%M
画像から3次元復元しよう！バンドル調整をpythonで実装してみる - Qiita
はじめに バンドル調整（Bundle Adjustment）は、複数のカメラからの画像データを使用して、カメラの位置と姿勢と三次元点の位置を同時に最適化する手法です。最初の論文は、1958年にD. C. Brownによって提案された1、かなり長い歴史を持つ技術です。 当時はアメリカ空軍が航空写真からの環境復元するための研究でしたが、近年では、visual-SLAMやSfMの普及とともに、より身近なところで使われるようになりました。 有名なvisual-SLAM（例：orb-slam2やVINS-Mono）は、ceresやgtsam、g2oなどのグラフ最適化ライブラリを利用してバンドル調整問題を解いています。しかし、内部の原理をちゃんと理解しないと、課題の改善ができない、独自の研究や発展につながらない可能性が高いです。 この記事では、初心者に向けバンドル調整の理論の紹介と式の導出を行いながら
ロボット技術者向け 速習(2) リー群・リー代数を使った3次元剛体変換 - Qiita
はじめに 前編「3次元回転群」はリー群・リー代数による3次元の回転表現を議論したが、ロボティクス工学の世界では、回転運動だけではなく、並進運動も重要である。回転変換と並進変換の組み合わせによる変換は、物体の形状を変化せずに行うことができ、一般的には剛体変換と呼ばれる。 最新のSLAMやロボット運動学の論文では、頻繁的にリー群による剛体変換が用いられている。ロボット技術者として、最新の研究成果を追いかけるためには、これらの知識を理解する必要がある。しかし、Web資料や教科書などに情報が存在するものの、相当な数学力がないと理解しにくい。 本稿の目的は、ロボット技術者に必要な剛体変換群の知識をできるだけわかりやすく解説する。本稿の説明は、前編の内容を理解する必要があるので、もし「3次元回転群」がわからない方はまず前編を読んでください。 また、他のWeb資料や教科書ではリー群の指数写像と対数写像の
業務でAWSを利用する時に知っておくべきポイント10選 - Qiita
2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro
超高速！多倍長整数の計算手法【前編：大きな数の四則計算を圧倒的な速度で！】 - Qiita
1. はじめに ～メインを読むための準備～ まず、大きな数の計算の話をする前に、少しコンピューターと計算回数について話しましょうか。 コンピューターは、現代ではソフトウェアやアプリケーションの開発に使われていますが、これには重要な背景があります。これは「計算がめっちゃ速いこと」です！人間なんかと比べたら、圧倒的な計算スピードを誇ります。 1-1. 人間の計算速度はどのくらい？ まず人間はどのくらいの速度で計算できるでしょうか？速い人も遅い人もいると思います。 例えば、$628 \times 463$ の計算を、今やってみましょう。10 秒以内で計算できたらかなり速い方でしょう。この計算では、次のように「単純計算」を合計 28 回もしていることになります。 9 回の 1 桁 × 1 桁の掛け算 6 回の 1 桁 × 1 桁の足し算 13 回の繰り上がり計算 もし $628 × 463$ が
Terminalizerのススメ - Qiita
なにげなく JavaScript Open Source Award 2019 を眺めてたら、Terminalizerというターミナルの画面キャプチャツールが紹介されてて使いやすそうでした！ Node.jsが入ってれば npx terminalizer ですぐ記録・再生・公開できる 記録した後から内容を変更できる デザインが変更しやすい GIFに変換する時は若干重い(?) キャプチャの仕方 実際にTerminalizer自身でインストールから実行するまでをキャプチャしてみます。 # インストール npm install terminalizer --global # hogeという名前で操作の記録開始(Ctrl-Dで記録終了) terminalizer record hoge # hoge.ymlで保存された操作を実行 terminalizer play hoge
新幹線でもQUICで快適にSSHする - Qiita
はじめに 今日は、劣悪な通信環境でも快適にSSHができるquicssh-rsをご紹介します。そして、実際に改善されるかを試してみます。 長くなったので最初に結論 quicssh-rsを使うと、 パケットロスに対して明らかに強くなった こちらのIPアドレスが変わっても通信が継続できた 遅延(pingのRTTが大きいこと)は改善されない模様 30%パケットロス環境での比較 IPアドレスを変更しても切れない SSHは新幹線(劣悪通信環境)に弱い 鉄道での移動時間が長いと、パソコンを開いて各種開発の続きをしたくなります。 …なりませんか？ 時には、別のサーバーにSSHでログインして何かコマンドを打ったり。 在来線1であれば概ね問題ありませんが、新幹線になると通信品質が大きく悪くなるため、SSHでの操作は大きなストレスが溜まりがちです。なんとかならないかとずっと思っていました。 新幹線の通信環境 通
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜファイルの末尾に改行を入れたほうが良いのか - Qiita
git worktreeを使ってみる - Qiita
