タグ付けされた質問 「scala」

この構造がScalaで型の不一致エラーを引き起こすのはなぜですか？ for (first <- Some(1); second <- List(1,2,3)) yield (first,second) <console>:6: error: type mismatch; found : List[(Int, Int)] required: Option[?] for (first <- Some(1); second <- List(1,2,3)) yield (first,second) 一部をリストに切り替えると、正常にコンパイルされます。 for (first <- List(1,2,3); second <- Some(1)) yield (first,second) res41: List[(Int, Int)] = List((1,1), (2,1), (3,1)) これも正常に機能します。 for (first <- …

81 scala  for-loop  type-mismatch  for-comprehension  scala-option 

SBTビルドを実行した結果として生成されるすべてのものを取り除く簡単な方法はありますか？いたるところにターゲットディレクトリが作成されることがわかりました。実行する sbt clean clean-cache clean-lib clean-plugins ...すべてを取り除くわけではありません。

81 scala  sbt 

クイックソートメソッドがSorting付いた並べ替えオブジェクトがあります。quickSort それを使用して、任意のタイプのオブジェクトの配列をソートするコード例は何でしょうか？Orderableトレイトの実装を渡す必要があるようですが、構文がわかりません。 また、私はこれを「スカラの方法」で行う答えを好みます。私はJavaライブラリを使用できることを知っています。

81 sorting  scala 

多くの文字列を一致させたい正規表現パターンがあると仮定します。 val Digit = """\d""".r 特定の文字列が正規表現と完全に一致するかどうかを確認したいだけです。Scalaでこれを行うための良い慣用的な方法は何ですか？ 正規表現でパターンマッチできることは知っていますが、抽出するグループがないため、この場合、構文的にはあまり満足のいくものではありません。 scala> "5" match { case Digit() => true case _ => false } res4: Boolean = true または、基になるJavaパターンにフォールバックすることもできます。 scala> Digit.pattern.matcher("5").matches res6: Boolean = true これもエレガントではありません。 より良い解決策はありますか？

80 regex  scala 

先物用のScalaのスレッドプールはどのくらいですか？ 私のScalaアプリケーションは何百万ものfuture {}sを作成しますが、スレッドプールを構成してそれらを最適化するために何かできることはないかと思います。 ありがとうございました。

80 multithreading  scala  parallel-processing  threadpool  future 

コレクションに対して要素ごとの操作を実行するためのScalaコードをいくつか記述しました。ここでは、同じタスクを実行する2つのメソッドを定義しました。1つの方法はを使用zipし、もう1つの方法はを使用しzippedます。 def ES (arr :Array[Double], arr1 :Array[Double]) :Array[Double] = arr.zip(arr1).map(x => x._1 + x._2) def ES1(arr :Array[Double], arr1 :Array[Double]) :Array[Double] = (arr,arr1).zipped.map((x,y) => x + y) 速度の点でこれら2つの方法を比較するために、次のコードを書きました。 def fun (arr : Array[Double] , arr1 : Array[Double] , f :(Array[Double],Array[Double]) => Array[Double] , itr : Int) ={ val t0 = System.nanoTime() …

38 scala  performance  scala-collections  jmh  elementwise-operations 

PythonとScalaを使用しているときのSparkのパフォーマンスを比較するために、両方の言語で同じジョブを作成し、ランタイムを比較しました。私は両方のジョブにほぼ同じ時間がかかると予想していましたが、Pythonのジョブだけがかかりましたが27min、Scalaのジョブはかかりました37min（ほぼ40％長くなります！）。私はJavaにも同じジョブを実装しましたが、それもかかり37minutesました。どうしてこれがPythonがそんなに速いのか 最小限の検証可能な例： Pythonジョブ： # Configuration conf = pyspark.SparkConf() conf.set("spark.hadoop.fs.s3a.aws.credentials.provider", "org.apache.hadoop.fs.s3a.AnonymousAWSCredentialsProvider") conf.set("spark.executor.instances", "4") conf.set("spark.executor.cores", "8") sc = pyspark.SparkContext(conf=conf) # 960 Files from a public dataset in 2 batches input_files = "s3a://commoncrawl/crawl-data/CC-MAIN-2019-35/segments/1566027312025.20/warc/CC-MAIN-20190817203056-20190817225056-00[0-5]*" input_files2 = "s3a://commoncrawl/crawl-data/CC-MAIN-2019-35/segments/1566027312128.3/warc/CC-MAIN-20190817102624-20190817124624-00[0-3]*" # Count occurances of a certain string logData = sc.textFile(input_files) logData2 = sc.textFile(input_files2) a = logData.filter(lambda value: …

16 python  scala  apache-spark  pyspark 

多くのタイプの光学系には、ファンラーホーフェンの表現があります。 たとえばLens、タイプのa は次のLens s t a b ように表すことができます。 Functor f => (a -> f b) -> s -> f t 同様にTraversal、は同様の方法で表すことができ、Functor制約をApplicative次のように入れ替えます。 Applicative f => (a -> f b) -> s -> f t MonocleやArrowなどのいくつかの光学フレームワークは、というタイプを定義しますOptional。 Monocleの光学では、階層 OptionalはLensとの間に適合しますTraversal 私が理解しているように：a Traversalが0から多くのターゲットをLens持つ可能性がある aのような場合、は0から1のターゲットを持つ可能性があるOptional aのようなものです。Lens Monocleでは、Optional関数のペアとして定義されます。 getOrModify :: s -> Either t a set :: …

15 scala  haskell  functional-programming  lenses  monocle-scala 

以下はfs2のドキュメントからのコードの一部です。関数goは再帰的です。問題は、それがスタックセーフであるかどうかをどのように知るか、および関数がスタックセーフかどうかをどのように推論するかです。 import fs2._ // import fs2._ def tk[F[_],O](n: Long): Pipe[F,O,O] = { def go(s: Stream[F,O], n: Long): Pull[F,O,Unit] = { s.pull.uncons.flatMap { case Some((hd,tl)) => hd.size match { case m if m <= n => Pull.output(hd) >> go(tl, n - m) case m => Pull.output(hd.take(n.toInt)) >> Pull.done } case None …

13 scala  functional-programming  tail-recursion  scala-cats  fs2 

私はScala Edition1のプログラミングにおける特性の章のコード例を通して作業していました https://www.artima.com/pins1ed/traits.html そして私のタイプミスのために奇妙な行動に出くわしました。以下の特性のオーバーライドメソッドでは、コードスニペットではコンパイルエラーは発生しませんが、オーバーライドされたメソッドの戻り値の型はUnitvs とは異なりStringます。しかし、オブジェクトのメソッドを呼び出すと、Unitが返されますが、何も出力されません。 trait Philosophical { def philosophize = println("I consume memory, therefore I am!") } class Frog extends Philosophical { override def toString = "green" override def philosophize = "It aint easy to be " + toString + "!" } val frog = new Frog //frog: Frog …

11 scala  overriding  traits 

私は本のプログラミングをscalaで読んでいて、こう言われています： ...この場合、その副作用は標準出力ストリームへの出力です。 そして、私は副作用がどこにあるのかわかりません、なぜなら同じ入力に対して、printlnは同じ出力を出力するからです（私は思う） UPDATE を呼び出すときはいつでも： println(5) それが印刷されます5私が呼び出す場合表示されていない、println(5)5以外の値を出力しますが！

10 scala  functional-programming  pure-function 

val i: java.lang.Integer = null val o: Option[Int] = Option(i) // This yields Some(0) null: java.lang.IntegerScala に変換する安全な方法は何Option[Int]ですか？

9 scala  optional 

型パラメーターが、囲んでいるクラスではなく、囲んでいるメソッドからのものである場合、パターンマッチングの動作が異なるのはなぜですか？例えば、 trait Base[T] case class Derived(v: Int) extends Base[Int] class Test[A] { def method(arg: Base[A]) = { arg match { case Derived(_) => 42 } } } エラーを与える constructor cannot be instantiated to expected type; found : A$A87.this.Derived required: A$A87.this.Base[A] case Derived(_) => 42 ^ Aメソッド型パラメーターの場合は正常にコンパイルされますが class Test { def …

9 scala  pattern-matching  type-inference  type-parameter 

非常に高速でメッセージを転送するサービスがあります。 現在、それはakka-tcpによって提供され、1分あたり350万のメッセージを作成します。grpcを試してみることにしました。残念ながら、その結果、スループットははるかに小さくなりました。1分あたり約50万メッセージはさらに少なくなります。 それを最適化する方法をお勧めしていただけませんか？ 私のセットアップ ハードウェア：32コア、24 Gbヒープ。 grpcバージョン：1.25.0 メッセージ形式とエンドポイント メッセージは基本的にバイナリBLOBです。クライアントは100K-1M以上のメッセージを同じリクエストに（非同期で）ストリーミングし、サーバーは何も応答せず、クライアントは何もしないオブザーバーを使用します service MyService { rpc send (stream MyMessage) returns (stream DummyResponse); } message MyMessage { int64 someField = 1; bytes payload = 2; //not huge } message DummyResponse { } 問題：akka実装と比較してメッセージレートが低い。CPU使用率が低いので、別の言い方をしても、grpc呼び出しが実際に内部的にブロックされているのではないかと思います。onNext()確かに呼び出しはすぐには戻りませんが、テーブルにGCもあります。 この問題を緩和するために、より多くの送信者を生成しようとしましたが、あまり改善されませんでした。 私の調査結果 Grpcは、メッセージをシリアル化するときに、実際に各メッセージに8KBバイトのバッファーを割り当てます。スタックトレースを見てください： java.lang.Thread.State：BLOCKED（オブジェクトモニター上）com.google.common.io.ByteStreams.createBuffer（ByteStreams.java:58）at com.google.common.io.ByteStreams.copy（ByteStreams.java： 105）io.grpc.internal.MessageFramer.writeUncompressed（MessageFramer.javaでio.grpc.internal.MessageFramer.writeKnownLengthUncompressed（MessageFramer.java:230）でio.grpc.internal.MessageFramer.writeToOutputStream（MessageFramer.java:274）に：168）io.grpc.internal.MessageFramer.writePayload（MessageFramer.java:141）at io.grpc.internal.AbstractStream.writeMessage（AbstractStream.java:53）at io.grpc.internal.ForwardingClientStream.writeMessage（ForwardingClientStream。 java：37）io.grpc.internal.DelayedStream.writeMessage（DelayedStream.java:252）at io.grpc.internal。ClientCallImpl.sendMessageInternal（ClientCallImpl.java:473）at io.grpc.internal.ClientCallImpl.sendMessage（ClientCallImpl.java:457）at …

9 java  scala  grpc 

次のコードのデータフレームがあります。 def test(lat: Double, lon: Double) = { println(s"testing ${lat / lon}") Map("one" -> "one", "two" -> "two") } val testUDF = udf(test _) df.withColumn("test", testUDF(col("lat"), col("lon"))) .withColumn("test1", col("test.one")) .withColumn("test2", col("test.two")) ログを確認したところ、行ごとにUDFが3回実行されていることがわかりました。「test.three」列から「test3」を追加すると、UDFがもう一度実行されます。 なぜ誰かが私に理由を説明できますか？ これは適切に回避できますか？

9 scala  apache-spark  apache-spark-sql