Slight recode of gsll/data/permutations.lisp (Re: Bugfix for gsll/data/permutations.lisp)

[Mirko Vukovic]

I got an account on gitlab.  I need to find a time slot to work on this, so
no progress in next few days.

Thanks for the coding suggestions.

Mirko

On Mon, Jan 4, 2016 at 7:18 AM, Mirko Vukovic <mirko.vukovic at gmail.com>
wrote:

> Hi Liam,
>
> thanks for the feedback.  I will get an account on gitlab.
>
> Mirko
>
> On Fri, Jan 1, 2016 at 1:12 PM, Liam Healy <lhealy at common-lisp.net> wrote:
>
>> Thanks for these patches. I think that GSLL should use the GSL
>> functions for permutations and combinations rather than relying on the
>> foreign representation as vectors (and the wrong type, too, as you
>> discovered). There is some loss of use of grid functions for
>> manipulation, but I never used that anyway (and I doubt anyone else
>> did).
>>
>> However, I would make some changes. Please use defmobject to define
>> the permutation and combination classes. It defines the interface to
>> GSL following GSL's standard way of naming functions. Second, GSLL
>> does not define interfaces to any _calloc functions, relying instead
>> on separate functions for clearing/resetting the data (and GSL always
>> defines a function for doing that). I'm not sure of the value of the
>> _calloc functions, but if they are thought useful, they should be
>> defined for every mobject and thus need a change in defmobject. So, I
>> would eliminate the :initialize keyword for now.
>>
>> The best way to learn how to use defmobject is to look at the other
>> uses of it in GSLL. When you write something, you can macroexpand it
>> to see that what comes out looks correct. Try macroexpanding the
>> defmobject histogram form and see how the interface to the foreign
>> object and functions is defined.
>>
>> I have created an issue at
>> https://gitlab.common-lisp.net/antik/gsll/issues/2. If you want to
>> register as a user on gitlab.common-lisp.net, I can assign it to you
>> and we can continue discussion and patches there. Thanks again.
>>
>> Liam
>>
>> On Sun, Nov 29, 2015 at 10:02 AM, Mirko Vukovic <mirko.vukovic at gmail.com>
>> wrote:
>> > This is a follow-up on the previous patch.
>> >
>> > I applied the same principles on data/combination.lisp and recoded using
>> > GSL's combination functions only.  Again this cleared up some errors or
>> > failures on my end.
>> >
>> > I hope that I did not mangle major pieces of your design intent.
>> >
>> > Mirko
>> >
>> >
>> > On Fri, Nov 27, 2015 at 10:43 PM, Mirko Vukovic <
>> mirko.vukovic at gmail.com>
>> > wrote:
>> >>
>> >> Liam,
>> >>
>> >> I am not trying to bludgeon this issue to death nor convince the you
>> that
>> >> I am right and you are wrong.
>> >>
>> >> In a nutshell, I started on this path because of exception errors when
>> >> trying to
>> >> load GSLL on Windows (SBCL or CCL) using GSL compiled MinGW64.  I
>> >> traced this to the initialization of the permutation structures and the
>> >> size of
>> >> the requested memory (see recent post on CFFI mailing list).
>> >>
>> >> I decided to rewrite a small part of permutation.lisp to use GSL's
>> code to
>> >> directly
>> >> initialize and query permutation structure.  The attached patch
>> contains
>> >> the
>> >> rewrite and some minor edits.  All the permutation and qrpt tests pass.
>> >>
>> >> The patch should be considered a proof-of-concept (or failure of
>> concept).
>> >>
>> >> For me, this patch has cleared the exception errors that have started
>> me
>> >> on this
>> >> trek.  Even if it is not accepted, I learned something, and it was fun.
>> >> And I can
>> >> keep it on my GSLL so that it runs for me.
>> >>
>> >> Best,
>> >>
>> >> Mirko
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Nov 26, 2015 at 10:24 AM, Liam Healy <lhealy at common-lisp.net>
>> >> wrote:
>> >>>
>> >>> Added thought: you can lookup any GSL (C) function to find the CL
>> >>> equivalent by using gsl-lookup. So for example
>> >>>
>> >>> (gsl:gsl-lookup "gsl_permute_vector")
>> >>> PERMUTE
>> >>> T
>> >>>
>> >>> tells you #'permute is the function you want. If there is no
>> >>> equivalent (there are some C functions with no interface in CL), you
>> >>> will get NIL as the return value of this function.
>> >>>
>> >>> Liam
>> >>>
>> >>>
>> >>> On Wed, Nov 25, 2015 at 11:20 PM, Mirko Vukovic <
>> mirko.vukovic at gmail.com>
>> >>> wrote:
>> >>> > Thanks for the explanations - I missed the :generic and :method
>> >>> > specifiers.
>> >>> > I'll study the macro-expansions.
>> >>> >
>> >>> > Sorry for the noise.
>> >>> >
>> >>> > Mirko
>> >>> >
>> >>> > On Tue, Nov 24, 2015 at 10:16 PM, Liam Healy <
>> lhealy at common-lisp.net>
>> >>> > wrote:
>> >>> >>
>> >>> >> The original code looks right to me.
>> >>> >>
>> >>> >> You have taken the generic function and the associated foreign
>> vector
>> >>> >> methods #'permute and gratuitously renamed them #'permute-vector,
>> >>> >> leaving the method for raw C pointer with the original name and no
>> >>> >> generic function. Then you completely delete the generic function
>> and
>> >>> >> vector methods for #'permute-inverse for no apparent reason,
>> leaving a
>> >>> >> method for the raw C pointer only.
>> >>> >>
>> >>> >> There is no duplicated code here. There is certainly the
>> equivalent of
>> >>> >> gsl_permute_vector, it is the GRID:VECTOR-DOUBLE-FLOAT (second arg)
>> >>> >> method of #'permute (which you renamed).
>> >>> >>
>> >>> >> I recommend macroexpansion as a way of seeing what's being
>> defined. If
>> >>> >> you use emacs, place the cursor on the defmfun line and do C-c C-m.
>> >>> >> Then you will see all the generic functions and methods, and you
>> will
>> >>> >> see there is no error in the original code.
>> >>> >>
>> >>> >> On Tue, Nov 24, 2015 at 5:43 PM, Mirko Vukovic
>> >>> >> <mirko.vukovic at gmail.com>
>> >>> >> wrote:
>> >>> >> > Because of a typo, GSLL did not have the equivalent of
>> >>> >> > GSL_PERMUTE_VECTOR.
>> >>> >> >
>> >>> >> > There was also a section of duplicated code.
>> >>> >> >
>> >>> >> > This patch should fix these errors.
>> >>> >> >
>> >>> >> > NOTE: I did not test this patch - My GSLL system is not behaving
>> >>> >> > super-cleanly on MSYS2 and GSL2.1.  Proceed with care.
>> >>> >> >
>> >>> >> > Mirko
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20160122/fb225847/attachment.html>