[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dennou-ruby:003117] Re: 質問:gphys



堀之内様

丁寧に説明していただきありがとうございます。

>> まずはこの ml に投げて相談、ということでしょうか?
>
> はい,それでいいです.ちなみに GPhys のコアの部分については,
> 変更の判断は私がします.

了解しました。

> ご提案の一番の目的は,それをしなくても,自動で大体よいように
> タイトルが出るようになって欲しいということですね.

はい、その通りです。
まずは、嘘のタイトルは避けたい、ということです。
それで、可能なら概ね適切なタイトルになってほしい、と。
かといって、適切な仕様が僕の頭にあるわけではないで、
まず仕様の相談ですが、、、

> さて,問題は,その仕様ですね.単純に考えると,
>
>  uv.long_name = "(#{u.long_name})*(#{v.long_name})"
>
> とするのでしょうが,演算していくうちに際限なく長くなってい
> きます.グラフのタイトル(すくなくとも現状では)は中央揃え
> ですので,長くなると見苦しいですね.もちろん,嘘の
> タイトルがつくよりましという考えはあるのですが,
> どうせやるなら,長さ対策もしていただきたいと思います.

長さ対策の一つの案としては、新たにインスタンス変数を
用意して、(lost_axes 的に)変数に施された処理を別に
記録し続けるのが良いのかな、と思っています。
その場合、long_name には、なんらかの演算が施されたことが
分かるような文字列に変更するなどしておいて、そして、
ggraph などで呼ぶ場合には annotate として表示されるなら、
長くなっても問題ない、とか。

とはいえ、どれほどの数の演算を行うかという一般の需要が
(少なくとも私には)予想できないため、その未知の需要のために
いたずらに新たな変数を導入したり仕組みを複雑化させるのは
得策ではないように思います。

結局、実装のシンプルさからすると、長さには目をつむって

>  uv.long_name = "(#{u.long_name})*(#{v.long_name})"

的なやり方が、実直で十分良いと僕は思いますが
いかがでしょうか?
ある程度以上に長くなってしまったら、そこは諦めて、
必要に応じて手で書き換えてもらう、で仕方ないと思います。
ggraph (or DCL) の表示で困る場合は、そちら側で
文字を小さくするなどして対応する、というスタンスで。

次に実装ですが、、、

> 仕様が決まれば,どう実装するかですね.どうせやるなら,
> 全ての演算で然るべくやって欲しいですが,コードの変更は
> 論理的,規則的かつ最小限になるように,しかるべき場所で
> やらないとなりません.

はい。
その思想は理解しているつもりですが、実際にどうやるかは
gphys (およびrubyも比較的)初心者の私には難しいところです。

> ちなみに,名前を持つのは
> VArray ですから,varray.rb ですべきです.あと,

なるほど、了解しました。

> オペレータごとに全部ハードコーディングするのでなく,
> 共通的なことはくくりだして支援メソッドを作ったほうが
> よいかもしれません(実際検討してないのでよくわかり
> ませんが.)

これは、Math_funcs 2種, Binary_operators 3種の
計5種に「共通的なこと」、という意味でしょうか?
今の僕の理解度からすると、5種それぞれに直書きする以外
いい方法が思いつきませんが、少し考えてみます。

しばらくは初歩的な質問をさせて頂く事もあるかと思いますが、
どうぞよろしくお願いします。

谷川



