Ciao, I wonder if someone can suggest me a somewhat efficient way to handle memory allocation and result storage for 'gsl_odeiv_evolve_apply()' micro steps results.
In my library I use the ODE solver in the same way 'lsode' is used in GNU Octave: select a vector of time steps and let the solver compute the evolution in each step. Octave does not allow access to micro step results. The GSL function allows us access these results, but their number is not known in advance, hence the need to select a memory allocation and value storage policy. I want the final result to be a GSL matrix with each state's values stored in a row. If I store the result in this way I cannot reallocate the block of memory without reordering the values. But if I store the state in a column I finally have to transpose the values, can it be done in place? I thought that this problem may be similar to the string memory management in scripting languages. Example: when TCL first allocates memory for a string it gives to it just enough bytes to hold all the chars; if a char is appended TCL reallocates the string doubling its size, and so on: each time the memory is full it is reallocated with doubled size. They say that this, experimentally, works fine. Another possibility is to allocate a linked list of matrices, but it requires more memory and infrastructure. TIA. -- Marco Maggi _______________________________________________ Help-gsl mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gsl
