VEGA TECH LAB

インテリア×テクノロジー

iOSDC JAPAN 2018

iOSアプリエンジニアの主計です。

今年も福岡からiOSDCに参加してきました。
去年もとても素晴らしいカンファレンスでしたが今年は更にパワーアップしているように感じました。iOSDCはコミュニケーションの場であり講義ではなく双方向コミュニケーションのカンファレンスとの説明が冒頭にあったのですが、それが実感できるカンファレンスだったと思います。
私自身いろんな方とコミュニケーションもとることができ、とても楽しむことができました。

印象に残ったセッション

どのセッションも興味深い内容でしたが、すべては紹介できないのでいくつか印象に残ったセッションを紹介致します。

MicroViewControllerで無限にスケールするiOS開発

www.icloud.com 今回のセッションのなかで一番聞きたかったセッションです。20人での開発もできるように画面を多数のViewControllerにしているとのことでした。
また、初期化の扱いやすさからInterfaceBuilderはStoryboardではなくXibを使うことでした。
GitHubでも公開されているのでコードリーディングしていきたい💪 github.com

QRコード読み取り?楽勝ですよ😙」=>「AVFoundationを信じたおれがバカだった😇」

speakerdeck.com QRコードには連結機能がありAVFoundationでの読み取りについてのセッションでした。QRコード活用の仕方しだいでとても便利なので扱う際には読んでおくといいと思います。

Depth in Depth

www.slideshare.net 深度情報を使って人物の切り抜きなどのデモをみることが出来ました。制約もありますが、モバイルで簡単に切り抜きが出来れば役に立ちそうです。

諸事情により9/2(最終日)に参加できなかったので9/1までの中から紹介させていただきました。 後日、ビデオが公開されると思うので見れなかったセッションも含めてみていきたいと思います。

iOSDCリジェクトコン

iOSDC JAPAN 2018 は終わってしまいましたが、リジェクトコンが9/18と9/20日にあります。
また面白い企画もありますのでご応募お待ちしております。 iosdcrc.firebaseapp.com

今年は福岡にサテライト会場を用意していますので福岡の方も是非参加お願いします。

東京

iosdc-reject-conference.connpass.com iosdc-reject-conference.connpass.com

福岡(サテライト)

iosdc-reject-conference.connpass.com iosdc-reject-conference.connpass.com

来年はcfpだしてスピーカーとして参加出来るように頑張りたいと思います!

iOSネイティブコードから構造体をUnityに渡す

ベガコーポレーションでエンジニアをやっているStellarBiblosです。   初回からかなりニッチな所ですが、これに関しての情報があまり無いようで、折角ですから記事にしてみました。

構造体

まずは各々の方で構造体を宣言しますが、変数の宣言順序が異なると正しく渡せません。 新規で作成している場合には考慮しなくていいと思いますが32bitサポートの場合バイト長が違ったりするため注意です。 また、C#だとboolはデフォルトで4バイトに対してC++は1バイトなため[MarshalAs( UnmanagedType.U1)]で明示的に1バイトと宣言しなければダメです。 その後3バイト長のchar/stringを用いてパディングしておいた方がいいと思います。 そうでなくても末尾が余っている場合はパディングを推奨します。

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Ansi)]
public struct Model {
    [MarshalAs(UnmanagedType.LPStr)]public string name;
    [MarshalAs(UnmanagedType.I4)]public int index;
    [MarshalAs(UnmanagedType.R4)]public float posX;
    [MarshalAs(UnmanagedType.R4)]public float posY;
    [MarshalAs(UnmanagedType.R4)]public float posZ;
}
struct Model_t {
    const char *name;
    int index;
    float posX;
    float posY;
    float posZ;
};

データ受け渡し

正しく構造体を作れていれば構造体のバイト長が一致します。 そのため構造体サイズ分アロケートしたポインタに対してmemcpyすればズレなくデータが取得できます。

class Reciever : MonoBehaviour {
    [DllImport("__Internal")] static extern void getModelStruct(IntPtr ptr);
    [DllImport("__Internal")] static extern void setModelStruct(IntPtr ptr);
   
