You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Big numbers are often stored in some data structure such as values of a BTreeMap. When I want to do some local change on the data structure, I usually get a &mut of the number. In this case, if I'm taking a neg(), a clone() of the number is needed, which is inefficient since it's essentially only a flip of sign. Similar for recip().
A new function like
fnset_neg(&mutself){self.sign = -self.sign;}
may be helpful. In fact, I even think it should be a method of the Neg trait.
If this is for a type that you control, you can certain add such a method directly. The num traits are mostly for generics where you don't know or control the particular numeric type.
Even for generics, you can already write something like this:
This assumes that zero is cheap to create and drop, but that's usually true.
In fact, I even think it should be a method of the Neg trait.
That would have to be a proposal for the standard library. When extending an existing trait, we also need a default implementation, and in that context I'd probably write it similar to what I wrote above, but add where Self: Default to the method and use mem::take instead of Zero.
Activity
cuviper commentedon Sep 6, 2024
If this is for a type that you control, you can certain add such a method directly. The
num
traits are mostly for generics where you don't know or control the particular numeric type.Even for generics, you can already write something like this:
This assumes that
zero
is cheap to create and drop, but that's usually true.That would have to be a proposal for the standard library. When extending an existing trait, we also need a default implementation, and in that context I'd probably write it similar to what I wrote above, but add
where Self: Default
to the method and usemem::take
instead ofZero
.