akubera

As others have said, Rust's ownership model prevents data races, as it can prove that references to mutable data can only be created if there are no other references to that data. Safe Rust also prevents use-after-free, double-free, and use-uninitialized errors. Does not prevent memory leaks or deadlocks.

It's easy to write code that deadlocks; make two shared pointers to the same mutex, then lock them both. This compiles without warnings:

    let mutex_a = Arc::new(Mutex::new(0_u32));
    let mutex_b = mutex_a.clone();
    
    let a = mutex_a.lock().unwrap();
    let b = mutex_b.lock().unwrap();
    println!("{}", *a + *b);

In terms of the math: the table legs are assumed to be equal length, and the wobble is caused by variations of the surface. Specifically the feet of the table are in the same plane. So you could rotate your mathematical table until all feet are secure on the plane, then cut the legs to make the top flat again (legs will not be same length, but top and bottom remain planes).

As for @Cerium's real-life usage, you have possibility of uneven legs and uneven floor (and discontinuities, like a raised floorboard) so it's obviously not guaranteed, but if the floor is warped and smooth enough, you can try.

[EDIT]: Changed wording

Looks good. One note about the video: you mention you recently watched a good video on 1-bit sound, and suggest it's worth a watch, but it doesn't appear to be linked-to in the description.

That seems to be the sentiment here. I'll take it into consideration. Thanks.

For the Rust crate, there is already an arbitrary limit (defaults to 100 digits) for "unbounded operations" like square_root, inverting, division. That's a compile time constant. And there's a Context object for runtime-configuration you can set with a precision (stop after `prec` digits).

But for addition, the idea is to give the complete number if you do `a + b`, otherwise you could use the context to keep the numbers within your `ctx.add(a, b)`. But after the discussions here, maybe this is too unsafe... and it should use the default precision (or a slightly larger one) in the name of safety? With a compile time flag to disable it? hmm...

I think that's the use-case for the rust_decimal crate, which is a 96-bit floating number (~28 decimal digits) which is safer and faster than the bigdecimal crate (which at its heart is a Vec<u64>, unbounded, and geared more for things like calculating sqrt(2) to 10000 places, that kind of thing). Still, people are using it for serialization, and I try to oblige.

Having user-set generic limits would be cool, and something I considered when const generics came out, but there's a lot more work to do on the basics, and I'm worried about making the interface too complicated. (And I don't want to reimplement everything.) D

I also would like a customizable parser struct, with things like localization, allowing grouping-delimiters and such (1_000_000 or 1'000'000 or 10,00,000). That could also return some kind of OutOfRange parsing error to disallow "suspicious" values, out of range. I'm not sure how that to make that generic with the serde parser, but I may some safe limits to the auto serialization code.

Especially with JSON, I'd expect there's only two kinds of numbers: normal "human" numbers, and exploit attempts.

This isn't about parsing so much as letting the users do "dangerous" math operations. The obvious one is diving by zero, but when the library offers arbitrary precision, addition becomes dangerous with regard to allocating all the digits between a small and large value

  1e10 + 1e-10 = 10000000000.0000000001
  1e10000000000000000000 + 1e-10000000000000000000 = ...

It's tough to know where to draw the lines between "safety", "speed", and "functionality" for the user.

[EDIT]: Oh I see, fix the parser to disallow such large numbers from entering the system in the first place, then you don't have to worry about adding them together. Yeah that could be a good first step towards safety. Though, I don't know how to parametrize the serde call.

I was attempting to solve this very problem in the Rust BigDecimal crate this weekend. Is it better to just let it crash with an out of memory error, or have a compile-time constant limit (I was thinking ~8 billion digits) and panic if any operation would exceed that limit with a more specific error-message (does that mean it's no longer arbitrary-precision?). Or keep some kind of overflow-state/nan, but then the complexity is shifted into checking for NaNs, which I've been trying to avoid.

Sounds like Haskell made the right call: put warnings in the docs and steer the user in the right direction. Keeps implementation simple and users in control.

To the point of the article, serde_json support is improving in the next version of BigDecimal, so you'll be able to decorate your BigDecimal fields and it'll parse numeric fields from the JSON source, rather than json -> f64 -> BigDecimal.

    #[derive(Serialize, Deserialize)]
    pub struct MyStruct {
      #[serde(with = "bigdecimal::serde::json_num")]
      value: BigDecimal,
    }

Whether or not this is a good idea is debatable[^], but it's certainly something people have been asking for.

[^] Is every part of your system, or your users' systems, going to parse with full precision?

I'd bet they have very similar performance-metrics, but the yield syntax is more extensible (i.e. you're not limited to one expression) and debug-able (you can put breakpoints within the function).

Also the name and the generator is nicer (for some definition of nice):

   >>> def square_vals(x : list):
   ...    return (v * v for v in x)
   ... 
   >>> square_vals([1,2,3])
   <generator object square_vals.<locals>.<genexpr> at 0x786b8511f5e0>

   >>> def square_vals_yields(x: list):
   ...     for v in x:
   ...         yield v * v
   ... 
   >>> square_vals_yields([1,2,3])
   <generator object square_vals_yields at 0x786b851f5ff0>

I think it's more idiomatic to pass generator-comprehensions into functions rather than return them from functions

    >>> sum((v*v for v in x))