    Model getModelFromNative() {
        var model = new Model();
        var ptr = IntPtr.Zero;
        try {
            System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions();
            try {}
            finally {
                ptr = Marshal.AllocCoTaskMem(Marshal.SizeOf(typeof(Model)));
            }
            GetFurnitureStruct(ptr);
            model = (Model)Marshal.PtrToStructure(ptr, typeof(Model));
        }
        finally {
            if(ptr != IntPtr.Zero) Marshal.FreeCoTaskMem(ptr);
        }
        return model;
    }

    void setModelFromNative(Model model) {
        var ptr = IntPtr.Zero;
        try {
            System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions();
            try {}
            finally {
                ptr = Marshal.AllocCoTaskMem(Marshal.SizeOf(typeof(Model)));
            }
            Marshal.StructureToPtr(ptr, model, false);
            setModelStruct(ptr);
        }
        finally {
            if(ptr != IntPtr.Zero) Marshal.FreeCoTaskMem(ptr);
        }
    }
}
Model_t myModel = *new Model_t { "Vega", 0, 0.0, 1.0, 1.2 };

extern "C" void getModelStruct(Model_t *model_t) {
    memcpy(model_t, &myModel, sizeof(Model));
}

extern "C" void setModelStruct(Model_t *model_t) {
    memcpy(&myModel, model_t, sizeof(Model));
}

おまけ

配列も取れます。 予め何らかの方法で配列長を知る必要がある為完璧な実装ではないです。

class ArrayReciever : MonoBehaviour {
    [DllImport("__Internal")] static extern void getModelStructArray(IntPtr ptr);

    Model[] getModeArraylFromNative(int length) {
        var models = new Model[length];
        var ptr = IntPtr.Zero;
        Int64 arrPtr = 0;
        try {
            System.Runtime.CompilerServices.RuntimeHelpers.PrepareConstrainedRegions();
            try {}
            finally {
                ptr = Marshal.AllocCoTaskMem(Marshal.SizeOf(typeof(Model)) * length);
            }
            arrPtr = (Int64)ptr;
            getModelStructArray(ptr);
            for(var i=0; i<length; i++) {
                models[i] = (Model)Marshal.PtrToStrucure((IntPtr)arrPtr, typeof(Model));
                arrPtr += (Int64)Marshal.SizeOf(typeof(Model));
            }
        }
        finally {
            if(ptr != IntPtr.Zero) Marshal.FreeCoTaskMem(ptr);
        }
        return models;
    }
}
Model_t myModels[3];

extern "C" void getModelStructArray(Model_t *models_t) {
    memcpy(models_t, &myModels, sizeof(myModels));
}

インターンで内定者さんがやってきた。

こんにちは。

ベガコーポレーション所属エンジニアの田中です。

 

 今回は、インターンで新卒の内定者の方が来社されましたのでその内容について紹介させていただきます。

 内定者さんには、弊社のデータ分析で使用しているSAP Predictive Analytics(以後SAP PA)を使って、電力予測とクラス分けの2つの課題に挑戦していただきました。インターン期間は2018年7月17日〜27日の約2週間で、成果発表を含めた課題解決を行っていただきました。

この記事の構成は、

  §1. 電力予測

  §2. クラス分類

  §3. インタビュー

  §4. 最後に

となっています。§1, 2が技術的な内容で、§3では内定者さんにインターンの感想などのインタビューを行ったものを掲載しています。そして、最後§4に総括・コメントを書いています。

 

§1. 電力予測

 このセクションでは、SAP PAを用いた電力予測について紹介します。SAP PAの詳細については、以前のブログに記載されておりますので、ご興味のある方は参照していただければと思います。

blog.vg-lab.com

 

 インターン課題として、内定者さんにはデータの収集・整形からSAP PAを用いた予測モデルの構築までの一連の行程を行っていただきました。その中で、予測精度を上げるためにどのようなデータを与えれば良いかという点を内定者さん自身で考察していただきました。

 学習データの収集では、電力会社が公開している電力量などの数値と該当地域の気候データの取得を行ってもらいました。これらデータを使って、SAP PAによる予測モデルを作成するためには目的変数説明変数を設定する必要があります*1 。特に、目的変数として何を与えれば、予測制度が上がるのか?を考えることが重要な作業となります。加えて、与える説明変数の期間についても調整してもらいました。ちなみに収集・整形したデータを学習データ評価データに上手く分割することで予測モデルの汎化能力を上げることも内定者さんに行っていただきました *2。 これら地道な調整の結果、今回は全てのモデル作成で「学習データ:2012年〜2017年,  評価データ:2018年〜予測日」の分割期間を採用しました。

 今回の予測対象は、2018年7月1日〜17日の期間での日毎の最大電力となっています。まずは、説明変数として気温を与えたものの中で、2パターンの結果を示します。 2パターンとは、それぞれ説明変数の期間を対象日から過去1週間分と過去1ヶ月間分に設定している場合に分けています。また、予測値を評価する指標としては、Root Mean Square Error (RMSE)を使用しました。RMSEは、予測と実測との差を表している値で、ゼロに近いほど予測精度が高いことを意味します。

 

 それでは、最大電力の予測結果を見ていきます。

1)説明変数:対象日から1週間前の気温  

f:id:TanakaKenta:20180806083024p:plain

RMSE

SAP PA  : 117.1  電力会社: 68.50

 

2)説明変数:対象日から1ヶ月前の気温  

f:id:TanakaKenta:20180806083315p:plain

RMSE

SAP PA  : 112.7   電力会社: 68.50

 上記2つの結果から、説明変数として気温だけを与えた場合は、説明変数の期間を調整することで僅かに予測精度が上がったものの、残念ながら2パターンともに電力会社の予想精度を大きく下回ってしまう結果となりました。

 

 次に、昨年の同時期の電力を説明変数として与えたものを示します。

 説明変数:対象日から1年前の前後3日分の電力 

f:id:TanakaKenta:20180806083546p:plain

RMSE

SAP PA  : 76.47   電力会社: 68.50

 SAP PAの予測精度は大きく向上したものの電力会社の予測精度にはまだ及びません

 

 そこで、説明変数として、気温と昨年の電力を併用したモデル作成しました。

説明変数:当日の気温と前3日分の電力

f:id:TanakaKenta:20180806083939p:plain

 

RMSE

SAP PA  : 36.15   電力会社: 68.50

 結果としては、電力会社よりも高精度な予測値を出すことができました。しかし、今回の予測モデルでは気温の変動が大きい時期に対する予測精度が著しく悪化してしまう汎化性での欠点も見つかりました。このように、予測モデルの性能の観点では、以前に弊社エンジニアが作成したモデルには及びませんでしたが、内定者さんの新しい発想から多くの発見が生み出されました

 

 §2. クラス分類

 次に、挑戦していただいた課題はクラス分類の問題となっています。特に、インターンではある2次元上のデータを2つのクラス(または3つのクラス)に分類する問題を解いていただきました。このクラス分け問題は、以下のように、2種類の値(+1またはー1)が分布しているデータを2色の領域に色分けする課題へと置き換えることができます。 

f:id:TanakaKenta:20180803092055p:plain

  この課題では、新卒エンジニアである私も同じ課題に挑戦し、どちらが上手く色分け出来るかの対決を行いました。 ちなみに私は、SAP PAとは別の手法としてTensorFlow(以後、TF)を用いたディープラーニングのアプローチから挑戦しました。

f:id:TanakaKenta:20180803084058p:plain

 今回は、与えられた学習データに対して、どのような学習モデルをどのように構築するのかという点にフォーカスした課題となっています。それでは、さっそく3本勝負の結果を見ていきます。ちなみに、勝敗の判定基準は内定者さんの主観です。

第1問) 2クラスの分類(長方形)

f:id:TanakaKenta:20180803093544p:plain

僅差で私、田中の勝利!! 正直、微妙なところですが内定者さんに1勝を譲ってもらいました。

 

第2問) 3クラスの分類

f:id:TanakaKenta:20180803093611p:plain

私は2色にしか色分けできていないのに対して内定者さんは3クラスに分類できているので、完全に内定者さんの勝利

 

第3問) 2クラスの分類(ロール)

