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

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

Recursion: getting input from the user

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

Contents

  Recursion: getting input from the user Alla _ <modelling.data@gmail.com> - 2017-01-30 02:06 -0800
    Re: Recursion: getting input from the user Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-30 12:11 +0000
      Re: Recursion: getting input from the user Alla _ <modelling.data@gmail.com> - 2017-01-30 04:46 -0800
        Re: Recursion: getting input from the user David Brown <david.brown@hesbynett.no> - 2017-01-30 14:35 +0100
          Re: Recursion: getting input from the user Alla _ <modelling.data@gmail.com> - 2017-01-30 05:55 -0800
        Re: Recursion: getting input from the user Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-30 17:16 +0000
    Re: Recursion: getting input from the user Barry Schwarz <schwarzb@dqel.com> - 2017-01-30 10:07 -0800
      Re: Recursion: getting input from the user Alla _ <modelling.data@gmail.com> - 2017-01-30 11:13 -0800
      Re: Recursion: getting input from the user "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-30 15:07 -0500
      Re: Recursion: getting input from the user Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-30 20:16 +0000
      Re: Recursion: getting input from the user Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 01:47 -0800
      Re: Recursion: getting input from the user supercat@casperkitty.com - 2017-02-02 12:38 -0800

#102741 — Recursion: getting input from the user

Hello!
I am trying to write a function that gets an input from the user.
If the user has not provided a correct input, then the function
should start all over again, prompting the user for another input.
I wonder why it doesn't perform the recursion. If I enter only new
line and then press ctrl D to indicate EOF, I get back the printf
message for the second time and the program stops.
When I enter a number, it correctly stores the number. 

Here is how the function is called:
av.industry_rate = industry_rate();

The function:
double industry_rate()
{
    printf("Please, enter the projected industry growth rate beyond 5 year horizon; maximum 3 numbers after the decimal point\n");
    char buf[7] = {0};
    while(fgets(buf, sizeof(buf), stdin) != NULL);
    
    if(buf[0] != '\n')
    {
        char *not_converted = NULL;
        double rate = strtod(buf, &not_converted);
        
        if(*not_converted == '\n' || *not_converted == '\t'
           || *not_converted == '\0')
        return rate;
    }
    return industry_rate();
}
Thank you!

[toc] | [next] | [standalone]

#102743

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

> I am trying to write a function that gets an input from the user.
> If the user has not provided a correct input, then the function
> should start all over again, prompting the user for another input.
> I wonder why it doesn't perform the recursion. If I enter only new
> line and then press ctrl D to indicate EOF, I get back the printf
> message for the second time and the program stops.

Here's what's happening...

