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

Restricted unsigned integer range would have been better?

Started by	"Ansel" <tinker454@trytospammenowloser.com>
First post	2012-07-23 01:32 -0600
Last post	2012-08-04 22:54 -0600
Articles	20 on this page of 107 — 18 participants

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

Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-23 01:32 -0600
Re: Restricted unsigned integer range would have been better? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-23 01:45 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 00:19 -0600
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-24 11:25 +0100
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:22 -0600
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-25 01:53 +0100
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 21:43 -0600
Re: Restricted unsigned integer range would have been better? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-24 16:29 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 21:53 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:24 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:12 -0600
Re: Restricted unsigned integer range would have been better? Nobody <nobody@nowhere.com> - 2012-07-23 10:37 +0100
Re: Restricted unsigned integer range would have been better? Andre <lodwig@pathme.de> - 2012-07-23 11:46 +0200
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-23 11:33 +0100
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-23 23:48 -0600
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 10:43 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 02:58 -0700
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 12:04 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 05:32 -0700
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 14:20 +0100
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 18:41 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 12:37 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:15 -0600
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:05 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:28 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:13 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 01:26 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 05:43 -0600
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-24 15:10 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:23 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:40 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:32 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 01:29 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 05:45 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 12:35 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 00:12 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-26 01:42 -0700
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-25 09:31 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 06:28 -0600
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-25 16:28 +0200
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-25 17:17 +0100
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-26 12:07 +0200
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-26 14:06 +0100
Re: Restricted unsigned integer range would have been better? James Kuyper <jameskuyper@verizon.net> - 2012-07-26 09:45 -0400
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-30 09:01 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 00:09 -0600
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-26 00:52 -0700
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-26 20:35 -0400
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 22:35 -0600
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-27 09:19 -0400
Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 12:51 -0500
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-27 16:19 -0700
Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 18:47 -0500
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-30 09:10 +0200
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-07-31 17:26 -1000
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 00:18 -0400
Re: Restricted unsigned integer range would have been better? "io_x" <a@b.c.invalid> - 2012-08-01 10:19 +0200
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-01 10:09 +0200
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 12:51 +0100
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 08:18 -0400
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 14:22 +0100
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 09:57 -0400
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 11:35 -0400
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:43 -0700
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-09-08 10:13 -0400
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:39 -0700
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:45 -0700
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 13:52 -0800
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 13:45 -0800
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-12-17 19:51 -0500
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-12-28 11:11 -0800
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-29 11:31 -0800
Re: Restricted unsigned integer range would have been better? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-29 23:59 +0000
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:01 -0800
Re: Restricted unsigned integer range would have been better? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-05 12:00 +0200
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2013-01-02 13:07 -0800
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-03 12:10 -0800
Re: Restricted unsigned integer range would have been better? James Kuyper <jameskuyper@verizon.net> - 2013-01-05 12:26 -0500
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:35 -0700
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:02 -0800
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-01 10:06 +0200
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 12:46 +0100
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-08-02 08:19 -1000
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-08-02 08:17 -1000
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-03 08:04 +0200
Re: Restricted unsigned integer range would have been better? "io_x" <a@b.c.invalid> - 2012-08-03 09:40 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-27 22:27 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-28 01:31 -0700
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-28 10:52 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-28 03:31 -0700
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-28 00:05 -0400
Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 23:22 -0500
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-27 22:35 -0600
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-04 08:43 -0700
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-04 16:40 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:58 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-04 23:10 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 01:16 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-05 02:25 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 03:35 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-05 12:16 -0700
Re: Restricted unsigned integer range would have been better? gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-05 19:56 +0000
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:12 -0600
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:07 -0600
Re: Restricted unsigned integer range would have been better? gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-05 13:33 +0000
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:13 -0600
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:54 -0600

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

#24052

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2012-08-01 14:22 +0100
Message-ID	<0.837a8fa3b84a81796f37.20120801142215BST.87lihy4uig.fsf@bsb.me.uk>
In reply to	#24048

pete <pfiland@mindspring.com> writes:

> Ben Bacarisse wrote:
<snip>
>> > On 01/08/2012 06:18, pete wrote:
>> >> Philip Lantz wrote:
<snip>
>> >>>    5. while (*s != '\0')
>> >>>           n = n * 10 + (*s - '0');
<snip>
>> >> If n is of type int and also not negative,
>> >> then you could write without having to use parentheses
>> >>      n = n * 10 - '0' + *s;
>> >> with no possibility of overflow.
>> 
>> I don't understand that.  Did you mean "and also unsigned" rather than
>> "and also not negative"?
>
> No. 
> It reminded me of a line from a toy atoi 
> that I once wrote as an exercise.

Ah!  You meant that the parentheses can be removed without causing an
otherwise avoidable overflow, I think.  Both versions can overflow, but
the "bad" version (n = n * 10 + *s - '0') can cause a needless overflow.

<snip>
-- 
Ben.

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

#24053

From	pete <pfiland@mindspring.com>
Date	2012-08-01 09:57 -0400
Message-ID	<501935C7.5D52@mindspring.com>
In reply to	#24052

Ben Bacarisse wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Ben Bacarisse wrote:
> <snip>
> >> > On 01/08/2012 06:18, pete wrote:
> >> >> Philip Lantz wrote:
> <snip>
> >> >>>    5. while (*s != '\0')
> >> >>>           n = n * 10 + (*s - '0');
> <snip>
> >> >> If n is of type int and also not negative,
> >> >> then you could write without having to use parentheses
> >> >>      n = n * 10 - '0' + *s;
> >> >> with no possibility of overflow.
> >>
> >> I don't understand that.
> >> Did you mean "and also unsigned" rather than
> >> "and also not negative"?
> >
> > No.
> > It reminded me of a line from a toy atoi
> > that I once wrote as an exercise.
> 
> Ah!  You meant that the parentheses can be removed without causing an
> otherwise avoidable overflow, I think.

Yes. That's what I meant.
Thank you.

> Both versions can overflow, but
> the "bad" version (n = n * 10 + *s - '0')
> can cause a needless overflow.

