search

lessthanoptimal / ejml

A fast and easy to use linear algebra library written in Java for dense, sparse, real, and complex matrices.
https://ejml.org
563 stars 117 forks source link

Missing float matrix constructors/code? #100

Closed antinos closed 4 years ago

antinos commented 4 years ago

Hello, Very likely a silly question which you can hopefully dismiss quickly, but is the library missing most of its float matrix constructors? For example, in org.ejml.data (https://github.com/lessthanoptimal/ejml/tree/SNAPSHOT/main/ejml-core/src/org/ejml/data) I was expecting to find FMatrix.java? They are all present in the latest .jar build, but I can't find the source code.

Major apologies if I am just not looking in the right place or if this is an expected condition.

Kind regards.

EDIT. Also, thanks so much for the amazing library.

lessthanoptimal commented 4 years ago

Almost all the float code is now auto generated from double code in the latest SNAPSHOT. In the next release there's a good chance more auto generated code will be removed from the repo.

antinos commented 4 years ago

Thanks for the quick and clear response. I'm not a programmer by profession and don't have any experience with Gradle and autogenerated code. I've just tried to build the project after installing Gradle and ran into java version issues (i'm running 1.8). I couldn't immediately see a way to generate the source whilst importing into eclipse with the buildship plugin either. These aren't your issues though, I just need to educate myself a bit and to actually follow the project readme.

Thanks again.

EDIT I updated to openJDK11 and successfully built the project using Gradle! Sorry to waste your time.

lessthanoptimal commented 4 years ago

No problem! I also updated the readme to make it a bit clearer. FYI you probably don't need to work off of source code directly unless you need a really new feature. I would probably stick to pre-built jars on Maven central that can be easily added using Gradle.

antinos commented 4 years ago

Thanks a tonne. Using the pre-built .jar from the maven repo was definitely my first choice and works perfectly in my test environment. However, I need to refactor the library a little to overcome .jar conflicts in the deployed setting (I'm making an ImageJ/Fiji plugin and they already have an earlier version of ejml baked into their default distribution). I know the better option is for Fiji to update their ejml, but the software is mish-mash of old and new plugins, and changing their ejml could break existing core functions (although I haven't looked into this in much depth). Not being a professional, I am sure there are other and better ways to handle this. An added advantage for me of using source is that I get a little peak behind the curtain, to hopefully educate myself, and I also get to inject some ImageJ API log calls and the like. Anyway, probably more info here than you are at all interested in.

Kind regards.

lessthanoptimal commented 4 years ago

Sounds good and ImageJ might be stuck on that version of EJML for a very long time from what it sounds like!