The "top" call reads lines (rather short ones!) until EOF (or an error,
but let's forget about those).  You typed \nCtrl-D so fgets is called
twice.  The first time it puts \n\0 in the buffer, the second time it
puts nothing there (leaving \n\0 there).  buf[0] != '\n' is false so the
top call recurses and returns industry_rate().

This second call sets up a new buffer full of nulls and tries to read a
line.  That fails (the input is at EOF) but this time buf[0] != '\n' is
true (buf[0] is 0) so strtod is called.  No number is seen and
not_converted will be left pointing at the first null in the buffer.
Thus the test *not_converted == '\n' || *not_converted == '\t' ||
*not_converted == '\0' is also true and rate will be returned.

When I run this code I get a different effect because my Linux system
breaks C's rules for interactive input: once EOF has been seen, further
input is possible, but you really should no rely on that possibility
(and it seems your system does not do that).

It's a little odd to read all the input and then look to see if the last
line had a number on it (which seems to be the plan).  It's usually
better to read until you get some acceptable data or you find that the
stream as ended.

> When I enter a number, it correctly stores the number.

Only in some situations.  If you type \n\n100\n\nCtrl-D you won't get
100 returned.  I'm not saying that's a problem, but you should give some
thought to what you will accept as input and you won't.

> Here is how the function is called:
> av.industry_rate = industry_rate();
>
> The function:
> double industry_rate()
> {
>     printf("Please, enter the projected industry growth rate beyond 5 year horizon; maximum 3 numbers after the decimal point\n");
>     char buf[7] = {0};

That's a little small.  If someone inputs a few spaces before the number
it could get truncated.

>     while(fgets(buf, sizeof(buf), stdin) != NULL);
>     
>     if(buf[0] != '\n')
>     {
>         char *not_converted = NULL;
>         double rate = strtod(buf, &not_converted);
>         
>         if(*not_converted == '\n' || *not_converted == '\t'
>            || *not_converted == '\0')
>         return rate;

Odd indentation!

>     }
>     return industry_rate();
> }

-- 
Ben.

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

#102745

On Monday, January 30, 2017 at 3:11:11 PM UTC+3, Ben Bacarisse wrote:
> Alla _ <modelling.data@gmail.com> writes:
> 
> > I am trying to write a function that gets an input from the user.
> > If the user has not provided a correct input, then the function
> > should start all over again, prompting the user for another input.
> > I wonder why it doesn't perform the recursion. If I enter only new
> > line and then press ctrl D to indicate EOF, I get back the printf
> > message for the second time and the program stops.
> 
> Here's what's happening...
> 
> The "top" call reads lines (rather short ones!) until EOF (or an error,
> but let's forget about those).  You typed \nCtrl-D so fgets is called
> twice.  The first time it puts \n\0 in the buffer, the second time it
> puts nothing there (leaving \n\0 there).  buf[0] != '\n' is false so the
> top call recurses and returns industry_rate().
> 
> This second call sets up a new buffer full of nulls and tries to read a
> line.  That fails (the input is at EOF) but this time buf[0] != '\n' is
> true (buf[0] is 0) so strtod is called.  No number is seen and
> not_converted will be left pointing at the first null in the buffer.
> Thus the test *not_converted == '\n' || *not_converted == '\t' ||
> *not_converted == '\0' is also true and rate will be returned.
> 
> When I run this code I get a different effect because my Linux system
> breaks C's rules for interactive input: once EOF has been seen, further
> input is possible, but you really should no rely on that possibility
> (and it seems your system does not do that).
> 
> It's a little odd to read all the input and then look to see if the last
> line had a number on it (which seems to be the plan).  It's usually
> better to read until you get some acceptable data or you find that the
> stream as ended.
> 
> > When I enter a number, it correctly stores the number.
> 
> Only in some situations.  If you type \n\n100\n\nCtrl-D you won't get
> 100 returned.  I'm not saying that's a problem, but you should give some
> thought to what you will accept as input and you won't.
> 
> > Here is how the function is called:
> > av.industry_rate = industry_rate();
> >
> > The function:
> > double industry_rate()
> > {
> >     printf("Please, enter the projected industry growth rate beyond 5 year horizon; maximum 3 numbers after the decimal point\n");
> >     char buf[7] = {0};
> 
> That's a little small.  If someone inputs a few spaces before the number
> it could get truncated.
> 
> >     while(fgets(buf, sizeof(buf), stdin) != NULL);
> >     
> >     if(buf[0] != '\n')
> >     {
> >         char *not_converted = NULL;
> >         double rate = strtod(buf, &not_converted);
> >         
> >         if(*not_converted == '\n' || *not_converted == '\t'
> >            || *not_converted == '\0')
> >         return rate;
> 
> Odd indentation!
> 
> >     }
> >     return industry_rate();
I see. Thank you very much.
Solved by rewriting like this:
double industry_rate()
{
    printf("Please, enter the projected industry growth rate beyond 5 year horizon in decimal notation; max 3 numbers after decimal point\n");
    char buf[7] = {0};
    char c;
    int i = 0;
    
    while( (c = getchar()) != EOF && (c != '\n' && c != '\t'))
        buf[i++] = c;
    if (c == '\n')
        buf[i] = '\0';
    
    if(buf[0])
    {
        char *not_converted = NULL;
        double rate = strtod(buf, &not_converted);
        
        if(*not_converted == '\n' || *not_converted == '\t'
                                                || *not_converted == '\0')
        return rate;
    }
    return industry_rate();
}
What indentation will be a correct one? Is the one above
better?

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

#102755

On 30/01/17 13:46, Alla _ wrote:
> On Monday, January 30, 2017 at 3:11:11 PM UTC+3, Ben Bacarisse wrote:
>> Alla _ <modelling.data@gmail.com> writes:
>>
>>> I am trying to write a function that gets an input from the user.
>>> If the user has not provided a correct input, then the function
>>> should start all over again, prompting the user for another input.
>>> I wonder why it doesn't perform the recursion. If I enter only new
>>> line and then press ctrl D to indicate EOF, I get back the printf
>>> message for the second time and the program stops.
>>
>> Here's what's happening...
>>
>> The "top" call reads lines (rather short ones!) until EOF (or an error,
>> but let's forget about those).  You typed \nCtrl-D so fgets is called
>> twice.  The first time it puts \n\0 in the buffer, the second time it
>> puts nothing there (leaving \n\0 there).  buf[0] != '\n' is false so the
>> top call recurses and returns industry_rate().
>>
>> This second call sets up a new buffer full of nulls and tries to read a
>> line.  That fails (the input is at EOF) but this time buf[0] != '\n' is
>> true (buf[0] is 0) so strtod is called.  No number is seen and
>> not_converted will be left pointing at the first null in the buffer.
>> Thus the test *not_converted == '\n' || *not_converted == '\t' ||
>> *not_converted == '\0' is also true and rate will be returned.
>>
>> When I run this code I get a different effect because my Linux system
>> breaks C's rules for interactive input: once EOF has been seen, further
>> input is possible, but you really should no rely on that possibility
>> (and it seems your system does not do that).
>>
>> It's a little odd to read all the input and then look to see if the last
>> line had a number on it (which seems to be the plan).  It's usually
>> better to read until you get some acceptable data or you find that the
>> stream as ended.
>>
>>> When I enter a number, it correctly stores the number.
>>
>> Only in some situations.  If you type \n\n100\n\nCtrl-D you won't get
>> 100 returned.  I'm not saying that's a problem, but you should give some
>> thought to what you will accept as input and you won't.
>>
>>> Here is how the function is called:
>>> av.industry_rate = industry_rate();
>>>
>>> The function:
>>> double industry_rate()
>>> {
>>>     printf("Please, enter the projected industry growth rate beyond 5 year horizon; maximum 3 numbers after the decimal point\n");
>>>     char buf[7] = {0};
>>
>> That's a little small.  If someone inputs a few spaces before the number
>> it could get truncated.
>>
>>>     while(fgets(buf, sizeof(buf), stdin) != NULL);
>>>     
>>>     if(buf[0] != '\n')
>>>     {
>>>         char *not_converted = NULL;
>>>         double rate = strtod(buf, &not_converted);
>>>         
>>>         if(*not_converted == '\n' || *not_converted == '\t'
>>>            || *not_converted == '\0')
>>>         return rate;
>>
>> Odd indentation!
>>
>>>     }
>>>     return industry_rate();
> I see. Thank you very much.
> Solved by rewriting like this:
> double industry_rate()
> {
>     printf("Please, enter the projected industry growth rate beyond 5 year horizon in decimal notation; max 3 numbers after decimal point\n");
>     char buf[7] = {0};
>     char c;
>     int i = 0;
>     
>     while( (c = getchar()) != EOF && (c != '\n' && c != '\t'))
>         buf[i++] = c;
>     if (c == '\n')
>         buf[i] = '\0';
>     
>     if(buf[0])
>     {
>         char *not_converted = NULL;
>         double rate = strtod(buf, &not_converted);
>         
>         if(*not_converted == '\n' || *not_converted == '\t'
>                                                 || *not_converted == '\0')
>         return rate;
>     }
>     return industry_rate();
> }
> What indentation will be a correct one? Is the one above
> better?
> 

There is no "correct" indentation - there are merely many ways to have
/bad/ indentation!

You had the "if" and the "return" at the same level:

    if(*not_converted == '\n' || *not_converted == '\t'
        || *not_converted == '\0')
    return rate;

This is definitely /bad/ - not merely "odd".

If you have a line continuation, it is common to use more than one
tab-stop (or space equivalent) for the indentation, to make it clear
that the second line is a continuation, not statement controlled by the
conditional  - as you did in your second version.  But the "return"
statement /must/ be indented:

    if(*not_converted == '\n' || *not_converted == '\t'
                              || *not_converted == '\0')
        return rate;

However, I would strongly recommend you look up the "one true brace
style", and make a lot more use of braces.  It makes it much harder to
get indentation wrong or confusing, especially when changing code, or
for anyone to make a mistake when reading the code.

    if (*not_converted == '\n' || *not_converted == '\t'
                              || *not_converted == '\0') {
        return rate;
    }


/You/ decide your indentation style for your own code, but if you are
making mistakes with your current style, it is a good indication that
you should consider changing.

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

#102757

On Monday, January 30, 2017 at 4:35:50 PM UTC+3, David Brown wrote:
> On 30/01/17 13:46, Alla _ wrote:
<snip>
> >         if(*not_converted == '\n' || *not_converted == '\t'
> >                                                 || *not_converted == '\0')
> >         return rate;
> >     }
> >     return industry_rate();
> > }
> > What indentation will be a correct one? Is the one above
> > better?
> > 
> 
> There is no "correct" indentation - there are merely many ways to have
> /bad/ indentation!
> 
> You had the "if" and the "return" at the same level:
Oh! What a surprise ) Never had such things before )
Maybe that happened because of some corrections I made
and hence the indentation moved. But, common, it is not 
such a big deal, a mere typo in my case for sure ) 
> 
>     if(*not_converted == '\n' || *not_converted == '\t'
>         || *not_converted == '\0')
>     return rate;
> 
> This is definitely /bad/ - not merely "odd".
> 
> If you have a line continuation, it is common to use more than one
> tab-stop (or space equivalent) for the indentation, to make it clear
> that the second line is a continuation, not statement controlled by the
> conditional  - as you did in your second version.  But the "return"
> statement /must/ be indented:
> 
>     if(*not_converted == '\n' || *not_converted == '\t'
>                               || *not_converted == '\0')
>         return rate;
> 
> However, I would strongly recommend you look up the "one true brace
> style", and make a lot more use of braces.  It makes it much harder to
> get indentation wrong or confusing, especially when changing code, or
> for anyone to make a mistake when reading the code.
> 
>     if (*not_converted == '\n' || *not_converted == '\t'
>                               || *not_converted == '\0') {
>         return rate;
>     }
> 
> 
> /You/ decide your indentation style for your own code, but if you are
> making mistakes with your current style, it is a good indication that
> you should consider changing.
Thank you very much. I am happy that at least this is definitely not 
an issue I have to solve or learn ) I am definitely fine on this front. 
At least something is not that bad )

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

