Develop Reference

Cholesky decomposition with jeigen?

I looked for fast java linear algebra library. I tried many of them(jblas, ujmp, ejml and others). In terms of performance finally I found more reliable the jeigen (java wrapper for c++ eigen library). But wrapper has no Cholesky decomposition. But original eigen it has. Is there a way to add decomposition to wrapper?

I do not know of a Java wrapper that performs a Cholesky Decomposition. Perhaps another user will post after me who is more knowledgeable specifically about Java and jeigen.
However, I can offer some help on your underlying problem, which is to perform a Cholesky Decomposition; I recently wrote a C++ program that performs a Cholesky Decomposition on a real, symmetric, positive-definite, matrix. The source code is freely available on GitHub:
https://github.com/dcb2015/dpotrf_ak1/blob/master/dpotrf_ak1.cpp
You can:
1) use the complete C++ program as-is in your own C++ compiler, or use the C++ source in your own program, if you know C++.
2) translate the C++ routine into Java for use in your own program. The sub-routine that performs the decomposition is quite small. And Java syntax is very similar to C/C++ syntax, so the translation should not be difficult. (Actually, I usually try to avoid the "++" aspects of the language and code as close to simple "C" as possible.) If writing the Java program is part of your work or assignment, this might be your best option.
3) use a ready-for-use JavaScript version of this program which is available online (see my Profile for the site.) If you do not have to write this program yourself, but only need the results of a decomposition, try it out. It may help you out of a tough spot.

Running algorithms in compiled C/C++ code within a Java/PHP/Python framework?

Occasionally, I have come across programming techniques that involve creating application frameworks or websites in Java, PHP or Python, but when complex algorithms are needed, writing those out in C or C++ and running them as API-like function calls within your Java/PHP/Python code.
I have been googling and searching around the net for this, and unless I don't know the name of the practice, I can't seem to find anything on it.
To put simply, how can I:
Create functions or classes in C or C++
Compile them into a DLL/binary/some form
Run the functions from -
Java
PHP
Python
I suspect JSON/XML like output and input must be created between the Java/PHP/Python and the C/C++ function so the data can be easily bridged, but that is okay.
I'm just not sure how to approach this technique, but it seems like a very smart way to take advantage of the great features of Java, PHP, and Python while at the same time utilizing the very fast programming languages for large, complex tasks.
The other thought going through my head is if I am creating functions using only literals in Java/PHP/Python, will it go nearly as fast as C anyway?
The specific tasks I'm looking to work with C/C++ on is massive loops, pinging a database, and analyzing maps. No work has started yet, its all theory now.

You can easily extend a python script with custom C++ code using Boost.Python, see this website for more details: http://www.boost.org/doc/libs/1_50_0/libs/python/doc/
This is how you can use it:
char const* greet()
{
return "hello, world";
}
#include <boost/python.hpp>
BOOST_PYTHON_MODULE(hello_ext)
{
using namespace boost::python;
def("greet", greet);
}
You need to compile this into a shared library. You will get a .dll on windows and a .so on Linux. The library will include the necessary code to make it available to python. Example using it:
>>> import hello_ext
>>> print hello_ext.greet()
hello, world
Here are some more examples: http://www.boost.org/doc/libs/1_50_0/libs/python/doc/tutorial/doc/html/index.html
When using Boost.Python remember to link your shared object to python if you are not using weak dynamic linking. There are similar things for PHP and Java.
As for other languages, I never used a custom shared library with Java but did so with PHP and it was a pain using the native Api. I found using swig way more pleasant.

