Retrieve matrix #28
Retrieve matrix #28
Conversation
According to my testing, it is not faster than just using dense matrices. That might be because our arrays are not huge O(5000x5000). In [22]: %timeit numpy.dot(spec * aarf.specresp, m) 100 loops, best of 3: 2.9 ms per loop In [21]: %timeit ms.dot(spec * aarf.specresp) The slowest run took 8.49 times longer than the fastest. This could mean that an intermediate result is being cached. 100 loops, best of 3: 3.12 ms per loop
|
Ooh, thanks for this! This is really helpful. Travis is currently failing to reasons not related to this PR, so I'll have to investigate what's going on there. Relatedly, do you think you might have a spare few minutes to come up with a couple of test cases to make sure this executes correctly? That would be awesome! |
|
Heh, I was afraid you would ask for that. How should I test the correctness? Would it be OK to compare apply_rmf against the dot product with the dense matrix, or is that too high-level? I saw in another PR that apply_rmf (times arf) might not correspond to proper fluxes at the moment, because some keywords (exposure time, scalings?) may be needed. Is that still true? |
|
Added a test case. I did not test the test yet, haven't downloaded git-lfs. |
|
Yeah, I think comparing to the I haven't looked at this package in quite a while, to be honest so the response to your second question is ... probably? I'll check either today or tomorrow and get back to you. |
|
git-lfs has been producing lots of hiccups recently; if it doesn't work, let me know and I might have to put the data elsewhere for easier download. |
|
Hi @dhuppenkothen, are you still considering merging this? |
Hi @dhuppenkothen,
thanks for this cool project!
I wanted to just get the RMF matrix values out.
In one commit I also played with using scipy.sparse to create sparse matrices, but I found that their .dot is not faster than just using the full matrix. So I removed the code again (in the second commit).
Cheers,
Johannes