dragonfly-ai / slash Goto Github PK

Any plans to add numerical methods for approximating cumulative distributions?

Hello!

Maybe a silly question - I see lots of "c authored..." in this repository's commit history - what does that mean?

Thank you!

Write exhaustive tests for javascript and jvm versions of VectorN.

Add support for kernels.

Hello!

I'm interested in trying out SLASH, but I'm confused what the current version is - on Scaladex, I see 0.1 is the most recent version (https://index.scala-lang.org/dragonfly-ai/slash) but I see 0.101 on main (

Which one should I use?

Thank you!

There's a more proper way to estimate all four parameters of a Beta distribution.

This might be better suited to a discussion than an issue, but I don't think discussions are open on this repo?

Some observations:

Getting started took a little more time than was necessary, as I had to go to maven to figure out the version and org
//> using lib ai.dragonfly::vector::0.101

Perhaps could be added to the top of the readme?

Vec[3](true, false, true) is a compile error. Can I assume, that this library is specialised to double vectors as a deliberate design choice?

val b = NArray(false, true) would be it's equivalent?

Currently, I can see how to index into a single entry, x(5). Is it possible to index into multiple entries, or would that be a custom for loop?

Spiritually,

val v = (1 to 10).map(_.toDouble).toArray
 val x = Vec[10]( v )
 val s = Vec(5,6)
 val slicedVec = x(s) // compile error... ideally would be a Vec[2](5, 6)

A Naive implementation fails, because Vec doesn't implement map

println(for (idx <- s) yield{ x(idx) }) // compile error

Is there a canonical approach to such a thing? I can see that NArrays get ArrayOps methods ... is it the intent that Vectors would, as well?

  val x = Vec.fill[10](2.0)
  val y = Vec.fill[10](1.0)
  val z = x.add(y)

  println("---- x ")
  println(x.show)
  println("---- y ")
  println(y.show)
  println("---- z ")
  println(z.show)

Prints

---- x 
《¹⁰↗〉3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0〉
---- y 
《¹⁰↗〉1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0〉
---- z 
《¹⁰↗〉3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0, 3.0〉

Is that expected? I assume so? It would appear, that the "add" operation has mutated the value of x. In contrast, x + y, does not.

Is it a "convention" that a .method, may mutate it's inputs? In Julia, a method which operates on its inputs would be called add!, to make this very clear.

Further, my personal preference (which you may feel free to ignore), is that a function which mutates its inputs should return Unit, or have an = in it's name. i.e. be purely side effecting. This is largely because of scalas immutable by default behaviour - which I feel a little this quietly subverts, and thus can surprise the unwary.

This is a personal preference, but in my opinion, the combination of these two changes could make it much clearer that "Here Be Dragons", with the mutable methods.