Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #102211 > unrolled thread

while loop condition doesn't work

Back to article view | Back to comp.lang.c

Contents

  while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 01:24 -0800
    Re: while loop condition doesn't work mark.bluemel@gmail.com - 2017-01-20 03:29 -0800
    Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-20 12:19 +0000
      Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 05:12 -0800
        Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 13:17 +0000
          Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 05:20 -0800
          Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-20 15:07 +0000
      Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 05:31 -0800
        Re: while loop condition doesn't work Manfred <noname@invalid.add> - 2017-01-20 15:23 +0100
        Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-20 15:16 +0000
          Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 07:45 -0800
            Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 16:06 +0000
              Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 08:37 -0800
              Re: while loop condition doesn't work David Brown <david.brown@hesbynett.no> - 2017-01-20 17:54 +0100
                Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 17:04 +0000
                  Re: while loop condition doesn't work David Brown <david.brown@hesbynett.no> - 2017-01-20 19:08 +0100
                  Re: while loop condition doesn't work Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 12:51 -0800
                    Re: while loop condition doesn't work Keith Thompson <kst-u@mib.org> - 2017-01-30 14:09 -0800
                      Re: while loop condition doesn't work supercat@casperkitty.com - 2017-01-30 14:57 -0800
                      Re: while loop condition doesn't work Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 21:31 -0800
                        Re: while loop condition doesn't work Keith Thompson <kst-u@mib.org> - 2017-02-02 10:01 -0800
                          Re: while loop condition doesn't work Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 00:22 -0800
                Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-20 19:12 +0000
                  Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-23 10:54 +0000
              Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 23:22 -0800
                Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-23 11:02 +0000
              Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-21 01:22 -0800
                Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-21 11:00 +0000
                  Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-21 08:35 -0800
                    Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-21 17:17 +0000
                      Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-21 09:32 -0800
            Re: while loop condition doesn't work Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-20 19:16 +0000
              Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-23 11:03 +0000
      Re: while loop condition doesn't work David Brown <david.brown@hesbynett.no> - 2017-01-20 14:34 +0100
        Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 07:40 -0800
          Re: while loop condition doesn't work Richard Heathfield <rjh@cpax.org.uk> - 2017-01-20 15:47 +0000
            Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 08:26 -0800
              Re: while loop condition doesn't work David Brown <david.brown@hesbynett.no> - 2017-01-20 18:01 +0100
                Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 09:26 -0800
                  Re: while loop condition doesn't work David Brown <david.brown@hesbynett.no> - 2017-01-20 19:02 +0100
                    Re: while loop condition doesn't work Alla _ <modelling.data@gmail.com> - 2017-01-20 10:13 -0800
                      Re: while loop condition doesn't work Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-21 05:36 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#102965

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> I agree that there's a problem.  I'm not sure eliminating such
>> comments or moving them elsewhere is the best solution.
>
> How you phrase the statement shows how deep the problem is.  My
> suggestion is not to move /comments/ but to put /commentary/
> outside the program.  Any program examples that have /comments/
> should have only those comments that one would write as part
> of a real (as opposed to example or tutorial) program.

In your opinion.

>                                                         The
> question of what is the best solution is misplaced:  it assumes
> we know exactly what problem we're trying to solve, that it is
> well-defined, that there is a "best" solution (by what metric?),
> and that we could tell whether a proposed solution is a best
> solution.  My goal is to avoid a behavior fairly well known to
> have negative effects.  It may be that in the process of doing
> that there will be other unexpected effects, but the only way
> to know what those might be is to try the suggestion and see
> what happens.

The goal is to present code to novice student programmers and explain to
them what the constructs in it mean.  Including comments explaining, for
example, what "++" means is one solution to that problem.  As discussed,
that solution causes another problem, encouraging the inappropriate use
of similar comments when the audience is not novice student programmers.

I suggest that clearly marking such comments and explaining their
purpose is one possible solution to that secondary problem.

[...]

>> Perhaps one could use some special marker, with a comment at the
>> top (and an explanation by the instructor) saying that any marked
>> comments are intended to explain the language features and should
>> not be included in real code.
>>
>>     int i;  /* TUT:  Create an object named "i" of type int */
>>     i = 42; /* TUT:  Assign the value 42 to i */
>>     i ++;   /* TUT:  Increment i by 1 */
>
> I've seen this done in other ways (eg, using a different font
> for the non-code material).  It suffers from many of the same
> problems that regular comments do.  Most importantly, it too
> promotes or reinforces a way of thinking that is damaging to
> less experienced programmers.  In that respect it isn't really
> an improvement over using regular "comments".

It's specifically intended to emphasize the point that such comments are
for exposition to inexperienced programmers, and that such comments
should not be used when such programmers are not the intended audience.

If you think it wouldn't work, that's fine; you may be right.

