Interfacing Ada with C

Interfacing Ada with C

[Paul Anderson]

Hi:

I have a need to interface an Ada library with a C program.
I am having trouble finding the best way to convert
strings between the two worlds.

I have a declaration:

    procedure One(Name : in Wide_String);
    pragma Export(C, One, "one");

When I compile I get:

foo.ads:29:42: warning: type of argument "One" is unconstrained array
foo.ads:29:42: warning: foreign caller must pass bounds explicitly

Fine, except how do I "pass bounds explicitly" when I call
this function in C?  The prototype for this function in C
would normally be:

    void one(wide_string w);

which doesn't have a slot for the bounds.  So where does it
go?

Alternatively, is there an different way of doing this that
avoids this problem?

I am using gnat-3.15p.

Thanks,

Paul.

Re: Interfacing Ada with C

[tmoran]

>The prototype for this function in C would normally be:
>
>    void one(wide_string w);
  As you've noted, what C calls a wide_string is not the same thing as
what Ada calls a Wide_String.  If a C wide_string is a null terminated
array of wchar_t, then you might try

    subtype variable_length_wide_string  -- known length (size_t) so no bounds
      is Interfaces.C.wchar_array(Interfaces.C.size_t);

    procedure One(C_Name : in out variable_length_wide_string);
    pragma Export(C, One, "one");
    ...
    procedure One(C_Name : in out variable_length_wide_string) is
      Name : Wide_String := Interfaces.C.To_Ada(C_Name);
    begin
      -- use/modify Name
      C_Name(0 .. Interfaces.C.Size_T(Name'length)) := Interfaces.C.To_C(Name);
    end One;

Re: Interfacing Ada with C

[Steve]

A different way of doing this:

In Ada you should be able to use Interfaces.C.Pointers and then declare your
procedure as follows:

  package Interface_Wide_String is
    new Interfaces.C.Pointers( Interfaces.C.size_T,
                               Interfaces.C.WChar_T,
                               Interfaces.C.WChar_Array,
                               Interfaces.C.Wide_Nul );

  procedure One( Name : in Interface_Wide_String.Pointer );
  pragma Export( C, One );


Within procedure "One" you can use:

    myName : Wide_String := Interfaces.C.To_Ada(
Interface_Wide_String.Value( Name ) );

If you need to look at the string as a wide string.

I haven't tested this, but I think it will work (it compiles anyway).

Steve
(The Duck)


"Paul Anderson" <notme@nowhere.com> wrote in message
news:3e9b28f8$1_4@newsfeed...
> Hi:
>
> I have a need to interface an Ada library with a C program.
> I am having trouble finding the best way to convert
> strings between the two worlds.
>
> I have a declaration:
>
>     procedure One(Name : in Wide_String);
>     pragma Export(C, One, "one");
>
> When I compile I get:
>
> foo.ads:29:42: warning: type of argument "One" is unconstrained array
> foo.ads:29:42: warning: foreign caller must pass bounds explicitly
>
> Fine, except how do I "pass bounds explicitly" when I call
> this function in C?  The prototype for this function in C
> would normally be:
>
>     void one(wide_string w);
>
> which doesn't have a slot for the bounds.  So where does it
> go?
>
> Alternatively, is there an different way of doing this that
> avoids this problem?
>
> I am using gnat-3.15p.
>
> Thanks,
>
> Paul.
>

Re: Interfacing Ada with C

[Steve]

"Steve" <nospam_steved94@attbi.com> wrote in message
news:pD3na.499811$sf5.816502@rwcrnsc52.ops.asp.att.net...
> A different way of doing this:
>
> In Ada you should be able to use Interfaces.C.Pointers and then declare
your
> procedure as follows:
>
>   package Interface_Wide_String is
>     new Interfaces.C.Pointers( Interfaces.C.size_T,
>                                Interfaces.C.WChar_T,
>                                Interfaces.C.WChar_Array,
>                                Interfaces.C.Wide_Nul );
[snip]
>
> I haven't tested this, but I think it will work (it compiles anyway).
>
> Steve
> (The Duck)
>
I created a small set of sources and tested my example (it does work).
Here's the source
for my test case:

------ File: clatest.c ------
#include <stdlib.h>

extern void One( wchar_t *text );
extern void adainit();
extern void adafinal();

int main(int argc, char* argv[])
{
    adainit();
    One( L"Hello from Ada" );
    adafinal();
    return 0;
}

------ File: One_Package.ads ------
with Interfaces.C;
with Interfaces.C.Pointers;

package One_Package is

  package Interface_Wide_String is
    new Interfaces.C.Pointers( Interfaces.C.size_T,
                               Interfaces.C.WChar_T,
                               Interfaces.C.WChar_Array,
                               Interfaces.C.Wide_Nul );

  procedure One( Name : in Interface_Wide_String.Pointer );
  pragma Export( C, One, "One" );

end One_Package;

------ File: One_Package.adb ------
with Ada.Wide_Text_Io;

package body One_Package is

  procedure One( Name : in Interface_Wide_String.Pointer ) is
  begin
    Ada.Wide_Text_Io.Put_Line( Interfaces.C.To_Ada(
Interface_Wide_String.Value( Name ) ) );
  end One;

end One_Package;

Steve
(The Duck)

Interfacing Ada with C

[Ada novice]

Hi,
    Having some background in C and in Ada, I would like to have some
examples on how to interface codes between these two languages. I
loved Ada but scientific computing libraries are not available. So I
was thinking to use an available numeric library in C to do some
mathematical operations such as calculations of eigenvalues and
eigenvectors from data in an Ada program. Ada does provide some
routines for eigenvalues and eigenvectors computations but they aren't
suitable for a non-symmetric matrix.

Information on interfacing Ada with C is scarce on the web and it
would help much if I can get some simple examples here from which I
can build up.

So in essence I'm looking for examples which illustrate how to pass
some data (e.g a matrix) from Ada to C, do some computations on the
matrix and return the results to the Ada environment. I understand
that a matrix can always be converted into a sequential row of data
which can be stored say in a file and then be passed to a C numerical
routine for some mathematical operation and then be returned back to
Ada likewise in the form of a data stored sequentially in a file.


Thanks
YC

Re: Interfacing Ada with C

[Robert A Duff]

Ada novice <posts@gmx.us> writes:

> Hi,
>     Having some background in C and in Ada, I would like to have some
> examples on how to interface codes between these two languages. I
> loved Ada but scientific computing libraries are not available. So I
> was thinking to use an available numeric library in C...

Or Fortran?

Look at 2.10, "Mixed Language Programming" in the GNAT
User's Guide.

- Bob

Re: Interfacing Ada with C

[Ada novice]

On Jul 24, 2:08 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
>
> Or Fortran?
>
> Look at 2.10, "Mixed Language Programming" in the GNAT
> User's Guide.
>
> - Bob

I have a good numeric library (IMSL from Visual Numerical) in C. As I
don't know Fortran at all, I prefer to use languages (C and Ada) that
I have some experiences with. Thanks I shall take a look at the GNAT
User's Guide.

YC

Re: Interfacing Ada with C

[Marco]

On Jul 24, 5:08 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Ada novice <po...@gmx.us> writes:
> > Hi,
> >     Having some background in C and in Ada, I would like to have some
> > examples on how to interface codes between these two languages. I
> > loved Ada but scientific computing libraries are not available. So I
> > was thinking to use an available numeric library in C...
>
> Or Fortran?
>
> Look at 2.10, "Mixed Language Programming" in the GNAT
> User's Guide.

http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/

Curiously they only mention C not Fortran

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

>     Having some background in C and in Ada, I would like to have some
> examples on how to interface codes between these two languages. I
> loved Ada but scientific computing libraries are not available. So I
> was thinking to use an available numeric library in C to do some
> mathematical operations such as calculations of eigenvalues and
> eigenvectors from data in an Ada program. Ada does provide some
> routines for eigenvalues and eigenvectors computations but they aren't
> suitable for a non-symmetric matrix.
>
> Information on interfacing Ada with C is scarce on the web and it
> would help much if I can get some simple examples here from which I
> can build up.

I think you have GNAT? Assuming that, you'll find their implementation
of Ada.Numerics.Generic_Real_Arrays in their Ada standard library;
you'll find this under the installation directory. On my Mac it's 
/opt/gnat-gpl-2010-x86_64/lib/gcc/x86_64-apple-darwin9.6.0/4.3.6/adainclude/a-ngrear.ad[sb]
but on a Windows machine it'll be something li
<install-dir>\<gnat-release>\lib\gcc\<architecture>\<gcc-release>\adainclude\a-ngrear.ad[sb]

This will lead you to System.Generic_Real_BLAS (s-gerebl.ad[sb]) and
System.Generic_Real_LAPACK (s-gerela.ad[sb]), which are interfaces to
the corresponding external libraries.


Not sure that these will fit your 'simple' criterion, though!

--S

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sat, 24 Jul 2010 04:57:53 -0700 (PDT), Ada novice wrote:

> So in essence I'm looking for examples which illustrate how to pass
> some data (e.g a matrix) from Ada to C,

Since C does not have arrays, especially 2D ones, you will have some custom
representation on the C side. It means that examples of bindings (there are
plenty of) won't help you unless you understand how you describe a
C-compatible object in Ada.

> do some computations on the
> matrix and return the results to the Ada environment.

Even more so, because C cannot return a compound object. Different C
libraries use different tricks to work around this.

I would propose reading RM B.3 and B.3.2. Another thing you have to
understand is the issue of flat arrays vs. arrays with a dope. The latter
cannot be used with C. Provided you know C well, the rest is simple.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

On Jul 24, 6:38 pm, Simon Wright <si...@pushface.org> wrote:

> but on a Windows machine it'll be something li
> <install-dir>\<gnat-release>\lib\gcc\<architecture>\<gcc-release>\adainclude\a-ngrear.ad[sb]
>
> This will lead you to System.Generic_Real_BLAS (s-gerebl.ad[sb]) and
> System.Generic_Real_LAPACK (s-gerela.ad[sb]), which are interfaces to
> the corresponding external libraries.
>
> Not sure that these will fit your 'simple' criterion, though!
>
> --S

Thanks. I've been able to locate these files under GNAT on my Windows
machine and read them. For eigensystems operations, only symmetric and
hermitian (complex-symmetric) matrices are allowed. I would like
however to be able to deal with a general non-symmetric matrix and
this I believe is not possible right now with Ada.

YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 24, 6:44 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Since C does not have arrays, especially 2D ones, you will have some custom
> representation on the C side. It means that examples of bindings (there are
> plenty of) won't help you unless you understand how you describe a
> C-compatible object in Ada.


Thanks for the "warnings". One way that I'm thinking is to write the
elements of the matrix sequentially into a file in Ada, read them into
C, put them into a matrix in C, do the appropriate computations in C
(with the IMSL C library), write the output in C in a file, and
finally importing them back into Ada again for further processing. Of
course, having several read-write operations is not computationally
time-efficient but this is a modest way to get starting. I know C at a
basic level and I'm not not an extensive user.

YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sat, 24 Jul 2010 11:04:18 -0700 (PDT), Ada novice wrote:

> On Jul 24, 6:44�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> Since C does not have arrays, especially 2D ones, you will have some custom
>> representation on the C side. It means that examples of bindings (there are
>> plenty of) won't help you unless you understand how you describe a
>> C-compatible object in Ada.
> 
> Thanks for the "warnings". One way that I'm thinking is to write the
> elements of the matrix sequentially into a file in Ada, read them into
> C, put them into a matrix in C, do the appropriate computations in C
> (with the IMSL C library), write the output in C in a file, and
> finally importing them back into Ada again for further processing. Of
> course, having several read-write operations is not computationally
> time-efficient but this is a modest way to get starting. I know C at a
> basic level and I'm not not an extensive user.

Why not to call IMSL directly from Ada? I looked shortly here

http://www.vni.com/products/imsl/c/TechSpecs/CNLspecs3MatrixStorage.php

it looks well documented and fairly designed. There should be no problem to
call it from Ada.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[tmoran]

> On Jul 24, 6:44=A0pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > Since C does not have arrays, especially 2D ones, you will have some cust=
> om
> > representation on the C side. It means that examples of bindings (there a=
> re
> > plenty of) won't help you unless you understand how you describe a
> > C-compatible object in Ada.
>
>
> Thanks for the "warnings". One way that I'm thinking is to write the
> elements of the matrix sequentially into a file in Ada, read them into
> C, put them into a matrix in C, do the appropriate computations in C
> (with the IMSL C library), write the output in C in a file, and
> finally importing them back into Ada again for further processing.

   Why do somersaults when you can just walk a few steps. As Dmitry
says, it really does depend on just what you are supposed to pass to
the C routine.  For instance, there's a very fast C routine to
calculate an FFT of a 256 element complex vector.  Using

  type Complex_Vectors is array(Integer range <>)
    of Ada.Numerics.Complex_Types.Complex;

  subtype Complex_256s is Complex_Vectors(1 .. 256);

  procedure fftc4_256(V : in out Complex_256s);
  pragma import(c, fftc4_256,"fftc4_256");

it can be called with

  X : Complex_256s;
  ...
  fftc4(X);

Hard to get any simpler.  If the C routine wants a pointer to an array of
pointers to rows, plus a couple of dimensions, that's a little harder.
But if the array is stored simply, and C expects the elements laid out the
same way as Ada, you can probably just pass in a pointer to the first
element in the array:

  type Matrix_Type is array(Integer Range <>, Integer range <>)
    of aliased Ada.Numerics.Complex_Types.Complex;

  type Pointer_To_Element is access all Ada.Numerics.Complex_Types.Complex;

  procedure C_Routine(M : in Pointer_To_Element;
                      Height, Width : in Interfaces.C.Unsigned);
  pragma import(C, C_Routine, "c_routine");

  M : Matrix_Type(1 .. 10, 0 .. 100);
  ...
  C_Routine(M(M'first(1), M'first(2))'access,
            Height => M'length(1),
            Width  => M'length(2));

For a whole lot of examples of Ada calling C, download the source for
CLAW (Class Library for Ada Windows) from www.rrsoftware.com

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> On Jul 24, 6:38 pm, Simon Wright <si...@pushface.org> wrote:
>
>> but on a Windows machine it'll be something li
>> <install-dir>\<gnat-release>\lib\gcc\<architecture>\<gcc-release>\adainclude\a-ngrear.ad[sb]
>>
>> This will lead you to System.Generic_Real_BLAS (s-gerebl.ad[sb]) and
>> System.Generic_Real_LAPACK (s-gerela.ad[sb]), which are interfaces to
>> the corresponding external libraries.
>>
>> Not sure that these will fit your 'simple' criterion, though!
>>
>> --S
>
> Thanks. I've been able to locate these files under GNAT on my Windows
> machine and read them. For eigensystems operations, only symmetric and
> hermitian (complex-symmetric) matrices are allowed. I would like
> however to be able to deal with a general non-symmetric matrix and
> this I believe is not possible right now with Ada.

No, but those files implement interfaces to those *parts of* the
external libraries BLAS and LAPACK that were necessary to implement the
Numerics annex.

It may be that the other parts of those libraries contain the features
you're looking for, in which case you have a head start on your own
implementation.

But, if not, you can at least see one approach to the job that you could
adopt for the external library of your choice.

Re: Interfacing Ada with C

[Ada novice]

Many thanks for all your inputs. I'll give you an example. Say we want
to compute the eigenvalues of this 3 X 3 matrix. The code in C (using
the IMSL library) is as follows:

#include <imsl.h>

int main()
{
int n = 3;
float a[] = {8.0, -1.0, -5.0,
-4.0, 4.0, -2.0,
18.0, -5.0, -7.0};
f_complex *eval;
/* Compute eigenvalues of A */
eval = imsl_f_eig_gen (n, a, 0);
/* Print eigenvalues */
imsl_c_write_matrix ("Eigenvalues", 1, n, eval, 0);
}


and the output on the screen (with some pretty formatting from
imsl_c_write_matrix) is:

       Eigenvalues
     1        2        3
( 2, 4) ( 2, -4) ( 1, 0)

Here, the first eigenvalue is 2 + 4i, the second one is 2 -4i and so
on. I found that f_complex (used in the line f_complex *eval) is
defined as follows:

typedef struct{
float re;
float im;
} f_complex;

and f_complex is for single-precision complex values (d_complex exists
for double-precision).

I have never worked with structures before and after some
"cursing" :), I could access the individual elements as follows:

printf(" %g\n", eval[0].re) will give me the real part of the first
eigenvalue i.e. 2.

What would the best way to interface this with Ada? The elements of my
matrix will be formed in Ada, then the matrix will be passed to C to
calculate the eigenvalues and then the latter passed back to Ada. The
size of my matrix will be fixed say 3 x 3. As a novice in Ada, I would
like to learn good programming practice and the best way is to use
codes and learn from experts here in Ada.

Thanks for your very kind help.
YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sun, 25 Jul 2010 05:21:44 -0700 (PDT), Ada novice wrote:

> What would the best way to interface this with Ada? The elements of my
> matrix will be formed in Ada, then the matrix will be passed to C to
> calculate the eigenvalues and then the latter passed back to Ada. The
> size of my matrix will be fixed say 3 x 3. As a novice in Ada, I would
> like to learn good programming practice and the best way is to use
> codes and learn from experts here in Ada.

Something like (not tested):

with Interfaces.C;  use Interfaces.C;
package IMSL is
   type Float_Matrix is -- Row-wise, packed/aligned
      array (Positive range <>, Positive range <>) of C_Float;
   pragma Convention (C, Float_Matrix);
   type F_Complex is record
      Re : C_Float;
      Im : C_Float;
   end record;
   pragma Convention (C, F_Complex);
   type Complex_Array is array (Positive range <>) of F_Complex;
   pragma Convention (C, Complex_Array);

   function F_Eig_Gen (Matrix : Float_Matrix) return Complex_Array;
 end IMSL;

package body IMSL is
   procedure Free (Ptr : System.Address);
   pragma Import (C, Free, "free");
      
   function F_Eig_Gen (Matrix : Float_Matrix) return Complex_Array is
   begin
      if Matrix'Length (1) /= Matrix'Length (2) then
         raise Constraint_Error;
      end if;
      declare -- No idea, how they report convergence/accuracy errors
         function Internal (N : Int; A : Address; Terminator : Address :=
            Null_Address) return Address;
         pragma Import (C, Internal, "imsl_f_eig_gen");
         Ptr  : Address := Internal
                           (  Matrix'Length (1),
                              Matrix (  Matrix'First (1),
                                        Matrix'First (2)
                                     )' Address
                           );
         Data : Complex_Array (1..Matrix'Length (1));
         for Data'Address use Ptr;
         pragma Import (Ada, Data);
         Result : Complex_Array := Data; -- Copy, we don't own that memory
      begin
         Free (Ptr);
         return Result;
      end;
   end F_Eig_Gen;
end IMSL;

Used as:

   Values : Complex_Array :=
      F_Eig_Gen
      (  (  ( 8.0,-1.0,-5.0),
            (-4.0, 4.0,-2.0),
            (18.0,-5.0,-7.0)  )
      );

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

Thanks a lot. On compilation I get:


     1. package body IMSL is
     2.    procedure Free (
     3.          Ptr : System.Address);
                       |
        >>> "System" is not visible
        >>> non-visible declaration at system.ads:40

     4.    pragma Import (C, Free, "free");
     5.
     6.    function F_Eig_Gen (
     7.          Matrix : Float_Matrix)
     8.      return Complex_Array is
     9.    begin
    10.       if Matrix'Length (1) /= Matrix'Length (2) then
    11.          raise Constraint_Error;
    12.       end if;
    13.       declare -- No idea, how they report convergence/accuracy
errors
    14.          function Internal (
                 |
        >>> missing body for "Internal"

    15.                N          : Int;
    16.                A          : Address;
                                    |
        >>> "Address" is not visible (more references follow)
        >>> non-visible declaration at system.ads:67

    17.                Terminator : Address := Null_Address)
                                               |
        >>> "Null_Address" is not visible
        >>> non-visible declaration at system.ads:69

    18.            return Address;
    19.          pragma Import (C, Internal, "imsl_f_eig_gen");
    20.          Ptr  : Address                                :=
Internal (Matrix'Length
    21.            (1), Matrix (Matrix'First (1), Matrix'First
(2))'Address);
    22.          Data : Complex_Array (1 .. Matrix'Length (1));
    23.          for Data'Address use Ptr;
    24.          pragma Import (Ada, Data);
    25.          Result : Complex_Array := Data;          -- Copy, we
don't own that memory
    26.       begin
    27.          Free (Ptr);
    28.          return Result;
    29.       end;
    30.    end F_Eig_Gen;
    31. end IMSL;

Compiling: c:/docume~1/testing/imsl.ads (source file time stamp:
2010-07-25 14:00:52)

     1. with Interfaces.C;
     2. use Interfaces.C;
     3. package IMSL is
     4.    type Float_Matrix is -- Row-wise, packed/aligned
     5.    array (Positive range <>, Positive range <>) of C_Float;
     6.    pragma Convention (C, Float_Matrix);
     7.    type F_Complex is
     8.       record
     9.          Re : C_Float;
    10.          Im : C_Float;
    11.       end record;
    12.    pragma Convention (C, F_Complex);
    13.    type Complex_Array is array (Positive range <>) of
F_Complex;
    14.    pragma Convention (C, Complex_Array);
    15.
    16.    function F_Eig_Gen (
    17.          Matrix : Float_Matrix)
    18.      return Complex_Array;
    19. end IMSL;

 31 lines: 7 errors


And what do I need on the C side?

Thanks
YC

Re: Interfacing Ada with C

[Ada novice]

I tested under the command prompt:

gcc -c imsl.adb

imsl.adb:3:16: "System" is not visible
imsl.adb:3:16: non-visible declaration at system.ads:40
imsl.adb:14:10: missing body for "Internal"
imsl.adb:16:29: "Address" is not visible (more references follow)
imsl.adb:16:29: non-visible declaration at system.ads:67
imsl.adb:17:40: "Null_Address" is not visible
imsl.adb:17:40: non-visible declaration at system.ads:69
gnatmake: "imsl.adb" compilation error


/YC

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> I tested under the command prompt:
>
> gcc -c imsl.adb
>
> imsl.adb:3:16: "System" is not visible
> imsl.adb:3:16: non-visible declaration at system.ads:40
> imsl.adb:14:10: missing body for "Internal"
> imsl.adb:16:29: "Address" is not visible (more references follow)
> imsl.adb:16:29: non-visible declaration at system.ads:67
> imsl.adb:17:40: "Null_Address" is not visible
> imsl.adb:17:40: non-visible declaration at system.ads:69
> gnatmake: "imsl.adb" compilation error

Then you need to add
   with System; use System;
to Dmitry's code.

I think Internal will sort itself out when you've fixed the type-related
withs as above.

Personally I'd have called Internal imsl_f_eig_gen if only so I'd
remember what was what! but YMMV.

Re: Interfacing Ada with C

[Ada novice]

On Jul 25, 4:26 pm, Simon Wright <si...@pushface.org> wrote:
>
> Then you need to add
>    with System; use System;
> to Dmitry's code.
>
> I think Internal will sort itself out when you've fixed the type-related
> withs as above.
>



Thanks. Now, imsl.ad(b,s) compile fine. Now to make the code work:

Do I need to have a C file also? The IMSL library won't activate by
itself.

I have a main file in Ada as testmatrix.adb:

with Imsl;
use Imsl;

procedure TestMatrix is

   Values : Complex_Array := F_Eig_Gen (((8.0, 1.0, 5.0), (4.0, 4.0,
2.0), (18.0, 5.0, 7.0)));

begin
   null;

end TestMatrix;

So I compile

gnatmake -c imsl.adb
gnatmake -c testmatrix.adb


And then work on the .ali files

gnatbind -n imsl.ali testmatrix.ali

I'll need a C file to do the linking. What to put in the C file?


Also
> Personally I'd have called Internal imsl_f_eig_gen if only so I'd
> remember what was what! but YMMV.

Do you mean renaming the procedure imsl.adb to Internal
imsl_f_eig_gen.adb . Sorry this part is not clear to me.

Thanks
YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sun, 25 Jul 2010 09:18:41 -0700 (PDT), Ada novice wrote:

> So I compile
> 
> gnatmake -c imsl.adb
> gnatmake -c testmatrix.adb

gnatmake testmatrix.adb -

> And then work on the .ali files
> 
> gnatbind -n imsl.ali testmatrix.ali
> 
> I'll need a C file to do the linking. What to put in the C file?

C files or library files?

With C files you do:

gcc -c c_file.c
gnatmake -c main_ada_file.adb
gnatbind main_ada_file.ali
gnatlink main_ada_file.ali c_file.o

With library files (import or object) it is simpler

gnatmake main_ada_file.adb --largs library_file.lib

(If you have only a shared library then it would require a bit more work.)

Better to create a gpr file for the binding and another one for the project
that uses them. With gpr files you can use GPS (GNAT IDE) as well as
command line:

gnatmake -Pproject_file.gpr

>> Personally I'd have called Internal imsl_f_eig_gen if only so I'd
>> remember what was what! but YMMV.
> 
> Do you mean renaming the procedure imsl.adb to Internal
> imsl_f_eig_gen.adb . Sorry this part is not clear to me.

Simon meant to name function Internal rather imsl_f_eig_gen. It is a matter
of style. I agree it would be better.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> Thanks. Now, imsl.ad(b,s) compile fine. Now to make the code work:
>
> Do I need to have a C file also? The IMSL library won't activate by
> itself.

> I have a main file in Ada as testmatrix.adb:
>
> with Imsl;
> use Imsl;
>
> procedure TestMatrix is
>
>    Values : Complex_Array := F_Eig_Gen (((8.0, 1.0, 5.0), (4.0, 4.0,
> 2.0), (18.0, 5.0, 7.0)));
>
> begin
>    null;
>
> end TestMatrix;
>
> So I compile
>
> gnatmake -c imsl.adb
> gnatmake -c testmatrix.adb

You don't need to use "-c". Try just

  gnatmake testmatrix.adb

It'll compile testmatrix.adb and imsl.adb for you, do the bind, and try
to do the link, but you'll get a linker error because it can't find
imsl_f_eig_gen.

Above, you wrote a C test:

   #include <imsl.h>

   int main()
   {
   int n = 3;
   float a[] = {8.0, -1.0, -5.0,
   -4.0, 4.0, -2.0,
   18.0, -5.0, -7.0};
   f_complex *eval;
   /* Compute eigenvalues of A */
   eval = imsl_f_eig_gen (n, a, 0);
   /* Print eigenvalues */
   imsl_c_write_matrix ("Eigenvalues", 1, n, eval, 0);
   }

and when you built that you must have told GCC where to find the IMSL
library: something like the "-limsl" below.

   gcc testprogram.c -o testprogram -limsl

You can do exactly the same with gnatmake:

   gnatmake testmatrix.adb -largs -limsl

Re: Interfacing Ada with C

[Ada novice]

On Jul 25, 7:06 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> C files or library files?
> With library files (import or object) it is simpler

> (If you have only a shared library then it would require a bit more work.)

It's a library file in IMSL named imslcmath_dll.lib

To use IMSL C library there are 2 steps:

1. Specify the location of the IMSL header files. It's  an "include"
directory in the IMSL directory.

2. Add the actual IMSL C library to the project. This IMSL C library
is called imslcmath_dll.lib which is in a "lib" directory in the IMSL
directory. There are other lib files, but this one is used for
numerical tasks.

I'm able to do the above easily with MVS2008/2010. The first step is
adding the "include" directory under Project > Configuration
Properties > C/C++ > General. The second step is just Project > Add
existing item.

I have only limited experience with GPS but let's give it a try:

First I create a folder and put the file imsl.ads, imsl.adb and
main_ada_file.adb (my testmatrix.adb). Then I create a project gpr,
specifying the main file and the source directory (containing our 3
files).

Then according to my step 1 from above, I add the folder "include"
from IMSL as also a source directory. So now I have 2 source
directories.

Then for step 2, I need to add the imslcmath_dll.lib file? How do I do
that in GPS? I can compile all 3 files imsl.ads, imsl.adb,
main_ada_file.adb in GPS. Then how do I proceed?

How do I do this in GPS:

> gnatmake main_ada_file.adb --largs library_file.lib

Sorry if I'm not that good enough to understand your explanations
quickly.

Thanks for your kind help and patience.
YC

Re: Interfacing Ada with C

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> You don't need to use "-c". Try just
>
>   gnatmake testmatrix.adb
>
> It'll compile testmatrix.adb and imsl.adb for you, do the bind, and try
> to do the link, but you'll get a linker error because it can't find
> imsl_f_eig_gen.
>
> Above, you wrote a C test:
[...]
> and when you built that you must have told GCC where to find the IMSL
> library: something like the "-limsl" below.
>
>    gcc testprogram.c -o testprogram -limsl
>
> You can do exactly the same with gnatmake:
>
>    gnatmake testmatrix.adb -largs -limsl

Of course, the above are all command-line-oriented and rather Unix-y at
that. Sorry I don't know how to deal with .lib files and .dlls, and
can't check any suggestions I might make out because I'm not running on
Windows ... I suspect others will be able to help more.

Re: Interfacing Ada with C

[Ada novice]

On Jul 25, 7:47 pm, Simon Wright <si...@pushface.org> wrote:
> Of course, the above are all command-line-oriented and rather Unix-y at
> that. Sorry I don't know how to deal with .lib files and .dlls, and
> can't check any suggestions I might make out because I'm not running on
> Windows ... I suspect others will be able to help more.


Thanks. Yes it'll be hard to do these things on the command line I
suppose. I hope as you said to get some help from some Windows guys
here...

YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sun, 25 Jul 2010 10:40:09 -0700 (PDT), Ada novice wrote:

> On Jul 25, 7:06�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> C files or library files?
> 
>> With library files (import or object) it is simpler
>>
> 
>> (If you have only a shared library then it would require a bit more work.)
>>
> 
> It's a library file in IMSL named imslcmath_dll.lib
> 
> To use IMSL C library there are 2 steps:
> 
> 1. Specify the location of the IMSL header files. It's  an "include"
> directory in the IMSL directory

You do not need include files

> 2. Add the actual IMSL C library to the project. This IMSL C library
> is called imslcmath_dll.lib which is in a "lib" directory in the IMSL
> directory. There are other lib files, but this one is used for
> numerical tasks.
> 
> I'm able to do the above easily with MVS2008/2010. The first step is
> adding the "include" directory under Project > Configuration
> Properties > C/C++ > General. The second step is hust Project > Add
> existing item.
> 
> 
> I have only limited experience with GPS but let's give it a try:
> 
> First I add create a folder and put the file imsl.ads, imsl.adb and
> main_ada_file.adb (my testmatrix.adb). Then I create a project gpr,
> specifying the main file and the source directory (containing our 3
> files).
> 
> Then according to my step 1 from above, I add the folder "include"
> from IMSL as also a source directory. So now I have 2 source
> directories.
> 
> Then for step 2, I need to add the imslcmath_dll.lib file? How do I do
> that in GPS? I can compile all 3 files imsl.ads, imsl.adb,
> main_ada_file.adb in GPS. Then how do I proceed?
> 
> How do I do this in GPS:
--------------------- imsl.ads
with Interfaces.C;  use Interfaces.C;
package IMSL is
   type Float_Matrix is -- Row-wise, packed/aligned
      array (Positive range <>, Positive range <>) of C_Float;
   pragma Convention (C, Float_Matrix);
   type F_Complex is record
      Re : C_Float;
      Im : C_Float;
   end record;
   pragma Convention (C, F_Complex);
   type Complex_Array is array (Positive range <>) of F_Complex;
   pragma Convention (C, Complex_Array);

   function F_Eig_Gen (Matrix : Float_Matrix) return Complex_Array;
end IMSL;
-------------------------- imsl.adb
with Interfaces.C;  use Interfaces.C;
with System;        use System;
package body IMSL is
   procedure Free (Ptr : System.Address);
   pragma Import (C, Free, "free");

   function F_Eig_Gen (Matrix : Float_Matrix) return Complex_Array is
   begin
      if Matrix'Length (1) /= Matrix'Length (2) then
         raise Constraint_Error;
      end if;
      declare
         function imsl_f_eig_gen
                  (N : Int; A : Address; Terminator : Address :=
Null_Address)
            return Address;
         pragma Import (C, imsl_f_eig_gen, "imsl_f_eig_gen");
         Ptr  : Address := imsl_f_eig_gen
                           (  Matrix'Length (1),
                              Matrix (  Matrix'First (1),
                                        Matrix'First (2)
                                     )' Address
                           );
         Data : Complex_Array (1..Matrix'Length (1));
         for Data'Address use Ptr;
         pragma Import (Ada, Data);
         Result : Complex_Array := Data; -- Copy, we don't own that memory
      begin
         Free (Ptr);
         return Result;
      end;
   end F_Eig_Gen;
end IMSL;
------------------------------------ imsl.gpr
project IMSL is
   for Source_Files use ("imsl.adb", "imsl.ads");
   package Linker is
      for Default_Switches ("ada") use ("imslcmath_dll.lib");
   end Linker;
end IMSL;
----------------------------------- test.adb
with Ada.Text_IO;   use Ada.Text_IO;
with IMSL;          use IMSL;
with Interfaces.C;  use Interfaces.C;
procedure Test is
   Values : Complex_Array :=
      F_Eig_Gen
      (  (  ( 8.0,-1.0,-5.0),
            (-4.0, 4.0,-2.0),
            (18.0,-5.0,-7.0)  )
      );
begin
   for Index in Values'Range loop
      Put_Line
      (  '('
      &  C_Float'Image (Values (Index).Re)
      &  " ,"
      &  C_Float'Image (Values (Index).Im)
      &  ')'
      );
   end loop;
end Test;
------------------------------------ test.gpr
with "imsl.gpr";
project Test is
   for Source_Files use ("test.adb");
   for Main use ("test.adb");
   package Linker renames IMSL.Linker;
end Test;

put "imslcmath_dll.lib into the same directory or change its path in the
project files. Make sure that the DLL is in the search path when you start
the program.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

On Jul 25, 8:26 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> ------------------------------------ imsl.gpr
> project IMSL is
>    for Source_Files use ("imsl.adb", "imsl.ads");
>    package Linker is
>       for Default_Switches ("ada") use ("imslcmath_dll.lib");
>    end Linker;
> end IMSL;


How to create imsl.gpr? I created a folder containing imsl.ads,
imsl.adb and test.adb. I specify test.adb as the main file. GPS asks
for a main file. The imsl.gpr that I get is:

project Imsl is

   for Object_Dir use "C:\Documents and Settings\yc";
   for Source_Dirs use (".\**");
   for Main use ("test.adb");

end Imsl;


and if I paste your imsl.gpr into this, GPS crashes.

YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sun, 25 Jul 2010 11:52:44 -0700 (PDT), Ada novice wrote:

> On Jul 25, 8:26�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> ------------------------------------ imsl.gpr
>> project IMSL is
>> � �for Source_Files use ("imsl.adb", "imsl.ads");
>> � �package Linker is
>> � � � for Default_Switches ("ada") use ("imslcmath_dll.lib");
>> � �end Linker;
>> end IMSL;
> 
> 
> How to create imsl.gpr?

Using notepad.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

I've created both imsl.gpr and test.gpr wih notepad. Now in a folder I
have

imsl.gpr
test.gpr
imsl.ads
imsl.adb
imslcmath_dll.lib

When I open imsl.gpr in GPS, I can't compile and it complains: No
valid file selected. This is because no main file was specified.
Please let me know how to go about with the compilation.

Thanks
YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sun, 25 Jul 2010 12:13:19 -0700 (PDT), Ada novice wrote:

> I've created both imsl.gpr and test.gpr wih notepad. Now in a folder I
> have
> 
> imsl.gpr
> test.gpr
> imsl.ads
> imsl.adb
> imslcmath_dll.lib
> 
> When I open imsl.gpr in GPS, I can't compile and it complains: No
> valid file selected. This is because no main file was specified.
> Please let me know how to go about with the compilation.

You have to open test.gpr.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

GOOD NEWS. It works fine. I tested with another matrix also and it
works as well. I assume that I didn't have to put the "include"
directory since IMSL is already on my Windows environment path.


On Jul 25, 9:19 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> You have to open test.gpr.
>

Yes you're right. I only thought that imsl.ad(b,s) should be compiled
first.


Thank you very much all of you especially Dmitry and Simon for your
very kind help. I'll need to study the code that you provided.


Thanks again.

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Sun, 25 Jul 2010 12:28:44 -0700 (PDT), Ada novice wrote:

> Yes you're right. I only thought that imsl.ad(b,s) should be compiled
> first.

It will as needed, i.e. when used in a project that produces something.

At some point later when you decide to turn your bindings into a library
(object/static and/or shared), you could change the IMSL project so that it
would produce that library. Then it will become compilable.

> Thank you very much all of you especially Dmitry and Simon for your
> very kind help. I'll need to study the code that you provided.

You are welcome. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> Many thanks for all your inputs. I'll give you an example. Say we want
> to compute the eigenvalues of this 3 X 3 matrix. The code in C (using
> the IMSL library) is as follows:
[...]
> What would the best way to interface this with Ada? The elements of my
> matrix will be formed in Ada, then the matrix will be passed to C to
> calculate the eigenvalues and then the latter passed back to Ada. The
> size of my matrix will be fixed say 3 x 3. As a novice in Ada, I would
> like to learn good programming practice and the best way is to use
> codes and learn from experts here in Ada.

I've encoded a general complex eigenvalues function, interfacing to the
LAPACK procedure zgeev, starting from a demo at
http://www.physics.oregonstate.edu/~rubin/nacphy/lapack/codes/eigen-c.html
& copying bits and pieces from within the GNAT implementation of
Ada.Numerics.Generic_Complex_Arrays.

Find it at http://public.me.com/simon.j.wright (folder numerics).

NB1 LAPACK is a Fortran code, hence the need to transpose the matrix.

NB2 the compilation gives warnings .. 

   $ gnatmake test_zgeev.adb
   gcc -c test_zgeev.adb
   test_zgeev.adb:9:06: warning: "Interfaces.Fortran.BLAS" is an internal GNAT unit
   test_zgeev.adb:9:06: warning: use of this unit is non-portable and version-dependent
   test_zgeev.adb:10:06: warning: "Interfaces.Fortran.LAPACK" is an internal GNAT unit
   test_zgeev.adb:10:06: warning: use of this unit is non-portable and version-dependent
   gnatbind -x test_zgeev.ali
   gnatlink test_zgeev.ali
   $

However, (a) one could always write ones own versions, (b) the results
are the same with GNAT GPL 2010 and GCC 4.5.0, (c) the output looks good
(from your inputs) ..

   $ ./test_zgeev 
    2.00000000000000E+00  4.00000000000000E+00
    2.00000000000000E+00 -4.00000000000000E+00
    9.99999999999996E-01  2.07319734774360E-16

I get the strong impression that to know what the arguments of the BLAS
& LAPACK subprograms are you have to buy the book or read the code!


This all worked without any need for additional link-time arguments on
Mac OS X, but YMMV on Windows. If not, I *think* that if you with
Ada.Numerics.Long_Complex_Arrays (no need to use anything from it) that
would be enough to bring in the necessary libraries.

Re: Interfacing Ada with C

[John B. Matthews]

In article <m2iq43rvv1.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:

> I've encoded a general complex eigenvalues function, interfacing to the
> LAPACK procedure zgeev, starting from a demo at
> http://www.physics.oregonstate.edu/~rubin/nacphy/lapack/codes/eigen-c.html
> & copying bits and pieces from within the GNAT implementation of
> Ada.Numerics.Generic_Complex_Arrays.
> 
> Find it at http://public.me.com/simon.j.wright (folder numerics).

Exemplary!

> NB1 LAPACK is a Fortran code, hence the need to transpose the matrix.
> 
> NB2 the compilation gives warnings .. 
> 
> $ gnatmake test_zgeev.adb
> gcc -c test_zgeev.adb
> test_zgeev.adb:9:06: warning: "Interfaces.Fortran.BLAS" is an internal GNAT unit
> test_zgeev.adb:9:06: warning: use of this unit is non-portable and version-dependent
> test_zgeev.adb:10:06: warning: "Interfaces.Fortran.LAPACK" is an internal GNAT unit
> test_zgeev.adb:10:06: warning: use of this unit is non-portable and version-dependent

For convenience, the warnings may be suppressed:

pragma Warnings("I");

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Ada novice]

On Jul 25, 10:04 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> At some point later when you decide to turn your bindings into a library
> (object/static and/or shared), you could change the IMSL project so that it
> would produce that library. Then it will become compilable.
>

Would you be kind enough to elaborate on your above comments a little
more?

Thanks
YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 26, 1:21 am, Simon Wright <si...@pushface.org> wrote:

> I've encoded a general complex eigenvalues function, interfacing to the
> LAPACK procedure zgeev, starting from a demo athttp://www.physics.oregonstate.edu/~rubin/nacphy/lapack/codes/eigen-c...
> & copying bits and pieces from within the GNAT implementation of
> Ada.Numerics.Generic_Complex_Arrays.

> Find it athttp://public.me.com/simon.j.wright(folder numerics).

Thank you very much for your commendable efforts. This is a very good
example to demonstrate how Ada can be binded with LAPACK.

>(b) the results
> are the same with GNAT GPL 2010 and GCC 4.5.0, (c) the output looks good
> (from your inputs) ..

>    $ ./test_zgeev
>     2.00000000000000E+00  4.00000000000000E+00
>     2.00000000000000E+00 -4.00000000000000E+00
>     9.99999999999996E-01  2.07319734774360E-16

I have Win XP and gcc (GCC) 4.3.6 20100603 for GNAT GPL 2010
(20100603). I get slightly different output:

 1.99999999999999E+00  3.99999999999999E+00
 2.00000000000000E+00 -4.00000000000000E+00
 1.00000000000000E+00 -3.45920620709768E-16

Your GCC version is more recent than mine. Maybe this is causing the
discrepancies or maybe it's because of your different OS. Did you
install your GCC separately? I got mine bundled with the GNAT GPL
2010.

>I get the strong impression that to know what the arguments of the BLAS
>& LAPACK subprograms are you have to buy the book or read the code!

On a side note, there's this book:

Handbook for Automatic Computation: Volume 2: Linear Algebra
(Grundlehren der mathematischen Wissenschaften) by John H. Wilkinson,
C. Reinsch, Alston S. Householder, and Friedrich L. B

which has lots of test matrix cases to check whether algorithms are
performing correctly.

> This all worked without any need for additional link-time arguments on
> Mac OS X, but YMMV on Windows. If not, I *think* that if you with
> Ada.Numerics.Long_Complex_Arrays (no need to use anything from it) that
> would be enough to bring in the necessary libraries.

It works fine on Windows too without anything to add. And I get the
same
compilation warnings.

YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Mon, 26 Jul 2010 06:40:49 -0700 (PDT), Ada novice wrote:

> On Jul 25, 10:04�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> At some point later when you decide to turn your bindings into a library
>> (object/static and/or shared), you could change the IMSL project so that it
>> would produce that library. Then it will become compilable.
> 
> Would you be kind enough to elaborate on your above comments a little
> more?

Project IMSL as written does not describe any entity to build. It does a
subcomponent of such an entity, like the test project, which defines an
executable. An executable can be built, a component cannot.

When bindings are mature and need to be redistributed, deployed, become a
part of some large project like Linux distribution with it specific
requirements etc, there is a need to pack the bindings code into a
pre-built library, static, shared or both. A project that describes such a
library is compilable, because a library has to be built. A library would
most likely have at least two different projects:

1. compilable "implementation" used by the library developer to build the
library from the sources.

2. non-compilable "interface" for library users who use the built library
in their projects. They don't need to compile the sources. They will use
*.ads, *.ali, *.lib/a files instead.

A good thing about Ada and gnatmake/grpbuid is that it is fairly simple to
do these things compared with the horrific make/configure.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[sjw]

On Jul 26, 12:21 am, Simon Wright <si...@pushface.org> wrote:

> I get the strong impression that to know what the arguments of the BLAS
> & LAPACK subprograms are you have to buy the book or read the code!

Aha! http://www.cs.colorado.edu/~jessup/lapack/documentation.html ..
OK, the subprogram documentation is in the form of UNIX man pages ..

Re: Interfacing Ada with C

[Ada novice]

On Jul 26, 4:52 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

- Hide quoted text -
- Show quoted text -
> On Mon, 26 Jul 2010 06:40:49 -0700 (PDT), Ada novice wrote:
> > Would you be kind enough to elaborate on your above comments a little
> > more?

> Project IMSL as written does not describe any entity to build. It does a
> subcomponent of such an entity, like the test project, which defines an
> executable. An executable can be built, a component cannot.

> When bindings are mature and need to be redistributed, deployed, become a
> part of some large project like Linux distribution with it specific
> requirements etc, there is a need to pack the bindings code into a
> pre-built library, static, shared or both. A project that describes such a
> library is compilable, because a library has to be built. A library would
> most likely have at least two different projects:

> 1. compilable "implementation" used by the library developer to build the
> library from the sources.

> 2. non-compilable "interface" for library users who use the built library
> in their projects. They don't need to compile the sources. They will use
> *.ads, *.ali, *.lib/a files instead.

> A good thing about Ada and gnatmake/grpbuid is that it is fairly simple to
> do these things compared with the horrific make/configure.

Thanks. But the library would not be portable to another machine as we
need more than the file imslcmath_dll.lib . IMSL runs because it's
on my Windows environment path. I hope that I'm understanding you
right.

As an engineer in another field, it's hard to grasp all that you're
saying but I hope with time I'll understand better :). Can you
recommend books/publications that discuss similar ideas that you have
been mentioning?

YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Mon, 26 Jul 2010 10:08:09 -0700 (PDT), Ada novice wrote:

> On Jul 26, 4:52�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Mon, 26 Jul 2010 06:40:49 -0700 (PDT), Ada novice wrote:
> 
>>> Would you be kind enough to elaborate on your above comments a little
>>> more?
>>
>> Project IMSL as written does not describe any entity to build. It does a
>> subcomponent of such an entity, like the test project, which defines an
>> executable. An executable can be built, a component cannot.
>>
>> When bindings are mature and need to be redistributed, deployed, become a
>> part of some large project like Linux distribution with it specific
>> requirements etc, there is a need to pack the bindings code into a
>> pre-built library, static, shared or both. A project that describes such a
>> library is compilable, because a library has to be built. A library would
>> most likely have at least two different projects:
>>
>> 1. compilable "implementation" used by the library developer to build the
>> library from the sources.
>>
>> 2. non-compilable "interface" for library users who use the built library
>> in their projects. They don't need to compile the sources. They will use
>> *.ads, *.ali, *.lib/a files instead.
>>
>> A good thing about Ada and gnatmake/grpbuid is that it is fairly simple to
>> do these things compared with the horrific make/configure.
> 
> Thanks. But the library would not be portable to another machine as we
> need more than the file imslcmath_dll.lib . IMSL runs because it's
> on my Windows environment path.

For deployment of the run-time you need a DLL, assuming that
imslcmath_dll.lib is an import library of.

The library build project is about how to create such a library from your
code if you are not going to distribute the sources.

> As an engineer in another field, it's hard to grasp all that you're
> saying but I hope with time I'll understand better :). Can you
> recommend books/publications that discuss similar ideas that you have
> been mentioning?

You may not believe it, but the GNAT User's Guide describes most, if not
all of that:

http://gcc.gnu.org/onlinedocs/gnat_ugn_unw

(Software engineers used to say, if nothing else helped, try to read the
manual... (:-))

You can also read this one to get the idea of Ada software distribution in
the form libraries. It is actually for Linux, but Ada is OS-agnostic:

http://people.debian.org/~lbrenta/debian-ada-policy.html

Specifically everything about GNAT project files:

http://www.adacore.com/wp-content/files/auto_update/gprbuild-docs/html/gprbuild_ug.html

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

Thanks, Dmitry for all these valuable links.

YC

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:
> On Jul 26, 1:21 am, Simon Wright <si...@pushface.org> wrote:
>
>> I've encoded a general complex eigenvalues function, interfacing to the
>> LAPACK procedure zgeev

> Thank you very much for your commendable efforts. This is a very good
> example to demonstrate how Ada can be binded with LAPACK.

Well, it's a start!

>>(b) the results
>> are the same with GNAT GPL 2010 and GCC 4.5.0, (c) the output looks good
>> (from your inputs) ..
>>
>>    $ ./test_zgeev
>>     2.00000000000000E+00  4.00000000000000E+00
>>     2.00000000000000E+00 -4.00000000000000E+00
>>     9.99999999999996E-01  2.07319734774360E-16
>
>
> I have Win XP and gcc (GCC) 4.3.6 20100603 for GNAT GPL 2010
> (20100603). I get slightly different output:
>
>  1.99999999999999E+00  3.99999999999999E+00
>  2.00000000000000E+00 -4.00000000000000E+00
>  1.00000000000000E+00 -3.45920620709768E-16
>
> Your GCC version is more recent than mine. Maybe this is causing the
> discrepancies or maybe it's because of your different OS. Did you
> install your GCC separately? I got mine bundled with the GNAT GPL
> 2010.

Mine was part of GNAT GPL 2010, but on Mac OS X LAPACK and BLAS come
with the OS; I suspect that on Windows they don't.

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Mon, 26 Jul 2010 20:46:10 +0100, Simon Wright wrote:

> Ada novice <posts@gmx.us> writes:
>> On Jul 26, 1:21�am, Simon Wright <si...@pushface.org> wrote:

>>>(b) the results
>>> are the same with GNAT GPL 2010 and GCC 4.5.0, (c) the output looks good
>>> (from your inputs) ..
>>>
>>> � �$ ./test_zgeev
>>> � � 2.00000000000000E+00 �4.00000000000000E+00
>>> � � 2.00000000000000E+00 -4.00000000000000E+00
>>> � � 9.99999999999996E-01 �2.07319734774360E-16
>>
>>
>> I have Win XP and gcc (GCC) 4.3.6 20100603 for GNAT GPL 2010
>> (20100603). I get slightly different output:
>>
>>  1.99999999999999E+00  3.99999999999999E+00
>>  2.00000000000000E+00 -4.00000000000000E+00
>>  1.00000000000000E+00 -3.45920620709768E-16
>>
>> Your GCC version is more recent than mine. Maybe this is causing the
>> discrepancies or maybe it's because of your different OS. Did you
>> install your GCC separately? I got mine bundled with the GNAT GPL
>> 2010.
> 
> Mine was part of GNAT GPL 2010, but on Mac OS X LAPACK and BLAS come
> with the OS; I suspect that on Windows they don't.

It makes little sense to compare decimal representations, which aren't
exact on most machines. Then before comparing any results, they should be
rounded to the accuracy of the given method.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

On Jul 26, 9:46 pm, Simon Wright <si...@pushface.org> wrote:

>
> Mine was part of GNAT GPL 2010, but on Mac OS X LAPACK and BLAS come
> with the OS; I suspect that on Windows they don't.

No they don't come pre-installed with windows. This means that the
"mathematical functions" that I have from BLAS /LAPACK in the GNAT
folder is the subset of the full versions that you have on your MAC OS
X.

YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 26, 10:39 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> It makes little sense to compare decimal representations, which aren't
> exact on most machines. Then before comparing any results, they should be
> rounded to the accuracy of the given method.
>

The discrepancies in the numbers are really insignificant. Yes you're
right about the decimal representations which are not machine
independent.

YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 25, 7:06 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

>
> With C files you do:
>
> gcc -c c_file.c
> gnatmake -c main_ada_file.adb
> gnatbind main_ada_file.ali
> gnatlink main_ada_file.ali c_file.o
>

I was wondering if it's possible to do the above in GPS through
"projects" as we did with the library (where 2 projects were created).
It would be great if the above could be done within GPS.

Thanks
YC

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Mon, 26 Jul 2010 22:50:48 -0700 (PDT), Ada novice wrote:

> On Jul 25, 7:06�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>> With C files you do:
>>
>> gcc -c c_file.c
>> gnatmake -c main_ada_file.adb
>> gnatbind main_ada_file.ali
>> gnatlink main_ada_file.ali c_file.o
> 
> I was wondering if it's possible to do the above in GPS through
> "projects" as we did with the library (where 2 projects were created).
> It would be great if the above could be done within GPS.

It is possible if you have GPS/gprbuild with multiple languages support:
You specify in your project file:

   for Languages use ("Ada", "C");

(I don't know if GNAT GPL 2010 already includes this. GNAT Pro does and, I
guess that Debian Linux GNAT does it as well)

For further information see GPRbuid User's Guide:

http://www.adacore.com/wp-content/files/auto_update/gprbuild-docs/html/gprbuild_ug.html

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Georg Bauhaus]

On 7/27/10 9:27 AM, Dmitry A. Kazakov wrote:

> For further information see GPRbuid User's Guide:
>
> http://www.adacore.com/wp-content/files/auto_update/gprbuild-docs/html/gprbuild_ug.html
>

Help Menu -> Gprbuild -> Gprbuild User's Guide

--
Warum in die Ferne schweifen?
Sieh, das Gute liegt so nah!

Re: Interfacing Ada with C

[Peter Hermann]

Ada novice <posts@gmx.us> wrote:
[snip]
 

YC,
Ada novice <posts@gmx.us> seems to be anonymous.
My Email did not arrive, as expected.
Maybe you open your identity to TEAM-ADA@LISTSERV.ACM.ORG
at least?
ph

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> On Jul 26, 9:46 pm, Simon Wright <si...@pushface.org> wrote:
>
>>
>> Mine was part of GNAT GPL 2010, but on Mac OS X LAPACK and BLAS come
>> with the OS; I suspect that on Windows they don't.
>
> No they don't come pre-installed with windows. This means that the
> "mathematical functions" that I have from BLAS /LAPACK in the GNAT
> folder is the subset of the full versions that you have on your MAC OS
> X.

Not quite, I think.

BLAS/LAPACK are what they are, I don't for a moment suppose that AdaCore
have gone to the trouble of subsetting them to suit their
needs. Instead, they've implemented Annex G using bindings to
BLAS/LAPACK, and Annex G only requires a limited set of bindings.

Remember, I provided a binding to a LAPACK subroutine that isn't used
by the Annex G bindings, and it worked for you!

Re: Interfacing Ada with C

[Ada novice]

On Jul 27, 7:33 pm, Simon Wright <si...@pushface.org> wrote:

> Not quite, I think.
>
> BLAS/LAPACK are what they are, I don't for a moment suppose that AdaCore
> have gone to the trouble of subsetting them to suit their
> needs. Instead, they've implemented Annex G using bindings to
> BLAS/LAPACK, and Annex G only requires a limited set of bindings.
>
> Remember, I provided a binding to a LAPACK subroutine that isn't used
> by the Annex G bindings, and it worked for you!

I get your point. So maybe the full set exists. I need to take a look
closer at i-forbla.ad(b,s), i-forlap.ads which refer to the BLAS/
LAPACK in the GNAT >....> Adainclude folder.

Thanks.
YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 27, 9:43 am, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:

> Help Menu -> Gprbuild -> Gprbuild User's Guide

Thanks for pointing out this link in GPS. I thought it was only
available online.

YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 27, 9:27 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 26 Jul 2010 22:50:48 -0700 (PDT), Ada novice wrote:
> > On Jul 25, 7:06 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> >> With C files you do:
>
> >> gcc -c c_file.c
> >> gnatmake -c main_ada_file.adb
> >> gnatbind main_ada_file.ali
> >> gnatlink main_ada_file.ali c_file.o
>
> > I was wondering if it's possible to do the above in GPS through
> > "projects" as we did with the library (where 2 projects were created).
> > It would be great if the above could be done within GPS.
>
> It is possible if you have GPS/gprbuild with multiple languages support:
> You specify in your project file:
>
>    for Languages use ("Ada", "C");
>
> (I don't know if GNAT GPL 2010 already includes this. GNAT Pro does and, I
> guess that Debian Linux GNAT does it as well)
>

Thanks. I think so. In project properties (GPS in GNAT GPL), one can
specify languages such as Ada, C..Fortran etc. So I need to test it.

Yes, I'll need to llok into the GPRbuild user Guide.

YC

Re: Interfacing Ada with C

[Ada novice]

On Jul 27, 2:24 pm, Peter Hermann <h...@h.de> wrote:
> YC,
> Ada novice <po...@gmx.us> seems to be anonymous.
> My Email did not arrive, as expected.

I have just checked my email at GMX and saw that you have written to
me. I have replied from my GMX account.

> Maybe you open your identity to TEAM-...@LISTSERV.ACM.ORG
> at least?
> ph

I don't know what settings I have but my email address is reachable of
course. How do I open to TEAM-...@LISTSERV.ACM.ORG ?

Thanks.

YC

team-ada (was e: Interfacing Ada with C

[Peter Hermann]

everybody reading comp.lang.ada is invited for
subscription  to  the  TEAM-ADA list
  (Team  Ada:  Ada  Programming Language Advocacy)

I am afraid I forgot how...

Re: Interfacing Ada with C

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> Ada novice <posts@gmx.us> writes:
>> On Jul 26, 1:21 am, Simon Wright <si...@pushface.org> wrote:
>>
>>> I've encoded a general complex eigenvalues function, interfacing to the
>>> LAPACK procedure zgeev
>
>> Thank you very much for your commendable efforts. This is a very good
>> example to demonstrate how Ada can be binded with LAPACK.
>
> Well, it's a start!

I've taken the plunge and started a SourceForge project for this. It's
at http://sourceforge.net/projects/gnat-math-extn/ -- under "Ada 2005
Math Extensions", click on [Develop] then on [Code].

I've chosen to use Mercurial (Hg) as the VCS, mainly to get a real-world
feel for using a DVCS (Distributed Version Control System). To downoad
the code, you'll need to install Hg - http://mercurial.selenic.com/ -
because I haven't actually made a code release yet!

If anyone feels moved to join in, just say (of course you need a SF
account to update the SF repository, but with Hg it should be possible
to work via patchsets .. )

For interest, the test program now looks like

   with Ada.Text_IO; use Ada.Text_IO;
   with Ada.Numerics.Generic_Real_Arrays;
   with Ada.Numerics.Generic_Complex_Types;
   with Ada.Numerics.Generic_Complex_Arrays.Extensions;

   procedure Test_Extensions is

      package Real_Arrays
      is new Ada.Numerics.Generic_Real_Arrays (Long_Float);
      package Complex_Types
      is new Ada.Numerics.Generic_Complex_Types (Long_Float);
      package Complex_Arrays
      is new Ada.Numerics.Generic_Complex_Arrays (Real_Arrays,
                                                  Complex_Types);
      package Extensions
      is new Complex_Arrays.Extensions;

      use Complex_Arrays;

      Input : Complex_Matrix (1 .. 3, 1 .. 3);
      Result : Complex_Vector (1 .. Input'Length (1));

   begin

      --  Values in yc's example
      Input := (((8.0, 0.0), (-1.0, 0.0), (-5.0, 0.0)),
                ((-4.0, 0.0), (4.0, 0.0), (-2.0, 0.0)),
                ((18.0, 0.0), (-5.0, 0.0), (-7.0, 0.0)));

      Result := Extensions.Eigenvalues (Input);

      for J in Result'Range loop
         Put_Line (Long_Float'Image (Result (J).Re)
                     & " "
                     & Long_Float'Image (Result (J).Im));
      end loop;

   end Test_Extensions;

(results as before)

Re: Interfacing Ada with C

[Ada novice]

On Jul 29, 12:26 am, Simon Wright <si...@pushface.org> wrote:
> Simon Wright <si...@pushface.org> writes:
> > Ada novice <po...@gmx.us> writes:
> >> On Jul 26, 1:21 am, Simon Wright <si...@pushface.org> wrote:
>
> >>> I've encoded a general complex eigenvalues function, interfacing to the
> >>> LAPACK procedure zgeev
>
> >> Thank you very much for your commendable efforts. This is a very good
> >> example to demonstrate how Ada can be binded with LAPACK.
>
> > Well, it's a start!
>
> I've taken the plunge and started a SourceForge project for this. It's
> athttp://sourceforge.net/projects/gnat-math-extn/-- under "Ada 2005
> Math Extensions", click on [Develop] then on [Code].
>
> I've chosen to use Mercurial (Hg) as the VCS, mainly to get a real-world
> feel for using a DVCS (Distributed Version Control System). To downoad
> the code, you'll need to install Hg -http://mercurial.selenic.com/-
> because I haven't actually made a code release yet!
>
> If anyone feels moved to join in, just say (of course you need a SF
> account to update the SF repository, but with Hg it should be possible
> to work via patchsets .. )
>

This is great news. I would be happy to join the project. I'm not a
programmer as you know :). I'm a mechanical engineer and have a sound
background in numerical methods and use them a lot. I would be happy
to contribute in testing, feedback and coming up with suggestions.

YC

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> On Jul 29, 12:26 am, Simon Wright <si...@pushface.org> wrote:
>> Simon Wright <si...@pushface.org> writes:
>> > Ada novice <po...@gmx.us> writes:
>> >> On Jul 26, 1:21 am, Simon Wright <si...@pushface.org> wrote:
>>
>> >>> I've encoded a general complex eigenvalues function, interfacing to the
>> >>> LAPACK procedure zgeev
>>
>> >> Thank you very much for your commendable efforts. This is a very good
>> >> example to demonstrate how Ada can be binded with LAPACK.
>>
>> > Well, it's a start!
>>
>> I've taken the plunge and started a SourceForge project for
>> this. It's at http://sourceforge.net/projects/gnat-math-extn/ --
>> under "Ada 2005 Math Extensions", click on [Develop] then on [Code].
>>
[...]
>>
>> If anyone feels moved to join in, just say (of course you need a SF
>> account to update the SF repository, but with Hg it should be possible
>> to work via patchsets .. )
>
> This is great news. I would be happy to join the project. I'm not a
> programmer as you know :). I'm a mechanical engineer and have a sound
> background in numerical methods and use them a lot. I would be happy
> to contribute in testing, feedback and coming up with suggestions.

The project needs someone with a sound background in numerical methods,
and feedback/suggestions are always more than welcome. So do join...

Re: Interfacing Ada with C

[Ada novice]

On Jul 29, 9:14 pm, Simon Wright <si...@pushface.org> wrote:

> The project needs someone with a sound background in numerical methods,
> and feedback/suggestions are always more than welcome. So do join...

Thanks. I'm actually a PhD student in mechanical engineering. The good
news is that I have access to many books on numerical methods. So I
will be happy to help you with the testing and provide suggestions as
to which algorithms can be considered better and are more used than
others. Robust algorithms are usually well documented in the
literature.

I don't have experience with mercurial but I have used one VCS
software namely Tortoise SVN locally on my machine for some of my
LaTeX documents. Right now I don't know how to download your test
codes using mercurial. I have though an account at SF. Maybe I can
wait till you have a public release.

Godspeed
YC

Re: Interfacing Ada with C

[John B. Matthews]

In article <m21vamrtg8.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:

> >> I've taken the plunge and started a SourceForge project for this. 
> >> It's at http://sourceforge.net/projects/gnat-math-extn/ -- under 
> >> "Ada 2005 Math Extensions", click on [Develop] then on [Code].

Is it possible to enable mercurial browsing in the [Code] tab?

<http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[sjw]

On Jul 30, 2:46 am, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article <m21vamrtg8....@pushface.org>,
>  Simon Wright <si...@pushface.org> wrote:
>
> > >> I've taken the plunge and started a SourceForge project for this.
> > >> It's athttp://sourceforge.net/projects/gnat-math-extn/-- under
> > >> "Ada 2005 Math Extensions", click on [Develop] then on [Code].
>
> Is it possible to enable mercurial browsing in the [Code] tab?
>
> <http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial>
>
> --
> John B. Matthews
> trashgod at gmail dot com
> <http://sites.google.com/site/drjohnbmatthews>

It is? (I tried it when not logged in, no problem ..)

Try here: http://gnat-math-extn.hg.sourceforge.net/hgweb/gnat-math-extn/
& click on gnat-math-extn in the Name column?

Re: Interfacing Ada with C

[Ada novice]

On Jul 30, 11:09 am, sjw <simon.j.wri...@mac.com> wrote:

> Try here:http://gnat-math-extn.hg.sourceforge.net/hgweb/gnat-math-extn/
> & click on gnat-math-extn in the Name column?


Thanks for this link. When I try to download the 3 files there (2 adb
and 1 ads) I get the files as files with xml codes in them. I guess
there must be a way to get the clean adb and ads files. I'm not
familiar with mercurial. Can someone please indicate how to go about?


Thanks
YC

Re: Interfacing Ada with C

[John B. Matthews]

In article 
<0b4752f2-411e-4f82-835a-8a46adaf2ff4@5g2000yqz.googlegroups.com>,
 sjw <simon.j.wright@mac.com> wrote:

> It is? (I tried it when not logged in, no problem ..)
> 
> Try here: http://gnat-math-extn.hg.sourceforge.net/hgweb/gnat-math-extn/
> & click on gnat-math-extn in the Name column?

Sorry, operator error. It works fine. :-)

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[John B. Matthews]

In article 
<a31a0183-68f0-4b83-8aa3-5ebbf036bf87@q35g2000yqn.googlegroups.com>,
 Ada novice <posts@gmx.us> wrote:

> On Jul 30, 11:09 am, sjw <simon.j.wri...@mac.com> wrote:
> 
> > Try 
> > here:http://gnat-math-extn.hg.sourceforge.net/hgweb/gnat-math-extn/ 
> > & click on gnat-math-extn in the Name column?
> 
> Thanks for this link. When I try to download the 3 files there (2 adb 
> and 1 ads) I get the files as files with xml codes in them. I guess 
> there must be a way to get the clean adb and ads files. I'm not 
> familiar with mercurial. Can someone please indicate how to go about?

You can click on the [raw] link at the top of any source page to get the 
text. Alternatively, download or build a mercurial binary for your 
platform:

<http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Ada novice]

On Jul 30, 5:13 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:

> You can click on the [raw] link at the top of any source page to get the
> text. Alternatively, download or build a mercurial binary for your
> platform:
>
> <http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial>

Thanks. The [raw] link gives the text versions but there some
additional + and - signs on the left of the text. I will have to
download mercurial for my Windows.

YC

Re: Interfacing Ada with C

[John B. Matthews]

In article 
<e0897c06-7125-48a0-9077-1893ce076b89@q22g2000yqm.googlegroups.com>,
 Ada novice <posts@gmx.us> wrote:

> On Jul 30, 5:13 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> 
> > You can click on the [raw] link at the top of any source page to get the
> > text. Alternatively, download or build a mercurial binary for your
> > platform:
> >
> > <http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial>
> 
> Thanks. The [raw] link gives the text versions but there some
> additional + and - signs on the left of the text. I will have to
> download mercurial for my Windows.

I think you may be looking at [raw] [diff] (difference) files.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Ada novice]

On Jul 30, 9:41 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:

>
> I think you may be looking at [raw] [diff] (difference) files.

Thanks. I have been able to locate the correct set of files. Opening
test_extensions.gpr in GPS gives me the following error messages:

[2010-07-30 22:54:16] E:\\ada\numerics\simon\jul29\test_extensions.gpr:
15:06: unknown project file: "../src/ada_math_build"
[2010-07-30 22:54:16] Error while loading project 'E:\ada\numerics
\simon\jul29\test_extensions.gpr'. Loading the default project.


I've tried to compile the source ads file
(Ada.Numerics.Generic_Complex_Arrays.Extensions.ads) in AdaGIDE and I
get the warning:

22. package Ada.Numerics.Generic_Complex_Arrays.Extensions is
                                                   |
        >>> warning: file name does not match unit name, should be "a-
ngcaex.ads"


and I get an error message with
Ada.Numerics.Generic_Complex_Arrays.Extensions.adb on compiling:

25.
    26. package body Ada.Numerics.Generic_Complex_Arrays.Extensions is
        |
        >>> descendents of package Ada may not be compiled


Note: for the source files adb and ads the name is ada-numerics-
generic_complex_arrays-extensions. Should it be ada-numerics-
generic_complex_arrays.extensions (with a dot between "arrays" and
"extensions" instead)?


YC

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> On Jul 30, 9:41 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
>
>>
>> I think you may be looking at [raw] [diff] (difference) files.
>
> Thanks. I have been able to locate the correct set of files.

Great!

>                                                              Opening
> test_extensions.gpr in GPS gives me the following error messages:
>
> [2010-07-30 22:54:16] E:\\ada\numerics\simon\jul29\test_extensions.gpr:
> 15:06: unknown project file: "../src/ada_math_build"
> [2010-07-30 22:54:16] Error while loading project 'E:\ada\numerics
> \simon\jul29\test_extensions.gpr'. Loading the default project.

Maybe - for Windows - you'll need to change

   with "../src/ada_math_build";

to

   with "..\src\ada_math_build";

(I thought gnatmake was slash-direction-agnostic, certainly it's OK for
paths inside a GPR ...)


Oh! that probably wasn't it: you seem to have the structure set up
differently from what the GPR expects, which is:

   ./src:
      ada-numerics-generic_complex_arrays-extensions.adb
      ada-numerics-generic_complex_arrays-extensions.ads
      ada_math_build.gpr

   ./test:
      test_extensions.adb
      test_extensions.gpr

If you go to the 'test' directory in a command window (or whatever it's
called in Windows now) and say

   E:\...> gnatmake -p -P test_extensions

it should go OK. The '-p' says 'create any necessary directories'. I'm
pretty sure it'll do this in GPS too (it may ask for permission).


> I've tried to compile the source ads file
> (Ada.Numerics.Generic_Complex_Arrays.Extensions.ads) in AdaGIDE and I
> get the warning:
>
> 22. package Ada.Numerics.Generic_Complex_Arrays.Extensions is
>                                                    |
>         >>> warning: file name does not match unit name, should be "a-
> ngcaex.ads"

From back in the day when GNAT had to run on DOS filesystems, the names
of units had to be 'krunched' to fit the 8.3 format, and for some reason
the standard library is still supplied this way. However, the code as
supplied builds OK with GCC 4.5.0 and GNAT GPL 2010 provided it's
compiled with ada_math_build.gpr.

I don't know whether AdaGIDE can manage GPRs, if not you're going to
have trouble using it for this...


> and I get an error message with
> Ada.Numerics.Generic_Complex_Arrays.Extensions.adb on compiling:
>
> 25.
>     26. package body Ada.Numerics.Generic_Complex_Arrays.Extensions is
>         |
>         >>> descendents of package Ada may not be compiled

You need special compilation options (-gnatpg) to allow compiling units
like these which (look as if they) are part of the standard
library. These options mean too that compilations have to be
warning-free.

src/ada_math_build.gpr supplies the necessary options.


> Note: for the source files adb and ads the name is ada-numerics-
> generic_complex_arrays-extensions. Should it be ada-numerics-
> generic_complex_arrays.extensions (with a dot between "arrays" and
> "extensions" instead)?

No, the dash is right:

ada-numerics-generic_complex_arrays-extensions
Ada.Numerics.Generic_Complex_Arrays.Extensions

Re: Interfacing Ada with C

[Ada novice]

On Jul 31, 12:19 am, Simon Wright <si...@pushface.org> wrote:

> Maybe - for Windows - you'll need to change

>    with "../src/ada_math_build";

> to

>    with "..\src\ada_math_build";

Actually, this doesn't seem to make a difference.

- Hide quoted text -
- Show quoted text -

> Oh! that probably wasn't it: you seem to have the structure set up
> differently from what the GPR expects, which is:

>    ./src:
>       ada-numerics-generic_complex_arrays-extensions.adb
>       ada-numerics-generic_complex_arrays-extensions.ads
>       ada_math_build.gpr

>    ./test:
>       test_extensions.adb
>       test_extensions.gpr

> If you go to the 'test' directory in a command window (or whatever it's
> called in Windows now) and say

>    E:\...> gnatmake -p -P test_extensions

> it should go OK. The '-p' says 'create any necessary directories'. I'm
> pretty sure it'll do this in GPS too (it may ask for permission).

I did what you suggested on the command line. This is what I get:

E:\...\jul29\test>gnatmake -p -P test_extensions
object directory "E:\...\jul29\src\.build" created for project
ada_math_build
library directory "E:\...\jul29\src\..\lib" created for project
ada_math_build
object directory "E:\...\jul29\test\.build" created for project
test_extensions
ada_math_build.gpr:15:09: there are no ada sources in this project
gnatmake: "test_extensions" processing failed

Note the ERROR message in the last line. As a result of the above
operations, now I have:

1. a .build directory is created in the folder test and it's empty;
2. a .build directory is created in the folder src and it's empty;
3. a lib folder is also created at the same level of hierarchy as the
folders test and src and it's empty

Afterwards, I'm able to open test_extensions.gpr WITHOUT any warning/
error messages in GPS

So next I tried to compile/build in GPS:

I press "Build main" (i.e. test_extensions.adb) and Ada_Math_Build.gpr
opens up and I get the message:

ada_math_build.gpr : there are no ada sources in this project

Looking at the structure of the gpr files in GPS in the "Project View"
pane on the LHS, I see that we just have 1 file: test_extensions.adb.
The source files Ada.Numerics.Generic_Complex_Arrays-
Extensions.ad(b,s) don't appear.
So there's something wrong. This is why I get the message: there are
no ada sources in this project on compiling.

> >         >>> warning: file name does not match unit name, should be "a-
> > ngcaex.ads"

> From back in the day when GNAT had to run on DOS filesystems, the names
> of units had to be 'krunched' to fit the 8.3 format, and for some reason
> the standard library is still supplied this way. However, the code as
> supplied builds OK with GCC 4.5.0 and GNAT GPL 2010 provided it's
> compiled with ada_math_build.gpr.

> I don't know whether AdaGIDE can manage GPRs, if not you're going to
> have trouble using it for this...

When I had problems earlier opening test_extensions.gpr in GPS as I
mentioned in my earlier post, I tried then to open the source files in
AdaGIDE just to compile them and see if everything is ok for the
source files. But I'm not using AdaGIDE. I will stick to GPS.

> > and I get an error message with
> > Ada.Numerics.Generic_Complex_Arrays.Extensions.adb on compiling:

> > 25.
> >     26. package body Ada.Numerics.Generic_Complex_Arrays.Extensions is
> >         |
> >         >>> descendents of package Ada may not be compiled

> You need special compilation options (-gnatpg) to allow compiling units
> like these which (look as if they) are part of the standard
> library. These options mean too that compilations have to be
> warning-free.

In GPS, I've taken a look at what switch is there for
test_entionsions.gpr and I see -gnatqQ. Changing this to -gnatpg puts
also -gnatVn automaticallt by GPS.

> > Note: for the source files adb and ads the name is ada-numerics-
> > generic_complex_arrays-extensions. Should it be ada-numerics-
> > generic_complex_arrays.extensions (with a dot between "arrays" and
> > "extensions" instead)?

> No, the dash is right:

> ada-numerics-generic_complex_arrays-extensions
> Ada.Numerics.Generic_Complex_Arrays.Extensions

I raised this issue as in the ads and adb files, you wrote:
Ada.Numerics.Generic_Complex_Arrays.Extensions .The dash is not
present. When I copied the plain text files of the codes from SF to
AdaGIDE, then of course, AdaGIDE proposed me the names
Ada.Numerics.Generic_Complex_Arrays.Extensions which match the names
inside the ads and adb files. But then I saw that on your website, you
named them with the dash instead. If I understand correctly, should
the names of the files not match the main procedure or package used
inside an Ada file? Maybe I'm thinking wrong here.

Thanks for giving me suggestions to make it work. We are not yet there
but hopefully with some minor adjustments, everything will be working
fine :).

YC

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> ada_math_build.gpr:15:09: there are no ada sources in this project

I get this if I've not put the two ada-numerics- source files in the
src/ directory.

I wanted to attach a screenshot of GPS here, showing how the structure
should look. Nowever, eternal-september.org doesn't allow binary
attachments, so see https://public.me.com/simon.j.wright,
numerics/gps-building-view.jpg.

Also, in the Build Main dialog box, see under Project the checked
'Create object dirs' box -- the equivalent of the -p flag to gnatmake.

Re: Interfacing Ada with C

[Simon Wright]

I forgot to add that (with GNAT GPL 2010) you'll need to use the
'-gnat05' flag. I've updated Sourceforge (the two GPRs).

test_extensions.gpr now reads
   package Compiler is
      for Default_Switches ("ada") use
        (
         "-gnatqQ",
         "-gnat05"   --  GNAT GPL 2010 requires this (GCC 4.5.0 doesn't)
         );
   end Compiler;

and ada_math_build.gpr now reads
   package Compiler is
      for Default_Switches ("ada") use
        (
         "-gnatpg",  --  to build Ada library items
         "-gnatqQ",  --  to keep ALI files even if there are compilation errors
         "-gnat05"   --  GNAT GPL 2010 requires this (GCC 4.5.0 doesn't)
        );
   end Compiler;

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

>> You need special compilation options (-gnatpg) to allow compiling units
>> like these which (look as if they) are part of the standard
>> library. These options mean too that compilations have to be
>> warning-free.
>
> In GPS, I've taken a look at what switch is there for
> test_entionsions.gpr and I see -gnatqQ. Changing this to -gnatpg puts
> also -gnatVn automaticallt by GPS.

The idea is that -- whatever extra hoops -gnatpg makes you (me) go
through as a writer of Ada library components -- the ordinary user
needn't be worried.

>> > Note: for the source files adb and ads the name is ada-numerics-
>> > generic_complex_arrays-extensions. Should it be ada-numerics-
>> > generic_complex_arrays.extensions (with a dot between "arrays" and
>> > "extensions" instead)?
>
>> No, the dash is right:
>
>> ada-numerics-generic_complex_arrays-extensions
>> Ada.Numerics.Generic_Complex_Arrays.Extensions
>
> I raised this issue as in the ads and adb files, you wrote:
> Ada.Numerics.Generic_Complex_Arrays.Extensions .The dash is not
> present. When I copied the plain text files of the codes from SF to
> AdaGIDE, then of course, AdaGIDE proposed me the names
> Ada.Numerics.Generic_Complex_Arrays.Extensions which match the names
> inside the ads and adb files. But then I saw that on your website, you
> named them with the dash instead. If I understand correctly, should
> the names of the files not match the main procedure or package used
> inside an Ada file? Maybe I'm thinking wrong here.

See
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn_unw/File-Naming-Rules.html#File-Naming-Rules
for the details.

Re: Interfacing Ada with C

[Ada novice]

Success here with the testing! Thanks for all your very kind help
Simon. First, I would like to draw your attention on 1 point. At
first, I was copying your raw files into AdaGIDE in order to save
them. Then running gnatmake -p -P test_extensions did produce a lots
of error messages: incorrect line terminator. I remember getting this
message before and what I did was to save the files in GPS and the
error messages disappear. I think in AdaGIDE pasting raw text can
cause some incompatibility due to the file system used. This is why I
guess I got this error: incorrect line terminator. I can't explain
this but I don't have it in GPS.


After successfully saving all your raw files within GPS, I ran
gnatmake -p -P test_extensions without any warnings/error messages and
the following were created:

A.) A lib folder is created at the same hierarchy level as src and
test. It has 2 files:
1.libada_math.dll
2.ada-numerics-generic_complex_arrays-extensions.ali


B.) In the src folder a .build folder is created with 2 files:
1. ada-numerics-generic_complex_arrays-extensions.ali
2. ada-numerics-generic_complex_arrays-extensions.o

C.) In the test folder a .build folder is created with 6 files:
1. b~test_extensions.adb
2. b~test_extensions.ads
3. b~test_extensions.ali
4. b~test_extensions.o
5. test_extensions.ali
6. test_extensions.o

