gsll-devel May 2011

gsll-devel@common-lisp.net

3 participants
3 discussions

Re: [GSLL-devel] [PATCH] ode-system: 'next-step' should be exported
by Liam Healy 04 May '11

04 May '11

On Wed, May 4, 2011 at 2:18 PM, Matt Peddie <mpeddie(a)gmail.com> wrote: > Liam, > > On Wed, May 04, 2011 at 10:20:42AM -0400, Liam Healy wrote: > > Unless I'm misunderstanding this request, this is already possible, in > > fact I'd regard it as the basic usage. Perhaps you are thrown off by > > the with-ode-integration macro and example. > > Great! I followed the example to begin with, so that was my starting > point. > > > I made up this macro in order to easily accommodate the case of > > non-array usage in the ODE solvers, because I wanted to show a simple > > example with scalars. However if you look at how that macro expands, > > there is a symbol #:DEP that is bound to a foreign array with the > > appropriate dimensions: > > > > [ macro definition ] > > > > So what you want to do is mimic this form, but instead define your > > foreign array directly. Is this what you're asking about? If it's an > > issue of CL array vs. foreign array, then you can use #'cl-array or > > just copy it over at the beginning and end. > > Thanks. I saw the way that DEP works within the macro, and I rewrote it > a few times in an attempt to pass around the array directly and use > grid:gref inside my dynamics function. I guess I just need to try a few > more things (like I said, newbie here). I want to use the foreign array > and avoid copying. > > > P.S. Please join the mailing list to post. Thank you. > > I joined right after I got the `your message needs to be approved' mail; > sorry. > > Matt > Good. Having said all that, I think there is definitely room for a more meaningful and more general macro than with-ode-integration. Though I'd like GSLL to be easier to use than GSL, at least calling make-ode-stepper, make-y-control, make-ode-evolution, apply-evolution, etc. on your own isn't any worse than GSL. And the macro expansion is what I would use as a "tutorial"; I understand for a CL newcomer it's still a tough task. Liam

1 0

Re: [GSLL-devel] [PATCH] ode-system: 'next-step' should be exported
by Matt Peddie 04 May '11

04 May '11

Hi, On Fri, 8 Apr 2011 at 15:44:08, Fedor Bezrukov <Fedor.Bezrukov(a)physik.uni-muenchen.de> wrote: > Though one thing is definitely needed (I'll think of it when I have > some time) -- ability to make the function for the ode to get and > return the arguments as an array -- quite a common case if you want to > solve a large system of differential equations (eg, inital value > problem for an ODE) I'd really, really like to use this array functionality. I know nothing about CFFI and am a gsll newbie, but I'm willing to help if I can. Matt

2 2

[GSLL-devel] [GSD] Time making large foreign-arrays vs large arrays
by Sumant Oemrawsingh 03 May '11

03 May '11

Hi, I ran into a problem making foreign arrays. I have a two lists of lists of floats called *data-50* and *data-1024*, which are to be used as the initial contents of a matrix (first is 50x50, second 1024x1024). I do the following: CL-USER> (time (type-of (make-grid '((array) single-float) :initial-contents *data-50*))) Evaluation took: 0.000 seconds of real time 0.000000 seconds of total run time (0.000000 user, 0.000000 system) 100.00% CPU 228,096 processor cycles 27,744 bytes consed (SIMPLE-ARRAY SINGLE-FLOAT (50 50)) CL-USER> (time (type-of (make-grid '((foreign-array) single-float) :initial-contents *data-50*))) Evaluation took: 0.036 seconds of real time 0.026995 seconds of total run time (0.026995 user, 0.000000 system) 75.00% CPU 79,104,003 processor cycles 294,688 bytes consed MATRIX-SINGLE-FLOAT With a 50x50 array, everything works out fine. However, when moving to the 1024x1024 data: CL-USER> (time (type-of (make-grid '((array) single-float) :initial-contents *data-1024*))) Evaluation took: 0.036 seconds of real time 0.035995 seconds of total run time (0.034995 user, 0.001000 system) 100.00% CPU 80,301,650 processor cycles 4,194,320 bytes consed (SIMPLE-ARRAY SINGLE-FLOAT (1024 1024)) CL-USER> (time (type-of (make-grid '((foreign-array) single-float) :initial-contents *data-1024*))) Evaluation took: 686.167 seconds of real time 683.878034 seconds of total run time (683.608075 user, 0.269959 system) [ Run times consist of 0.196 seconds GC time, and 683.683 seconds non-GC time. ] 99.67% CPU 3 forms interpreted 1,502,208,488,440 processor cycles 59,838,352 bytes consed before it was aborted by a non-local transfer of control. ; Evaluation aborted on NIL. After over 10 minutes of intensive work, I gave up and aborted. When using make-foreign-array directly, instead of make-grid, I get the same problem. I would understand that foreign arrays take a bit more time to make; in the *data-50* example, about an order of magnitude more bytes were consed to make the foreign array (and needing more processor cycles). While this is not very thorough, I would expect there to be some linear relation between the array size and the time it takes. E.g. 50x50 foreign array takes less than a 0.1 second, so I would expect 1024x1024 to take less than 42.0 seconds. While that is still a long time for a normal-sized array, clearly, this is not the case. I can run some more tests later to find out where the problem lies. Or is this a known bug or limitation for foreign arrays and sbcl? Or am I just doing something wrong here? Thanks, Sumant -- Sumant Oemrawsingh

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel May 2011