aaronkutch / awint Goto Github PK

current development is on the stage18 branch

After seeing https://thunderseethe.dev/posts/row-types/ I wonder if we want to name it "injection", in contrast to "concatenation". We will have short literal matching, but definitely want some kind of ability to define sum types. We may also want to create product types and retroactively do something with the concatenation macros.

This is an issue that I unfortunately cannot reasonably fix at the moment. The problem is that they entirely removed const from a bunch of core APIs (rust-lang/rust#110395). They plan to soon bring another implementation online and reimplement const. In the meantime, if you need const_support, you will need to pin to 1.70-nightly (e.x. use rustup install nightly-2023-04-14 and cargo +nightly-2023-04-14.

here's what I have now:

use awint::{cc, inlawi, inlawi_ty, Bits, InlAwi};

let mut Gx: inlawi_ty!(512) = inlawi!(0i128, 0i128, 0111100110111110011001100111111011111001110111001011101110101100010101011010000001100010100101011100111010000111000010110000011100000010100110111111110011011011001011011100111000101000110110010101100111110010100000010101101100010110111110000001011110011000);
let mut pad: inlawi_ty!(512) = InlAwi::zero();
println!("{:x}", Gx);

let minus_1: inlawi_ty!(512) = inlawi!(0i128, 0i128, 0i128, -1i128);
println!("{:x}", minus_1);

Gx.mul_assign(&minus_1, &mut pad);
println!("{:x}", Gx);

output:

0x79be667e_f9dcbbac_55a06295_ce870b07_029bfcdb_2dce28d9_59f2815b_16f81798_u512
0xffffffff_ffffffff_ffffffff_ffffffff_u512
0x79be667e_f9dcbbac_55a06295_ce870b06_88dd965c_33f16d2d_04521ec5_48710c90_fd640324_d231d726_a60d7ea4_e907e868_u512

but here's what I'm getting from python:

hex((0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 * -1) & (2**512-1))
'0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8641998106234453aa5f9d6a3178f4f8fd640324d231d726a60d7ea4e907e868'

current work is on the stage9 branch

work is currently on the stage10 branch

For the smallvec analogue of arbitrary width integers, I realized that we should probably handle Ext/Int multiplexing and unused capacity in the same type since we are already taking some branching hits, and expandable bigint functionality can be added on through this: &Self functions

new developments are on the stage13 branch

Current Development is on the stage16 branch

Current development is on the stage17 branch

current work is on the stage11 branch

development is currently on the stage15 branch

There are a bunch of TODOs that can be replaced with replace or get

I initially designed ExtAwi, InlAwi, and Bits back before certain pointer related things were const, and after seeing https://crates.io/crates/thin-vec I realized that maybe I can in fact eliminate LEN or at least the unnecessary extra usize from all the types without needing custom DST support. I may even want to pursue storing bitwidth externally with bit storage like thin-vec since a lot more of these types tend to be used at the same time in a function vs the typical cases for Vec. This time around, we have the bitwidth as a header instead of a janky trailer, which should cancel out some extra ops incurred.

Current development is on the stage14 branch

I think it should be possible to have a function with the signature arb_urem_(duo: &mut Self, div: &Self, pad: &mut Self) -> Option<()>, the way it works in the general case is copying duo to pad, performing digit_udivide_inplace_ with it and the most significant digit bits of div plus 1, then using pad again as a temporary in a subtract-multiply step against duo, then repeating the whole process in a loop. There are probably edge cases when it gets close to the end, or maybe we can simply dd_divide that stuff.

current work is on the stage12 branch