#102764

Alla _ <modelling.data@gmail.com> writes:
<snip>
> Solved by rewriting like this:

> double industry_rate()
> {
>     printf("Please, enter the projected industry growth rate beyond 5 year horizon in decimal notation; max 3 numbers after decimal point\n");
>     char buf[7] = {0};
>     char c;

int c;  (Do you remember why?)

>     int i = 0;
>     
>     while( (c = getchar()) != EOF && (c != '\n' && c != '\t'))
>         buf[i++] = c;

You can overrun the buffer.  Why do you check for a tab?

>     if (c == '\n')
>         buf[i] = '\0';

This statement serves no purpose.

>     if(buf[0])
>     {
>         char *not_converted = NULL;
>         double rate = strtod(buf, &not_converted);
>         
>         if(*not_converted == '\n' || *not_converted == '\t'
>                                                 || *not_converted == '\0')

There can't be a \n or a \t in the buffer, and if the number entered was
followed by a space *not_converted won't be == 0.  Do you really want to
reject that input?

>         return rate;
>     }
>     return industry_rate();
> }
> What indentation will be a correct one? Is the one above
> better?

I was referring to not indenting the body of the inner 'if' (i.e. the
return rate; statement).

-- 
Ben.

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

#102769

On Mon, 30 Jan 2017 02:06:42 -0800 (PST), Alla _
<modelling.data@gmail.com> wrote:

>Hello!
>I am trying to write a function that gets an input from the user.
>If the user has not provided a correct input, then the function
>should start all over again, prompting the user for another input.
>I wonder why it doesn't perform the recursion. If I enter only new
>line and then press ctrl D to indicate EOF, I get back the printf
>message for the second time and the program stops.
>When I enter a number, it correctly stores the number. 
>
>Here is how the function is called:
>av.industry_rate = industry_rate();
>
>The function:
>double industry_rate()
>{

<snip>

>    return industry_rate();
>}

Is no one going to mention that using recursion for this purpose
should be on the list of 10 worst ideas ever.  A while or do...while
loop that iterates until the input has been validated will be so much
easier to debug not to mention more efficient and less likely to
overflow the stack.

-- 
Remove del for email

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

#102780

On Monday, January 30, 2017 at 9:07:31 PM UTC+3, Barry Schwarz wrote:
> On Mon, 30 Jan 2017 02:06:42 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
> 
> >Hello!
> >I am trying to write a function that gets an input from the user.
> >If the user has not provided a correct input, then the function
> >should start all over again, prompting the user for another input.
> >I wonder why it doesn't perform the recursion. If I enter only new
> >line and then press ctrl D to indicate EOF, I get back the printf
> >message for the second time and the program stops.
> >When I enter a number, it correctly stores the number. 
> >
> >Here is how the function is called:
> >av.industry_rate = industry_rate();
> >
> >The function:
> >double industry_rate()
> >{
> 
> <snip>
> 
> >    return industry_rate();
> >}
> 
> Is no one going to mention that using recursion for this purpose
> should be on the list of 10 worst ideas ever.  A while or do...while
> loop that iterates until the input has been validated will be so much
> easier to debug not to mention more efficient and less likely to
> overflow the stack.
I will take a look what I can do to correct this. Thank you.

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