>> (It's been a long time since I was a beginning programmer, so
>> it's hard for me to tell what would work best.)
>
> The "what would work best" phrase tacitly implies that you
> know what problem is being addressed.  Can you say what problem
> it is you're trying to solve here?

See above.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103123

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>>> I agree that there's a problem.  I'm not sure eliminating such
>>> comments or moving them elsewhere is the best solution.
>>
>> How you phrase the statement shows how deep the problem is.  My
>> suggestion is not to move /comments/ but to put /commentary/
>> outside the program.  Any program examples that have /comments/
>> should have only those comments that one would write as part
>> of a real (as opposed to example or tutorial) program.
>
> In your opinion.

Yes, the word "should" generally implies a value judgment,
presumably subjective, which would make the statement one of
opinion rather than one of fact.  Do you use the word "should"
differently?  Have any of your statements in this subthread been
anything other than just your opinion (not counting things like
"It might be true that ...", etc)?

>>                                                         The
>> question of what is the best solution is misplaced:  it assumes
>> we know exactly what problem we're trying to solve, that it is
>> well-defined, that there is a "best" solution (by what metric?),
>> and that we could tell whether a proposed solution is a best
>> solution.  My goal is to avoid a behavior fairly well known to
>> have negative effects.  It may be that in the process of doing
>> that there will be other unexpected effects, but the only way
>> to know what those might be is to try the suggestion and see
>> what happens.
>
> The goal is to present code to novice student programmers and
> explain to them what the constructs in it mean.  Including
> comments explaining, for example, what "++" means is one solution
> to that problem.

I guess that's how you see it but it isn't what I meant in the
comment that started the discussion.  I was talking only about
the situation of using comments for reasons other than because
the program needs them, the motivating example of which was for a
didactic purpose.  What you describe as a "goal" and a "problem"
is secondary and largely incidental to the context I am trying to
highlight.

> As discussed, that solution causes another
> problem, encouraging the inappropriate use of similar comments
> when the audience is not novice student programmers.

Using comments in such a way causes an _effect_ of passing the
habit on from teacher to student, but I see the effect as being
symptomatic of a deeper problem - namely, the thought processes
gone through (or not gone through) by programmers at different
levels of experience (with the problem being how to get those
processes to be better rather than worse).

> I suggest that clearly marking such comments and explaining their
> purpose is one possible solution to that secondary problem.

Different problem.  The problem I am hoping to address is deeper
than that.


>>> Perhaps one could use some special marker, with a comment at the
>>> top (and an explanation by the instructor) saying that any marked
>>> comments are intended to explain the language features and should
>>> not be included in real code.
>>>
>>>     int i;  /* TUT:  Create an object named "i" of type int */
>>>     i = 42; /* TUT:  Assign the value 42 to i */
>>>     i ++;   /* TUT:  Increment i by 1 */
>>
>> I've seen this done in other ways (eg, using a different font
>> for the non-code material).  It suffers from many of the same
>> problems that regular comments do.  Most importantly, it too
>> promotes or reinforces a way of thinking that is damaging to
>> less experienced programmers.  In that respect it isn't really
>> an improvement over using regular "comments".
>
> It's specifically intended to emphasize the point that such
> comments are for exposition to inexperienced programmers, and that
> such comments should not be used when such programmers are not the
> intended audience.
>
> If you think it wouldn't work, that's fine;  you may be right.

The question is, work to do what?  This proposed solution is for
a different problem than the problem I am trying to address.

[toc] | [prev] | [next] | [standalone]

#102254

David Brown <david.brown@hesbynett.no> writes:

> On 20/01/17 17:06, Richard Heathfield wrote:
>> 
>>     /* if we're just at a field boundary, we
>>        want to move to just past that boundary.
>>        If we're at the end of the string,
>>        then two things happen: (1) we can't be
>>        sure that it's legal to move past the '\0'
>>        AND (2) there is in any case nothing more
>>        to convert.
>> 
>>        So if we're not at '\0', we want ptr to
>>        point to not_converted + 1. Otherwise, we
>>        want ptr to point to not_converted (which will
>>        terminate the loop).
>> 
>>        In C, the result of a condition is either 0
>>        (false), or 1 (true), and this happens to map
>>        precisely onto what we want. So we can do this:
>>      */
>> 
>>     ptr = not_converted + (*not_converted != '\0');
>> 
>
> And how is that better than:
>
> 	if (*not_converted != '\0') {
> 		ptr = not_converted + 1;
> 	} else {
> 		ptr = not_converted;
> 	}

It's not.  Much better is

  ptr = not_converted + (*not_converted != '\0');

without the comment!  After all, it's just an addition, and if it makes
someone do a double-take on the code that's great because it means
someone else with check that it does what's needed.  Most people seeing

	if (*not_converted == '\0') {
		ptr = not_converted + 1;
	} else {
		ptr = not_converted;
	}

will just glaze over thinking "oh, yes, skip the non-null".

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102364

