■自宅サーバ計画破綻……
　NASで自宅サーバを立てて遊ぶぜと思ったけど、無理やった。
　コミュファ光、固定IPじゃないじゃん……。
　ちな、mixhostにしました。

■レンタルサーバ選び条件
　鯖選びで悩みました……
　まず、アダルトOKなのは必須。
　エロいのがやりたいわけじゃなくて勝手にサイト消されないのが必須。
万が一掲示板作ったとかで、エロ投稿でアカウントごと消されるのは嫌だし。
　かつ勉強がてらなので、高いのはNG。
　アダルトOKで月1000円以下なのが必須条件かなー。月100万円稼ごうとは考えていないし。
　そういうのは海外鯖なのが必須条件だし。

■候補
　ここ参考にした。まーGoogleで一発で出るとこ。
<https://sabarentalserver.com/hosting/hikaku/adultserver/>

・mixhost
・FUTOKA
・アナハイム

とりあえずこの三つあたり。適当に。

■ここにした
　mixhostにしてみた。一年契約縛りでいってみた。13000円か。たけーな。
　理由は深く考えずに、直感。

■後悔
　あれ、このサーバVPSサポートしていねぇ……
　REDMINEサーバ立てられないじゃん……

■そしてそれは閃光のように
　あ、察し。俺の13000円が……

■照合順序の疑問
SQL Serverだとインスタンスを作成する際に照合順序の設定が出来た。
たとえばCI_とかだ。これを設定すると大文字小文字・半角全角・ひらがなカタカナが同一視されないようになった。

しかし、SQLiteだとどういう仕様なのかよくわかっていない。
本記事はこの仕様についてレポートする。


■公式サイトの記述
Datatypes In SQLite Version 3
https://www.sqlite.org/datatype3.html
以下のように記載がある
7. Collating Sequences
------------------------------------------------------
When SQLite compares two strings, it uses a collating sequence or collating function (two words for the same thing) to determine which string is greater or if the two strings are equal. SQLite has three built-in collating functions: BINARY, NOCASE, and RTRIM.

・BINARY - Compares string data using memcmp(), regardless of text encoding.
・NOCASE - The same as binary, except the 26 upper case characters of ASCII are folded to their lower case equivalents before the comparison is performed. Note that only ASCII characters are case folded. SQLite does not attempt to do full UTF case folding due to the size of the tables required.
・RTRIM - The same as binary, except that trailing space characters are ignored.

An application can register additional collating functions using the sqlite3_create_collation() interface.
------------------------------------------------------
意味わかんないなｗ翻訳しようｗ
------------------------------------------------------
SQLiteは2つの文字列を比較するとき、照合シーケンスまたは照合関数（同じものに対して2つの単語）を使用して、どちらの文字列が大きいか、または2つの文字列が等しいかどうかを判断します。 SQLiteには、BINARY、NOCASE、およびRTRIMという3つの組み込み照合関数が組み込まれています。

・BINARY - テキストのエンコーディングに関係なく、memcmp（）を使用して文字列データを比較します。
・NOCASE - バイナリと同じですが、ASCIIの26文字の大文字は、比較が実行される前に同等の小文字に変換されます。 ASCII文字だけが大文字に変換されることに注意してください。 SQLiteは、必要なテーブルのサイズのために完全なUTFの大文字小文字の変換を試みません。
・RTRIM - バイナリと同じですが、末尾のスペース文字は無視されます。

アプリケーションは、 sqlite3_create_collat​​ion（）インタフェースを使用して追加の照合関数を登録できます。
------------------------------------------------------


■まとめ
・BINARYはメモリ照合。大文字小文字半角全角ひらがなカタカナは同一視しないっすよ
・大文字小文字は全部小文字にして比較する（大文字小文字は同一視しますよ）
・メモリ照合だけど、末尾スペースは切り取るよ
ってことね。

ちなみにBINARYがデフォルトだから、
大文字小文字半角全角ひらがなカタカナが同一視される心配は無いということだ。


■補足１ BINARYがデフォルトだとしている記述
7.1. Assigning Collating Sequences from SQL
Every column of every table has an associated collating function. If no collating function is explicitly defined, then the collating function defaults to BINARY. The COLLATE clause of the column definition is used to define alternative collating functions for a column.

7.1. SQLからの照合順序の割り当て
すべての表の各列には、関連する照合機能があります。 照合機能が明示的に定義されていない場合、照合機能のデフォルトはBINARYになります。 列定義のCOLLATE句は、 列の代替照合関数を定義するために使用されます。


