タグ

hashに関するmanabouのブックマーク (38)

  • 大体の位置情報を示すSec-CH-Geohashヘッダ - ASnoKaze blog

    Private Relayをはじめ、Proxyを通してクライアントのIPアドレスをサーバに対して隠す技術が登場しています。 ところで、Webサービスはクライアントの位置情報によって出力する情報を変えたり、最適化を行う場合があります。JavaScriptのGeolocation APIから取得することもあるでしょうが、APIアクセスなどJavaScriptが利用できない場合もあるでしょう。その場合、IPアドレスから位置情報を類推する手段(GeoIPなど)があります。 IPアドレスから位置情報をある程度推測する手法は、IPアドレスが隠されると機能しなくなります。 Private Relayではユーザが望む場合は、Webサーバに対して大体の位置情報を提供するという観点について、IETF 111の発表で触れています。 (https://datatracker.ietf.org/meeting/11

    大体の位置情報を示すSec-CH-Geohashヘッダ - ASnoKaze blog
  • Wi-Fiのパスフレーズを「パケットを食べる」ことで解析する電子ペットキット「Hash Monster」

    Wi-Fiの脆弱性を突いてその情報を収集する「Pwnagotchi(ポーナゴッチ)」は、Raspberry Pi Zero Wをベースとして「たまごっち」をヒントに開発された電子ペットキットで、日語にも対応しています。そんなPwnagotchiの影響を受けて開発された「Hash Monster」は、マイコンのESP32を搭載した開発モジュールで動作する電子ペットキットです。 The Hash Monster: ESP32 Tamagotchi For WiFi Cracking — Telescope https://telescope.ac/petazzoni/the-hash-monster-esp32-tamagotchi-for-wifi-cracking PwnagotchiはWi-Fi技術規格であるWPAやWPA2に存在する脆弱性を利用して、Wi-Fiのパスフレーズ特定につ

    Wi-Fiのパスフレーズを「パケットを食べる」ことで解析する電子ペットキット「Hash Monster」
  • Google はどうやって Deep Learning でメモリ使用量を 99% 削減したか。

    NewsPicksエンジニア採用サイトです。さまざまな強みを持つエンジニアが、自分たちの個性を活かし、未来を創るための挑戦をしてる自由な環境で、一緒に世の中をおもしろくしてみませんか?

    Google はどうやって Deep Learning でメモリ使用量を 99% 削減したか。
  • 地形プロシージャル生成 - パーリンノイズアルゴリズム - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    地形プロシージャル生成 - パーリンノイズアルゴリズム - Qiita
  • 【決定版】コンピュータ将棋のHASHの概念について詳しく | やねうら王 公式サイト

    いまどきの将棋ソフトを使っていると、「HASH 50%」などと表示されている。これはHASH利用率と呼ばれる。この数字が大きくなってくると探索の効率が悪くなる。要するに潤沢にメモリがある場合に比べると弱くなる。これは、どれくらいの値までであるなら適切なのか?HASH利用率が99%にならない限りHASHには余裕があるものなのか?HASHはどういう仕組みになっているのか?HASH利用率が50%の状況で、ハッシュ衝突はしているのか?など、わりとソフトを長年使っていても知らない人が多いのでここに原理から詳しく説明した決定版的な記事を書く。 ShogiGUI将棋神やねうら王に表示されている「HASH」とは何ですか? 一度探索した局面を保存しておく表です。 この表に登録するときにハッシュ(hash)という値を使って登録するため、ハッシュテーブル(hash table)と呼ばれます。これを略して(値と

  • Pythonでブロックチェーンを実装して採掘までやってみたので解説する - paiza times

    Photo by Stock Catalog 秋山です。 皆さんは暗号通貨で遊んでいますか? エンジニアの中には、ブロックチェーンなど暗号通貨で使われている技術に興味がある…という人も多いのではないでしょうか。最近は、ブロックチェーンを活用した新しいモノもどんどん増えていますね。 というわけで今回は、ブロックチェーンや採掘(≒Proof of Work)について、Pythonでコードを書きながら説明してみたいと思います。 ■ブロックチェーンをPythonで実装してみる 最も単純なブロックチェーンの場合、ブロック単位のデータにハッシュ値があり、そのハッシュ値は一つ前のブロックのハッシュ値を含んで計算されています。そのため、すべてのデータはチェーン上に繋がって前後関係のもとにある…という状態です。 ハッシュ値が何かわからない人はググったりして調べていただければと思いますが(ハッシュ値(ダイジェ

    Pythonでブロックチェーンを実装して採掘までやってみたので解説する - paiza times
  • ハッシュ値の使い方について - クックパッド開発者ブログ

    モバイル基盤グループのヴァンサン(@vincentisambart)です。 先日以下のツイートを拝見しました。 Swift's stdlib moves to randomly seeded hashing: https://t.co/2T5oRYtD8B— ericasadun (@ericasadun) 2018年3月10日 この変更はSwift 4.1にはまだ入りませんが、4.2か5.0に入るはずです。コードレビューでこの変更が問題を起こそうなコードを指摘したことあるので、ハッシュ値のおさらいをする良いタイミングではないでしょうか。 Swiftのことを考えて書いていますが、多くのプログラミング言語にも当てはまります。ハッシュ値はSwiftではhashValueというプロパティが返しますが、多くの言語では単にhashというメソッド・関数が返します。 ハッシュマップ ハッシュ値はハッシュ

    ハッシュ値の使い方について - クックパッド開発者ブログ
  • PostgreSQL v11新機能先取り:Hash-PartitioningとParallel-Append - KaiGaiの俺メモ

    今回のエントリーは PostgreSQL Advent Calendar 2017 - Qiita に参加しています。 PG-Stromの視点からも、PostgreSQL v11には首を長くして待っていた機能が2つ入っている。 その1:Hash-Partitioning github.com その2:Parallel-Append github.com Hash-Partitioningというのは、PostgreSQL v10で追加されたテーブルパーティショニング機能の拡張で、日付時刻などの幅(Range)でパーティション化を行うのではなく、レコードの値をハッシュ関数に通して得られた値を元に、振り分ける先の子テーブルを選択して書き込みを行うというもの。 特徴としては、データの母集団が特異なものでない限り*1、各子テーブルへの書込みは均等に平準化されることになる。これは後で説明する通り、子テ

    PostgreSQL v11新機能先取り:Hash-PartitioningとParallel-Append - KaiGaiの俺メモ
  • 意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama

    プログラムを書いていると、素直に実装した結果として毎回特定の条件が満たされているけど、来それは誰も保証してないという場面に出くわすことがよくある。保証されていない偶然の動作に依存することで生じるバグというのはかなり多い。 例えば最近では、ドラゴンボールZ ドッカンバトルというゲームで、2回SQL文を実行した結果が同じ順序で並んでいるという誤った期待をしているコードがあったせいで、ガチャの確率表示がめちゃくちゃになってしまって、運営が確率操作しているのではないかという騒動が発生したことがあった [1]。データベースでは空のテーブルにデータを追加してその直後に読み返すと、データを追加した順番に結果が返ってきたりしがちなので、問題のコードはきれいなテスト環境では偶然うまく動いてしまったのだろうと思う。 上のようなバグを防ぐために最近よく使われているのは、来保証しないところをわざと壊すという方

    意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama
  • 「いいね!」増えるハッシュタグ、AIが提案、 東大が新技術

    SNSの投稿画像に付けるハッシュタグを人工知能が提案し、閲覧数や「いいね!」などを向上させられる技術東大が開発した。 東京大学は、SNSに投稿する画像・動画の「人気度」を向上させられるハッシュタグを、人工知能AI)が提案する技術を開発した。AIが提案するハッシュタグを付けて約2000枚の画像を投稿したところ、人が付けたタグだけの場合より、2倍の閲覧数を獲得できたという。 人が付けた既存のタグに関連が深く、閲覧数や「いいね!」など「人気度」への影響力が強いタグを推薦できる計算手法「FolkPopularity Rank」を開発。画像や動画に付いているタグとその人気度を数学的なグラフ(行列)で表現し、どのタグ同士が同時に用いられることが多いかを考慮しながら反復的に計算することで、各タグの人気度への影響を数値化・ランキングする。 スコア計算にかかる時間は「通常のサーバで数秒程度」と短いため、

    「いいね!」増えるハッシュタグ、AIが提案、 東大が新技術
  • Maglev Hashing with Python - yunazuno.log

    今更ながら,GoogleのMaglev論文で提案されているMaglev Hashingを手元で実装してみた. Maglev: A Fast and Reliable Software Network Load Balancer Maglev Hashingとは 所謂Consitent Hashの一種.Maglevロードバランサにおけるリアルサーバ選択に使用されている. 上記論文のSection 3.4で詳細が説明されている.NSDI'16での発表スライドも併せて眺めると分かりやすい. Maglev: A Fast and Reliable Software Network Load Balancer | USENIX Slide: https://www.usenix.org/sites/default/files/conference/protected-files/nsdi16_sli

    Maglev Hashing with Python - yunazuno.log
  • 私が書いた最速のハッシュテーブル – PART 3 | POSTD

    テーブルを、異なるmax_load_factor()と比較する 先に示した最後のグラフは、私のテーブルとgoogle::dense_hash_mapがmax_load_factorに0.5を使う一方で、std::unordered_mapとboost::multi_indexが1.0を使って動作検証を行っていました。もしかすると他のテーブルも、低いmax_load_factorの値を使えば、より速くなるのではないでしょうか? それを確かめるため、最初のグラフ(成功したルックアップ)に使ったのと同じベンチマークを実行しました。ただし、どのテーブルもmax_load_factorは0.5に設定しました。そして、テーブルの再割り当ての直前に測定を行いました。もう少し詳しく説明しますが、まずは次のグラフをご覧ください。 注釈: 成功したルックアップの占有率(load factor) 0.5 (縦軸

    私が書いた最速のハッシュテーブル – PART 3 | POSTD
  • 私が書いた最速のハッシュテーブル – PART 2 | POSTD

    素数か2のべき乗か ハッシュテーブルのアイテムをルックアップする際に高負荷なステップが3つあります。 キーをハッシングする キーをスロットにマッピングする 該当スロットのメモリをフェッチする ステップ1は、キーが整数であれば、低負荷になります。単にintをsize_tにキャストするだけです。しかし、文字列のようなタイプのキーの場合は高負荷となります。 ステップ2はよくある整数モジュロ演算です。 ステップ3はポインタの間接参照です。std::unordered_mapの場合は複数のポインタ間接参照となります。 処理の遅いハッシュ関数でなければ、直観的にステップ3が最も高負荷になると考えると思います。しかし、全てのルックアップでキャッシュミスが生じなければ、整数モジュロが最も高負荷な処理となります。現代のハードウェアにおいても整数モジュロは非常に遅いのです。 Intelマニュアル では、整数モ

    私が書いた最速のハッシュテーブル – PART 2 | POSTD
  • 私が書いた最速のハッシュテーブル – PART 1 | POSTD

    結局、やり出したら止まりません。私は以前、” I Wrote a Fast Hashtable(私が書いた高速なハッシュテーブル) “という記事と、それに次いで” I Wrote a Faster Hashtable(私が書いたより高速なハッシュテーブル) “という記事をブログにアップしましたが、今回ついに、最速のハッシュテーブルを書き上げました。これが意味するところは、ルックアップがどのハッシュテーブルよりも速いということです。それに加えて、挿入や削除も(最速とまではいかないまでも)非常に速く行えます。 秘訣は、探索回数の上限を設定したロビンフッドハッシュ法を使用することです。ある要素が、その理想的な位置からX数以上、離れた位置にある場合、テーブルを拡張することで、全ての要素が、その大きなテーブル内において、理想的な位置に近づくようにします。結果的に、このやり方は非常にうまくいきました。

    私が書いた最速のハッシュテーブル – PART 1 | POSTD
  • Hash indexes are faster than Btree indexes?

    PostgreSQL have supported Hash Index for a long time, but they are not much used in production mainly because they are not durable.  Now, with the next version of PostgreSQL, they will be durable.  The immediate question is how do they perform as compared to Btree indexes. There is a lot of work done in the coming version to make them faster. There are multiple ways in which we can compare the per

    Hash indexes are faster than Btree indexes?
  • GitHub - skarupke/flat_hash_map: A very fast hashtable

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - skarupke/flat_hash_map: A very fast hashtable
  • 高速なハッシュテーブルを設計する | POSTD

    (訳注:2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) はじめに 稿では、高速で汎用的なハッシュテーブルを作るために行う、設計についての多くの意思決定事項を紹介します。最終的に、私の emilib::HashSet とC++11の std::unordered_set の間のベンチマークが出来上がりました。もし、ハッシュテーブルに興味があって、自分で設計したいなら(どのプログラミング言語かに関わらず)、稿がヒントになるかもしれません。 ハッシュテーブル は、素晴らしい発明です。 ならし計算量O(1) ( O(√N)時間 )で、挿入、削除、検索を行うことができます。ならし計算量とは、ハッシュテーブルの計算に平均でO(1)の計算量がかかることを意味しますが、時々、これよりも多くの時間がかかる場合があります。具体的には、ハッシュテーブルに空きがない場合で、挿入の

    高速なハッシュテーブルを設計する | POSTD
  • モジュロ演算の替わりとなる高速処理 | POSTD

    N 個の要素セットの中からランダムに整数を1つ取り出すと仮定します。使っているコンピュータに32ビット整数の乱数を生成する機能がある場合、その数をどのように N より小さいインデックスに変換すればいいのでしょうか。例えば、サイズが N のハッシュテーブルがあると仮定します。このような場合でも、ハッシュ値(通常32ビットや64ビットの整数)を N より小さいインデックスに変換する必要があります。このような場合、大抵プログラマは解決の際、 N が2のべき乗であるようにしますが、これは必ずしも理想的とは言えません。 任意の整数 N をできるだけ公平にマッピングしたいとします。2 ³² 個存在する32ビットの整数全てから始める場合、{0, 1 ,…, N – 1}の値域に定められた値に、ちょうど2 ³² / N 個の値をマッピングできるようにするのが理想的です。 残念ながら、2 ³² は N によ

    モジュロ演算の替わりとなる高速処理 | POSTD
  • Import APIとFuzzy Hashingでマルウエアを分類する ~impfuzzy~(2016-05-09) - JPCERT/CC Eyes

    Top > “マルウェア”の一覧 > Import APIとFuzzy Hashingでマルウエアを分類する ~impfuzzy~(2016-05-09) 一般に、マルウエア検体の調査は、既知のマルウエアかどうかを判別することから始めます。データベース化された多数の既知のマルウエアと調査検体との比較を高速に実行するために、ハッシュ関数をマルウエア検体に施して得られたハッシュ値が利用されます。 ハッシュ関数の中でも、MD5やSHA1などの伝統的なハッシュ関数の場合には、入力データが1ビットでも異なれば、まったく異なるハッシュ値になりますので、完全に同じではないが類似した既知の検体があれば、既知のマルウエアと判定したい場合には役に立ちません。 現在では、カスタマイズされた上で攻撃に使われるマルウエアがほとんどであるため、カスタマイズされた検体を類似していると判断できるようなハッシュ関数が望まれ

    Import APIとFuzzy Hashingでマルウエアを分類する ~impfuzzy~(2016-05-09) - JPCERT/CC Eyes
  • Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング

    こんにちは。サーバサイドエンジニアの @DQNEO です。 前回の「Gitのつくりかた」に続いてGitのコアな部分のお話です。 Gitのコミットハッシュ値とは何か Gitを使っていると必ずコミットハッシュ値というものが出てきます。9e47c22みたいなアレです。 これはある特定のコミットを指し示すIDとして使うことができます。 では質問です。 このコミットハッシュ値は「何を元に」「どうやって」計算されているでしょうか? 「ある特定のコミット」とはそもそも何なのか この問題を考える前に、まず「コミットとは何か」を明らかにしておきましょう。 コミットというと「コミットする行為」すなわち「動作」のことを想像するかもしれません。 しかしGitの内部構造的観点から言うと、Gitが管理記録しているのはコミット行為の結果生成されたデータの方です。 この「コミットによって生成されたデータ」のことを「コミッ

    Gitのコミットハッシュ値は何を元にどうやって生成されているのか | メルカリエンジニアリング