パスワードを忘れた? アカウント作成
6477914 story
プログラミング

高専プロコン、「サイコロの個数を数える」という課題に対し人力で数えたチームが優勝 111

ストーリー by hylom
専門家がトライしでもこれは難しいのでは 部門より
あるAnonymous Coward 曰く、

全国高等専門学校 第23回プログラミングコンテストが10月13日、14日にかけて行われたのだが、このコンテストの競技部門の結果が話題になっている。

競技部門のテーマは、「大きさの異なる3種類のサイコロの数を数える」というもの(募集要項PDF)で、画像処理によってサイコロの数を数えることが想定されていた。しかし、実際に優勝したチームは人力でサイコロの数を数えていた(「サイコロの数を手動でカウントするためのカウンターソフトウェア」を開発した)をことが判明、「プログラミング」の意義が問われる結果となった(市況かぶ全力2階建)。

Twitterなどではこの件について「微妙な出題をした運営が悪い」「正攻法(画像処理)でチャレンジしたチームも存在したのに残念」「むしろ人力で高い精度で数えられた優勝チームはすごい」など、賛否両論のようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 去年の対策 (スコア:5, 参考になる)

    by imaic (31975) on 2012年10月16日 13時54分 (#2252239) 日記

    久留米高専の方のようですが
    「人力で解いたほうが速い問題が出た場合には
     人力でやるためのソルバーを用意しておく」
    対策は、以前からやっているようです。
    http://d.hatena.ne.jp/natrium11321/20111224/1324738589 [hatena.ne.jp]

    • by Anonymous Coward on 2012年10月16日 15時15分 (#2252334)

      それはそれで凄いな。大したもの。
      ソリューションってのはそういうもんだ。

      親コメント
  • FAQ (スコア:5, 参考になる)

    by Anonymous Coward on 2012年10月16日 13時56分 (#2252247)
    http://www.procon.gr.jp/modules/smartfaq/faq.php?faqid=271 [procon.gr.jp]より

    Q2.分析において人間(競技者)の情報処理能力を積極的に活用することは許されますか。もし制限がありましたらご提示ください。
    A2.募集要項に書いた以外の制限はありません。

  • by fcp (32783) on 2012年10月16日 22時57分 (#2252696) ホームページ 日記

    しかし、実際に優勝したチームは人力でサイコロの数を数えていた(「サイコロの数を手動でカウントするためのカウンターソフトウェア」を開発した)をことが判明

    「サイコロの数を手動でカウントするためのカウンターソフトウェアを開発した」ってのは、そりゃ開発したかもしれないけれど、重要なのはそこじゃないよね。

    他のサイコロに隠れていて見えないサイコロがあるから、人手だろうが画像処理だろうが、見えているサイコロを数えてその数をそのまま答える、というのでは駄目。そこをどうするかは、見えているサイコロの個数をどう数えるかとは別に考える必要がある。

    宇部高専チームの人が Twitter で書いていること (1 [twitter.com], 2 [twitter.com], 3 [twitter.com], 4 [twitter.com]) によると、方針はたぶんこんな感じ。

    A. 1 回戦のデータから、サイコロの大中小の各サイズについてどれだけの割合が見えているかを計算しておく。
    B. 調査時間の間に、フィールドの見えているサイコロの大中小の個数を人手で数えてその間の比率を計算する。
    C. A の割合を用いて B の比率を補正することで、見えないサイコロも含めた大中小の間の比率を推定する。
    D. サイコロの総重量は知らされるので、大中小の比率さえ決まれば個数がわかる。

    単純だから、たぶん似た方針のチームはほかにもあっただろうけど、大中小の間の比率だけを使うってのはうまいやり方だと思う。

  • 「○○が悪い」なの? (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2012年10月16日 16時07分 (#2252398)

    この件について主催者が頭かかえて真剣に悩んでたり
    競技者がふてくされたり、抗議してたりするの?

    そうでないなら、
    我々外野が、「○○が悪い」みたいに何らかのブツに対して悪者性(?)を求めるのは
    あんま意味無くね?

  • by Anonymous Coward on 2012年10月16日 20時28分 (#2252591)

    某チームの中の人です。

    今回のプログラミングコンテストの競技部門で想定される入力データは

    1.表面上の大中小サイコロの各個数ないしは比率
    2.大中小サイコロ1個あたりの平均重量
    3.サイコロの総重量

    あたりでしょうか?
    あとは隠れているサイコロの処理などを考慮する必要があります。

    表面上の大中小サイコロの各個数については本番まで会場の照明条件がわからないなど、
    画像処理を主体とするチームには分の悪いものでした。

  • by EnergyField (42789) on 2012年10月16日 13時04分 (#2252156) 日記

    人脳こそが最高のプログラムということですな。
    #たしかにこれは運営のプログラミングが悪い

  • by nemui4 (20313) on 2012年10月16日 13時13分 (#2252172) 日記

    マンマシン融合システムのゆるい進化の途中かもしれない。

    レギュレーションに抵触していないなら何も問題はないだろうね。
    人力を超えられないなら機械に頼る必要もないでしょうし。

    • by Anonymous Coward

      参加メンバーが野鳥の会に入っていたかシューティングゲームかスロットの目押しの達人で動体視力が鍛えられていたんだろうか
      とりあえず人力で数えて行く際のコツとか聞いてみたいですね

      • by Anonymous Coward

        書いて思ったけど動体視力というより俯瞰する能力かな?

  • by Anonymous Coward on 2012年10月16日 13時30分 (#2252195)

    お題や競技方法が悪いとしか思えない・・・
    測定機器までお任せってアバウトすぎて
    プログラミングの競技としてどうなの?という感じ。

    ##私も多分手動で数えると思います。

    • by Anonymous Coward on 2012年10月16日 13時48分 (#2252225)

      次からは1週間耐久とかの個数にしましょう

      # それでも人力が勝ったら素直にすごい

      親コメント
    • レギュレーションを読む限り、何の問題もなさそうですよね。人間が調査した情報をもとに、コンピューターで処理して~とか書かれているし、人間の調査した個数をもとに、コンピューターが集計しても何も問題はない。
      俺も重複カウントなどを防ぐための支援ツール作って終わりにすると思う。

      親コメント
    • by Anonymous Coward

      ロジカルシンキングとかのせいでアバウトな問題を出すのが流行ってるからね。
      そういうのに毒されてるとしか思えない。

  • 人力カウント部分のAPIをちゃんと整えておけば堂々とプログラミングで数えたって言えたんじゃないかな

    # メカニカルターク使いこなしてる人って/.Jにいたりするのでしょうか?
    # 私はとっても使いたいんですが、情報漏れの観点で無理

  • by Anonymous Coward on 2012年10月16日 14時02分 (#2252252)

    コマ大チームもたまに正解しているしなあ。

  • by Anonymous Coward on 2012年10月16日 14時06分 (#2252258)

    ってヤツだよね、これ。

  • by Anonymous Coward on 2012年10月16日 23時20分 (#2252706)

    どこかで読んだけど、バグを減らすため、無理してプログラムで計算するなというのがあったな。

    生年月日を入力させておきながら、直後に年齢も入力させるとか。

  • by Anonymous Coward on 2012年10月16日 13時41分 (#2252215)

    コストが安く、しかも精度が良いわけだからOKでしょう。
    (アマゾンのピッキングは手動+専用PDAで倉庫上の保管位置をナビする)
    別に全部を機械化することはないし、すべてを人力で回す必要もない。

    全自動化をやりたければ、測定機器(INPUT側)は決めうちでやんないとダメでしょうね。

    • by Anonymous Coward

      すまん、Amazonってどこから出てきた話?
      協賛してるとか?

      • by Anonymous Coward on 2012年10月16日 14時32分 (#2252282)

        倉庫は自動化されておらず、バッグとPDAを持った人が徘徊して品物を取り出してるんだよ。
        品物も一見バラバラに配置されていて、PDAが発注リストの最適なルートを表示して、
        その指示に従って人がそこまで行って取り出してる。

        ジャンル別に整理して配置してても、それぞれの数が増減すれば置き場の移動が発生したり、
        機械化しようとしても品物(本とか)ごとに大きさが違っていたりして、結果的に効率が悪く
        なるんだってさ。それなら最初から空いてるところにつっ込んで在庫はコンピュータに管理
        させてしまえ、と。人なら品物の大きさの違いなんか関係ないしね。

        問屋など、決まった数をまとめて扱うところだと箱を規格化してしまえば機械化も容易だろうけど、
        単品で扱う小売業なAmazonだとそれは無理だしね。品物ごとに一定の大きさのトレーなどに
        入れて管理する方法もあるだろうけど、それだと今度は場所の無駄が発生するし。

        親コメント
        • by Anonymous Coward on 2012年10月16日 17時55分 (#2252503)

          おととしの夏、ばたばた倒れていてバイトを大量に募集していた

          さすが人力なんだなと感心した。

          親コメント
      • by kicchy (4711) on 2012年10月16日 14時51分 (#2252310)

        Amazonの倉庫システム設計で
        ピッキングを完全機械化せずに、あえて人手を残していますが
        それが、人間をデバイスと考えて、得意の画像認識に使う発想の
        今回の手法と似ているとの指摘でしょう。

        # 私は評価しています。結果として正確に素早く課題をこなして居るわけですから。
        # 人手を認識に使わないほうが早くこなせるスケールの課題もあるとなお楽しそうです。

        親コメント
  • by Anonymous Coward on 2012年10月16日 13時49分 (#2252226)

    プログラミングする時間や人員などまで考慮すると、かなり優秀なコストパフォーマンスなのでは。
    定型作業ではない現場では喜ばれる人材でしょう。

  • by Anonymous Coward on 2012年10月16日 13時50分 (#2252230)

    「コンピュータによる画像解析」はマシンビジョンによる自動的なオブジェクト数のカウントのみを意味するものでは無いだろう.
    資料を読んだが、俺も多方向からカメラで撮影した画像をコンピュータで加工後にプリントアウトして、目視で重複チェックしながらカウントすれば良いだろうと思った.
    調査用機材としてプリンタを持ち込んではいけないとは書いてないし.

    だいたい「コンピュータとデジカメ等の調査用機材を活用して~」と書いてあるんだから、出題者がソフトウェアによる自動計測のみを想定していたとは考えられない.
    プログラミングコンテストとあるが、競技内容がプログラミングとどう結びつくのかがはっきりしないんだから出題のしかたが悪い.

  • by Anonymous Coward on 2012年10月16日 13時51分 (#2252231)

    次回はサヴァンな人を連れてきたチームの勝ちだな。

  • by Anonymous Coward on 2012年10月16日 13時51分 (#2252232)

    すごいアルゴリズムでも、マシンにパワーがなければすごく計算速度はあがらない。

    前に、画像診断の装置のプログラム製作をかじっていたんですが、
    すごい効率的で早い計算アルゴリズムでもなかなか時間がかかるらしく
    どうすればいいってときに、GPGPUでやるというのを思い出した。

    オフトピでした

  • by Anonymous Coward on 2012年10月16日 13時56分 (#2252248)

    同じような計数を数百回繰り返して回答する、といった、
    人力<自動が成立する出題にすべきでしたね。
    比較して人力のほうが正確と結論が出る出題じゃあ文句の言いようはないな。

typodupeerror

Stableって古いって意味だっけ? -- Debian初級

読み込み中...