how to model this a better way

oke, and how must I see those classes and elemating the need for a lookup.

it may be explained in pseudo-code.

Roelof



Op 18-4-2019 om 20:28 schreef Richard Sargent:

On Thu, Apr 18, 2019 at 10:33 AM Roelof Wobben <[hidden email]> wrote:

oke

Maybe I understand something not right,

Lets say we have this scenario.

Robot is on position (0,0)
now it turns left so the robot faces East

I don't understand what position has to do with direction nor why that would be a problem. They are two distinct attributes.

Point and Dictionary are sufficient classes to model the limited requirements of this exercise.

You could model a new class DirectionVector which internalizes the Point used to provide the direction and provides its own name, eliminating the need for a look up of any kind.

or this scenario

Robot is on position (0,0)
now it turns right so the robot faces west.

it looks that dictionary cannot provide this answer.
or do I overlook something

Roelof



Op 18-4-2019 om 19:17 schreef Richard Sargent:

On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <[hidden email]> wrote:

yep, I have read that one
but I never gets a answer how I can "convert"  a point to something like north, east

because the challenge wants this to be the answer :

(Dictionary new
                add: 'direction' -> 'north';
                add:
                    'position'
                        ->
                            (Dictionary new
                                add: 'x' -> 0;
                                add: 'y' -> 0;
                                yourself);
                yourself)

If you have previously defined a "representation map", you would be golden.

e.g.

Dictionary new

at: self northDirectionVector put: 'north';

at: self eastDirectionVector put: 'east';

at: self southDirectionVector put: 'south';

at: self westDirectionVector put: 'west';

yourself.

Then:

(Dictionary new
                add: 'direction' -> (self directionRepresentationMap at: self directionVector);

...

and I think I need then to use if then , which I try to avoid as much as possible.

Roelof



Op 18-4-2019 om 18:33 schreef Richard Sargent:

On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <[hidden email]> wrote:

Hello,

I know I have asked earlier but im still stuck on this one : https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md

I tried with all double dispatch but that will be a lot of duplicate classes

The problem I cannot solve right is that a robot can move or turn. when a robot turns only the direction the robot is facing changes and the position not. when a robot moves the facing direction stays the same but the position changes. but the change is dependend on the facing. Also the new facing direction is dependend on the old facing direction/

How can I model this the best.

I already have a object Robot that contains the facing direction and the current position

or tried without it but then I use a lot of if then's


so it  there  a better way to model this problem so it will be all nice and readable code.

If I remember correctly, Richard O'Keefe gave you a viable design. 1) Use a Point for your direction vector. 2) Use a second Point for your position.

e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 is South, 1@0 is East, and -1@0 is West. When you move, you add the direction vector to your current position. If you allow movements of greater than a single unit, you multiply the direction vector by the distance before adding that product to the position.

Roelof

I can't escape the feeling that this answer is leaving a lot on the 
table because the question is asked from a narrow perspective.

On 4/18/19 10:01 , Roelof Wobben wrote:
 because the challenge wants this to be the answer :

 (Dictionary new
                 add: 'direction' -> 'north';
                 add:
                     'position'
                         ->
                             (Dictionary new
                                 add: 'x' -> 0;
                                 add: 'y' -> 0;
                                 yourself);
                 yourself)

You quickly find it’s a more interesting exercise than just a “point and dictionary”, particularly if you want to do it in an elegant Smalltalk way (but not over do it either).

The interesting bit is that when facing a new direction, you need to know how to advance in that direction , and also what “left” and “right” of that direction are too. So it teases out having some objects and techniques for this.

For those interested - join exercism-Pharo (https://exercism.io/tracks/pharo-smalltalk/installation) in non mentor mode and you can easily download it with the tests and try it out yourself (without running through the other exercises).

Tim

Sent from my iPhone

On 18 Apr 2019, at 21:41, Richard Sargent <[hidden email]> wrote:

Your system would have instance variables holding the cardinal directions and another holding the current direction vector.

e.g.

north := DirectionVector x: 0 y: 1 name: 'north'.

Your robot would implement e.g. #faceNorth to assign the "north" direction vector to the current direction vector instance variable.

On Thu, Apr 18, 2019 at 12:17 PM Roelof Wobben <[hidden email]> wrote:

oke, and how must I see those classes and elemating the need for a lookup.

it may be explained in pseudo-code.

Roelof



Op 18-4-2019 om 20:28 schreef Richard Sargent:

On Thu, Apr 18, 2019 at 10:33 AM Roelof Wobben <[hidden email]> wrote:

oke

Maybe I understand something not right,

Lets say we have this scenario.

Robot is on position (0,0)
now it turns left so the robot faces East

I don't understand what position has to do with direction nor why that would be a problem. They are two distinct attributes.

Point and Dictionary are sufficient classes to model the limited requirements of this exercise.

You could model a new class DirectionVector which internalizes the Point used to provide the direction and provides its own name, eliminating the need for a look up of any kind.

or this scenario

Robot is on position (0,0)
now it turns right so the robot faces west.

it looks that dictionary cannot provide this answer.
or do I overlook something

Roelof



Op 18-4-2019 om 19:17 schreef Richard Sargent:

On Thu, Apr 18, 2019 at 10:01 AM Roelof Wobben <[hidden email]> wrote:

yep, I have read that one
but I never gets a answer how I can "convert"  a point to something like north, east

because the challenge wants this to be the answer :

(Dictionary new
                add: 'direction' -> 'north';
                add:
                    'position'
                        ->
                            (Dictionary new
                                add: 'x' -> 0;
                                add: 'y' -> 0;
                                yourself);
                yourself)

If you have previously defined a "representation map", you would be golden.

e.g.

Dictionary new

at: self northDirectionVector put: 'north';

at: self eastDirectionVector put: 'east';

at: self southDirectionVector put: 'south';

at: self westDirectionVector put: 'west';

yourself.

Then:

(Dictionary new
                add: 'direction' -> (self directionRepresentationMap at: self directionVector);

...

and I think I need then to use if then , which I try to avoid as much as possible.

Roelof



Op 18-4-2019 om 18:33 schreef Richard Sargent:

On Thu, Apr 18, 2019 at 8:57 AM Roelof Wobben <[hidden email]> wrote:

Hello,

I know I have asked earlier but im still stuck on this one : https://github.com/exercism/problem-specifications/blob/master/exercises/robot-simulator/description.md

I tried with all double dispatch but that will be a lot of duplicate classes

The problem I cannot solve right is that a robot can move or turn. when a robot turns only the direction the robot is facing changes and the position not. when a robot moves the facing direction stays the same but the position changes. but the change is dependend on the facing. Also the new facing direction is dependend on the old facing direction/

How can I model this the best.

I already have a object Robot that contains the facing direction and the current position

or tried without it but then I use a lot of if then's


so it  there  a better way to model this problem so it will be all nice and readable code.

If I remember correctly, Richard O'Keefe gave you a viable design. 1) Use a Point for your direction vector. 2) Use a second Point for your position.

e.g. if you align the compass with a Cartesian plane, 0@1 is North, 0@-1 is South, 1@0 is East, and -1@0 is West. When you move, you add the direction vector to your current position. If you allow movements of greater than a single unit, you multiply the direction vector by the distance before adding that product to the position.

Roelof

On Mon, 22 Apr 2019 at 23:15, Richard O'Keefe <[hidden email]> wrote:
>
> I already discoursed on this at some length.
> (1) In my own answer, I used code to map direction names to vectors.
>     But the Dictionary answers are absolutely fine.
> (2) I pointed out that there are ALREADY "turn left" and "turn right"
>     operations on Points.
> (3) An elegant solution is one which wastes no effort.
>     Introducing classes that you don't need is definitely wasted
>     effort.

Elegance in art is in the eye of the beholder.  You've got one position on it.
I'll just balance it with an alternative view for students to consider
around "classes that you don't need".

> WARNING: untested first draft code (can't find the tested stuff).
>     obey: commands
>       |position direction|
>       position  := 0@0.
>       direction := 1@0.
>       commands do: [:each |
>         each caseOf: {
>           [$A] -> [position  := position  + direction].
>           [$L] -> [direction := direction leftRotated].
>           [$R] -> [direction := direction rightRotated]
>         }].
>       ^{position. direction}
> You will need to fiddle with this a bit to get the mapping between
> problem coordinates and solution coordinates right, and you'll
> need that Dictionary mapping directions to direction names, but
> that's pretty much it.

> If you define more than one class for this problem, your code is not elegant.

If the purpose of the problems is simply to solve the problem, then
doing the absolute minimum is a reasonable view of elegance.
After all, its throw away code.  You're never going to be maintaining it.

But if the purpose of problems is to lead students in new ways of
thinking about structuring OO solutions
for maintainability within Pharo, then I feel its lacking.  I remember
an instructor from my youth
advising that "practicing a kata poorly is the habit that will be
reproduced automatically (in a crisis)"

>       ^{position. direction}

For me, viewing   {2@3. 1@0 }  in a debugger is a much greater
cognitive load than {2@3.  'Facing east'}
to determine which direction its facing.  So I consider the latter
more elegant.  TDD helps minimise class over-engineering,
but for me the latter is a "need".  In terms of throw-away exercises,
its about what habits students want to gain from doing them.

Just another perspective.
cheers -ben