On Sat, 14 Dec 2019 18:24:08 -0800 (PST), Rick C
<gnuarm.deletethisbit@gmail.com> wrote:
>On Saturday, December 14, 2019 at 5:52:32 PM UTC-5, Eric Jacobsen wrote:
>> On Thu, 12 Dec 2019 19:59:30 -0800 (PST), Rick C
>> <gnuarm.deletethisbit@gmail.com> wrote:
>>
>> >On Thursday, December 12, 2019 at 6:59:49 PM UTC-5, Eric Jacobsen wrote:
>> >> On Thu, 12 Dec 2019 11:07:19 -0800 (PST), Rick C
>> >> <gnuarm.deletethisbit@gmail.com> wrote:
>> >>=20
>> >> >On Wednesday, December 11, 2019 at 11:44:36 AM UTC-5, Eric Jacobsen wrot=
>> >e:
>> >> >> On Mon, 9 Dec 2019 18:46:53 -0800 (PST), Rick C
>> >> >> <gnuarm.deletethisbit@gmail.com> wrote:
>> >> >>=3D20
>> >> >> >On Monday, December 9, 2019 at 4:27:01 AM UTC-5, Richard (Rick) Lyons=
>> > wr=3D
>> >> >ote=3D3D
>> >> >> >:
>> >> >> >> Rick C.
>> >> >> >> You're being unreasonable by posting uncommented code here and then=
>> > ex=3D
>> >> >pec=3D3D
>> >> >> >ting someone to "simplify" that code for you. Then as Piergiorgio str=
>> >ugg=3D
>> >> >les=3D3D
>> >> >> > to try to help, you replied to him in a rude way.
>> >> >> >
>> >> >> >Sorry if anyone thought I was rude. I was asking what was not clear =
>> >abo=3D
>> >> >ut =3D3D
>> >> >> >the code.=3D3D20
>> >> >> >
>> >> >> >Not sure what you mean about "simplifying" the code. I listed the ra=
>> >the=3D
>> >> >r s=3D3D
>> >> >> >imple and straightforward code so it could be seen how the coefficien=
>> >ts =3D
>> >> >are=3D3D
>> >> >> > being generated. I don't even know what the language is and I was a=
>> >ble=3D
>> >> > to=3D3D
>> >> >> > undertstand was it was doing to a large degree. =3D3D20
>> >> >> >
>> >> >> >Sorry if my posts are not appropriate. I'm not sure what to say that=
>> > wo=3D
>> >> >uld=3D3D
>> >> >> > be better.=3D3D20
>> >> >> >
>> >> >> >--=3D3D20
>> >> >> >
>> >> >> > Rick C.
>> >> >> >
>> >> >> > -+ Get 1,000 miles of free Supercharging
>> >> >> > -+ Tesla referral code - https://ts.la/richard11209
>> >> >>=3D20
>> >> >> Your posts are not inappropriate and asking questions, even questions
>> >> >> about code, is fine. There will be a lot of folks, however, like
>> >> >> Piergiorgio and myself and many others, who just find reading somebody
>> >> >> else's code a struggle in itself.
>> >> >>=3D20
>> >> >> Everybody thinks code they've written is straightforward, because they
>> >> >> wrote it, but it's not obvious or easy to everybody else. I don't
>> >> >> even know what language that code is, or at least the syntax isn't
>> >> >> immediately obvious to me, and figuring it out and how the
>> >> >> coefficients are generated is just not how I want to spend any of my
>> >> >> time.
>> >> >>=3D20
>> >> >> It might be easy, but it isn't obvious enough to pass the
>> >> >> investigation threshold for some of us. That said, maybe somebody
>> >> >> else will come along and give it a shot.
>> >> >>=3D20
>> >> >> But don't be discouraged from asking questions or posting problems.
>> >> >> And don't let the old grumpy guys like me slow you down just because
>> >> >> we're not willing to do something.
>> >> >
>> >> >Thanks for the reply.=3D20
>> >> >
>> >> >I am surprised that anyone would say the code is not immediately obvious=
>> >. =3D
>> >>=20
>> >> Hence the disconnect.
>> >>=20
>> >> For example, in the leading comment:
>> >>=20
>> >> y% is an integer value that goes from
>> >> filter length / 2 to +filter length / 2 )
>> >>=20
>> >> The % has specific meaning in some languages, but do those meanings
>> >> apply here? I've no idea.
>> >
>> >I guess some people are more intuitive than others. I don't see how the pe=
>> >rcent sign is even relevant when reading that comment. The important point=
>> > is that the variable is stepped through the range of filter length which i=
>> >s a symmetrical range. =20
>>
>> The percent sign appears in the code, so is very relevant to
>> attempting to understand what it means.
>>
>> The range, as shown, may not be symmetrical, depending on what is
>> meant. When it comes to ambiguous code, assumptions are often
>> counterproductive.
>>
>> >Why would you even be trying to understand details of the language when rea=
>> >ding through this code to understand what the intent is? Obviously you can=
>> >'t discern the details of the language. Why even try?=20
>>
>> That's why many don't.
>>
>> >
>> >> y% can't be an integer value for "filter length/2" for odd filter
>> >> lengths, so does that mean the intent is to reject all even lengths?
>> >
>> >Of course it can be integer. What is 11/2? 5! I don't know if that is wh=
>> >at they are using to calculate the coefficients or not. It may be that thi=
>> >s is only for odd length filters. I don't know and I don't really care muc=
>> >h. =20
>>
>> Then I'm glad I didn't spend any time trying to understand it.
>> >
>> >> I've no idea, and it's not wise to assume, so many will just pass.
>> >
>> >That's fine. But assumption is exactly what is needed here, but not about =
>> >the parts you are having trouble with. Those parts can be ignored at first=
>> >. =20
>> >
>> >Not trying to be rude or judgemental or anything negative. I recall in ele=
>> >mentary school I would be very literal about the things I read. If I didn'=
>> >t understand a word or a phrase I would stop. I was taught to read a first=
>> > pass to get some idea of what was being said. Then I could go back to see=
>> > if it made more sense.=20
>>
>> That's great with people, but you posted code. Computers don't do
>> nuance, they are the epitome of literal, so asking somebody to analyze
>> a chunk of code requires understanding of how that code will be
>> executed. Since it doesn't appear to be a very common language, if
>> it's even a language and not pseudo-code, but I don't really know
>> which, it's hard to say what it'll do without knowing the details of
>> how the code will be executed.
>>
>> e.g., does it round up? down? toward zero? away from zero? You
>> stated previously 11/2 = 5, but there's no way to know that and you
>> certainly didn't state it previously. And that's a critical thing to
>> know to understand how many or what coefficients would be generated.
>>
>> >
>> >> Even if you get past the above, the value runs from:
>> >>=20
>> >> filter length / 2=20
>> >>=20
>> >> to=20
>> >>=20
>> >> +filter length / 2
>> >>=20
>> >> So, it doesn't run? Or it just has one, singular value?
>> >>=20
>> >> I've no idea.
>> >
>> >Not clear what you are trying to say. The code does not have any looping c=
>> >onstruct to increment the value, so the assumption is that that is done in =
>> >some other aspect of the code or tool that aren't shown here. =20
>>
>> Another unstated assumption.
>>
>> >The part you are getting hung up on is the index for the filter coefficient=
>> >s. I don't understand what is unclear about that. Once you know that - ev=
>> >erything else about the index in the code should be clear. No? Not that i=
>> >t matters though. =20
>>
>> No.
>>
>> >
>> >> So, yeah, it's not obvious, even getting past the very first comment.
>> >>=20
>> >> One could make assumptions, but that's usually not productive.
>> >>=20
>> >> When it's clear as mud, you need to be willing to wade throug the mud,
>> >> and many aren't.
>> >
>> >What mud?
>>
>> The points I made previously regarding the ambiguity of interpreting
>> the code. You have since pointed out additional ambiguity.
>>
>> >You don't even need to look at the code other than to realize th=
>> >ey are calculating filter coefficients and the center tap coefficient for t=
>> >he odd length filter is a 1 which I pointed out. At that point I said the =
>> >coefficients for an odd length allpass filter were all zero except for a 1 =
>> >at the center tap. I asked what the filter coefficients would be if the a=
>> >llpass filter were even length. No inspection of the code is needed for th=
>> >at. =20
>> >
>> >Is the question not clear? =20
>>
>> Apparently not.
>>
>> However, if your filter coefficients for the odd-length all-pass are a
>> one at the center tap with zeros on either side, you can make it an
>> even-length all-pass with exactly the same frequency response by
>> deleting any one of the zeros.
>>
>> I hope that helps.
>
>Not really. I could produce an all pass filter by setting any one coefficient to a 1 and the rest to zero. But they will all have different delays. The point is to have an all pass that the band pass would be subtracted from.
>
>It is amazing to me how much effort people have spent explaining how little effort they are willing to spend to understand the question and help.
I think if you'd put the effort into clarifying the question
initially, which now seems to be quite different than your initial
post, you may have gotten more useful responses.
I'm still not quite sure what you're after, whether you want to know
how to subtract frequency responses in the time domain, which is not
trivial, or you want the initial code modified to create bandstop
coefficients (which seems to be what you first asked for, hence people
telling you they don't want to reverse-engineer strange code of an
unknown language), or you want to be pointed toward a bandstop
algorithm similar to what you posted, or something related but not
quite clear yet.
There are still a number of very knowledgable people here, but you're
not going to get a useful answer if your question isn't clear or
wasn't the question you meant to ask or if you ask for work beyond
what people are willing to do for free.
I hope you got your money's worth. Oh, wait... ;)