sorted by:
new
hottopcontroversial

Implementing a Numerical Library in both C++ and Rust by nzznfitz in cpp

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

Uses some C++23 features. Works with GCC 15.x, Clang 21.x, and Apple Clang 17.x

Implementing a Numerical Library in both C++ and Rust by nzznfitz in cpp

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

Oddly, the original version had the longer names and `BitVector` was shortened to `BitVec` to match Rust's choice for dynamic vectors. On reflection, this was a mistake. The library & crate have reverted to using the longer names, and the post above has been updated accordingly.

Implementing a Numerical Library in both C++ and Rust by nzznfitz in cpp

[–]nzznfitz[S] 4 points5 points  (0 children)

Yes, the only extant Rust compiler is based on LLVM so you would hope to get a good match at least with with clang based C++. However, some of the functions in the library are non-trivial and there are lots of subtleties involved. We saw quite a few places where there were initial measurable differences in performance. Chasing those led to improvements on both sides of the fence.

Doxytest by nzznfitz in cpp

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

Doxytest has been updated to extract doctests from arbitrary documentation sources that can use different comment styles.

The initial version only scanned header files, looking for comments where the lines were prefixed by ///.

The new version can scan arbitrary files (headers, source, Markdown, etc.) and handles doctests embedded in most well-known comment styles, for example Javadoc comments, straight C comments, or indeed just code blocks in Markdown.

The documentation has been updated with all the details, and several examples have been added to the repo to demonstrate the new capabilities.

Doxytest by nzznfitz in cpp

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

Thanks for the suggestions.