I also think I should change the condition my loop from
        while (isdigit(*nptr)) {
to 
        while (*nptr != '\0') {
similar to what Philip Lantz had.
I think that the spirit of atoi
is that it is supposed to be a simple function,
which is only to be used 
when it is known that the input won't cause any problems.

-- 
pete

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

#24063

From	pete <pfiland@mindspring.com>
Date	2012-08-01 11:35 -0400
Message-ID	<50194CB7.285A@mindspring.com>
In reply to	#24053

pete wrote:
 
> I also think I should change the condition my loop from
>         while (isdigit(*nptr)) {
> to
>         while (*nptr != '\0') {
> similar to what Philip Lantz had.
> I think that the spirit of atoi
> is that it is supposed to be a simple function,
> which is only to be used
> when it is known that the input won't cause any problems.

However, my intention was that the function which I wrote,
should do what the standard says that atoi does.

atoi is described in terms of what strtol does.
And since strtol is described as 
decomposing the string into three parts,
(the middle one being called "the subject sequence")
and only operating on the subject sequence,
I think that 
    while (isdigit(*nptr)) {
is the way for the code that I wrote,
to do what I want.

-- 
pete

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

#26075

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2012-09-07 11:43 -0700
Message-ID	<kfn1uidisi3.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#24038

pete <pfiland@mindspring.com> writes:

> Philip Lantz wrote:
>> [..snip..snip..]
>>
>> Do you really? Would you use casts in situations like these?
>>   5. while (*s != '\0')
>>          n = n * 10 + (*s - '0');
>> 
>> I would find them to be undesirable clutter.
>
> I was thinking the same thing.
>
> And I think you meant to imply 
> that (*s) is an expression of type char.
>
> If n is of type int and also not negative,
> then you could write without having to use parentheses
>     n = n * 10 - '0' + *s;
> with no possibility of overflow.

Is there some reason you wouldn't write

    n = *s-'0' + n*10;   /* or add more spacing, if preferred */

?

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

#26141

From	pete <pfiland@mindspring.com>
Date	2012-09-08 10:13 -0400
Message-ID	<504B529D.35AA@mindspring.com>
In reply to	#26075

Tim Rentsch wrote:
> 
> pete <pfiland@mindspring.com> writes:
> 
> > Philip Lantz wrote:
> >> [..snip..snip..]
> >>
> >> Do you really? Would you use casts in situations like these?
> >>   5. while (*s != '\0')
> >>          n = n * 10 + (*s - '0');
> >>
> >> I would find them to be undesirable clutter.
> >
> > I was thinking the same thing.
> >
> > And I think you meant to imply
> > that (*s) is an expression of type char.
> >
> > If n is of type int and also not negative,
> > then you could write without having to use parentheses
> >     n = n * 10 - '0' + *s;
> > with no possibility of overflow.
> 
> Is there some reason you wouldn't write
> 
>     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> 
> ?


Not any good reason.

I have an aesthetic preference 
for writing the more strongly associated arithmetic operators first.

-- 
pete

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

#26602

From	Philip Lantz <prl@canterey.us>
Date	2012-09-22 23:39 -0700
Message-ID	<MPG.2ac84e9a3020d2b89896c6@news.eternal-september.org>
In reply to	#26141

pete wrote:
> Tim Rentsch wrote:
> > pete writes:
> > > Philip Lantz wrote:
> > >> [..snip..snip..]
> > >>
> > >>   5. while (*s != '\0')
> > >>          n = n * 10 + (*s - '0');
> > >>
> > > If n is of type int and also not negative,
> > > then you could write without having to use parentheses
> > >     n = n * 10 - '0' + *s;
> > > with no possibility of overflow.
> > 
> > Is there some reason you wouldn't write
> > 
> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> > 
> > ?
> 
> 
> Not any good reason.
> 
> I have an aesthetic preference 
> for writing the more strongly associated arithmetic operators first.

I think aesthetics *is* a good reason for writing code a certain way. 
Too bad everyone doesn't agree with *my* aesthetic sense. :-) But even 
when it differs, it's still way better than code written by those who 
have no aesthetic sense at all.

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

#26603

From	Philip Lantz <prl@canterey.us>
Date	2012-09-22 23:45 -0700
Message-ID	<MPG.2ac84fed7c8972ee9896c7@news.eternal-september.org>
In reply to	#26602

Philip Lantz wrote:
> pete wrote:
> > Tim Rentsch wrote:
> > > pete writes:
> > > > Philip Lantz wrote:
> > > >> [..snip..snip..]
> > > >>
> > > >>   5. while (*s != '\0')
> > > >>          n = n * 10 + (*s - '0');
> > > >>
> > > > If n is of type int and also not negative,
> > > > then you could write without having to use parentheses
> > > >     n = n * 10 - '0' + *s;
> > > > with no possibility of overflow.
> > > 
> > > Is there some reason you wouldn't write
> > > 
> > >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> > > 
> > > ?
> > 
> > 
> > Not any good reason.
> > 
> > I have an aesthetic preference 
> > for writing the more strongly associated arithmetic operators first.
> 
> I think aesthetics *is* a good reason for writing code a certain way. 
> Too bad everyone doesn't agree with *my* aesthetic sense. :-) But even 
> when it differs, it's still way better than code written by those who 
> have no aesthetic sense at all.

Oh, oops, I just realized someone might think I was talking about Tim 
when I wrote this. I wasn't! Just a general comment on the applicability 
of aesthetics to coding.

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

#29431

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2012-12-17 13:52 -0800
Message-ID	<kfnd2y8gxcu.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#26603

Philip Lantz <prl@canterey.us> writes:

> Philip Lantz wrote:
>> pete wrote:
>> > Tim Rentsch wrote:
>> > > pete writes:
>> > > > Philip Lantz wrote:
>> > > >> [..snip..snip..]
>> > > >>
>> > > >>   5. while (*s != '\0')
>> > > >>          n = n * 10 + (*s - '0');
>> > > >>
>> > > > If n is of type int and also not negative,
>> > > > then you could write without having to use parentheses
>> > > >     n = n * 10 - '0' + *s;
>> > > > with no possibility of overflow.
>> > > 
>> > > Is there some reason you wouldn't write
>> > > 
>> > >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
>> > > 
>> > > ?
>> > 
>> > 
>> > Not any good reason.
>> > 
>> > I have an aesthetic preference 
>> > for writing the more strongly associated arithmetic operators first.
>> 
>> I think aesthetics *is* a good reason for writing code a certain way. 
>> Too bad everyone doesn't agree with *my* aesthetic sense. :-) But even 
>> when it differs, it's still way better than code written by those who 
>> have no aesthetic sense at all.
>
> Oh, oops, I just realized someone might think I was talking about Tim 
> when I wrote this.

Certainly I was not given that impression.

> I wasn't! Just a general comment on the applicability 
> of aesthetics to coding.

The key point, I think, is that different people have different
aesthetic judgments, and also have different weights for how
important the different factors are.  Oh, maybe I would add
another one, namely, sometimes people will write things one
way rather than another just because that's how they're used
to writing it.  That tendency can also be dangerous, as Dijkstra
has discussed in his writings.

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

#29429

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2012-12-17 13:45 -0800
Message-ID	<kfnhankgxnz.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#26602

Philip Lantz <prl@canterey.us> writes:

> pete wrote:
>> Tim Rentsch wrote:
>> > pete writes:
>> > > Philip Lantz wrote:
>> > >> [..snip..snip..]
>> > >>
>> > >>   5. while (*s != '\0')
>> > >>          n = n * 10 + (*s - '0');
>> > >>
>> > > If n is of type int and also not negative,
>> > > then you could write without having to use parentheses
>> > >     n = n * 10 - '0' + *s;
>> > > with no possibility of overflow.
>> > 
>> > Is there some reason you wouldn't write
>> > 
>> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
>> > 
>> > ?
>> 
>> 
>> Not any good reason.
>> 
>> I have an aesthetic preference 
>> for writing the more strongly associated arithmetic operators first.
>
> I think aesthetics *is* a good reason for writing code a certain way.
> [snip elaboration]

Sure, but not the only one.  In writing, for example, it is my
preference not to split an infinitive.  Sometimes, though, it's
awkward to just blindly follow that rule.  In the particular
case here (ie, in assigning to n), IMO there is very little
difference aesthetically between the two writings, and the
second one even might be a little easier to digest when reading
it.  Partly I was curious how much of the choice was an actual
conscious process and how much was doing things a particular way
just because that's the way the author is used to doing them.

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

#29451

From	pete <pfiland@mindspring.com>
Date	2012-12-17 19:51 -0500
Message-ID	<50CFBDF9.39F5@mindspring.com>
In reply to	#29429

Tim Rentsch wrote:
> 
> Philip Lantz <prl@canterey.us> writes:
> 
> > pete wrote:
> >> Tim Rentsch wrote:
> >> > pete writes:
> >> > > Philip Lantz wrote:
> >> > >> [..snip..snip..]
> >> > >>
> >> > >>   5. while (*s != '\0')
> >> > >>          n = n * 10 + (*s - '0');
> >> > >>
> >> > > If n is of type int and also not negative,
> >> > > then you could write without having to use parentheses
> >> > >     n = n * 10 - '0' + *s;
> >> > > with no possibility of overflow.
> >> >
> >> > Is there some reason you wouldn't write
> >> >
> >> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> >> >
> >> > ?
> >>
> >>
> >> Not any good reason.
> >>
> >> I have an aesthetic preference
> >> for writing the more strongly associated 
> >> arithmetic operators first.
> >
> > I think aesthetics *is* a good reason
> > for writing code a certain way.
> > [snip elaboration]
> 
> Sure, but not the only one.  In writing, for example, it is my
> preference not to split an infinitive. 

My preference is to not split an infinitive.
No, wait ..., I told that wrong ;)

> Sometimes, though, it's
> awkward to just blindly follow that rule.  In the particular
> case here (ie, in assigning to n), IMO there is very little
> difference aesthetically between the two writings, and the
> second one even might be a little easier to digest when reading
> it.  Partly I was curious how much of the choice was an actual
> conscious process and how much was doing things a particular way
> just because that's the way the author is used to doing them.

I frequently imagine a processor with an accumulator
and I write the values in the order that I imagine them being accessed.

But sometimes, I'll write something like
    digit = n - 10 * tenth;
even though
    digit = tenth * -10 + n;
fits that rule better,
just because I prefer the looks of
    digit = n - 10 * tenth;
and then I have to say "I don't really know why".

-- 
pete

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

#29735

From	Philip Lantz <prl@canterey.us>
Date	2012-12-28 11:11 -0800
Message-ID	<MPG.2b47124e204513a69896e3@news.eternal-september.org>
In reply to	#29429

Tim Rentsch wrote:
> Philip Lantz writes:
> > pete wrote:
> >> Tim Rentsch wrote:
> >> > pete writes:
> >> > > Philip Lantz wrote:
> >> > >> [..snip..snip..]
> >> > >>
> >> > >>   5. while (*s != '\0')
> >> > >>          n = n * 10 + (*s - '0');
> >> > >>
> >> > > If n is of type int and also not negative,
> >> > > then you could write without having to use parentheses
> >> > >     n = n * 10 - '0' + *s;
> >> > > with no possibility of overflow.
> >> > 
> >> > Is there some reason you wouldn't write
> >> > 
> >> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> >> > 
> >> > ?
> >> 
> >> 
> >> Not any good reason.
> >> 
> >> I have an aesthetic preference 
> >> for writing the more strongly associated arithmetic operators first.
> >
> > I think aesthetics *is* a good reason for writing code a certain way.
> > [snip elaboration]
> 
> Sure, but not the only one.  In writing, for example, it is my
> preference not to split an infinitive.  Sometimes, though, it's
> awkward to just blindly follow that rule.  In the particular
> case here (ie, in assigning to n), IMO there is very little
> difference aesthetically between the two writings, and the
> second one even might be a little easier to digest when reading
> it.  Partly I was curious how much of the choice was an actual
> conscious process and how much was doing things a particular way
> just because that's the way the author is used to doing them.

It was conscious, because I had to consider whether to add the 
parentheses. In my usual work environment, they wouldn't matter, so I 
would very likely leave them out. In this newsgroup, little omissions 
like that can get you attacked without mercy. :-)  So I did think about 
whether to put in the parentheses, and that caused me to carefully 
consider the whole expression. I stand by my choice, although I do 
recognize that, as you said, different people weigh the factors 
differently.

However, I honestly don't see the factors that cause you you prefer your 
formulation, or why you said (in another post in this thread) that 
there's no reason to choose
    while ('\0' != *s)
over
    while (*s != '\0')
(some people think there is, as I'm sure you know, but I don't), but you 
said that there are reasons other than aesthetics to choose
    n = *s-'0' + n*10;
over
    n = n * 10 + (*s - '0');
(Or did I misunderstand that?)

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

#29743

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2012-12-29 11:31 -0800
Message-ID	<kfnvcbk1wqm.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#29735

Philip Lantz <prl@canterey.us> writes:

> Tim Rentsch wrote:
>> Philip Lantz writes:
>> > pete wrote:
>> >> Tim Rentsch wrote:
>> >> > pete writes:
>> >> > > Philip Lantz wrote:
>> >> > >> [..snip..snip..]
>> >> > >>
>> >> > >>   5. while (*s != '\0')
>> >> > >>          n = n * 10 + (*s - '0');
>> >> > >>
>> >> > > If n is of type int and also not negative,
>> >> > > then you could write without having to use parentheses
>> >> > >     n = n * 10 - '0' + *s;
>> >> > > with no possibility of overflow.
>> >> > 
>> >> > Is there some reason you wouldn't write
>> >> > 
>> >> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
>> >> > 
>> >> > ?
>> >> 
>> >> 
>> >> Not any good reason.
>> >> 
>> >> I have an aesthetic preference 
>> >> for writing the more strongly associated arithmetic operators first.
>> >
>> > I think aesthetics *is* a good reason for writing code a certain way.
>> > [snip elaboration]
>> 
>> Sure, but not the only one.  In writing, for example, it is my
>> preference not to split an infinitive.  Sometimes, though, it's
>> awkward to just blindly follow that rule.  In the particular
>> case here (ie, in assigning to n), IMO there is very little
>> difference aesthetically between the two writings, and the
>> second one even might be a little easier to digest when reading
>> it.  Partly I was curious how much of the choice was an actual
>> conscious process and how much was doing things a particular way
>> just because that's the way the author is used to doing them.
>
> It was conscious, because I had to consider whether to add the
> parentheses.  In my usual work environment, they wouldn't
> matter, so I would very likely leave them out.  In this
> newsgroup, little omissions like that can get you attacked
> without mercy. :-)  So I did think about whether to put in the
> parentheses, and that caused me to carefully consider the whole
> expression.

Sorry, I wasn't clear.  What I was (and am) curious about is
the choice between putting the multiplication term first or
second.  Were both of those among the alternatives you
considered?  (And, unimportant side issue:  how about 10*n
instead of n*10?)

> I stand by my choice, although I do recognize that, as you
> said, different people weigh the factors differently.

At least as interesting as what choice was made is what factors
were considered.  Your comment about the (putative) reaction in
the work environment, for example, isn't one I would have thought
of right off the bat.

> However, I honestly don't see the factors that cause you you
> prefer your formulation,

I mentioned one in the posting.  Did you not see that?  And are
there really no other possible factors that you could think of?

> or why you said (in another post in this thread) that 
> there's no reason to choose
>     while ('\0' != *s)
> over
>     while (*s != '\0')
> (some people think there is, as I'm sure you know, but I
> don't),

Not exactly.  I have seen reasons stated for preferring

    if(0==*s)    // or some other constant besides 0

over

    if(*s==0)

but I don't remember that reasoning being extended to the '!='
operator.  It is of course possible to make an indirect argument
for the '!=' case, based on the proposed argument for the '=='
case, but I don't remember it (either the case or the indirect
argument) being discussed.  So I still don't know of any direct
reason to prefer  0 != *s  to  *s != 0.

> but you 
> said that there are reasons other than aesthetics to choose
>     n = *s-'0' + n*10;
> over
>     n = n * 10 + (*s - '0');
> (Or did I misunderstand that?)

What I said was the writing with the '*' done second might be
easier to digest;  because that formulation doesn't have (or
need) parentheses, they don't have to be scanned, and no mental
effort is required for why they might be necessary, unlike the
formulation that does have parentheses.  Surely you can imagine
other plausible motivations (eg, related to workplace reactions)
for distinguishing the two, besides just aesthetic concerns --
yes?

If I may be philosophical for a moment, IME reactions on style
issues (considering this case purely a style issue, which of
course it isn't, at least not purely) tend to fall into one of
two camps, namely:  one, style choices are purely a matter of
preference, just follow whatever the local customs are;  and two,
there are definite reasons for preferring one style over another,
and the preferred style should be followed without exception.  I
believe neither of these camps is right.  In many cases there is
no reason to prefer strongly one style over another, and when
that holds consistency with local custom should dominate.  In
other cases there are good and compelling reasons for preferring
one style over another, and in those cases it is important to set
or influence local custom to go in the right direction.  And
finally, it's almost never true that following a single style
choice in every circumstance, and without any alternative or
exceptions, is the best course of action.  When advocating a
particular style choice (for a class of situations, but one
particular choice to apply to those situations), it's important
to discuss the limits or possible exceptional circumstances when
an alternate choice might be better.  But that's kind of a
digression from the topic here, so please excuse my indulgence.

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

#29745

From	glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date	2012-12-29 23:59 +0000
Message-ID	<kbo05r$lj3$1@speranza.aioe.org>
In reply to	#29743

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Philip Lantz <prl@canterey.us> writes:
 

(snip)
>>> >> > >>          n = n * 10 + (*s - '0');

(snip)
>>> Sure, but not the only one.  In writing, for example, it is my
>>> preference not to split an infinitive.  

>> It was conscious, because I had to consider whether to add the
>> parentheses.  In my usual work environment, they wouldn't
>> matter, so I would very likely leave them out.  In this
>> newsgroup, little omissions like that can get you attacked
>> without mercy. :-)  So I did think about whether to put in the
>> parentheses, and that caused me to carefully consider the whole
>> expression.
 
> Sorry, I wasn't clear.  What I was (and am) curious about is
> the choice between putting the multiplication term first or
> second.  Were both of those among the alternatives you
> considered?  (And, unimportant side issue:  how about 10*n
> instead of n*10?)

Usual math notation for polynomials puts the higher powers on
the left, and the coefficient to the left of the variable.
 
>> I stand by my choice, although I do recognize that, as you
>> said, different people weigh the factors differently.
 
> At least as interesting as what choice was made is what factors
> were considered.  Your comment about the (putative) reaction in
> the work environment, for example, isn't one I would have thought
> of right off the bat.
 
(snip)

>> or why you said (in another post in this thread) that 
>> there's no reason to choose
>>     while ('\0' != *s)
>> over
>>     while (*s != '\0')
>> (some people think there is, as I'm sure you know, but I
>> don't),
 
> Not exactly.  I have seen reasons stated for preferring
 
>    if(0==*s)    // or some other constant besides 0
 
> over
 
>    if(*s==0)

Not that I never make mistakes, but I don't especially 
like the (0==*s) form.
 
> but I don't remember that reasoning being extended to the '!='
> operator.  It is of course possible to make an indirect argument
> for the '!=' case, based on the proposed argument for the '=='
> case, but I don't remember it (either the case or the indirect
> argument) being discussed.  So I still don't know of any direct
> reason to prefer  0 != *s  to  *s != 0.

Well, supposedly the (0==*s) form is to guard against accidentally
writing (0=*s) which will generate a compiler error.

Seems to me that when one meant (0!=*s) one could still accidentally
write (0=*s). Then again, there are a very large number of ways one
can miswrite an expression such that the compiler doesn't detect the
error. 
 
>> but you 
>> said that there are reasons other than aesthetics to choose
>>     n = *s-'0' + n*10;
>> over
>>     n = n * 10 + (*s - '0');
>> (Or did I misunderstand that?)
 
> What I said was the writing with the '*' done second might be
> easier to digest;  because that formulation doesn't have (or
> need) parentheses, they don't have to be scanned, and no mental
> effort is required for why they might be necessary, unlike the
> formulation that does have parentheses.  Surely you can imagine
> other plausible motivations (eg, related to workplace reactions)
> for distinguishing the two, besides just aesthetic concerns --
> yes?

