How to gracefully get rid of the use of dictionaries?

[Shrinavat 17]

There is current code, in which I think the use of dictionaries is redundant:

const
  N = $1;
  S = $2;
  E = $4;
  W = $8;
  
var
  DX, DY, OPPOSITE: TDictionary<Integer, Integer>;

// init dictionares
  DX := TDictionary<Integer, Integer>.Create;
  DX.Add(E, 1);
  DX.Add(W, -1);
  DX.Add(N, 0);
  DX.Add(S, 0);
  DY := TDictionary<Integer, Integer>.Create;
  DY.Add(E, 0);
  DY.Add(W, 0);
  DY.Add(N, -1);
  DY.Add(S, 1);
  OPPOSITE := TDictionary<Integer, Integer>.Create;
  OPPOSITE.Add(E, W);
  OPPOSITE.Add(W, E);
  OPPOSITE.Add(N, S);
  OPPOSITE.Add(S, N);

// Usage of these dictionaries is shown below in the example code:
  var nx := x + DX[dir];  
  var ny := y + DY[dir];
  grid[ny, nx] := grid[ny, nx] or OPPOSITE[dir];

To improve performance, I would like to avoid using dictionaries and use a simpler code instead... but I don't know which one?

Any help in this arena would be greatly appreciated.

[Fr0sT.Brutal 900]

TDirection = (dirN, dirS, dirW, dirE)

TDirectionArr = array[TDirection] of ShortInt

[FPiette 385]

1 hour ago, Fr0sT.Brutal said:

TDirection = (dirN, dirS, dirW, dirE)

@Fr0sT.Brutal given the way he defined N, S, E, W (Power of two), it is likely meant to combine them (NE = N + E). It is better stay like it is, or replaced by an "set of". But of course we don't know how he makes use of those values so it is pure speculation...

[Shrinavat 17]

44 minutes ago, FPiette said:

given the way he defined N, S, E, W (Power of two), it is likely meant to combine them (NE = N + E).

You are correct. The code uses expressions like:

cx := E or W;

grid[ny, nx] := grid[ny, nx] or S;

[Fr0sT.Brutal 900]

2 hours ago, FPiette said:

given the way he defined N, S, E, W (Power of two), it is likely meant to combine them (NE = N + E)

TDirections = set of TDirection

?

 

note: I could miss some important detail here as it's monday and even coffee doesn't help much %-)

[David Heffernan 2353]

2 hours ago, Shrinavat said:

You are correct. The code uses expressions like:

cx := E or W;

grid[ny, nx] := grid[ny, nx] or S;

The code in the original post doesn't. Kinda makes a difference. Still, it's not an important difference as it happens. You have no real need for a hash table based loopup. An array is fine for lookup. You can then use sets additionally. 

[FPiette 385]

You didn't define the variable types, so I made some guessing and came with the following code:

type
  TDirection  = (dirE, dirW, dirN, dirS);
  TDirections = set of TDirection;

var
  DX       : array [TDirection] of Integer = (1, -1,  0, 0);
  DY       : array [TDirection] of Integer = (0,  0, -1, 1);
  Opposite : array [TDirection] of TDirection = (dirW, dirE, dirS, dirN);


procedure Demo;
var
  x, y, nx, ny : Integer;
  Dir          : TDirection;
  Grid         : array[0..100, 0..100] of TDirections;
begin
  x   := 3;
  y   := 5;
  Dir := dirN;
  nx  := x + DX[Dir];
  ny  := y + DY[Dir];

  Grid[nx, ny] := Grid[nx, ny] + [Opposite[Dir]];
end;

 

[Pat Foley 52]

Quote

You are correct. The code uses expressions like:

cx := E or W;

grid[ny, nx] := grid[ny, nx] or S;

You might consider white boarding or build simple model.  Consider N,S,E,W as UI.  Use a heading for instance.  So the instance turns left West or right East when heading North.  Heading South turning left means heading East on the UI.  Then the business of quarter turns could

be solved by quadants or (heading + 360 +/90) mod 360. 

 

Or

Quote

TDirection = (dirN, dirS, dirW, dirE)

given

 

TDirection = (dirN, dirE, dirS, dirW) // note changed

heading: TDirection;

Const

quarterTurn = 1

halfTurn = 2

 

//change direction by adding subtracting  the turn 

 Heading := TDirection((4 + ord(Heading) + quarterTurn)mod 4); 

 

[Shrinavat 17]

Thank you all, you put me on the right track!

[David Schwartz 430]

Code is supposed to reflect your design goals.

 

I get nervous whenever someone tries explaining their design with code.

I still don't know what you're trying to accomplish here other than change your code somehow.

 

Are you familiar with Einstein's famous quote: "You cannot solve a problem at the same level of logic used to create it"?

 

You showed us some code, assert there's a problem, then ask how to rewrite the code to solve this supposed problem without explaining a larger context. Several people made guesses based on assumptions they all had to make, but none of us really know for sure what the problem really is.

 

I mean ... I do not understand why the dictionaries are there in the first place either. 

 

Edited March 15, 2021 by David Schwartz

[Guest]

I think David bought the ticket, but he forgot the time for the movie ... The lights went on, and they all left!

 

Summary: The movie was good, the popcorn was delicious, however, those who arrived later did not know what it was about.

 

hug

Edited March 16, 2021 by Guest

[David Schwartz 430]

I saw where it ended up, although I didn't look all that closely at the details. Just chiming in with my thoughts about the use of TDictionary in the first place, AND the use of code to explain code.