Here the original mail exchange (in German) about this:
Wenn wir deinem Vorschlag folgen und eine logische Unterscheidung zwischen Scala-Primitiven und Tensor0 wollen, würde ich den Implicit Cast entfernen und in ausgewählten Methoden eine Overload-Method mit Boolean/Int/Float/Double implementieren. Dies sind viele Boilerplate Methoden für uns, aber es macht die User-Seite klarer. Wir definieren, welche Methoden Float/Double erlauben, z.B. alle arithmetischen Operationen. Und alle restlichen, z.B. gd.step(...), verlangen immer einen Tensor0.
Dann würde Folgendes einen Typerror geben (zurzeit gehen diese Statements):
optimizer.step(3f) // => Float is not a Tensor0
3f.median // => Float has no method median
Und man sollte auch bei contract/dot dann Folgendes nicht mehr erlauben, weil es eine Tensoroperation ist:
Tensor0(3f).dot(3f)
FYI:
Ich dachte SIP-71 würde dies vereinfachen, aber glaube ehrlich gesagt doch nicht, da es nur um den import geht: https://docs.scala-lang.org/sips/71.html
Here the original mail exchange (in German) about this:
Wenn wir deinem Vorschlag folgen und eine logische Unterscheidung zwischen Scala-Primitiven und Tensor0 wollen, würde ich den Implicit Cast entfernen und in ausgewählten Methoden eine Overload-Method mit Boolean/Int/Float/Double implementieren. Dies sind viele Boilerplate Methoden für uns, aber es macht die User-Seite klarer. Wir definieren, welche Methoden Float/Double erlauben, z.B. alle arithmetischen Operationen. Und alle restlichen, z.B. gd.step(...), verlangen immer einen Tensor0.
Dann würde Folgendes einen Typerror geben (zurzeit gehen diese Statements):
optimizer.step(3f) // => Float is not a Tensor0
3f.median // => Float has no method median
Und man sollte auch bei contract/dot dann Folgendes nicht mehr erlauben, weil es eine Tensoroperation ist:
Tensor0(3f).dot(3f)
FYI:
Ich dachte SIP-71 würde dies vereinfachen, aber glaube ehrlich gesagt doch nicht, da es nur um den import geht: https://docs.scala-lang.org/sips/71.html