As I wrote above, normal math notation for polynomials puts the
higher powers on the left. Assuming I dind't have to worry about
overflow, I would probably write  n * 10 + *s - '0', though
the form (*s - '0') emphasizes the conversion.

If I did need to worry about overflow, then it likely requires
more tests to avoid, possibly with the multiply and add on
separate statements.
 
> If I may be philosophical for a moment, IME reactions on style
> issues (considering this case purely a style issue, which of
> course it isn't, at least not purely) tend to fall into one of
> two camps, namely:  one, style choices are purely a matter of
> preference, just follow whatever the local customs are;  and two,
> there are definite reasons for preferring one style over another,
> and the preferred style should be followed without exception.  

Yes. And often the preferred style isn't the most natural or
most readable. 

> I believe neither of these camps is right.  In many cases there
> is no reason to prefer strongly one style over another, and when
> that holds consistency with local custom should dominate.  In
> other cases there are good and compelling reasons for preferring
> one style over another, and in those cases it is important to set
> or influence local custom to go in the right direction.  And
> finally, it's almost never true that following a single style
> choice in every circumstance, and without any alternative or
> exceptions, is the best course of action.  When advocating a
> particular style choice (for a class of situations, but one
> particular choice to apply to those situations), it's important
> to discuss the limits or possible exceptional circumstances when
> an alternate choice might be better.  But that's kind of a
> digression from the topic here, so please excuse my indulgence.

-- glen

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

#29780

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2013-01-02 10:01 -0800
Message-ID	<kfna9srea6p.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#29745

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Philip Lantz <prl@canterey.us> writes:
> 
>>> [considering  n = n * 10 + (*s - '0')   vs   n = *s-'0' + n*10 ]
>
>>> It was conscious, because I had to consider whether to add the
>>> parentheses.  In my usual work environment, they wouldn't
>>> matter, so I would very likely leave them out.  In this
>>> newsgroup, little omissions like that can get you attacked
>>> without mercy. :-)  So I did think about whether to put in the
>>> parentheses, and that caused me to carefully consider the whole
>>> expression.
>  
>> Sorry, I wasn't clear.  What I was (and am) curious about is
>> the choice between putting the multiplication term first or
>> second.  Were both of those among the alternatives you
>> considered?  (And, unimportant side issue:  how about 10*n
>> instead of n*10?)
>
> Usual math notation for polynomials puts the higher powers on
> the left, and the coefficient to the left of the variable.
> [snip elaboration and unrelated]

