• You should never check for cycle in (1), as you are at best removing dependencies from the graph.
• Instead of keeping track of current dependencies and formula in (2) and rolling back to it when a cycle is found, another option is to verify for a pending cyclic graph upfront.

The description states formulas need to be calculated on 'write', not on 'read'. Yet, solutions that calculate on 'read' pass this kata. This means the formulas are pure, and laziness, or deferring the calculation to the 'read' function instead of 'write', is allowed. This behavior should have been in the description all along, but it isn't :/

Very cool kata and on a very important topic, a shame that not more people have attempted it; probably too busy trying to import NumPy - sad!

Test suite has been updated by dolamroth on 2021-09-29 14:55:45 UTC

For those who struggle with this Kata.

RULES OF RETAINING AND UPDATING CELLS:

1. write(name, value)

• update the value at the given cell;
• check if there is a cycle in a graph (find out if there is a cell that depends recursively on itself);
• if there is NO cycle - proceed with updating the graph;
• if the cycle was detected - do not update anything except the value that was already updated
  IMPORTANT - do NOT rollback this change (for the same mysterious reason) and you'll be fine))

2. write(name, dependencies, formula)

• save dependencies and formula for a given cell that were previously assigned to it;
• apply new dependencies and formula;
• check if there is a cycle in the graph;
• if there is NO cycle - proceed with updating the graph;
• if there is one - ROLLBACK the changes, restore previous dependencies and formula,
  no values have to be updated in this case.

First of all, I wish to express my gratitude for a really interesting kata that targets basic graph algorithms.

There are some issues I want to point out:

1. Description has to be improved:

• it's unclear what are the rules of retention and updating (I'll provide more elaborate comments regarding this subject below);
• the following sentences doesn't look meaningful:
  'A sheet has an infinite number of cells. The default value of any cell is the number 0'
  I've no idea what means 'an infinite number of cells'..
  Now mysterious zero. Provided boiler-plate code and description forces the value of a cell to be of Object type (and that doesn't seem to be an idea by itself).
  And it's impossible to assign 0 to an instance of the Object type. I suggest rephrase it roughly as follows: 'if a cell with a given name wasn't previously initialized, using method write, it has to be given a value of Integer.valueOf(0)'.

2. Functions in this kata violate good code practices.

• Function<Object[], Object> - I do not suggest to use generics in the wild like this. Because using Object as a generic type is as good as don't use generics at all.
• And I hope no one will argue that blind castings from Object to Integer contradict the concept of type safety and must be avoided.
  I understand that the reason for this decision - desire to make it possible to store any kind of data in a cell. But this requirement has nothing to do with the data structures and algorithms and it pollutes the programing model. So in my opinion, it'll be much better to stick with int as value-type for this task. It'll not change the actual algorithm but the code will be more readable.

fractions removed from list

Accepting floating point numbers now.

Python translation:

Preloaded tests are passed but when running random tests:

Return value of solve_sequence must be a callable with 1 argument, that returns int

I'm returning valid solution but it is rejected:

def solve_sequence(seq):
  ...

  def f(r):
    y = 0
    ...
    return y
  return f

It's common in JavaScript to check for argument === undefined to see if an argument exists

That's just plain wrong. There is a fundamental difference between passing in undefined and not doing so, because arguments.length would be different. There are lots of libraries that does this.

except if you use the the arguments object which is not commonly used

[CITATION NEEDED]

And anyways, it's also inconsistent with the sample tests.

It's common in JavaScript to check for argument === undefined to see if an argument exists,
so I thought there is no difference between sending undefined and not sending anything,
except if you use the the arguments object which is not commonly used

write(name, value) is called in actual test as write(name, value, undefined) instead, which violates the description the it is called with two arguments only.

In fact, the description just overloads write with two different functions without specifying how to distinguish between the two. Is it the type of the second argument? Then it should be clearly specified. Otherwise it's pure guesswork.

The fixed tests are poorly written: It is written in a way that makes all subsequent test blocks depend on the previous blocks leaving the user object in a correct state. The test blocks should not be highly coupled to each other, as each block should be testing individual things.

The purity and laziness characteristics of formula is unspecified. Is formula guaranteed to be pure (passing the same values always returns the same value)? When should it be calculated, and which cells should be recalculated?

Recalculation can be performance heavy, and the use of impure functions like RAND are quite common in spreadsheet usage, so depending on the requirement the cells can end up with different values.