Then I was able to build using Build main: test_extensions.adb
successfully.

Now for the outputs I get:

 2.00000E+00  4.00000E+00
 2.00000E+00 -4.00000E+00
 9.99999E-01  1.10569E-07

-6.00000E+00
-4.00000E+00
-2.00000E+00
-1.21279E-07
 2.00000E+00
 4.00000E+00
 6.00000E+00

 6.00000E+00  0.00000E+00
 4.00000E+00  0.00000E+00
-6.00000E+00  0.00000E+00
 2.00000E+00  0.00000E+00
-3.17504E-07  0.00000E+00
-4.00000E+00  0.00000E+00
-2.00000E+00  0.00000E+00

The second set of results are for the Test16 which are ok. What about
the third set of results? What are these?


On Jul 31, 3:25 pm, Simon Wright <si...@pushface.org> wrote:

> The idea is that -- whatever extra hoops -gnatpg makes you (me) go
> through as a writer of Ada library components -- the ordinary user
> needn't be worried.
>

Here are the switches for "build main"

%gnatmake -q -c -gnats -u %eL -P%PP %X %fp

which are a bit similar to those you have in the jpg file from your
earlier post.

I didn't add -gnatpg for the compiler switch. I had these: -gnatqQ -
gnat05

and I can compile fine and output the results. Is the -gnatpg a
necessity?


