.
#🔒 fastest way to list subtract?
fierce crane
fierce crane
hey, I want to take two lists with a small number of elements, they are position vectors, so 3. then subtract them element wise, what is the fastest way to do this? I dont want parallelization through something like numpy for lists of such small size, and list comprehension seems slow
fossil raven
are they very long lists? Like tens of thousands of elements?
if not, then just do it the dumb slow way; any extra speed from (say) parallelizing is probably not worth the added complexity
fierce crane
no, sorry I shouldve edited the dot to contain my message if you missed it
just 3 elements
fossil raven
two lists, 3 elements each?
how on Earth could that be slow?
that's three subtractions.
fierce crane
its not about it being slow I just want it to be as fast as possible
it has to iterate over each address
fossil raven
🤔
fierce crane
it could change depending on implementation
fossil raven
buy a faster computer? I completely don't understand what you're trying to do.
how long are these subtractions currently taking?
fierce crane
a couple hundred nanoseconds?
I have a solar system simulation :P
rewriting my old one rather*
and need as much performance without swapping to straight C as possible
map(operator.sub, a, b) gives a very good time
but the syntax is shocking
livid trellis
I know you said not Numpy, but...Numpy.
fierce crane
numpy is so bad for this 
livid trellis
Or something even GPU-calculated.
fierce crane
numpy takes around 8x longer
fossil raven
ah, you're doing it a zillion times. gotcha
fierce crane
for a 3 element array
livid trellis
Numba might help you squeeze out some speed.
nimble saffron
are you only dealing with two positions?
fierce crane
no. so I cant use caches they are generalised and its a n body integrator
from %timeit map(operator.sub, a, b), it gathers around 200 nanoseconds,
%timeit np.subtract(a,b) gives around 2.68 MICRO seconds
so I might just have to use the shit syntax, just thought id come by and see if anyone knew a nice method
livid trellis
Map is lazy.
nimble saffron
I mean. if you're only dealing with 3-length arrays... (a[0] - b[0], a[1] - b[1], a[2] - b[2])
livid trellis
np.subtract wouldn't be
fierce crane
I mean. if you're only dealing with 3-length arrays... `(a[0] - b[0], a[1] - b[1...
ill see what speed this gathers, its my current implementation right now
livid trellis
The map is faster because it's not actually doing the work.
fierce crane
element wise subtraction then ig
nimble saffron
are you comparing one position to a ton of other positions or anything like that? why is sticking to pure python so important
fierce crane
are you comparing one position to a ton of other positions or anything like that...
its for a university project and they want it in python so the demonstrators and lab heads are able to provide help, if I had it my way I would be using C
I can provide a demo of what its currently doing
livid trellis
!e py m = map(int, '123') print(m) # No work done yet, just the creation of the iterator for v in m: # One element of work done per iteration print(v)
acoustic egretBOT
!e ```py
m = map(int, '123')
print(m) # No work done yet, just the creation of ...
:white_check_mark: Your 3.12 eval job has completed with return code 0.
001 | <map object at 0x7f82ea75b6a0>
002 | 1
003 | 2
004 | 3
Hence, "lazy".
fierce crane
fierce crane
are you comparing one position to a ton of other positions or anything like that...
just for context
nimble saffron
dang looks cool
fierce crane
the ABSOLUTELY TERRIBLE source code is there https://github.com/ClarkieUK
its not long
livid trellis
from %timeit map(operator.sub, a, b), it gathers around 200 nanoseconds,
%time...
All this is timing is the creation of the iterator, not of the work done.
For map
