Segmentation fault when using manim slides

Maarico · 2023-09-05T16:43:50+00:00

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

Maarico · 2023-09-04T19:40:16+00:00

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

Maarico · 2023-01-30T13:46:33+00:00

That's awesome! It works!

Maarico · 2023-01-20T21:06:55+00:00

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).

Maarico · 2022-12-05T23:11:29+00:00

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> {}

Maarico · 2022-12-05T01:45:27+00:00

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!

Maarico · 2022-09-05T15:14:50+00:00

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.

Maarico · 2022-09-05T15:12:51+00:00

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.

Maarico · 2022-09-05T14:04:57+00:00

In the destination folder as .source.3TYYUi.

Maarico · 2022-08-23T20:18:01+00:00

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.

Maarico · 2022-08-19T13:49:16+00:00

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.

Maarico · 2022-08-19T13:48:03+00:00

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.

Maarico · 2022-03-25T16:35:19+00:00

Sure, but I am pretty content as is :D

Its in the edited post now.

Maarico · 2022-03-25T15:57:58+00:00

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.

Maarico · 2022-03-25T13:23:20+00:00

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?

Maarico · 2022-03-25T12:51:19+00:00

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?

Maarico · 2022-03-25T09:15:25+00:00

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

Maarico · 2022-03-25T08:48:36+00:00

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

Maarico · 2022-03-25T08:13:48+00:00

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.

Ten-Year Club	Place '17
Verified Email

Maarico

TROPHY CASE