I don't find this idea very compelling either as explanation or as
argument.  That is one common notation, but certainly not the only
one.  Also it's true that the expression in question happens to be
a polynomial, but I expect that observation would not occur to
most software developers who write code to do such things.  At
best it suggests there may be an unconscious habit of writing the
multiplication first, and probably there is some truth in that,
but that's a far cry from making an aesthetic choice.  It seems
much more likely that people tend to write the multiplication
first simply because the first textbook or example they read of
how to do base conversion used 'n*10 + digit', or something
similar, in its code.

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

#29834

From	Phil Carmody <thefatphil_demunged@yahoo.co.uk>
Date	2013-01-05 12:00 +0200
Message-ID	<878v88ne3r.fsf@bazspaz.fatphil.org>
In reply to	#29780

Tim Rentsch <txr@alumni.caltech.edu> writes:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
..
> > Usual math notation for polynomials puts the higher powers on
> > the left, and the coefficient to the left of the variable.
> > [snip elaboration and unrelated]
> 
> I don't find this idea very compelling either as explanation or as
> argument.  That is one common notation, but certainly not the only
> one.

Absolutely. In perturbation theory, p-adic arithmetic, probability 
and statistics, and calculus, it's absolutely standard to have the
exponents increase as you move right. The "usual notation" argument
is completely hollow.

