[Scilab-Dev] Gmp in scilab revisited.

Jonathan Blanchard BlanchardJ at ieee.org
Tue Sep 30 19:09:03 CEST 2008


Well hum I don't know if I should discuss my current strategy as most
computer programming expert would kill me because of it.

Right now I only wanted to test using gmp in Scilab so I needed
something to hole my gmp variable. I choose to use the matrix of
double type for a quick hack. It's kind of weird as the matrix doesn't
hold meaningful value when seen as a matrix of double but it's just a
temporary hack.

So I had two way of doing this. The first one :

void C2F(GmpCreateVarFromPtr) ( int StkPos, mpz_t GmpVar, int *StkAdd  )
{
  int m1 = 2;
  int n1 = 1;
  CreateVar(StkPos,MATRIX_OF_DOUBLE_DATATYPE, &m1, &n1, StkAdd);

  memcpy( stk(*StkAdd), (void*)GmpVar, 12 );

  return;
}

It just memcpy the mpz operand inside the memory allocated to a matrix
of double. The value of the operand stay in the heap allocated by
malloc. In this situation if the initial Scilab variable is destroyed
it's a memory leak as some memory is not freed. If Scilab would
somehow be aware of the it would be simple to free the memory when
variable are cleared from the stack. This approach have the advantages
of being relatively fast and using gmp in scilab would be very fast.
And would approach native speed for big operands as the call overhead
would only be a small portion of the processing done.

Second solution is basically the same thing but the whole limb of the
gmp operand is copied inside the Scilab stack. This is kind of slow in
the long run but ensure that all the memory is freed. This is a bit
like you said, using an mlist would be better for this purpose but
then again if you overload some operators aren't you overloading the
mlist type and not a new type you defined yourself?

As I said this is just a quick hack. In a perfect world a native
Scilab type would be better but this is a bit to complicated to me and
cannot be bundled in a toolbox. I also do not know what are the
policies and enthusiasm of the Scilab developers to integrate external
contributions in the core code.

Jonathan Blanchard



On Tue, Sep 30, 2008 at 1:47 PM, Collette Yann <ycollet at freesurf.fr> wrote:
> Good example.
> With a pointer stored in a structure: it's the mess.
> With a "binary array" stored in a mlist of this kind:
> mlist(['gmplist','array'],[])
> it should be better. The memory is managed by scilab, in the array, you
> always allocate a multiple of typeof(double) so as to store your gmp number.
> You have to write 2 functions: one to translate a gmp struct into an array
> of double and another to translate an array of double into gmp struct.
>
>
> What was your strategy ? Do you store gmp numbers into strings ?
>
> YC
>
> Jonathan Blanchard a écrit :
>>
>> I see what you mean I think. But what happen when it get destroyed.
>> Let say for example the following code.
>>
>> a = gmpinit(123);
>> b = gmpinit(234);
>>
>> a = gmpmul(a,b);
>>
>> In this code the initial variable 'a' get cleared but if memory was
>> allocated out of the Scilab stack it won't be freed.
>>
>> Jonathan Blanchard
>>
>>
>>
>>
>
>



More information about the dev mailing list