Thanks very much for helping me with the compilation. Now it's good
that some more testing is done on different cases. Do you plan to add
the output for eigenvectors also?

YC

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> Success here with the testing! Thanks for all your very kind help
> Simon. First, I would like to draw your attention on 1 point. At
> first, I was copying your raw files into AdaGIDE in order to save
> them. Then running gnatmake -p -P test_extensions did produce a lots
> of error messages: incorrect line terminator. I remember getting this
> message before and what I did was to save the files in GPS and the
> error messages disappear. I think in AdaGIDE pasting raw text can
> cause some incompatibility due to the file system used. This is why I
> guess I got this error: incorrect line terminator. I can't explain
> this but I don't have it in GPS.

Was this perhaps with the ada-numerics* files? there may be some -gnatpg
problem with inconsistent line terminators, I guess GPS is clever enough
to know that it's going to be anuisance and fix it.

> After successfully saving all your raw files within GPS, I ran
> gnatmake -p -P test_extensions without any warnings/error messages and
> the following were created:
>
> A.) A lib folder is created at the same hierarchy level as src and
> test. It has 2 files:
> 1.libada_math.dll
> 2.ada-numerics-generic_complex_arrays-extensions.ali
>
> B.) In the src folder a .build folder is created with 2 files:
> 1. ada-numerics-generic_complex_arrays-extensions.ali
> 2. ada-numerics-generic_complex_arrays-extensions.o
>
> C.) In the test folder a .build folder is created with 6 files:
> 1. b~test_extensions.adb
> 2. b~test_extensions.ads
> 3. b~test_extensions.ali
> 4. b~test_extensions.o
> 5. test_extensions.ali
> 6. test_extensions.o
>
> Then I was able to build using Build main: test_extensions.adb
> successfully.