■補足２　LIKEについての注意点
……と思ったら=だと同一視されなかったんですが、やっぱりLIKEだと大文字小文字は同一視されるみたい……。サンプルプログラムを作ってテストしたから間違いない。
恐らくLIKEの仕様なんだろう（投げやり）。ま、=さえちゃんと効けば問題ないさ。


■書くときに参考にしたサイト
Django と SQLite/MySQL ： 照合順序を意識しよう
http://hideharaaws.hatenablog.com/entry/2015/03/17/160122
Datatypes In SQLite Version 3
https://www.sqlite.org/datatype3.html

ソースコードのレポを印刷すべく久しぶりにEPSONのA890を使用すべく、電源を入れた。
はずだったのだが、起動せん。
電源ケーブルは通電しているはずなのだが、電源そのものが入らないのだ。

何か動かしたというわけではなくPC初心者が言う「何もしないのに壊れた」状態である。
電源の入れなおしや、電源ボタン長押しを行ったが、うんともすんとも言わぬ。

エプソンのサポセンのHPを開き、修理費用を見ようと試みたが、、、サポート終わってる。
純正インク八割残ってるのに・・・

なぜか起動するたびにすさまじい勢いでインクを消費する糞プリンタを作り続ける、糞企業め。
「刷れば刷るほど損をする、エプ損」
こういわれていたEPSONだったが、認識を改めねばならぬ。

「刷る前に壊れる、エプ損」

あーあ。年賀状シーズン控えているのに、手痛い出費だ。
化石であるcanonのBJ890はまだ死に掛けながらもまだ動いているというのにな。スキャナー無いけど。
昔のやつの方が丈夫なんだろうか？　いや、電子機器でそんなことは無い筈なのだが・・・・。

そのうち新しい複合機買います。ええ。もう二度とEPSONのものは買わん。
次からはcanonじゃ・・・刷れば刷るほどインク代が浮くcanonにするんじゃ・・・。
canon最強じゃ・・・。


ということでcanonを買いますよ！　え？HP？　なにそれ、おいしいの？

私は32bitDIBクラスを作成して使用しているのだが、今回、エフェクトを作りたいと考えるようになった。
その上で、私は飽和加算および飽和減算を行う必要性があることに気がついた。
なぜなら、個別にビットを切り演算すると言うことは著しい速度低下が行われるからだ。

既存の方法
//32BitDIBは EERRGGBB(EEは使用しない)として使用されているので、分解しRGBを受け取る
void CDIBGL::GetRGBfor32DIB(LPCOLORREF bgr,LPBYTE r,LPBYTE g,LPBYTE b){
    *r = (BYTE)((*bgr & 0x00FF0000)>>16);
    *g = (BYTE)((*bgr & 0x0000FF00)>>8);
    *b = (BYTE)((*bgr & 0x000000FF));
    //printf("RGB :%.8X R:%.2X G:%.2X B:%2X\n",bgr,*r,*g,*b);//debug用
}

BYTE CDIBGL::GetBYTE(int i){
    if( (i>>31)&0x00000001 ){//負数ならば i<0
        return 0x00;
    }
    if( (i>>8) > 0){//iが負数でないとき255より上のビットがあれば　i>255
        return 0xFF;
    }
    return (BYTE)i;
}

まあ、最初はこの二つのメソッドを使用してこのように値を取り出して加算していたわけだ。
…… まあ、いろいろなサイトを見てこの方法に行き着いたし、速度面を除けば不満はない。
速度を考えなければな！

ちなみに、二つのメソッドをそのまま使用する関数にコピペすると約七割～九割程度の時間短縮が可能だ。
これは実測で分ったことだが、見栄えが悪いし時間がかかりすぎる。

改善するにあたって参考にしたサイト
まず、このサイトを見て欲しい。
http://shakenbu.org/yanagi/misc/bitop.html
非常に有益な方法が書いてあることが一目でわかる、いいサイトだなって思う。マジおすすめ。

でも俺は頭が良くない！
だが、よくわからん。ビット演算はよくわからんな、直感的に理解できない。
じゃ、どうしようって俺は考えた。

そうだ！　値をみて考えよう！

ということで以下のようなソースファイルを作って演算や値を見て考えることにした。
飽和加算の実験ソースコード
////////////////////////////////////////////////////////////////////////////////////////////
#include <stdio.h>
#define DWORD unsigned int
#define COLORREF DWORD
#define WORD unsigned short
#define BYTE unsigned char

#define RGB(r,g,b)  ((COLORREF)(((BYTE)(r)|((WORD)((BYTE)(g))<<8))|(((DWORD)(BYTE)(b))<<16)))