Altough I agree with the comments (you might do it for fun, for business it's a bad idea) you might be interested in this similar question. The mentioned SWIG framework supports
all the languages you mentioned. I worked with it in a project with tons of legacy C code. Not really simple, but very powerful.

For Java, you can search JNI (Java Native Interface), there're a lot of guides telling how to use it.

On a slightly different take from the other proposed solutions, you could look into Gearman
Basically, it's a broker system. You have workers, which can be written in C in your case, to which you can delegate tasks from your python / php / java / w/e code.
Strong point is that you decouple both applications (if you rewrite your app in another language, you'll probably have less work as you only need to get the app to talk to Gearman).
Bad thing is that I think you'll be adding overhead which could make the performance boost irrelevant.

Computer vision, C++ OR Java

I'm a complete newbie in the computer vision world and recently I implemented some examples using OpenCV with Java. I'm impressed with the potential this area has and wish to continue learning more.
I learned that OpenCV is written in C++ and while Java has a wrapper (JavaCV) I understood that the applications in Java are slower than in C++ and most enterprise application are written in C++.
My question is this: I have few years of experience in Java and I feel very comfortable to write any application with it; would it be smart to move to C++ to learn CV or should I stick with Java and use its wrapper.

Computer vision is a demanding area - and while it is true that you'd best stay with what you know, and move to opencv only if performance is needed, another truth is that you'll need to go deep into mathematics, pointers and algorithms to learn and build a good computer vision app. And to do that in Java can be more cumbersome than learning c++.
So, if all you want to do is to apply a filter over an image for some school project - go for Java. But if you want to stay more with OpenCV, to learn vision algorithms or to write your own, my strong suggestion is to learn C++ - isn't that scary!
A reason to write native code is flexibility - you'll want to do all kind of tricks that are difficult or performance-killers in Java.
Shortly speaking, learning C++ is much simpler than computer vision. And OpenCV is not just a library you want to call to do some processing out there. It's bleeding edge technology - you'll want to understand it, to hack into it, to build over it, to go through the code, much more than call someJNIfunc();
And if you do so, please be aware that OpenCV offers two interfaces - one for C and one for C++. And while they offer the same functionality, the C++ one is much like Java - with automatic memory management and more sweeties. You can refer to this post to see the differences

I suggest sticking with what you're comfortable with for now. Only switch to C++ when you find that it doesn't expose certain APIs you want or performance actually becomes a problem. Right now, you're in the learning phase.

JavaCV uses a wrapper called JavaCPP to call OpenCV from Java programs. JavaCPP automatically generates temporary native libraries that form a bridge used by JNI to let Java programs call the OpenCV native libraries.
The solution is elegant and it works well, but is quite finicky about installing just the right versions and having classpaths set correctly. You can get a glimpse of the difficulties people face at the JavaCV discussion forum, and at http://code.google.com/p/javacv/wiki/Windows7AndOpenCV.
I got this working with OpenCV-2.3.1 on XP, Windows 7, and Ubuntu 10.11, and still it took me several days to get it all updated to OpenCV-2.4.2. ffmpeg is especially tricky to get right across all platforms.
There is little or no speed overhead if you are using Java for high level program control because image objects and list-based data structures are maintained on the native side through pointers. One pitfall is knowing who is responsible for releasing allocated memory, so be prepared for VM crashes with complicated programs.
There is a bit overhead in transferring data objects to the Java side. I find that it takes about 1 microsecond to copy a keypoint location into a Java-side Point object. This doesn't sound like much but in a real-time application with thousands of keypoints it can make a difference. We also copy JavaCV IplImage objects to Java through ByteBuffers. This takes a millisecond or less so is quite feasible for real-time use.
In our case, we have a substantial body of Java code to leverage against OpenCV. And Java's garbage collection makes many things much much easier. I are satisfied that the overhead of learning JavaCV has been well worth it.
I found it necessary to build the project in Eclipse and compile JavaCV from source instead of using javacv.jar. (You'll need the other .jar files though.) This lets you examine exceptions to track down library version and classpath errors. And the JavaCV source is needed to understand how JavaCV exposes the OpenCV API.

How much time is spent in the OpenCV library and how much time is spend in your program? If your program entirely in C++ it cannot reduce the time spent in your program (outside the library) to less than nothing. e.g. if you spend 99% of your time in the library, using C++ cannot make it more than 1% faster.

For simple programs, Java and C++ doesn't make any significant difference in speed. But for a large code with lot of computational complexity, C++ turns out to be faster.
Wrappers do have a problem of overhead. But this will be negligible for a small program. If you write a complex code in Java, it wont be easy to rewrite it into C++. This is because of the large no of functions available in Java which will be so much different from C++.
Whether you should use Java or C++ for OpenCV depends on your motive.
If you seriously want to lean OpenCV and work on some big projects , I suggest you to move on to C++. But if you are looking for having just some fun with OpenCV, it will be better to stick to what you know.

Among C++ or Java, better use C++. I have almost no experience in Java, but the reason I would recommend C++ is its common usage among ML&CV libraries.
One of the best solution of powerful and flexible computer vision application may be next sequence:
training a model using flexible Python and popular machine learning libraries;
storing pre-trained weights;
rewriting the best model architechture to C++ using OpenCV library with useful, but not extensive Mat class or compiling to C++ ML model;
compiling with definite specification of your device processor.
Advances of this solution are application work speed, code safety, development speed and compatibility with many devices.
Moreover, Python Tensorflow and other models could be loaded to C++, e.g. PyTorch.
Besides, it is much more easier to get help from CV community with the C++ OpenCV code.
Disadvantages are tons of development problems and development speed (which may not be omitted with Java), sometimes strictful flexibility limits of OpenCV lib, and many others you may not think of at the beginning.

What parts of a Java application should be written in Scala?

I'm writing a Java application using Struts 2, but now I'd like to make it a hybrid Java & Scala project instead. I don't have much experience with Scala, but I learned Haskell years ago at college -- I really liked the functional programmed paradigm, but of course in class we were only given problems that were supremely suited to a functional solution! In the real world, I think some code is better suited to an imperative style, and I want to continue using Java for that (I know Scala supports imperative syntax, but I'm not ready to go in the direction of a pure Scala project just yet).
In a hybrid project, how does one decide what to code in Java and what to code in Scala?

Two things:
99% of Java code can be expressed in Scala
You can write projects that support mixed Java+Scala compilation. Your Scala code can call your Java code and your Java code can call your Scala code. (If you want to do the latter, I suggest defining the interface in Java and then just implementing it in Scala. Otherwise, calling Scala code from Java can get a little ugly.)
So the answer is: whatever parts you want. Your Scala code does not need to be purely functional. Your Scala code can call Java libraries. So pretty much any parts you could write in Java you could also write in Scala.
Now, some more practical considerations. When first trying Scala, some people pick relatively isolated, non-mission-critical parts of their program to write in Scala. Unit tests are a good candidate if you like that approach.
If you're familiar with Java and have learned Haskell in the past, I suggest treating Scala as a "better Java". Fundamentally, Scala compiles to JVM bytecode that is very, very similar to what Java outputs. The only difference is that Scala is more "productive": it produces more bytecode per line of code than Java does. Scala has a lot of things in common with Haskell (first-class functions, for-comprehensions are like Haskell's do-notation, limited type inference), but it's also very different (it's not lazy by default, it's not pure). So you can use some of your insights from Haskell to inspire your Scala style, but "under the hood" it's all Java bytecode.

In the spirit of your question, I recommend you write in Scala any code that involves heavy manipulation of collections, or that handle XML.
Scala's collection library is the foremost functional feature of Scala, and you'll experience great LoC reduction through its usage. Yes, there are Java alternatives, such as Google's collection library, but you asked what you should write in Scala. :-)
Scala also has native handling of XML. You might well find the transition difficult, if you try to take DOM code and make it work on Scala. But if you, instead, try to approach the problem and the Scala perspective and write it from scratch for Scala, you'll have gains.
I'd advise using Actors as well, but I'm not sure how well you can integrate that with Struts 2 code on Java. But if you have concurrent code, give Actors in Scala a thought.

It might sound silly, but why not write your entire project in Scala? It's a wonderful language that is far more expressive than Java while maintaining binary-compatible access to existing Java libraries.

Ask these questions of your project:
"What operations need side-effects?" and "What functionality is already covered well by Java libraries?" Then implement the rest in Scala.
However I would warn that hybrid projects are by their very nature more difficult than stand alone projects as you need to use multiple languages/environments. So given you claim not much experience with Scala I'd recommend playing with some toy projects first, perhaps a subset of your full goal. That will also give you a feel for where the divide should occur.

Accessing .NET/dll libraries/components from Java?

Are there inexpensive or free gateways from .NET to Java? I'm looking at some data acquisition hardware which has drivers for C/C++ and .NET -- I really don't want to do any programming in .NET.
Update: I haven't done what I originally wanted to do, but I've done something similar, using JNA to encapsulate some functions from a DLL, in order to control a USB hardware device from Java. (the DLL comes from the device manufacturer) It works really nicely. Thanks!

You could also try to use JNA for accessing the native library. JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. If their API is fairly straight foward, this might be the path of least resistance.
See their getting started guide where they call some native code (printf and GetSystemTime).

Well, there's JNBridge and EZ JCom, just from a Google search.
You could also use IKVM which is a slightly different approach.
(Any reason for not wanting to learn .NET, out of interest? It's a nice platform, and C# is a lovely language...)

If they have C++ versions of the drivers then you could write a wrapper around it using JNI and then load that in Java. JNI can be a bit of a pain, but it would let you use the C++ version of their drivers and not have to deal with .Net at all if you don't want.

I am partial to the recommendation to jump in the deep end with C# since it is so similar to Java. I did this and used IKVM to compile my favorite Java libs. to .NET assemblies and you get [nearly] all the core java runtime classes to boot, so if you tire of trying to find just the right C# collection type, you can always go back to java.util. (No generic collections though. Not sure why.)
Depending on what platform you're on, you have several choices for free IDEs too. For windows you can get Visual Studio Express for free but I also use SharpDevelop. You can also get the Mono IDE on Linux (and a few flavours of Unix, I think ?).
The C# learning curve is shallow if you already know Java. I only blew off 1.5 limbs on landmines that came out of nowhere for reasons I still don't understand, but workarounds were easy to come by. The worst thing about it was the darn developer docs which are AWFUL on account of being so slow. I really miss the snappiness of JavaDoc. Not only are the online docs incredibly slow, the problem is compounded by someones's iffy decision to put class summaries, constructors and methods/properties all on seperate pages so it just takes forever. Someone said to get the docs installer and install docs locally for a slightly improved experience. Not a bad idea I suppose.

I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

If you have a Java application, the JNI mentioned by the others will be the way to go. You write some wrapper classes, and that's it.
If writing the wrappes is a too big task (depending on the number of methods you have to wrap), have a look at SWIG . I think it generates wrappers automatically, but I never actually used it.
If you want to code in the Java language, but you don't care if your program will run on the JRE/JVM, then you might as well use Microsoft J#. Basically, it's writing Java-Code wich is compiled to .NET-Bytecode and can use the .NET classes of the driver as well as your existing Java classes. With J# you will run into problems if your existing Java-code is newer than Java 1.4, look at this question on how to solve them.
From that point on, you could later add code in J#, C# or any other .NET language. However, you won't get back to the JRE/JVM easily.