f:id:TanakaKenta:20180803093626p:plain

 

何となく渦巻きを巻いているので私の勝利!! ということで3本勝負の結果は、内定者さん1勝、私2勝で何とか面目を保ちました。

  最後に、第3問に特化したアルゴリズムを内定者さんが作成して下さったので、その色分け結果を示します。詳細は省きますが、それなりに上手く色分けできているように思います。

f:id:TanakaKenta:20180806081334p:plain

 

 §3. インタビュー

 最後に、内定者さんにインタビューした内容を一問一答形式でまとめました。私からの質問に対して、内定者さんが答えるというものです。

Q1.  今、大学ではどのようなことをしていますか?

A1.  大学ではRubyを使って教育用プログラミング言語Scratchを対象とした研究を行っています。また、ものづくり部でアプリ制作もしています。学外では小・中学生にRubyプログラミングを教える団体に所属しています。あとエンジニア主体のRubyの勉強会に参加したりもしています。

 

Q2.  ベガの選考を受けようと思ったのは何故ですか?

A2.  福岡に知り合いが多い中で、ベガを知りました。福岡という土地柄と社員さんの雰囲気の良さに魅力を感じ選考を進めて来ました。東京の企業も何社か受けましたが、技術レベルの高さとユニークな強みのある会社であると感じたことが決め手となりました。

 

Q3.  インターンを受けようと思ったのは何故ですか?

A3.  一番はベガの社員さんの雰囲気を知りたいと思ったからです。あと実業務に早く触れて実践的に技術力を身に付けていきたいと考えました。

 

Q4.  インターンで技術的に大変だったことは何かありますか?

A4.  今までデータ分析をしたことがなかったので、予測モデルを作成することが大変でした。ただ、メンターさんに親切に教えていただいたので何とか形することができました。

 

Q5.  インターンの雰囲気はどうでしたか?

A5.  社員さんの雰囲気がとても良かったです。質問しやすい環境で自分のアイディアなども聞いていただけて楽しく課題に挑戦できました。

 

Q6.  なんとなくでも職場の雰囲気、業務のイメージはつかめましたか?

A6.  職場はキレイで家具も揃っていて雰囲気もとても良かったです。あとランチにも連れて行ってもらえて、いろいろ話ができてよかったです。業務の具体的な内容までは把握しきれてはいませんが、大まかなイメージはできたように思います。

 

§4. 最後に

 今回のインターンでは、二週間という短い期間の中で試行錯誤をしながら、しっかりと成果発表までやりきった内定者さんを見て、『とても優秀な学生さんだな』という印象を受けました。このような優秀な学生さんが弊社に集まって来ている状況をとても嬉しく思いつつ、弊社のエンジニアとしては身の引き締まる思いです。来年度から一緒に働いていけることを楽しみにしています!!

 

*1:目的変数は予測したい値(今回は日毎の最大電力)で、説明変数はその目的変数の予測値を算出するのに必要な値(例えば、気温)になります。

*2:モデルの学習に使用するデータを学習データ、そのモデルの検証に使用するデータを評価データと呼びます。

try! Swift 2018

ベガコーポレーションのiOSアプリエンジニアの主計です。 だいぶ遅くなってしまいましたが、3月1日〜3月3日で行われたtry! Swift 2018というカンファレンスに参加してきましたので印象に残ったセッションなどを簡単にレポートしたいと思います。 www.tryswift.co

印象に残ったセッション

Swift によるアルゴリズムの可視化

このセッションは内容も良かったのですがデモのライブコーディングがすばらしかったです! デモではPlaygroudを活用してベジェ曲線の仕組みがわかりやすくコードに落とし込んでいてわかりやすかったです。 自分はまだまだ開発段階でのPlaygroundの活用がたりないなとも感じさせられました。

動画・スライド

www.youtube.com speakerdeck.com github.com

超解像+CoreML+Swiftを使ってアプリの画像データ転送量削減に挑戦する

CoreMLと聞くと解析やAIという先入観がありましたが、こんな活用法もあるのか!と気づかせてもらえました。 画像の転送量削減は画像を使っているサービスならどこにでもあてはまることですし、UXにも直結するので試してみたいなと感じました。