#102791

On 01/30/2017 01:07 PM, Barry Schwarz wrote:
> On Mon, 30 Jan 2017 02:06:42 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
>> Hello!
>> I am trying to write a function that gets an input from the user.
>> If the user has not provided a correct input, then the function
>> should start all over again, prompting the user for another input.
>> I wonder why it doesn't perform the recursion. If I enter only new
>> line and then press ctrl D to indicate EOF, I get back the printf
>> message for the second time and the program stops.
>> When I enter a number, it correctly stores the number.
>>
>> Here is how the function is called:
>> av.industry_rate = industry_rate();
>>
>> The function:
>> double industry_rate()
>> {
>
> <snip>
>
>>    return industry_rate();
>> }
>
> Is no one going to mention that using recursion for this purpose
> should be on the list of 10 worst ideas ever. ...

It's a very bad idea, but I don't think it makes the top 10 - the 
competition for those spots is pretty fierce. At least it's 
tail-recursion, some compilers know how to translate such recursion into 
the equivalent of the following:

> ... A while or do...while
> loop that iterates until the input has been validated will be so much
> easier to debug not to mention more efficient and less likely to
> overflow the stack.

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

#102792

Barry Schwarz <schwarzb@dqel.com> writes:

> On Mon, 30 Jan 2017 02:06:42 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
>>Hello!
>>I am trying to write a function that gets an input from the user.
>>If the user has not provided a correct input, then the function
>>should start all over again, prompting the user for another input.
>>I wonder why it doesn't perform the recursion. If I enter only new
>>line and then press ctrl D to indicate EOF, I get back the printf
>>message for the second time and the program stops.
>>When I enter a number, it correctly stores the number. 
>>
>>Here is how the function is called:
>>av.industry_rate = industry_rate();
>>
>>The function:
>>double industry_rate()
>>{
>
> <snip>
>
>>    return industry_rate();
>>}
>
> Is no one going to mention that using recursion for this purpose
> should be on the list of 10 worst ideas ever.