This looks as expected. NB that's a sort of half-baked library; to make
a proper dll * include files it needs to be a 'stand-alone library' in
GNAT terms. From the user's point of view it Just Works (I did have a
problem on a Debian machine with GCC 4.3.2, didn't automatically find
the shared library). Anyway, if it works for you on windows don't worry
about it!

> Now for the outputs I get:
>
>  2.00000E+00  4.00000E+00
>  2.00000E+00 -4.00000E+00
>  9.99999E-01  1.10569E-07
>
> -6.00000E+00
> -4.00000E+00
> -2.00000E+00
> -1.21279E-07
>  2.00000E+00
>  4.00000E+00
>  6.00000E+00
>
>  6.00000E+00  0.00000E+00
>  4.00000E+00  0.00000E+00
> -6.00000E+00  0.00000E+00
>  2.00000E+00  0.00000E+00
> -3.17504E-07  0.00000E+00
> -4.00000E+00  0.00000E+00
> -2.00000E+00  0.00000E+00
>
> The second set of results are for the Test16 which are ok. What about
> the third set of results? What are these?

The second set are with the package that comes with the compiler, that
takes a symmetric complex matrix (which this is - needs to be complex to
check the new code) and outputs a real eigenvalue vector.

The third set are with the new package, that takes a general complex
matrix and outputs a complex eigenvalue vector.