On 20/01/17 19:12, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 20/01/17 17:06, Richard Heathfield wrote:
>>>
>>>     /* if we're just at a field boundary, we
>>>        want to move to just past that boundary.
>>>        If we're at the end of the string,
>>>        then two things happen: (1) we can't be
>>>        sure that it's legal to move past the '\0'
>>>        AND (2) there is in any case nothing more
>>>        to convert.
>>>
>>>        So if we're not at '\0', we want ptr to
>>>        point to not_converted + 1. Otherwise, we
>>>        want ptr to point to not_converted (which will
>>>        terminate the loop).
>>>
>>>        In C, the result of a condition is either 0
>>>        (false), or 1 (true), and this happens to map
>>>        precisely onto what we want. So we can do this:
>>>      */
>>>
>>>     ptr = not_converted + (*not_converted != '\0');
>>>
>>
>> And how is that better than:
>>
>> 	if (*not_converted != '\0') {
>> 		ptr = not_converted + 1;
>> 	} else {
>> 		ptr = not_converted;
>> 	}
>
> It's not.  Much better is
>
>   ptr = not_converted + (*not_converted != '\0');
>
> without the comment!

BTW, normally I wouldn't have bothered with the comment, because...

> After all, it's just an addition,

Right. The comment was purely for Alla's benefit.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102267

On Friday, January 20, 2017 at 7:06:52 PM UTC+3, Richard Heathfield wrote:
> On 20/01/17 15:45, Alla _ wrote:
> > On Friday, January 20, 2017 at 6:17:01 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> >>>         while(not_converted > ptr && !isspace(*not_converted))
> >>
> >> Why are you interested in non-spaces? [...]
> > With this function I just need two numbers out of 5 - the first and the last
> > one. At the moment the function is called the input
> > contains numbers, separated by commas (csv format), as in
> > 1062,1252,1587,1934,2519
> 
> In which case you have no need to call isspace at all, and the whole 
> thing can be done in less than a dozen lines of very simple code.
> 
> n = 0; /* this is how many numbers you've successfully parsed */
> do
> {
>    /* try to convert a number */
>    num[n] = strtod(ptr, &not_converted, 10);
> 
>    /* if that worked... */
>    if(not_converted > ptr)
>    {
>      /* record the success */
>      ++n;
> 
>      /* if we're just at a field boundary, we
>         want to move to just past that boundary.
>         If we're at the end of the string,
>         then two things happen: (1) we can't be
>         sure that it's legal to move past the '\0'
>         AND (2) there is in any case nothing more
>         to convert.
> 
>         So if we're not at '\0', we want ptr to
>         point to not_converted + 1. Otherwise, we
>         want ptr to point to not_converted (which will
>         terminate the loop).
> 
>         In C, the result of a condition is either 0
>         (false), or 1 (true), and this happens to map
>         precisely onto what we want. So we can do this:
>       */
> 
>      ptr = not_converted + (*not_converted != '\0');
>    }
> } while(not_converted > ptr && n < expected_count);

I have just realized this: how can this loop iterate through the whole
line if:
- this is a do while loop; so things are 'done' first, and only than the 
condition is evaluated;
- if nc>ptr, the code than sets ptr to be bigger than nc, and than
the code checks if nc>ptr, and it is, of course, not, so the loop
never goes for the second round. 
> 
<snip>

[toc] | [prev] | [next] | [standalone]

#102365

On 21/01/17 07:22, Alla _ wrote:
> On Friday, January 20, 2017 at 7:06:52 PM UTC+3, Richard Heathfield wrote:
>> On 20/01/17 15:45, Alla _ wrote:
>>> On Friday, January 20, 2017 at 6:17:01 PM UTC+3, Ben Bacarisse wrote:
>>>> Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>>>>>         while(not_converted > ptr && !isspace(*not_converted))
>>>>
>>>> Why are you interested in non-spaces? [...]
>>> With this function I just need two numbers out of 5 - the first and the last
>>> one. At the moment the function is called the input
>>> contains numbers, separated by commas (csv format), as in
>>> 1062,1252,1587,1934,2519
>>
>> In which case you have no need to call isspace at all, and the whole
>> thing can be done in less than a dozen lines of very simple code.
>>
>> n = 0; /* this is how many numbers you've successfully parsed */
>> do
>> {
>>    /* try to convert a number */
>>    num[n] = strtod(ptr, &not_converted, 10);
>>
>>    /* if that worked... */
>>    if(not_converted > ptr)
>>    {
>>      /* record the success */
>>      ++n;
>>
>>      /* if we're just at a field boundary, we
>>         want to move to just past that boundary.
>>         If we're at the end of the string,
>>         then two things happen: (1) we can't be
>>         sure that it's legal to move past the '\0'
>>         AND (2) there is in any case nothing more
>>         to convert.
>>
>>         So if we're not at '\0', we want ptr to
>>         point to not_converted + 1. Otherwise, we
>>         want ptr to point to not_converted (which will
>>         terminate the loop).
>>
>>         In C, the result of a condition is either 0
>>         (false), or 1 (true), and this happens to map
>>         precisely onto what we want. So we can do this:
>>       */
>>
>>      ptr = not_converted + (*not_converted != '\0');
>>    }
>> } while(not_converted > ptr && n < expected_count);
>
> I have just realized this: how can this loop iterate through the whole
> line if:
> - this is a do while loop; so things are 'done' first, and only than the
> condition is evaluated;

<long explanation of why this is fine, snipped (and with good reason!)>

