Clock

[rabestro]

Closes #303

[rabestro]

Hi colleagues,

How about to add .editorconfig file to the repo root to prevent issues with a newline ending? https://editorconfig.org/

[rabestro]

I'm wondering if there might be a more structured approach to the input data. +cc @glennj for thoughts on that.

In Bash track equals is not used at all.

Since subtract and add operations use only positive numbers the other approach is to not use keywords at all.

1. Create - we use two numbers
2. Add/Subtract - we use three numbers with +/- for each
3. Equals - we use four numbers

In the program we can use only NF to distinguish between the different cases:

BEGIN {
    MinutesInHour = 60
    MinutesInDay = MinutesInHour * 24
}
NF == 2 {
    printClock(clock($1, $2))
}
NF == 3 {
    printClock(clock($1, $2 + $3))
}
NF == 4 {
    print clock($1, $2) == clock($3, $4) ? "true" : "false"
}
function clock(hours, minutes) {
    return ((hours * MinutesInHour + minutes) % MinutesInDay + MinutesInDay) % MinutesInDay
}
function printClock(minutes) {
    printf "%02d:%02d\n", int(minutes / MinutesInHour), minutes % MinutesInHour
}

[IsaacG]

In the program we can use only NF to distinguish between the different cases:

I'm thinking more along the lines of not having to depend on NF or empty fields. What if $1 always contained the operation?

[rabestro]

In the program we can use only NF to distinguish between the different cases:

I'm thinking more along the lines of not having to depend on NF or empty fields. What if $1 always contained the operation?

This thought also crossed my mind. So, input data can be like:

create 8 15 
create -4 75
add 8 15 45
subtract 23 67 81
equals 21 15 45 15

$1 like a function or property name.

Compare with the current approach:

8 15 
-4 75
8 15 add 45
23 67 subtract 81
21 15 equals 45 15

50%/50% for me :)

@glennj, @kotp what do you think about this?

[kotp]

In the program we can use only NF to distinguish between the different cases:

@glennj, @kotp what do you think about this?

I like the add clock time time pattern. It is easy to remember. But the operator in the middle makes it easier to "normalize" inputs, in case there are only minutes given and not hours before or after that operator, rather than both hour and minute values given for one or both.

Do what you want to show and teach.

[IsaacG]

I like the add clock time time pattern. It is easy to remember. But the operator in the middle makes it easier to "normalize" inputs, in case there are only minutes given and not hours before or after that operator, rather than both hour and minute values given for one or both.

Do what you want to show and teach.

We could also do something like have multi-line programs, though that breaks with the standard paradigm.

add
HH MM
MM

The add line could indicate that two lines should be read.

[rabestro]

I like the add clock time time pattern. It is easy to remember. But the operator in the middle makes it easier to "normalize" inputs, in case there are only minutes given and not hours before or after that operator, rather than both hour and minute values given for one or both. Do what you want to show and teach.

We could also do something like have multi-line programs, though that breaks with the standard paradigm.

add
HH MM
MM

The add line could indicate that two lines should be read.

The AWK for processing records and fields. If we Introduce some specific format, this will increase the complexity of easy exercise.

Three options are equal from my point of view:

1. The current implementation
2. The property as the first field and arguments in the next fields
3. Without property names, just numeric fields.

Let's keep this exercise simple.

[kotp]

The add line could indicate that two lines should be read.

The "two lines" being "two records" and since we are already processing a variable number of fields in the records, this may not increase complexity, really. But think of lines (which may be the case, but the idea is fields and records) and that changes the problem.

Let's keep this exercise simple. - @rabestro

Let's add the minimum complexity necessary.

There is no reason that this exercise is inherently simple and must be constrained to that, but also, let's add only the minimal possible to make it "good".

We have already introduced variable fields in a record, by suggestion of

create 8 15 
create -4 75
add 8 15 45
subtract 23 67 81
equals 21 15 45 15

The data suggested is adding complexity since there is no indication that the number of fields is fixed. So we must figure out what happens if we have only 3, what if there are 4, what must happen if there is 5? The 5 is the simplest case, really, as there is no less doubt as to what represents 0 for minutes or is that hours, and for which time?"

[rabestro]

Hi team,

Do we agree on this format:

create 8 15 
create -4 75
add 8 15 45
subtract 23 67 81
equals 21 15 45 15

The exemplar solution will be:

BEGIN {
    MinutesInHour = 60
    MinutesInDay = MinutesInHour * 24
}
$1 == "create" {
    printClock(clock($2, $3))
}
$1 == "add" {
    printClock(clock($2, $3 + $4))
}
$1 == "subtract" {
    printClock(clock($2, $3 - $4))
}
$1 == "equal" {
    print clock($2, $3) == clock($4, $5) ? "true" : "false"
}
function clock(hours, minutes) {
    return ((hours * MinutesInHour + minutes) % MinutesInDay + MinutesInDay) % MinutesInDay
}
function printClock(minutes) {
    printf "%02d:%02d\n", int(minutes / MinutesInHour), minutes % MinutesInHour
}

@IsaacG, @kotp, @glennj - is it fine?

[glennj]

Hi folks. I like the command hh mm delta format. I'd suggest adding a detailed comment in the test script, just so that it's clear.

[rabestro]

Hi folks. I like the command hh mm delta format. I'd suggest adding a detailed comment in the test script, just so that it's clear.

I've changed the example solution and tests. For generating tests, I'm using a custom Gem (Gemini)

• Sample chat: https://gemini.google.com/share/99bfe9ac394a
• Custom Gem: https://gist.github.com/rabestro/091673e51f7f2f2a2a39f80c34868c9d