char *print_bin( unsigned int x ){
static char  out[100];
    unsigned int n, i, j;
    n = 1<<31;
    j = 0;
    for( i=0; i<32; i++ ){
        if( x&(n>>i) )
            out[j]='1';
        else
            out[j]='0';
            j++;
        if( i%4==3 ){
            out[j]=',';
            j++;
        }
    }
    out[j-1] = '\0';
    return out;
}


int main(void){
    char str[100];
    DWORD A,B,tmp,mask,result;
   
    A=RGB( 12,123,255);//012とすると8進数と間違えられる恐れあり
    B=RGB(111,222,148);
   
    printf("tmp = ((A&B)+((A^B)>>1)&0x7f7f7f7f)&0x80808080\n");
   
    printf( "A         :(%s)_2 = (%.8X)_16\n",print_bin( A ), A );
    printf( "B         :(%s)_2 = (%.8X)_16\n",print_bin( B ), B );
   
    tmp = A&B;
    printf( "A&B       :(%s)_2 = (%.8X)_16\n",print_bin( tmp ), tmp );
   
    tmp = A^B;//^はXOR！知ってると思うけど！
    printf( "A^B       :(%s)_2 = (%.8X)_16\n",print_bin( tmp ), tmp );
   
    tmp = (A^B)>>1;
    printf( "A^B>>1    :(%s)_2 = (%.8X)_16\n",print_bin( tmp ), tmp );
   
    printf( "0x7f7f7f7f:(%s)_2 = (%.8X)_16\n",print_bin( 0x7f7f7f7f ), 0x7f7f7f7f );
   
    tmp = ((A^B)>>1)&0x7f7f7f7f;
    printf( "((A^B)>>1)&0x7f7f7f7f:\n           (%s)_2 = (%.8X)_16\n",print_bin( tmp ), tmp );
   
    tmp =  (A&B) + (((A^B)>>1)&0x7f7f7f7f);
    printf( "(A&B)+((A^B)>>1)&0x7f7f7f7f:\n           (%s)_2 = (%.8X)_16\n",print_bin( tmp ), tmp );
   
    printf( "0x7f7f7f7f:(%s)_2 = (%.8X)_16\n",print_bin( 0x80808080 ), 0x80808080 );

    tmp =  (A&B) + (((A^B)>>1)&0x7f7f7f7f)&0x80808080;
    printf( "((A&B)+((A^B)>>1)&0x7f7f7f7f)&0x80808080:\n           (%s)_2 = (%.8X)_16\n",print_bin( tmp ), tmp );
   
   
    printf("\nmask = (tmp << 1) - (tmp >> 7)\n");
    mask = tmp<<1;
    printf( "tmp<<1:    (%s)_2 = (%.8X)_16\n",print_bin( mask ), mask );
   
    mask = tmp>>7;
    printf( "tmp>>7:    (%s)_2 = (%.8X)_16\n",print_bin( mask ), mask );

    mask = (tmp<<1) - (tmp>>7);
    printf( "(tmp<<1)-(tmp>>7):\n           (%s)_2 = (%.8X)_16\n",print_bin( mask ), mask );
   
   
    printf("\nresult = (( A + B ) - mask) | mask\n");
    result =  (A+B)-mask;
    printf( "(A+B)-mask:(%s)_2 = (%.8X)_16\n",print_bin( result ), result );
   
    result =  ((A+B)-mask)|mask;
    printf( "((A+B)-mask)|mask:\n           (%s)_2 = (%.8X)_16\n",print_bin( result ), result );
   
    return 0;
}

////////////////////////////////////////////////////////////

まあ、こんな感じ。わざわざブログにソースコードを載せる必要なんて無いんだけどね。
ちなみに
char *print_bin( unsigned int x )
は32bitの変数を二進数で表示する関数。printfで使用している。
＊実はどこかで拾ったのだがどこで拾ったのか思い出せん。
確か元々１６ビットのを二進数にする関数だった覚えがある。でも32ビット欲しかったから少し改変して32ビットに対応させた。うーん、どこだったっけ……見つけたら追記しておく。作者の人ごめんね。

で、実際の演算結果は下のようになった。
ソースコードの演算結果

