Posts in category Programming:
Recently I've mostly used React for front end development, but also used the serverless framework quite extensively for back end, API and event based flows. So finding Serverless Next.js was nice.
Recently, demand for high-speed compression has lead to new algorithms based on pure Lempel-Ziv compression without entropy coding. Examples are Snappy and LZ4, both using byte based LZ77 algorithms. This leaves significant redundancy on the table that can be used for steganography while remaining completely transparent to the users of the cover file.
Snappy and LZ4 are two high speed compression algorithms that are based on LZ77. They are used in various applications where decompression speed
Move-to-front is an algorithm for coding symbols that have been seen recently with a smaller number. It’s used as a part of some data compression algorithms, e.g. after a Burrows-Wheeler transform.
I tried to approximate it in a faster way and found an algorithm that I haven’t seen elsewhere (although it’s probably not new).
I've recently been using mercurial for revision control. I still don't like it much as git, because it tries so hard to prevent me from modifying history (modifying local history is not a bad idea) and has so many tools that do almost the same thing.
However, the MQ extension is quite nice. Even though it requires you to learn a new set of commands (where in git you'd just use another local branch as a queue), it does make modifying and moving through patches
I found a bug in my 7 hand poker evaluator generator, which means that the tables I posted earlier, while valid and usable, are not optimal. I haven't yet rewritten the code, but the difference should be on the order of a couple of percent. Meanwhile, I used the same procedure I outlined to create a table-based representation for a five card evaluator.
The tables and a BlitzMax file are included in a compressed archive.
Over the past few days I've looked at poker hand evaluation, specifically 7-card evaluation for games like Texas Hold'em. What I did is based on three evaluators I've studied: Cactus Kev's 5-card evaluator, Paul Senzee's 7-card hash function and the "2+2 evaluator" by Ray Wotton et. al.
First a little background: There are (52 choose 7) = c. 134 million 7
I've come to like the expressiveness of the Python language, though I dislike some of the other features. Here's a 50 line raytracer that renders scenes of colored spheres to a PNG file:
import math from PIL import Image
def sub(v1, v2): return [x-y for x,y in zip(v1, v2)] def dot(v1, v2): return sum([x*y for x,y in zip(v1, v2)]) def norm(v): return [x/math.sqrt(dot(v,v)) for x in v]
def trace_sphere(r, s, tmin, color): sr = sub(s, r) dsr = dot(sr, r)
I created a BlitzMax program to filter* and compress images using either LZMA SDK or zlib. Here are the results for three test images I picked up from Wikipedia: Mona Lisa (painting), The Gunk (pixel art) and Grad1 (gradient).
I'm writing a small raytracer to familiarize myself with Java. Obviously many of the main algorithms need to be as fast as possible in order to eventually get to real time speeds.
Here's my optimized version of a ray-sphere intersect check. It can probably be tweaked further: 9 additions, 7 multiplications best case; and 12 additions, 7 multiplications and a square root worst case is the current speed/complexity.
The method only calculates t - the coefficient of the ray direction