プログラミング言語 Scala 2冊目

1 ：デフォルトの名無しさん：2009/06/30(火) 00:36:11

The Scala Programming Language
ttp://www.scala-lang.org/

リンク集
ttp://sites.google.com/site/scalatohoku/%E5%8B%89%E5%BC%B7%E4%BC%9A%E8%B3%87%E6%96%99

前スレ
プログラミング言語 Scala
ttp://pc12.2ch.net/test/read.cgi/tech/1205156417/

640 ：デフォルトの名無しさん：2009/11/15(日) 23:53:48

内包表記はあるんだけど。。

641 ：デフォルトの名無しさん：2009/11/16(月) 00:40:13

一連の流れを見て思ったのは、C#はえーって事。
C#もautoboxingしてるはずなのに？

642 ：デフォルトの名無しさん：2009/11/16(月) 00:51:08

>>636
boxing/unboxingに関してはJavaも条件同じだよ(コンテナにIntなどを挿入する場合)。そして、Scalaでも
必要無ければ勝手にboxing/unboxingされたりはしない。つか、よくわからん独自の型って何よ？
AnyVal配下のInt,Long,Float,Double,...は全部バイトコードレベルではJVMのintやlong型にマップされる
から効率は変わらんぞ。それ以外の型はほぼ、単にScalaで実装されたライブラリに過ぎんし。

643 ：デフォルトの名無しさん：2009/11/16(月) 00:52:08

>>641
C#のGenericsは型情報残ってるから、コンテナにプリミティブ型入れるときのautoboxingは要らんはず
たぶん、その辺が効いてるんじゃないかなあ。

644 ：デフォルトの名無しさん：2009/11/16(月) 00:56:25

JavaではおとなしくTIntArrayList使えってことだな。

645 ：デフォルトの名無しさん：2009/11/16(月) 01:50:25

>>629
ちゃんとデバックしてみてよ、動作おかしいから
>>635を書いたのも同じ人だと思うけど、アルゴリズムを勘違いしてるよ
最初のsqrt(i)個の素数じゃなくて、sqrt(i)以下の素数を調べればいいってことだよ
「エラトステネスのふるい」で検索してみてよ
って俺も今調べたところだけどｗ

それで、これって案外、関数型的に書くの難しいね
単純にfilterとかindexWhereを使うのは効率化の意味がない
じゃあどう書けばScala的で「ある程度」効率がいいのかを考えたけど、

import scala.collection.mutable.ListBuffer

object Primes {
　def main(args: Array[String]) {
　　val primes = new ListBuffer[Int]
　　for {
　　　i <- 2 to args(0).toInt
　　　if !primes.take(primes.indexWhere(_ > Math.sqrt(i))).exists(i % _ == 0)
　　} primes += i
　}
}

こんな感じじゃねーかな
これでもめちゃくちゃ遅いけどね
まあ、Scalaは簡潔にも書けるし、いざとなったら
Javaみたいに書いて高速化できるっつーことで

646 ：デフォルトの名無しさん：2009/11/16(月) 04:33:43

>>645
その人ではないが>>566も>>587も>>589も全部if (sqrt < i) になってるのを見て
変だと思わなかったのか？

untilじゃなくてto使ってるから勘違いしたのか？

647 ：デフォルトの名無しさん：2009/11/16(月) 04:44:42

if !(primes.takeWhile(_ <= (Math sqrt i)).exists(i % _ == 0))
の方がいいな

648 ：デフォルトの名無しさん：2009/11/16(月) 07:13:17

このソースコードでpsycoより早くなる人いる？
俺の環境が悪いのか･･･

def main(args : Array[String]) {
　println("start")
　var primes:ArrayBuffer[Int] = new ArrayBuffer[Int]()
　for (i <- 2 until 1000 * 10000){
　　if (isPrime(primes, i))
　　　primes += i
　}
　println("done")
}

