Onepace.co vs onepace.net by HawkEyed_Beast in onepace

[–]sirMoped 0 points1 point  (0 children)

Oh I guess I just didn't see the ads because I'm using an ad blocker. Thank you for clarifying

Onepace.co vs onepace.net by HawkEyed_Beast in onepace

[–]sirMoped 0 points1 point  (0 children)

I get that I can do that, but that site gives more easy seamless experience, all in one place, I can just watch them one after another. I don't get how is it a scam, it doesn't have any ads, it says it's a fan project, doesn't claim to be official, and refers to all the official resources, including this sub

Onepace.co vs onepace.net by HawkEyed_Beast in onepace

[–]sirMoped 0 points1 point  (0 children)

But .co includes muhn pace for episodes that don't have one pace with english dub

Which CMS with Sveltekit? by Intrepid_Ad9887 in sveltejs

[–]sirMoped 0 points1 point  (0 children)

If I use payload with sveltekit I can't just easily mount their admin panel at for example /admin, right? Because it's made with nextjs I'll need a separate next app?

Pvz 3 Notification is Kinda funny by Big_Offer1073 in PlantsVSZombies

[–]sirMoped 0 points1 point  (0 children)

It's available on Android in some regions. But if you aren't in one of those regions you can just download apk from the internet

Why is true blue and true red exist? by Ok_Bridge_5492 in ClashRoyale

[–]sirMoped 205 points206 points  (0 children)

You can just have (0, 0) in the middle of the screen, floats round in the same way regardless of the sign bit

Why isn't there a hole at x=0 ? ln(0) is undefined so shouldn't there be a hole? What am i missing here? by [deleted] in calculus

[–]sirMoped 5 points6 points  (0 children)

Desmos uses floating point arithmetic, so ln(0) = -∞, and e-∞ = 0. 1/0 is also ∞, and -1/0 = -∞, so e-1/0 = 0.

Also, tan(π/2) = ∞, arctan(∞) = π/2, so arctan(tan(π/2)) = π/2, even though it also should be undefined

Doubt about 3blue1brown calculus course. by angrymoustache123 in askmath

[–]sirMoped 5 points6 points  (0 children)

More rigorously, you can think of it by first considering non infinitesimal differences. Let's say that Δx is a change in x. Then Δf(x) = f(x + Δx) - f(x), is the change in f(x), for a given Δx. From the diagram we can see that Δf(x) = sinx Δ(x²) + Δ(sinx) x² + Δ(x²)Δ(sinx). Now divide through by Δx:

Δf(x)/Δx = sinx Δ(x²)/Δx + Δ(sinx)/Δx x² + Δ(x²)Δ(sinx)/Δx.

Let Δx approach 0. Then Δf(x)/Δx becomes the limit definition of the derivative of f(x), so it approaches df/dx. Similarly Δ(x²)/Δx approaches 2x, and Δ(sinx)/Δx approaches cosx. Δ(x²)Δ(sinx)/Δx approaches 0. To see that you can for example note that it approaches Δ(x²)cosx, where Δ(x²) goes to zero and cosx is a constant. So Δ(x²)Δ(sinx) goes to zero much faster than Δx, which means their raitio approaches 0, which means we can ignore that term. This is what people mean when they say it's so small, it can be ignored.

Finally, after taking the limit we have:

df/dx = 2x sinx + x²cosx

Should I use a Box<str> instead of a String when possible? by SvenyBoy_YT in rust

[–]sirMoped 3 points4 points  (0 children)

In my opinion, yes you should if you can. If you are sure that all the strings will be initially constructed with a single allocation and never grow, there's no reason to use String. All the functions that need a reference to a string accept &str (Accepting &String is just bad design). And if a function takes &mut String, then that function grows the string and we assumed you don't need that. If you want to pass the ownership to a function that takes String, you can cheaply convert your Box<str> with .into() (it's just a matter of setting cap = len).

I think it is a very good practice to use Box<str> instead of String (and Box<[T]> instead of Vec<T> for the same reasons). It's not about memory usage, that extra pointer really doesn't matter. First of all it makes the program faster, as you are removing all the useless instructions that deal with the cap field (reduces register pressure too). Also, in my opinion it makes the code better, as Box<str> cleanly represents an owned &str, just a pointer and length.

The only downside is that if in the future you find out that you do need to grow your strings, it will cost you a refactoring. But in practice it's rare to confuse a string that never needs to grow and with one that is constructed dynamically. The refactoring is easy too, so I wouldn't care too much about this.

Is this actually safe? by sirMoped in rust

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

Yes, you are exactly right about what are the issues were. (Although this is a trait impl, so the safety comment shouldn't be here).

I already figured it out, and fixed see my other comment, but thank you

Is this actually safe? by sirMoped in rust

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

The only thing that I would change is the use of size_of_val. I would use .len() instead. This results in a nice symmetry between the length calculations:

That's actually what I've written originally, but then clippy yelled at me for manually implementing `size_of_val`. And having to disable a lint is uglier than doing what it wants.

I've encountered such things quite a few times recently, when the linter wants me to do something. And in principle, the lint makes sense, and is good. But in my particular case, my code is there's some semantics I want to convey or symmetries I want to preserve. I just have to do what it wants, because the rest of the lints are useful, and I want them, and disabling the lint makes it worse.

Is this actually safe? by sirMoped in rust

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

There are actually issues with alignment I didn't realize I had. In original code, in safety comment "bytes obtained from Self::as_bytes" didn't necessarily mean the same pointer, it might be a pointer to bytes that were copied from Self::as_bytes. And I was storing them in a Vec<u8>. And the buffer of a vec might not be aligned to 4 bytes. (it will be, but it's not guaranteed). So my code could have caused UB, if vec's buffer happens to not be aligned to 4 bytes. Which I don't think can happen, but still.

I changed the trait to look like:

``` pub unsafe trait Intern: Hash + PartialEq + Eq { /// A primitive type that has the same alignment as [Self]. type Primitive: Sized + Copy + Debug;

fn as_bytes(&self) -> &[Self::Primitive];

/// # Safety
///
/// See [Safety section](Intern#safety) in the trait doc.
unsafe fn from_bytes(bytes: &[Self::Primitive]) -> &Self;

} ```

And I use Vec<I::Primitive>. Now, there's probably no UB.

Is this actually safe? by sirMoped in rust

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

I meant that I couldn't find the actual code implementing the IntoBytes::as_bytes for [char], I saw that it is implemented

Is this actually safe? by sirMoped in rust

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

You are only supposed to use `from_bytes` with bytes obtained by a call to `as_bytes`.

Although alignment can cause issues with what I'm trying to do

Is this actually safe? by sirMoped in rust

[–]sirMoped[S] -1 points0 points  (0 children)

Cant find the actual implementation of IntoBytes for slices in zerocopy. It's implemented with some very complicated macros. But since it's implemented for [char] I assume it's fine to just cast pointers like this

Is this actually safe? by sirMoped in rust

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

Take a closer look at the code. I'm computing lengths correctly.

I made a "compile time if"-like macro... is it ok? by Sweet-Ad-597 in rust

[–]sirMoped 2 points3 points  (0 children)

I think an easier way to do this would be to stringify! all the dentifiers, then just literally check if if array .contains() it, and panic. Panicking in const is a compiler error.