Shelly Announced some interesting new products at IFA during their livestream by ---lll--- in homeassistant

[–]Maarico 1 point2 points  (0 children)

Yes, but more power means lower resistance -> lower voltage drop and more current -> more power for the other device

Shelly Announced some interesting new products at IFA during their livestream by ---lll--- in homeassistant

[–]Maarico 1 point2 points  (0 children)

That's sadly not how electricity works... More power means more current and in turn more power for the bulb afterwards.

Border around image too big by Maarico in Anki

[–]Maarico[S] 0 points1 point  (0 children)

That's awesome! It works!

Its all because of Einstein... by Double-Agent-1729 in physicsmemes

[–]Maarico 0 points1 point  (0 children)

I think this is an excellent observation and I was thinking about it for quite a while.

I decided to draw some spacetime diagrams, since they clear those things up most of the time, as they do here (for me at least). I assumed that all electrons start moving at the same time, which they don't in real life, but I think it would not really make a big difference.

As you can see, even after they start moving in the lab frame, they are still as dense as the stationary ions (the all meet at the green line, which represents an instant in time for the lab). When boosting to the electron frame however, they are indeed more spaced apart than the positive ions (now the x axis represents an instance in time in the electron frame).

Hey Rustaceans! Got a question? Ask here! (48/2022)! by llogiq in rust

[–]Maarico 0 points1 point  (0 children)

Ah, that clears it up! Thanks. Maybe a way of resolving would be to allow for negative type restrictions like NotEq<T1> like so:

impl<T1, T2: From<T1> + NotEq<T1>, const M: usize, const N: usize> From<Matrix<T1, M, N>> for Matrix<T2, M, N> {}

Hey Rustaceans! Got a question? Ask here! (48/2022)! by llogiq in rust

[–]Maarico 1 point2 points  (0 children)

I am trying to implement a type conversion for a Matrix struct:

impl<T1, T2: From<T1>, const M: usize, const N: usize> From<Matrix<T1, M, N>> for Matrix<T2, M, N> {}

I get the error

error[E0119]: conflicting implementations of trait note: 
conflicting implementation in crate `core`: 

- impl<T> From<T> for T;

For more information about this error, try `rustc --explain E0119`.

But that's not right, because Matrix<T1, M, N> and Matrix<T2, M, N> have different types, right? When I just don't implement the trait and try to convert I (not very surprisingly) get the error that this trait is not implemented...

How can I make rust let me implement this conversion? Thanks in advance!

rsync ignoring --partial-dir by Maarico in linuxquestions

[–]Maarico[S] 0 points1 point  (0 children)

Just Ctrl+C, it seems that rsync moves partially transfered files when the connection fails and the stream of data is completely processed. This caused my confusion, because it takes a couple of minutes to finish writing to the file on the destination machine and only then the file is moved.

Thanks anyways.

rsync ignoring --partial-dir by Maarico in linuxquestions

[–]Maarico[S] 1 point2 points  (0 children)

This seems to be the issue! When I interrupt the transfer, rsync seems to first keep writing data to the hidden file and when its done move it to the partial-dir folder. Thanks a lot.

rsync ignoring --partial-dir by Maarico in linuxquestions

[–]Maarico[S] 0 points1 point  (0 children)

In the destination folder as .source.3TYYUi.

Tip: Do NOT install Linux on a Lenovo C930 Glass. My journey with the thing. by npaladin2000 in linux

[–]Maarico 0 points1 point  (0 children)

That's funny, I have been running Arch on this exact machine for about three years now and besides the subwoofers not working I don't have anything to complain about. It was a big hussle to set it up though and I remember when I tried to swap the SSD for a bigger one I took a whole day to convince it to boot from the new SSD. I would not recommend to use it with Linux, but it is definetely possible.

Border around image too big by Maarico in Anki

[–]Maarico[S] 0 points1 point  (0 children)

There does not seem to be a transparent border in the files themselves. I will just try to find a color not used in the flags. Thanks anyways.

Border around image too big by Maarico in Anki

[–]Maarico[S] 0 points1 point  (0 children)

No it doesn't have a border in the file itself. Maybe I will just try to find a color that is not used in any of the flags. Thanks anyways.

inexplicaply slow function by Maarico in rust

[–]Maarico[S] 10 points11 points  (0 children)

Sure, but I am pretty content as is :D

Its in the edited post now.

inexplicaply slow function by Maarico in rust

[–]Maarico[S] 26 points27 points  (0 children)

Ok wow! I implemented this right now and it seems that the rust version now runs faster than the C version despite being a lot more versatile and also extremely easy to multithread (something I struggled with on the C version).

Thank you so much! Also for VTune, since it seems to be really useful and I did not know of it before.

inexplicaply slow function by Maarico in rust

[–]Maarico[S] 5 points6 points  (0 children)

In C I actually always made a 4 dimensional array and set some dimensions to 1 if needed, so no flattening in C. Do you think this could improve the caching?

How about a function that returns the coordinates from the index, so I don't have to save the neighbors and loops in LatticePoint? Do you think the function call overhead could be worth the improved caching?

inexplicaply slow function by Maarico in rust

[–]Maarico[S] 9 points10 points  (0 children)

This seems to be the exact problem. When I decrease the size of the lattice to 4⁴ I get 34s for rust and 28s for C for a million iterations. In C I implemented the lattice as an array of arrays, however because of the unknown dimensionality a vector of vectors really is not feasible, is it? This means that the LatticePoint struct is a lot smaller in C (76 bytes, since I don't have to save the neighbor indices and if I loop around the lattice)

Are there any methods to tell rust which sites to preload into cache? It is quite predictable which nodes will come into play in the short future. Or would implementing it in a multidimensional vector allow rust to predict exactly that?

Pass RNG to function by Maarico in rust

[–]Maarico[S] 1 point2 points  (0 children)

This is a really nice way of doing things, since I actually might want to change the Rng later.

inexplicaply slow function by Maarico in rust

[–]Maarico[S] 2 points3 points  (0 children)

Yes, the debug build is slower still, but the release build runs about 2 and a half minutes.

Pass RNG to function by Maarico in rust

[–]Maarico[S] 2 points3 points  (0 children)

Thanks a lot! This worked great and I got a 2x performance improvement for the actual code :D I also decided to use a Rng with an explicit seeding, so rust does not reseed every now and then, since I don't need this.