> - if nc>ptr, the code than sets ptr to be bigger than nc, and than
> the code checks if nc>ptr, and it is, of course, not, so the loop
> never goes for the second round.

Excellent! If I'd bothered to test the code, I'd have spotted that. I 
didn't bother to test the code, so I didn't spot it, but you *did* spot it.

I think you can give yourself a pat on the back for that, while I get on 
with ordering some sackcloth and ashes from eBay.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102268

On Friday, January 20, 2017 at 7:06:52 PM UTC+3, Richard Heathfield wrote:
> On 20/01/17 15:45, Alla _ wrote:
> > On Friday, January 20, 2017 at 6:17:01 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> >>>         while(not_converted > ptr && !isspace(*not_converted))
> >>
> >> Why are you interested in non-spaces? [...]
> > With this function I just need two numbers out of 5 - the first and the last
> > one. At the moment the function is called the input
> > contains numbers, separated by commas (csv format), as in
> > 1062,1252,1587,1934,2519
> 
> In which case you have no need to call isspace at all, and the whole 
> thing can be done in less than a dozen lines of very simple code.
> 
> n = 0; /* this is how many numbers you've successfully parsed */
> do
> {
>    /* try to convert a number */
>    num[n] = strtod(ptr, &not_converted, 10);
> 
>    /* if that worked... */
>    if(not_converted > ptr)
>    {
>      /* record the success */
>      ++n;
> 
>      /* if we're just at a field boundary, we
>         want to move to just past that boundary.
>         If we're at the end of the string,
>         then two things happen: (1) we can't be
>         sure that it's legal to move past the '\0'
>         AND (2) there is in any case nothing more
>         to convert.
> 
>         So if we're not at '\0', we want ptr to
>         point to not_converted + 1. Otherwise, we
>         want ptr to point to not_converted (which will
>         terminate the loop).
> 
>         In C, the result of a condition is either 0
>         (false), or 1 (true), and this happens to map
>         precisely onto what we want. So we can do this:
>       */
> 
>      ptr = not_converted + (*not_converted != '\0');
>    }
> } while(not_converted > ptr && n < expected_count);
> 
> expected_count would appear to be 5 in this case. If it's always 5, use 
> a constant e.g. #define NUMBERS_PER_LINE 5
> 
> if(n == expected_count) you have all the numbers you need. If it isn't, 
> you don't, and presumably that's an error.
> 
Here is my version. 
    int count = 0;    
    while(count < DATA_SIZE)
    {
        dat_years->sales = strtod(ptr, &not_converted);
        
        if (not_converted > ptr)
        {
            count++;
            dat_years += (count != DATA_SIZE);      // :)))))
            ptr = not_converted + (*not_converted != '\0');
        }
        else
        {
            fprintf(stderr, "Incorrect data on line %s at count %i\n", line, count);
            return false;
        }
    }

[toc] | [prev] | [next] | [standalone]

#102271

Alla _ <modelling.data@gmail.com> writes:
<snip>

