もの自体はなかなかだと思う. が,
このライセンスだと, 協力する気にはなれない...
仮に漏れがコード追加・修正しても, 俺に利益がないだけならまだしも,
総括者だけが得することができるのは納得いかない.
総括者が修正する場合であってもソース公開しろと!
or 非公開で販売するなら漏れにも少しは還元しry
また, 1割以上と決めるのは良くない(高い?)気がします.
そのソフト自体がメインになるようなものなら良いですが,
ライブラリのようなものだと, 普通 1% 以下な気がします.
0円販売ってことにしたらどうなるんだろう
167 :
164:2009/01/08(木) 08:02:20
>>165 Thanks!
まぁ人はともかく, ソフト自体はなかなかなものだと思い,
ちょっと見てみたけど・・・
メモ程度のコメントはあったが,
Javadoc コメントが全くなかった ヽ(`Д′)ノ<Javadocツクレネーヨ!
もしかして, 公開しても簡単に触らせないよう
コメント削除してますか?
後, もう少し Java の流儀に従って頂けると助かるんですが・・・
(package 使う, [ある程度]Sun Java コーディング規約に従う etc.)
あと・・・ ant, Eclipse は使わないんですか?
168 :
164:2009/01/08(木) 08:11:14
↑日本語変ですみませぬ。。。
>>167 実は、最初にJava版を作り始めた時、キーボードが故障していまして、
色々なキーが入力できない状態になっていたのです。それでコメントを
書くのが難しくなって全体的に書いていなかったのでした。
普段は日本語でコメントを書く主義だったんですが、理由は忘れましたが
英語コメントになっていたりします。忘れてしまい下が、当時IME(FEP)に
必要なキーが押せなくなっていたのかも知れません。
javadocは余り知らないのです。eclipseは使っていません。packageも
余り理解していません。Sun Javaコーディング既約はどこにあるのかも
分かりません。
>>164 に書かれていることですが、
「総括者が修正する場合であってもソース公開しろと!
or 非公開で販売するなら漏れにも少しは還元しry 」
これについては、後段のアイデアは面白いです。ただし、ライセンス化
するには色々なアイデアが必要となりますので、検討に時間がかかります。
例えば、還元する割合をどう決めるかです。
>>164 >仮に漏れがコード追加・修正しても, 俺に利益がないだけならまだしも,
>総括者だけが得することができるのは納得いかない.
これについては、あなたが修正した場合、あなたが勝手に売る権利は
存在しています。それで利益を上げることが可能です。
>>170 その場合、あなたが修正したバージョンのソースはあなたに公開する義務は
ありません。自由にソースを追加/修正し、秘技や企業秘密をふんだんに入れ
て貰って構いません。普通、GPLなどでは修正後のソースは絶対公開する
必要がありますが、それでは改良版を売ることが難しくなり動機ややる気
を損なうおそれがあります。BRPLではその点を考慮して、改良した人が
将来利益を得る権利を与えているのです。
>>160 いえ、ソースを非公開にするのは誰でも無料で行えます。
この場合、
「
>>166 にもあるように0円で売る」
ということに該当します。
もし、非公開にして、さらに、販売する場合には総括者に一割還元して
下さい、という物です。
>>156 例えば、あなたが思う、JavaAppletよりも適当な言語は何でしょうか?
>>157 いくつかの安価なレンタルサーバー上でも、JRE(Java実行環境)が動作する
ことを確認しています。具体的には「XreaのCoreServer」と
「さくらInternet」です。今はクライアント専用ですが、将来、
サーバー上でShikikeiプログラムを動かせば、数式部分を単なる画像と
してHTMLブラウザで表示できるようになりそうです。こうすれば、
クライアント側にJREがインストールされていない場合でも数式が表示
できます。
>>164 >また, 1割以上と決めるのは良くない(高い?)気がします.
>そのソフト自体がメインになるようなものなら良いですが,
>ライブラリのようなものだと, 普通 1% 以下な気がします.
この辺については、どういう基準で決めて良いか難しいからです。
判断基準を考えるのが難しいので今のところそうしてあります。
例えば、一割と言わずに「1ライセンス」販売するごとに総括者に
300円還元する、という案も上がっています。そうすると、10個以上の
別のBRPLライセンスのプログラムを合体させた時に、末端作者に全く
利益が回らなくなると言う問題も回避できます。
>>175 理由は、価格の下限を規定する規則(?)を発見することが出来ないので。
あと、高いと「売れない」から価格を下げていった結果、0円になりました
ケースもあり得るため。
179 :
175:2009/01/08(木) 13:48:39
なにに驚いてるか誤解されてるようですね
0円販売というのがありだと、
BRPL規則のいくつかが無意味化すると思いませんか?
改造して無料配布配布してソース非公開が可能なんですから
もうちょっとすっきり書いたらどうなの?って話です
>>179 そこに気づかれてしまったあなたは、ちゃんと理解している証です。
偉い!
今北なんだけど、なんで数式の表現に独自形式をつかうの?
TeXかMathMLが使えれば、他の数式処理ソフトからの(orへの)コピペが使えて便利なのに。
>>143とかが手軽に見えるのだが。
TeX/MathMLと画像で数式データを保持しておけば、画像データがあるのでオフラインでも読める。
MathML対応ブラウザなら、表示もきれいにできるはず。
数式の入力支援はJavascriptでやればいいことだし。
掲示板以外にもブログのコメント欄とかWikiとかに組み込み易い形になってれば
もっと利用者も増えるでしょ
開発に参加したいと思う以前に、使ってみたいと思えない
これが盛り上がらない理由じゃないですか
>>182 >なんで数式の表現に独自形式をつかうの?
まず、TeX に関しては理想的とは言えないと持ったからです。
まだまだ改善の余地があると思ったのでShikikei形式を提案しました。
>TeX/MathMLと画像で数式データを保持しておけば、画像データがあるのでオフラインでも読める。
>MathML対応ブラウザなら、表示もきれいにできるはず。
まず、MathML自体、ブラウザ依存が激しい。また、必ずしも最初からイン
ストールされているわけではない。また、表示もそれほど綺麗とは限らな
い。
「画像での保存(?)」と書かれていますが、「数式画像の生成」と読み替え
たとして話しますと、これに関してはJavaをサーバーサイドで動かすことが
可能なので、将来的には
>>143の「mimeTeX (miniTeXではありません)」
と同様のことがJavaで書いていても可能です。
つまり、数式を見るだけには、クライアント側ではJREをインストールする
必要がありません。サーバーサイドで数式画像を作るためです。
>数式の入力支援はJavascriptでやればいいことだし
これに関しては、JavaScriptで書く場合、HTMLタグとの連携になるため、
どうしても速度の問題があります。それから、微妙な位置をマウスで
指定するのが難しくなると思われます。プログラミングも複雑になること
が予想されます。また、ソースをクローズドにしたい場合でも、必然的に
ソースが公開されてしまうという問題も大きいです。
>掲示板以外にもブログのコメント欄とかWikiとかに組み込み易い形になってれば
>もっと利用者も増えるでしょ
これに関しては、サーバーサイドでJavaが動かせるので、Javaで
書いていても、将来的には十分可能です。
>開発に参加したいと思う以前に、使ってみたいと思えない
>これが盛り上がらない理由じゃないですか
これに関してはまあ、そうかも知れません。そもそも数式自体、
興味が沸かない人も多い可能性があります。しかし、実際は
需要はあると考えています。
誤字訂正:
>>183 >言えないと持ったからです。
--->
言えないと思ったからです。
入力に他記法も受け付け、内部では自形式に変換して格納することにすれば、
>>182の「他の数式処理ソフトからの(orへの)コピペが使えて便利なのに」と、
Shikikei形式の利用が両立すると思う。
オープンソースなので、やりたい人は自分で行ってください。
↑
すみませんが、例のお決まり文句です。
>>188 それから、本気でやって欲しいことや意見があるのであれば、まずは、
PukiWiki に名前(ニックネームなど)を書くなど、何かの「足跡」
を残しておいてください。
話はそれからにしましょう。
192 :
188:2009/01/12(月) 23:53:30
>>192 そうですか。
提案はいつでも歓迎しますので、これからもお待ちしております。
194 :
デフォルトの名無しさん:2009/02/03(火) 22:06:56
age
やめろよ・・・・・・・・・・・
何を?
開発
maxima使うならちょっと興味あったんだけどなあ
>>198 検討はしていたんですが、Maximaが使っている言語はLISPですね。
使うとすれば、LISPをJavaAppletやJavaApplicationから使うにはどう
したらいいかを検討する必要があります。
同様のLISP処理系が他にもあるかも知れませんが、まずは、そういった
処理系のどれかでMaximaが単独で正常に動作することを確認することか
ら始めるのが早道ですね。
どなたかにやっていただけると助かりますが。
>>202 どのぐらい真面目にやるきあるprojectなの
axiomって数式処理ソフトだと
lisp使いとpyhon使いが混合してコード書いてたけど
そんな感じの構成にするつもりはないの?
>>203 >lisp使いとpyhon使いが混合してコード書いてたけど
>そんな感じの構成にするつもりはないの?
特に決まってはいません。
1. 数式処理ソフトがLISPで組みやすい
2. 既存の数式処理ソフトがLISPで書かれている
このような事情がある時は、LISPとのハイブリッドにしても良いかと
思います。もちろん、Pythonでも同じ事ですが。
>どのぐらい真面目にやるきあるprojectなの
NWSOSやNWSCの方もやるつもりでいますので、大変ではありますが、
NWSCのフロントエンドにする事、及び、NWSOSにShikikeiを移植する
こと(JREがNWSOSで動けばそれでOk)、も計画に入っているので、
結構まじめにやりたいと思っています。
なお、常時、協力者募集中です。
なお、必要とされる式の計算の種類はそれほど多くないと思うので、
自前で組んで組めない物でもないと思います。
分数の約分は分子・分母の最大公約数を求めればよいのでユークリッドの
互除法が使えそうです。ただし、変数が2個以上の場合はよく考えていま
せん。それからよく使う物として因数分解がありますが、これについては
既に分かっているアルゴリズムの内、ネットからでも手に入るものが
あります。積分についてはサイエンス社の黄色い本によく知られている
パターンについてはかかれているのでそれが参考になると思いますが、
積分についてはそれほど必要がないような気がするので後回しでも
構わないかと思います。
詳しい方にとっては幼稚なレベルですみません。
207 :
デフォルトの名無しさん:2009/03/17(火) 00:18:14
>>207 Z
z
z
<⌒/ヽ-、___
/<_/____/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄
そうか
209 :
デフォルトの名無しさん:2009/05/16(土) 23:43:58
>>207 幽体離脱
∧∧ ∩
(`・ω・)/
⊂ ノ
(つノ
(ノ
<⌒/ヽ-、___
/<_/____/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄
上げてくださったんですね。(^_^)/
有り難うございます。
211 :
デフォルトの名無しさん:
>>209 ?…ドウイタシマシテ
∧∧
(´・ω)
_|⊃/(___
/ ヽ_(____/
 ̄ ̄ ̄ ̄ ̄ ̄ ̄