def isPrime(x:ArrayBuffer[Int], y:Int) : Boolean = {
　for (i <- x) {
　　if (i > (Math sqrt y))
　　　return true
　　if (y % i == 0)
　　　return false
　}
　return true
}

649 ：デフォルトの名無しさん：2009/11/16(月) 09:03:34

>>647
ああ、takeWhile失念してたわ
それが答えだね

>>648
俺の環境だとそれとpsycoのやつでほとんど同じくらい

650 ：デフォルトの名無しさん：2009/11/16(月) 16:34:40

Lift連載第二回

Scala＋LiftフレームワークのView/Template
http://codezine.jp/article/detail/4512

651 ：デフォルトの名無しさん：2009/11/16(月) 21:07:19

Python(Psyco)早すぎてワロタ
元サイトの時間はCとC++が一緒なのだが、
最初にのみmallocしてるCとC++が一緒って変じゃないか？
コンパイル時に賢くなんかやってくれてるのかな

scalaは速度が必要な場合はJavaに近い速度の書き方ができるわけだが
上の流れを見てるとJavaというかプログラムのことをよくわかってない
人も結構いるから、誰でも同じようにかけるJavaみたいなのも必要だな

652 ：574 611：2009/11/16(月) 22:11:24

>>626 >>645
ご指摘ありがとうございました。

653 ：デフォルトの名無しさん：2009/11/16(月) 23:22:38

>>645
試しにStreamを使ってみたら、けっこう速くなった(Java風には敵わんが)
if !Stream.fromIterator(primes.elements).takeWhile(_ <= (Math sqrt i)).exists(i % _ == 0)

654 ：デフォルトの名無しさん：2009/11/16(月) 23:37:49

Streamってのはなんだ？
takeWhileでも新しいListを生成しないやつなんだろうなとは思うが

655 ：デフォルトの名無しさん：2009/11/16(月) 23:47:31

まず口の利き方を勉強したまえ

656 ：デフォルトの名無しさん：2009/11/17(火) 05:21:54

Streamはメソッドチェインしても逐次的に処理してくれるのか。

657 ：653：2009/11/17(火) 07:19:13

わざわざStreamを使わなくても、Iteratorを使えば同じことが出来た。
if primes.elements.takeWhile(_ <= (Math sqrt i)).forall(i % _ != 0)

658 ：デフォルトの名無しさん：2009/11/17(火) 08:44:45

なぜexistsをforallに変える必要があるんだ

659 ：デフォルトの名無しさん：2009/11/17(火) 20:41:10

>>651
いや、俺は逆だと思うよ
元のプログラムがわかりづらいんだよ

今回のアルゴリズムは、ある数nが素数かを調べるには
sqrt(n)以下の素数で割り切れるかを調べればよい、という話だが
>>647はそれをすっきりと表現している
最初からこれを見たら間違うやつは少ないと思う
でも、元のプログラムだと、そういうアルゴリズムだって
なかなかわからないんだよ、注意深く読まないと

最初から低級な書き方で書いていくと
どんどん読むのに労力がいるプログラムになってしまう
だから最初は関数型的に簡潔に書くべきで、
問題が起きてから書き下せばいいってのが、今回の教訓だと思うね

660 ：デフォルトの名無しさん：2009/11/17(火) 21:23:03

>>657
ライブラリのソース見たけど、IteratorのtakeWhileって何もしてないな
hasNextに判定を差し込むだけだから、確かにこれは速い
ライブラリ実装依存の最適化はあまりよくないと思うけど、しょうがないか
それでもpsycoとか>>648の倍の時間がかかるけど
まあ、一行で書いてそれなら十分か

661 ：653：2009/11/17(火) 22:52:49

>>658
'!'の処理が必要なくなる分だけ速くなるかと思って試しに修正して戻し忘れてた。

>>660
takeWhileの実装というよりは、Iterator自体の性質の方が性能に影響していると思う。
Iteratorであれば、必要に応じて要素を計算するので、2や3で割り切れる場合に無駄が少なくて済む。

