web-dev-qa-db-ja.com

駐車スペース割り当てシステムのアルゴリズム

私のオフィスでは、車でオフィスに来る200人の従業員がいます。しかし、私の駐車スペースには160台の駐車スペースしかありません。次に、駐車スロットを公平に割り当てて従業員に駐車チケットを発行するアプリケーションを設計および開発したいと思います。

この問題を解決するために、私は以下のようなアルゴリズムを設計することを考えていました:

200人の従業員、5営業日、160の空き駐車スペースがあります。 5色のプールを作成し、各従業員に1色を割り当てます。

  1. 40-緑-月、火、水、木
  2. 40-青-火、水、木、金
  3. 40-赤-水、木、金、月
  4. 40-白-木、金、月、火
  5. 40-黒-金、月、火、水

これにより、1日のオフィスに来る車は160台だけになります。

次に、上記のアルゴリズムを拡張して、このシステムを次のユースケースでより効果的かつ効率的にしたいと思います。

従業員は休暇を申請することができます。そのような場合、割り当てられたチケットは使用されず、駐車スロットは空のままです-リソースの非常に効率的な使用ではありません。その空き枠を公平に他の社員に配分したい。

これを解決するための最も最適な、または少なくとも、より最適なアルゴリズムは何ですか?

3
user317612

カラーコードの説明方法を変更すると、このシステムを理解しやすくなります。

Blue  = No parking on Mon 
Red   = No parking on Tue  
White = No parking on Wed 
Black = No parking on Thr
Green = No parking on Fri 

これを確認したら、これは実際には複雑な問題ではありません。

従業員は休暇を申請することができます。そのような場合、割り当てられたチケットは使用されず、駐車スロットは空のままです-リソースの非常に効率的な使用ではありません。その空き枠を公平に他の社員に配分したい。

これを解決するための最も最適な、または少なくとも、より最適なアルゴリズムは何ですか?

月曜日です。病気で電話しています。グリーンチケットを持っています。青いチケットを持っている人はそれを使うことができます。帽子から青いチケット名を選び、その日の私の緑のチケットを渡してください。できました。

誰かが勝つ前に誰かが2度勝つことを恐れる場合、1つのデッキのシャッフルに切り替えることができます。誰かに有利になる確率を傾けるわけではありませんが、誰かがどれほど不運になるかを制限します。欠点は、状態を保存する必要があることです。

幸運な勝者は、彼らがバスに乗る前に私が電話したことを望んでいるだけです。これらのチケットの割り当ては簡単です。割り当ての変更を伝えることは解決するのが難しい問題です。

5
candied_orange

駐車場オークション

オークションは多くの場合、希少なリソースへのアクセスを規制するために使用され、多くの人々によって公正なメカニズムと見なされています。メカニズム(比較的単純)をポリシー(会社のポリシーや法的規制に依存する場合があります)から分離してみます。

これは実装の完全なスケッチではなく、具体化する必要があるアイデアの集まりにすぎません。

オークションのメカニズム

利用可能な駐車スロットは、従業員がその日の交通手段を計画できるように、十分に事前に毎日オークションされます。従業員は、定義されたスケジュールで割り当てられたポイントを使用して駐車スロットに入札します(たとえば、各従業員は週の初めに10000ポイントを獲得します)。

毎日のオークションは次のように機能します。

  • その日の入札フェーズが開いている間、従業員はそれぞれの日に入札します。後で追加のポイントを獲得できるため、従業員は現在のポイントバランスより高い入札を行うことができます(以下のポリシーオプションを参照してください)。ゼロ値の入札も可能です。すべての従業員ではなく多くの従業員が休日をとる休日など、それを支払う意思はありません。
  • 入札フェーズが終了する(オークションが開始される)と、すべての入札金額が入札者の現在の残高にクランプされ、入札は降順の金額とタイムスタンプの昇順で並べ替えられます。
  • 駐車枠の数に対応する最初のN個の入札が勝ちます。すべての入札者が同じ金額を支払うように、すべての入札の金額を最低落札金額まで減らすことを決定できます(以下のポリシーオプションを参照してください)。
  • その金額は従業員のポイント残高から差し引かれ、従業員はそれぞれその日のチケットを受け取ります。

