Window walk optimisation
You want to find a job that is near your home transport wise, near a supermarket, doctors that pays the most and has the cheapest house to buy or rent
We can walk different web sites in an iterative hill climbing algorithm.
Enumerate list of towns, cities and villages
Enumerate houses to rent and to buy at lowest cost sorted first.
Enumerate list of supermarkets near said houses and near job, sort by smallest distance
Enumerate jobs, sorted by most pay first
Now walk all these datasets as an optimisation problem to find a list of efficient combinations of jobs and housing.
This is far better than manually cross referencing data in separate tabs.
+[企画]
A site that walks London transport options and house prices to help find a place to live
This is a dedicated site to this task
良いアイデア。ただし、これを使用して、参加するコミュニティを見つけたいと思います。仕事を探すことは非常に気のめいる提案ですが、それはウェブがいっぱいです。コミュニティ検索の観点から、この問題を誰もフレーミングしていないことは非常にわかりやすいです。 確かに、同じまたは類似の制約を使用して同じ検索を実行しますが、異なる用語を使用します。言語は私たちが自分の考えを形作り表現するために得たすべてです
Good idea. However, I'd like to use this to find a community to join. Looking for a job is a very depressing proposition, but that's what the web is full of. It's very telling that no one is framing this issue in terms of community search. Granted, it'll do the same search using same or similar constraints, but using different lingo. Language is all we got to shape and express our thoughts
Skihappy多面的な多変数問題を見つけるために使用できると思います。コミュニティのデータベースがある場合、理論的には、それらのデータベースプロバイダーはデータを調べるためのAPIを提供する必要があります。
問題は、ウェブサイトが「コミュニティ」という用語を使用しない限り、Googleがウェブサイトを分類しないことです。
Skihappy I suspect it can be used to find any multi faceted multi variable problem. If there is a database of communities then in theory those database providers should provide an API to interrogate the data.
The problem is Google doesn't categorise websites unless the website uses the term "community".
データの列挙とウォーキングを実行することの実際的な懸念について考えました。
データのウォーキングは効率化のために分散できると思います。 各レコードを一度に1つずつ歩くのは意味がありません。ダウンロードするデータはたくさんあります。
データのプロバイダーが各サブ反復をウォークするように、継続スタイルを使用できると思います。
したがって、データのウォークは、コラボレーションするサーバー間の継続です。
I thought about the practical concerns of executing the enumeration and walking of data.
I think the walking of data can be distributed for efficiency. It doesn't make sense to walk each record one at a time. It's a lot of data to download.
I think a continuation style can be used so that the provider of the data walks each sub iteration.
So the walking of data is continuations between collaborating servers.
こういうのが好きです。実際、それは道で終わるわけではありません-私たちの食事の選択と栄養を取ります-それらはウィンドウウォークの最適化のパラメータです-どこで借りるかは私たちが歩く製品やサービスの種類とその順序に依存するかもしれません社会的状況に従事する製品やサービスの数は最適ではない可能性があります-異なる人々（健康かどうか）間でそれらを相互に関連付けて、より良いものを提案しないのはなぜですか（たとえば、「スティーブはジムに歩いてきました、そして彼の血ヘモグロビンレベルやその他のパラメータは良好で、私が知っているそのような「スティーブ」はたくさんあります。アパートの近くにあるジムを検討する必要がありますか？」）そして、それらをパラメータとして「ウィンドウウォークの最適化」を行います。調整されます。
実際、顧客が購入の詳細に関するデータを含むデジタルレシート（紙のレシートではなく）を、購入した各製品/サービスアイテムのサプライチェーンの詳細まで取得すると、製品/サービスのウォークツー最適化が容易になります。データの詳細を取得するために紙の領収書に印刷されたURL（またはQRコード）を使用して、プライバシー（現金支払いの場合でも）を簡単に維持できます。これは、モバイルバンキングアプリとは言わずに、割引に使用するポイントカードを使用して簡単に行うことができます（通常、製品の詳細データは取得されません）。それが行われていない場合、消費者はデータ不足のままになります。カテゴリは次のとおりです。ショッピングレシートデータを取得する方法？
I'd love this kind of thing. In fact, it doesn't end with the path -- take our dietary choices and nutrition -- they are a parameter in window walk optimization -- where to rent may depend on the kind of products and services we walk to, and that sequence of products and services to be engaged with in social circumstances may be sub-optimal -- why not to correlate them across different people (healthy or not), and suggest better ones (e.g., "Steve has been walking to gym, and his blood hemoglobin levels, and other parameters are good, and there are many such 'Steves' that I know, maybe you should consider that gym nearby your apartment?"), and then, based on them as a parameter, the "window walk optimization" would be adjusted.
In fact, walk-to product/service optimization would be easier if customers were to get the digital receipts (instead of paper ones) with data about their purchase details down to supply chain details about each product/service item purchased... It could be easily done preserving privacy (even for cash payments) with a URL (or QR code) printed on the paper receipt to fetch data details. It could easily be done with loyalty cards, that people use for discounts, not to speak with mobile banking apps (which, I guess, generally don't get the products details data). If it is not being done, the consumers are left data-poor. The category is: how to get back the shopping receipts data?
目標は、任意のWebサイトタブを別のタブと相互参照できるようにすることです。したがって、人々は公に利用可能なあらゆる情報を歩くことができます。
私の以前の投稿は、ウォーキングをサーバーにオフロードする特別な方法があることを示唆していました。これは、歩行の問題を変数と列挙のセットとしてアップロードできる一般的なエンドポイントであると思います。サーバーがユーザーに代わってリクエストを行うには、他のWebページのURLも提供する必要があります。
転送するデータが大量になるため、完全な結果セットではなく、上位N個の結果にのみ関心があります。
この歩行の最適化をナップサック問題と組み合わせて、カロリー、脂肪、炭水化物、タンパク質の予算に応じて健康的な食事のレシピをスケジュールすることができます。メニューやレシピのウェブサイト、食料品の買い物のウェブサイトがあるレストランのサイトがあれば、それらをすべて組み合わせることができます!!
この機能を使用して、同時に高性能で安価でエラー率の低いハードドライブを見つけることを想定しています。 （Back blazeはハードドライブの障害統計を公開します）
The goal is that any website tab can be cross referenced with another tab. So people can walk any information that is publicly available.
My previous post implied there would be a special way to offload walking to servers. I envision this being a common endpoint which lets you upload the walking problem as a set of variables and enumerations. You would have to provide the URL of other web pages too for the server to make requests on your behalf.
You would only be interested in the top N results - not the full result set as that would be lots of data to transfer.
You could combine this walk optimisation with the knapsack problem to schedule healthy meal recipes according to a calorie, fat, carbohydrate, protein budget. If you had a restaurant site with a menu or a recipe website or a grocery shopping website - they can all be combined!!
I envision using this feature to find hard drives that are simultaneously high performance, cheap and have low error rates. (Back blaze publishes hard drive failure stats)
なるほどですが、どのように歩きますか？歩きやすいようにするには、メタドライブのようなものが必要だと思います。
ターゲット_条件のクエリ_を記述するための形式について話し合ったと思います（たとえば、Ansibleのロールはマシンのターゲット状態を定義します。これらのロールは目的関数の例です-条件を自動満たすためのクエリの一種です）。 「wantsfiles」について。
興味深いのは、プログラム合成とプログラム検索がどのように歩行の最適化につながるのかということです。
I see, but how will it walk? I think it would require something like the Metadrive to walk easily.
I think we had talked about the formats for describing target queries for conditions (for example, Ansible's roles define target states of machines, these roles are examples of objective functions -- a kind of queries for conditions to auto-satisfy), when we talked about the "wants files".
It's interesting, how program synthesis and program search boils down to walk optimization.
さて、URLを含むヒルウォークを定義するための構文を形式化することを考えました。
サーバーが機能する場合は、プロトコルをサポートするためにサーバー自体を変更する必要があります。
Metadriveは、データ収集をローカルで実行することもできます。それはただより多くのデータ転送をもたらすでしょう。
Well I thought of formalising a syntax for defining a hill walk that includes URLs.
If the servers do the work, then it requires the servers themselves change to support the protocol.
Metadrive could execute the data collection locally too. It would just result in more data transfer.
GUIを使用してウォーク検索を構築するのは、ブラウザプラグインといくつかのGUIである可能性があります。
Excelには、非常に強力なWhatIfという機能があります。セル値をインテリジェントに変更して、目標値を見つけることができます。
It could be a browser plugin and some GUI to build a walk search with the GUI.
In Excel we have a feature called What If which is very powerful. It can change cell values intelligently to find a goal value.