Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93534 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-09-15 05:11 -0700 |
| Last post | 2016-09-23 14:59 -0700 |
| Articles | 15 on this page of 75 — 22 participants |
Back to article view | Back to comp.lang.c
Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-15 05:11 -0700
Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-15 05:29 -0700
Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-15 15:01 +0100
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 15:32 +0100
Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-15 08:10 -0700
Re: Continue with learning C luser droog <luser.droog@gmail.com> - 2016-09-15 12:06 -0700
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 21:38 +0100
Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 21:02 -0700
Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-17 08:03 -0500
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-17 22:38 +0100
Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-17 18:14 -0400
Re: Continue with learning C raltbos@xs4all.nl (Richard Bos) - 2016-09-18 10:47 +0000
Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:25 -0700
Re: Continue with learning C Ian Collins <ian-news@hotmail.com> - 2016-09-19 20:51 +1200
Re: Continue with learning C James Kuyper <jameskuyper@verizon.net> - 2016-09-19 09:49 -0400
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-19 15:15 +0100
Re: Continue with learning C Keith Thompson <kst-u@mib.org> - 2016-09-19 11:39 -0700
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 09:55 +0800
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 08:50 +0200
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 18:04 +0800
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 13:25 +0200
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 20:18 +0800
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 15:25 +0200
Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 08:45 -0400
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 22:05 +0800
Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 10:56 -0400
Re: Continue with learning C Rosario19 <Ros@invalid.invalid> - 2016-09-19 18:55 +0200
Re: Continue with learning C Anton Shepelev <anton.txt@gmail.com> - 2016-09-25 01:08 +0300
Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 17:08 -0700
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-18 01:11 +0100
Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-17 21:32 -0400
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 16:27 +0200
Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-18 16:08 -0400
Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:30 -0700
Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-18 16:07 -0400
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 16:38 +0200
Re: Continue with learning C BartC <bc@freeuk.com> - 2016-09-18 16:37 +0100
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-18 23:54 +0800
Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 16:56 -0700
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-18 17:05 +0100
Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 12:28 -0400
Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 17:00 -0700
Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:40 -0700
Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-19 08:55 -0500
Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-18 11:31 -0500
Re: Continue with learning C Ian Collins <ian-news@hotmail.com> - 2016-09-19 07:25 +1200
Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 20:36 +0100
Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 15:45 -0400
Re: Continue with learning C Rosario19 <Ros@invalid.invalid> - 2016-09-19 18:58 +0200
Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-18 09:55 -0700
Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-18 10:12 -0700
Re: Continue with learning C luser droog <luser.droog@gmail.com> - 2016-09-18 13:11 -0700
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 21:54 +0200
Re: Continue with learning C supercat@casperkitty.com - 2016-09-18 15:58 -0700
Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-19 07:09 +0100
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-19 10:04 +0200
Re: Continue with learning C BartC <bc@freeuk.com> - 2016-09-19 10:38 +0100
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-19 13:29 +0200
Re: Continue with learning C supercat@casperkitty.com - 2016-09-19 08:04 -0700
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 09:33 +0800
Re: Continue with learning C supercat@casperkitty.com - 2016-09-19 20:47 -0700
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 09:00 +0200
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 17:59 +0800
Re: Continue with learning C Ike Naar <ike@iceland.freeshell.org> - 2016-09-20 17:24 +0000
Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 08:57 +0200
Re: Continue with learning C supercat@casperkitty.com - 2016-09-20 10:53 -0700
Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-19 13:19 +0800
Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:30 +0100
Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:15 -0700
Re: Continue with learning C Barry Schwarz <schwarzb@dqel.com> - 2016-09-15 12:38 -0700
Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 11:42 -0700
Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 12:40 -0700
Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 12:49 -0700
Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-23 14:47 -0700
Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-23 14:59 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-19 20:47 -0700 |
| Message-ID | <b68940ce-9481-43a8-aa11-2ccb15be903e@googlegroups.com> |
| In reply to | #93832 |
On Monday, September 19, 2016 at 8:33:39 PM UTC-5, Reinhardt Behm wrote: > AT Monday 19 September 2016 23:04, supercat wrote: > > Energizing the primary brake alone would be acceptable behavior. > > Energizing > > the secondary brake alone would also be acceptable behavior. A > > majority-vote system, however, would generate an unacceptable behavior > > even though only one controller was malfunctioning. > > Such redundant system only make sense if the software on each system is > developed according to the same requirements. Having clear requirements > should prevent our scenario. With clearly specified behavior there is not > "the other controller thinks ...". If it "thinks" differently it is either > defective or the software was not been developed according to the > requirements. > Assuming that the software was developed as it should be, why should in your > example the second controller come to a different conclusion about the state > and usability of the primary brake? It has the same information about the > brakes since it gets the same inputs. The software was developed to the same > requirements so it has to come to the conclusions. There is - and may not - > no random element in there. The only reason for such differences is a > malfunction, either hardware or software. If the programs were developed independently, floating-point rounding might not match precisely. If the decision about which brake to use is a sufficiently close call, a rounding difference could make the difference between selecting one brake vs the other.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-20 09:00 +0200 |
| Message-ID | <nrqmpn$6h0$2@dont-email.me> |
| In reply to | #93834 |
On 20/09/16 05:47, supercat@casperkitty.com wrote: > On Monday, September 19, 2016 at 8:33:39 PM UTC-5, Reinhardt Behm wrote: >> AT Monday 19 September 2016 23:04, supercat wrote: >>> Energizing the primary brake alone would be acceptable behavior. >>> Energizing >>> the secondary brake alone would also be acceptable behavior. A >>> majority-vote system, however, would generate an unacceptable behavior >>> even though only one controller was malfunctioning. >> >> Such redundant system only make sense if the software on each system is >> developed according to the same requirements. Having clear requirements >> should prevent our scenario. With clearly specified behavior there is not >> "the other controller thinks ...". If it "thinks" differently it is either >> defective or the software was not been developed according to the >> requirements. > >> Assuming that the software was developed as it should be, why should in your >> example the second controller come to a different conclusion about the state >> and usability of the primary brake? It has the same information about the >> brakes since it gets the same inputs. The software was developed to the same >> requirements so it has to come to the conclusions. There is - and may not - >> no random element in there. The only reason for such differences is a >> malfunction, either hardware or software. > > If the programs were developed independently, floating-point rounding might > not match precisely. If the decision about which brake to use is a > sufficiently close call, a rounding difference could make the difference > between selecting one brake vs the other. > To a large extent, you avoid floating point precisely because it can be hard to get bit-perfect. But if you /do/ need floating point, you can do so by being very careful to track the possible effects of rounding errors in order to avoid getting different results.
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2016-09-20 17:59 +0800 |
| Message-ID | <nrr1a0$vkl$3@dont-email.me> |
| In reply to | #93839 |
AT Tuesday 20 September 2016 15:00, David Brown wrote: > On 20/09/16 05:47, supercat@casperkitty.com wrote: >> On Monday, September 19, 2016 at 8:33:39 PM UTC-5, Reinhardt Behm wrote: >>> AT Monday 19 September 2016 23:04, supercat wrote: >>>> Energizing the primary brake alone would be acceptable behavior. >>>> Energizing >>>> the secondary brake alone would also be acceptable behavior. A >>>> majority-vote system, however, would generate an unacceptable behavior >>>> even though only one controller was malfunctioning. >>> >>> Such redundant system only make sense if the software on each system is >>> developed according to the same requirements. Having clear requirements >>> should prevent our scenario. With clearly specified behavior there is >>> not "the other controller thinks ...". If it "thinks" differently it is >>> either defective or the software was not been developed according to the >>> requirements. >> >>> Assuming that the software was developed as it should be, why should in >>> your example the second controller come to a different conclusion about >>> the state and usability of the primary brake? It has the same >>> information about the brakes since it gets the same inputs. The software >>> was developed to the same requirements so it has to come to the >>> conclusions. There is - and may not - no random element in there. The >>> only reason for such differences is a malfunction, either hardware or >>> software. >> >> If the programs were developed independently, floating-point rounding >> might >> not match precisely. If the decision about which brake to use is a >> sufficiently close call, a rounding difference could make the difference >> between selecting one brake vs the other. >> > > To a large extent, you avoid floating point precisely because it can be > hard to get bit-perfect. But if you /do/ need floating point, you can > do so by being very careful to track the possible effects of rounding > errors in order to avoid getting different results. There is just a difference between real engineering and experimental programming. ;-) -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-09-20 17:24 +0000 |
| Message-ID | <slrn3vfsnu2s6f.b8n.ike@iceland.freeshell.org> |
| In reply to | #93842 |
On 2016-09-20, Reinhardt Behm <rbehm@hushmail.com> wrote: > There is just a difference between real engineering and experimental > programming. ;-) What's the difference between engineering and "real" engineering?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-20 08:57 +0200 |
| Message-ID | <nrqmkm$6h0$1@dont-email.me> |
| In reply to | #93804 |
On 19/09/16 17:04, supercat@casperkitty.com wrote: > On Monday, September 19, 2016 at 3:05:00 AM UTC-5, David Brown wrote: >> When you use triple redundancy with majority votes, you make your >> software and your hardware with a very tight specification. When the >> inputs are this, and the current state is that, the output of the >> function/regulator/module/whatever shall be this - and it shall be valid >> within this specific time interval. >> >> No system gets to make guesses about the future, unless /all/ systems >> are specified to make the same guesses in the same circumstances. There >> is no place for trying to make a "smarter" computer here - it is only at >> the level of the specifications that people are allowed to be "clever". > > Many control systems inherently need to make estimates about future > behavior in order to decide what to do in the present. Of course. But that is a matter of following the specified algorithms - not making creative guesses. A key point to making such redundant software is that each version has to do the same thing, and hit the synchronisation points with the same results. If the specifications say "predict the future in /this/ way", that's what they do. If the programmer thinks "we can get more accurate results by predicting the future in /that/ way", he is in the wrong job. (Perhaps he should be writing the specs.) > But there may be > problems even in some immediate-present scenarios. Suppose a system might > attempt to slow down by energizing either of two braking systems, but should > avoid energizing both. The first controller thinks the primary brake is > sufficiently hot that it should use the backup brake instead. The second > controller thinks the primary brake is fine. The third controller is > malfunctioning and either doesn't think any braking is necessary, or thinks > both brakes should be applied. Such a system is known as "broken by design", and does not leave the whiteboard of the first planning meeting. If the different controllers are getting different information, the system is broken. If the different controllers think different thinks from the same information, the system is broken. If the different controllers come to different conclusions from the same thought process, the system is broken. The triple redundancy is there so that if something breaks at run-time, you will still have a safe working system. But if you break everything before you even start putting it together, the exercise is pretty pointless. > > Energizing the primary brake alone would be acceptable behavior. Energizing > the secondary brake alone would also be acceptable behavior. In a triple redundancy system, there is only ever /one/ acceptable behaviour at a time. There are no options, no choices. > A majority-vote > system, however, would generate an unacceptable behavior even though only > one controller was malfunctioning. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-20 10:53 -0700 |
| Message-ID | <d416ae76-2eed-418e-bcf8-82b4a8ae5445@googlegroups.com> |
| In reply to | #93838 |
On Tuesday, September 20, 2016 at 1:57:41 AM UTC-5, David Brown wrote: > In a triple redundancy system, there is only ever /one/ acceptable > behaviour at a time. There are no options, no choices. I don't think it will be possible to ensure that three computers always remain in perfect sync without adding single points of failure. If one computer malfunctions in subtle ways, it may not be possible for the other two to reach consensus about what's going on. If all three computers agree on everything *except* that CPU2 reports that the data it received from CPU1 and CPU3 doesn't match, should CPU2 be shut down as odd-man-out because it's the only thing that saw errant data from CPU3, or is it possible that CPU3 failed to ensure that its outputs would be seen the same way by both CPU1 and CPU3? If a CPU failure occurs, I don't think it will be possible in the general case to ensure that the other two CPUs remain in lockstep. If the two are not in sync but each is trying to fly the plane, then so long as each can notice what is happening and react to the way the system as a whole is responding (e.g. if all CPUs agree that in case of disagreement about which brake should be used, brake #1 should be used if at all practical and if brake #1 is not believed reliable then brake #2 should be used as well) then the system should be reliable even if the two working CPUs aren't in perfect lockstep.
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2016-09-19 13:19 +0800 |
| Message-ID | <nrnshf$uh5$1@dont-email.me> |
| In reply to | #93751 |
AT Monday 19 September 2016 03:54, David Brown wrote: >> Didn't the Space Shuttle have multiple backup computers, one of which >> was programmed by a different team to make sure they didn't share the >> same bugs? >> > > I believe it is common practice in avionics to have three independent > computers for the most critical parts. Each board must have a different > processor/microcontroller from a different company, and be programmed by > independent teams using different development tools. A majority voting > system is used to determine the signals that are driven out to the > actuators, with any differences of opinion leading to alarm bells. Here is an interesting article about the group that developed the shuttle software: <https://www.fastcompany.com/28121/they-write-right-stuff> -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-09-19 01:30 +0100 |
| Message-ID | <87vaxsivd9.fsf@bsb.me.uk> |
| In reply to | #93735 |
BartC <bc@freeuk.com> writes: <snip> > And wasn't it Knuth who offered $250(?) for each bug readers > discovered in his algorithms? It's varied over time, but the most common was $2.56 -- a hex dollar. And they were sent out for all sorts of corrections, not just algorithm bugs. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-09-19 01:15 -0700 |
| Message-ID | <299a03ff-24b8-4979-848f-6272055ed765@googlegroups.com> |
| In reply to | #93562 |
On Thursday, September 15, 2016 at 10:07:08 PM UTC+3, luser droog wrote: > On Thursday, September 15, 2016 at 9:32:42 AM UTC-5, Richard Heathfield wrote: > > On 15/09/16 13:11, Alla _ wrote: > > > > PS: I don't promise that form time to time I will not get into doing > > > something that might be beyond my current level, but, please, don't > > > scold me for that. > > > > You /will/ get scolded for that, because that's precisely what's got you > > into trouble before. > > > > It's not avoidable, IMO. If you're really writing code to expand your skills, > you /will/ sometimes be on this side of the line and sometimes on the other > side. I think the important point is /it's okay to get scolded/. > If you learned what to do better from the scolding, then say "I see. Thanks." > If you don't see then you say "I don't see. What about ...? Didn't I > already ...?" > > I'll say that when you get through K&R, I highly recommend van der Linden's > Deep C Secrets. It will refine your understanding, and it's a very 'fun' book. > Told in a light-hearted tone with tons of diverting anecdotes. Thank you very much! I agree with you. I am not afraid of being reprimanded; I even like it a lot, because one does learn from a positive and professional reprimand; hence I always welcome it. Sometimes people do get annoyed with my incorrect learning process, and hence scold me for that; I understand that too. I just can't promise to be a good girl always. Thank you very much for the book; I will find it.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-09-15 12:38 -0700 |
| Message-ID | <hdtltb994jb2n1mdilv273oilll6t987ao@4ax.com> |
| In reply to | #93534 |
On Thu, 15 Sep 2016 05:11:24 -0700 (PDT), Alla _ <modelling.data@gmail.com> wrote: >Hello! <snip> >I have the following books: >K&R >C: a reference manual 5th edition http://careferencemanual.com/ I don't know anything about this book but it enjoys a good reputation. Oddly enough, the examples at the web site will not display properly in Internet Explorer. They come out unformatted and with major omissions. I was going to suggest you avoid the web site and use a printed copy but when I double checked with Firefox they displayed fine. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-09-21 11:42 -0700 |
| Message-ID | <b8cf11fd-6780-4c75-9af5-9aa586e28c86@googlegroups.com> |
| In reply to | #93534 |
W dniu czwartek, 15 września 2016 14:11:31 UTC+2 użytkownik Alla _ napisał: > Hello! > > It's been a while since I have posted here and since I have done C exercises. I was doing the course > I have mentioned here a few times, and have also been overwhelmed with other matters. > > It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance, > for your opinion on the best way to choose. > > 1) At the moment I have completed chapter 4 of K&R. > 2) My main issues, which do not allow me to write correct code, are inability to find concise solutions and > inability to eliminate redundant code (too much loops, etc), which derives from the first issue; most likely, > both come from the lack of practice in doing logical exercises and finding solutions. > > I have the following books: > K&R > C: a reference manual 5th edition http://careferencemanual.com/ > > Shall I continue with K&R and simultaneously read through and do exercises in C: A reference book, > or can you recommend a way you think will better serve the goal of learning good coding habits > (I understand that the main way is to practice as much as possible). > > Thank you very much! > > PS: I don't promise that form time to time I will not get into doing something that might be beyond > my current level, but, please, don't scold me for that. Also, I would like to write my final project in C, > a small arithmetic game. > > During this time I have scratched the surface of Java and php languages, and, well, C is by far the best > one; I do hope that people who learn other languages start with C, and move further only upon mastering > this low level language - I believe it's essential. > > PS2: I will be able to move on starting from the beginning of the next week; I will not have access to the > internet during a few days starting tomorrow. i think you wasting your time it is becouse 2 points 1) to know c you need to know some amount of knowledge about its syntax and constructs in c case this is not so much - you may get it by browsing not quite fat book - it is also not hard 2) after getting that 'additive' (or how to cal it) knowledge you will need to eliminate things you do not understand (this is much harder as it needs understanding of some complexity of c) forst point may take like 3 days, second may take long or shorter depending on way of learning (in my case it took long - like 5 years) Doin exercises is imo somewhat waste of time (more on this maybe later)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-09-21 12:40 -0700 |
| Message-ID | <4dba7fb2-e80f-4651-85c1-3cd2d44a357c@googlegroups.com> |
| In reply to | #93877 |
W dniu środa, 21 września 2016 20:42:36 UTC+2 użytkownik fir napisał: > W dniu czwartek, 15 września 2016 14:11:31 UTC+2 użytkownik Alla _ napisał: > > Hello! > > > > It's been a while since I have posted here and since I have done C exercises. I was doing the course > > I have mentioned here a few times, and have also been overwhelmed with other matters. > > > > It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance, > > for your opinion on the best way to choose. > > > > 1) At the moment I have completed chapter 4 of K&R. > > 2) My main issues, which do not allow me to write correct code, are inability to find concise solutions and > > inability to eliminate redundant code (too much loops, etc), which derives from the first issue; most likely, > > both come from the lack of practice in doing logical exercises and finding solutions. > > > > I have the following books: > > K&R > > C: a reference manual 5th edition http://careferencemanual.com/ > > > > Shall I continue with K&R and simultaneously read through and do exercises in C: A reference book, > > or can you recommend a way you think will better serve the goal of learning good coding habits > > (I understand that the main way is to practice as much as possible). > > > > Thank you very much! > > > > PS: I don't promise that form time to time I will not get into doing something that might be beyond > > my current level, but, please, don't scold me for that. Also, I would like to write my final project in C, > > a small arithmetic game. > > > > During this time I have scratched the surface of Java and php languages, and, well, C is by far the best > > one; I do hope that people who learn other languages start with C, and move further only upon mastering > > this low level language - I believe it's essential. > > > > PS2: I will be able to move on starting from the beginning of the next week; I will not have access to the > > internet during a few days starting tomorrow. > > i think you wasting your time it is becouse 2 points > > 1) to know c you need to know some amount of knowledge about > its syntax and constructs > > in c case this is not so much - you may get it by browsing not quite fat book - it is also not hard > > 2) after getting that 'additive' (or how to cal it) knowledge you will need to eliminate things you do not understand (this is much harder as it needs understanding of some complexity of c) > > forst point may take like 3 days, second may take long or shorter > depending on way of learning (in my case it took long - like 5 years) > > Doin exercises is imo somewhat waste of time (more on this maybe later) one could think exercises will teach one not c but coding programs (which are greatly separate things) but they also not teach this (becouse are terribly poor and teaches you somewhat wrong way - thus are 'unusefull' in my view (waste of time - some big amount of time like those 5 years of understanding c took me an basic approach to unlearn such c like in those terribly exercises (im on a way still and this proces of unlearning is maybe not finished yet, but i really feel need to make it quite different way))
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-09-21 12:49 -0700 |
| Message-ID | <23cb9975-0db3-4cf1-87db-f223be981f7a@googlegroups.com> |
| In reply to | #93878 |
W dniu środa, 21 września 2016 21:41:08 UTC+2 użytkownik fir napisał: > W dniu środa, 21 września 2016 20:42:36 UTC+2 użytkownik fir napisał: > > W dniu czwartek, 15 września 2016 14:11:31 UTC+2 użytkownik Alla _ napisał: > > > Hello! > > > > > > It's been a while since I have posted here and since I have done C exercises. I was doing the course > > > I have mentioned here a few times, and have also been overwhelmed with other matters. > > > > > > It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance, > > > for your opinion on the best way to choose. > > > > > > 1) At the moment I have completed chapter 4 of K&R. > > > 2) My main issues, which do not allow me to write correct code, are inability to find concise solutions and > > > inability to eliminate redundant code (too much loops, etc), which derives from the first issue; most likely, > > > both come from the lack of practice in doing logical exercises and finding solutions. > > > > > > I have the following books: > > > K&R > > > C: a reference manual 5th edition http://careferencemanual.com/ > > > > > > Shall I continue with K&R and simultaneously read through and do exercises in C: A reference book, > > > or can you recommend a way you think will better serve the goal of learning good coding habits > > > (I understand that the main way is to practice as much as possible). > > > > > > Thank you very much! > > > > > > PS: I don't promise that form time to time I will not get into doing something that might be beyond > > > my current level, but, please, don't scold me for that. Also, I would like to write my final project in C, > > > a small arithmetic game. > > > > > > During this time I have scratched the surface of Java and php languages, and, well, C is by far the best > > > one; I do hope that people who learn other languages start with C, and move further only upon mastering > > > this low level language - I believe it's essential. > > > > > > PS2: I will be able to move on starting from the beginning of the next week; I will not have access to the > > > internet during a few days starting tomorrow. > > > > i think you wasting your time it is becouse 2 points > > > > 1) to know c you need to know some amount of knowledge about > > its syntax and constructs > > > > in c case this is not so much - you may get it by browsing not quite fat book - it is also not hard > > > > 2) after getting that 'additive' (or how to cal it) knowledge you will need to eliminate things you do not understand (this is much harder as it needs understanding of some complexity of c) > > > > forst point may take like 3 days, second may take long or shorter > > depending on way of learning (in my case it took long - like 5 years) > > > > Doin exercises is imo somewhat waste of time (more on this maybe later) > > one could think exercises will teach one not c but coding programs (which are greatly separate things) but they also not teach this (becouse are terribly poor and teaches you somewhat wrong way - thus are 'unusefull' > in my view (waste of time - some big amount of time like those 5 years of understanding c took me an basic approach to unlearn such c like in those > terribly exercises (im on a way still and this proces of unlearning is maybe not finished yet, but i really feel need to make it quite different way)) in short words 'youre in a wrong way', it my sound like a bit ironic (malicious?) (may be correct) the reason is some kind of slight arrogancy you got coz you dont know what ya is doin ;c
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-09-23 14:47 -0700 |
| Message-ID | <e9887da1-ea2b-4f93-a873-f3e7943da9f7@googlegroups.com> |
| In reply to | #93878 |
W dniu środa, 21 września 2016 21:41:08 UTC+2 użytkownik fir napisał: > W dniu środa, 21 września 2016 20:42:36 UTC+2 użytkownik fir napisał: > > W dniu czwartek, 15 września 2016 14:11:31 UTC+2 użytkownik Alla _ napisał: > > > Hello! > > > > > > It's been a while since I have posted here and since I have done C exercises. I was doing the course > > > I have mentioned here a few times, and have also been overwhelmed with other matters. > > > > > > It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance, > > > for your opinion on the best way to choose. > > > > > > 1) At the moment I have completed chapter 4 of K&R. > > > 2) My main issues, which do not allow me to write correct code, are inability to find concise solutions and > > > inability to eliminate redundant code (too much loops, etc), which derives from the first issue; most likely, > > > both come from the lack of practice in doing logical exercises and finding solutions. > > > > > > I have the following books: > > > K&R > > > C: a reference manual 5th edition http://careferencemanual.com/ > > > > > > Shall I continue with K&R and simultaneously read through and do exercises in C: A reference book, > > > or can you recommend a way you think will better serve the goal of learning good coding habits > > > (I understand that the main way is to practice as much as possible). > > > > > > Thank you very much! > > > > > > PS: I don't promise that form time to time I will not get into doing something that might be beyond > > > my current level, but, please, don't scold me for that. Also, I would like to write my final project in C, > > > a small arithmetic game. > > > > > > During this time I have scratched the surface of Java and php languages, and, well, C is by far the best > > > one; I do hope that people who learn other languages start with C, and move further only upon mastering > > > this low level language - I believe it's essential. > > > > > > PS2: I will be able to move on starting from the beginning of the next week; I will not have access to the > > > internet during a few days starting tomorrow. > > > > i think you wasting your time it is becouse 2 points > > > > 1) to know c you need to know some amount of knowledge about > > its syntax and constructs > > > > in c case this is not so much - you may get it by browsing not quite fat book - it is also not hard > > > > 2) after getting that 'additive' (or how to cal it) knowledge you will need to eliminate things you do not understand (this is much harder as it needs understanding of some complexity of c) > > > > forst point may take like 3 days, second may take long or shorter > > depending on way of learning (in my case it took long - like 5 years) > > > > Doin exercises is imo somewhat waste of time (more on this maybe later) > > one could think exercises will teach one not c but coding programs (which are greatly separate things) but they also not teach this (becouse are terribly poor and teaches you somewhat wrong way - thus are 'unusefull' part of the trouble is when you are learned c syntax those examples throws/puts you in some small hell of disambiguity: you can code it that or that, this may be somewhat better but maybe some other may be better, unfortunatelly not any of this is clearly the best (or even clearly 100% ok thax to some c glitches) - This kind of hell is better to avoid but this is BTw not all (nor even most) of the real topic For me real topic is so called 'coding meat/matter' (or how to call it finer) it is a skill to operate on real coding (program) matter nice and efficiently - but this is hard and personally you dont even seem to touch it (this is also ehere this all group extreamally fails imo - focusing on quite unimportant details where you need totally oposite (at least it seems so to me): tiotaly unfocusing on unimportant details and go to the matter) - but those are hard things where i still get lost > in my view (waste of time - some big amount of time like those 5 years of understanding c took me an basic approach to unlearn such c like in those > terribly exercises (im on a way still and this proces of unlearning is maybe not finished yet, but i really feel need to make it quite different way))
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-09-23 14:59 -0700 |
| Message-ID | <ef983f7c-3235-4275-9f29-0b21673d2793@googlegroups.com> |
| In reply to | #93967 |
W dniu piątek, 23 września 2016 23:48:05 UTC+2 użytkownik fir napisał: > W dniu środa, 21 września 2016 21:41:08 UTC+2 użytkownik fir napisał: > > W dniu środa, 21 września 2016 20:42:36 UTC+2 użytkownik fir napisał: > > > W dniu czwartek, 15 września 2016 14:11:31 UTC+2 użytkownik Alla _ napisał: > > > > Hello! > > > > > > > > It's been a while since I have posted here and since I have done C exercises. I was doing the course > > > > I have mentioned here a few times, and have also been overwhelmed with other matters. > > > > > > > > It's time to get back to C and to try to learn as much as I can. I will be grateful, as usual, for your guidance, > > > > for your opinion on the best way to choose. > > > > > > > > 1) At the moment I have completed chapter 4 of K&R. > > > > 2) My main issues, which do not allow me to write correct code, are inability to find concise solutions and > > > > inability to eliminate redundant code (too much loops, etc), which derives from the first issue; most likely, > > > > both come from the lack of practice in doing logical exercises and finding solutions. > > > > > > > > I have the following books: > > > > K&R > > > > C: a reference manual 5th edition http://careferencemanual.com/ > > > > > > > > Shall I continue with K&R and simultaneously read through and do exercises in C: A reference book, > > > > or can you recommend a way you think will better serve the goal of learning good coding habits > > > > (I understand that the main way is to practice as much as possible). > > > > > > > > Thank you very much! > > > > > > > > PS: I don't promise that form time to time I will not get into doing something that might be beyond > > > > my current level, but, please, don't scold me for that. Also, I would like to write my final project in C, > > > > a small arithmetic game. > > > > > > > > During this time I have scratched the surface of Java and php languages, and, well, C is by far the best > > > > one; I do hope that people who learn other languages start with C, and move further only upon mastering > > > > this low level language - I believe it's essential. > > > > > > > > PS2: I will be able to move on starting from the beginning of the next week; I will not have access to the > > > > internet during a few days starting tomorrow. > > > > > > i think you wasting your time it is becouse 2 points > > > > > > 1) to know c you need to know some amount of knowledge about > > > its syntax and constructs > > > > > > in c case this is not so much - you may get it by browsing not quite fat book - it is also not hard > > > > > > 2) after getting that 'additive' (or how to cal it) knowledge you will need to eliminate things you do not understand (this is much harder as it needs understanding of some complexity of c) > > > > > > forst point may take like 3 days, second may take long or shorter > > > depending on way of learning (in my case it took long - like 5 years) > > > > > > Doin exercises is imo somewhat waste of time (more on this maybe later) > > > > one could think exercises will teach one not c but coding programs (which are greatly separate things) but they also not teach this (becouse are terribly poor and teaches you somewhat wrong way - thus are 'unusefull' > > > part of the trouble is when you are learned c syntax those examples throws/puts you in some small hell of disambiguity: you can code it that or that, this may be somewhat better but maybe some other may be better, > unfortunatelly not any of this is clearly the best (or even clearly > 100% ok thax to some c glitches) - This kind of hell is better to > avoid but this is BTw not all (nor even most) of the real topic > > For me real topic is so called 'coding meat/matter' (or how to call it finer) it is a skill to operate on real coding (program) matter nice and efficiently - but this is hard and personally you dont even seem to touch it (this is also ehere this all group extreamally fails imo - focusing on quite unimportant details where you need totally oposite (at least it seems so to me): tiotaly unfocusing on unimportant details and go to the matter) - but those are hard things where i still get lost > > > in my view (waste of time - some big amount of time like those 5 years of understanding c took me an basic approach to unlearn such c like in those > > terribly exercises (im on a way still and this proces of unlearning is maybe not finished yet, but i really feel need to make it quite different way)) One could say that things im sayin is 'the view of the producer' (where producer would like to get things just done and most likely in 1 hour etc) which is generaly hated by coders (also by me) but with time i realized that doing real programs needs me to be more producer than coder... (more on this (some partial thoughts on how to be producer) maybe later
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web