Laboratory of Mobile Agricultural Chemicals Searcher
携帯農薬検索実験室

研究会

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
60 / 114 ツリー <前へ | 次へ>

〔495〕ACFinder 060920版 kabe (06/09/20 23:45)
〔497〕Re:ACFinder 060920版 kabe (06/09/21 0:12)
〔498〕Re:ACFinder 060920版 Hidemi Oya (06/09/21 22:23)
〔499〕Re:ACFinder 060920版 Hidemi Oya (06/09/22 21:19)
〔501〕病害虫タブ(MATCH演算子)の不具合 kabe (06/09/26 9:27)
〔502〕Re:病害虫タブ(MATCH演算子)の不具合 Hidemi Oya (06/09/26 23:10)
〔503〕Re:病害虫タブ(MATCH演算子)の不具合 Hidemi Oya (06/09/27 0:24)
〔504〕Re:病害虫タブ(MATCH演算子)の不具合 Hidemi Oya (06/09/27 21:44)

〔495〕ACFinder 060920版
 kabe WEB  (06/09/20 23:45)

引用なし
   kabeです。

060920版です。
http://acfinder.kabe.info/

作物タブの検索を REGEXP演算子を使う方式に変更しました。
今までは単純に LIKE 作物名% で前方一致で検索していましたが、正規表現検索で指定した作物名を含むものを全て検索対象とし、かつ「○○を除く」は除外されます。
作物名に「なす,野菜類」と指定した場合に「野菜類(なすを除く)」は検索対象となりません。
より精度の高い作物名検索ができますが、反面、検索速度は遅くなっています。

