Re: [OF] Gold codes in communication pkg?

[Carnë Draug]

On 4 June 2014 10:38, Juan Pablo Carbajal <address@hidden> wrote:
> On Wed, Jun 4, 2014 at 11:28 AM, Carnë Draug <address@hidden> wrote:
>> On 4 June 2014 10:05, Juan Pablo Carbajal <address@hidden> wrote:
>>> On Tue, Jun 3, 2014 at 12:21 PM, Juan Pablo Carbajal
>>> <address@hidden> wrote:
>>>> On Tue, Jun 3, 2014 at 1:05 AM, Carnë Draug <address@hidden> wrote:
>>>>> On 2 June 2014 19:02, Juan Pablo Carbajal <address@hidden> wrote:
>>>>>> On Mon, Jun 2, 2014 at 3:41 PM, Carnë Draug <address@hidden> wrote:
>>>>>>> On 1 June 2014 13:08, Juan Pablo Carbajal <address@hidden> wrote:
>>>>>>>> I was checking the communication package. Is there a function to
>>>>>>>> generate Gold codes (or maximum length sequences)?
>>>>>>>> If not I could contribute such (simple) function.
>>>>>>>
>>>>>>> Would be nice if you could make a Matlab compatible version of such
>>>>>>> function [1]. This would make it dependent on a development version of
>>>>>>> Octave since it will require classdef.
>>>>>>>
>>>>>>> Carnë
>>>>>>>
>>>>>>> [1] 
>>>>>>> http://www.mathworks.co.uk/help/comm/ref/comm.goldsequence-class.html
>>>>>>
>>>>>> How exactly do you suggest to proceed to make something compatible?
>>>>>> That is an object not a function, as was my offer.
>>>>>>
>>>>>> Even if one provides an option parser that accepts and works more or
>>>>>> less similarly, this will still be completely not-portable, since
>>>>>> other methods are needed for the generation and administration of the
>>>>>> sequence.
>>>>>
>>>>> Well, it's your work so you can do whichever way is better for you.
>>>>> ideally, you could write it using classdef (Matlab compatible), use it
>>>>> in your own work (if you are using development version), and then we
>>>>> would only release it as part of the communications package once
>>>>> classdef is also released (4.2). It wouldn't be the first time we hold
>>>>> packages releases until a specific Octave release happens. Or you
>>>>> could simply branch comm for stuff that will be dependent on 4.2 so
>>>>> others can continue working and releasing the communications package.
>>>>>
>>>>> I guess this would be the ideal case. I'm unsure if the current state
>>>>> of classdef is enough to implement the goldsequence options you
>>>>> specifically want, if using development version is acceptable for your
>>>>> work, or if you have the extra time working with classdef may take.
>>>>>
>>>>> Carnë
>>>>
>>>> Hi Carnë,
>>>>
>>>> I see, it doesn't sound like heaven to me. I do not use classdef and
>>>> so far I haven't had the need to do so.
>>>> So this would be extra work that I am not sure I can afford at the moment.
>>>> I will try to implement a core gold sequence generator that could
>>>> eventually be ported to classdef (though I think there is not such
>>>> thing as classdef portable, being such a different paradigm).
>>>> If that is the plan then I wont spend time implementing all the
>>>> details of the matlab interface.
>>>>
>>>> I guess this is the best I can offer at the moment.
>>>>
>>>> Cheers
>>>
>>> Hi again,
>>>
>>> Gold sequence generator was added to the communication packabe between
>>> 2010b and 2014b. However the pseudo random sequence generator (aka
>>> maximum length sequence, m-code, m-sequence, linear feedback shift
>>> registers, etc...) was there already in 2010b.
>>>
>>> In the views of an eventual classdef implementation. What would be
>>> easy to start with:
>>> 1) A function with inputParser options?
>>> 2) An old style object?
>>>
>>> Yes, I understand it would be better to just provide a classdef
>>> object, but I can do it at the moment. Is it preferable not to have
>>> any implementation?
>>
>> I really ought to replace the current inputParser in the general
>> package with a Matlab compatible version in core. And they are not
>> compatible so I won't recommend you that.
>>
>> Carnë
>
> Shall I understand then that and old style object is preferred?

You don't really need inputParser to implement the same type of API.
It's a nice helper function but it's not a requirement, and in some
cases it's even easier to not use it.

I'd say just implement whatever is more sensible to you. Either way,
it will be targeted for deprecation one day for replacement with the
Matlab compatible version (if we actually ever get to do it is a
completely different story).

Carnë