> I didn't add -gnatpg for the compiler switch. I had these: -gnatqQ -
> gnat05 and I can compile fine and output the results. Is the -gnatpg a
> necessity?

Yes *but only in the src/ directory*, which is why it's in
ada_math_build.gpr & not in test_extensions.gpr.

This is part of a clean compile...

   gcc -c -g -fPIC -gnatpg -gnatqQ -gnat05 -I- -gnatA /Users/simon/gnat-math-extn/src/ada-numerics-generic_complex_arrays-extensions.adb
   gcc -c -g -gnatqQ -gnat05 -I- -gnatA /Users/simon/gnat-math-extn/test/test_extensions.adb

and the first line, for the library, has the additional flags -fPIC
(because, on this architecture, you need position-independent code for a
shared library) and -gnatpg (from ada_math_build.gpr, as discussed).

> Thanks very much for helping me with the compilation. Now it's good
> that some more testing is done on different cases. Do you plan to add
> the output for eigenvectors also?

Seemed like a plan! Also real non-symmetric, I think.

I found the LAPACK test suite described here -
http://www.netlib.org/lapack/lawns/lawn41.ps - could be useful though it
could also be a pain to translate.

Re: Interfacing Ada with C

[Ada novice]

On Jul 31, 11:02 pm, Simon Wright <si...@pushface.org> wrote:

> Was this perhaps with the ada-numerics* files? there may be some -gnatpg
> problem with inconsistent line terminators, I guess GPS is clever enough
> to know that it's going to be anuisance and fix it.

Once I had a similar problem with another adb or ads file which I got
from the web a few weeks back. The problem was then with GPS and not
with AdaGIDE. As GPS was complaining, what I did afterwards was to
save the "raw text" into
AdaGIDE and I didn't get any complain when compiling the file into
GPS after that. Is that because a raw text can be using a different
end of line
marker? The file encoding that's being used in an editor may be
different and not pure ASCII. In any case, one can always play around
and save the raw files in Notepad on Windows or in another editor like
WinEdt also.

> > I didn't add -gnatpg for the compiler switch. I had these: -gnatqQ -
> > gnat05 and I can compile fine and output the results. Is the -gnatpg a
> > necessity?
> Yes *but only in the src/ directory*, which is why it's in
> ada_math_build.gpr & not in test_extensions.gpr.
> This is part of a clean compile...
>    gcc -c -g -fPIC -gnatpg -gnatqQ -gnat05 -I- -gnatA /Users/simon/gnat-math-extn/src/ada-numerics-generic_complex_arrays-extensions.adb
>    gcc -c -g -gnatqQ -gnat05 -I- -gnatA /Users/simon/gnat-math-extn/test/test_extensions.adb
> and the first line, for the library, has the additional flags -fPIC
> (because, on this architecture, you need position-independent code for a
> shared library) and -gnatpg (from ada_math_build.gpr, as discussed).

Thanks for the explanation.

> > Thanks very much for helping me with the compilation. Now it's good
> > that some more testing is done on different cases. Do you plan to add
> > the output for eigenvectors also?
> Seemed like a plan! Also real non-symmetric, I think.
> I found the LAPACK test suite described here -http://www.netlib.org/lapack/lawns/lawn41.ps- could be useful though it
> could also be a pain to translate.

A long-term goal might perhaps be to be able to solve the generalized
eigenvalue problem. See for example here:

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/eig.html

Now, the code has a function like (from the link above)

eig(A) returns a vector of the eigenvalues of matrix A.

In engineering, for example in vibration analysis, one is more
interested in the generalized eigenvalue problem (from the above link)

eig(A,B) returns a vector containing the generalized eigenvalues, if A
and B are square matrices.

In vibration analysis, matrices representing the mass, stiffness and
damping of a structure are readily formed from a model of the real-
life structure. When the generalized eigenvalue problem is solved,
then the eigenvalues give the resonances of the structure i.e.
frequencies at which large vibration occur. Normally only the first
few eigenvalues are of interest as they represent those resonant
frequencies that can give the most damage to the structure. The
corresponding eigenvectors represent then the relative displacements
between different locations of the structure at a given resonant
frequency and give a general idea how the structure is deformed at a
given resonant frequency (or eigenvalue). The eigenvectors don't give
the actual displacements but only an indication of how the different
parts of the structure will deform in relation to each other. Actual
magnitude of displacements can only be obtained under actual testing
when a force is applied to the structure. Of course the mass,
stiffness
and damping matrix are real matrices (but not necessarily symmetric).

Some information on the algorithm is found here in the IMSL C user
guide:

http://www.vni.com/products/imsl/documentation/CNL700_Docs/html/cmath...

in Chapter 2: Eigensystem analysis (on the left of the page and expand
the chapter to get the different sections) at the bottom of the
section "Usage notes", and in the sections eig_symgen, geneig.
There's
the section: genig (complex) where both A and B are complex but I
don't have a
clue where this can be used in engineering. It may be more of
relevance to mathematicians though.
But these are very complex algorithms. Your link to lawn41.ps also has
some information.
And as you said, this can be a pain to translate.

YC

Re: Interfacing Ada with C

[John B. Matthews]

In article <m262zzs0nz.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:

> I've taken the plunge and started a SourceForge project for this. 
> It's at http://sourceforge.net/projects/gnat-math-extn/ -- under "Ada 
> 2005 Math Extensions", click on [Develop] then on [Code].
> 
> I've chosen to use Mercurial (Hg) as the VCS, mainly to get a 
> real-world feel for using a DVCS (Distributed Version Control 
> System). To downoad the code, you'll need to install Hg - 
> http://mercurial.selenic.com/ - because I haven't actually made a 
> code release yet!
> 
> If anyone feels moved to join in, just say (of course you need a SF 
> account to update the SF repository, but with Hg it should be 
> possible to work via patchsets .. )

I just wanted to report success and offer a small patch: it seems to 
makes a considerable difference in the executable size:

$ hg diff
diff -r aac8ba7708e2 test/test_extensions.gpr
--- a/test/test_extensions.gpr  Sat Jul 31 17:09:42 2010 +0100
+++ b/test/test_extensions.gpr  Sun Aug 01 06:33:33 2010 -0400
@@ -37,4 +37,8 @@
       for Default_Switches ("ada") use ("-E");
    end Binder;
 
+   package Linker is
+      for Default_Switches ("ada") use ("-dead_strip");
+   end Linker;
+
 end Test_Extensions;

With GNAT 4.3.4 (FSF), I had to build with Library_Kind "static" before 
I could build with "dynamic". For some reason, the dylib appears in 
../src/.build/ instead of ../lib/. I think that's a bug in the older 
version that I've also seen building GtkAda.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

4 times, with slightly different contents! is your newsreader posting
the message when you asked it to save a draft, perhaps?

> On Jul 31, 11:02 pm, Simon Wright <si...@pushface.org> wrote:

>> Seemed like a plan! Also real non-symmetric, I think.  I found the
>> LAPACK test suite described here
>> -http://www.netlib.org/lapack/lawns/lawn41.ps- could be useful though
>> it could also be a pain to translate.
>
> A long-term goal might perhaps be to be able to solve the generalized
> eigenvalue problem. See for example here:
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/eig.html
>
> Now, the code has a function like (from the link above)
>
> eig(A) returns a vector of the eigenvalues of matrix A.
>
> In engineering, for example in vibration analysis, one is more
> interested in the generalized eigenvalue problem (from the above link)
>
> eig(A,B) returns a vector containing the generalized eigenvalues, if A
> and B are square matrices.
>
> In vibration analysis, matrices representing the mass, stiffness and
> damping of a structure are readily formed from a model of the real-
> life structure. When the generalized eigenvalue problem is solved,
> then the eigenvalues give the resonances of the structure i.e.
> frequencies at which large vibration occur. Normally only the first
> few eigenvalues are of interest as they represent those resonant
> frequencies that can give the most damage to the structure. The
> corresponding eigenvectors represent then the relative displacements
> between different locations of the structure at a given resonant
> frequency and give a general idea how the structure is deformed at a
> given resonant frequency (or eigenvalue). The eigenvectors don't give
> the actual displacements but only an indication of how the different
> parts of the structure will deform in relation to each other. Actual
> magnitude of displacements can only be obtained under actual testing
> when a force is applied to the structure. Of course the mass,
> stiffness and damping matrix are real matrices (but not necessarily
> symmetric).
>
> Some information on the algorithm is found here in the IMSL C user
> guide:
>
> http://www.vni.com/products/imsl/documentation/CNL700_Docs/html/cmath...
>
> in Chapter 2: Eigensystem analysis (on the left of the page and expand
> the chapter to get the different sections) at the bottom of the
> section "Usage notes", and in the sections eig_symgen, geneig.
> There's the section: genig (complex) where both A and B are complex
> but I don't have a clue where this can be used in engineering. It may
> be more of relevance to mathematicians though.  But these are very
> complex algorithms. Your link to lawn41.ps also has some information.
> And as you said, this can be a pain to translate.

If you thnk it would be useful .. it's a good thing that LAPACK already
includes the generalized eigenvalue algorithms (xGGEV), then! Binding to
an existing proven coding of an algorithm I can do, creating a new one
... hmm.

Re: Interfacing Ada with C

[Ada novice]

On Aug 1, 6:14 pm, Simon Wright <si...@pushface.org> wrote:
> Ada novice <po...@gmx.us> writes:
>
> 4 times, with slightly different contents! is your newsreader posting
> the message when you asked it to save a draft, perhaps?
>

Actually, I posted and then make some modifications to explain better.
And this in 4 tiles as you said. But I deleted each post to put the
new one instead. And only my "final" post appear here. So do you mean
that you were informed (through email perhaps?) 4 times about me
posting? Of course this was never my intention. I shall avoid in the
future to delete a post and re-write it.


> If you thnk it would be useful .. it's a good thing that LAPACK already
> includes the generalized eigenvalue algorithms (xGGEV), then! Binding to
> an existing proven coding of an algorithm I can do, creating a new one
> ... hmm.

Actually, the generalised eigenvalue problem is indeed very useful in
various branches of engineering and yes it would be very kind of you
to provide such a binding. Maybe later you can inform the Numerics
group of the Ada committee of your efforts so that more people will be
made aware of the bindings.

And thanks again for letting me know about my 4 posts.
YC

Re: Interfacing Ada with C

[Simon Wright]

"John B. Matthews" <nospam@nospam.invalid> writes:

> In article <m262zzs0nz.fsf@pushface.org>,
>  Simon Wright <simon@pushface.org> wrote:
>
>> I've taken the plunge and started a SourceForge project for this. 
>> It's at http://sourceforge.net/projects/gnat-math-extn/ -- under "Ada 
>> 2005 Math Extensions", click on [Develop] then on [Code].
[...]
>> If anyone feels moved to join in, just say (of course you need a SF 
>> account to update the SF repository, but with Hg it should be 
>> possible to work via patchsets .. )
>
> I just wanted to report success and offer a small patch: it seems to 
> makes a considerable difference in the executable size:

Glad it worked!

> $ hg diff
> diff -r aac8ba7708e2 test/test_extensions.gpr
> --- a/test/test_extensions.gpr  Sat Jul 31 17:09:42 2010 +0100
> +++ b/test/test_extensions.gpr  Sun Aug 01 06:33:33 2010 -0400
> @@ -37,4 +37,8 @@
>        for Default_Switches ("ada") use ("-E");
>     end Binder;
>  
> +   package Linker is
> +      for Default_Switches ("ada") use ("-dead_strip");
> +   end Linker;
> +
>  end Test_Extensions;

I get the impression this is Mac-specific? Sounds like a good trick,
though.

> With GNAT 4.3.4 (FSF), I had to build with Library_Kind "static" before 
> I could build with "dynamic". For some reason, the dylib appears in 
> ../src/.build/ instead of ../lib/. I think that's a bug in the older 
> version that I've also seen building GtkAda.

It's OK on GCC 4.5.0 & GNAT GPL 2010.

Do you really mean you had to build with "static" *before* "dynamic"?
weird ...

I think that while it's under development, maybe a static library would
be the Right Thing.

Re: Interfacing Ada with C

[Simon Wright]

Ada novice <posts@gmx.us> writes:

> On Aug 1, 6:14 pm, Simon Wright <si...@pushface.org> wrote:
>> Ada novice <po...@gmx.us> writes:
>>
>> 4 times, with slightly different contents! is your newsreader posting
>> the message when you asked it to save a draft, perhaps?
>>
>
> Actually, I posted and then make some modifications to explain better.
> And this in 4 tiles as you said. But I deleted each post to put the
> new one instead. And only my "final" post appear here. So do you mean
> that you were informed (through email perhaps?) 4 times about me
> posting? Of course this was never my intention. I shall avoid in the
> future to delete a post and re-write it.

I suppose the 'cancel' messages didn't make it to my news hosting
organisation, then. Not to worry.

Re: Interfacing Ada with C

[John B. Matthews]

In article <m2mxt6b6qd.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:
[...]
> > +   package Linker is
> > +      for Default_Switches ("ada") use ("-dead_strip");
> > +   end Linker;
> 
> I get the impression this is Mac-specific? Sounds like a good trick, 
> though.

Looking closer, I see it's listed among the "Darwin Options".

> > With GNAT 4.3.4 (FSF), I had to build with Library_Kind "static" 
> > before I could build with "dynamic". For some reason, the dylib 
> > appears in ../src/.build/ instead of ../lib/. I think that's a bug 
> > in the older version that I've also seen building GtkAda.
> 
> It's OK on GCC 4.5.0 & GNAT GPL 2010.
> 
> Do you really mean you had to build with "static" *before* "dynamic"? 
> weird ...

Yes, building "static" puts an archive (.a) in the expected place 
(../lib/), where a subsequent "dynamic" build apparently uses it.

> I think that while it's under development, maybe a static library 
> would be the Right Thing.

Maybe, as -g is in use.

On a related note, the project builds and runs correctly on Ubuntu 10.04 
using GNAT 4.4.3 (FSF), Mercurial 1.4.3, blas 1.2, and lapack 3.2.1.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Simon Wright]

"John B. Matthews" <nospam@nospam.invalid> writes:

> In article <m2mxt6b6qd.fsf@pushface.org>,
>  Simon Wright <simon@pushface.org> wrote:

>> I think that while it's under development, maybe a static library 
>> would be the Right Thing.
>
> Maybe, as -g is in use.

I've made a static release (20100801, delay caused by SF file release
system outage) at http://sourceforge.net/projects/gnat-math-extn/files/

> On a related note, the project builds and runs correctly on Ubuntu 10.04 
> using GNAT 4.4.3 (FSF), Mercurial 1.4.3, blas 1.2, and lapack 3.2.1.

Good news. 

Re: Interfacing Ada with C

[Ada novice]

On Aug 2, 6:36 pm, Simon Wright <si...@pushface.org> wrote:

> I've made a static release (20100801, delay caused by SF file release
> system outage) athttp://sourceforge.net/projects/gnat-math-extn/files/
>