tmp = ((A&B)+((A^B)>>1)&0x7f7f7f7f)&0x80808080
A         :(0000,0000,1111,1111,0111,1011,0000,1010)_2 = (00FF7B0A)_16
B         :(0000,0000,1001,0100,1101,1110,0110,1111)_2 = (0094DE6F)_16
A&B       :(0000,0000,1001,0100,0101,1010,0000,1010)_2 = (00945A0A)_16
A^B       :(0000,0000,0110,1011,1010,0101,0110,0101)_2 = (006BA565)_16
A^B>>1    :(0000,0000,0011,0101,1101,0010,1011,0010)_2 = (0035D2B2)_16
0x7f7f7f7f:(0111,1111,0111,1111,0111,1111,0111,1111)_2 = (7F7F7F7F)_16
((A^B)>>1)&0x7f7f7f7f:
           (0000,0000,0011,0101,0101,0010,0011,0010)_2 = (00355232)_16
(A&B)+(((A^B)>>1)&0x7f7f7f7f):
           (0000,0000,1100,1001,1010,1100,0011,1100)_2 = (00C9AC3C)_16
0x80808080:(1000,0000,1000,0000,1000,0000,1000,0000)_2 = (80808080)_16
((A&B)+((A^B)>>1)&0x7f7f7f7f)&0x80808080:
           (0000,0000,1000,0000,1000,0000,0000,0000)_2 = (00808000)_16

mask = (tmp << 1) - (tmp >> 7)
tmp<<1:    (0000,0001,0000,0001,0000,0000,0000,0000)_2 = (01010000)_16
tmp>>7:    (0000,0000,0000,0001,0000,0001,0000,0000)_2 = (00010100)_16
(tmp<<1)-(tmp>>7):
           (0000,0000,1111,1111,1111,1111,0000,0000)_2 = (00FFFF00)_16
result = (( A + B ) - mask) | mask
(A+B)-mask:
           (0000,0000,1001,0100,0101,1010,0111,1001)_2 = (00945A79)_16
((A+B)-mask)|mask:
           (0000,0000,1111,1111,1111,1111,0111,1001)_2 = (00FFFF79)_16

よくわかるような気がする解説。
引用したサイトを見て分る人は読む必要が全くないのだが、一応解説。

まず前提として理解して欲しいことはtmpでやりたいことだ。
これは演算結果からも明白なようにmaskを作るための演算で、実際の今回の演算結果を見ると、
((A&B)+((A^B)>>1)&0x7f7f7f7f)&0x80808080:
    (0000,0000,1000,0000,1000,0000,0000,0000)_2 = (00808000)_16
mask = (tmp << 1) - (tmp >> 7)
    (0000,0000,1111,1111,1111,1111,0000,0000)_2 = (00FFFF00)_16
もうやりたいことが分ったと思う。つまりtmpではmaskを作るためにその8ビットの先頭を1にすることが目的なのだ。

次に理解して欲しいことは0x7f7f7f7fの取り扱いで、これは
0111,1111,0111,1111と続いていく。
これが何を表しているのかというと、他の値へ繰り上がるビットをマスクして除去している。
なんで0111,0111としていないかは当然わかるよね？
（ヒント：一色は８ビット……いや、ヒント要らなかったか）

更にA^B>>1は何かと言えばxorしているものを1ビットずらしているんだ。
（^はxor。xorはわかる……よね？）
これは8ビットの最初のビットが片方1かを確認しているだけだ。他のビットには一切考えなくてもいい。
（だって、&0x7f7f7f7fでマスクするんだから！）
で、右にずらす意味がわからんだろう？　それはA&Bを加算したときに理解できると思う。

勘のいい人はもう分ってるね。お疲れ様でした。
（もちろん、勘のいい人というのは情報工出身者を指すぞ！）

まあ、典型的な繰り上げ加算処理だから分ってる人は飛ばして貰っていいんだが、
このあと、A&Bと加算するとあら不思議、飽和する８ビットの先頭が１に！！！！

これはA&Bで８ビットの先頭が１ならそのまま１に
(A&B)+(A^B)>>1との加算で８ビットの二番目のビットを繰り上げるわけだ。
なんでXORだったか分るよね？仮にそのままandしていたら今頃８ビットの先頭は1+1で繰り上がって0になってしまう。

あとは簡単だから説明しない。
流石にこれ以降で分らない部分は流石に無いと思うので。
（分らんとこは演算結果を見ればすんなり理解出来ないと思う）

感想
記事……長！！！！ひでぇ！！こんな記事誰も読まない気がする！！！！！
熱心に書いたらすごく長くなってしまった。


あ、ちなみにmainのソースコードや演算結果の表示が少し汚いけどそこはスルーで。
（元々、記事にするつもりは無く独習のつもりだったので勘弁してくれ！）

飽和減算の記事も書きたいな。また、時間があったら書こう。