Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "algebraic type"
-
Since we're limiting this to things on my desk I can't do any more deep cuts out of my calculator collection, but this one is still somewhat interesting.
The HP 32S was my friend throughout university, it replaced the 15c I used before which does not live on my desk. The notable thing about the 32s is the fact it's an RPN calculator. RPN calculators are the best way to have friends never ask to borrow your calculator. The exchange will start by them asking to use it, you saying sure, and them handing it back a few minutes later without saying a word.
There's two kinds of people in this world. People who go "wtf" in an interview when asked to create a calculator program using a stack, and people who were oddballs and for whatever reason used reverse polish notation devices.
For those not familiar, rather than entering values into the calculator in "10+10" fashion, you instead provide it a compositional set of values until an operation is provided (10,10,+) at which point it executes. The why is, this type of operation allows the calculator to more naturally process operations, and eliminates the need for parenthesis which makes the operations less error prone in practice and easier to track.
The 32s had a 4 year run before being replaced by the 32SII. In the same way using a Curta will give you a significant understanding of how radix computations and floating points work. Using an HP 32s (or any of its predecessors) will do the same for algebraic functions, because you had to program them yourself using a basic label address system that also had subroutine support.
Kids who grew up with graphing calculators don't know how good you had it 😋4 -
I want to explain to people like ostream (aka aviophille) why JS is a crap language. Because they apparently don't know (lol).
First I want to say that JS is fine for small things like gluing some parts togeter. Like, you know, the exact thing it was intended for when it was invented: scripting.
So why is it bad as a programming language for whole apps or projects?
No type checks (dynamic typing). This is typical for scripting languages and not neccesarily bad for such a language but it's certainly bad for a programming language.
"truthy" everything. It's bad for readability and it's dangerous because you can accidentaly make unwanted behavior.
The existence of == and ===. The rule for many real life JS projects is to always use === to be more safe.
In general: The correct thing should be the default thing. JS violates that.
Automatic semicolon insertion can cause funny surprises.
If semicolons aren't truly optional, then they should not be allowed to be omitted.
No enums. Do I need to say more?
No generics (of course, lol).
Fucked up implicit type conversions that violate the principle of least surprise (you know those from all the memes).
No integer data types (only floating point). BigInt obviously doesn't count.
No value types and no real concept for immutability. "Const" doesn't count because it only makes the reference immutale (see lack of value types). "Freeze" doesn't count since it's a runtime enforcement and therefore pretty useless.
No algebraic types. That one can be forgiven though, because it's only common in the most modern languages.
The need for null AND undefined.
No concept of non-nullability (values that can not be null).
JS embraces the "fail silently" approach, which means that many bugs remain unnoticed and will be a PITA to find and debug.
Some of the problems can and have been adressed with TypeScript, but most of them are unfixable because it would break backward compatibility.
So JS is truly rotten at the core and can not be fixed in principle.
That doesn't mean that I also hate JS devs. I pity your poor souls for having to deal with this abomination of a language.
It's likely that I fogot to mention many other problems with JS, so feel free to extend the list in the comments :)
Marry Christmas!34 -
So while exploring some new ideas, I decided to figure out if I could use variables in the known set to determine the bounds of variables in the unknown set.
The variables in question are algebraic identities derived from the semiprimes, so you already know where this is going.
The existing known set is 1194 identities.
And there are, if I recall, roughly two dozen unknowns.
Many knowns have the unknowns as their factors. The d4 product set for example is composed of variables d4a, d4u, d4z, d4z9, d4z4, d4alpha, d4theta, d4omega, etc.
The component variables themselves are unknown, just their products are known. Anyway.
What I've found interesting is if you know the minimum of some of these subsets, for example d4z is smallest out of the d4's for some semiprimes, then you know the upperbound of both the component variables d4 and z.
Unless of course either of them is < 1.
So the order of these variables, based on value, changes depending on the properties of the semiprime, which I won't get into. Most of the time the order change is minor, but for some variables they can vary a lot between semiprimes, rapidly shifting their rank in the known set. This makes it hard to do anything with them.
And what I found myself asking, over and over again, was if there was a way to lock them down? Think of it like a giant switch board, where flipping one switch lights up N number of others, apparently at random. But flipping some other switch completely alters how that first switch works and what lights it seemingly interacts with. And you have a board of them thats 1194^2 in total. So what do you do?
I'd had a similar notion a while back, where I would measure relative value in the known set, among a bunch of variables, assign a letter if the conditions were present, and generate a string, called a "haplotype."
It was hap hazard and I wrote a lot of code to do filtering, sorting, and set manipulation to find sets of elements in common, unique elements, etc. But the 'type' strings, a jumble of random letters, were only useful say, forty percent of the time. For example if a semiprime had a particular type starting with a certain series of letters, 40% of the time a certain known variable was guaranteed to be above a certain variable from the unknown set...40%~ of the time.
It was a lost cause it seemed.
But I returned to the idea recently and revamped the entire notion.
Instead what I would approach it from a more complete angle.
I'd take two known variables J and K, one would be called the indicator, and the other would be the 'target'.
Two other variables would be the 'component' variables (an element taken from the unknown set), and the constraint variable (could be from either the known or unknown set).
The idea was that relationships between the KNOWN variables (an indicator and a target variable) could be used to indicate the rank relationship between the unknown component variable and the constraint variable.
You'd think this wouldn't work either, but my intuition was there were so many seemingly 'random' rank changes of variables in the known set for any two semiprimes, that 1. no two semiprimes ever shared the same order for every variable, and 2. the order of the known variables had to be leaking information about the relationships of the unknown variables.
It turns out my intuition was correct.
Imagine you are picking a lock, and by knowing the order and position of the first two pins, you are able to deduce the relative position of two pins further back that you can't reach because of the locks security features. It doesn't let you unlock the lock directly, but by knowing this, if you can get past the lock's security features, you have a chance of using information about the third pin to get a better, if incomplete, understanding about the boundary position of the last pin.
I would initiate a big scoring list, one for each known element or identity. And then I would check it in tandem like so:
if component > constraint and indicator > target:
indicator[j]+= 1
This is a simplication, but the idea was to score ALL such combination of relationship, whether the indicator was greater than the target at the same time a component was greater than a constraint, or the opposite.
This worked out to four if checks and four separate score lists.
And by subtracting one scorelist from another, I could check for variables that were a bad fit: they'd have equal probability of scoring for example, where they were greater than the target one time, and then lesser than it for another semiprime.
So for any given relationship, greater or lesser between any unknown variable and constraint variable, I could find any indicator variable and target variable whose relationship strongly correlated to the unknown's.18 -
I need cyclic data structures but algebraic data types are my first love and tying the knot is impossible with the eagerness F# has. The interfaces and classes I abandoned C# for are the ones I am now writing in F#. What a job well done on my part in avoiding mutability :(6
-
Just realized that it’s been a long time since I had to deal with collections that contain values of different types and that ugly type checks that come with it when you need to do something with the values.
Sum types are really a blessing. -
I identified the need for a product akin to an ORM that maps an algebraic type system such as that of Rust to a key-value database (my situation dictates lmdb but I'd like to abstract away the store). Can you recommend prior art for me to research?4