自然言語処理スレッド その5
レス数が900を超えています。1000を超えると表示できなくなるよ。
このスレッドでは、おもに日本語の構文解析・談話理解・情報検索・
文章生成などの、実装とそれに付帯する技術および理論について
扱いたいと思っています。 >>809
レスがコピペにしか感じないならあなたが
オリジナル性のあるレスをすればいいでしょ?
そういうレスこそ生産的だから待ち望んでいるよ >>813
>あなたはプログラミングの経験がないのでは?
決めつけはよくないな
「あなたは要件定義の経験がないのでは?」
とでも返そうか?
業務は流動的なので確定していないことが多い
RPA(の導入)なんかでもツール自体よりも
業務フローの把握や整理とかが難しいことが多い
>仕様が確定すればプログラミングは可能になる
もちろん仕様が確定してた方が作りやすいけど
本当は長期的には不確定な部分は必ず残るんだよね
たとえば消費税や年号のように変化する部分がある
機能の拡張や修正なども当然出てくるだろうし
それでプログラムを抽象化するのは未来への投資で
抽象化や間接化で不確定性に対応できるようにする
逆に変化しないならハードコーディングでいいけど >>811
>>たしかに言語(棋譜)とも言えるし画像とも言えるね
アルファ碁に関しては専門の論文や解説書があるので、ここでは深く言及しないが
将棋でも囲碁もある局面(例えば10手進んだ局面)では画像データになる
19×19の碁盤に白石と黒石が配置された1枚の絵になるので
Googleは画像処理技術を応用したんですよ
猫の画像を入力する代わりに、ある瞬間の棋譜の画像を入力する
猫か猫でないかを判別する代わりに、その局面が優勢か劣勢かを判別する >>817
>Googleは画像処理技術を応用した
グーグルだから有名な話だと思うけど
じつは他にも同様の例があるんだよ?
たとえば株式市場はチャートで表現できるから
グラフの画像にして画像認識させて
それで株価が上がるか下がるかを出力させようと
でもここで囲碁と大きな違いがあってそれはやはり
囲碁は完全情報だけど株式市場は不完全情報なので
株価を予測できるとは限らない(できない場合が多い) >>816
あなたとけんかするつもりはないですが、
要件定義はプログラミングとは呼ばない (呼ぶべきではない)
基本設計も同じ
一般に自動化プログラミングと呼ばれるものが過去にもあったけど、
自動化プログラミングとAIとは違いますよね
入力情報と出力結果は自動化プログラミングでもAIでも同じです
自動化プログラミングは仕様書を機械的にプログラム言語に置き換えただけ
AIは別のアプローチでプログラムを作る(探索とか学習とかで)
自動化プログラミングで仕様書からプログラムを作れるのならこれは完全情報ゲームですよ >>818
意味がわからない
株価予測と株価データからチャートを作成する問題は別
株価チャートを作るプログラミングは完全情報ゲームとして扱わないとプログラムなんか作れませんよね
例えば1カ月分の日足データと、グラフィックライブラリがあれば基本的に作成できるはず
サイズとか期間とか目盛とかいろいろあるんでしょうけど、全部事前に決めてあげるもので
全部決まったら完全情報ゲームですよ 明地文男、3点チャージ投資法
http://3-charge.b.la9.jp/
日経平均大幅続落で、日経225は、198銘柄が3点チャージ!
「トヨタ」「ホンダ」「キャノン」」などがレア・チャージ!
底値に針を仕掛ければ、一瞬で、数% は上がる! そもそも生データがあるのにわざわざチャート画像化して学習する意味あるの? >>819
株価予測AIが作れても予測が上手くいかないのは
不完全情報ゲームが対象だから、不完全なものになるから
「情報が完全でなければプログラミングは不可能」というよりも
「情報が不完全なら不完全なプログラム」になるということです
つまりプログラムの作成は可能だが機能は不完全だということ
要件定義を通して現実世界とのズレが埋まってないとも言えます
>自動化プログラミングで仕様書から
>プログラムを作れるのならこれは完全情報ゲーム
でもそれは仕様書レベルからの自動化であって
要件レベルから直接的に自動化できるプログラムはまだない
(もしあればプログラマは皆失業する)
たいていの場合は要件というか
自然言語で表現される対象の現実が不完全なので
人工言語の仕様書に落として
人工言語のプログラムに翻訳するという形になる
これはコンパイラ(やインタプリタ)が高級言語を
アセンブラや機械語に翻訳するのと同じ構図でしょう?
だからふり返って昔にはコンパイラの研究が人工知能と
分類されていたのもそんなにおかしくないんだけれど……
それで色んな事をガーッと言ってきたけど、とくに私が言いたい
さしあたりの結論としてはビジネスでは現実とのズレはなくらないということ
または、もしプログラミングは完全でもソフト開発としては不完全ということ >>820
プログラミングが仕様に対して完全でも
最初の要求は株価を予測することなので
要求に対しては不完全ということですね >>822
えーっともちろんべつに画像化しなくても
独自のデータ構造で解析してもいいんだろうけど……
画像化することで画像認識のライブラリが使えるから
少なくとも一から作る手間が省けるとか
一つの試みとしてメリットは存在するでしょうと cnnから入った人は
時系列データとか
分からない もちろん画像と違って
株式市場は時系列データだから
そういう処理をしようという考え方もあるよ
言語も時系列データ(音声言語はとくにそうだし)
として扱うのも有効な手法でしょう
囲碁の局面を画像化するという話題が出たから
それの応用が利くような例を挙げただけ >>823
話が発散していて会話が成立しません
まず私が「AIプログラミング」と呼んでいるのは「AIが仕様書に基づいて完全なプログラムを作成すること」です
仕様書が不完全なら当然プログラムは欠陥になります
完全な仕様書を作成するのにもAI分野の技術手法は使えるかもしれませんが
それはここではAIプログラミングとは呼びません (話が発散してしまうので)
基本的なアプローチとして、機械に近い部分から解決していくか、人間に近い部分から解決していくか
というスタンスがあります
いろいろ考え方はあると思いますが、
機械に近い部分から解決されていくだろう…と私は思っています
機械に近い部分は規則や前提条件が明確だからです
詳細仕様書からAIがプログラムを作れるようになれば、次は
基本設計書から詳細仕様書を作る方法は?といった具合に
より曖昧でてこずる領域に進んでいくのだと思います
多分、何十年もかけてね >>824
意味がわかりません
株価予測プログラムならそんなのは無理ですよ
経済学を駆使してでも物理学を駆使しても理論的基盤がないのだからね
せいぜい統計学と確率論でルールを決めうちしてプログラムを作ることになるのでしょう
ルールを決め打ちしてしまったなら、そこから先は「完全情報ゲーム」の世界に移行するのでは? >>822
目的次第でしょうね
この会話ではそこがぶれてるのでなかなか一致点を見つけるのがむずかしい
株価予測が目的なら、多分、過去の株価データからパターンを見つけ出して…
というところに学習の意味があるのでは
私が学習と言っているのはAIにプログラムを作らせたい…というのが念頭にあるので、
プログラマが過去に作った大量のプログラムを学習して…というイメージで話しています 完ぺきな株価予測プログラムは存在しないが、
トレーダーの代わりに株の売買が出来るAIは存在するし既に稼働している。
金融工学を極めた高給取りのファンドだって損をしながらギリギリで利益を出してる。
AIに求められる精度は連中と同等で全然オケ >>828
>話が発散していて会話が成立しません
ではイメージできるよう
具体的なストーリーにしましょう
>「AIプログラミング」と呼んでいるのは
>「AIが仕様書に基づいて完全なプログラムを作成すること」
――という前提なら、「AIプログラミング」の定義上
AIプログラミング自体は完全な仕様書を作成できないので
仕様書は人間(プログラマ)が作ることになるでしょう
プログラムはAIが仕様書から完全に作れるのだから
プログラマには仕様書を書くのが残された仕事になると
するとプログラマのプログラミングとは仕様書書きで
それは自動化できない前提だから不完全な世界なのです
じっさい要件定義は不完全な現実が入ってくるし
となるとプログラミングが「完全でないと不可能」というより
「可能だが不完全」という方が実態に合ってくるでしょう?
まあ正確には逃げ道がいくつもありますけどね
囲碁(のゲームAI)のように完全な世界だけを扱おうとか
仕様書の作成は「プログラミング」ではなく「設計」だとか
仕様書の作成は「プログラマ」ではなく「SE」の仕事だとか
仕様書を自動作成する「メタAIプログラミング」を仮定するとか >>828
>機械に近い部分から解決していくか
>人間に近い部分から解決していくか
>機械に近い部分から解決されていくだろう
逆に人間に近い部分から解決していくスタンスもあるでしょう
これは別になにか天の邪鬼でただ逆張りしてるのではなくて
論点を明確にするため、議論を多様化するためでもあります
>>770
「翻訳メモリ」を機械翻訳に応用するという例は
人間に参加させるというアプローチで
じつは人間も仮想的な計算資源みたいに解釈できると >>829
>株価予測プログラムならそんなのは無理ですよ
難しいとは思いますが無理とは断言できないでしょう
「ランダムウォーク仮説」が正しいかどうかは
経済学者でも意見が分かれるのだから
>統計学と確率論でルールを決めうちして
>そこから先は「完全情報ゲーム」の世界に移行
そこは決め打ちしかないとは決まってなくて
ファンダメンタルの情報を引っぱってこよう、
たとえば特許情報の解析は昔からあるけど
その応用で企業の決算書を解析しようとか
いろいろな手法がありえるでしょう
グーグルの機械検索エンジンだって
グーグルが実現するまでは
別に「理論的基盤」とかなかったでしょう?
グーグルがその基盤を作ったわけで
もっと言えばAIやインターネットだって
昔の人は「そんなのは無理」と言ったかもしれない
あまり断定すると技術的な可能性をなくしてしまうので
未来の技術は仮説的な思考で考えることにしています >>830
考えが一致するのが目的というより
考えの多様性と生産性が目的なので
別に一致しなくてもいいのです
もし昔の「ルールベースしかない」で
開発者が全員一致したままだったら
自然言語処理の次のステージに進んでなかったし
今の「ルールベースはオワコン」
「機械学習しかない」で全員一致したままでも
さらに次のステージに進んでいかないかもしれないから >>831
>完ぺきな株価予測プログラムは存在しない
完璧な絶望が存在しないようにね……w
>トレーダーの代わりに株の売買が出来る
>AIは存在するし既に稼働している
昔から「株ロボ」とかありましたからね
ただ一方で「ソーシャルトレード」みたいに
あえて人間を使おうという発想もやはりある
まあここでは自然言語処理が本題なんだけど
人間は自然言語を自然に理解できるので
人間に参加させるのは場合によって有力な手段です >>832
何を言ってるのか意味がわからん
大雑把な話を避けるために、話の領域(プログラムでいえばスコープ)を限定しようとしてるのに
プログラムを作るのがプログラマの仕事なので、ここがAIができるようになると人間は別の仕事に移行するのは当然ですが
そこに至るまでには多分長い時間がかかると思います
従って上流工程の部分をAIが本質的に解決するのはまだまだ難しい
でもプログラミングだけに限れば結構、条件が揃いつつあるんじゃないでしょうか?
今のIDEも高機能エディタも構文上、次に来るべきワードやシンタクスの候補を教えてくれます
また過去に開発した大量のプログラム資産はAIの学習教材として、かなり役立つはず
ライブラリの使用方法もプログラマが学習するよりもAIの方が得意なはず(本来はね)
問題は、何を解決したいか、必要なデータや資源(ライブラリや仕様書)をどのようにAIに指示・提供したらよいか
そういった部分がまだ手探りといったところ
それでも上流工程よりは条件整備ができつつあるんじゃないかと思ってます >>834
ランダムウォークは確率論ですよ
正確には確率過程、マルコフ過程の一つです
仮にランダムウォークという手法を使ってみると決めたら、そこから先の作業は「完全情報ゲーム」です
他の手法でも同じ
理論的基盤がないものを使って、解決ができないのは当たり前の話で
だから何が言いたいのかわかりません
大体、株価なんてのは天気の影響も受けるし、コロナの影響も受けるし、為替の影響も受けるし…
つまり理論的学術基盤が何もないので統計や確率でごまかしてるようなもん これはやる?
https://news.nicovideo.jp/watch/nw6818自然言語処理ライブラリ「Camphr」(カンファー)をオープンソースとして公開578 >>832
>>837
結局私が言いたいことは
自然言語処理そのものが不完全だということです
AIプログラミングが完全でも仕様書は作れない
仕様書は自然言語で書かれているから
じゃあ自然言語処理のAIも不完全になる
そしてこの構図で見ると前世紀のルールベースでの
自然言語処理がなぜ挫折したのかよく分かる
Prologは一階述語論理を言語的に実装したもの
述語論理は完全な体系(本当は実装が不完全だが措く)
だが自然言語は述語論理より複雑な体系だから
フレーム問題のようなことが起きてカバーできない
だから完全な基盤があって上手くいく保証がある
って発想自体が自然言語処理では通用しない
8クイーンみたいな箱庭というかトイプロブレムなら
完全に解析できてる問題もあるんだけど >>837
>今のIDEも高機能エディタも構文上
>次に来るべきワードやシンタクスの候補を教えてくれます
これは日本語漢字入力や検索エンジンと
同じで局所的な問題でしょう
エキスパートシステムという言い方をすれば
前世紀でも部分的にはできていた
将棋や囲碁もエキスパートシステム(弱いAI)
であって強いAIではないから
結局弱いAIをどう使うかという問題になる
>ライブラリの使用方法
ライブラリの依存関係をAIに解かせる
みたいな環境構築の自動化は進展の余地があるでしょう
>問題は、何を解決したいか
>必要なデータや資源(ライブラリや仕様書)
>そういった部分がまだ手探り
要するに自然言語処理はまだ不完全なのです
だからこそ新規アプリを開発する余地がある
枯れきったジャンルだと新規参入は難しいし >>838
やはりグーグルの例で
もしまだ人力ポータルが主流だった頃に
機械検索エンジンが作れると言ったら
「理論的基盤がないから、そんなのは無理ですよ」と言われても
当時はそれなりに説得力があったかもしれません
将棋のAIに機械学習が搭載されてから飛躍的に強くなったけど
昔は「機械学習では強くなれない」みたいな意見があったそうで
今から後出しジャンケンで言えば「何言ってんの」って思えるけど
だから不確実なものは不確実なので
できる訳ないとかできるに決まってるとか
先に決めつけても仕様がないのです
>株価なんてのは天気の影響も受けるし
気温が上がるとアイスクリームが売れるというのは
統計でよくある例だし常識的にも分かることだけど
株価と気温など天候の相関関係を統計的に解析する
というのも可能でしょう。儲かるかどうかは別だけど
固定観念の枠を外して可能性を考えることは
ソフトの開発において有効な考え方だと思います
それは自然言語処理がまだ未解決のジャンルだから >>840
自然言語処理ライブラリ「Camphr」(カンファー)をオープンソースとして公開
https://pkshatech.com/ja/news/2020-03-13/
リンクが崩れているので改めて張り直しました
このCamphrというのは説明を読むと
spaCyのプラグインで
spaCyとは Pythonで動かす自然言語処理ライブラリなので
今はPythonが主流だし開発環境の選択肢になるでしょう
>>839
それはそうですね
違法だけど >>842
あなたは自分自身の自然言語が適切か省みたほうがよい
問いかけや課題に対して正面から向き合わず、別の話ばかりしている
>>AIプログラミングが完全でも仕様書は作れない
=>そんな話は私はしていないし、否定もしていない
仕様書をどう作るかという話は私は一度もしていない
できないことを議論しても仕方がない
できること(できそうなこと、可能性ある事)は何かという話をしている
>>だから完全な基盤があって上手くいく保証がある
>>って発想自体が自然言語処理では通用しない
=>そんな話は私はしていないし、否定もしていない
あなたが株価予測を例に挙げたので、株価予測には理論的基盤がないと申し上げた
例が適切ではないという意味だ
私はあなたの意見を全部否定してるわけではない
全部肯定しているわけでもない
どの部分が共感できてどの部分が共感できないか、
互いの関心の範囲がずれていれば、重ねられる部分はどこか
擦り合わせをすることで、自分の考えを補正したり再発見したりできる可能性がある >>842
>結局私が言いたいことは
>自然言語処理そのものが不完全だということです
ならば「チンポがシコシコする」という日本語表現は、文法的に正しいのか?
チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。
オブジェクト指向で言う「集約」は2種類あって、全体(俺)と部分(チンポ)が繋がっている場合と、
全体(俺)と部分(チンポ)が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。
違うか?
「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、50字以内で述べろ! 3/15 日 19:30 BS232 自然言語処理の応用 放送大学 >>847
自律神経の働きによって胸は鼓動を打ちチンポは勃起するが、シコシコするのは人の意識のため主体は手となる
NLPの辞書としては、チンポが独立した生き物としての学習は可能だが世界の事実と異なるためデータ数が少なく採用されないだろう
そもそもとして、NLPの不完全性からの問題提起もオブジェクト指向の集約も夢精の例もほぼ意味がなく、生物学の知識だけで解けるという極めて低品質な謎かけ、読みやすさを意識した文体しか褒めるところがないな 世界の事実?
>>849
>チンポが独立した生き物としての学習は可能だが世界の事実と異なるため
化学の元素なるものは空想である、物理的エネルギーなどというのも空想である。
だいたい、客観的事実存在という観念なるものが大いなる空想である。
今日の実験や科学はけっして空想を排斥することはできないのである。 >>845
損みたいに自分の自社株持ってる人がコメントで株価操作出来る人は違法で逮捕されないのはなぜなんだぜ? 株価が大きく動いた後で重大なニュースが発表されるということがよくある
間違いなくインサイダーなんだろうが、逮捕されたという話を聞いたことがない >>213
>自然言語処理は、自然科学とまったく異なるただの 形 而 上 学 だからな
それらしい理屈をつけているだけで、ユークリッド幾何学なんてコンピューターの世界だけ。 俺が一番偉い。みんな跪け。
これでトップはすでに決まった。
以降のマウンティングは無意味である。 NICTからBERTのモデルが公開されたね
これはとても良いこと ロゼッタのBLEUが90あたりだそうで
0.2ポイント上がった(笑)とかでドヤ顔で論文出して喜んでいたのはなんだったんだろう、て思う >>530
>例えば、現実の世界に、円形をした物はたくさん存在するが、いずれも完全な円ではないし円そのものでもない。
例えばですけど、僕の知り合いが中学生のころ、数学で「√3は無理数なのに、1:2:√3の直角三角形は現実に存在する。
実物の三角形の√3の端はどうなっているんだ?」と疑問に思って親に聞いたところ答えられなかったことがあったそうです。
https://news.nicovideo.jp/watch/nw6859935?news_ref=top_topiclist 虚数は存在しない(これも嘘だが)とされているが
無理数は実在するからな >>849
>チンポは勃起するが、シコシコするのは人の意識のため
意識するのもチンポの働きなんだが?
<俺>
「 部屋の英子がこちらを向いた気配に、彼は勃○した陰○を外から障子に突きたてた。障子は乾いた音をたてて破れ、
それを見た英子は読んでいた本を力一杯障子にぶつけたのだ。本は見事、的に当って畳に落ちた。 」
<チンポ>
「 その瞬間、竜哉は体中が引き締まるような快感を感じた。彼は今、リングで感じるあのギラギラした、
抵抗される人間の喜びを味わったのだ。 」 >>650
>脳でなくチンポで物を考える生物についてなら
チンポは考える葦である! >>650
>脳でなくチンポで物を考える生物についてなら
【エロGIF】見てるだけでチンポがムズムズしてくる
http://ero-shame.com/blog-entry-103469.html Google翻訳ってコーパスどうしているんだろう?
WEBサイトから集めて自動アライン? そんな高度なことはせずに、wiki+αでコスト重視だと思う 942名無し三等兵2020/04/04(土) 08:20:34.27ID:VRY1NLOI
なんでカスミンを揶揄するとチンポ厨が牽制に出てくるんだろう
「正確な記述を心がけています」とかのたまったカスミンが「チンポがシコシコする」の語法的誤りには全く触れないのも変だし
カスミンが直接返答するとプライドに傷付くようなレスにばかりチンポ厨が牽制を入れるのも不自然だし
カスミンとチンポ厨は共依存で嫌われ者同士で援護しあう関係でしょうか
「カスミンはホモ」 204 名無し三等兵 sage 2020/04/06(月) 14:56:56.40 ID:K9vi7RPu
本が読書する
ニンジンが料理する
これが妙だと思わない脳の持ち主ってどうよ? と思っていたが、脳がチンポなら仕方ない
ただし人間扱いしてやる理由もない 2020-04-27
番外編 98年ブルマJC (エッチなポーズ連続のエロダンスを強制される哀れな娘達)
https://vuluma.hatenablog.com/entry/erodancejcshuchi
↑
チンポがシコシコする、とはこういう意味だ! 問題がないわけじゃないけど
指標としてはいいんじゃない? パラレルコーパスって
ラベル付きデータって言えるの? MeCabの処理のデモを提供するいくつかのウェブのページで、
「複合名詞」とか「サ変動詞」とか、デフォではないと思われる要素を散見するのですが、
これって自分でカスタムなロジックを入れて作ってる、で正解ですかね?
大雑把に、名詞が連続したら複合名詞にするとか、「名詞+する」をまとめるとか。
それともそういうのも処理できるバージョンがあったりします? >>880
そうですか。例えば「形態素解析」を処理すると一般的には|形態|素|解析|か
|形態素|解析|と処理されます(辞書によります)。よね?
これを|形態素解析|と一語に処理してほしい場合にどうしたらいいのかと。
ちなみに mecab-ipadic-NEologd を使ったら|形態素解析|と一語になりましたが
辞書のサイズが1.1GBですか。これがロジックで済むなら大きな辞書を使わずに
同様の処理が可能なのかなと。 ロジックですまないから辞書にしてんでしょ
こねくり回した sentcepiece より random を加えた bpe の方が良くて草 >>882
なるほどー。
他にも、何月何日とか、〇〇円とかの数詞系を1フレーズと認識させたいのですが、
確かにこれもNElogdの辞書だとうまくいくんですよね。
あとは辞書の大きさだけがネックかも。 そっか、二百億円と書く以外に2百億円と書く場合もありますね。
NEologdでも後者は駄目っぽいです。 あとサ変動詞(〇〇する)、も「〇〇」と「する」をまとめたかったり。
〇〇「を」する という言い方もたまにするので微妙。 489 名無し三等兵 sage 2020/07/07(火) 13:32:25.30 ID:VR0moFYQ
やっぱり珍カスの別人格じゃんチンボ脳www
ケツ蹴るぞとか言われたら発狂して(でもチビるほど怖いから)別のキチガイ人格でレスして勝った気になるマジキチガイ、
それが珍カス MeCabのC++ APIを使ってみようかと思うのですが。taggerでnodeを作って。
品詞はnode->featureの値のカンマ区切りを自分でパースしてゲットするので正解?
nodeに品詞の値の要素があってもいいのではと思ったり。
元のテキスト上のオフセットとノードの関係を知りたい場合、node->surfaceが元の
テキストのポインター? バイトオフセットを計算する必要があると。
UTF-16で使いた場合、MeCabってUTF-16でセットアップできるんですかね。それとも
UTF-8でセットアップして、プログラム上で毎回文字コード変換?
などという疑問が早速あるのですが、皆さんいかがしてますでしょう。
個人的にはJavaのBreakIteratorのような使い勝手が欲しいのですが... goやらrustがあるのに?
しかもコマンドラインでやればいいようなことしかしてないくせに? javaやpythonのポーティングもあったよね
きうてぃーもあるのに 皆さん一般的な使い方のリンクをありがとう。そのレベルは一応大丈夫なつもり。
MeCabのAPI、パース結果と元のテキスト上の位置との関連を見つけにくいような。
パース結果だけを(で)取り扱う、という立ち位置なのか。
JavaのBreakIteratorはイテレータだけでなく元のテキストのオフセットで結果を得る
メソッド等もあり、パース結果と元のテキストとの関連をより処理しやすい。
(>>888の最後に書いたのはそういう意味。言語自体のことではなく。)
うーんもしかして必要に応じて自分で少し作り足したりする必要があるのかな? ちなみにJava APIはNode.getSurface()がStringを返してくるのでC++ APIとは違い
元のテキスト上のオフセットはわからないのではないか、という。
(まさかStringに対してポインタ演算みたいなことはしないですよね?)
これも、オフセットが必要な使い方はするな、という立ち位置なのかもしれんけど。 Java APIではNode.getLength()が要素のバイト長を返してくるようで(例えばUTF-8とか)。
しかしJavaで文字処理してるときにUTF-8のバイト長を教えられても、って感じはする。
ま、Node.getSurface()がStringだからそのlength()でいいんだろうけど。
Javaだけで使うならMeCab本体のエンコーディングはUTF-16の方がうれしいような。可能?
一方MeCab本体をUTF-8でインストールしてもJava API自体は動いているわけだから文字
エンコーディングのマッチングとか、何かしてるのかな? 511 名無し三等兵 sage 2020/07/07(火) 21:24:00.41 ID:e+um6EKL
カスミンが「「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、50字以内で述べろ!」に霞ケ浦の回答をするのは何時なりや?
全世界は知らんと欲す そんなことしなくても
コマンドラインでできそう(笑) >>897
ん、上のMeCabの話へのレス?
プログラムの中で使いたいのでAPIについて考えているのだが。 AIがプロファイリングするとJava使えっていう結論が出た だからコマンドラインでできそうだなあってこと(笑) もうお前らどうでもいい。
MeCabの、自分にとって使いにくい部分はアダプタを書いてイテレータのクラスに
繋げた。今のところ若干無理矢理感があるがインターフェース自体はおk。
そういえば思い出した。
昔、Mac OS Xのライブラリを眺めていると何故かMeCabがあり、遊んでみたら何故か
辞書がUTF-16だった。
今になって全てわかった気がする。 テキストの処理で単語を処理単位にした方がいい場合がいろいろある。
ちなみにメヒビとかアオサとか割と好き。
しかしMeCab用の巨大辞書を某デバイスに突っ込むことは容認されるだろうか。
Text To Speechのファイルよりもでかかったらまずいか。
そういえばあれだってトークナイズとかしてるんだろうなあ。 読み上げ君とかは時々変な読み上げ方するが
MeCab使ってたらもうちょっとマシなんだろうか とりあえずMeCabの辞書って圧縮とかはかかってないっぽいかも。
squashfs上に置いたりしたら性能がどのくらい落ちるかな。 MecabはEUCやshift-jisが効率よいんですよ。 >>908
何の効率ですか? メモリ使用量? 処理速度?
今日び文字処理がUTF-16なAPIが少なくないので、連携して使うとするとMeCab側に
UTF-16のオプションがあると使いやすいのだが。
辞書は、UTF-8だと日本語が1文字3バイト使うのでやはりこちらもUTF-16だと
いいんじゃないかと。圧縮とかしてたら違ってくるけど。 というかJavaはでかいでしょw
Objective-CやSwiftのNSStringもUTF-16。
この時点で昨今のユーザー用デバイスの上は基本的にUTF-16ということであるw
C++にはchar16_tというUTF-16用のネイティブな型がある。 仕組みを知らないレベルなら、上からモノを言わないほうが良いのだろうけど。 わざと煽るとレスが増える
わざと間違えるとレスが増える
味を覚えたら繰り返す 人をおちょくることにだけ長けた古参が集う、そんなスレ。
自分からは生産的なことは何一つできない。
ザ・老害。 レス数が900を超えています。1000を超えると表示できなくなるよ。