あと、Iteratorみたいな遅延リストって、関数型言語ならたいてい持っていると思うので、
Scalaのライブラリ依存の高速化テクニックという訳でもないと思う。

662 ：デフォルトの名無しさん：2009/11/17(火) 22:56:31

>>661
なるほどなるほど
Iteratorのメソッドならチェインしてもたいてい速いと
勉強になった

663 ：デフォルトの名無しさん：2009/11/18(水) 13:56:17

イテレータが遅いんじゃ話にならんがな

664 ：デフォルトの名無しさん：2009/11/19(木) 22:02:45

まだ4倍遅いな

665 ：デフォルトの名無しさん：2009/11/21(土) 07:09:09

標準の Iterator#takeWhile が遅いようだ。
takeWhile を自作すれば速くなるが、やりすぎか?

def myTakeWhile[A](it: Iterator[A], p: A => Boolean) = new Iterator[A] {
　private var cached = false
　private var nextCache: A = _
　private var hasNextCache = false
　def hasNext = {
　　if (!cached) {
　　　cached = true
　　　if (it.hasNext) { nextCache = it.next; hasNextCache = p(nextCache) }
　　　else hasNextCache = false
　　}
　　hasNextCache
　}
　def next =
　　if (hasNext) { cached = false; nextCache }
　　else throw new NoSuchElementException("next on empty iterator")
}
def main(args: Array[String]) {
　val primes = new ArrayBuffer[Int]
　for {
　　i <- 2 until args(0).toInt
　　if !myTakeWhile[Int](primes.elements, (_ <= (Math sqrt i))).exists(i % _ == 0)
　} primes += i
}

666 ：デフォルトの名無しさん：2009/11/21(土) 08:56:40

いやいや、自作のそういうメソッドを既存のクラスに付加できるのも
Scalaの立派な魅力

667 ：デフォルトの名無しさん：2009/11/21(土) 09:47:26

あぁそうか、暗黙の型変換を使えば良かったのか

668 ：デフォルトの名無しさん：2009/11/21(土) 09:59:17

lift ってどうなの？ごちゃごちゃしてる感があるんだけど。

669 ：デフォルトの名無しさん：2009/11/21(土) 12:13:37

maven必須なのがなんとも

670 ：デフォルトの名無しさん：2009/11/21(土) 16:42:53

hasNextをchache化するとなんでtakeWhileが速くなるんですか？

671 ：デフォルトの名無しさん：2009/11/21(土) 18:19:22

引数の型がObjectの関数に数値や文字列などを渡したいんだけどどうしたらいいの？

672 ：デフォルトの名無しさん：2009/11/21(土) 18:39:07

もしかして、このスレって 2.8.0 が前提なの?
2.8.0 のソースを見ているとしか思えないレスが散見されるんだが(>>660,670)

673 ：デフォルトの名無しさん：2009/11/21(土) 18:49:31

>>671
文字列はAnyRefのサブタイプなのでそのまま渡せる
Intとかもimplicit conversionが定義されているので、本来ならそのまま渡せる…はずなんだけど
他のimplicit conversionと衝突しているせいで、エラーになる。解決するには
foo(num:java.lang.Integer)
みたいにして、java.langにあるラッパークラスに変換してあげると良い
(fooはAnyRefを引数に取る関数)。

674 ：デフォルトの名無しさん：2009/11/21(土) 18:56:57

このスレは3.0前提だよな？

675 ：デフォルトの名無しさん：2009/11/21(土) 18:58:56

>>674
3.0って一体いつになるんだよw

676 ：デフォルトの名無しさん：2009/11/21(土) 19:23:31

ああ、2.7と2.8じゃ、ソースコードが全然違うね
2.7は同じプログラムでも倍くらい遅いわ
elementsメソッドがobsoleteになってるからまぎらわしかったね
ちゃんとiteratorと書かなきゃ駄目だったね、いまさらだけどｗ

677 ：デフォルトの名無しさん：2009/11/21(土) 19:49:03