I'm not because I think it shows imagination.  It may not be one of the
10 *best* ideas ever, but it's very far from being in the worst 10!

> A while or do...while
> loop that iterates until the input has been validated will be so much
> easier to debug

Yes.  A loop is almost always better in this situation.

> not to mention more efficient and less likely to
> overflow the stack.

Given that it's for interactive input, the efficiency is of a call vs a
loop is going to be of no consequence, and overflowing the stack is
unlikely to be a problem.

-- 
Ben.

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

#102953

Barry Schwarz <schwarzb@dqel.com> writes:

> On Mon, 30 Jan 2017 02:06:42 -0800 (PST), Alla _
> <modelling.data@gmail.com> wrote:
>
>> Hello!
>> I am trying to write a function that gets an input from the user.
>> If the user has not provided a correct input, then the function
>> should start all over again, prompting the user for another input.
>> I wonder why it doesn't perform the recursion.  If I enter only new
>> line and then press ctrl D to indicate EOF, I get back the printf
>> message for the second time and the program stops.
>> When I enter a number, it correctly stores the number.
>>
>> Here is how the function is called:
>> av.industry_rate = industry_rate();
>>
>> The function:
>> double industry_rate()
>> {
>
> <snip>
>
>>    return industry_rate();
>> }
>
> Is no one going to mention that using recursion for this purpose
> should be on the list of 10 worst ideas ever.  A while or do...while
> loop that iterates until the input has been validated will be so much
> easier to debug not to mention more efficient and less likely to
> overflow the stack.

To me this sounds like imperative prejudice talking.  As written
the function may not be a good candidate for recursion, but there
is nothing inherent in the /purpose/ that makes it unsuitable for
(possibly) using recursion.  IME recursive solutions can be
easier to get right, equally efficient, and easily verifiable to
use constant stack space, even for situations like this one.

Please note that I don't mean to suggest this is always true.
Sometimes a recursive approach is better, and sometimes an
imperative approach is better - it depends on the details of the
particular functionality desired.  But the idea that recursion
should be rejected out-of-hand for a whole class of problems
is.. well, let me say not as thoroughly considered as it might
be.

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

#102977

On Monday, January 30, 2017 at 12:07:31 PM UTC-6, Barry Schwarz wrote:
> Is no one going to mention that using recursion for this purpose
> should be on the list of 10 worst ideas ever.  A while or do...while
> loop that iterates until the input has been validated will be so much
> easier to debug not to mention more efficient and less likely to
> overflow the stack.

There are a number of situations where the appropriate semantic concept
would be an *explicit* tail call, but unfortunately language designers
don't usually provide a distinct syntax for tail calls and ordinary calls.
Although there are some situations where having a compiler automatically
convert regular calls to tail calls would suffice (which is probably why
language designers don't include an explicit syntax), the lack of such
distinction makes it impossible for a compiler to know whether a given
call *needs* to be processed one way or the other [using a tail call can
be important if recursion depth would otherwise be unmanageable; using an
ordinary call may be important in some situations involving system-level
issues like dynamically-changing memory maps.]

I'd have no qualm about using an explicit tail call in a case where a
function needs to "start over", possibly with different arguments, but
using recursion for such purposes seems a bit icky.

[toc] | [prev] | [standalone]

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

csiph-web