2009/10/9 Takeshi Horinouchi <horinout@xxxxxxxxxxxxxxxxx>:
> 谷川さま
>
> ご提案ありがとうございます.
>
>> ただ、こういう個人的変更がたまってきた後に本家が
>> バージョンアップすると、毎回面倒かなとも思い、
>> もし本家に取り込んでも構わない変更なら
>> 取り込んでもらいたいと考えている次第です。
>
> こういう風に考えていただけると,大変ありがたいです.
>
>> そこで、相談なのですが、こういう変更を施したい場合、
>> まずはこの ml に投げて相談、ということでしょうか?
>
> はい,それでいいです.ちなみに GPhys のコアの部分については,
> 変更の判断は私がします.
>
>> ある gphys オブジェクトに数学演算を施した時に、
>> その演算記録をそのオブジェクトに保持してほしい、と思い、
>> numru/gphys/gphys.rb に若干の変更を施したいと
>> 考えています(v0.7.0 の gphys.rb の 750 行目付近)。
> ..
>> 今のところ、自分の必要性から、数学演算を施した時に、
>> それが分かるように name と long_name を直接書き換える
>> ようにしています。(例えば ggraph などで描かれる図のタイトルに
>> 反映されるように。)しかし、別途、インスタンス変数を用意して、
>> そこに記録し続ける方がいいような気もします。というのも、
>> 2項演算だったり演算が複数回に及んだりすると、場合によっては
>> 厄介な事もある気がするからです。
>
> 現状では,例えば uv = u*v などとすると,uv の単位は
> 正しく u の単位と v の単位をかけたものになるのですが,
> name と long_name は u のものが引き継がれるだけなので,
> 図をかくと "zonal wind" などと表示されてしまいますね.
> そこで,図に書いて変だったときに uv.long_name = "UV"
> などとあとからするのは,私もよくやります.
>
> ご提案の一番の目的は,それをしなくても,自動で大体よいように
> タイトルが出るようになって欲しいということですね.
> 確かにそうなるとよいと思います.
>
> さて,問題は,その仕様ですね.単純に考えると,
>
>  uv.long_name = "(#{u.long_name})*(#{v.long_name})"
>
> とするのでしょうが,演算していくうちに際限なく長くなってい
> きます.グラフのタイトル(すくなくとも現状では)は中央揃え
> ですので,長くなると見苦しいですね.もちろん,嘘の
> タイトルがつくよりましという考えはあるのですが,
> どうせやるなら,長さ対策もしていただきたいと思います.
>
> 仕様が決まれば,どう実装するかですね.どうせやるなら,
> 全ての演算で然るべくやって欲しいですが,コードの変更は
> 論理的,規則的かつ最小限になるように,しかるべき場所で
> やらないとなりません.ちなみに,名前を持つのは
> VArray ですから,varray.rb ですべきです.あと,
> オペレータごとに全部ハードコーディングするのでなく,
> 共通的なことはくくりだして支援メソッドを作ったほうが
> よいかもしれません(実際検討してないのでよくわかり
> ませんが.)
>
> ということで,今回の課題は,それなりに気をつけてやらないと
> ならないですから,仕様と実装について詳しく紹介していただいて,
> 私がOKと思えば取り込みたいと思います.面倒かとは
> 思いますが,ご理解ください.
>
>> まとめると、
>> ・一般に、変更・追加をしたいときのコミットの仕方
>> ・上記の具体的問題の実装方法
>> について、コメントいただけると助かります。
>
> コミットの仕方ですが,GPhys 開発陣と認定されている方に
> ついては,直接 cvs にコミットしていただいてます.ただし,
> それぞれなんとなく持ち場は決まってますので,それを超えて,
> 例えば今回のようにコアな部分に関わる変更でしたら,まず
> 私に相談というようなことに,実際上はなってます.
> それ以外の方はとにかくまず相談ということで,よろしく
> お願いします.
>
> 具体的な実装方法については,気をつけて頂きたいのは上のような
> ことです.つまり,一般性を重視しますので,なるべく広い範囲で
> 良い振る舞いをするようにしていただきたいです.でも,コアの部分
> ですので,実行速度にも配慮することを求めます.
>
>> 北大低温研/CPSの谷川と申します。
>> はじめまして。
>>
>> gphys について、いくつかお尋ねしたいことがあります。
>>
>> ある gphys オブジェクトに数学演算を施した時に、
>> その演算記録をそのオブジェクトに保持してほしい、と思い、
>> numru/gphys/gphys.rb に若干の変更を施したいと
>> 考えています(v0.7.0 の gphys.rb の 750 行目付近)。
>>
>> そこで、相談なのですが、こういう変更を施したい場合、
>> まずはこの ml に投げて相談、ということでしょうか?
>>
>> もしそれが YES として、この実装方法についても相談です。
>> 今のところ、自分の必要性から、数学演算を施した時に、
>> それが分かるように name と long_name を直接書き換える
>> ようにしています。(例えば ggraph などで描かれる図のタイトルに
>> 反映されるように。)しかし、別途、インスタンス変数を用意して、
>> そこに記録し続ける方がいいような気もします。というのも、
>> 2項演算だったり演算が複数回に及んだりすると、場合によっては
>> 厄介な事もある気がするからです。
>>
>> 今のところ、自分の用途としては数学演算さえ施された
>> 情報さえ保持されればよいので、上記のような変更をして
>> 個人的に使っています(数行書き換えるだけ、単位の変換もなし)。
>> ただ、こういう個人的変更がたまってきた後に本家が
>> バージョンアップすると、毎回面倒かなとも思い、
>> もし本家に取り込んでも構わない変更なら
>> 取り込んでもらいたいと考えている次第です。
>>
>> まとめると、
>> ・一般に、変更・追加をしたいときのコミットの仕方
>> ・上記の具体的問題の実装方法
>> について、コメントいただけると助かります。
>
>
> 堀之内 武
>
>
>
>



-- 
Takayuki Tanigawa
Center for Planetary Science / ILTS, Hokkaido University