静岡で村松園芸を営む両親のもとに生まれる。小学生の頃は絵が得意でコンクールで賞を受賞したことがある。園芸店は朝も早く、両親の苦労や大変さをよく知っていたため、元々花にやりがいを見いだせず、事業を継ぐ意向もなかった。高校から芸術系の勉強ができる東京の玉川大学の付属高校へ進学するため上京した。玉川大学では芸術学部で日本画を専攻していた。大学時代にアメリカへ留学をする。この考えは両親に反対され学費を出してもらえず、コツコツ貯金し、300万円ほど貯め、自費で留学を果たした。留学先で語学スクールに通いながら花屋でアルバイトをしていた。アメリカでは日常生活の中で頻繁に、花を贈り合う文化があり、その違いに衝撃を受けた。語学学校の知人で言葉が通じないアラブ人の男性とメキシコ人の女性がいた。男性が女性に花を贈ったことをきっかけに、二人は誰もがうらやむカップルとなった出来事をきっかけに、「花は、言葉を超える世界の共通言語だ」という想いを強くした。アメリカ、ヨーロッパで修行を積み、1974年シカゴ・アメリカンフローラルアートスクールを卒業。親の危篤という嘘で留学先から連れ戻され、家財道具もそのままに留学を終えることになった。世界の花文化に触れて、帰国してから、様々なコンテストに出る準備を始めた。生け花の三大流派である池坊、草月流、小原流も学び、日本文化も表現できるフラワーアーティストを目指した。台湾・韓国・タイなどアジア各国でフラワーデモンストレーションを開始。 1989年長野五輪表彰式用ビクトリーブーケのデザインを担当。
短波は電離層と地上に反射しながら伝播するので、他の波長帯と比較して、遠距離まで伝播する。また、近距離であれば直接波で到達する。しかし、中距離では、直接波では到達せず、かつ反射による到達も期待できない場所ができる。このことをスキップ現象、あるいは単にスキップという。1920年代ごろまでは、さほど遠距離まで到達させる必要がなく、ある程度広い範囲をカバーしたければ、短波よりも長波や中波を使うほうがよい、とされていた。しかし、電波には波長が短いほど直進性が良くなるという特性があり、1950年代に入って半導体が電波通信の場に登場し、周波数を上げることがさほど難しくなくなってくると、超短波や極超短波がその地位を占めるようになった。
2015年現在、GPGPU対応プログラムの開発環境・APIとして代表的なものはCUDA、OpenCL、およびDirectComputeであり、GPGPU黎明期の開発環境に比べればはるかに開発しやすくなっているものの、依然としてアクセラレーターとなるハードウェアを意識したGPGPU特有のプログラミング知識が不可欠である。また、規格によってある程度標準化・抽象化されているとはいえ、いずれもデバイスとの通信を行なうローレベルのAPIを使いこなさなければならないなど、通常の C/C++ や Fortran を用いたソフトウェア開発とは次元の異なる難しさがあり、導入のハードルが高い。特に OpenCL と DirectCompute はハードウェアに共通にアクセスできる API を規定しているだけであり、CUDAよりもさらにローレベルの抽象度である。この点に関しては、アクセラレーターの存在を抽象化し、従来のCPUベース並列プログラミング用の共通規格 OpenMP に近い高レベルプログラミング環境を提供する OpenACC や C++ AMP といった規格も徐々に整備されつつある。CPU上で動作するプログラムは組み込み環境を除き、ライブラリも含めて高レベルに洗練された開発環境が整っていることが多い。例えばC++、Java、C#言語などの代表的な高級言語では、単純な連続メモリの配列構造だけでなく、リンクリスト・二分探索木・ハッシュテーブルといった基本的なデータ構造はプログラミング言語標準ライブラリで提供されていることがほとんどだが、GPUプログラミングの場合は高速に処理できないという理由から基本的には配列構造しか用意されていない。フォトンマッピング手法の開発者であるWann Jensen博士によると、複雑なデータ構造をGPU上で扱おうとするとCPUよりもはるかに困難となる場合が多いと評されている。他にも、GPUプログラミング言語であるHLSL、GLSL、およびOpenCL CではC++テンプレートのようなジェネリックプログラミング機能がサポートされないため、生産性が低い。なおBLASやFFTに関しては、NVIDIAによるCUDA実装のcuBLASやcuFFT、およびAMDによるOpenCL実装のclMath (clBLAS, clFFT) が存在する。そのほか、二分探索、ソート、リダクション、スキャンといったよく使われるアルゴリズムに関しては、NVIDIAによるCUDA実装のC++テンプレートベース並列アルゴリズムライブラリThrustや、AMDによるOpenCL/C++ AMP実装の同等ライブラリBoltが存在するが、両者に互換性はない。また、GPUで演算した結果をCPUで読み出して利用する場合、従来アーキテクチャではGPUメモリからCPUメモリへのデータ転送が必要となる。その逆もまた然りである。こうしたCPU-GPU間のメモリ転送にかかる処理時間およびプログラミング上の手間が、性能のボトルネックやソフトウェア開発の難しさにつながるという問題も抱えている。これは物理的にメモリが分離されているディスクリートGPUとCPUによる構成だけでなく、従来型のオンボードグラフィックスやCPU内蔵GPUといった、物理メモリを共有する構成においても同様である。CUDAやOpenCLにはソフトウェア（ドライバー）レベルでこの転送の手間を解決する仕組みとして統合メモリ (unified memory) 機能や共有仮想メモリ (shared virtual memory) 機能が用意されてはいるが、あくまでメモリ空間のアドレッシングを仮想化して転送処理を自動化するだけの仕組みであり、アプリケーションプログラマーが明示的に転送処理を記述してチューニング・最適化する場合と比べてパフォーマンス上の問題もある。この点に関しては、AMDが推進しているHSA (Heterogeneous System Architecture) におけるhUMA (heterogeneous Uniform Memory Access) といった解決策が模索されている。GPGPUプログラムの移植性に関しては、CUDAはNVIDIAハードウェア専用であり、また DirectCompute (DirectX) はMicrosoftプラットフォーム（Microsoft Windows、Xbox Oneなど）専用という制約がある。一方でOpenCLは、GPUだけでなく対応するあらゆるハードウェア・あらゆるプラットフォームへ展開できる高い移植性を持っているが、性能に関するポータビリティは必ずしも確保・保証されず、場合によってはデバイスやチップごとにコードをチューニングする必要がある。