nd4j | Fast , Scientific and Numerical Computing for the JVM | GPU library

in the comments I would appreciate comments on our docs to help improve the site. We cover this scenario explicitly. I'll summarize it below then comment with a link. If you see anything missing please do help us improve the website for the future.

Nd4j uses javacpp which relies on classifiers to determine how to include native binaries. The way it works is the core classes are put in a standalone library/artifactId (nd4j-native) and it needs an accompanying classifier dependency to go with it. This will be an artifact id with the same name and version plus an additional classifier. This will usually be the OS and architecture name for your platform. This could be linux-x86_64 (linux on 64 bit intel) or android-arm64 (android on 64 bit ARM devices)

These also usually have accompanying dependencies such as openblas (which we also use the javacpp bindings for) to enable us to access fast 3rd party math routines.

With that in mind a dependency block like this is usually what you're looking for:

That looks like an old example. Where did you get it from? Note that the project does not endorse or support random examples people pull from. If this is from the book, please note those examples are a few years old at this point and should not be used.

This should be the latest one: https://github.com/eclipse/deeplearning4j-examples/blob/master/dl4j-examples/src/main/java/org/deeplearning4j/examples/quickstart/modeling/feedforward/classification/ModelXOR.java

This configuration suffers from what I like to call the "toy problem syndrome". Dl4j assumes minibatches by default and therefore clips the learning by default relative to the minibatch size of the input examples. This is how 99% of problems are setup if you do anything in the real world.

This means that each step the net takes is actually not the full step it would take if you do a toy problem with the whole set in memory. Our latest example handles this by turning minibatch off for this:

Could you clarify a bit about what you are running in to? Your build.gradle would be nice to see. It's kind of hard to tell what you might be running in to.

The only thing I can tell you is that there are certain properties files that are used by the framework that should be bundled in the jars.

Typically when this happens, that means that whatever is bundling the jar didn't include that resource.

Thanks!

CanvasFrame tries to do gamma correction by default because it's typically needed by cameras used for CV, but cheap webcams usually output gamma corrected images, so make sure to let CanvasFrame know about it this way:

Firstly, always use Nd4j.create(..) for ndarrays. Never use the implementation. That allows you to safely create ndarrays that will work whether you use cpus or gpus.

2nd: Always use the RecordReaderDataSetIterator's builder rather than the constructor. It's very long and error prone.

That is why we made the builder in the first place.

Your NullPointer actually isn't coming from where you think it is. it's due to how you're creating the ndarray. There's no data type or anything so it can't know what to expect. Nd4j.create(..) will properly setup the ndarray for you.

Beyond that you are doing things the right way. The record reader handles the batching for you.

Well, I couldn't work out how to make log4j function. I tried what was suggested in the comments, such as including slf4j-log4j12, or nd4j-x86.

Sometimes the best way to solve a problem is to remove it instead: I stopped trying to get log4j to function and went with nd4j-native.

I ran mvn dependency:tree on your project and it turns out there were older versions being pulled in:

hold its data in that library's native matrix data structure. I think this is a use case for generics.

Generics serves to link things. You declared the type variable with , and you've used it in, as far as your paste goes, exactly one place (a field, of type T). That's a red flag; generally, given that it links things, if you use it in only one place that's usually a bad sign.

Here's what I mean: Imagine you want to write a method that says: This method takes 2 parameters and returns something. This code doesn't particularly care what you toss in here, but, the parameters must be the same type and I return something of that type too. You want to link the type of the parameter, the type of the other parameter, and the return type together.

That is what generics is for.

It may apply here, if we twist our minds a bit: You want to link the type of the data field to a notion that some specific implementation of BaseMatrix can only operate on some specific type, e.g. ND4JMatrix.

However, mostly, no, this doesn't strike me as proper use of generics. You can avoid it altogether quite easily: Just.. stop having that private T data; field. What good is it doing you here? You have no idea what type that is, you don't even know if it is serializable. You know nothing about it, and the compiler confirms this: There is absolutely not one iota you can do with that object, except things you can do to all objects which are generally quite uninteresting. You can call .toString() on it, synchronize on it, maybe invoke .hashCode(), that's about it.

Why not just ditch that field? The implementation can make the field, no need for it to be in base!

Here: