namark @namark@social.cleverlibre.org

Since it was a tie between map, progress and linin, I obviously had to go with way.

https://git.sr.ht/~namark/libsimple_support/tree/95f5932b9d61c0badd2d87d9ae8def074b47a22b/source/simple/support/algorithm.hpp#L285
https://git.sr.ht/~namark/sketchbook/commit/85f2009edc65171dbc6a06f8bfb4dc7405ed69eb

#cpp

can:
while( auto x = get() ) stuff(x);
can't:
while( !(auto x = get()) ) stuff(x);

someone write a proposal ToT

#cpp

I'm going to go with 4 as a shorthand of the successor function in cases where it makes sense (naturals, integers) and as a generalization in cases where it doesn't (rationals).

The only problem is that it doesn't optimize well for IEEE floats. It emits an add instruction because of a special case -
0.0 + (-0.0) = 0.0,
which makes negative zero the actual addition identity, as opposed to positive zero that floats are initialized with by default. However this seems to be a well known problem (I guess comes up often with accumulate/reduce type algorithms), so I would expect the user to be aware of this if it's a bottleneck for them, and either use -ffast-math or a custom type that initializes to negative zero.

#cpp #float

Considering a generic function, that accepts a count of numbers (usual + - * / algebra) and returns their average (sum over count), what requirements make sense to be imposed on the number to allow division by count?

(count is 2 in example pseudo code)

1. explicit construction from a single natural number:
(n1 + n2)/number(2)

2. straight up a division operator that accepts a natural number as second argument:
(n1 + n2)/2

3. multiplication identity constructor/value that can be accumulated (using addition) to reach count:
(n1 + n2)/(number::one + number::one)

4. addition operator that accepts a natural number as second argument (assuming zero/default constructor available):
(n1 + n2)/(number() + 2)

#cpp #programming #generic_programming

forgot #cpp -_-

Try to write transparent wrapper using implicit conversion ->
-> templates don't pick it up, cause type deduction -> fix with metamagic ->
gcc rejects valid >~<
http://ix.io/2nlC/cpp
Isolate, work around.

Add an innocent constant variable -> clang segmentation faults x_x
http://ix.io/2nlF/cpp
power through without the quality of life constant.
Brag about bugs you found.
Feel alive.

#cpp

For a vector of booleans representing a disjunction, considering these 3 binary operations:

1. Reducing conjunction. Reduces both operands and return the conjunction as a single boolean. Trivial, logical and sane.

2. Expanding conjunction. Returns a matrix representing a disjunction of conjunctions of all pairings of element from each operand (kind of a halfway symbolic computation). Somewhat complicated (essentially matrix multiplication), but still logical, if a bit insane.

3. Element-wise conjunction. Returns a vector containing the conjunction of corresponding elements of two vectors. This vector no longer represents a disjunction unless explicitly converted to original type. Kind of a masking operation. Illogical and insane.

Which operator would you prefer for each?

#cpp #boolean #algebra