Jump to content
Shrinavat

How to gracefully get rid of the use of dictionaries?

Recommended Posts

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.

Share this post


Link to post

TDirection = (dirN, dirS, dirW, dirE)

TDirectionArr = array[TDirection] of ShortInt

  • Thanks 1

Share this post


Link to post
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...

Share this post


Link to post
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;

Share this post


Link to post
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 %-)

Share this post


Link to post
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. 

  • Thanks 1

Share this post


Link to post

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;

 

  • Like 1
  • Thanks 1

Share this post


Link to post
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); 

 

  • Thanks 1

Share this post


Link to post
Posted (edited)

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 by David Schwartz
  • Like 1

Share this post


Link to post
Guest
Posted (edited)

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 by Guest

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×