The strongest argument for ordering the operands for me is the one 
that makes the code self-descriptive - the code says what the human
would say to explain it. What are we doing? We're multiplying n by 
10 and adding the new digit. I.e.  n = n * 10 + (*pd - '0');
In particular, I like the line begining "n = n ...", as that says 
in the clearest possible way (apart from the 'op=' notiation which
can't perform multiple modifications, both * and +) that we're 
modifying the prior value of n.

Phil
-- 
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.

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

#29786

From	Philip Lantz <prl@canterey.us>
Date	2013-01-02 13:07 -0800
Message-ID	<MPG.2b4e418d9ea630709896e4@news.eternal-september.org>
In reply to	#29743

Tim Rentsch wrote:
> Philip Lantz writes:
> > Tim Rentsch wrote:
> >> Philip Lantz writes:
> >> > pete wrote:
> >> >> Tim Rentsch wrote:
> >> >> > pete writes:
> >> >> > > Philip Lantz wrote:
> >> >> > >> [..snip..snip..]
> >> >> > >>
> >> >> > >>   5. while (*s != '\0')
> >> >> > >>          n = n * 10 + (*s - '0');
> >> >> > >>
> >> >> > > If n is of type int and also not negative,
> >> >> > > then you could write without having to use parentheses
> >> >> > >     n = n * 10 - '0' + *s;
> >> >> > > with no possibility of overflow.
> >> >> > 
> >> >> > Is there some reason you wouldn't write
> >> >> > 
> >> >> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> >> >> > 
> >> >> > ?
> >> >> 
> >> >> 
> >> >> Not any good reason.
> >> >> 
> >> >> I have an aesthetic preference 
> >> >> for writing the more strongly associated arithmetic operators first.
> >> >
> >> > I think aesthetics *is* a good reason for writing code a certain way.
> >> > [snip elaboration]
> >> 
> >> Sure, but not the only one.  In writing, for example, it is my
> >> preference not to split an infinitive.  Sometimes, though, it's
> >> awkward to just blindly follow that rule.  In the particular
> >> case here (ie, in assigning to n), IMO there is very little
> >> difference aesthetically between the two writings, and the
> >> second one even might be a little easier to digest when reading
> >> it.  Partly I was curious how much of the choice was an actual
> >> conscious process and how much was doing things a particular way
> >> just because that's the way the author is used to doing them.
> >
> > It was conscious, because I had to consider whether to add the
> > parentheses.  In my usual work environment, they wouldn't
> > matter, so I would very likely leave them out.  In this
> > newsgroup, little omissions like that can get you attacked
> > without mercy. :-)  So I did think about whether to put in the
> > parentheses, and that caused me to carefully consider the whole
> > expression.
> 
> Sorry, I wasn't clear.  What I was (and am) curious about is
> the choice between putting the multiplication term first or
> second.  Were both of those among the alternatives you
> considered?  (And, unimportant side issue:  how about 10*n
> instead of n*10?)