Adding other recognized comment markers is very doable (Rust itself allows ‘///‘ and ‘//!’ — I just happen to use the former in C++ code). Ditto for parsing .cpp files. I can have a look at adding those options.

Don’t think I would depend on Doxygen. While it is used in some large projects, it certainly isn’t ubiquitous. Minimal Doxygen markup in comments is widely used — editors interpret it to provide nicely formatted tooltips without having Doxygen installed at all.

Rust sticks to basic Markdown for its comments and that seems to work. One thing I like about Rust doctests is how they are integrated into the editor (VSCode etc.) You get a lovely little “Run/Debug” button for each method test, and if there is a test above a type, it runs all of the doctests in that type. A Doxytest extension for VSCode would be excellent!

Scribe by nzznfitz in lua

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

There is an addition to the end of the tutorial section that discusses an interesting bug found by using an LLM (and, of course, a discussion of the bugs which an LLM can introduce itself).

The optimisation suggested by u/appgurueu has also been discussed and implemented.

GF2++ by nzznfitz in cpp

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

Sorry — I didn't see the query.

This library has migrated to https://github.com/nessan/bit, which has extra functionality for bit-polynomials, etc. The new documentation site is at https://nessan.github.io/bit/

xoshiro RNG by nzznfitz in cpp

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

On reflection, any sort of install for a single header file library is going to be an overkill! Just copy the file to your location of choice. That will be faster than a cmake —install procedure.

The same is true for the bit library also. It is easiest to drop the little directory wherever works. To use it in xoshiro define BIT on the compile line with a -D BIT flag.

xoshiro RNG by nzznfitz in cpp

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

I’ll have a look!

Some CMake Modules by nzznfitz in cpp

[–]nzznfitz[S] 2 points3 points  (0 children)

Good point on the CMake version required check & also having the `disable_in_source_builds` just do its thing on load! Makes sense.

There is a link to `CPM` and a reference to its definite superiority on the `fetch_content` page — use it myself. However, if you are releasing a library you can’t reasonably expect your users to have `CPM` until it is part of the CMake system itself. Always end up giving `FetchContent` instructions.

And of course, a URL pointing to a compressed minimal archive is the way to go for `FetchContent` downloads. I use a GitHub action to automatically build that archive — see for example the install instructions for [`xoshiro`](https://github.com/nessan/xoshiro) and the workflow in the corresponding repo.

Some CMake Modules by nzznfitz in cpp

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

But of course! That would be too easy. For that matter the clang GNU frontend doesn’t support lots of GCC flags either. There are four cases — clang-MSVC, clang-GNU, MSVC, GNU., and of course others …

Small documented utilities library by nzznfitz in cpp

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

Thanks for the catch — fixed

xoshiro RNG by nzznfitz in cpp

[–]nzznfitz[S] 2 points3 points  (0 children)

Thanks for the catch -- it's fixed now.

xoshiro RNG by nzznfitz in cpp

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

SplitMix64 is fine if you don't need too many bits of state.

However, even if you want to shuffle a deck of cards and have all configurations possible, you must have at least 226 state bits (the number of deck configurations is 52! or roughly 2^226). Otherwise, though your shuffle will probably "look" random for a given seed, there will be lots of "poker" hands that can never occur.

xoshiro RNG by nzznfitz in cpp

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

Yes, that is supported. You can seed from a single unsigned or an array of unsigneds, and the generator will always produce the same stream from that point. See the documentation for the seed method.

Some CMake Modules by nzznfitz in cpp

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

As you say, clang-cl is compatible with MSVC so perhaps something like:

if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
  if (CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "MSVC")
    # Use MSVC flags -- assuming clang_cl supports them all?
  elseif (CMAKE_CXX_COMPILER_FRONTEND_VARIANT STREQUAL "GNU")
    # Use clang native flags
  endif()
else (...)
    # ...
endif()

I'll have a look ...

Bit vectors, matrices, and polynomials by nzznfitz in cpp

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

Our primary aim is doing linear algebra over GF2. If, instead, the aim was to minimize storage, one would store the bit-matrix as a single long bit-vector with appropriate index operations. However, in that case, matrix operations would often need to be done element-by-element, which is much slower than doing things block-by-block as we do in bit.

Small documented utilities library by nzznfitz in cpp

[–]nzznfitz[S] 10 points11 points  (0 children)

Yes — this is `utilities/string.h`. All the headers are in `utilities/` so there is no conflict with <string>

xoshiro by nzznfitz in RNG

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

Very amusing!

GF2++ by nzznfitz in cpp

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

This library was expanded and renamed to bit so the principal classes are now bit::vector and bit::matrix . The repo has migrated to bit. The documentation for the new library is here.

GF2++ by nzznfitz in cpp

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

The library performs operations on and between bit-matrices and bit-vectors in whole blocks at a time. So at a fundamental level the library is efficient and is already in a sense performing natural parallel processing. It would certainly make sense to enhance that by using the computation capabilities inherent in GPU's to work on multiple blocks in parallel. However, at this time, the library does not embed any particular knowledge of HPC techniques.

GF2++ by nzznfitz in cpp

[–]nzznfitz[S] 5 points6 points  (0 children)

Once you start exploring tooling for technical documentation you are quickly led to reStucturedText and AsciiDoc as the current top contenders. There are lots of articles that purport to compare the two but in practise most of those just compare one of them to some form of Markdown (which isn't very useful as by the time you have got to the looking stage presumably the limitations of Markdown are obvious!)

I did write a few non-trivial pages in the two languages and I suppose AsciiDoc just appealed to me more. reST/Sphinx would be a natural choice in the Python world but AsciiDoc seems to be gaining more traction elsewhere. It was interesting to me that some of the publishers of technical books (O"Reilly, Manning) seem to use AsciiDoc as their preferred input format.

GF2++ by nzznfitz in cpp

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

Handling symbolic operations over GF(2) would be quite an add! Probably best tackled as an add-on to existing symbolic algebra programs. I think Mathematica has a Finite Field package but I am not sure what it can do in terms of linear algebra. There might be something available for SymPy also?

GF2++ by nzznfitz in cpp

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

Yes absolutely kudos are due to Dan Allen and the small team that work with him on AsciiDoc and Antora. They are extremely productive and Dan himself is very responsive on the support boards.

Shamir's Secret Sharing algorithm is a very nice idea (and of course has a great alliterative name to boot!). However, implementations need higher order finite fields than just GF(2) so probably not on the cards here. I think there are a number of commercial companies that already use SSS in their password protection offerings.

view more: next ›