bitset | Go package implementing bitsets

I doubt this would be documented. It certainly won't be 'fixed', as there is no sensible fix available that doesn't break backwards compatibility, and it is nowhere near relevant enough to take such drastic steps.

Whilst the API docs make no such guarantee, the effect of size() is that it simply returns the nBits value you passed when you constructed the BitSet instance... but rounded up to the next value that is evenly divisible by 64:

The documentation you've cited is correct.

certainty - a measure of the uncertainty that the caller is willing to tolerate: if the call returns true the probability that this BigInteger is prime exceeds (1 - 1/2^certainty)

99.9% indeed exceeds 1 - 1/(2²) = 3/4, so there's nothing wrong with what you've shown us.

The implementation makes no guarantees that that's exactly the probability, it just provides an implementation whose error is definitely bounded by that certainty.

Most quality primality testers will have lots of optimizations for small primes, or rather, numbers whose divisors are small composite numbers. These likely kick in before the random aspects of the algorithm, resulting in higher-than-usual accuracy for small primes.

The synopsis for std::bitset is as follows. The rest are implementation details that are irrelevant may change, and should not affect well-formed code.

NVCC does not currently support C++20. In fact, the C++17 support is quite new (November 2020; see the NVCC versions). You can find more information here and there. Using Clang instead may help you to (partially) use C++20.

Interesting question.

The reaon, why this happens is that the std::bitsethas already an overwritten extraction operator >>. Please see here. You can read that this behaves like a formatted input function. So, it will read until the next white space and then stop. It will end reading, if we have an "end of file" or until it hits the length of the defined std::bitset.

Accidently you have spaces in your source file, which will act as separator for this formatted input function, and will not lead to any problem.

Actually, you should see a lot of "bitsets" in your std::vector, all consisting of many leading '0'es at the beginning and a few '1's with different length at the end.

That is the result of reading many '1' islands and padding the string on the left with '0's, so that the final bitset has 40 characters.

If you want C++ to call your function, you would need to open the std-namespace. While it could be done, this is strongly discouraged, except for template specializations. See:

NOT recommended:

There is a method for getting the next unset bit at or after a given index: BitSet.nextClearBit(int).

There is a complementary method, nextSetBit(int), for finding the next set bit.

So, you can find the start of a range with the former, and the end of the range with the latter.

You need to handle the return values of the methods carefully:

• If nextSetBit returns -1, that means that the current run of clear bits extends to the end of the BitSet.
• nextClearBit doesn't return -1, because BitSets don't have a clearly-defined size in terms of the number of clear bits - they essentially extend infinitely, but only actually allocate storage to hold set bits. So, if nextClearBit returns a value beyond the logical size of the BitSet (i.e. an index for a 15-minute slot beyond the end of the day/date range), you know that you can stop searching.

Apparently neither of those classes define the layout. Just write your own class and define the layout you want:

How to reduce the float rounding error when converting it into fixed-point in C++?

Rearrange the calculation of the fixed-point encoding to round the result to an integer and so that all arithmetic in it is performed exactly until a single division just before the rounding, as with mybits = bitset<16>(std::round((x*10 + i)*32/10));. This will produce correct results until something beyond i = 317,169. (Remove x += 0.1; from the loop; x is used as an unchanging value in this new formula.)

The problem stems from the fact that .1 is not representable in a binary-based floating-point format, so the source text 0.1 is converted to 0.1000000000000000055511151231257827021181583404541015625 (when IEEE-754 “double precision” is used for double), and each addition of that to x (in x += 0.1;) performs an operation that rounds the ideal real-arithmetic sum to the nearest value representable in double, and, since x is float, rounds that again to the nearest value representable in float (typically the IEEE-754 “single precision” format).

The desired value for the fixed-point number in iteration i is 1051 + i/10, converted to a fixed-point encoding with five fraction bits. The encoding of this is (1051 + i/10) • 32 rounded to the nearest integer. So the value we want to compute is round((1051 + i/10) • 32), where “round” is the desired round-to-integer function (such as round-to-nearest-ties-to-even, or round-to-nearest-ties-to-away).

We can write this as a fraction as ((1051•10 + i)•32) / 10. The advantage of this is that (1051•10 + i)•32 is an integer and can be calculated exactly, with either integer or floating-point arithmetic, as long as it stays within the bounds of exact arithmetic. (For the “single precision” format, this means (1051•10 + i)•32 ≤ 2²⁴, so i ≤ 2¹⁹−10,510 =  513,778.)

Then the only unwanted rounding is in the division. That division occurs immediately before the desired rounding to an integer, so it is not exacerbated by any other operations. So we can compute the fixed-point encoding as std::round((x*10 + i)*32/10) and only be concerned with the rounding error in the division by ten. (To use std::round, include . Note that std::round rounds halfway cases away from zero. To use the current floating-point rounding mode, usually round-to-nearest-ties-to-even by default, use std::nearbyint.)

A rounding in the division will cause an error in the final result only if it causes a value of (x•10 + i)*32/10 whose fraction portion is not exactly ½ to become a value with a fraction of exactly ½. (The converse, causing a value with a fraction of ½ to become a value with some other fraction does not occur because a value with a fraction of ½ is exactly representable in binary floating-point, so no rounding occurs. An exception would be if the number were so large it would be beyond the point where any fractions are representable. However, this does not occur for the IEEE-754 “single precision” format unless the value is also overflowing the Q10.5 format.)

Assuming round-to-nearest is in use, any computed result is at most ½ ULP from the real-arithmetic result. (“ULP” stands for “Unit of Least Precision,” the effective position value of the lowest bit in the significand given the exponent scaling.) Therefore, (x•10 + i)*32/10 can round to a value with fraction ½ only if its fraction portion is at most ½ ULP from that value. The nearest the fraction portion of any such quotient can be to ½ without being ½ is 4/10 or 6/10. The distance of these from ½ is 1/10. So as long as 1/10 exceeds ½ ULP, std::round((x*10 + i)*32/10) produces the desired result.

For numbers in [2¹⁹, 2²⁰), the ULP of the “single precision” format is 2⁻⁴ = 1/16, which is less than 1/10. Therefore, considering only non-negative i, as long as (x*10 + i)*32/10 < 2²⁰, the result is correct. For x = 1051, this gives us (1051•10 + i)•32/10 < 2²⁰ ⇒ i < 317,170.

Thus we can use mybits = bitset<16>(std::round((x*10 + i)*32/10)); up until i = 317,169, at least.

This is not how switching over types work. You can switch over an object’s actual type and have to specify type names, rather than Class literals.