App Inventor for Android で SVM（サポートベクトルマシン）分類

以下は同じような心境とお考えください。

｢なぜ山に登るのか｣
｢なぜスマホでSVM分類するのか｣

下記の書籍は、数多くある機械学習関連のうちの非常に優れた一冊です。これに刺激を受けて、その中にあった、SVMによる分類の例題を、Android向けにデモアプリとして動かしました。下図のとおりです。

歴史上の人物の特徴量を与えて、その人を｢政治家｣か｢非政治家｣かに分類する例題です。

SVMのJavaライブラリは、LIBSVM（国立台湾大学による）を利用させていただきました。上記のAndroidアプリは、MIT App Inventorを使って作成しました。既存のApp Inventorのブロックだけでは、このようなアプリはほとんど作成できません。そこで、LIBSVMを使ったJavaアプリを作成し（下記書籍を参考に）、App InventorのActivity Starter機能（ブロック）を使って、これを呼び出す形にしています。上の実行例画面でその概要を示します。↑拡大してご覧下さい。

このアプリでは、20名のデータのうち、ランダムに１名を選んで、それを｢テスト用データ｣とし、残り19名のデータを｢学習用データ｣として学習、テストを繰り返し実行できます。

また、このアプリの学習データを入れ替えれば、類似の問題、例えば有名な｢タイタニック号の乗客の生死｣の分類等にも（データ加工に幾らかの工夫は必要でしょうが）適用できそうです。

●参考書籍
杉本徹+岩下志乃共著｢Javaで学ぶ自然言語処理と機械学習｣、オーム社

A good example of Extension for App Inventor

If you want to create your own blocks (Extensions blocks) with App Inventor, how about referring to the example below. It is an ImageProcessor Extension published on the MIT App Inventor site. This makes two images to be combined into one.
http://appinventor.mit.edu/extensions/

It is said to be "Unsupported" materials, but intelligible Java source code has been released. The main functions of this extension are as follows:

• Fetch two images into the application, then creates an image combining the two.
• Give a weight to decide which image to adopt strongly.
• For all the pixels, for each of the elements of R, G, B, A, both images are combined according to the weight. It is as follows: (pixel in image C) = weight * (pixcel in image A) + (1 - weight) * (pixcel in image B)
• Writes the image of the join result to external storage. In doing so, give write permission with annotation @UsesPermissions.

From the Java source code of this Extension, you can learn the following basic items:

• Basic operation of pixels of an image
• How to make a function block with and without return value
• Generation of user event and its processing
• How to set properties (image size, weight,  etc.)

After understanding this Java source program, I made a very simple application using this extension. The following figure shows the entire source program of this application. Of course, thanks to this Exrensions block, this is extremely consice. Furthermore, after preparing the Java source list, you do not need to set up the build environment yourself. The following cloud builder will take care of everything.

http://editor.appybuilder.com/

Complete source program using Extensions blocks

Two examples of execution result of this application are shown below. The images as expected were obtained. How fun this is!

Original images(above) and the combined image(blow)

I would like to introduce my second version Extension which is a little advanced now.

With this experience as a clue, you want to develop yet another unique Extensions. The following reference sites would help you.

# How to make Extension concretely
http://ai2.appinventor.mit.edu/reference/other/extensions.html
# Java source code for existing blocks in App Inventor
https://github.com/mit-cml/appinventor-sources/tree/master/appinventor/components/src/com/google/appinventor/components/runtime

Java is Still Free

｢Javaは有償化される！｣というニュースが流れていました。しかし、本当にそうなのか、真の意味はどうなのかを問う記事を私は過去に書きました。以下の記事です。
Java（JDK）有償化で大学等での教育研究に支障はあるか

また、下記のサイトにもその関連記事が掲載されています。
｢すべての人のためのJavaプログラミング　書籍サポートページ｣
https://www.i.h.kyoto-u.ac.jp/users/tsuiki/javaEveryone3/link.html
｢Javaプログラミングを学ぶ...｣

このほど、Oracle Code Oneで発表された講演に、｢Java is still free｣というのがあったそうです。これは読んでみる価値がありそうです。日本のJava Championらによる以下の記事は、正確そうで信頼できそうです。

https://docs.google.com/document/d/1HtUnuAkUEDGL2gwUOkrDrmLe_zrD6wpAyqYBZxRmHv4/edit

https://codezine.jp/article/detail/11258?utm_source=cz-news&utm_medium=email&utm_campaign=cz-news20181219