It was clear--I only made the comment about the parentheses because it 
caused me to consider the entire expression somewhat more carefully that 
I might have otherwise. Hence I can say with confidence now, weeks 
later, that it really is what I wanted to write, not just what I 
happened to type first.

I think of the expression as "what I'm doing to n": multiplying it by 10 
and adding something. So I write it in that order. I didn't consider 
other specific alternatives, but I considered whether the expression as 
written said what I wanted it to say. (I'm writing this as applied to 
that one situation, but I'm describing my usual way of writing code, 
which is, of course, the point.)

> > However, I honestly don't see the factors that cause you you
> > prefer your formulation,
> 
> I mentioned one in the posting.  Did you not see that?

No, and rereading both the context above and your original response, I 
still don't see it.

> > or why you said (in another post in this thread) that 
> > there's no reason to choose
> >     while ('\0' != *s)
> > over
> >     while (*s != '\0')
> > (some people think there is, as I'm sure you know, but I
> > don't),
> 
> Not exactly.  I have seen reasons stated for preferring
> 
>     if(0==*s)    // or some other constant besides 0
> 
> over
> 
>     if(*s==0)
> 
> but I don't remember that reasoning being extended to the '!='
> operator.  It is of course possible to make an indirect argument
> for the '!=' case, based on the proposed argument for the '=='
> case, but I don't remember it (either the case or the indirect
> argument) being discussed.  So I still don't know of any direct
> reason to prefer  0 != *s  to  *s != 0.

<laugh> Of course, you're right. Since I have never liked that approach, 
I didn't even think about the difference in applicability between == and 
!=.

> > but you 
> > said that there are reasons other than aesthetics to choose
> >     n = *s-'0' + n*10;
> > over
> >     n = n * 10 + (*s - '0');
> > (Or did I misunderstand that?)
> 
> What I said was the writing with the '*' done second might be
> easier to digest;  because that formulation doesn't have (or
> need) parentheses, they don't have to be scanned, and no mental
> effort is required for why they might be necessary, unlike the
> formulation that does have parentheses.

I disagree completely. The precedence of operations is critical to 
reading the expression, and the mental effort required to understand 
that precedence is not increased in this case with the parentheses 
explicit. (Of course, this only applies with a very limited number of 
parentheses, as in this example; I certainly am not encouraging lots of 
redundant parentheses.)

