ロボット、千葉ロッテマリーンズについていいかげんなことを書きます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
この作品って内容的には被っていないけど奨励賞的には被っているような気がします。
ソースコードはよく分かりませんがまだ公開されていないのでしょうか？
どっちにしてもこれだけドキュメントが充実している時点で評価は高いだろうし、かなり厳しくなりそうです。何だか誤字が多いけど。
それにしても、なんで去年は産総研の人は誰も応募しなかったのでしょうね？
レゴマインドストーム EV3のCPUの性能を考えるとRTCを何十個も動作させるとかは考えない方がよさそうです。
そもそもツールが充実しているのでLinuxが動作してもありがたみを感じる人は少ないのではないでしょうか？例のごとく持っていないので完全に想像ですが。
この製品を購入する人がどういう層の人なのかが分かりません。ピンからキリまでいるのでしょうけど、それが問題です。多分ですけどCUIでの操作自体を全く経験したことがない人も多いと思いますよ。コマンドプロンプト自体を見たことがない人も多いかもしれないです。
RTMユーザーだって「Linuxを使える」と言う人は多いと思いますけど、メインはWindowsかMacの人がほとんどだと思うので、CUIでの操作が当たり前だと思ってはいけません。
CUIでの操作を日常的にやっている人なんて、パソコンを所持している人全体の中ではかなり貴重です。
どうにもこの作品はコマンドラインで操作するツールが中心みたいですけど、レゴマインドストーム EV3のユーザーにどの程度需要があるのかは未知数です。
あまりレゴマインドストームのユーザーがCUIを使っているイメージはないのですが、僕の勝手な考えなので真偽は定かではありません。
あまり話すこともないので感想はソースコードが公開されてから書きます。
レゴマインドストーム EV3を持っていたら別ですけど、それなりに高いですからね。
RTCをソースコードのみ配布してこちらでビルドするようにしている人も多いですが、そもそもビルドに失敗するかどうかも考えなければなりません。
一番可能性として高いのは依存ライブラリの問題です。
Boostはどうにもバージョンが変わるとエラーが出なかった場所からエラーが出るなんて事は珍しくないみたいなので注意が必要です。
意外に気づきにくいのがC++11で変更された機能で、
std::vector<int> v{ 0, 1, 2 };
はVC++2010以前ではエラーが出るみたいです。
なのでC++11、C++14の新機能を使う場合は注意は必要です。
あまり関係ないけど、どうにも僕はラムダ式が苦手です。全部関数で書けよとか思ったりします。
それから昔から条件演算子が苦手です。全部if文で書けよと思っています。
CMakeLists.txtの記述の問題ですけど、GCCでC++11の機能を使うには-std=c++11のオプションを追加する必要があります。
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
実際にはこのページみたいに書くみたいです。
GCCのバージョンが古い場合は -std=c++0xのオプションを追加します。
ビルド済みの実行ファイル、DLLで配布するのが確実ですけど著作権的に無理な場合もあるかもしれないので、もしもソースコードで配布する場合は以上の点には注意してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ソースコードはよく分かりませんがまだ公開されていないのでしょうか？
どっちにしてもこれだけドキュメントが充実している時点で評価は高いだろうし、かなり厳しくなりそうです。何だか誤字が多いけど。
それにしても、なんで去年は産総研の人は誰も応募しなかったのでしょうね？
レゴマインドストーム EV3のCPUの性能を考えるとRTCを何十個も動作させるとかは考えない方がよさそうです。
そもそもツールが充実しているのでLinuxが動作してもありがたみを感じる人は少ないのではないでしょうか？例のごとく持っていないので完全に想像ですが。
この製品を購入する人がどういう層の人なのかが分かりません。ピンからキリまでいるのでしょうけど、それが問題です。多分ですけどCUIでの操作自体を全く経験したことがない人も多いと思いますよ。コマンドプロンプト自体を見たことがない人も多いかもしれないです。
RTMユーザーだって「Linuxを使える」と言う人は多いと思いますけど、メインはWindowsかMacの人がほとんどだと思うので、CUIでの操作が当たり前だと思ってはいけません。
CUIでの操作を日常的にやっている人なんて、パソコンを所持している人全体の中ではかなり貴重です。
どうにもこの作品はコマンドラインで操作するツールが中心みたいですけど、レゴマインドストーム EV3のユーザーにどの程度需要があるのかは未知数です。
あまりレゴマインドストームのユーザーがCUIを使っているイメージはないのですが、僕の勝手な考えなので真偽は定かではありません。
あまり話すこともないので感想はソースコードが公開されてから書きます。
レゴマインドストーム EV3を持っていたら別ですけど、それなりに高いですからね。
RTCをソースコードのみ配布してこちらでビルドするようにしている人も多いですが、そもそもビルドに失敗するかどうかも考えなければなりません。
一番可能性として高いのは依存ライブラリの問題です。
Boostはどうにもバージョンが変わるとエラーが出なかった場所からエラーが出るなんて事は珍しくないみたいなので注意が必要です。
意外に気づきにくいのがC++11で変更された機能で、
std::vector<int> v{ 0, 1, 2 };
はVC++2010以前ではエラーが出るみたいです。
なのでC++11、C++14の新機能を使う場合は注意は必要です。
あまり関係ないけど、どうにも僕はラムダ式が苦手です。全部関数で書けよとか思ったりします。
それから昔から条件演算子が苦手です。全部if文で書けよと思っています。
CMakeLists.txtの記述の問題ですけど、GCCでC++11の機能を使うには-std=c++11のオプションを追加する必要があります。
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
実際にはこのページみたいに書くみたいです。
GCCのバージョンが古い場合は -std=c++0xのオプションを追加します。
ビルド済みの実行ファイル、DLLで配布するのが確実ですけど著作権的に無理な場合もあるかもしれないので、もしもソースコードで配布する場合は以上の点には注意してください。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
PR
僕の勝手な考えなのですが、どうにも最初からRTCで実装しようとすると失敗するのではないかと思います。
まずは単一のプログラムで実装する事を目指して、それから切り離せる部分は切り離していけばいいのではないですかね？何だか似たような事を言ったような記憶がありますけど。
やりがちな失敗として他のRTCに依存しすぎるという事があります。
そもそもコンポーネント指向の基本として「コンポーネント間の依存を少なくする」と言う事があると思います。
「はじめてのコンポーネント指向ロボットアプリケーション開発 ~RTミドルウェア超入門~」ではやたらとこの点を押してきます。RTM関連の人は大抵この本を読んでいると思うので、分かっていても間違うのだから難しい部分ではあります。
よくこんな感じでRTC同士が沢山のコネクタで接続されている事例がありますが、こうなってしまったら少し考えた方が良いかもしれません。片方のRTCがもう片方のRTCへの依存が大きいために起こったのかもしれません。
ただまあこんな感じの場合はやむ負えないかもしれないです。
この場合は9軸センサRTCの加速度、地磁気、角速度は個別に使う事も可能なので特に問題はないです。
こういうGUI上でマウスを操作してその位置などを送信して処理をするというRTシステムをたまに見ますけど、これはどうかと思いました。この例はかなり簡略化していますが、実際はもっと複雑だったと思います。
そもそもGUIは特定のシステム専用に作られている事が多いので再利用性は低いです。これでRTC2の再利用性が高ければ問題ありませんが、再利用性の低いGUIのRTCへの依存が大きい時点でRTC2の再利用性も低いと思います。
接続するコネクタ数が1～2つならまだ我慢できますけど、それ以上になると再利用するときに接続が面倒なだけです。おそらく拡張性を高めるためにRTCで分割したのでしょうけど、常に3本以上のポートを接続するRTCを起動する事を強いられると考えると逆効果です。
なので最初に言った通り、まずは一つのプログラムで実装する事を目指しましょう。
最初からRTCで実装しようとすると失敗します。
RTM講習会って四国では一回もやった事ないみたいですけど、ちょっと冷遇しすぎだと思います。完全な空白地帯になっているので、気が向いたらやってください。できれば愛媛で。
RTMコンテスト2015の作品が投稿されているみたいです。
ダウンロードするときにやたらと重かったのですけど、VSのsdfファイルを入れるのはどうかと思います。でも実行ファイルはちゃんと削除しているんだよなあ。
あとは何でもグローバル変数で書くのは個人的には好きではありません。と言うか何でクラス内でしか使っていない変数までグローバルにしているんだ・・・
そして何故KinectCameraの初期化失敗時にRTC_ERRORに遷移するようにしていないのか、何故かKinectDepthではちゃんとエラーに遷移するようになっているので謎です。
JPEG圧縮した画像データを出力するデータポートのデータ型が何故TimedOctetSeqになっているのかも謎です。
コンフィギュレーションパラメータで圧縮形式を変更できるようにして、無圧縮の画像データと同じデータポートから出力すれば良いのではないですかね？
後は受信先で圧縮形式を識別して復元すればいいと思いますけど。
仕様なのかどうかは知りませんけど、KinectDepthのRAWというデータポートって何もデータがない状態で出力されています。
KinectHumanTracking.cppの284行目のIf文ですが、preと言う変数は宣言されてからIf文まで一度も変更していないようなので分岐する意味がありません。と言うかどっちにしても同じ処理をしているように見えます。まあだからと言って何か影響があるかと言えば特にないのですけど。
僕の勘違いでなければ271～283行目の処理は全く意味がないように見えます。そもそもどういう意図で記述したのでしょうか？それに伴ってcommand_img_dataと言う変数も意味がないので188～195行目も必要ありません。なんだか全体的に意図が読み取りづらい印象です。
後はSafeRelease関数が他のソースコードからコピーしたものであれば一応そのソースコードの入手先とライセンスを明記する必要があるとは思います。
まあ数行なので審査には影響しないでしょうし別に誰かに損害を与えるとかいうわけではないですけど、無用なトラブルを避けるためです。
大抵の作品に言える事なのですが、ロジック部分は別ファイルに切り離すのが基本です。
全部onExecuteとかに書くのは少し問題だと思います。
最初からRTCで実装しようとするからこうなるのではないでしょうか？
RTC化する以前にまずは単体のプログラムで動作できる事が重要で、テスト用プログラムでロジック部分をクラスで実装しておけばRTCへの再実装も簡単です。
そのせいか、特にKinectHumanTrackingのソースコードの見通しが悪い感じがします。
このブログで散々言った通り、ソースコードのみで配布はあり得ないなと思います。
こっちでビルドするのは地味に面倒なので、全く使ってもらえない可能性が高いです。
このブログを読んでいないのでしょうか？読んでいるわけないだろ
致命的に大きな問題があるわけではないのですが、一体何が特徴なのかが分かりません。
まだ全容が分からないので何とも言えませんが、奇抜さとか斬新さというものが感じられませんでした。
こういう作品が一番辛い評価になるので、もう少し何か欲しいかなとは思いました。
ちょっと今のままでは受賞は厳しいかなという印象です。
この作品には全く関係はないのですが、去年のコンテストで盗用した作品があった件についてコンテスト運営側から何の説明もないうちに今年の作品が投稿されてしまったことは大変遺憾です。
受賞を取り消さないと決めたのであればそれでもいいのですよ。
ただ何の説明もないのは、非常に後味が悪いです。
このままではあの作品は盗用で賞を取ったという認識になってしまうわけで、もしも違うのであれば否定した方が良いとは思っています。少なくとも僕の中ではそういう認識になっています。
何にせよもう時間がないので、10月中にはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
まずは単一のプログラムで実装する事を目指して、それから切り離せる部分は切り離していけばいいのではないですかね？何だか似たような事を言ったような記憶がありますけど。
やりがちな失敗として他のRTCに依存しすぎるという事があります。
そもそもコンポーネント指向の基本として「コンポーネント間の依存を少なくする」と言う事があると思います。
「はじめてのコンポーネント指向ロボットアプリケーション開発 ~RTミドルウェア超入門~」ではやたらとこの点を押してきます。RTM関連の人は大抵この本を読んでいると思うので、分かっていても間違うのだから難しい部分ではあります。
よくこんな感じでRTC同士が沢山のコネクタで接続されている事例がありますが、こうなってしまったら少し考えた方が良いかもしれません。片方のRTCがもう片方のRTCへの依存が大きいために起こったのかもしれません。
ただまあこんな感じの場合はやむ負えないかもしれないです。
この場合は9軸センサRTCの加速度、地磁気、角速度は個別に使う事も可能なので特に問題はないです。
こういうGUI上でマウスを操作してその位置などを送信して処理をするというRTシステムをたまに見ますけど、これはどうかと思いました。この例はかなり簡略化していますが、実際はもっと複雑だったと思います。
そもそもGUIは特定のシステム専用に作られている事が多いので再利用性は低いです。これでRTC2の再利用性が高ければ問題ありませんが、再利用性の低いGUIのRTCへの依存が大きい時点でRTC2の再利用性も低いと思います。
接続するコネクタ数が1～2つならまだ我慢できますけど、それ以上になると再利用するときに接続が面倒なだけです。おそらく拡張性を高めるためにRTCで分割したのでしょうけど、常に3本以上のポートを接続するRTCを起動する事を強いられると考えると逆効果です。
なので最初に言った通り、まずは一つのプログラムで実装する事を目指しましょう。
最初からRTCで実装しようとすると失敗します。
RTM講習会って四国では一回もやった事ないみたいですけど、ちょっと冷遇しすぎだと思います。完全な空白地帯になっているので、気が向いたらやってください。できれば愛媛で。
RTMコンテスト2015の作品が投稿されているみたいです。
ダウンロードするときにやたらと重かったのですけど、VSのsdfファイルを入れるのはどうかと思います。でも実行ファイルはちゃんと削除しているんだよなあ。
あとは何でもグローバル変数で書くのは個人的には好きではありません。と言うか何でクラス内でしか使っていない変数までグローバルにしているんだ・・・
そして何故KinectCameraの初期化失敗時にRTC_ERRORに遷移するようにしていないのか、何故かKinectDepthではちゃんとエラーに遷移するようになっているので謎です。
JPEG圧縮した画像データを出力するデータポートのデータ型が何故TimedOctetSeqになっているのかも謎です。
コンフィギュレーションパラメータで圧縮形式を変更できるようにして、無圧縮の画像データと同じデータポートから出力すれば良いのではないですかね？
後は受信先で圧縮形式を識別して復元すればいいと思いますけど。
仕様なのかどうかは知りませんけど、KinectDepthのRAWというデータポートって何もデータがない状態で出力されています。
KinectHumanTracking.cppの284行目のIf文ですが、preと言う変数は宣言されてからIf文まで一度も変更していないようなので分岐する意味がありません。と言うかどっちにしても同じ処理をしているように見えます。まあだからと言って何か影響があるかと言えば特にないのですけど。
僕の勘違いでなければ271～283行目の処理は全く意味がないように見えます。そもそもどういう意図で記述したのでしょうか？それに伴ってcommand_img_dataと言う変数も意味がないので188～195行目も必要ありません。なんだか全体的に意図が読み取りづらい印象です。
後はSafeRelease関数が他のソースコードからコピーしたものであれば一応そのソースコードの入手先とライセンスを明記する必要があるとは思います。
まあ数行なので審査には影響しないでしょうし別に誰かに損害を与えるとかいうわけではないですけど、無用なトラブルを避けるためです。
大抵の作品に言える事なのですが、ロジック部分は別ファイルに切り離すのが基本です。
全部onExecuteとかに書くのは少し問題だと思います。
最初からRTCで実装しようとするからこうなるのではないでしょうか？
RTC化する以前にまずは単体のプログラムで動作できる事が重要で、テスト用プログラムでロジック部分をクラスで実装しておけばRTCへの再実装も簡単です。
そのせいか、特にKinectHumanTrackingのソースコードの見通しが悪い感じがします。
このブログで散々言った通り、ソースコードのみで配布はあり得ないなと思います。
こっちでビルドするのは地味に面倒なので、全く使ってもらえない可能性が高いです。
このブログを読んでいないのでしょうか？読んでいるわけないだろ
致命的に大きな問題があるわけではないのですが、一体何が特徴なのかが分かりません。
まだ全容が分からないので何とも言えませんが、奇抜さとか斬新さというものが感じられませんでした。
こういう作品が一番辛い評価になるので、もう少し何か欲しいかなとは思いました。
ちょっと今のままでは受賞は厳しいかなという印象です。
この作品には全く関係はないのですが、去年のコンテストで盗用した作品があった件についてコンテスト運営側から何の説明もないうちに今年の作品が投稿されてしまったことは大変遺憾です。
受賞を取り消さないと決めたのであればそれでもいいのですよ。
ただ何の説明もないのは、非常に後味が悪いです。
このままではあの作品は盗用で賞を取ったという認識になってしまうわけで、もしも違うのであれば否定した方が良いとは思っています。少なくとも僕の中ではそういう認識になっています。
何にせよもう時間がないので、10月中にはお願いします。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
ubilinuxでupmをインストールするのが面倒くさいので使いたくなかったのですが、upmを使って実装し直す事も考えています。
よく見るとPCA9685、LSM303、LSM9DS0、GP2Y0Aもサポートされているのでこっちで実装する必要なかったみたいです。
以前はこっちで使うセンサでサポートされているのがPCA9685とLSM303DLHCだけだったのですが、少しずつ増えているみたいなのでupmで実装し直しなおしてもいいかもしれません。GP2Y0Aは内容を見た感じでは電圧を取得できるだけで距離には変換してくれないみたいです。
特に書くこともないので時事ネタで埋めます。
出世大名家康くんなんてゆるキャラがいるらしいけど、今は不謹慎なので活動を自粛すべきだと思います。
何故かと言うと鬼怒川の決壊の原因は徳川家康の河川改修工事が原因だからです。
これは浜松市役所に苦情の電話をかけなければなりませんね。
まあこれは冗談ですけど、不謹慎厨はどこにでもいるから油断はできません。
こんな事で苦情の電話がかかってきたら、僕なら逆ギレします。
STAP細胞の再現実験なんてやっていたらしいですけど、なんとも無駄なことしたなあという印象です。
最初から全て捏造だったと明らかにしておけばこんな迷惑をかける事もなかっただろうに、どうしてこんな事になったのでしょうね？
個人的な考えですが、一般人ならともかく専門家が騙されるのは騙される方が悪いと言えなくもないと思います。
結果を導いた過程を考えれば怪しいかどうかぐらいは勘付けるのではないかと思います。
盗用に関しても同じで、盗用元を知らずに評価してしまった側にも少なからず責任はあるとは思います。
念のために言っておきますが、当たり前ですけど不正をやった本人が一番悪いのは間違いありません。
何が言いたいのかと言うと、騙された方が負った損害を全て賠償しろとは言いませんけど、不正で得た利益は全部返せと言う事です。
STAP細胞に関しては利益を全部返したどころか相当な損害が出たわけで、もういいのではないでしょうか？
オリンピックのエンブレム問題は少し叩きすぎです。もう信用が戻る事はないと思うので、佐野氏はデザイナーとしては実質的に終わっています。東京都民からすれば税金で払わなくてもいい費用を払ったわけなのですが、それは審査員や審査員を任命した組織委員会にも責任はあるのでそっちを叩きましょう。僕は東京都民ではないので全く関係のない話ではあるのですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
よく見るとPCA9685、LSM303、LSM9DS0、GP2Y0Aもサポートされているのでこっちで実装する必要なかったみたいです。
以前はこっちで使うセンサでサポートされているのがPCA9685とLSM303DLHCだけだったのですが、少しずつ増えているみたいなのでupmで実装し直しなおしてもいいかもしれません。GP2Y0Aは内容を見た感じでは電圧を取得できるだけで距離には変換してくれないみたいです。
特に書くこともないので時事ネタで埋めます。
出世大名家康くんなんてゆるキャラがいるらしいけど、今は不謹慎なので活動を自粛すべきだと思います。
何故かと言うと鬼怒川の決壊の原因は徳川家康の河川改修工事が原因だからです。
これは浜松市役所に苦情の電話をかけなければなりませんね。
まあこれは冗談ですけど、不謹慎厨はどこにでもいるから油断はできません。
こんな事で苦情の電話がかかってきたら、僕なら逆ギレします。
STAP細胞の再現実験なんてやっていたらしいですけど、なんとも無駄なことしたなあという印象です。
最初から全て捏造だったと明らかにしておけばこんな迷惑をかける事もなかっただろうに、どうしてこんな事になったのでしょうね？
個人的な考えですが、一般人ならともかく専門家が騙されるのは騙される方が悪いと言えなくもないと思います。
結果を導いた過程を考えれば怪しいかどうかぐらいは勘付けるのではないかと思います。
盗用に関しても同じで、盗用元を知らずに評価してしまった側にも少なからず責任はあるとは思います。
念のために言っておきますが、当たり前ですけど不正をやった本人が一番悪いのは間違いありません。
何が言いたいのかと言うと、騙された方が負った損害を全て賠償しろとは言いませんけど、不正で得た利益は全部返せと言う事です。
STAP細胞に関しては利益を全部返したどころか相当な損害が出たわけで、もういいのではないでしょうか？
オリンピックのエンブレム問題は少し叩きすぎです。もう信用が戻る事はないと思うので、佐野氏はデザイナーとしては実質的に終わっています。東京都民からすれば税金で払わなくてもいい費用を払ったわけなのですが、それは審査員や審査員を任命した組織委員会にも責任はあるのでそっちを叩きましょう。僕は東京都民ではないので全く関係のない話ではあるのですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
とりあえず予稿原稿は書きましたけど、まだ直すところはありそうなので入稿はしません。
人の論文とかを読んでいて、まずできていない事を実現できたとか嘘を書くのは論外なのですが、実現できた事を書いているのか、それとも実現できるかもしれない事を書いているのかの区別が付かないのが一番困ります。
明確に嘘を書いていれば言い訳する余地はないのですが、実現できるかもしれないことをあたかも実現できている事のように誤解を与えるような書き方をしている場合、「実現できたと明記はしていない」と言い訳ができてしまいます。
なんだかその分たちが悪いと言うか、わざとだとすれば詐欺師並みの技術だと思います。
何の論文や予稿原稿の事なのかは言いませんが、内容としてはこんな感じでした。
まず2章1節でRTCの設計について説明して、次に2章2節でRTCの実装について述べて、そして2章3節でそのRTCの利用例を提案していました。つまりこの利用例は実装できていません。
この流れで2章の3節に「このように～する事によって、（中略）簡単にシステムが構成できる」なんて書いていれば誰でも誤解します。
せめて「～が期待できる」とかならばまだ分かったのですが、明言されてしまうと「提案したシステムを実装して有用性を確かめられた」という印象にしかなりません。いわば仮説を立てただけで検証をしていないのに何故か結論が出てしまっているわけで、完全に論理が破綻しています。
実装や実験をしたのかどうかは曖昧に書いて、「簡単にシステムが構成できる」と事実がはっきりしない部分は断言している。どうにも行動が矛盾しているというか、凄まじい違和感を感じます。
これは一例であって、こういう感じの論文や予稿原稿は珍しくもないと思います。
個人的な考えですが、実現できそうな事というのは「今後の展望」に含まれることだと思うので、結言に書いてほしいのですよね。それなら誤解する人はいないと思います。
まあ論文ならともかく予稿原稿で内容を評価する人もあまりいないだろうし、実はあまり問題ないのかもしれないですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
人の論文とかを読んでいて、まずできていない事を実現できたとか嘘を書くのは論外なのですが、実現できた事を書いているのか、それとも実現できるかもしれない事を書いているのかの区別が付かないのが一番困ります。
明確に嘘を書いていれば言い訳する余地はないのですが、実現できるかもしれないことをあたかも実現できている事のように誤解を与えるような書き方をしている場合、「実現できたと明記はしていない」と言い訳ができてしまいます。
なんだかその分たちが悪いと言うか、わざとだとすれば詐欺師並みの技術だと思います。
何の論文や予稿原稿の事なのかは言いませんが、内容としてはこんな感じでした。
まず2章1節でRTCの設計について説明して、次に2章2節でRTCの実装について述べて、そして2章3節でそのRTCの利用例を提案していました。つまりこの利用例は実装できていません。
この流れで2章の3節に「このように～する事によって、（中略）簡単にシステムが構成できる」なんて書いていれば誰でも誤解します。
せめて「～が期待できる」とかならばまだ分かったのですが、明言されてしまうと「提案したシステムを実装して有用性を確かめられた」という印象にしかなりません。いわば仮説を立てただけで検証をしていないのに何故か結論が出てしまっているわけで、完全に論理が破綻しています。
実装や実験をしたのかどうかは曖昧に書いて、「簡単にシステムが構成できる」と事実がはっきりしない部分は断言している。どうにも行動が矛盾しているというか、凄まじい違和感を感じます。
これは一例であって、こういう感じの論文や予稿原稿は珍しくもないと思います。
個人的な考えですが、実現できそうな事というのは「今後の展望」に含まれることだと思うので、結言に書いてほしいのですよね。それなら誤解する人はいないと思います。
まあ論文ならともかく予稿原稿で内容を評価する人もあまりいないだろうし、実はあまり問題ないのかもしれないですけど。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
どうにも予稿原稿を書くときに一番困るのは序論です。
2章以降は自分がやった事、自分が思った事を書けば良いだけなのですが、序論はそうはいきません。
人の真似をせずに自分で考えて文章を書くというのは容易ではありません。
しかも僕が論文を読むときに一番いいかげんに読むのが序論なのであまりやる気もでません。
正直なところ英文アブストラクトとか誰も読まないだろと思っていますけど、仕方ないので一応は書きます。
今年の参加者が減ったのって僕みたいな訳わからない人間が最優秀賞を取ったからですかね？
逆に言えば審査に一切の利害が関係しない、極めて公平な審査ができているという事なので良い事だと思いますけどね？
その公平な審査を妨げる悪質な参加者がいたのは残念でしたけど、もうあれには触れたくもありません。
HSPプログラムコンテスト2013でも似たような事例があったみたいですけど、こっちは盗用元の作者がコンテスト事務局に問い合わせたこととコンテストの規模が大きかったせいで大炎上したみたいです。
RTMコンテストの例の件もこれと何ら変わりません。
何だか軽い問題のように扱われているような気がするのですが、これぐらい重大な問題だったという事です。
よく考えてみればRTMコンテストでも同じ事が起こったにもかかわらず受賞の取り消しすらもしないという状況はかなり異常なのかもしれません。そもそも例の件に関してどう対処するか、審査にミスがあったのかの説明自体がRTMコンテストの運営サイドからは今のところありません。
直接問い合わせたいのですが、「通報しない」と言ったのでできません。
もしも審査にミスがなかったのであれば、どうしてランセンスの問題を指摘しなかったのかを教えてほしいです。
ライセンスファイルに人の名前を書いて成り済まし行為を行うとか手口が余りにも悪質なので、審査にミスがなかったから受賞を取り消さないというレベルの問題ではないと思いますけどね。
笑顔で表彰状を受け取る写真や受賞のコメントがネット上で公開されていますけど、佐野研二郎氏のエンブレムお披露目会見時の謎ポーズと同じで恥以外の何物でもありません。さすがにそのページへのリンクは貼りませんけど、検索したらすぐに出てきます。
これで何も処分しなければまた同じ事しますよ、この人。別にこの人だけなら知った事ではないのですけど、他にも同じことをする人が出てくるかもしれません。盗用した事がバレても受賞の取り消しがないのですから、そんな事が起こってもおかしくありません。
どちらにしろ公式サイト、メーリングリストで今年の参加者に注意を促しておいた方がよいとは思います。
ちなみに昨日届いた「作品登録用ID番号のお知らせと今後のお願いについて」というメールにはこの件に関する注意喚起が無かったのですが、昨日から公開できるという事なので手遅れにならないうちに注意を促した方がよさそうです。
今度同じことが起きればHSPプログラムコンテストみたいに大炎上します。おそらく過去に同じことがあったという事で例の件にも飛び火して大変な事になります。
RSNPコンテストの利益相反って一体何でしょう？
それはともかくRSNPコンテストにはソースコードの公開義務はないみたいなので、盗用があっても永久に発覚する事はなさそうです。ソースコードがそもそも審査基準にはないのでしょうけど、だからこそ人のライブラリ等を使った場合は分かりやすく明記する必要があると思います。
それにしてもRSNPコンテストは「実際にサービスを利用することで審査いたしますので」と書いてありますけど、ちゃんと動作できるのでしょうかね？なかなか人の環境で動作できるソフトウェアを開発するのは簡単ではありません。逆に言えば動作できただけでも評価は高いのかもしれないです。
さっきも言いましたが、昨日からRTMコンテスト2015の作品登録ができるようになったみたいです。
今のところ誰も公開していないみたいですね。当たり前か。
僕も今年は10月31日の締め切りギリギリまでプロジェクトページを作成しないつもりです。
締め切りを守ることは大事なのですが、それ以上に人の著作物を盗用しない事の方が遥かに重要です。
知識不足でOSSライセンス違反を犯す事はあるかもしれませんが、それは審査員の人が注意してくれると思います。もちろん自分で気を付けるに越したことはないので、ライセンスについてはよく確認してください。
それ以前に盗用の意図があったのであれば注意するも糞もないのですけど、HSPプログラムコンテストで盗用した作者のプライバシーがネット上に晒される、通っている学校に苦情の電話が掛かるとかいう事態になった事を考えればやめた方がいいと思います。
「例の作品について二度と言及しない」と言ったのに、破ってしまったかもしれないです。
いやでも今回話したのは主に審査側の事なのでセーフではないでしょうか？
どうにもアウトっぽいので次から気を付けます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
2章以降は自分がやった事、自分が思った事を書けば良いだけなのですが、序論はそうはいきません。
人の真似をせずに自分で考えて文章を書くというのは容易ではありません。
しかも僕が論文を読むときに一番いいかげんに読むのが序論なのであまりやる気もでません。
正直なところ英文アブストラクトとか誰も読まないだろと思っていますけど、仕方ないので一応は書きます。
今年の参加者が減ったのって僕みたいな訳わからない人間が最優秀賞を取ったからですかね？
逆に言えば審査に一切の利害が関係しない、極めて公平な審査ができているという事なので良い事だと思いますけどね？
その公平な審査を妨げる悪質な参加者がいたのは残念でしたけど、もうあれには触れたくもありません。
HSPプログラムコンテスト2013でも似たような事例があったみたいですけど、こっちは盗用元の作者がコンテスト事務局に問い合わせたこととコンテストの規模が大きかったせいで大炎上したみたいです。
RTMコンテストの例の件もこれと何ら変わりません。
何だか軽い問題のように扱われているような気がするのですが、これぐらい重大な問題だったという事です。
よく考えてみればRTMコンテストでも同じ事が起こったにもかかわらず受賞の取り消しすらもしないという状況はかなり異常なのかもしれません。そもそも例の件に関してどう対処するか、審査にミスがあったのかの説明自体がRTMコンテストの運営サイドからは今のところありません。
直接問い合わせたいのですが、「通報しない」と言ったのでできません。
もしも審査にミスがなかったのであれば、どうしてランセンスの問題を指摘しなかったのかを教えてほしいです。
ライセンスファイルに人の名前を書いて成り済まし行為を行うとか手口が余りにも悪質なので、審査にミスがなかったから受賞を取り消さないというレベルの問題ではないと思いますけどね。
笑顔で表彰状を受け取る写真や受賞のコメントがネット上で公開されていますけど、佐野研二郎氏のエンブレムお披露目会見時の謎ポーズと同じで恥以外の何物でもありません。さすがにそのページへのリンクは貼りませんけど、検索したらすぐに出てきます。
これで何も処分しなければまた同じ事しますよ、この人。別にこの人だけなら知った事ではないのですけど、他にも同じことをする人が出てくるかもしれません。盗用した事がバレても受賞の取り消しがないのですから、そんな事が起こってもおかしくありません。
どちらにしろ公式サイト、メーリングリストで今年の参加者に注意を促しておいた方がよいとは思います。
ちなみに昨日届いた「作品登録用ID番号のお知らせと今後のお願いについて」というメールにはこの件に関する注意喚起が無かったのですが、昨日から公開できるという事なので手遅れにならないうちに注意を促した方がよさそうです。
今度同じことが起きればHSPプログラムコンテストみたいに大炎上します。おそらく過去に同じことがあったという事で例の件にも飛び火して大変な事になります。
RSNPコンテストの利益相反って一体何でしょう？
それはともかくRSNPコンテストにはソースコードの公開義務はないみたいなので、盗用があっても永久に発覚する事はなさそうです。ソースコードがそもそも審査基準にはないのでしょうけど、だからこそ人のライブラリ等を使った場合は分かりやすく明記する必要があると思います。
それにしてもRSNPコンテストは「実際にサービスを利用することで審査いたしますので」と書いてありますけど、ちゃんと動作できるのでしょうかね？なかなか人の環境で動作できるソフトウェアを開発するのは簡単ではありません。逆に言えば動作できただけでも評価は高いのかもしれないです。
さっきも言いましたが、昨日からRTMコンテスト2015の作品登録ができるようになったみたいです。
今のところ誰も公開していないみたいですね。当たり前か。
僕も今年は10月31日の締め切りギリギリまでプロジェクトページを作成しないつもりです。
締め切りを守ることは大事なのですが、それ以上に人の著作物を盗用しない事の方が遥かに重要です。
知識不足でOSSライセンス違反を犯す事はあるかもしれませんが、それは審査員の人が注意してくれると思います。もちろん自分で気を付けるに越したことはないので、ライセンスについてはよく確認してください。
それ以前に盗用の意図があったのであれば注意するも糞もないのですけど、HSPプログラムコンテストで盗用した作者のプライバシーがネット上に晒される、通っている学校に苦情の電話が掛かるとかいう事態になった事を考えればやめた方がいいと思います。
「例の作品について二度と言及しない」と言ったのに、破ってしまったかもしれないです。
いやでも今回話したのは主に審査側の事なのでセーフではないでしょうか？
どうにもアウトっぽいので次から気を付けます。
にほんブログ村のロボットのカテゴリから
全然人が来ない・・・