Thanks. I have just run the 20100801 release on my Windows machine and
everything seems fine. I did everything on the command line.

YC

Re: Interfacing Ada with C

[Ada novice]

I have made some simple tests on some special matrices which can pose
some problems. I limited myself to matrices with real values. I have
tested:

1. non-symmetric real matrices with repeated values.
   No problem here

2. a real orthogonal matrix. Such a matrix gives all eigenvalues of
unit modulus. I tested the case from http://en.wikipedia.org/wiki/Orthogonal_matrix.
In Matlab,

   eig([0, -0.8, -0.6; 0.8, -0.36, 0.48; 0.6, 0.48, -0.64])

   gives the eigenvalues as 0 + 1i, 0 - 1i and -1.

   Using your Ada code gives:

   -1.78814E-08  1.00000E+00
   -8.72890E-09 -1.00000E+00
   -1.00000E+00  0.00000E+00


Does the Blas code work with Fortran double-precision? In the above,
Matlab with double (15 digits precision). I don't see you using the
type Long_Float in the Ada code. I don't know how many digits are
being passed from the Fortran result to Ada. Maybe this is causing the
discrepancy between the expected results (all eigenvalues of modulus
one) and the output in Ada.


3. a real skew-symmetric matrix. This is also interesting as all
eigenvalues are imaginary. I tested the case from
http://en.wikipedia.org/wiki/Skew-symmetric_matrix. In Matlab,

   eig([0, 2, -1; -2, 0, -4; 1, 4, 0])

   gives the eigenvalues as   0 ;  0 + 4.582575694955841i and 0 -
4.582575694955841i

   Using the Ada code gives:

    9.12635E-08  4.58258E+00
   -5.31220E-08  1.92730E-07
    3.95880E-08 -4.58258E+00

    Here also exist some slight discrepancies. I believe as mentioned
above that if we change use more precision digits, then we'll get
"better" answers.


Thanks.

YC

Re: Interfacing Ada with C

[John B. Matthews]

In article 
<b7f5edce-124d-4b91-82f2-e9793d39a3cf@x25g2000yqj.googlegroups.com>,
 Ada novice <posts@gmx.us> wrote:

> 2. a real orthogonal matrix. Such a matrix gives all eigenvalues of
> unit modulus. I tested the case from 
> http://en.wikipedia.org/wiki/Orthogonal_matrix.
> In Matlab,
> 
>    eig([0, -0.8, -0.6; 0.8, -0.36, 0.48; 0.6, 0.48, -0.64])
> 
>    gives the eigenvalues as 0 + 1i, 0 - 1i and -1.
> 
>    Using your Ada code gives:
> 
>    -1.78814E-08  1.00000E+00
>    -8.72890E-09 -1.00000E+00
>    -1.00000E+00  0.00000E+00
> 
> 
> Does the Blas code work with Fortran double-precision? In the above,
> Matlab with double (15 digits precision). I don't see you using the
> type Long_Float in the Ada code. I don't know how many digits are
> being passed from the Fortran result to Ada. Maybe this is causing the
> discrepancy between the expected results (all eigenvalues of modulus
> one) and the output in Ada.

Using these declarations in test_extensions.adb:

   subtype My_Float is Long_Float;

   Input : constant Complex_Matrix
     := (((0.0, 0.0), (-0.8,  0.0),  -0.6,  0.0)),
         ((0.8, 0.0), (-0.36, 0.0),  (0.48, 0.0)),
         ((0.6, 0.0),  (0.48, 0.0), (-0.64, 0.0)));

I get this result:

./test_extensions
 0.00000000000000E+00  1.00000000000000E+00
-2.77555756156289E-17 -1.00000000000000E+00
-1.00000000000000E+00  0.00000000000000E+00

[...]
-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[sjw]

On Aug 5, 2:23 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> In article
> <b7f5edce-124d-4b91-82f2-e9793d39a...@x25g2000yqj.googlegroups.com>,
>  Ada novice <po...@gmx.us> wrote:
>
>
>
> > 2. a real orthogonal matrix. Such a matrix gives all eigenvalues of
> > unit modulus. I tested the case from
> >http://en.wikipedia.org/wiki/Orthogonal_matrix.
> > In Matlab,
>
> >    eig([0, -0.8, -0.6; 0.8, -0.36, 0.48; 0.6, 0.48, -0.64])
>
> >    gives the eigenvalues as 0 + 1i, 0 - 1i and -1.
>
> >    Using your Ada code gives:
>
> >    -1.78814E-08  1.00000E+00
> >    -8.72890E-09 -1.00000E+00
> >    -1.00000E+00  0.00000E+00
>
> > Does the Blas code work with Fortran double-precision? In the above,
> > Matlab with double (15 digits precision). I don't see you using the
> > type Long_Float in the Ada code. I don't know how many digits are
> > being passed from the Fortran result to Ada. Maybe this is causing the
> > discrepancy between the expected results (all eigenvalues of modulus
> > one) and the output in Ada.
>
> Using these declarations in test_extensions.adb:
>
>    subtype My_Float is Long_Float;
>
>    Input : constant Complex_Matrix
>      := (((0.0, 0.0), (-0.8,  0.0),  -0.6,  0.0)),
>          ((0.8, 0.0), (-0.36, 0.0),  (0.48, 0.0)),
>          ((0.6, 0.0),  (0.48, 0.0), (-0.64, 0.0)));
>
> I get this result:
>
> ./test_extensions
>  0.00000000000000E+00  1.00000000000000E+00
> -2.77555756156289E-17 -1.00000000000000E+00
> -1.00000000000000E+00  0.00000000000000E+00

The reason for the 'subtype My_Float is Float;' is to make it easy to
change the type in use, for experimentation. You can certainly use
Fortran double precision, equivalent to the GNAT Ada Long_Float.

Although LAPACK/BLAS (at 3.2.2 anyway) allow you to build with
extended precision (80-bit floats, GNAT Long_Long_Float if on x86
hardware) GNAT's implementation of Generic * Arrays assumes the worst
case, ie BLAS/LAPACK only available in single & double precision; and
if the type in use (My_Float in my test case) doesn't match Fortran
single or double precision it converts to double precision, makes the
call, then converts back. I think this deserves a warning at the least
if the precision of the result doesn't match the precision of the base
type.

The Extensions code makes the same transformations as GNAT's.

Re: Interfacing Ada with C

[Ada novice]

Thanks sjw and trashgod. It's good that changing the subtype to
Long_Float fixes the "problem" easily. First my apologies for
supplying the test matrices in Matlab form and in Ada form in my
earlier post. I should have of course supplied them in Ada's form as
trashgod did to make things easier for you.

I tried again case 2 and case 3 from my earlier post:

2. case 2

  Input : constant Complex_Matrix
        := (((0.0, 0.0), (-0.8, 0.0), (-0.6, 0.0)),
            ((0.8, 0.0), (-0.36, 0.0), (0.48, 0.0)),
            ((0.6, 0.0), (0.48, 0.0), (-0.64, 0.0)));

   and the eigenvalues are:

    -9.97465998686664E-18  1.00000000000000E+00
    -2.07489190759413E-17 -1.00000000000000E+00
    -1.00000000000000E+00  0.00000000000000E+00

3. Case 3

  Input : constant Complex_Matrix
        := (((0.0, 0.0), (2.0, 0.0), (-1.0, 0.0)),
            ((-2.0, 0.0), (0.0, 0.0), (-4.0, 0.0)),
            ((1.0, 0.0), (4.0, 0.0), (0.0, 0.0)));

  and the eigenvalues are:

-3.16587034365767E-17  4.58257569495584E+00
 3.52062239626920E-17 -1.38867432149415E-16
 2.99876030370094E-16 -4.58257569495584E+00


They are much more accurate and better results of course. I wonder why
Matlab tends to be give very "accurate" answers. Normally 15 digits of
precision is also used there.



On Aug 5, 3:57 pm, sjw <simon.j.wri...@mac.com> wrote:

> Although LAPACK/BLAS (at 3.2.2 anyway) allow you to build with
> extended precision (80-bit floats, GNAT Long_Long_Float if on x86
> hardware) GNAT's implementation of Generic * Arrays assumes the worst
> case, ie BLAS/LAPACK only available in single & double precision; and
> if the type in use (My_Float in my test case) doesn't match Fortran
> single or double precision it converts to double precision, makes the
> call, then converts back.

Can we change the subtype to Long_Long_Float? This will be of 18
precision digits and "more" precise than Fortran's double precision.
It would be like asking for more precision that can be offered. Did I
understand you correctly?


Thanks
YC

Re: Interfacing Ada with C

[Jeffrey Carter]

On 08/05/2010 10:24 AM, Ada novice wrote:
>
> They are much more accurate and better results of course. I wonder why
> Matlab tends to be give very "accurate" answers. Normally 15 digits of
> precision is also used there.

You requested 15 decimal digits; your results are zero to 15 decimal places. If 
you output in non-scientific notation you'd get zero; presumably that's what 
Matlab is doing.

-- 
Jeff Carter
"I was in love with a beautiful blonde once, dear.
She drove me to drink. That's the one thing I'm
indebted to her for."
Never Give a Sucker an Even Break
109

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

Re: Interfacing Ada with C

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 08/05/2010 10:24 AM, Ada novice wrote:
>>
>> They are much more accurate and better results of course. I wonder why
>> Matlab tends to be give very "accurate" answers. Normally 15 digits of
>> precision is also used there.
>
> You requested 15 decimal digits; your results are zero to 15 decimal
> places. If you output in non-scientific notation you'd get zero;
> presumably that's what Matlab is doing.

The attached update uses fixed notation, looks rather better.

Note that the reason for the lack of precision in the Test16 results is
likely because the inputs are only specified to 6 digits.


