[Gambas-devel] Problems in gb.gsl

[Randall Morgan]

2012/2/18 Benoît Minisini <gambas at ...1...>

> Here is a list of what I have detected (I may have missed some things!)
>
> 1) You cannot use 'Pointer' to implement the Complex.Frexp method. You
> must do differently. Maybe by returning a Variant[] with a Float and an
> Integer. Gambas cannot return more than one value.
>

   That's why I returned on value and modified the contents of another as
is typical C.
   However, I too felt this was not Basic like. I will look at a variant
solution.


>
> 2) gsl_frexp has nothing to do with complex numbers. So why do you put
> it in the Complex class?
>

   True. My only excuse is not enough coffee!


>
> 3) Arguments must be named the "Pascal" way: so you must write (X) in
> the signature, not (x).
>

   Ok. Changed this in all files and will add it to my list of notes.


>
> 4) "static GSLCOMPLEX *create_complex();" written in c_complex.h is a
> mistake. "static" means that the create_complex() function is private to
> the c_complex.c file. If you need to use create_complex() outside of
> c_complex.c, you must remove the 'static' keyword, and then you can
> declare it in the header file. Moreover, you will have to rename it so
> that we know that it is not static anymore: something like
> 'COMPLEX_create' (this is the convention I use).
>

   Ok, so static does more than just making it available before class
creation.
   Noted and added to my notes. Will change shortly.


>
> 5) You must update all your source file top commentaty with the true
> file name.
>

    Did this to my local files yesterday when I noticed the error. Should
be resolved on next check in.

>
> 6) GB.NewArray() and its fellows will help you to implement the
> Polynomial class: you just have to keep a 'double *' pointer, and these
> functions will do everything for you: allocating, freeing, increasing
> the array size, shrinking it. The 'len' field I put in the CPOLYNOMIAL
> structure is actually not needed, as GB.Count() returns the size of the
> array.
>

   Ok, will play more with them. I don't like the idea of limiting the
number of coefficients artificially.
   Since this is a scientific library their may be times when one wants to
use it in circumstances that
   are atypical. So dynamically allocating space and letting he machine
resources limit the library use
   I think is more appropriate. But I also want to do this in a manner that
is not wasteful or puts undo
   burden on the system. Hence my experiment with allocating a fixed number
of coefficients when we
   run out of space. I'm guessing I can do the same with GB.AllocArray and
friends.

   Thanks for your input and feedback,

   Randall




> Regards,
>
> --
> Benoît Minisini
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>



-- 
If you ask me if it can be done. The answer is YES, it can always be done.
The correct questions however are... What will it cost, and how long will
it take?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20120218/3dbc2c5c/attachment.html>