動画・スライド

www.youtube.com speakerdeck.com github.com

番外編(お昼休み)

ランチを食べ終わってスポンサーブースを歩いていると人だかりが。。。 Yahoo! Japanさんのブースでライブコーディングが行われていたので覗いてきました。 普段開発している様子を紹介してくださっていたようでしたので時間を忘れて見入ってしまいました。 簡単に概要をまとめると、

  • ペアプログラミングでTDD
  • 細かい粒度のToDoを元に1人がテストコードを記述
  • テストが失敗ことを確認
  • もう1人がテストが通るように実装
  • テストが成功することを確認
  • レビューしリファクタ
  • ToDoにチェック

このような形で開発をしているとのことでした。 また、実装時にレビューは完了しているため、プルリクエストの際にはコードビューは行っていないみたいです。 テストコードのメソッド名を日本語で記述し、テストコードが仕様書になるように実装されていたのも面白かったので参考にしてみたいと感じました。

まとめ

国内外問わず素晴らしいセッションばかりでした。 海外のエンジニアと交流できたりできとても良いカンファレンスでした。 ただ、自分の英語力のなさに毎回落ち込みます。。。少しずつでも勉強しないといけないですね。。。 来年も必ず参加したいと思います。

福岡から iOSDC JAPAN 2017 に参加してきました

こんにちは。 ベガコーポレーションの主計(カズエ)です。

9月15日(金)から9月17日(日)に早稲田大学理工学部西早稲田キャンパスで開催された iOSDC JAPAN 2017 に参加してきましたので、見てきたセッション等の中から特に印象に残ったものについてレポートを書いていきたいと思います。 f:id:nesskazu:20170919164348j:plain

スポンサー紹介

オープニングでスポンサー紹介があったのですが、何処かで聞いたことのある声が、、、

エヴァンゲリオンミサトさんでした!

スポンサー紹介聞き流すことが多いかと思いますが、
今回はみなさん、食い入るようにみていて、twitterのタイムラインがすごい勢いで流れました。
スポンサー企業にとっても嬉しいはずなのですごい良い取り組みだと感じました。

Swaggerで始めるAPI定義管理とコードジェネレート

speakerdeck.com Swagger Codegen を使うことでクライアントを自動生成してくれるのは便利そうでした。
CocoaPodsのライブラリとして出力したりRxSwiftとの連携も可能だったりと結構実用的そうです。
設計とコードの乖離防止はクライアントとサーバー双方のエンジニアの不要なコミュニケーションを発生させたりするのでSwagger等のツールを使い齟齬を発生させない仕組みが大事であることを再認識しました。

節子、それViewControllerやない…、FatViewControllerや…。

ViewControllerはいろんな処理を書きやすいためつい、節子になりそうですがUIの処理とビジネスロジックが混ざってしまうとテストがしづらくなってしまいます。
UIKitをimportしないPresenterを作り責務を分けることでテストしやすくなります。
設計に関してはメリットデメリットがあるのでなかなか選定が難しいですが、責務を分離しテストしやすくすることに関しては実装コストを上昇することを防ぐためにも必ずやっていきたいです。 dev.classmethod.jp

具体例とクイズで学ぶ、Swiftの4種類のエラーの使い分け

Swiftのエラーには

  • Simple domain errors
  • Recoverable errors
  • Universal errors
  • Logic failures

があり、どのようにエラーハンドリングしたいかで利用するエラーを決めることが大事とのことです。発表の後半はクイズ形式であったため、参加者が考える機会がありとてもいいなと思いました。
@koherさんはQiitaでもSwiftのエラーについて記事にされていますので下記も一緒に読んでみるといいかと思います。
qiita.com qiita.com

Build high performance and maintainable UI library

UIのテストは困難であるが、

  • データの流れを1方向にする
  • 状態をモデルに分離する
  • 振る舞いをモックに置き換える

などを実践することでテストが可能であることをわかりやすく解説されて参考になりました。

発表された内容はブログにもまとめられていますので、こちらもチェックしてみてください。 blog.kishikawakatsumi.com

RxSwiftのObservableとは何か

