Re: Question on Java implementation
Thanks. Will do. Don't get me (too) wrong. This self-requirement is that I produce some software able to work on any computer. The natural language choice (for me) was Java. If I didn't levy this requirement, my preferred language is C++. I know, but haven't worked with, C/Fortran in years. And I quite understand why C/Fortran is an excellent choice; only not for this effort. art On 5/14/2024 10:16 PM, Dave Allured - NOAA Affiliate wrote: Hmmm. No compiling -- that caught me by surprise because I dwell in the C/fortran world. But I see now, what you are trying to do. Did you see the list of alternative math packages on the GNU GSL home page? You might check to see if there is a Java SVD implementation in there somewhere. On Tue, May 14, 2024 at 10:49 PM lostbits wrote: I don't think that this will do. The issue is that C is not cross-platform. The C code will have to compiled for each platform that it is to be used on, and then a distribution scheme must be developed to deliver the C and Java wrappers.I am trying to avoid this. But, I think I can restrict my needs to SVD for the time being, so I will just recode SVD in Java. Thanks. In other applications this might turn out to be an ideal solution. art On 5/14/2024 12:02 PM, Dave Allured - NOAA Affiliate wrote: Just to be clear, JavaCPP is a Java wrapper around the GSL C library. GSL is 100% C. JavaCPP is almost 100% Java. So you would first install the GSL C library, then JavaCPP, then you would be ready to access GSL for your Java project, through the JavaCPP interface. Will this work okay for your project? On Tue, May 14, 2024 at 9:36 AM Dave Allured - NOAA Affiliate wrote: The GSL website home page lists JavaCPP, a package of Java wrappers for GSL. I think this is your best approach, mature and time tested, among other reasons. Will this be sufficient for your project? On Tue, May 14, 2024 at 9:11 AM lostbits wrote: Sorry to intrude. I'm working on a Java project and would like to use (at least) SVD in it. Is there a Java version of GSL, or GSL lookalike anywhere? This is not a heavy-duty numerical processing application, and time is not a constraint. Java was chosen because it is cross-platform, a goal, not because it is fast. thanks art
Re: Question on Java implementation
I don't think that this will do. The issue is that C is not cross-platform. The C code will have to compiled for each platform that it is to be used on, and then a distribution scheme must be developed to deliver the C and Java wrappers.I am trying to avoid this. But, I think I can restrict my needs to SVD for the time being, so I will just recode SVD in Java. Thanks. In other applications this might turn out to be an ideal solution. art On 5/14/2024 12:02 PM, Dave Allured - NOAA Affiliate wrote: Just to be clear, JavaCPP is a Java wrapper around the GSL C library. GSL is 100% C. JavaCPP is almost 100% Java. So you would first install the GSL C library, then JavaCPP, then you would be ready to access GSL for your Java project, through the JavaCPP interface. Will this work okay for your project? On Tue, May 14, 2024 at 9:36 AM Dave Allured - NOAA Affiliate wrote: The GSL website home page lists JavaCPP, a package of Java wrappers for GSL. I think this is your best approach, mature and time tested, among other reasons. Will this be sufficient for your project? On Tue, May 14, 2024 at 9:11 AM lostbits wrote: Sorry to intrude. I'm working on a Java project and would like to use (at least) SVD in it. Is there a Java version of GSL, or GSL lookalike anywhere? This is not a heavy-duty numerical processing application, and time is not a constraint. Java was chosen because it is cross-platform, a goal, not because it is fast. thanks art
Question on Java implementation
Sorry to intrude. I'm working on a Java project and would like to use (at least) SVD in it. Is there a Java version of GSL, or GSL lookalike anywhere? This is not a heavy-duty numerical processing application, and time is not a constraint. Java was chosen because it is cross-platform, a goal, not because it is fast. thanks art
Re: [Help-gsl] Fwd: Modifying adaptive integration function
On 5/11/2018 12:35 AM, Francesco Florian wrote: On Thursday, May 10, 2018 8:17:47 PM CEST lostbits wrote: On 5/10/2018 8:08 AM, Patrick Alken wrote: On 05/10/2018 04:18 AM, Francesco Florian wrote: Hello! Since I have received no answer, I wonder whether this is the right mailing list for this question. If it is not, can you please point me to the right one? Thank you Hello, What exactly are you trying to do that QAG cannot? Perhaps there is an alternate way without rewriting the function. My guess is you could get away with just removing the GSL_COERCE_DBL wrappers from the code, but it may not match the original QUADPACK results, according to the comments in qag.c. Patrick My guess is that gcc -DHAVE_EXTENDED_PRECISION_REGISTERS ... would define the pre-process variable, if that's what you want. If you do nothing then the variable is not defined. More to the point: #if HAVE_EXTENDED_PRECISION_REGISTERS #define GSL_COERCE_DBL(x) (gsl_coerce_double(x)) // used with gcc --DHAVE_EXTENDED_PRECISION_REGISTERS #else #define GSL_COERCE_DBL(x) (x) // used without defining the variable #endif I was looking for a way to check if the compiler actually supports it. The method above seems to rely on me knowing that, and then passing -DHAVE_EXTENDED_PRECISION_REGISTERS to gcc if appropriate. Patrick Alken's answer seems to suggest it is ok not to match QUADPACK results; if it is correct it would work for me. The compiler does support -D...The code probably supports the option also. If the code has a function gsl_coerce_double then the coe supports the option. As to the correct functionality, to wit, the code is correct but the operations are incompatible, perhaps the easiest way to to this check is to compile and execute and observe (or digitally check) the results. I am not knowledgeable on the options and don't know enough other than to suggest that you try and check.
Re: [Help-gsl] Why are standard (*, +, etc) operators not overloaded for complex numbers in C++
On 1/28/2018 10:01 AM, John D Lamb wrote:
On 27/01/18 19:38, Vincent Vandalon wrote:
Dear All,
I am curious why the standard binary operators are not overloaded for
the
gsl_complex type in C++; I presume this overloading is omitted
intentionally (since you can quickly write them yourself). Was the
choice
to omit overloaded operators mainly driven by the desire to avoid
accidentally/non-explicit casting of a built-in type to gsl_complex?
Presumably because gsl is written in C.
I don’t think C has a complex type. In any case the C++ complex type
seems to be difficult to make compatible with the gsl representation
while maintaining the original code in C.
I realise it is possible to do some sort of conversion/casting in C++.
But this is not likely efficient.
Operator overloading can be very efficient. To wit:
#ifdef COMPLEX_H
#define COMPLEX_H
class Complex { // example 1
private:
double creal;
double cimag;
public:
Complex(double real, double imag): creal(real), cimag(imag) {}
inline double imag() } return cimag; }
inline double real() { return ccreal;}
Complex& operator+(Complex y) {return Complex(y.real() + creal,
y.imag() + cimag);}
Complex& operator+(double y) {return Complex(y + creal, cimag);
// and so on
}
Complex& operator+(double y, Complex x) { return Complex(x.real() + y,
x.imag(); }
typedef struct { // example 2
double creal;
double cimag;} complex; // this is an example only --
C++ has a complex type
complex& operator+(complex x, complex y) { return complex{x.creal +
y.creal, x.cimag + y.cimag}; }
#endif
With all functions inline. The inline nature of the functions reduce
overhead by eliminating the function call and allows the compiler to
optimize the expression itself. The end result is a performance profile
similar to a built-in operation.
And the operator overloading can be extended to the remaining arithmetic
functions (-, *, /} with equal ease.
If the case against operator overloading is efficiency, then I think
that that can be dismissed. This doesn't mean that there aren't other
valid reasons for not extending the C functions into the C++ world. As
for example, here, In example 1 I have made the complex type a class and
implemented the add operator by adding two objects from the class.
Example 2 shows a non-object oriented approach.
Both the Complex and complex internals can be made conformant with the
existing approaches in gsl (with, perhaps, some issues not discussed
here). I've forgotten how to do casting. Look at the code in
gnu.org/software/gslip to see an approach.
art
[Help-gsl] A question on Vector and Matrix views
Why do views have to be on the stack? It is easy to construct a stack based view and use this view throughout the program so I don't understand the restriction? Why are there restrictions in using Matrix views in certain functions, GNU Scientific Library 8.4, or does the manual mean to say that wherever gsl_matrix * is used then tsl_matrix_view * can be used? A similar issue exists for vectors. thanks art