[-- Attachment #2: New test program --]
[-- Type: text/plain, Size: 5011 bytes --]

--  This package is free software; you can redistribute it and/or
--  modify it under terms of the GNU General Public License as
--  published by the Free Software Foundation; either version 3, or
--  (at your option) any later version.  It is distributed in the
--  hope that it will be useful, but WITHOUT ANY WARRANTY; without
--  even the implied warranty of MERCHANTABILITY or FITNESS FOR A
--  PARTICULAR PURPOSE.
--
--  You should have received a copy of the GNU General Public License
--  along with this program; see the file COPYING3.  If not, see
--  <http://www.gnu.org/licenses/>.
--
--  Copyright Simon Wright <simon@pushface.org>

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Numerics.Generic_Real_Arrays;
with Ada.Numerics.Generic_Complex_Types;
with Ada.Numerics.Generic_Complex_Arrays.Extensions;

procedure Test_Extensions is

   subtype My_Float is Long_Float;
   package My_Float_IO is new Float_IO (My_Float);
   use My_Float_IO;

   package Real_Arrays
   is new Ada.Numerics.Generic_Real_Arrays (My_Float);
   package Complex_Types
   is new Ada.Numerics.Generic_Complex_Types (My_Float);
   package Complex_Arrays
   is new Ada.Numerics.Generic_Complex_Arrays (Real_Arrays, Complex_Types);
   package Extensions
   is new Complex_Arrays.Extensions;

   use Real_Arrays;
   use Complex_Types;
   use Complex_Arrays;

begin

   declare
   --  Values in yc's example
      Input : constant Complex_Matrix
        := (((8.0, 0.0), (-1.0, 0.0), (-5.0, 0.0)),
            ((-4.0, 0.0), (4.0, 0.0), (-2.0, 0.0)),
            ((18.0, 0.0), (-5.0, 0.0), (-7.0, 0.0)));
      Result : Complex_Vector (1 .. Input'Length (1));
   begin

      Put_Line ("Values from <143ef70b-7e74-426b-a621-a5fd157849be"
                  & "@x21g2000yqa.googlegroups.com>");

      Result := Extensions.Eigenvalues (Input);

      for J in Result'Range loop
         Put (Result (J).Re, Exp => 0);
         Put (" ");
         Put (Result (J).Im, Exp => 0);
         New_Line;
      end loop;

      New_Line;

   end;

   declare
   --  Values in Test 16 of
   --  http://people.sc.fsu.edu/~jburkardt/f_src/lapack/lapack_OSX_prb_output.txt
      Z : constant Complex := (0.0, 0.0);
      A : constant Complex := (2.44949, 0.0);
      B : constant Complex := (3.16228, 0.0);
      C : constant Complex := (3.46410, 0.0);
      Input : constant Complex_Matrix
        := (
            1 => (Z, A, Z, Z, Z, Z, Z),
            2 => (A, Z, B, Z, Z, Z, Z),
            3 => (Z, B, Z, C, Z, Z, Z),
            4 => (Z, Z, C, Z, C, Z, Z),
            5 => (Z, Z, Z, C, Z, B, Z),
            6 => (Z, Z, Z, Z, B, Z, A),
            7 => (Z, Z, Z, Z, Z, A, Z)
           );
   begin

      Put_Line ("Values in Test16 of "
                  & "http://people.sc.fsu.edu/~jburkardt/f_src/lapack"
                  & "/lapack_OSX_prb_output.txt");

      -- GNAT: Eigenvalues of symmetrix complex matrix are real
      Put_Line ("using Complex_Arrays.Eigenvalues");
      declare
         Result : constant Real_Vector := Complex_Arrays.Eigenvalues (Input);
      begin
         for J in Result'Range loop
            Put (Result (J), Exp => 0);
            New_Line;
         end loop;
      end;
      New_Line;

      --  Extension: Eigenvalues of general complex matrix are complex.
      Put_Line ("using Extensions.Eigenvalues");
      declare
         Result : constant Complex_Vector := Extensions.Eigenvalues (Input);
      begin
         for J in Result'Range loop
            Put (Result (J).Re, Exp => 0);
            Put (" ");
            Put (Result (J).Im, Exp => 0);
            New_Line;
         end loop;
      end;
      New_Line;

   end;

   declare
   --  Values from http://en.wikipedia.org/wiki/Skew-symmetric_matrix
      Input : constant Complex_Matrix
        := (((0.0, 0.0), (2.0, 0.0), (-1.0, 0.0)),
            ((-2.0, 0.0), (0.0, 0.0), (-4.0, 0.0)),
            ((1.0, 0.0), (4.0, 0.0), (0.0, 0.0)));
      Result : Complex_Vector (1 .. Input'Length (1));
   begin

      Put_Line
        ("Values from http://en.wikipedia.org/wiki/Skew-symmetric_matrix");

      Result := Extensions.Eigenvalues (Input);

      for J in Result'Range loop
         Put (Result (J).Re, Exp => 0);
         Put (" ");
         Put (Result (J).Im, Exp => 0);
         New_Line;
      end loop;
      New_Line;

   end;

   declare
   --  Values from http://en.wikipedia.org/wiki/Orthogonal_matrix
      Input : constant Complex_Matrix
        := (((0.0, 0.0), (-0.8, 0.0), (-0.6, 0.0)),
            ((0.8, 0.0), (-0.36, 0.0), (0.48, 0.0)),
            ((0.6, 0.0), (0.48, 0.0), (-0.64, 0.0)));
      Result : Complex_Vector (1 .. Input'Length (1));
   begin

      Put_Line
        ("Values from http://en.wikipedia.org/wiki/Orthogonal_matrix");

      Result := Extensions.Eigenvalues (Input);

      for J in Result'Range loop
         Put (Result (J).Re, Exp => 0);
         Put (" ");
         Put (Result (J).Im, Exp => 0);
         New_Line;
      end loop;
      New_Line;

   end;

end Test_Extensions;

Re: Interfacing Ada with C

[John B. Matthews]

In article <m2k4o4dcxy.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:

> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
> 
> > On 08/05/2010 10:24 AM, Ada novice wrote:
> >>
> >> They are much more accurate and better results of course. I wonder 
> >> why Matlab tends to be give very "accurate" answers. Normally 15 
> >> digits of precision is also used there.
> >
> > You requested 15 decimal digits; your results are zero to 15 
> > decimal places. If you output in non-scientific notation you'd get 
> > zero; presumably that's what Matlab is doing.
> 
> The attached update uses fixed notation, looks rather better.
> 
> Note that the reason for the lack of precision in the Test16 results 
> is likely because the inputs are only specified to 6 digits.

YC: For what it's worth, I think of this in model/view terms: The 
subtype My_Float is a model of real numbers that is implemented as 
polynomials with some finite number of terms having binary 
coefficients. The package My_Float_IO provides a view of My_Float that 
is rounded to some finite number of displayed decimal digits, the 
default for which is My_Float'Digits-1.

[nice working update elided]

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Jacob Sparre Andersen]

Ada novice <posts@gmx.us> wrote:

> Can we change the subtype to Long_Long_Float? This will be of 18
> precision digits [...]

That's not guaranteed.  If you want 18 digits, you should declare the
type (My_Float?) as:

   type My_Float is digits 18;

Jacob
--
Jacob Sparre Andersen Research & Innovation
Vesterbrogade 148K, 1. th.
1620 K�benhavn V
Danmark

Phone:    +45 21 49 08 04
E-mail:   jacob@jacob-sparre.dk
Web-sted: http://www.jacob-sparre.dk/

Re: Interfacing Ada with C

[sjw]

On Aug 5, 6:24 pm, Ada novice <po...@gmx.us> wrote:

> On Aug 5, 3:57 pm, sjw <simon.j.wri...@mac.com> wrote:
>
> > Although LAPACK/BLAS (at 3.2.2 anyway) allow you to build with
> > extended precision (80-bit floats, GNAT Long_Long_Float if on x86
> > hardware) GNAT's implementation of Generic * Arrays assumes the worst
> > case, ie BLAS/LAPACK only available in single & double precision; and
> > if the type in use (My_Float in my test case) doesn't match Fortran
> > single or double precision it converts to double precision, makes the
> > call, then converts back.
>
> Can we change the subtype to Long_Long_Float? This will be of 18
> precision digits and "more" precise than Fortran's double precision.
> It would be like asking for more precision that can be offered. Did I
> understand you correctly?

You can change to Long_Long_Float, and on an Intel machine that will
use 80 bits (on a PowerPC it won't; Long_Long_Float is the same as
Long_Float, because the FPU on a PPC doesn't support extended
precision (AFAIK)).

*BUT* *BUT* *BUT* the internals of the matrix operations (the standard
ones and our extensions) only use 64 bits. So the apparent extra
precision is fool's gold.

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Fri, 06 Aug 2010 10:04:24 +0200, Jacob Sparre Andersen wrote:

> Ada novice <posts@gmx.us> wrote:
> 
>> Can we change the subtype to Long_Long_Float? This will be of 18
>> precision digits [...]
> 
> That's not guaranteed.  If you want 18 digits, you should declare the
> type (My_Float?) as:
> 
>    type My_Float is digits 18;

Further, practically you should never use subtype in the form

   subtype My_Float is Long_Float;

except for special cases like:

   subtype Non_IEEE_Float is Long_Float range Long_Float'Range;

or

   subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

On Aug 5, 10:25 pm, Simon Wright <si...@pushface.org> wrote:
>
> The attached update uses fixed notation, looks rather better.

Thanks for the revised code Simon.

YC

Re: Interfacing Ada with C

[Ada novice]

On Aug 5, 7:59 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:
>
> You requested 15 decimal digits; your results are zero to 15 decimal places. If
> you output in non-scientific notation you'd get zero; presumably that's what
> Matlab is doing.
>

Thanks. This makes sense. Matlab is using decimal notation and works
to 15 digits of precision. Hence we won't see when the most
significant digit has power "e-17" say in scientific notation.

YC

Re: Interfacing Ada with C

[Ada novice]

On Aug 6, 10:42 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Further, practically you should never use subtype in the form
>
>    subtype My_Float is Long_Float;
>
> except for special cases like:
>
>    subtype Non_IEEE_Float is Long_Float range Long_Float'Range;
>
> or
>
>    subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;

Thanks. Why is  subtype My_Float is Long_Float not proper? Is it
because it's a subtype and not a parent type? Because we haven't
specified what's the parent type is and a subtype is only a parent
type with a limited range. So this is why

 subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;

as you wrote makes sense I guess as we are limiting the range?

What about "type My_Float is digits 18" as Jacob Sparre Andersen said
in an earlier message? This is not a subtype and should be
theoretically proper. Am I right? But sjw in an earlier message
mentions that the "internals of the matrix operations only use 64
bits. So in any case then asking for more than Long-Float precision is
not "relevant".


YC

Re: Interfacing Ada with C

[Peter Hermann]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:
>    type My_Float is digits 18;

14 will run everywhere,
18 not.

ph

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Fri, 6 Aug 2010 02:26:22 -0700 (PDT), Ada novice wrote:

> On Aug 6, 10:42�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Further, practically you should never use subtype in the form
>>
>> � �subtype My_Float is Long_Float;
>>
>> except for special cases like:
>>
>> � �subtype Non_IEEE_Float is Long_Float range Long_Float'Range;
>>
>> or
>>
>> � �subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;
> 
> Thanks. Why is  subtype My_Float is Long_Float not proper? Is it
> because it's a subtype and not a parent type?

Because it does not tell anything about My_Float. When you declare a
subtype you should have a reason for it. The only reason is putting a
constraint on it. (Another might be type renaming, but that is an Ada
kludge)

> What about "type My_Float is digits 18" as Jacob Sparre Andersen said
> in an earlier message?

If you wanted a type of defined accuracy.

It depends on what you want to achieve:

1. Constraining -> Subtype

2. Requiring certain accuracy/precision -> Type

3. Interfacing -> A type from some library package like Interfaces.C

4. Separation of domains (e.g. measurement units etc) -> Type

5. Type extension, reimplementation -> type T is private; and in the
private part: type T is new Float;

> But sjw in an earlier message
> mentions that the "internals of the matrix operations only use 64
> bits. So in any case then asking for more than Long-Float precision is
> not "relevant".

That would be the case 3.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

On Aug 6, 11:49 am, Peter Hermann <h...@h.de> wrote:
> Jacob Sparre Andersen <ja...@jacob-sparre.dk> wrote:
>
> >    type My_Float is digits 18;
>
> 14 will run everywhere,
> 18 not.
>
> ph

Is this because all (modern) platforms/architectures can easily
provide for 14 but not for 18? Most likely, all 32-bit Intel machines
are able to provide for 18. Am I right?

YC

Re: Interfacing Ada with C

[Ada novice]

On Aug 6, 11:51 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> Because it does not tell anything about My_Float. When you declare a
> subtype you should have a reason for it. The only reason is putting a
> constraint on it. (Another might be type renaming, but that is an Ada
> kludge)
>
> > What about "type My_Float is digits 18" as Jacob Sparre Andersen said
> > in an earlier message?
>
> If you wanted a type of defined accuracy.
>
> It depends on what you want to achieve:
>
> 1. Constraining -> Subtype
>
> 2. Requiring certain accuracy/precision -> Type
>
> 3. Interfacing -> A type from some library package like Interfaces.C
>
> 4. Separation of domains (e.g. measurement units etc) -> Type
>
> 5. Type extension, reimplementation -> type T is private; and in the
> private part: type T is new Float;
>
> > But sjw in an earlier message
> > mentions that the "internals of the matrix operations only use 64
> > bits. So in any case then asking for more than Long-Float precision is
> > not "relevant".
>
> That would be the case 3.
>

Thanks for the explanations.

YC

Re: Interfacing Ada with C

[Simon Wright]

Jacob Sparre Andersen <jacob@jacob-sparre.dk> writes:

> Ada novice <posts@gmx.us> wrote:
>
>> Can we change the subtype to Long_Long_Float? This will be of 18
>> precision digits [...]
>
> That's not guaranteed.  If you want 18 digits, you should declare the
> type (My_Float?) as:
>
>    type My_Float is digits 18;

And if you build on a PowerPC Mac the compiler will refuse because that
precision isn't implemented.

Re: Interfacing Ada with C

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 06 Aug 2010 10:04:24 +0200, Jacob Sparre Andersen wrote:
>
>> Ada novice <posts@gmx.us> wrote:
>> 
>>> Can we change the subtype to Long_Long_Float? This will be of 18
>>> precision digits [...]
>> 
>> That's not guaranteed.  If you want 18 digits, you should declare the
>> type (My_Float?) as:
>> 
>>    type My_Float is digits 18;
>
> Further, practically you should never use subtype in the form
>
>    subtype My_Float is Long_Float;
>
> except for special cases like:
>
>    subtype Non_IEEE_Float is Long_Float range Long_Float'Range;
>
> or
>
>    subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;

Depends what you mean by "practically".

The thought process was, "I'm going to be writing a set of demo cases
which should work for arbitrary floating-point types, I'll call the type
My_Float. Shall I use type My_Float is new ... or subtype My_Float is
...? Doesn't really matter, go for subtype."

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Fri, 06 Aug 2010 17:49:14 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Fri, 06 Aug 2010 10:04:24 +0200, Jacob Sparre Andersen wrote:
>>
>>> Ada novice <posts@gmx.us> wrote:
>>> 
>>>> Can we change the subtype to Long_Long_Float? This will be of 18
>>>> precision digits [...]
>>> 
>>> That's not guaranteed.  If you want 18 digits, you should declare the
>>> type (My_Float?) as:
>>> 
>>>    type My_Float is digits 18;
>>
>> Further, practically you should never use subtype in the form
>>
>>    subtype My_Float is Long_Float;
>>
>> except for special cases like:
>>
>>    subtype Non_IEEE_Float is Long_Float range Long_Float'Range;
>>
>> or
>>
>>    subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;
> 
> Depends what you mean by "practically".
> 
> The thought process was, "I'm going to be writing a set of demo cases
> which should work for arbitrary floating-point types, I'll call the type
> My_Float. Shall I use type My_Float is new ... or subtype My_Float is
> ...? Doesn't really matter, go for subtype."

I am not sure what do you mean. If the code meant to be used with any type,
then it should be generic (My_Float is digits <>). If the code is to work
with some yet unknown type (to be determined later) then it should be
My_Float is new Long_Float. That would protect me from mixing Long_Float
and My_Float.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

Hi guys, thanks for raising these subtle points. It's very informative
to read the discussions.

YC

Re: Interfacing Ada with C

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Fri, 06 Aug 2010 17:49:14 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> On Fri, 06 Aug 2010 10:04:24 +0200, Jacob Sparre Andersen wrote:
>>>
>>>> Ada novice <posts@gmx.us> wrote:
>>>> 
>>>>> Can we change the subtype to Long_Long_Float? This will be of 18
>>>>> precision digits [...]
>>>> 
>>>> That's not guaranteed.  If you want 18 digits, you should declare the
>>>> type (My_Float?) as:
>>>> 
>>>>    type My_Float is digits 18;
>>>
>>> Further, practically you should never use subtype in the form
>>>
>>>    subtype My_Float is Long_Float;
>>>
>>> except for special cases like:
>>>
>>>    subtype Non_IEEE_Float is Long_Float range Long_Float'Range;
>>>
>>> or
>>>
>>>    subtype Non_Negative_Float is Long_Float range 0.0..Long_Float'Last;
>> 
>> Depends what you mean by "practically".
>> 
>> The thought process was, "I'm going to be writing a set of demo cases
>> which should work for arbitrary floating-point types, I'll call the type
>> My_Float. Shall I use type My_Float is new ... or subtype My_Float is
>> ...? Doesn't really matter, go for subtype."
>
> I am not sure what do you mean. If the code meant to be used with any type,
> then it should be generic (My_Float is digits <>). If the code is to work
> with some yet unknown type (to be determined later) then it should be
> My_Float is new Long_Float. That would protect me from mixing Long_Float
> and My_Float.

You're clearly right for serious code (in this case, for serious unit
tests which I may well make generic). But this wasn't a serious test, it
was an exploratory hack. Perhaps I shouldn't have let it out into the
wild without a bit more polishing.

I do feel that writing a demo like this one as a set of generics
instantiated for various floating types would probably have obscured the
point.

Re: Interfacing Ada with C

[John B. Matthews]

In article <m2pqxvbi8l.fsf@pushface.org>,
 Simon Wright <simon@pushface.org> wrote:

[...]
> >> The thought process was, "I'm going to be writing a set of demo 
> >> cases which should work for arbitrary floating-point types, I'll 
> >> call the type My_Float. Shall I use type My_Float is new ... or 
> >> subtype My_Float is ...? Doesn't really matter, go for subtype."
> >
> > I am not sure what do you mean. If the code meant to be used with 
> > any type, then it should be generic (My_Float is digits <>). If the 
> > code is to work with some yet unknown type (to be determined later) 
> > then it should be My_Float is new Long_Float. That would protect me 
> > from mixing Long_Float and My_Float.
> 
> You're clearly right for serious code (in this case, for serious unit 
> tests which I may well make generic). But this wasn't a serious test, 
> it was an exploratory hack. Perhaps I shouldn't have let it out into 
> the wild without a bit more polishing.

No! Release Early, Release Often:

<http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html>

> I do feel that writing a demo like this one as a set of generics 
> instantiated for various floating types would probably have obscured 
> the point.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Interfacing Ada with C

[Randy Brukardt]

"Ada novice" <posts@gmx.us> wrote in message 
news:aca699e9-90a9-4fba-b424-b75d249e260e@z10g2000yqb.googlegroups.com...
>On Aug 6, 11:49 am, Peter Hermann <h...@h.de> wrote:
>...
>> 14 will run everywhere,
>> 18 not.
>>
>> ph
>
>Is this because all (modern) platforms/architectures can easily
>provide for 14 but not for 18? Most likely, all 32-bit Intel machines
>are able to provide for 18. Am I right?

Intel architectures might, but that doesn't mean that Ada compilers will. 
Most of the early Ada compilers (for Ada 83) didn't support anything beyond 
digits 15. Janus/Ada still doesn't. The original reason was that I couldn't 
be sure that the operations on the 80-bit type met the Ada 83 requirements 
for numeric precision.

It's OK to ignore those requirements in Ada 95 (unless you are running in 
"strict" mode), but I don't think most compilers actually have separate 
strict and relaxed modes. In any case, it might very well be OK to support 
the 80-bit type, I've just never tried to figure out whether it is. (The 
majority of ACATS tests only apply to Float, Short_Float, and Long_Float, so 
those tests wouldn't apply to the 80-bit type anyway, so passing the ACATS 
doesn't prove anything either way.)

Besides, there is no analog to those types on any other processor that we 
ever considered porting Janus/Ada to; we wanted code to be reasonably 
portable between implementations.

Obviously, GNAT has made a different choice, but it's not one I would count 
on being available elsewhere.

                         Randy.


YC 

Re: Interfacing Ada with C

[Dmitry A. Kazakov]

On Fri, 06 Aug 2010 20:46:37 -0400, John B. Matthews wrote:

> In article <m2pqxvbi8l.fsf@pushface.org>,
>  Simon Wright <simon@pushface.org> wrote:
>
>> Perhaps I shouldn't have let it out into 
>> the wild without a bit more polishing.
> 
> No! Release Early, Release Often:
> 
> <http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html>

Yes!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interfacing Ada with C

[Ada novice]

On Aug 7, 6:07 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> Intel architectures might, but that doesn't mean that Ada compilers will.
> Most of the early Ada compilers (for Ada 83) didn't support anything beyond
> digits 15. Janus/Ada still doesn't. The original reason was that I couldn't
> be sure that the operations on the 80-bit type met the Ada 83 requirements
> for numeric precision.
>
> It's OK to ignore those requirements in Ada 95 (unless you are running in
> "strict" mode), but I don't think most compilers actually have separate
> strict and relaxed modes. In any case, it might very well be OK to support
> the 80-bit type, I've just never tried to figure out whether it is. (The
> majority of ACATS tests only apply to Float, Short_Float, and Long_Float, so
> those tests wouldn't apply to the 80-bit type anyway, so passing the ACATS
> doesn't prove anything either way.)
>

Thanks. Long_Float with its 15 precision digits is very much enough
for any numerical calculation in my opinion.

YC

Re: Interfacing Ada with C

[Georg Bauhaus]

On 8/7/10 2:46 AM, John B. Matthews wrote:

> No! Release Early, Release Often:
>
> <http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html>

Maybe after injecting some of Ada 2012 in the sense of
http://research.microsoft.com/en-us/people/thoare/assertearlyassertoften.ppt

Simplifying_Assumption in particular?



Georg

Re: Interfacing Ada with C

[John B. Matthews]

In article <4c5d22e0$0$7661$9b4e6d93@newsspool1.arcor-online.net>,
 Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:

> On 8/7/10 2:46 AM, John B. Matthews wrote:
> 
> > No! Release Early, Release Often:
> >
> > <http://catb.org/esr/writings/homesteading/cathedral-bazaar/ar01s04.html>
> 
> Maybe after injecting some of Ada 2012 in the sense of
> http://research.microsoft.com/en-us/people/thoare/assertearlyassertoften.ppt
> 
> Simplifying_Assumption in particular?

I think so, but I'm not sure how to apply the principle.

Ada.Numerics.Generic_Complex_Arrays.Extensions is generic, but it has no 
generic parameters; the formal parameters of its subprograms are 
instances of types defined in Generic_Complex_Types and 
Generic_Complex_Arrays. IIUC, the assertion in the test program would be 
that those instantiations succeeded at compile-time (slide 10).

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>