To summarise the situation with your data:-
1) You came up with an algorithm on paper/Matlab/whatever.
2) You implemented that algorithm in some programming language.
3) You built a set of test data to exercise your algorithm, and came up with some results for what it should do in theory.
4) You put that test data through the code and came out with some results for what it does in practise.
In this process there are various places where things can go wrong with your methodology. Your code may not correctly reflect your algorithm. Your test data may have been worked backwards from the code instead of forwards from the algorithm. Your test data for your algorithm and your test data for your code may not be the same.
Unless the reviewer has the algorithm and the source code and all the test data for both and all the output data for both, they cannot verify that your work is sound and your conclusions are valid. This is not subject to dispute - it is logically impossible, if they want to properly review your work. Anything else is making assumptions which may not be valid.
I have personally been affected by this situation, when my company bought some control theory IP from a researcher. He'd written papers on how this was supposed to work and the theory behind it, and then he'd built some electronics to implement his theory. His papers covered the theory, and also included schematics for the electronics. When I read this to work out how to implement his theory in software, I found that the schematic had an extra filter in it. The action of this filter turned out to be critical to the system being stable or even effective, but it was not documented at any point anywhere in his work. It wasn't until we had a phone call with him that we found out what the purpose of the filter was, and how we were supposed to tune it.
This was in a paper which theoretically had been peer reviewed when it was published. Clearly it hadn't been peer reviewed thoroughly enough! His results showed that given the same data, the implementation output was pretty close to the theoretical expected output, and the effect of the filter was at a different place in the response. Still though, the implementation flatly would never have worked without this filter present, and it wouldn't have been at all hard to include this in the theoretical model. He could even have said "this filter is required for these reasons, but can be ignored in this area of the response we're looking at for these reasons" and he would have been covered. What is not acceptable is what he did, which is to fail to mention it at all, because the end result of that is that someone trying to implement his work would be unable to.
Like I said, he still got his paper published, and no-one complained at the time. It should have been spotted by his original reviewers though. In your case, your reviewer should be looking for discrepancies like this - it's the whole point of peer review. So if people are asking you for things you haven't made available, (a) it's a good sign they're checking thoroughly, and (b) you should have made it available in the first place as best practise.