Observerパターンの解説からRxSwiftの実装を紐解いていくかたちでの丁寧な発表で、
各Observableの違いをとても理解しやすかったです。
発表原稿をQiitaにアップされているので合わせて読むと良いと思います。
qiita.com

ディープリンクの設計と実装

speakerdeck.com WebがRESTfullなURLであれば基本的にそれにあわせてアプリのURL設計をしていけばよいとのことです。
ただ、UITabBarControllerやUINavigationControllerの階層など考慮すべきことも多いのでをしっかりと検証しないとUXを低下させてしまいそうなので気をつける必要がありそうです。

新しい画像フォーマットHEIFを用いたiOSアプリの通信量削減

speakerdeck.com 現在はWebPで配信しているがiOS11からHEIFに対応したので検証したところ約50%通信量削減に成功。
問題点は特許の関係からiPhoneを爆買い(48台程度)する必要がある(笑)
Qiitaに補足が上がっていたのでこちらも合わせてどうぞ。
qiita.com

コード生成による静的なDependency Injection

speakerdeck.com DIすることで疎結合になるがインスタンス生成が面倒になることを解消しようとするアプローチでの発表でした。
テストしやすくするためにはDIは重要なので参考にしたいと思いました。

iOSDCで「コード生成による静的なDependency Injection」について話した & 口頭原稿を公開 github.com

サポート効率を上げるためのロギング環境構築

bugsnagではアプリのいろんなところに仕込むだけで、パンくずログが取得できるので、バグの改修に役立つ。
エラーコードをしっかりと定義し管理することが大事。
再現できないバグは多くの人にコストがかかるのでしっかりログをとることが大事であると思いました。

まとめ

今回初めてiOSDCに参加しましたが、一言で言うと「最高」でした。
スタッフ、スポンサー企業、スピーカー、参加者が作り上げているイベントという感じでとてもよかったと思います!
特にスタッフ、スポンサー企業、スピーカーの皆様ありがとうございました。

知り合いもほとんどいないなかでの参加でしたが、
パックマンルールを呼びかけて頂いたおかげで初対面の方ともたくさんお話することが出来ました。
運営の方ありがとうございます!

また、ノベルティもたくさん頂きました。 f:id:nesskazu:20170919163958j:plain

来年も開催されれば必ず参加したいと思います。あとCfP出したいなと思います!

SAP Predictive Analyticsの予測をAWS λで

こんにちは。
ベガコーポレーション所属エンジニアの篠原です。

 

少し日が開いてしまいましたが、前回ご紹介したSAP PAのモデルをエクスポートし、プログラム(今回はJavaScript)で実行したいと思います。

また、ローカル環境で動かすだけではおもしろくないので、AWS λ(とAPI Gateway)を使用し、数値(説明変数の値)を渡すと予測結果を返してくれる予測APIを作っていきます。

前回記事

blog.vg-lab.com

 

なお、本記事の内容は「第二回 合同勉強会 in 福岡」で発表した内容を一部変更してお送りします。*1

*1:第二回 合同勉強会 in 福岡ではJavaScriptでなくJavaで発表しました。

続きを読む

SAP Predictive Analytics 分類/回帰分析

こんにちは。
ベガコーポレーション所属エンジニアの篠原です。


今日は弊社でデータ分析に使用しているSAP Predictive Analyticsをご紹介したいと思います。


SAP Predictive Analytics(以後SAP PA)はHANAで有名なドイツSAP社の予測分析ツールで、分類/回帰、クラスタ、アソシエーションなどの分析を行うことができます。
今回は分類/回帰分析について解説いたします。

分類/回帰分析は教師あり機械学習で、目的変数がカテゴリの場合は分類、数値の場合は回帰となります。
SAP PAでは、目的変数の型で自動的に決められます。

テキストファイルやExcelファイルあるいはデータベースでデータを用意し、学習を行うことで予測を行うことができるモデルを作成することができます。
弊社ではデータ加工の都合上、テキストファイルで行なっています。

テキストファイルの場合はCSVでもTSVでも大丈夫です。
(自動判別してくれます。)

