Sales Commission
November 17, 2020
Here is our solution:
> (define (commission) (let loop ((commissions (list))) (display "Enter sales amount or CTRL-D: ") (let ((sale (read))) (if (eof-object? sale) (begin (newline) (values (list->vector (reverse commissions)) (sum commissions))) (let ((commission (+ (* sale 0.1) 200))) (display " Commission is ") (display commission) (newline) (loop (cons commission commissions))))))) > (commission) Enter sales amount or CTRL-D: 1000 Commission is 300.0 Enter sales amount or CTRL-D: 500 Commission is 250.0 Enter sales amount or CTRL-D: 2500 Commission is 450.0 Enter sales amount or CTRL-D: 2000 Commission is 400.0 Enter sales amount or CTRL-D: #(300.0 250.0 450.0 400.0) 1400.0
You can run the program at https://ideone.com/9G4Ngf.
Reminder: You can find all my solutions at https://gitlab.com/common-lisp-exercises/programming-praxis
Here’s a solution in Python.
Example usage:
After reading the problem specification, I realised that I did not know what was required. After looking at the preceding solutions, I realised that other people thought they knew what was required but did not agree, which made me feel
less stupid. We need either an unambiguous specification or an input-output sample. At the very least, a clear statement like “The input consists of sales numbers for a single employee, and the $200 base is applicable to each sale, even a sale of $0.” or that “The input may contain (name sale) amounts for multiple employees and the sales for a single employee need not be adjacent” or whatever.
As it stands, this is not an interesting exercise in programming but a frustrating exercise in struggling to deal with a hopeless vague specification.
@Richard A. O’Keefe : indeed, this is the normal situation in real life.
Customers come to you with problem statements that are in general:
idiotic,
ill-defined,
wrong,
not what the customer wanted,
incomplete,
contradictory,
ambiguous,
the examples are wrong and inconsistent,
and so on.
A customer cannot provide you with a formal specification, or just a consistent unambiguous problem statement, because if they could produce that, they could be programmers themselves!
So indeed, the first task, is to clarify the problem statement. In absence of a closed tight interaction loop with the customer (the teacher), you can only write down the specifications yourself. Note how my solution starts with a 13-line comment giving precisions on the input format, the output format, and the formula to be used.