In article <6d8002d0.0309110229.2b9231c0@posting.google.com>, 
deane_gavin@hotmail.com says...

[ ... ]

> OK, so we can assume 64 bits are available. Why can we also assume
> that no airline will choose to use a 20 digit ticket number? 

Because the airlines have agreed that the number is always 10 digits.  
If that standard should change, they might just as easily change the 
"checksum" part as the number of digits, so trying to write code that 
generates the current check-digit with more digits is pointless.

> All my
> credit and bank cards have 16 digit numbers, plus (these days) three
> security digits. This will just fit in 64 bits. But by your argument,
> because it would take nearly a third of a million years to use up all
> the available numbers at one million per second, the banks are being
> non-sensical and satisfying their requirements is irrelevant.

Credit card numbers are an entirely different sort of thing.  The 
requirements are totally different, so the size of number is different.  
I certainly did NOT say that 64-bit numbers were sufficient for every 
possible task ever, only that they were more than adequate for THIS 
task.  As it happens, that assertion was absolutely correct.

[ ... ]
 
> See above. The customer pays my wages. Unless they have signed a piece
> of paper accepting that 20 digit serial numbers will not work, I
> produce code that can cope with that.

See above.  The airlines have already agreed that the serial number is 
always 10 digits, so software does not need to accept any more than that 
-- in fact, properly written software should reject any more than that.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Jerry Coffin wrote:

> Because the airlines have agreed that the number is always 10 digits.
> If that standard should change, they might just as easily change the
> "checksum" part as the number of digits, so trying to write code that
> generates the current check-digit with more digits is pointless.

What color is the sky on your world, Jerry? I don't think it's the
same one I'm in. I've had managers come up to me any number of times
and make small changes to a spec and expect them to be easy to
implement. Let's consider a scenario:

Manager: Hi Tom, I've just come from a meeting. Due to increased
security requirements all the airlines will be increasing the ticket
numbers from 10 digits to 25. The new digits will hold a lot of
extra identity information. You won't have to worry about what they
do, though. Just change your code for the new length.

Option 1: Tom: Oh. Gee. My code uses a fixed-length integer to
compute the checksum. I'll have to rewrite it. Won't take long, but
I'm in the middle of that other urgent project...

Option 2: Tom: No problem, my code will work on any length number.
I'll just change the field length in the header and recompile.

-- 
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'gbzmlpu@cbobk.pbz' | rot13

Jerry Coffin  wrote in message
news:MPG.19ca2bffcdce2e609896b4@news.west.earthlink.net...
> In article ,
> no@email.provided says...
>
> [ ... ]
>
> > > In short, your assertion is wrong: my method is guaranteed to work.
> >
> > See how it goes with this:
> > 76562091829833252963
>
> That number simply isn't allowed as an airline ticket number.

In what country? By what airline? Please provide evidence.

Why do you think the problem description included "lengthy" (ticket number),
"Don't attempt to read the number in a single step", which you promptly did,
and "Carry out the division on its digits one at a time", which you ignored?

DW

Jerry Coffin  wrote in message
news:MPG.19ca2dee77d265019896b5@news.west.earthlink.net...
> In article <6d8002d0.0309110229.2b9231c0@posting.google.com>,
> deane_gavin@hotmail.com says...
>
> [ ... ]
>
> > OK, so we can assume 64 bits are available. Why can we also assume
> > that no airline will choose to use a 20 digit ticket number?
>
> Because the airlines have agreed that the number is always 10 digits.
> If that standard should change, they might just as easily change the
> "checksum" part as the number of digits, so trying to write code that
> generates the current check-digit with more digits is pointless.

This is irrelevant to the exercise. Do you really think that students doing
computing exercises are supposed to know how long airline ticket numbers
are? If there were a maximum length the exercise would say so.

This question is from a 2001 Computer Science exam. The OP's description
isn't exactly the one given in the exam. The complete question, which may be
found at http://tinyurl.com/n29n, is:
* * * *
3.[8] Airline tickets are assigned lengthy identifying numbers, such as
47715497443. To be valid, the last digit of the number must match the
reminder when the other digits - as a group are divided by 7. (For example,
4771549744 divided by 7 yields the reminder 3.) Write a program that checks
whether or not an airline ticket number is valid. The program should prompt:
Enter ticket number:

a user should enter the number, and the program should answer VALID or
INVALID.
Assume that the tickets numbers are too big to be stored as long integer.

