> It's a kind of cheating because it means not understanding the essence of the problem
In my opinion, this method presumes a clear understanding of the problem itself.
If you didn't have a clear understanding of the problem, you would not be able to test an answer to see if it is correct.
Now, this clear understanding of the problem could, of course, be coupled with a lack of understanding of other methods available (such as algebra) to solve the problem.
OTOH, maybe it's just coupled with a clear understanding that with the working memory that you have available to you right at the moment and without writing anything down, you don't even need those other methods.
This is related to "When all you have is a hammer, everything looks like a nail."
It's slightly different, because you've supercharged your hammer. Everything you ever understood about how to solve word problems has been subsumed into what your brain labels as "algebra."
But look at it this way:
1) Did you use algebra to convert the problem to algebraic form? Probably not; algebra says nothing about word problems.
2) Once it was in algebraic form, did you need to repeatedly apply algebraic rules in order to reduce the problem, or could you glance at it and figure it out?
You may also be hampered by your choice of variable, because you chose "X" to be an intermediate variable.
If, instead, you choose "X" to be what you are searching for, Ann's current age, then the problem setup is:
24 - x = x - 12
Which many of us can solve in our heads without writing down, or even without consciously converting "Ann's current age" to "X".
Sorry to say, the first half of this comment is almost gibberish. It became algebra when I introduced an unknown variable and wrote down an equation. I can't see a way to solve the problem without doing that.
> If X is Ann's current age, then the problem setup is: 24 - x = x - 12
How did you get this equation from the problem statement? The equation is of course correct, but I don't see how you would derive it, other than writing down a more obvious equation and rearranging it.
> Sorry to say, the first half of this comment is almost gibberish.
In what way?
> It became algebra when I introduced an unknown variable and wrote down an equation.
But a lot of people, including me, can solve it without writing down any equation.
> I can't see a way to solve the problem without doing that.
Ah. So it's gibberish because of your limitations? That's... not how this usually works. (Although, to be fair, it's often the case that people of limited intellectual means lash out with unkind comments such as "gibberish" so maybe this is how it works.)
> How did you get this equation from the problem statement?
"Mary is 24 years old. She is twice as old as Ann was when Mary was as old as Ann is now. How old is Ann?"
We know that there is a delta between Mary's current age (24) and what I called X in my previous comment (Ann's current age AKA Mary's prior age). That would be 24 - X.
We also know that at some previous time, Ann was 12 (half of 24) when Mary was (Ann's current age AKA Mary's prior age).
Some of us just take the mental shortcut that the in between age has to be the average of 24 and 12 (because the delta doesn't change[1], so the delta must have been the same before as it is now), but if forced to write it down into algebra, we can say that this second statement is X - 12.
And then of course, again, because the delta doesn't change, and the delta is equal to both x-12 and 24-x, those expressions must be equal to each other.
[1] Except of course, the delta could wobble a bit for birthdays being on different dates within the year. In simple puzzles like this, of course, that +/- 1 year possibility is usually ignored.
I think what you suggest works! Putting it in the wording of my original comment: Mary IS 24, Ann WAS 12, and the same amount of time gets you from 12 to Ann's current age, and from Ann's current age to 24. I think it is obvious from there that you're half-way between, so Ann is 18. Thank you!
The part of your earlier comment I consider gibberish has nothing to do with the problem.
> It's slightly different, because you've supercharged your hammer.
This does not mean anything.
> Everything you ever understood about how to solve word problems has been subsumed into what your brain labels as "algebra."
This is bizarre speculation. Why are you analyzing my brain? I just asked for an explanation!
> Did you use algebra to convert the problem to algebraic form?
As you say, this is impossible to do, because it doesn't make sense. So why bring it up? It sounds like you are trying to convince me the problem is not algebra - or that I am in some way only seeing it as algebra because I am not thinking about the problem clearly. But I never said it was! I just said I can't see how to do it without algebra. Since you mixed those things up, I clarified by saying exactly what sense I was talking about algebra in the first place. Clearly that didn't work!
Again, thank you for explaining your reasoning, I appreciate it. Just leave out the analysis of my mind!
I should have added weasel words like "maybe" and "probably" because I don't know you. Yet, everything I wrote, I have observed numerous times in other people.
And (and of course, maybe I'm wrong here) if you hadn't learned algebra, this solution would have been more obvious to you. Obviously we can't run that experiment directly. But think back to your childhood. Did you ever intuitively know the answer to a problem that others struggled with? Does that happen as often lately?
Formal methods like algebra are powerful and allow us to document, step by step, transformations that would be impossible to hold in our heads informally. We can solve problems that were unapproachable before. But we can get so used to using them that we forget intuitive tricks that we used to use.
Maybe this didn't happen to you. You're right. I don't know you. I'm only extrapolating. It really is the sort of simple problem that many people (possibly most of them younger) can solve immediately without assigning variable names or even writing anything down.
If this describes your capabilities when you were younger, then something changed. What is it?
Let me give you an example of my own. When I was a child I would play around with electronics. I intuitively knew that if I put two resistors in parallel, the amount of resistance would go down, and by how much, and could easily extend that to 3 or 4 resistors, rummaging through my collection to find resistors that would parallel to give me the value I wanted.
Once I learned the parallel resistor formula, I got slower at everything above two resistors.
Which brings us to:
> As you say, [using algebra to convert the problem to algebraic form] is impossible to do, because it doesn't make sense. So why bring it up?
I brought it up because, although we agree that it is not strictly part of algebra, it is something that you had to learn in order to use algebra effectively.
To me (and of course, again, I'm still speculating here) the fact that you're smart enough to use intuitive methods to set the problem up in algebraic form means that you were probably smart enough to use intuitive methods to simply solve the problem directly, if you weren't so used to directing your brain activity towards doing things using algebra.
Uhhh... what? The OP is right; even if you do it intuitively it's still algebra. If you need a proverb to justify it: Just because your hammer is made of stone doesn't make it less of a hammer.
Look, when someone says "you need algebra to solve this" is it reasonable to assume that they are talking about informal methods that people have used forever, or is it more reasonable to assume they are talking about formal algebraic methods?
Because many people sure as shit don't need any algebraic symbols or operators to solve this in their heads.
I did a similar thing with a rack of test equipment. I had a PC power supply on each shelf, and used an NPN transistor to turn on the power supply whenever the USB port connected from the main computer to that shelf rack was turned on. Crude, but effective, out of band communication.
The local USB hub on the shelf was powered from the PC power supply on that shelf, so a single long USB cable from the shelf with the control computer could command the shelf (including the USB hub on the shelf) to fully power up or down, and then control several test devices through the USB hub, and none of the USB devices on the shelf (some of which were bus-powered) needed to worry about not getting sufficient voltage through a long cable and a hub.
> I think especially the cheap hubs will changes the parts used overtime and not update the revision.
Yeah, the last time I purchased them was December 2022, so I definitely don't know for sure that they still work. But they aren't the cheapest hub, so maybe?
But at that time, I purchased hubs from several manufacturers, and most of them didn't work. The first thing I had working was actually an eval kit from an IC vendor.
Also, many hubs that can theoretically be used powered or unpowered are terrible about backfeeding power, either to the host, or (more commonly) to the wall wart.
It's best to either always use the hub unpowered, or to buy a hub that always requires power, unless you've checked and made sure that it's not going to screw you over.
You need to be careful with this one, or reductio ad absurdum might lead you to not build microservices, or even a monolithic app, before you have acquired your first customer.
True, but also "Do Things that Don't Scale" (https://www.paulgraham.com/ds.html). There are many examples of successful companies that had customers before they had products.
Obviously, it partly depends on the implementation machine, how big a hole the tables blow in your cache, how fast the multiplies are, etc.
But it probably also hugely depends on the format that you want your trits in. If you use them unpacked, e.g. one trit per byte, then even if you're using tables, you still have to do a lot of manipulation (e.g. either shifting and oring, or having different tables, and a table lookup per trit and adding together to get the binary).
You can have a single 3x256=768-byte table -- just multiply the input byte by 3 to get the offset into the table, and read out the 3 trits (1 trit per byte) beginning at that offset.
ETA: If you're prepared to waste a byte per entry so that entries are 4 bytes wide, on x86 you can use effective address calculation to do the multiplication for you, letting you decode 3 trits in 1 CPU instruction:
In any case, if there were 3 trits, I'm not sure what the practical difference between a single table you describe and 3 different 256 byte tables, again depending on the architecture.
Yes a single table would have better cache effects for a single read, but presumably? you're doing a lot of reads in an unpacking phase.
You wouldn’t need five tables. Each trit takes up two bits when unpacked into 0,1,2 values.
You can do a full unpacking-via-lookup with a uint16[256] and then do bit shifting and masking to extract the individual trits, but using an extra byte in each entry (or 3 tables) would let you extract with just two shifts.
This starts to vary a lot with the microarchitecture, and there’s the added dimension of SIMD vectorization, so accurate timing in a realistic context becomes important.
But then, I'm pretty sure you haven't said anything different than what I said in the great-great-grandparent of your comment, other than slightly fleshing it out for a couple of particular scenarios.
But you haven't covered the packing, which is the primary thing I was suggesting you might need multiple tables for if you really wanted to use tables and really didn't want to do shifting or multiplication.
I think storing 5 consecutive bytes per entry in a size-1280 table will still be faster than 5 single-byte lookups in separate size-256 tables, since it only requires 1 (unaligned) dword MOV and 1 byte MOV.
> compared to languages which demand much more effort to get anything substantial done.
It is not clear at all to me that other languages "demand much more effort" for the same end result.
It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting psychological studies on this, but the rift is so large, I think there may be some significantly different brain processing going on between the two groups.
To your point, yes, it is also clear that, to the extent that lisp can match the productivity of other languages, whether it exceeds them or not, one of the tools that is needed to achieve this productivity boost in lisp is heavy usage of homoiconicity, and this results in every serious lisp program being a collection of DSLs, each of which is only understood by one person or very few people.
> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp.
I can guarantee you that most of these simply didn't go far enough; they had their "minds blown" with too little. They latched onto a highlight or two, found a way of sort doing that in C++ or Javascript and moved on.
There are people who have had their "minds blown" by time/mass dilation of special relativity, or phenomena in quantum physics, who don't actually know anything about physics; they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
For those of us sticking with the Lisp program, in one way or another, it was more of a sequence of small revelations in a progression of topics. Oh, that's a good way of representing that; that is pretty nicely thought out; that fits well with that; they had that how many decades ago? Sheesh; ...
Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
> I can guarantee you that most of these simply didn't go far enough;
And I can guarantee that I knew, when I wrote my comment, that I was summoning this very "No true Scotsman" argument.
> they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
It always superciliously starts with how true lisp people are the most brilliant ever.
> Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
And is eventually undermined by an admission of cognitive inflexibility, although not usually so quickly or in the same comment. Good job!
> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp
For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp
If you then optimize for employability, which I assume most developers do (not all, but a large percentage), you might end up with not that many people practicing lisp regularly
> For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp
Certainly. But why would that be? It couldn't possibly be that the programmers already there built a system using the tools of their choice, and that system is now running well and deemed maintainable enough they require additional developers for the same language, could it?
Sometimes, of course, companies change their implementation language. The most famous cases I know of this are Viaweb and reddit, where the companies moved away from lisp. The company's main motive in this, of course, is making money. If they have a good product that is deemed maintainable, why would they piss off the original team, who probably chose the language, by switching languages?
Many programmers have worked in lisp. Studies have shown that programmers routinely learn new languages and somewhat forget old ones; older programmers are typically only currently proficient in as many languages as younger ones.
A company with a successful product is going to attempt to leverage that success. Whether leveraging it looks like incrementally improving it, or like treating it as a prototype and throw it out, will typically be a long conversation between developers and management. Typically incremental improvements are greatly preferred; it is only when all stakeholders become convinced that a fresh start is required that massive changes like implementation language will take place.
The calculus, of course is changing with LLMs. See, for example, the recent migration of bun away from zig. That rewrite was spearheaded by a massively effective lone developer, the exact persona that is claimed to always prefer lisp. Sadly, he chose rust.
I cannot disagree, but many who should know better do.
I have seen people argue with a straight face that there are no copyright concerns simply because of the sheer volume of the data that LLMs are trained on.
This makes less than zero sense. If someone has seen code, or heard music, and creates something too similar, it is a copyright violation, even though that person has seen much code or heard much music before. This is why the concept of "clean room" implementation exists, and why the concept of the abstraction-filtration-comparison legal text exists.
LLM proponents will point to the fact that courts have ruled that using copyrighted material for training has been ruled fair use.
This actually makes sense. Just as you can read a book, so can an LLM.
The thing that, AFAIK, hasn't been ruled on yet, is when the LLM regurgitates something that is too close to the book. If a human were to do that it is a clear copyright violation.
To pretend that "dilution is the solution to pollution" in terms of LLM training data, and that anything the LLM produces is original material, is to give LLMs more rights than humans have.
In my opinion, this method presumes a clear understanding of the problem itself.
If you didn't have a clear understanding of the problem, you would not be able to test an answer to see if it is correct.
Now, this clear understanding of the problem could, of course, be coupled with a lack of understanding of other methods available (such as algebra) to solve the problem.
OTOH, maybe it's just coupled with a clear understanding that with the working memory that you have available to you right at the moment and without writing anything down, you don't even need those other methods.
reply