Randy Yates wrote:> "Martin Blume" <mblume@socha.net> writes: > > >>"Jerry Avins" schrieb >> >>>>Back to your original question, I think that beginners should >>>>learn the array approach, because this is the "natural" >>>>formulation of the problem set. >>> >>> ... >>> >>>What is natural to one is forced to another. >>>It depends on how one sees the problem. >>>Why is a set of coefficients most naturally seen as an array? >>>I see it as a list, occasionally best dealt with as an array. >>> >> >>You are right. But in this case I think that the array approach >>is the best and indeed the "natural" approach for beginners. >>For a guy having assembler experience, the pointer approach may >>of course be more natural. >> >> >>>... >>>"To get a good solution, develop an understanding >>>of the whole problem, then divide it into tractable >>>parts that connect in a sensible way." >>> >> >>Yes. >> >> >>>"To get a good solution, start from the end and work backward." >>> >> >>That's the best way ... :-) >> >> >>>"If you don't see the problem the way I do, your view is >> >>defective." >> >>Not necessarily. Your (my) view may be incomplete (either the >>understanding of the problem, or the descriptive power of the view). >> >> >>>A good teacher is more than an adept in the field he teaches. >>>He has to see what he teaches from many points of view in order to >>>adapt the material to the student's mind set. >>> >> >>I think that is what defines a good understanding of a problem: >>that one can look at it from different angles and understand and >>describe the phenomena. Indeed a problem should be looked at from >>as many possible angles as possible in order to get a deeper >>understanding. >>In that sense my understanding of C is not yet complete: although >> I can read and understand the pointer notation, I wouldn't write >>code in that way. So that explains why (in my view) the array >>notation >>is the "natural" one. > > > Trick question: > > int count[20]; > int i; > > for (i = 0; i < 20; i++) > { > printf("count is %d\n", i[count]); > } > > Will this compile and run?No, it needs to be placed in a function, and if it's compiled under C++ you need to include <stdio.h> -- was that the trick? Once you do that, does it work because of an implicit integer to pointer conversion, or is it some peculiarity of C that you can do things the other way around and have it be legal? In other words, can you do this if count is an array of double, or chars, or some other thing? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Conceptual model for pointer arithmetic in FIR filter implementation?
Started by ●October 13, 2004
Reply by ●October 16, 20042004-10-16
Reply by ●October 16, 20042004-10-16
"Martin Blume" <mblume@socha.net> writes:> "Randy Yates" schrieb >> >> [...] I've also learnt that optimization costs a lot - and >> >> is often done to parts of a program that don't matter >> > ... >> > Rule of Optimization: Prototype before polishing. Get it >> > working before you optimize it. >> > ... >> > The most basic argument for prototyping first is Kernighan & >> > Plauger's; "90% of the functionality delivered now is better >> > than 100% of it delivered never". >> >> I'll take the low road and buck Kernighan. It's a matter of faith >> and competency. The "delivered never" is bullshit. >> > Depends on the project. There are projects that were never > delivered.This is true, but when one makes such a statement, the implication is that there is a significant probability of the "worse" clause. I'm NOT bucking prototyping. Heck no. I'm bucking the idea that there is never a time and a place to knuckle down and grind out some fairly tedious assembly language. This seems to be the prevailing wisdom in embedded software development, and I think this mindset is crippling innovation. -- % Randy Yates % "Rollin' and riding and slippin' and %% Fuquay-Varina, NC % sliding, it's magic." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Living' Thing', *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●October 16, 20042004-10-16
Tim Wescott <tim@wescottnospamdesign.com> writes:> Randy Yates wrote: >> "Martin Blume" <mblume@socha.net> writes: >> >>>"Jerry Avins" schrieb >>> >>>>>Back to your original question, I think that beginners should >>>>>learn the array approach, because this is the "natural" >>>>>formulation of the problem set. >>>> >>>> ... >>>> >>>>What is natural to one is forced to another. >>>>It depends on how one sees the problem. >>>>Why is a set of coefficients most naturally seen as an array? >>>>I see it as a list, occasionally best dealt with as an array. >>>> >>> >>>You are right. But in this case I think that the array approach >>>is the best and indeed the "natural" approach for beginners. >>>For a guy having assembler experience, the pointer approach may >>>of course be more natural. >>> >>> >>>>... >>>>"To get a good solution, develop an understanding >>>>of the whole problem, then divide it into tractable >>>>parts that connect in a sensible way." >>>> >>> >>>Yes. >>> >>> >>>>"To get a good solution, start from the end and work backward." >>>> >>> >>>That's the best way ... :-) >>> >>> >>>>"If you don't see the problem the way I do, your view is >>> >>>defective." >>> >>>Not necessarily. Your (my) view may be incomplete (either the >>>understanding of the problem, or the descriptive power of the view). >>> >>> >>>>A good teacher is more than an adept in the field he teaches. >>>>He has to see what he teaches from many points of view in order to >>>>adapt the material to the student's mind set. >>>> >>> >>>I think that is what defines a good understanding of a problem: >>>that one can look at it from different angles and understand and >>>describe the phenomena. Indeed a problem should be looked at from >>>as many possible angles as possible in order to get a deeper >>>understanding. >>>In that sense my understanding of C is not yet complete: although >>> I can read and understand the pointer notation, I wouldn't write >>>code in that way. So that explains why (in my view) the array >>>notation >>>is the "natural" one. >> Trick question: >> int count[20]; >> int i; >> for (i = 0; i < 20; i++) >> { >> printf("count is %d\n", i[count]); >> } >> Will this compile and run? > > No, it needs to be placed in a function, and if it's compiled under > C++ you need to include <stdio.h> -- was that the trick?No. I assumed the requisite ancillary stuff was there. You could also argue that without a compiler, a complete source file (as you have described) would not compile and run.> Once you do that, does it work because of an implicit integer to > pointer conversion, or is it some peculiarity of C that you can do > things the other way around and have it be legal?The latter. There is an old book by Anderson and Anderson http://www.asgteach.com/books/advc_lg.jpg that states "the rule" is "count[i] iff *(count + i)". Since addition is commutative, this is the same as *(i + count) = i[count]; Try it!> In other words, > can you do this if count is an array of double, or chars, or some > other thing?Yes. -- % Randy Yates % "Bird, on the wing, %% Fuquay-Varina, NC % goes floating by %%% 919-577-9882 % but there's a teardrop in his eye..." %%%% <yates@ieee.org> % 'One Summer Dream', *Face The Music*, ELO http://home.earthlink.net/~yatescr
Reply by ●October 16, 20042004-10-16
Randy Yates <yates@ieee.org> writes:> "Martin Blume" <mblume@socha.net> writes: > >> "Randy Yates" schrieb >>> >> [...] I've also learnt that optimization costs a lot - and >>> >> is often done to parts of a program that don't matter >>> > ... >>> > Rule of Optimization: Prototype before polishing. Get it >>> > working before you optimize it. >>> > ... >>> > The most basic argument for prototyping first is Kernighan & >>> > Plauger's; "90% of the functionality delivered now is better >>> > than 100% of it delivered never". >>> >>> I'll take the low road and buck Kernighan. It's a matter of faith >>> and competency. The "delivered never" is bullshit. >>> >> Depends on the project. There are projects that were never >> delivered. > > This is true, but when one makes such a statement, the implication > is that there is a significant probability of the "worse" clause. > > I'm NOT bucking prototyping. Heck no. I'm bucking the idea that there > is never a time and a place to knuckle down and grind out some fairly > tedious assembly language. This seems to be the prevailing wisdom in > embedded software development, and I think this mindset is crippling > innovation.Let me also add that I think we're losing out on some significant innovation when we follow the paradigm in which critical sections of code generated by, e.g., the C compiler is optimized. I think that, by the time you've relinquished the module or code snippet to C, you've given up thinking of optimizations that could've been implemented in an assembly-only environment. This is guilding the lilly somewhat, but nonetheless, in a balls-to-the-wall application such as a comm equalizer, viterbi, etc., it can be significant, I predict. -- % Randy Yates % "Ticket to the moon, flight leaves here today %% Fuquay-Varina, NC % from Satellite 2" %%% 919-577-9882 % 'Ticket To The Moon' %%%% <yates@ieee.org> % *Time*, Electric Light Orchestra http://home.earthlink.net/~yatescr
Reply by ●October 16, 20042004-10-16
Randy Yates wrote:> "Martin Blume" <mblume@socha.net> writes: > > >>"Jerry Avins" schrieb >> >>>>Back to your original question, I think that beginners should >>>>learn the array approach, because this is the "natural" >>>>formulation of the problem set. >>> >>> ... >>> >>>What is natural to one is forced to another. >>>It depends on how one sees the problem. >>>Why is a set of coefficients most naturally seen as an array? >>>I see it as a list, occasionally best dealt with as an array. >>> >> >>You are right. But in this case I think that the array approach >>is the best and indeed the "natural" approach for beginners. >>For a guy having assembler experience, the pointer approach may >>of course be more natural. >> >> >>>... >>>"To get a good solution, develop an understanding >>>of the whole problem, then divide it into tractable >>>parts that connect in a sensible way." >>> >> >>Yes. >> >> >>>"To get a good solution, start from the end and work backward." >>> >> >>That's the best way ... :-) >> >> >>>"If you don't see the problem the way I do, your view is >> >>defective." >> >>Not necessarily. Your (my) view may be incomplete (either the >>understanding of the problem, or the descriptive power of the view). >> >> >>>A good teacher is more than an adept in the field he teaches. >>>He has to see what he teaches from many points of view in order to >>>adapt the material to the student's mind set. >>> >> >>I think that is what defines a good understanding of a problem: >>that one can look at it from different angles and understand and >>describe the phenomena. Indeed a problem should be looked at from >>as many possible angles as possible in order to get a deeper >>understanding. >>In that sense my understanding of C is not yet complete: although >> I can read and understand the pointer notation, I wouldn't write >>code in that way. So that explains why (in my view) the array >>notation >>is the "natural" one. > > > Trick question: > > int count[20]; > int i; > > for (i = 0; i < 20; i++) > { > printf("count is %d\n", i[count]); > } > > Will this compile and run?It may compile and it may run, but if it does it will yield unpredictable results. count[] was never initialized. Anyway, doesn't one want count[i], not i[count]? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●October 16, 20042004-10-16
Jerry Avins <jya@ieee.org> writes:> [...] > It may compile and it may run, but if it does it will yield > unpredictable results. count[] was never initialized.True, but irrelevent.> Anyway, doesn't > one want count[i], not i[count]?That's the point - they're isomorphic. -- % Randy Yates % "...the answer lies within your soul %% Fuquay-Varina, NC % 'cause no one knows which side %%% 919-577-9882 % the coin will fall." %%%% <yates@ieee.org> % 'Big Wheels', *Out of the Blue*, ELO http://home.earthlink.net/~yatescr
Reply by ●October 16, 20042004-10-16
In article <ckjpt6$1qr$1@gnus01.u.washington.edu>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:>Even more, note that the [] operator is commutative in C. > >y[n] is exactly the same as *(y+n) by definition. > >*(y+n) is the same as *(n+y) commutative property of addition > >*(n+y) is the same as n[y] by the same definition as above.It's not the same thing at all; defining it that way won't make it so. If y is a pointer to an array of floats, and n is an integer, then y[n] = *(y+n) = *(n+y). In this case n is synonymous with "offset of n multiplied by sizeof(float) bytes." You can't do n[y] with n declared as an integer; the compiler won't allow it. If you cast n to a float pointer, then ((float *)n)[y] won't give you any meaningful result, and will likely result in an addressing error on operating systems like unix that manage memory. n[y] means that the value of n by itself is a memory address (which can be anything), and incrementing it by y*sizeof(float) will reference who-knows-what, especially if n is an odd number that doesn't correspond to a word-aligned boundary. -A
Reply by ●October 16, 20042004-10-16
Randy Yates wrote:> Jerry Avins <jya@ieee.org> writes: > >>[...] >>It may compile and it may run, but if it does it will yield >>unpredictable results. count[] was never initialized. > > > True, but irrelevent. > > >>Anyway, doesn't >>one want count[i], not i[count]? > > > That's the point - they're isomorphic.That's rich! Of course, a + b = b + a. It won't work for 2D arrays, though. :-) (It won't work in Forth either, at least not the way I define my arrays.) Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●October 16, 20042004-10-16
axlq wrote:> In article <ckjpt6$1qr$1@gnus01.u.washington.edu>, > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > >>Even more, note that the [] operator is commutative in C. >> >>y[n] is exactly the same as *(y+n) by definition. >> >>*(y+n) is the same as *(n+y) commutative property of addition >> >>*(n+y) is the same as n[y] by the same definition as above. > > > It's not the same thing at all; defining it that way won't make it so. > > If y is a pointer to an array of floats, and n is an integer, then > y[n] = *(y+n) = *(n+y). In this case n is synonymous with "offset > of n multiplied by sizeof(float) bytes." You can't do n[y] with > n declared as an integer; the compiler won't allow it. If you > cast n to a float pointer, then ((float *)n)[y] won't give you any > meaningful result, and will likely result in an addressing error > on operating systems like unix that manage memory. n[y] means > that the value of n by itself is a memory address (which can be > anything), and incrementing it by y*sizeof(float) will reference > who-knows-what, especially if n is an odd number that doesn't > correspond to a word-aligned boundary. > > -AYou mean I was conned? I hate typed quantities and overloaded operators! Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●October 17, 20042004-10-17
axlq@spamcop.net (axlq) writes:> In article <ckjpt6$1qr$1@gnus01.u.washington.edu>, > glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >>Even more, note that the [] operator is commutative in C. >> >>y[n] is exactly the same as *(y+n) by definition. >> >>*(y+n) is the same as *(n+y) commutative property of addition >> >>*(n+y) is the same as n[y] by the same definition as above. > > It's not the same thing at all; defining it that way won't make it so. > > If y is a pointer to an array of floats, and n is an integer, then > y[n] = *(y+n) = *(n+y). In this case n is synonymous with "offset > of n multiplied by sizeof(float) bytes." You can't do n[y] with > n declared as an integer; the compiler won't allow it.Bullshit: ***ptr.mak*** ptr.exe : ptr.c gcc ptr.c -o ptr.exe ***ptr.c*** #include <stdio.h> int main(int argc, char* argv[]) { float count[20]; int n; for (n = 0; n < 20; n++) { n[count] = n + 0.123; printf("count[%d] = %f\n", n, count[n]); } return 0; } ***built with*** make -f ptr.mak ***runs as*** e:\rr\thirdedition\import>ptr ptr count[0] = 0.123000 count[1] = 1.123000 count[2] = 2.123000 count[3] = 3.123000 count[4] = 4.123000 count[5] = 5.123000 count[6] = 6.123000 count[7] = 7.123000 count[8] = 8.123000 count[9] = 9.123000 count[10] = 10.123000 count[11] = 11.123000 count[12] = 12.123000 count[13] = 13.123000 count[14] = 14.123000 count[15] = 15.123000 count[16] = 16.122999 count[17] = 17.122999 count[18] = 18.122999 count[19] = 19.122999 -- % Randy Yates % "Bird, on the wing, %% Fuquay-Varina, NC % goes floating by %%% 919-577-9882 % but there's a teardrop in his eye..." %%%% <yates@ieee.org> % 'One Summer Dream', *Face The Music*, ELO http://home.earthlink.net/~yatescr
