[Gambas-user] Complex Numbers and Shared Libraries

[Cedron Dawg]

[...snip...]


There are embedded arrays [2] which should have a packed representation
in memory like arrays in C, but I don't know if you can cast any pointer
to such an array type and then use it successfully.

> Now we come to the crux of my real question.  The return values from a DFT is an array of complex numbers.  In the FFTW library, a complex number is two adjacent floats in memory, the first being the real part and the second being the imaginary part.
> 
> I seem to have three options:
> 
> 1) Deal with two doubles
> 2) Use the gb.gsl complex
> 3) Use gb.complex
> 
> The first I know I can do.  The other two are mutually incompatible.  Since I am likely to want to use the gsl for more stuff, I think I would like to use #2.
> 
> I've been doing some experimenting and researching, and have not been able to figure out how to get the address of the actual values.  Nor have I been able to read or write complex values to the remote memory area.
> 
> Second question:  Is this possible?
> 

That should be very possible. If you have the two Floats (note: a C float
is a Gambas Single, a C double is a Gambas Float), you can create a complex
number object from them:

  ' ... get re and im from the library ...
  Dim z As New Complex(re, im)

You can get the real and imaginary part back out of the object if you
need to pass them again to the library later.

gb.complex and gb.gsl both allow that.

> I am proceeding under the assumption it is not.  Any opinions on how I am doing things are welcome.  I am still a newbie to Gambas.

If you want to interface Gambas with C libraries, the -by far- cleanest
solution is to write what is called a *native component* for Gambas.
This is a C library itself which is written in the Gambas C framework.
This framework consists of many preprocessor macros and an interpreter API.
At the end of the day, this framework enables you to implement Gambas
classes in C, so that you can access your target library properly in C,
but present it as if it was written in Gambas.

As a corollary, you don't have to wrestle with struct alignment issues
anymore because all access to C structs is done from C code, not Gambas
code. All this translation of struct definitions and functions from a
C library into Gambas Struct and Extern declarations becomes really,
really messy really, really fast.

The downside is that currently native components have to live in the
Gambas source tree and be compiled from there, so you are less flexible
about the distribution of your component. I don't see why that has to
stay like this though. The only thing you really need most of the time
is the gambas.h header which might even be installed into /usr/include
in a hypothetical future.

Regards,
Tobi

[1] http://gambaswiki.org/wiki/lang/alloc
[2] http://gambaswiki.org/wiki/lang/arraydecl

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

=======================================================================

That's what I meant by the two doubles approach.  I should have said floats, sorry.

The ease of development and debugging is a big consideration for me.  With a shared library, I can edit the source code in Pluma, press save, go to my terminal, hit up arrow/enter, then go to Gambas and press the run button.  I don't see being able to make something easier than that.  I really like that I can put temporary debug printf statements in my C code and see the output in the console.

I'm also root on my machine, so putting a .so link in my /usr/lib or a .h in my /usr/include is not a problem.

Ced