Ad
  • Custom User Avatar

    Same here
    signature [1.8190803733637595, 10.32113085317588, 2.4538921407466985]
    It should work with random inputs too: arrays first differed at element [25]; expected:<9145259.517695228> but was:<9145259.51769523>

    signature [4.523989247754125, 4.4306407266327845, 2.9433070582317944]
    It should work with random inputs too: arrays first differed at element [21]; expected:<602130.3478075289> but was:<602130.3478075288>

    signature [1.218691787383328, 7.628302847784772, 14.623238617452863]
    It should work with random inputs too: arrays first differed at element [20]; expected:<778388.1052085671> but was:<778388.105208567>

  • Custom User Avatar

    Please, add random tests which check not some 10000000...-th element but a whole list generated by next()-ing though the whole matrix.

  • Default User Avatar

    Sure, I'm not saying the situation is ideal. ;)

  • Custom User Avatar

    Which is why I said the test code is not defensive.

    Also, what these global variables are named is an implementation detail, and the tests should not depend on us doing the same. It'd have been an issue if it was other things.

  • Custom User Avatar
  • Default User Avatar

    why there is a test on this

    Currently, there is no test specifically on that (I asked for it. The author didn't do it) but the values are overriden at the beginning of the test cases. So what you'r asking for is actually that a specific test was made, with an Test.expect(condition, message, allow_raise=True) so that the executions are stopped? honestly, as long as the code cannot pass with wrong values, the test suite being stopped or not, I don't see a difference. The only useful thing would be a meaningful error message about that.

    If I don't define the 4 directions, the test gives an error (bad)

    What do you expect exactly when you remove parts of the ocde...? ;p Yes, that would be better (actually, "cleaner") to stop the executions and so on. But again, the code won't pass through the tests...

  • Custom User Avatar

    Define a custom object that overrides the [] operator (assuming you already specified that's the way to do random access, which you should also put into the description):

    https://stackoverflow.com/questions/1957780/how-to-override-the-operator

  • Custom User Avatar

    But the thing is:

    • If I don't define the 4 directions, the test gives an error (bad)
    • If I define them but in wrong values, the tests gives a failed test and then proceed without problems, which begs the question of why there is a test on this if the whole test code doesn't depend on it?
  • Custom User Avatar

    I thought it's obvious that you can't iterate backwards if you dont have random access property or don't know length (or cant slice), and i think it's a spoiler (kind of), but i put in description, thank you.

    which is not an iterator but an range object

    I didnt say that Table.data is iterator. Iterator is what Table.walk() should return.

  • Custom User Avatar
  • Default User Avatar

    the wrapper problem doesn't apply anymore since the last changes of the runner, even without a wrapper function.

  • Custom User Avatar

    Laziness requirement is not tested on the y-dimension.

  • Custom User Avatar

    Python
    Iterator must be lazy.

    And yet your lazy test is

    [range(10,10+10**10),
     range(20,20+10**10),
     range(30,30+10**10),
     range(40,40+10**10)]
    

    , which is not an iterator but an range object. Iterator can be infinite and hence does not guarantee to have a last element (in fact iterators don't even have a length property), so iterating backwards is not a valid operation if you're requiring laziness and iterators.

    It means that your requirement is bogus and it should either be corrected or removed.

  • Custom User Avatar

    Python: There's no reason to check if the four direction global variables has to be specific values. And if not defining them breaks the tests, the tests not are defensive enough and it's bad. (It also means the tests is not wrapped in a closure, which brings other problems.)

    Please wrap the whole test code into a function, define the variables inside the function, then run it. Then it won't depend on the user defining the variables correctly.

  • Default User Avatar

    remove the seeding, with that, the random test aren't random anymore. ;)

  • Loading more items...