Hint: Don=t attempt to read the number in a single step. Instead, use
getchar to obtain digits one by one. Carry out the division one digit at
time, being careful not to include the last digit in the division.
* * * *

Now, Jerry, let's assume that your code can easily be adapted to work with a
long long or a double. With a student's future possibly hanging on the
outcome of this question, what answer do you think the examiners were
expecting?

DW

In article , 
no@email.provided says...

[ ... ]

> In what country? By what airline? Please provide evidence.

To all appearances, any airline in any country on earth.  If you want 
the standard, you're going to have to get it yourself.
 
> Why do you think the problem description included "lengthy" (ticket number),
> "Don't attempt to read the number in a single step", which you promptly did,
> and "Carry out the division on its digits one at a time", which you ignored?

Because the person who wrote the description was a moron, or perhaps 
simply because he was trying to take a simple problem and turn it into 
something more complex.  Your later post that this was used as part of a 
programming contest would tend to indicate the latter.  The choice 
between the two is more or less irrelevant. 

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

In article <3F6087E2.E8CF67E1@pobox.com>, tztemp25@pobox.com says...
> Jerry Coffin wrote:
> 
> > Because the airlines have agreed that the number is always 10 digits.
> > If that standard should change, they might just as easily change the
> > "checksum" part as the number of digits, so trying to write code that
> > generates the current check-digit with more digits is pointless.
> 
> What color is the sky on your world, Jerry? I don't think it's the
> same one I'm in. I've had managers come up to me any number of times
> and make small changes to a spec and expect them to be easy to
> implement. Let's consider a scenario:

1) this is not a spec that one manager changes -- it's an international 
standard that changes rarely if at all.

2) I never, at any point, stated that the standard would never change -- 
only that if it did change, there was absolutely NO guarantee that the 
length would be what changed, and the rest of figuring the check digit 
would remain constant.  The fact is, the current length is more than 
adequate for a long time to come, while there would be a considerable 
gain if they changed it to use something like a self-correcting code 
instead of the current one.

The fact is, when you write code you can't plan for every possible 
change, and if you attempted to do so, you'd end up with an unholy mess. 
Therefore, you have to develop good judgement about what's likely to 
change and what's not, and develop accordingly.  So far, you've yet to 
show any reason to believe that changing the length of this particular 
number is at all likely.

The Q&A format only wastes space -- it does nothing to change the 
fundamental indefensibility of your position.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

On Thu, 11 Sep 2003 13:59:49 +0000, Jerry Coffin wrote:

> In article <6d8002d0.0309110229.2b9231c0@posting.google.com>, 
> deane_gavin@hotmail.com says...
> 
> [ ... ]
> 
>> OK, so we can assume 64 bits are available. Why can we also assume
>> that no airline will choose to use a 20 digit ticket number? 
> 
> Because the airlines have agreed that the number is always 10 digits.  

Actually, a quick Google search informed me that they are thirteen digits,
counting the final "check" digit. So a long long would technically work.
However, the actual length of the digits was not part of the problem
description, and therefor it cannot be taken into account, IMO.

Update: I found an airline ticket lying around (from American Airlines, if
it matters). It has a fourteen-digit ticket number. Methinks the length of
ticket numbers may not be as granite-engraved as you are led to believe.

Josh

Jerry Coffin  wrote in message
news:MPG.19cab4ad273e6fff9896b7@news.west.earthlink.net...
> In article ,
> no@email.provided says...
> > Why do you think the problem description included "lengthy" (ticket
number),
> > "Don't attempt to read the number in a single step", which you promptly
did,
> > and "Carry out the division on its digits one at a time", which you
ignored?
>
> Because the person who wrote the description was a moron, or perhaps
> simply because he was trying to take a simple problem and turn it into
> something more complex.

Or because he had in mind the algorithm he wanted the student to write, and
chose airline-ticket numbers of unspecified length as a _hypothetical_
application for it. Further, by applying a little of the common sense and
insight that one reasonably expects a competent computer science student to
possess, he probably expected the student to understand what is required and
not get hung up on real-world details that are clearly irrelevant to the
stated problem.

DW

On Fri, 12 Sep 2003 02:22:31 +0000, Jerry Coffin wrote:

> In article , curien@cox.net 
> says...
> 
> [ ... ]
> 
>> Actually, a quick Google search informed me that they are thirteen digits,
>> counting the final "check" digit.
> 
> There are two "x's", a 10 digit number, and the check digit.