Creating my own extension blocks for App Inventor

MIT App Inventor for efficiently developing mobile applications has functions named Extensions that users can develop their own blocks. If you know Java, in principle you can do that, but in fact it's not so easy. Development methods for Extensions are presented in several sites, among which the AppyBuilder Code Editor shown in the following is extremely easy to use and useful:
https://amerkashi.wordpress.com/2018/11/26/appybuilder-code-editor/
http://Editor.AppyBuilder.com

Anyway, here we will create a simple and unique block with Extensions. The figure below is a hearing training application using English news. There is a counter to record how many times you have heard a particular news. Of course, even when resuming after turning off the power of smartphone, that counter must be continued. In other words, it must be created as a persistent counter.

Persistent counter in a real app

We will proceed with a simple application that extracts only this persistent counter portion as follows.

Persistent counter for an examination

If you use TinyDB, you can easily create such a counter as shown below. However, to do that, first you need to read the value of the counter (tag) from TinyDB, add 1 to it, and store the result in TinyDB again. This is very troublesome, because this counter is supposed to be used in many situations.

Persistent counter made with normal TinyDB (built-in)

To alleviate this complexity, we have created a new block to "count up one tag value" that is not found in the conventional Tiny DB. Including the original TinyDB functions, I made this name FoYoDB. As you can see, count-up part became very neat!

Persistent counter made with new FoYoDB (Extension)

In order to have versatility in this FoYoDB, we also made a block that allows you to arbitrarily specify "step value for counting up" as follows. This time, we created Extensions to extend original TinyDB, but from now on we would like to tackle the development of Extensions with higher originality.

All blocks created as an extension FoYoDB

Google Fusion Tables Turndown

One of the easy-to-use web databases on various smartphone applications is Google Fusion Tables. This has been effectively used especially in MIT App Inventor, Thunkable, AppyBuilder and others. So I was surprised at the email from Google that I received recently. In the mail, it was written as follows:

"we will be retiring Fusion Tables. We plan to turn down Fusion Tables and the Fusion Tables API on December 3, 2019. .... Maps using the Fusion Tables Layer in the Maps JavaScript API v3.37 will start to see errors in August 2019."

please see also MIT App Inventor Forum:
https://groups.google.com/forum/#!topic/mitappinventortest/Z5ft8KY93O4

Famous Pizza Party app based on Fusion Tables

In other words, the day we have to say good-by to FusionTables is coming! Besides this, there is also a key-value type Tiny WebDB as a web database that can be used from a smartphone. However, this Fusion Tables is a highly versatile SQL type, and furthermore it was superior in visualization and cooperation with maps. Retiring this valuable database makes us sad.

Let's write some memories of Fusion Tables. As an example of App Inventor app, Pizza Party using this was famous. Below are excellent commentaries, which many enthusiasts were able to create their own applications based on.

http://appinventor.mit.edu/explore/ai2/pizzaparty.html

In addition, the following Pura Vida Apps (by Taifun) has responded to various troubles in using Fusiontables. Many users will also appreciate it.

"Frequently Made Errors with Fusion Tables and how to fix them"
"How to use the Service account option to connect to a Fusion Tables"
https://puravidaapps.com/fusionservice.php

Currently, with smartphone applications, more advanced Firebase DB and CloudDB can be used. Actually in App Inventor, those functions are either built in as standard or provided as one of Extensions. In the future, these will gradually be used. 

Thank you Google Fusion Tables!

WebDB expected as a successor to Fusion Tables

A paper on parallel algorithms for old supercomputers

As you may know, ResearchGate is one of social network services for academic persons. I have not used it very much, but I registered as a member in the past. Recently, the following e-mail arrived from ResearchGate.

The above paper was accepted in IEEE Transactions in 1985 (about 33 years ago). A kind of parallel computing algorithms for the supercomputer (vector machine) at the time was proposed and analyzed. This modest e-mail tells me that this paper is cited from 31 other papers and that 51 subscriptions have been made by ResearchGate readers. 

It is not a big event, but I am happy myself. At that time, the supercomputer was a vector computer with several number of parallel pipelines controlled by chaining technology. After that, there are thousands of processor configurations that are said to be massively parallel, and now they are transitioning to millions of many core (multi-core) configurations. However, underlying foundation of most parallel algorithms would be common to any configuration. For that reason, the algorithms for the old vector machine may still be a reference now.