Re: silly behavior of factor(6)

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Apr 28, 2010, at 9:45 01AM, David Laight wrote:

> On Tue, Apr 27, 2010 at 05:07:10PM -0400, Matthew Mondor wrote:
>> On Tue, 27 Apr 2010 20:19:05 +0000
>> David Holland <dholland-tech%netbsd.org@localhost> wrote:
>> 
>>> I fixed the man page the other day to match the current behavior.
>>> However, the first issue you see is because of getopt; factor -- -10
>>> behaves as expected.
>> 
>> Hmm I wonder why getopt(3) is used at all if factor(6) supports no options
>> whatsoever...
> 
> To follow the standard so that options can be added in the future.
> 
> FWIW, my thoughs is that the product of the numbers on the RHS (of the
> result) should be equal to the value on the left.
> 
> This would mean that all these are possible valid answers:
> 0:
> 0: 0
> 1: 1

Actually, I don't agree that the first answer here is valid.  More precisely, 
its validity depends on the defined semantics of a null set, which could take 
us back where we were.  We can get away from the arbitrariness if we define the 
result r as

        for (i=0; i < n; i++) r *= p[i]

in which case a null set has the initial value of r -- and that, of course, is 
1.  But that leads to other unpleasant implications.

So -- saying

        0: 0

is simple and correct; saying

        0:

is only good if you're trying to indicate an anomalous input, since its natural 
implications don't work.

Of course, we're all spending far too many pixels on this...


                --Steve Bellovin, http://www.cs.columbia.edu/~smb