> If I may be philosophical for a moment, IME reactions on style
> issues (considering this case purely a style issue, which of
> course it isn't, at least not purely)

Again you say this isn't purely a style issue, but I still haven't seen 
you say what, specifically, you regard as a non-style issue here. I'm 
beginning to think that you and I have different ideas as to what 
constitutes style. The only reason I see above that you give for a 
different way of writing this is that it "might be easier to digest". 
That seems to me to fall *completely* within the bounds of 
style/aesthetics. (To me those two words cover the same ground.)

> In many cases there is
> no reason to prefer strongly one style over another, and when
> that holds consistency with local custom should dominate.  In
> other cases there are good and compelling reasons for preferring
> one style over another, and in those cases it is important to set
> or influence local custom to go in the right direction.  And
> finally, it's almost never true that following a single style
> choice in every circumstance, and without any alternative or
> exceptions, is the best course of action.  When advocating a
> particular style choice (for a class of situations, but one
> particular choice to apply to those situations), it's important
> to discuss the limits or possible exceptional circumstances when
> an alternate choice might be better.

I agree completely.

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

#29798

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2013-01-03 12:10 -0800
Message-ID	<kfnhamyc9jy.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#29786

Philip Lantz <prl@canterey.us> writes:

> Tim Rentsch wrote:
>> Philip Lantz writes:
>> > Tim Rentsch wrote:
>> >> Philip Lantz writes:
>> >> > pete wrote:
>> >> >> Tim Rentsch wrote:
>> >> >> > pete writes:
>> >> >> > > Philip Lantz wrote:
>> >> >> > >> [..snip..snip..]
>> >> >> > >>
>> >> >> > >>   5. while (*s != '\0')
>> >> >> > >>          n = n * 10 + (*s - '0');
>> >> >> > >>
>> >> >> > > If n is of type int and also not negative,
>> >> >> > > then you could write without having to use parentheses
>> >> >> > >     n = n * 10 - '0' + *s;
>> >> >> > > with no possibility of overflow.
>> >> >> > 
>> >> >> > Is there some reason you wouldn't write
>> >> >> > 
>> >> >> >     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
>> >> >> > 
>> >> >> > ?
>> >> >> 
>> >> >> 
>> >> >> Not any good reason.
>> >> >> 
>> >> >> I have an aesthetic preference 
>> >> >> for writing the more strongly associated arithmetic operators first.
>> >> >
>> >> > I think aesthetics *is* a good reason for writing code a certain way.
>> >> > [snip elaboration]
>> >> 
>> >> Sure, but not the only one.  In writing, for example, it is my
>> >> preference not to split an infinitive.  Sometimes, though, it's
>> >> awkward to just blindly follow that rule.  In the particular
>> >> case here (ie, in assigning to n), IMO there is very little
>> >> difference aesthetically between the two writings, and the
>> >> second one even might be a little easier to digest when reading
>> >> it.  Partly I was curious how much of the choice was an actual
>> >> conscious process and how much was doing things a particular way
>> >> just because that's the way the author is used to doing them.
>> >
>> > It was conscious, because I had to consider whether to add the
>> > parentheses.  In my usual work environment, they wouldn't
>> > matter, so I would very likely leave them out.  In this
>> > newsgroup, little omissions like that can get you attacked
>> > without mercy. :-)  So I did think about whether to put in the
>> > parentheses, and that caused me to carefully consider the whole
>> > expression.
>> 
>> Sorry, I wasn't clear.  What I was (and am) curious about is
>> the choice between putting the multiplication term first or
>> second.  Were both of those among the alternatives you
>> considered?  (And, unimportant side issue:  how about 10*n
>> instead of n*10?)
>
> It was clear--I only made the comment about the parentheses
> because it caused me to consider the entire expression somewhat
> more carefully that I might have otherwise.  Hence I can say
> with confidence now, weeks later, that it really is what I
> wanted to write, not just what I happened to type first.
>
> I think of the expression as "what I'm doing to n":  multiplying
> it by 10 and adding something.  So I write it in that order.  I
> didn't consider other specific alternatives, but I considered
> whether the expression as written said what I wanted it to say.
> (I'm writing this as applied to that one situation, but I'm
> describing my usual way of writing code, which is, of course, the
> point.)

It really is what you wanted to write, out of the set of one
alternative that you considered?  Does this mean you think
no other alternative could possibly be better, or only that
this writing is good enough so you don't have to think about
other ways to write it?


>> > However, I honestly don't see the factors that cause you you
>> > prefer your formulation,
>> 
>> I mentioned one in the posting.  Did you not see that?
>
> No, and rereading both the context above and your original
> response, I still don't see it.

Sorry, I guess I was too terse.


>> > or why you said (in another post in this thread) that 
>> > there's no reason to choose
>> >     while ('\0' != *s)
>> > over
>> >     while (*s != '\0')
>> > (some people think there is, as I'm sure you know, but I
>> > don't),
>> 
>> Not exactly.  I have seen reasons stated for preferring
>> 
>>     if(0==*s)    // or some other constant besides 0
>> 
>> over
>> 
>>     if(*s==0)
>> 
>> but I don't remember that reasoning being extended to the '!='
>> operator.  It is of course possible to make an indirect argument
>> for the '!=' case, based on the proposed argument for the '=='
>> case, but I don't remember it (either the case or the indirect
>> argument) being discussed.  So I still don't know of any direct
>> reason to prefer  0 != *s  to  *s != 0.
>
> <laugh> Of course, you're right. Since I have never liked that
> approach, I didn't even think about the difference in
> applicability between == and !=.

I hadn't either until I had the example in front of me.


>> > but you 
>> > said that there are reasons other than aesthetics to choose
>> >     n = *s-'0' + n*10;
>> > over
>> >     n = n * 10 + (*s - '0');
>> > (Or did I misunderstand that?)
>> 
>> What I said was the writing with the '*' done second might be
>> easier to digest;  because that formulation doesn't have (or
>> need) parentheses, they don't have to be scanned, and no mental
>> effort is required for why they might be necessary, unlike the
>> formulation that does have parentheses.
>
> I disagree completely.  The precedence of operations is
> critical to reading the expression, and the mental effort
> required to understand that precedence is not increased in this
> case with the parentheses explicit.  (Of course, this only
> applies with a very limited number of parentheses, as in this
> example;  I certainly am not encouraging lots of redundant
> parentheses.)

You disagree meaning you personally don't find that writing
easier to digest, or you disagree meaning you don't think
it's possible that anyone could find it easier to digest?
Or perhaps most people?


