Re: 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 
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  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 
>> 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.vuko...@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 
>> >> 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.vuko...@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 <
>> lhe...@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 

Re: 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  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 
> 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  >
> > 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 
> >> 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.vuko...@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  >
> >>> > 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 

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

[Liam Healy]

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  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 
> 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 
>> 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 
>>> 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 
>>> > 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
>>> >> 
>>> >> wrote:
>>> >> > Because of a typo, GSLL did not have the equivalent of
>>> >> > GSL_PERMUTE_VECTOR.
>>> 

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

[Mirko Vukovic]

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  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 
> 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 
> 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  >
> >> 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
> >
> >
>


0005-Adapted-data-permutation.lisp-to-use-GSL-s-native-st.patch
Description: Binary data

Re: Bugfix for gsll/data/permutations.lisp

[Liam Healy]

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  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