FYI: this library has been in development for nearly a decade and is very mature. It is as old as the likes of Scikit-Learn or Theano. It is, or at least was, widely used within MS.
I spent a good couple of hours trying to get into machine learning, using Microsoft.ML,from zero previous knowledge. I did the iris and sentiment tutorial on Microsofts docs, but when I tried moving to my own (very simple) dataset, I got exception after exception not understanding why. No one else seem to have the problems (because it's so new - to the public) and the source on github is apparently incomplete so I couldn't dig all the answers out myself.
It might be stable and mature but it's not a good entry point for beginners imo.
Can you explain how this is done? Does this mean that VM and the GPUs can be on different host machines? Will it affect the GPU-CPU communication performance?
Sounds like if you max the GPUs per CPU core they have CPU cores "left over" that they then use for CPU-only instances, instead of splitting a host to a predefined pattern of just GPU instances that use up all the CPU as well.
I'm a fan of Keras too. Including comments on Keras and other higher-level libraries would make my original review too long, hence I dropped it.
Note that the performance review is very much incomplete. As mentioned in the blog: Deep Learning is not just about feed-forward convnets, not just about ImageNet, and certainly not just about a few passes over the network. However, Soumith’s benchmark is the only notable one as of today. So we will base the Single-GPU performance rating based on his benchmark.
For TF, I think a bigger single-node perf issue is memory allocation. At NIPS, Jeff Dean didn't have a straight forward answer for why TF's memory perf is so poor.
Tensor is a much better term than multidimensional array:
- It's not as verbose
- The concept of tensor has linear algebra operations associated with it while multidimensional array is just a programming term without any attached Math operations.
> The concept of tensor has linear algebra operations associated with it while multidimensional array is just a programming term without any attached Math operations.
But that's the precise problem. The multidimensional arrays that programmers call "tensors" do not generally have the operations defined on them that you would expect from a tensor, such as index contraction, tensor products, or differentiation. At the same time, a tensor is different from an array, just like a number is different from its decimal representation. These distinctions are important when you want to change the basis, a very useful and frequent operation for both tensors and numbers.
Then again, this battle was already fought and lost for vectors, which programmers specialised to mean "arrays" instead of meaning "elements of a linear space".
I have used MSYS2 but decided to come back to Cygwin.
1. Commands in MSYS2, while fast in its shell, are slower than Cygwin's commands when run in PowerShell.
2. MSYS2 can't be installed via Chocolatey. It's because MSYS2 owners are against Chocolatey (insane!). Which makes it harder to automate the replication of my environment across machines.
3. Cygwin does has package managers. I use Cyg-Get, which is also available via Chocolatey.
If not, what do you think would be the most likely-way forward for cross-platform C++/CLI:
- Forget it
- Make VC++ cross-platform
- clang/gcc to support C++/CLI and produce mixed-mode assembly
?
public int X { get; } is more consistent with how properties are declared. Consistency is important.
If you care about clean code, here's an even better way
public readonly int X;
They are not exactly the same but they are equivalent in most cases. In exotic cases where you're required to use auto-getters, adding the brackets wouldn't hurt.
> public int X { get; } is more consistent with how properties are declared. Consistency is important.
As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc.
The braces are for scope in C# and all C derivative languages. There is no scope being created here and no requirement for scope.
Also there are other places in C# where the scoping braces can be dropped [when there's only a single statement within]:
if(foo == 1)
{
bar();
}
Can be written:
if(foo == 1)
bar();
So I don't see the inconsistency at all if they were to drop the braces.
> If you care about clean code, here's an even better way public readonly int X
That's what I use. Cue the next round of discussion about fields and properties...
>As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax?
They did change the property declaration syntax too.
public int X => 5;
is the same as
public int X { get { return 5; } }
This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about.
Of course it isn't identical to public int X { get; } because the latter is assignable in the constructor. But comparing _that_ to methods is apples to oranges since methods aren't assignable.
I think you're quoting me out of context here. I am debating the consistency angle. My argument is that if there is such a drive for consistency (and therefore that's a good reason to keep the braces) then the method syntax wouldn't have changed to drop the braces. So I feel that argument is moot when discussing the reason for keeping the (what I believe to be) ugly syntax of X { get; } = 5;
Your example of the computed properties is not the same. I like the computed properties syntax, but unless the properties can be computed from the constructor parameters then you will still need to either use the ugly property syntax, or readonly fields to get the same immutable guarantees.
Personally I am fine with using readonly fields, I was only commenting on how the C# team have (in my opinion) missed the opportunity to get rid of some of the unnecessary clutter. I know however many people don't like using readonly fields for various reasons: serialisation, data-binding, interface declarations, etc.
This is a rather poor example. If you distribute the C# code above as a library, people can extend and introduce another shape, while they cannot do it easily with you F# code.
I did mention the Expression Problem[1] in my comment, and explicitly called out subclassing as a particular advantage of C# (the OP asked for criticism of F#).
Also, even though F# can also subclass, that facility is a bit weak since it can't define protected members.
MS only decided to open source it recently.
Disclaimer: I was one of the early team members.