> Here is my version. 
>     int count = 0;    
>     while(count < DATA_SIZE)
>     {
>         dat_years->sales = strtod(ptr, &not_converted);
>
>         if (not_converted > ptr)
>         {
>             count++;
>             dat_years += (count != DATA_SIZE);      // :)))))

This is not needed.  Presumably you are worried about adding one to
dat_years in the case where it points to the last element in the array,
but C specifically permits that.  Provided you don't access anything
using that pointer there will be no problem.

>             ptr = not_converted + (*not_converted != '\0');
>         }
<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102280

On Saturday, January 21, 2017 at 2:00:48 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> <snip>
> 
> > Here is my version. 
> >     int count = 0;    
> >     while(count < DATA_SIZE)
> >     {
> >         dat_years->sales = strtod(ptr, &not_converted);
> >
> >         if (not_converted > ptr)
> >         {
> >             count++;
> >             dat_years += (count != DATA_SIZE);      // :)))))
> 
> This is not needed.  Presumably you are worried about adding one to
> dat_years in the case where it points to the last element in the array,
> but C specifically permits that.  Provided you don't access anything
> using that pointer there will be no problem.
I see. Thank you very much. I did use that pointer to access the data, so I might
leave that for security reasons for now. 
> 
> >             ptr = not_converted + (*not_converted != '\0');
> >         }
> <snip>
> -- 
> Ben.

[toc] | [prev] | [next] | [standalone]

#102286

Alla _ <modelling.data@gmail.com> writes:

> On Saturday, January 21, 2017 at 2:00:48 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>> <snip>
>> 
>> > Here is my version. 
>> >     int count = 0;    
>> >     while(count < DATA_SIZE)
>> >     {
>> >         dat_years->sales = strtod(ptr, &not_converted);
>> >
>> >         if (not_converted > ptr)
>> >         {
>> >             count++;
>> >             dat_years += (count != DATA_SIZE);      // :)))))
>> 
>> This is not needed.  Presumably you are worried about adding one to
>> dat_years in the case where it points to the last element in the array,
>> but C specifically permits that.  Provided you don't access anything
>> using that pointer there will be no problem.
>
> I see. Thank you very much. I did use that pointer to access the data,
> so I might leave that for security reasons for now.

Really?  That seems very odd but since you did not show the part the
uses the pointer after the loop, I can't be sure.

>> >             ptr = not_converted + (*not_converted != '\0');
>> >         }
>> <snip>

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102291

On Saturday, January 21, 2017 at 8:17:20 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> > On Saturday, January 21, 2017 at 2:00:48 PM UTC+3, Ben Bacarisse wrote:
> >> Alla _ <modelling.data@gmail.com> writes:
> >> <snip>
> >> 
> >> > Here is my version. 
> >> >     int count = 0;    
> >> >     while(count < DATA_SIZE)
> >> >     {
> >> >         dat_years->sales = strtod(ptr, &not_converted);
> >> >
> >> >         if (not_converted > ptr)
> >> >         {
> >> >             count++;
> >> >             dat_years += (count != DATA_SIZE);      // :)))))
> >> 
> >> This is not needed.  Presumably you are worried about adding one to
> >> dat_years in the case where it points to the last element in the array,
> >> but C specifically permits that.  Provided you don't access anything
> >> using that pointer there will be no problem.
> >
> > I see. Thank you very much. I did use that pointer to access the data,
> > so I might leave that for security reasons for now.
> 
> Really?  That seems very odd but since you did not show the part the
> uses the pointer after the loop, I can't be sure.
It is a very bad part, which I was working on; a test one. Nothing to show.

[toc] | [prev] | [next] | [standalone]

#102255

Alla _ <modelling.data@gmail.com> writes:

> On Friday, January 20, 2017 at 6:17:01 PM UTC+3, Ben Bacarisse wrote:
<snip>
>> Why are you interested in non-spaces?  Nothing in your specification
>> seems to need non-spaces.  Can you write out what the input should look
>> like in general?  I.e. what will you permit and what won't you permit?
> With this function I just need two numbers out of 5 - the first and the last
> one. At the moment the function is called the input 
> contains numbers, separated by commas (csv format), as in
> 1062,1252,1587,1934,2519

That's not a specification of what input you accept and what input you
reject, but on reflection I don't think answering me is worth your time.
Richard has come in with some suggestions and trying to follow two
people's advice is never a good idea.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#102366

On 20/01/17 19:16, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
>
>> On Friday, January 20, 2017 at 6:17:01 PM UTC+3, Ben Bacarisse wrote:
> <snip>
>>> Why are you interested in non-spaces?  Nothing in your specification
>>> seems to need non-spaces.  Can you write out what the input should look
>>> like in general?  I.e. what will you permit and what won't you permit?
>> With this function I just need two numbers out of 5 - the first and the last
>> one. At the moment the function is called the input
>> contains numbers, separated by commas (csv format), as in
>> 1062,1252,1587,1934,2519
>
> That's not a specification of what input you accept and what input you
> reject, but on reflection I don't think answering me is worth your time.
> Richard has come in with some suggestions and trying to follow two
> people's advice is never a good idea.

On the other hand, Richard's suggested code palpably does not work. Alla 
might be better following the advice of a working Ben rather than that 
of a broken Richard.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102227

On 20/01/17 13:19, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
>> Please, help me to understand why a very simple while loop 
>> condition doesn't work - it doesn't stop the loop when I 
>> expect it to stop. 
>> Please, take a look at the piece of code, and my explanation
>> of how I intended it to perform:
>>
>> Input:
>> 1062,1252,1587,1934,2519
>>
>> Count starts at 5.
>>
>> double number_1 = strtod(ptr, &not_converted);
>>     if (not_converted > ptr)
>>     {
>>         double number_2 = 0;
>>     
>>         while(not_converted > ptr && (!isspace(*not_converted)
>>                                  || *not_converted != '\0'))
>>         {
>>             ptr = not_converted + 1;
>>             number_2 = strtod(ptr, &not_converted);
>>             count--;
>>         }
>>         if(count != 1)
>>             return false;
>>     }
>> Explanation:
>> (1) before the loop number_1 = 1062, and 
>> not_converted is ",1252,1587,1934,2519"
>> (2) not_converted is bigger than ptr, and not_converted
>> doesn't point to any space character or '\0';
> 
> That's not what your test does.  Please, please, please, if you take
> nothing else from my coaching, always negate a while condition to see
> what it is you are trying to establish:
> 
>  while(nc > ptr && (!isspace(*nc) || *nc != '\0')) ...
> 
> is trying to make the condition false.  It stops when
> 
>      !(nc > ptr  &&  (!isspace(*nc) ||   *nc != '\0'))
>   == !(nc > ptr) || !(!isspace(*nc) ||   *nc != '\0')
>   ==   nc <= ptr || (!!isspace(*nc) && !(*nc != '\0'))
>   ==   nc <= ptr ||   (isspace(*nc) &&   *nc == '\0')
>   ==   nc <= ptr || 0
>   ==   nc <= ptr
> 
> I've urged you to do this on several occasions.  Do it every time you
> write a loop until you can do it without thinking.  (It's complicated by
> break, but you should be avoiding break.)
> 
> The main logic rules involved are called De Morgan's laws:
> 
>   !(A && B) => !A || !B
>   !(A || B) => !A && !B
> 

I would also suggest that if this sort of analysis (which is a good
idea) is too complicated for you (Alla) to get right in your head, then
it is too complicated.  Consider making it simpler, such as by
extracting part of it to a separate function, using bool flag variables
that you build up in parts, or move some of the conditions inside the
loop somewhere.  If your conditional takes more than one line to write,
or contains a mixture of && and ||, then it is not going to be obvious
what it does.		


> <snip>
> 
> On another issue, a well-structured program to read numbers and checking
> how many there are will have a call to strtod in only one place.
> 

[toc] | [prev] | [next] | [standalone]

#102235

On Friday, January 20, 2017 at 4:34:22 PM UTC+3, David Brown wrote:
> On 20/01/17 13:19, Ben Bacarisse wrote:
> > Alla _ <modelling.data@gmail.com> writes:
> > 
> >> Please, help me to understand why a very simple while loop 
> >> condition doesn't work - it doesn't stop the loop when I 
> >> expect it to stop. 
> >> Please, take a look at the piece of code, and my explanation
> >> of how I intended it to perform:
> >>
> >> Input:
> >> 1062,1252,1587,1934,2519
> >>
> >> Count starts at 5.
> >>
> >> double number_1 = strtod(ptr, &not_converted);
> >>     if (not_converted > ptr)
> >>     {
> >>         double number_2 = 0;
> >>     
> >>         while(not_converted > ptr && (!isspace(*not_converted)
> >>                                  || *not_converted != '\0'))
> >>         {
> >>             ptr = not_converted + 1;
> >>             number_2 = strtod(ptr, &not_converted);
> >>             count--;
> >>         }
> >>         if(count != 1)
> >>             return false;
> >>     }
> >> Explanation:
> >> (1) before the loop number_1 = 1062, and 
> >> not_converted is ",1252,1587,1934,2519"
> >> (2) not_converted is bigger than ptr, and not_converted
> >> doesn't point to any space character or '\0';
> > 
> > That's not what your test does.  Please, please, please, if you take
> > nothing else from my coaching, always negate a while condition to see
> > what it is you are trying to establish:
> > 
> >  while(nc > ptr && (!isspace(*nc) || *nc != '\0')) ...
> > 
> > is trying to make the condition false.  It stops when
> > 
> >      !(nc > ptr  &&  (!isspace(*nc) ||   *nc != '\0'))
> >   == !(nc > ptr) || !(!isspace(*nc) ||   *nc != '\0')
> >   ==   nc <= ptr || (!!isspace(*nc) && !(*nc != '\0'))
> >   ==   nc <= ptr ||   (isspace(*nc) &&   *nc == '\0')
> >   ==   nc <= ptr || 0
> >   ==   nc <= ptr
> > 
> > I've urged you to do this on several occasions.  Do it every time you
> > write a loop until you can do it without thinking.  (It's complicated by
> > break, but you should be avoiding break.)
> > 
> > The main logic rules involved are called De Morgan's laws:
> > 
> >   !(A && B) => !A || !B
> >   !(A || B) => !A && !B
> > 
> 
> I would also suggest that if this sort of analysis (which is a good
> idea) is too complicated for you (Alla) to get right in your head, then
> it is too complicated.  Consider making it simpler, such as by
> extracting part of it to a separate function, using bool flag variables
> that you build up in parts, or move some of the conditions inside the
> loop somewhere.  If your conditional takes more than one line to write,
> or contains a mixture of && and ||, then it is not going to be obvious
> what it does.		
> 
Thank you very much. I don't see any difficulties with this type of 
analysis - it is pretty clear and very easy; these are very basic 
logic constructions. 
> 
> > <snip>
> > 
> > On another issue, a well-structured program to read numbers and checking
> > how many there are will have a call to strtod in only one place.
> >

[toc] | [prev] | [next] | [standalone]

#102237

On 20/01/17 15:40, Alla _ wrote:
> On Friday, January 20, 2017 at 4:34:22 PM UTC+3, David Brown wrote:
<snip>
>> If your conditional takes more than one line to write,
>> or contains a mixture of && and ||, then it is not going to be obvious
>> what it does.		
>>
> Thank you very much. I don't see any difficulties with this type of
> analysis - it is pretty clear and very easy; these are very basic
> logic constructions.

The fact that you got it wrong suggests that it isn't as basic as you 
might think. That isn't intended to belittle you, though - it's just a 
warning to you (and to all of us) that complicated conditionals can 
easily bite, which is why a wise programmer keeps them as simple as 
possible.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#102240

On Friday, January 20, 2017 at 6:47:15 PM UTC+3, Richard Heathfield wrote:
> On 20/01/17 15:40, Alla _ wrote:
> > On Friday, January 20, 2017 at 4:34:22 PM UTC+3, David Brown wrote:
> <snip>
> >> If your conditional takes more than one line to write,
> >> or contains a mixture of && and ||, then it is not going to be obvious
> >> what it does.		
> >>
> > Thank you very much. I don't see any difficulties with this type of
> > analysis - it is pretty clear and very easy; these are very basic
> > logic constructions.
> 
> The fact that you got it wrong suggests that it isn't as basic as you 
> might think. That isn't intended to belittle you, though - it's just a 
> warning to you (and to all of us) that complicated conditionals can 
> easily bite, which is why a wise programmer keeps them as simple as 
> possible.
Yes yes, I understand it. I truly don't think it is a complicated thing, 
especially after the explanation and check method Ben has suggested. 
I truly had that mental block, and, unfortunately, I do have them 
sometimes. Not to let these issues to occur I will do my best to 
always use this test.

[toc] | [prev] | [next] | [standalone]

#102244

On 20/01/17 17:26, Alla _ wrote:
> On Friday, January 20, 2017 at 6:47:15 PM UTC+3, Richard Heathfield wrote:
>> On 20/01/17 15:40, Alla _ wrote:
>>> On Friday, January 20, 2017 at 4:34:22 PM UTC+3, David Brown wrote:
>> <snip>
>>>> If your conditional takes more than one line to write,
>>>> or contains a mixture of && and ||, then it is not going to be obvious
>>>> what it does.		
>>>>
>>> Thank you very much. I don't see any difficulties with this type of
>>> analysis - it is pretty clear and very easy; these are very basic
>>> logic constructions.
>>
>> The fact that you got it wrong suggests that it isn't as basic as you 
>> might think. That isn't intended to belittle you, though - it's just a 
>> warning to you (and to all of us) that complicated conditionals can 
>> easily bite, which is why a wise programmer keeps them as simple as 
>> possible.
> Yes yes, I understand it. I truly don't think it is a complicated thing, 
> especially after the explanation and check method Ben has suggested. 
> I truly had that mental block, and, unfortunately, I do have them 
> sometimes. Not to let these issues to occur I will do my best to 
> always use this test.
> 

I've been doing boolean logic since I was about 12, I've worked with
programmable logic devices, I've manually simplified Karnaugh maps with
half a dozen variables, and I work with bits and flags all the time in
my low-level programming.

And to me, the original conditional was /not/ obvious and I had to think
about it.  That's why /I/ would not write a mixture like this, because I
can't see at a glance what it does.

That does not mean the logic here is "difficult" or not "basic", just
that it is not done without thought.  Multiplying two 3-digit numbers by
hand is not difficult, and the process is basic - we've all know since
primary school how it is done.  But you have to think about it, and if
you don't do so methodically (such as Ben's suggestions for analysing
the conditional), you have a good chance of getting it wrong.

[toc] | [prev] | [next] | [standalone]

#102246

On Friday, January 20, 2017 at 8:01:27 PM UTC+3, David Brown wrote:
> On 20/01/17 17:26, Alla _ wrote:
> > On Friday, January 20, 2017 at 6:47:15 PM UTC+3, Richard Heathfield wrote:
> >> On 20/01/17 15:40, Alla _ wrote:
> >>> On Friday, January 20, 2017 at 4:34:22 PM UTC+3, David Brown wrote:
> >> <snip>
> >>>> If your conditional takes more than one line to write,
> >>>> or contains a mixture of && and ||, then it is not going to be obvious
> >>>> what it does.		
> >>>>
> >>> Thank you very much. I don't see any difficulties with this type of
> >>> analysis - it is pretty clear and very easy; these are very basic
> >>> logic constructions.
> >>
> >> The fact that you got it wrong suggests that it isn't as basic as you 
> >> might think. That isn't intended to belittle you, though - it's just a 
> >> warning to you (and to all of us) that complicated conditionals can 
> >> easily bite, which is why a wise programmer keeps them as simple as 
> >> possible.
> > Yes yes, I understand it. I truly don't think it is a complicated thing, 
> > especially after the explanation and check method Ben has suggested. 
> > I truly had that mental block, and, unfortunately, I do have them 
> > sometimes. Not to let these issues to occur I will do my best to 
> > always use this test.
> > 
> 
> I've been doing boolean logic since I was about 12, I've worked with
> programmable logic devices, I've manually simplified Karnaugh maps with
> half a dozen variables, and I work with bits and flags all the time in
> my low-level programming.
> 
> And to me, the original conditional was /not/ obvious and I had to think
> about it.  That's why /I/ would not write a mixture like this, because I
> can't see at a glance what it does.
> 
> That does not mean the logic here is "difficult" or not "basic", just
> that it is not done without thought.  Multiplying two 3-digit numbers by
> hand is not difficult, and the process is basic - we've all know since
> primary school how it is done.  But you have to think about it, and if
> you don't do so methodically (such as Ben's suggestions for analysing
> the conditional), you have a good chance of getting it wrong.

David, you didn't understand me correctly. I do not even try to show off,
or anything of the sort; you might have already seen that it is not my way;
my way is to learn and to admit that I know nothing, and to do my best to 
acquire the knowledge I can. As to the logic construction we are discussing,
it is basic, and I honestly do understand it, especially after very useful
way to check suggested by Ben; and undoubtedly I am going to use
it every single time I write something. 
As to such conditions, as Richard has pointed out, "experienced 
programmers" tend to avoid them and to make as simple as possible.
The key word here is "experienced", and I am just at the beginning of 
the journey. So I believe it'll come. I also hope sometime to get to 
learning more profound logic constructions (I did have a course on
those in college, but that was a long time ago, and at that time I 
didn't understand how useful it is and how interesting it is, although
it was a course led by a brilliant. late now, professor). 
And after reading this 
"I've been doing boolean logic since I was about 12, I've worked with
> programmable logic devices, I've manually simplified Karnaugh maps with
> half a dozen variables, and I work with bits and flags all the time in
> my low-level programming",
 I know whom to consult with. 
I won't ask now, though this paragraph has kindled my interest even more,
but maybe later about what books could be helpful in learning 
the basics of the subject. 

[toc] | [prev] | [next] | [standalone]

#102248

On 20/01/17 18:26, Alla _ wrote:
> On Friday, January 20, 2017 at 8:01:27 PM UTC+3, David Brown wrote:
>> On 20/01/17 17:26, Alla _ wrote:
>>> On Friday, January 20, 2017 at 6:47:15 PM UTC+3, Richard Heathfield wrote:
>>>> On 20/01/17 15:40, Alla _ wrote:
>>>>> On Friday, January 20, 2017 at 4:34:22 PM UTC+3, David Brown wrote:
>>>> <snip>
>>>>>> If your conditional takes more than one line to write,
>>>>>> or contains a mixture of && and ||, then it is not going to be obvious
>>>>>> what it does.		
>>>>>>
>>>>> Thank you very much. I don't see any difficulties with this type of
>>>>> analysis - it is pretty clear and very easy; these are very basic
>>>>> logic constructions.
>>>>
>>>> The fact that you got it wrong suggests that it isn't as basic as you
>>>> might think. That isn't intended to belittle you, though - it's just a
>>>> warning to you (and to all of us) that complicated conditionals can
>>>> easily bite, which is why a wise programmer keeps them as simple as
>>>> possible.
>>> Yes yes, I understand it. I truly don't think it is a complicated thing,
>>> especially after the explanation and check method Ben has suggested.
>>> I truly had that mental block, and, unfortunately, I do have them
>>> sometimes. Not to let these issues to occur I will do my best to
>>> always use this test.
>>>
>>
>> I've been doing boolean logic since I was about 12, I've worked with
>> programmable logic devices, I've manually simplified Karnaugh maps with
>> half a dozen variables, and I work with bits and flags all the time in
>> my low-level programming.
>>
>> And to me, the original conditional was /not/ obvious and I had to think
>> about it.  That's why /I/ would not write a mixture like this, because I
>> can't see at a glance what it does.
>>
>> That does not mean the logic here is "difficult" or not "basic", just
>> that it is not done without thought.  Multiplying two 3-digit numbers by
>> hand is not difficult, and the process is basic - we've all know since
>> primary school how it is done.  But you have to think about it, and if
>> you don't do so methodically (such as Ben's suggestions for analysing
>> the conditional), you have a good chance of getting it wrong.
>
> David, you didn't understand me correctly. I do not even try to show off,
> or anything of the sort; you might have already seen that it is not my way;

And you have misunderstood me - I did not think you were "showing off". 
I just wanted you to be clear that even though you know how to do 
something, and even if it is not "difficult" and you can normally write 
it correctly, that does not mean it is a good way to write the code.  It 
is important that you learn to /understand/ a wide range of ways to 
write C code - but equally it is important to learn to write code that 
is as simple, easy to understand, and obviously correct as you possibly 
can.  A lot of people are bad at that!

> my way is to learn and to admit that I know nothing, and to do my best to
> acquire the knowledge I can. As to the logic construction we are discussing,
> it is basic, and I honestly do understand it, especially after very useful
> way to check suggested by Ben; and undoubtedly I am going to use
> it every single time I write something.
> As to such conditions, as Richard has pointed out, "experienced
> programmers" tend to avoid them and to make as simple as possible.
> The key word here is "experienced", and I am just at the beginning of
> the journey. So I believe it'll come.

Threads like this are giving you a short-cut to experience (though they 
certainly don't replace it).

> I also hope sometime to get to
> learning more profound logic constructions (I did have a course on
> those in college, but that was a long time ago, and at that time I
> didn't understand how useful it is and how interesting it is, although
> it was a course led by a brilliant. late now, professor).
> And after reading this
> "I've been doing boolean logic since I was about 12, I've worked with
>> programmable logic devices, I've manually simplified Karnaugh maps with
>> half a dozen variables, and I work with bits and flags all the time in
>> my low-level programming",
>  I know whom to consult with.
> I won't ask now, though this paragraph has kindled my interest even more,
> but maybe later about what books could be helpful in learning
> the basics of the subject.
>

If you need to know about Karnaugh maps or simplifying boolean logic 
while programming C, you are probably doing something wrong :-)  It is 
one of these fun skills that has mostly been replaced by software.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web