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(a)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(a)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(a)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(a)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(a)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
>> >
>> >
>>
>
>
