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

[Mirko Vukovic]

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/20160104/79570595/attachment.html>