>>665 は、2.7.7 を前提として書きました。
2.8.0 のソースを見る限り、わざわざ takeWhile を自作する必要はないようなので、
2.8.0 の方は >>665 を無視してください。

678 ：デフォルトの名無しさん：2009/11/21(土) 19:54:26

基本的にはVerとか示すのが一番なんだろうけど
まぁ大体分かるしいいんじゃないの
宿題スレだと必須だけど

679 ：デフォルトの名無しさん：2009/11/22(日) 11:29:41

NetBeansのscalaプラグインってimportの保管してくれないの？

680 ：デフォルトの名無しさん：2009/11/22(日) 18:12:59

う〜ん・・遅い・・・う〜ん・・・

681 ：デフォルトの名無しさん：2009/11/22(日) 20:14:06

なんで関数型言語って並列処理に適してるんだ？いまいち理由がわからん。
あとerlangにしろscalaにしろアクターとかを言語レベルでサポートしてるのはなぜ？別に関数型言語にアクターは必ず必要ってわけではないよね？

682 ：デフォルトの名無しさん：2009/11/22(日) 20:19:19

アクターやCPSなどの並列モデルに関しては、
スレッドなどと一緒で、有望や成熟した物が、
徐々に主流なものにサポートされていくだけだとおもう。

元々の言語に向き不向きはあるかもしれないが。

683 ：デフォルトの名無しさん：2009/11/22(日) 20:20:35

関数型言語が並列に向いてると言われてるのは、
参照透明性があれば処理を別々にしやすいからじゃね

684 ：デフォルトの名無しさん：2009/11/22(日) 20:38:57

いままでの分散処理では、チューニングすれば速度の出るMPIとかは特別な用途向けで、
一般的なプログラム向けとしては、それを仮想的な共有メモリモデルに
当てはめて処理能力を上げるかを研究してきたというのがあった。
↓
それに対して、WebスケールのプログラムやPCでの同時処理数が一般的になるなかで、
共有メモリ上での処理は、CAP定理というので、結局スケールしないことも分かってた。
↓
DBにしろ言語にしろ共有しないで動作する機構を単位とするものが必要になってきて
それには、不変型で処理する関数型とかメッセージパッシングとかが必要だ。
↓
特殊な言語じゃなくて、Cのような主流の書き方が出来る言語で出来るようにしよう。
↓
Scala出来たよ。←今ここ
↓
C/C++とかJava/C#でもサポートされる。

685 ：デフォルトの名無しさん：2009/11/23(月) 01:04:16

>>681
関数⇒副作用無し(入力が一意なら出力も一意)⇒関数の依存関係だけで並列実行可能性が決まる⇒並行処理でウマー
というのが基本的な考え方。とは言え、実在の処理系でソレが実現できているかは別問題だったり。

あと、ScalaのActorはライブラリでの実装で、言語レベルでは何もしてないぞ。
Erlangの方は、そもそもアクターがないとまともなプログラムが書けない言語仕様。

686 ：デフォルトの名無しさん：2009/11/23(月) 01:15:28

Scalaは、なぜ関数の副作用の有無を判別出来るようにしなかったんだろう？
var/valみたいに。

687 ：デフォルトの名無しさん：2009/11/23(月) 06:15:41

実際には副作用があるけど外から見ると無いように見える関数とか作れるからじゃね
というかどっちにしろコンパイラが賢くないと意味なさげ

688 ：デフォルトの名無しさん：2009/11/23(月) 08:57:55

それを明示できるようになったとしたら、
Cのconst引数と同じで、コールスタックの深いところで副作用のある関数を
使わななきゃいけなくなったときにえらい目に合う気が

689 ：デフォルトの名無しさん：2009/11/23(月) 23:16:43

>>688みたいなこと、たまにやるわ。
自分の設計が悪いんだろうけどがっくりする。
一方でmutableなのかわかったほうがいいとも思う。
IDEのリファクタリングなどの機能でなんとかならんかね