では実際にモデル作成と予測を行います。
今回は最大電力を予測し、電力会社の予想結果と比較・勝負したいと思います。

 

データの用意

電力会社によりますと、予想最大電力は天候・予想気温、曜日、節電効果、景気動向などを考慮して予想しているそうです。
節電効果や景気動向はデータが手元にないため、電力会社で考慮されているパラメータの内、気温と曜日(及び休日)を説明変数として採用します。
天候は1日の内での決定が難しいために採用せず、気温は最高気温を使用します。
その他のパラメータとして、時期(季節)を特定するための年間通算日(1月1日を1とする)を用います。

予測には用いませんが、ラベルとして日付と比較用の電力会社の予想が入っています。
データはこんな感じになります。↓

f:id:cxalpha:20170817134750p:plain


データがある2012年1月から2017年7月を学習期間とし、2017年8月の予測を行います。

 

SAP PAでのモデル作成

SAP PAを開き、分類/回帰モデルの作成を選択します。

f:id:cxalpha:20170817134845p:plain

 

データソースの選択で用意したテキストファイルを読み込みます。

f:id:cxalpha:20170817134911p:plain

 

変数記述ではデータの保存形式(数値や文字列など)や値の形式(連続値や断続値など)を指定します。

f:id:cxalpha:20170817134927p:plain

 

以前行ったことがあるデータと同じカラムで変数記述ファイルが保存してあったり、変数記述を作成してあれば読み込むだけでOKですが、今回は変数記述ファイルがないので、解析し、必要であれば保存形式や値の形式を指定します。

f:id:cxalpha:20170817135002p:plain

 

変数の選択では目的変数と除外する変数を選択します。
年月日と電力会社の予測値は予測に使用しないので除外します。

f:id:cxalpha:20170817135030p:plain

 

モデル作成の設定画面です。モデルの自動保存や詳細設定が行えますが、デフォルトのまま進めます。

f:id:cxalpha:20170817135053p:plain

 

モデル作成が行われます。説明変数の数やレコード数にもよりますが、数秒で終わります。
(1000の説明変数の場合でも数十秒から数分で終わります。)

f:id:cxalpha:20170817135107p:plain

 

モデルができたら、モデルの情報を見ることができます。

↓のグラフは実測値と予測値の比較で、緑の理想線と青の検証線が近く、誤差範囲が少ないものが理想です。

f:id:cxalpha:20170817135228p:plain

 

モデルの適用と評価

モデルの適用をすると、説明変数から目的変数の予測を行うことができます。

f:id:cxalpha:20170817135510p:plain

 

今回は検証用に8/16までのデータに対して適用を行います。

f:id:cxalpha:20170817135736p:plain

 

実際の最大電力と電力会社の予想、SAP PAの予測結果をプロットしました。↓

f:id:cxalpha:20170821081931p:plain

  電力会社RMSE SAP PA RMSE
8/10まで 91.71 49.25
8/16まで 78.07 93.92

8/10まではSAP PAで行ったモデルの予測結果が当たっているようです。

RMSE※を計算しても8/10までのRMSEは電力会社が91.71に対し、SAP PAが49.25とSAP PAの予測が当たっていますが、8/17までのRMSEは電力会社が78.07に対し、SAP PAが93.92と逆転されました。

原因としましては、休日設定は日本の祝日としたためにお盆休みが休日となっていなかったことや、8/11の山の日が2016年に導入されたため2015年までの学習データと状況が異なったことが考えられます。

 

※RMSE(Root Mean Square Error)

f:id:cxalpha:20170817142621p:plain

予測値が正解から乖離を示す。モデルの予測精度の悪さを表すため0 に近い値であるほど良い。

 

残念ながら電力会社に後半逆転され負けてしまいましたが、20分ほどで電力会社に匹敵する予測を行うことができました。

今回はSAP PAGUIでの操作がメインでしたが、SAP PAの分類/回帰分析ではJavaJavaScriptなどのソースもエクスポートすることが可能です。

次回以降に作成したモデルのソースエクスポートとその実行を行いたいと思います。

 

connpass.com

↑の合同勉強会でもSAP PAについて発表する予定です。

興味がある方はぜひお越しください。