Reconsider both curried and tupled overloads on dsharp.add etc.

This pattern of having both curried and tupled methods is not recommended F# design and will likely cause problems (I noticed it in strange doc generation). I think we will probably have to just choose one or another

    static member add(a:Tensor, b:Tensor) = a.add(b)
    static member add(b:Tensor) = fun (a:Tensor) -> a.add(b)
    static member sub(a:Tensor, b:Tensor) = a.sub(b)
    static member sub(b:Tensor) = fun (a:Tensor) -> a.sub(b)
    static member mul(a:Tensor, b:Tensor) = a.mul(b)
    static member mul(b:Tensor) = fun (a:Tensor) -> a.mul(b)
    static member div(a:Tensor, b:Tensor) = a.div(b)
    static member div(b:Tensor) = fun (a:Tensor) -> a.div(b)

[dsyme]

Proposal from discussion with @gbaydin - make an explicit open to get the pipelined notation

    t.dropout()
    t.dropout(0.5)

    dsharp.dropout (t, 0.5) // never used in documentation (curried, no pipeline)

    open DiffSharp.Pipelined
    t |> dsharp.dropout()
    t |> dsharp.dropout(0.5)

[dsyme]

Is the problem only about the documentation?

There are multiple potential problems:

1. Order of arguments is confusing, e.g. dsharp.sub x y is y - x not x - y. That’s really very confusing to people, and there’s nothing to force currying to be used for this overload. It’s ok for the API author - they know what to do - but other people won’t get this.

2. F# type inference and tooling is not really designed for APIs like this. I just don’t know if it will be that great. Certainly F# type inference just works much better if there are fewer overloads. Also will parameter help work? I don’t know.

3. 2x the documentation

4. It might be fine for div/add/mul/… etc. with two arguments but get whacky with other things that have more arguments. What’s the general rule?

5. Intellisense will be more confusing to people. 2x the entries and they won’t know which to choose

6. The curried methods will look confusing to people in intellisense

7. If we add shape inference, then we have 2x the API surface area

8. Too many ways to do the same thing

9. Are user-defined binary operators also meant to follow this pattern?

Of these (1) is to me too severe to embrace this on anything non-commutative.

There’s commonly also a problem where things like this combine: a 2x multiplication of your API surface area becomes 4x then 8x… when combined with something else (like overloading on scalars).

Anyway I’d recommend against building this in for now for all the above reason. In your example just write the lambda

else d.valuesTensor.unstack() |> Seq.map f |> dsharp.stack |> (fun t -> t.mean(0))

and separately advocate for solving this at the F# language level, e.g. via _.x(args) notation:

else d.valuesTensor.unstack() |> Seq.map f |> dsharp.stack |> _.mean(0)