定型処理タブの機能もアップしてます。
[#483]
>今のところ仕様上の問題で、「さやいんげん(露地栽培),さやいんげん,豆類(未成熟),野菜類」のように露地栽培を検索対象としたいことが明らかであっても、「野菜類(施設栽培)」まで検索してしまいます。次のバージョンでは、作物名のどこかに「露地栽培」が含まれる場合は「野菜類(施設栽培)」や「野菜類(水耕栽培)」は検索対象外となるように変更します
が修正されました。

〔497〕Re:ACFinder 060920版
 kabe WEB  (06/09/21 0:12)

引用なし
   kabeです。

一部不具合というか、意図した動作とならない部分があるようです。

ミニトマト(施設栽培),ミニトマト,なす科野菜,野菜類」と指定すると「ミニトマト(露地栽培)」は除外される動作を想定してましたが、拾ってしまいます。
この点の修正は明日以降にしますので、お待ちください。

ということで 060920版は作物タブのREGEXP機能評価版とします。
速度面で、以前より体感的に遅いので、LIKE演算子を使った速度優先モードもあった方がいいですかね。

〔498〕Re:ACFinder 060920版
 Hidemi Oya WEB  (06/09/21 22:23)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

>ミニトマト(施設栽培),ミニトマト,なす科野菜,野菜類」と指定すると「ミニトマト(露地栽培)」は除外される動作を想定してましたが、拾ってしまいます。
 これは、CsvToRegExp 関数の設計思想によるものです。作物名は合致するもののみを検索し、上位分類の非合致な限定付き作物名を除外すれば良いという方針です。
 とりあえず、施設栽培のときに露地栽培だけを除外するので良いなら、
   if AnsiPos('露地', s) > 0 then s := s + '|施設|水耕';
の下に
   if sp and (AnsiPos('施設', s) > 0) then s := s + '|露地';
を追加すれば OK だと思います。ただ、「○○(トンネル栽培)」「○○(マルチ栽培)」といった「○○(露地栽培)」以外のパターンをどこまで網羅するかは検討する必要があるでしょうね。

 個人的には、作物名選択ダイアログの分類タブでも複数選択ができるようにし、選択した作物名に完全一致するものだけが出力された方が、いらないものまで表示されなくて使いやすいと思います。
 作物名選択の簡便さと、結果の精密さのトレードオフなので、どちらか一方のみを採用するとなると、かなり微妙な判断を迫られますけどね。当面、前方一致か完全一致かを選択できるようにして、ユーザが好きな方を使えるというのが良いかもしれません。

>速度面で、以前より体感的に遅いので、LIKE演算子を使った速度優先モードもあった方がいいですかね。
 確実に遅いですね(^_^;)。とはいえ、環境にもよるでしょうが、「稲」で検索しても何十秒もの時間がかかるわけではありません。従来の検索方法では、どうしても本来使えない農薬まで拾ってしまうところが不満でした(REGEXP はこの解消のために実装したようなものですから)。
 もし速度優先モードを付けるなら、こちらは完全一致にした方が良いと思います。

〔499〕Re:ACFinder 060920版
 Hidemi Oya WEB  (06/09/22 21:19)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

> 当面、前方一致か完全一致かを選択できるようにして、ユーザが好きな方を使えるというのが良いかもしれません。
 というようにするなら、LIKE を使った高速モードでもこれを使えばよいわけですね。

〔501〕病害虫タブ(MATCH演算子)の不具合
 kabe WEB  (06/09/26 9:27)

引用なし
   kabe です。

修正版遅れてますが、今週末にはなんとかしたいと思います。

ところで、病害虫タブに不具合がありました。
MATCH 演算子を使っているのですがどうも意図した結果が帰ってきません。

SELECT DISTINCT byochu FROM m_Tekiyo WHERE byochu MATCH '%サビダニ%' order by byochu

と LIKE を使った場合の検索結果が異なります。

MATCHを使った場合、なぜか「トマトサビダニ」が出てきません。
MATCH '%ハモグリ%' では「イネハモグリバエ」「トマトハモグリバエ」が出てきません。
LIKE では出てきます。

>Hidemi Oya さん
原因わかりますか?

〔502〕Re:病害虫タブ(MATCH演算子)の不具合
 Hidemi Oya WEB  (06/09/26 23:10)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

>MATCHを使った場合、なぜか「トマトサビダニ」が出てきません。
>MATCH '%ハモグリ%' では「イネハモグリバエ」「トマトハモグリバエ」が出てきません。
 「イネ○○」は「%シンガレセンチュウ%」とかでもダメですね。「%センチュウ%」なら「イネシンガレセンチュウ」は出ますが…。
 「イネ」「トマト」のほかに、「シスト」「コブ」「、」に検索語が続くとやはりダメですね。

>原因わかりますか?
 う〜ん、特定の文字列だけ漏れてしまうってのは、理解に苦しみます。私のプログラム側の問題なら全てのパターンでダメになるはずなので、Ddelphi の UTF か Ansi 系ライブラリ、あるいは Windows の LCMAP 系 API の問題かもしれません。が、そうだとすると対策はちょっとやっかいで、簡単には対応できないかも…。
 改善は検討しますが、時間がかかりそうなので、当面
 MATCH '%pattern%'
の代わりに
 REGEXP 'pattern'
をお使いください。'%pattern' は 'pattern$'、'pattern%' は '^pattern'、'pattern' は '^pattern$' です。現在は REGEXP が速度向上しているので、単純パターンなら MATCH と検索時間は変わりません(LIKE に比べると遅いですが、単純パターンなら待ち時間は1〜2秒だと思います)。

〔503〕Re:病害虫タブ(MATCH演算子)の不具合
 Hidemi Oya WEB  (06/09/27 0:24)

引用なし
   kabe さん、こん**は。Hidemi Oya です。

> う〜ん、特定の文字列だけ漏れてしまうってのは、理解に苦しみます。私のプログラム側の問題なら全てのパターンでダメになるはずなので、Ddelphi の UTF か Ansi 系ライブラリ、あるいは Windows の LCMAP 系 API の問題かもしれません。
 AnsiPos で文字列検索してるのに、UTF8 エンコードの文字列を渡してました。エンコード間違いという、実に基本的なミスですね(^_^;)。
 対策コードでは、余分な AnsiToUtf8 変換が減ったので、ほんのわずかですが検索速度も上がってます。

〔504〕Re:病害虫タブ(MATCH演算子)の不具合
 Hidemi Oya WEB  (06/09/27 21:44)

引用なし
   自己レスです。

> AnsiPos で文字列検索してるのに、UTF8 エンコードの文字列を渡してました。エンコード間違いという、実に基本的なミスですね(^_^;)。
 だんだん思い出してきました。これ、本来は UTF8 エンコードの文字列を Pos 関数で検索するように作ってありました。おそらく、SQLite コンポーネントを作ったときに、勘違いして AnsiPos に書き換えてしまったのではないかと思います。
 ま、おかげで MATCH 演算子がほんのわずかとはいえ速度が上がったので、怪我の巧妙ともいえますが(^_^;)。

 話は変わって、MATCH, REGEXP の高速化について。
 前々から思ってはいたのですが、検索パターンが定数の場合、これを事前に正規化するプリプロセッサ関数を実装すれば、今よりも高速化できるのではないかと考えています。現在は、検索パターンが式の場合を考慮して、検索する側も検索される側も毎回正規化しています。が、検索パターンは定数のことが多いので、プリプロセッサ関数で最初に正規化してやれば、SQL 実行中は検索される側だけ正規化すればすみますから、文字列正規化ルーチンを呼び出す回数は半分ですみます。

  ツリー表示 ┃スレッド表示 ┃一覧表示 ┃トピック表示 ┃番号順表示 ┃検索  
60 / 114 ツリー <前へ | 次へ>
ページ:  ┃  記事番号:   
(SS)C-BOARD vv3.8 is Free.