>> If I may be philosophical for a moment, IME reactions on style
>> issues (considering this case purely a style issue, which of
>> course it isn't, at least not purely)
>
> Again you say this isn't purely a style issue, but I still
> haven't seen you say what, specifically, you regard as a
> non-style issue here.  I'm beginning to think that you and I
> have different ideas as to what constitutes style.  The only
> reason I see above that you give for a different way of writing
> this is that it "might be easier to digest".  That seems to me
> to fall *completely* within the bounds of style/aesthetics.
> (To me those two words cover the same ground.)

In programming, I think I would say something is purely a style
issue if all the alternatives being considered are obviously
semantically equivalent.  The word 'obviously' is obviously
somewhat fuzzy.  The word 'equivalent' is also fuzzy in the
sense I mean to use it here, which is weaker than 'identical'
but stronger than 'isomorphic' (eg, an N**2 algorithm is not
"equivalent" in this sense to an N * log N algorithm, even
though their externally visible behavior may be identical if
performance is ignored;  whereas 'for(;;)' and 'while(1)' seem
close enough to be called "equivalent").

In the thread of this discussion, some of the alternatives that
have come up are (the spacing may not match exactly, please
ignore that):

    n = n * 10 + *s - '0';
    n = n * 10 + (*s - '0');
    n = n * 10 - '0' + *s;
    n = *s-'0' + n*10;

Certainly these are not all semantically equivalent, since when
overflow happens isn't always the same in the different cases.
Not couting that, are all of these _obviously_ equivalent?  At
some level I think we're having the discussion precisely because
it isn't immediately obvious that the expression '*s-'0' + n*10'
does what you want it to do.  It's clear enough if System 2
thinking is used, but maybe not if just System 1 thinking is
used.  (These terms in the sense of "Thinking, Fast and Slow",
by Kahneman.)  Does that all make sense?  I'm definitely
interested to hear what you mean by "style" if it would draw
different sorts of boundaries.


>> In many cases there is
>> no reason to prefer strongly one style over another, and when
>> that holds consistency with local custom should dominate.  In
>> other cases there are good and compelling reasons for preferring
>> one style over another, and in those cases it is important to set
>> or influence local custom to go in the right direction.  And
>> finally, it's almost never true that following a single style
>> choice in every circumstance, and without any alternative or
>> exceptions, is the best course of action.  When advocating a
>> particular style choice (for a class of situations, but one
>> particular choice to apply to those situations), it's important
>> to discuss the limits or possible exceptional circumstances when
>> an alternate choice might be better.
>
> I agree completely.

That is reassuring, at least we agree on something. :)

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

#29838

From	James Kuyper <jameskuyper@verizon.net>
Date	2013-01-05 12:26 -0500
Message-ID	<kc9no7$1sv$1@dont-email.me>
In reply to	#29786

On 01/02/2013 04:07 PM, Philip Lantz wrote:
...
> I disagree completely. The precedence of operations is critical to 
> reading the expression, and the mental effort required to understand 
> that precedence is not increased in this case with the parentheses 
> explicit. (Of course, this only applies with a very limited number of 
> parentheses, as in this example; I certainly am not encouraging lots of 
> redundant parentheses.)

For me, redundant parenthesis always cause a slight slowdown in my
reading of an expression, because I have to carefully consider the
possibility that I misunderstood something that makes them not
redundant. That's only a significant effect in very complicated
expressions, but it always has some effect, even for the simplest ones.

It's similar, in that regard, to unnecessary casts - I always have to
stop and consider the possibility that I've misunderstood something that
might have made the cast necessary.

People who have more confidence (whether or not it's warranted) in their
ability to not make such mistakes probably don't suffer the same slowdown.
-- 
James Kuyper

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

#26601

From	Philip Lantz <prl@canterey.us>
Date	2012-09-22 23:35 -0700
Message-ID	<MPG.2ac84d7cee4577f79896c5@news.eternal-september.org>
In reply to	#26075

Tim Rentsch wrote:
> pete writes:
> > Philip Lantz wrote:
> >> [..snip..snip..]
> >>
> >>   5. while (*s != '\0')
> >>          n = n * 10 + (*s - '0');
> >> 
> > If n is of type int and also not negative,
> > then you could write without having to use parentheses
> >     n = n * 10 - '0' + *s;
> > with no possibility of overflow.
> 
> Is there some reason you wouldn't write
> 
>     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
> 
> ?

Yes. It's the same reason I wouldn't write
    while ('\0' != *s)
-- it doesn't correspond to the way I think of the operation. That 
applies to pete's suggestion, too, by the way.

I wasn't even thinking of overflow when I wrote that; I put in the 
parentheses to make it abundantly clear to the reader what the statement 
is doing.

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

#29434

From	Tim Rentsch <txr@alumni.caltech.edu>
Date	2012-12-17 14:02 -0800
Message-ID	<kfn8v8wgwwe.fsf@x-alumni2.alumni.caltech.edu>
In reply to	#26601

Philip Lantz <prl@canterey.us> writes:

> Tim Rentsch wrote:
>> pete writes:
>> > Philip Lantz wrote:
>> >> [..snip..snip..]
>> >>
>> >>   5. while (*s != '\0')
>> >>          n = n * 10 + (*s - '0');
>> >> 
>> > If n is of type int and also not negative,
>> > then you could write without having to use parentheses
>> >     n = n * 10 - '0' + *s;
>> > with no possibility of overflow.
>> 
>> Is there some reason you wouldn't write
>> 
>>     n = *s-'0' + n*10;   /* or add more spacing, if preferred */
>> 
>> ?
>
> Yes. It's the same reason I wouldn't write
>     while ('\0' != *s)
> -- it doesn't correspond to the way I think of the operation. That 
> applies to pete's suggestion, too, by the way.  [snip elaboration]

But there's an important difference between the two cases,
namely, in the second one there is no other reason to choose the
alternate formulation over the original, whereas in the first
there are.  I'm not trying to argue that either formulation (ie,
of the assignment to n) is compelling necessarily, only that
there are weights on both sides of the scale.

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

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

csiph-web

Restricted unsigned integer range would have been better?

Contents

#24052

#24053

#24063

#26075

#26141

#26602

#26603

#29431

#29429

#29451

#29735

#29743

#29745

#29780

#29834

#29786

#29798

#29838

#26601

#29434