The page I found said there were 13 /digits/.
http://jwilson.coe.uga.edu/EMT668/EMT668.Folders.F97/Waggener/Units/IDNumbers/checkdigits.htm#mod7\

I don't know if it's right or not.
 
>> Update: I found an airline ticket lying around (from American Airlines,
>> if it matters). It has a fourteen-digit ticket number. Methinks the
>> length of ticket numbers may not be as granite-engraved as you are led
>> to believe.
> 
> Methinks if you honestly want us to believe that, you'd better be
> prepared to show some reason to believe it

I have a ticket on my desk. Well, it's a boarding pass. The number on it
is 10012158878422. There are no 'x's other than in the labels. Maybe
boarding passes are different (though it says "PASSENGER TICKET AND
BAGGAGE CHECK" at the top).

Josh

In article <3F6087E2.E8CF67E1@pobox.com>, tztemp25@pobox.com says...

[ ... ]

> What color is the sky on your world, Jerry? I don't think it's the
> same one I'm in. I've had managers come up to me any number of times
> and make small changes to a spec and expect them to be easy to
> implement. Let's consider a scenario:

Looking at my previous follow-up to this, I see that while I've alluded 
to the defects in some of the alternatives offered, I've never really 
pointed them out explicitly.  Perhaps it's worthwhile to do so, and 
compare them to what I offered, and point out why I think the latter is 
better.

Here's what I posted:

	char *names[2] = { "Invalid", "Valid" };

	long digits, ticket_number, check_digit;

	scanf("%ld", &digits);

	ticket_number = digits / 10;
	check_digit = digits % 10;

	printf("%s\n", names[ticket_number % 7 == check_digit]);

Now, it's definitely true that for this to work correctly, the variables 
need to be changed from long to long long (at the time I wasn't sure 
whether this was homework, and if I think something might be, I attempt 
to ensure that anything I post will need at least a little reading, 
understanding and modification before it can be turned in).

Now, what's good about this: first it does input.  Then it does 
processing.  Then it does output.  The strings that are output are 
separated from the code that prints them out.  IMO, the single biggest 
defect in the code is that it puts the "%7 == check_digit" into the 
printf statement.

In code that was being written for real use, we should have something 
like this:

bool check_ticket_number(std::input_iterator in);

that checks the number, completely separately from the rest of the code.  
For localization, the "valid" and "invalid" should really be read from a 
separate file rather than encoded as constants; the code is basically 
written with that in mind, but the details that are irrelevant to the 
task at hand left out.

Now, let's take a look at what David White posted:

#include 

int main()
{
    int k = 0;
    int c = 0;
    while((c = getchar()) != '\n')
    {
        k = (k*10 + (c - '0')) % 7;
    }
    printf("\nRemainder=%d\n", k);
    return 0;
}

Now, what (IMO, obviously) is bad about this?

First and foremost, it (obviously) doesn't attempt to solve the original 
problem at all.  Ignoring that, however, it still has some major 
shortcomings, which are more or less diametrically opposed to what I 
said was good about what I posted.  First of all, the input is almost 
inextricably intertwined with the processing -- to separate the two, we 
have to completely rewrite both.  Second, it assumes that the only 
possible terminator to the number is a new-line.  Third, what it prints 
out is directly encoded as a string constant in the printf statement, 
making localization considerably more difficult.

To get back to your original question: the color of the sky in my world 
is blue.  Here, the lengths of numbers on airline tickets change only 
very rarely, and since there are literally thousands of machines of all 
sorts all over the world that "know" about the current format, there is 
also a great deal of warning before such a thing happens.

By contrast, user interfaces change constantly -- to the point that 
writing one code base to support two or three is within the realms of 
possibility, so processing must always be separated from I/O.  
Requirements for language support are typically at least as stringent -- 
not only is it typically necessary to support more than one language at 
time, BUT it's usually required that the code should not need to be 
recompiled to convert from one language to the next, and adding support 
for a new language should normally only require the services of 
competent translator for that language, NOT a programmer scanning 
through printf statements to find places that need changing.

So, in the end, you're more or less correct: some parts of specs do 
change frequently and on short notice.  Other pars typically do not.  
Unfortunately, just about any code that follows the "hint" that was 
given will get this exactly backwards: it has an easy time dealing with 
a change will happen only rarely and with a great deal of warning, but 
adds considerable difficulty in dealing with changes that are basically 
certain to happen, and probably on a regular basis at that.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.