従業員はポイントを相互に転送することができます。たとえば、配車を共有する人々のグループがポイントをプールして、オークションで勝つ可能性を高めることができます。これは、経済的にも環境的にも理にかなっています。別のオプションとしては、休暇を取って従業員がポイントを同僚に販売する従業員がいる場合や、部門がポイントの抽選会を開催したい場合があります。これらすべてはユーザー次第であり、オークションシステムの一部ではありません。

(オプション)ポイントマーケットメカニズム

直接の合意に従ってポイント間でポイントを転送できることに加えて、従業員はシステムに組み込まれた市場でポイントを売買できます。これにより、その不便さを補償するのが少し不便な場合でも、公共交通機関を使用する人々が可能になるかもしれません。

従業員は売りオファーと買い注文を市場に出すことができます。既存の売りオファーよりも高い買い注文は、トランザクションで互いに照合されます。

方針

可能なオークションスケジュールとルールはいくつかあります。

  • デイリーオークション
    可能な各日のオークションは、事前に特定の時間、たとえば2日前の午後6時に開催されます。これにより、従業員は予期せぬニーズの変化に対応できます。
  • 毎週のオークション
    すべての曜日のオークションは、前週の金曜日または土曜日に開催されます。各従業員は、駐車場を使用できる日の要約を受け取ります。
  • 最低落札価格を支払う
    一部のオークションでは、落札者が2回目の入札で設定された金額( https://en.wikipedia.org/wiki/Vickrey_auction を参照)とこのシステムへの可能なアプリケーションを支払うオークションの勝者はすべて、最低落札金額だけを支払うことになります。ただし、これによって公平性が向上するか低下するかはわかりません。
  • 現在の残高よりも高い入札単価
    特に、入札とそれぞれのオークションの間に十分な時間がある場合、従業員が現在のバランスよりも多く入札することは理にかなっている可能性があります。彼らが休暇を取っており、その休暇の後の週のオークションに入札したいときの市場または定期的なポイントスケジュールのため。ただし、これにより、他の従業員がオークションに勝つ可能性について誤った認識が生じる可能性があります。

会社は、特別なニーズ(障害、妊娠など)を持つ人々のアカウントを異なる方法で処理することを決定するかもしれません。たとえば、障害のある人が利用できるスロットを用意することが法的に求められている場合や、妊娠中の従業員にボーナスポイントを与えて、毎日の駐車スロットを取得する機会を増やしたい場合があります。

ポイント市場では、それが実際に努力する価値があるかどうかを決定する必要があります(誰かが関与するお金を処理する必要があり、これはロジスティックスおよび法的問題を引き起こす可能性があります)。

技術的な実装とユーザーインターフェイス

ほとんどの人にとっておそらく最も簡単な解決策は、従業員がログインし、公開オークションの概要を確認し、入札し、場合によっては市場に取引ポイントを置くことができるWebサイトです。多くの人にとって、一致するスマートフォンアプリも魅力的かもしれません。

チケットは、電子メールまたはスマートフォンアプリを通じて従業員が利用できるようにすることができます。各チケットには、自動駐車バリアがそのようなバリアを持っている場合に駐車場へのアクセスを許可するために使用できる情報を含むQRコードを含めることができます。

アプリケーションで使用するフレームワーク内で利用可能なスケジューリングメカニズムを使用して、オークションのスケジューリングとポイントの支払いを実装する必要があります。また、将来の日付のオークションを作成し、過去のオークションと入札をクリーンアップするスケジュールも必要です。

オークションパーツのデータベーススキーマスケルトンは比較的単純です。実際に実装する場合は、さらにフィールドを追加する必要があります。

  • 従業員
    • e_id(一意のキー)
    • ポイント(ポイントのバランス)
  • 競売
    • 日付(主キー)
    • slots_available(建設作業またはその他の使用のために駐車スペースの一部が利用できない場合にスロットの数を減らすことができます)
    • オープン(フラグを立てることができるかどうかを示すフラグ。代わりにクロージングタイムスタンプを使用することもできます)
  • 入札
    • e_id(従業員のキー)
    • 日付(オークションのキー)
    • タイムスタンプ(同じ入札単価の関係を壊すため)
    • 落札者(この入札が落札したかどうかを示すフラグ)
2