Some things I realized about AI while contemplating slide rule prices on eBay
misc-stuff.terraaeon.com
misc-stuff.terraaeon.com
I have many engineer friends. They have no problem understanding the math and physics and concepts of things like statics analysis and don't use simulation "because they don't understand the problem" but because simulations allow you to use more complicated, or more unusual structures that classical methods simply cannot work with.
Your stupid slide rule and winging cannot compete with the power that you get from actually using the math that your older methods just approximate. Turns out, much more accurate simulation allows for BETTER SOLUTIONS.
Stop being a crotchety and elitist angry person and try to understand the way things are going, instead of casting new methods aside because you don't personally understand or get them.
I felt that I had a better grasp of what a particular computation meant. The need to keep track of orders of magnitude and so on helped me catch errors that would have slipped through if I was just pressing buttons and copying down results. The practice helped me later on with "back of the envelope" calculations.
It doesn't make me nostalgic for slide rules, though. Give me an HP calculator any day.
Same thing happens everywhere - people don’t understand enough to do something like ballparking some numbers to check if they’re at all reasonable - but this is useful.
Sounds familiar, like I just read an example of it :/
The Author generates strings of characters (that ultimately form 'words' and 'sentences' and 'paragraphs' in aggregate).
These character strings are chosen by an author to suggest a 'frame of mind' in order to best get her point across. So when an author of fiction causes a character to say things that are interpreted as angry, it doesn't mean the author herself is, in fact, angry.
Therefore, unless we know something not in evidence besides the author's strings of characters, drawing conclusions as to the writer's mental state is ... odd. Even for pieces of non-fiction.
this is how written communication works
- too much uncertainty - extremely relaxed tolerances for acceptable answers
and are performed in people's heads or simple napkin/grade school maths. It's not about computational power, it's about what's right for the job.
The calculators had to produce an answer that was off by more than a factor of 2 before the students suspected something might be wrong.
Back in the 80s at Boeing, the experienced engineers were deeply suspicious of any "computer numbers" because they'd been burned too many times by garbage results pushed by the computer department. I was the only person in my group (of about 30) to use a computer to calculate things. The others used calculators and graphical methods. My lead engineer didn't want any "computer numbers". I persisted, so he set up a competition between me and his best graphical method draftsman.
One of the numbers I generated didn't match the graphical results. My lead said "see, you can't trust those computer numbers!" The graphics guy said he'd recheck that one. A couple hours later, he said he'd made a mistake and the computer numbers were correct. (Note the "couple hours" to get one number.)
After that, my lead only trusted computer numbers from me, and directed a lot of the calculation work to me.
(All designs were double checked by a separate group, and then validated on the test stand. Correcting a mistake by then, however, got very expensive.)
That's an interesting thought.
There's no reason a calculator has to output only a number - with the computing power and displays at our disposal today, we could easily draw and/or animate a virtual slide rule.
A virtual slide rule probably wouldn't be the best option, though. It's just a visual metaphor for how the values in the calculation relate to one another, and it's one that's only going to be useful for someone who has learned to use a slide rule.
I wonder if there might be an effective, generic way to present calculations visually in a way that requires little or no training to understand. Has anyone done this?
If the model can be ran at the rate of frames per second, sliders or other non precise inputs are good for this.
Eg. You can get an exaggerated deformation view of a part, with animation for different input stress.
VS a slide where you only get the one value of output at a time
A specific operation is much less important than the context, dimensional analysis, getting order-of-magnitude or precision correct. Performing operations narrowly is probably operating on the wrong level.
You do realize who that is right?
https://github.com/DigitalMars/dmc/blob/master/src/CORE16/DO...
Also, many of the math library functions, though I used "Software Manual for the Elementary Functions" by Cody&Waite for a guide.
I imagine you know as much about IEEE 754 as anyone living.
Thanks for the all the great software!
The point here isn't a out precision, its about accuracy. Most simulations consider tolerances and variability as an afterthought, and as you point ouf spitting out a seemingly precise but likely innacurate output.
Really we should have the best of both worlds - simulations should model uncertainty or use MTCS, and output a probability range.
Engineers do learn how floats are stored and how computations are done on them to avoid numerical problems while solving whatever differential equations and matrices that they need
Using a slide rule is also explicitly imprecise, so the user isn't expecting that the result to accurate to n decimal places. They're aware of the imprecision and are likely at least considering whether the level of precision is enough to answer the question they're asking.
If I'm looking at a blueprint as see a dimension listed as "1.5mm", my instinct is that anything from 1.47mm to 1.53mm "-ish" is likely to suffice. I'm going to want to understand how that part interfaces with others to make sure it won't cause an issue if it's slightly different. If on the same drawing that dimension is marked as "1.5125mm", my assumption would be that the person who drew it out was specific for a reason. I'm going to be much less likely to try to consider the interface with other parts because I assume that level of precision indicates that it's already been considered.
Note that the above is just a conceptual example. I'm not a draftsman, machinist, or an engineer - I've just done enough amateur machining and design work for 3D printing that it popped to mind. Yes, I'm aware that there are implicit and explicit tolerances based on the number of significant digits in a measurement. :)
I replied that I had calculated the max and min values based on the rest of the assembly. When a part is delivered, if it is out of tolerance it gets bounced to the engineers to see if it can be salvaged. As the jackscrew was an extremely expensive part, I reasoned that giving it the max possible tolerance meant cost savings on parts that wouldn't have to get diverted to engineering for evaluation.
The drawings got approved :-)
Given that, I can only assume that every other branch of engineering has long since fully accounted for it.
> Did you think it would actually be built as designed
Of course. You can't build modern airplanes any other way.
> did you always assume there would be some additional degrees of freedom or out of tolerance build you didn’t account for?
Nope. I accounted for the tolerances specified for all the parts it was to be connected to. When the airplane #1 was built, the jackscrew fit perfectly on the first try, which surprised the old mechanics working on it :-) It was my job to account for everything anyone could think of. It really wasn't a miracle or anything, just arithmetic.
The other crash involving jackscrew failure (on a 747) was when an unsecured armored personnel carrier slid back and fell on it, snapping it. You can't really blame the jackscrew for that. No airplane is designed to handle heavy iron cargo flopping about in the hold.
On the human scale precise clock maths is rarely necessary, and conceptually thinking of time as a base 60 number can be more trouble than good.
Technology Connections has a very good video on this, and completely changed thinking: https://youtu.be/NeopkvAP-ag
I strongly disagree, having used a slide rule despite and spent hours exploring how it is the physical representation of logarithms.
I could tell you many stories of witnessing otherwise smart engineers run the worst possible simulations I've ever seen, but argue that their results were correct simply because the computer generated them.
I suspect its our trust and reliance on digital computing, and the amount of cultural messaging.
I was certainly a very green engineer, but I had played around a lot with numerical simulations in college. I knew I could get better, faster, and more reliable results with a computer program than the calculators everyone else used.
My lead was right to be very skeptical, and I enjoyed the challenge he set up for me. I had no problem being asked to prove my results were correct.
The point is that we shouldn't trust a model just because it is run on a computer, just as we should trust that hand written calculations may not have numerical mistakes.
Perfectly suitable. But they did have a couple of hours to come up with the right numbers, and they did have slide rules and graphical methods as backup. That is what allows evolution, you can't believe a computer right from the start and instantly abandon older methods. Those methods have a place.
In fact if an African student wanted to be a mathematician, a slide rule--due to its analog nature would--set him ahead and allow him faster results than his peers. Whereas a calculator you don't know where you've got it wrong.
The speedup wasn't in writing the program to do the calculations. The speedup was in being able to run the program repeatedly as the design got tweaked. There was also the fact that once the program proved correct, the iterations were also free of error. For example, if I write a program to compute sin(x), I only need to check a few points to verify it. Doing it graphically or by hand can introduce error for every use.
Now that's the incredibly difficult part, as bugs are no stranger to code, let alone code that tries to model the real world with assumptions.
The sin function is actually incredibly incredibly complex (https://stackoverflow.com/questions/2284860/how-does-c-compu...) and implimentation are full of implicit and imperfect assumptions (like floating point). Under normal use these errors are silently propogated, and the floating point model well designed enough that for the majority it doesn't matter at all.
Being able to run a model whilst iterating is great, but at the end of the day it's still a model, and could break down.
I'd check the results by running the reverse algorithm to see if the outputs reproduced the inputs.
For example, I'd check the matrix inversion by multiplying the input by the inverse and seeing how close it got to the identity matrix.
Something I tell developers and system administrators in my consulting job is to be aware of "orders of magnitude" and try to estimate them in their head when investigating things.
Just yesterday I was trying to explain to someone that taking 4 seconds to load 150 bytes of text on a page is an error measured in orders of magnitude. Scaling up or down isn't the answer when the situation is "off" by a factor of 100,000x or more!
I was nearly laughed out of the room because apparently Deloitte — a much more expensive consultancy — had told them that what they really needed was to dynamically scale out further.
“The cloud will scale to the size of your wallet if you let it.” was my response, which… did not go down well.
I didn’t hear back after that. Years later they’re still scaling up and working on migrating to a more cost-effective hosting provider.
eg. http://web.mit.edu/4.441/1_lectures/1_lecture8/1_lecture8.ht...
Now think about the 1960's when I estimate 90% of the calculations for the Apollo moon project were done on slide rules.
NASA did have the best computers available and used them to the max but that tied them up so much they were only used for those things where it was thought you just had to have a computer for. And this was by design a highly computerized spacecraft itself like nothing ever before.
The better your slide rule skills, the better your computer abilities may be once you get a hold of a computer.
That's what computers were made for, to augment a well established inuitive manual calculation capability of accomplishing all kinds of very advanced engineering.
> Performing calculations with slide rules was part of what forced generations of scientists and engineers to _understand the approximations they were using to solve problems_.
I think this is a valid and pretty strong point. Just as in science significant figures matter, the same does for all thinking. In the given example, it is undeniable that calculators don't propogate uncertainty the same way that a physical slide rule does.
> He did not want to be bothered with the actual truth (i.e. flaws and inaccuracies in the simulation), because he was simply not interested.
Models by definition do not capture all the intricacies, and it's important to have an instinct about what matters and an instruct about the expected model result. It is commonplace for simple models to ignore uncertainty and tolerances as a factor (for simulation speed or complexity reason), which can lead to drastic differences in simulated and true outcomes. Any reasonably complex model is also likely to be chaotic, but it can be difficult to appreciate when the model is useful, and when it isn't. I think it's quite easy to forget these nuances, especially if you don't fully appreciate the field you're modeling.
> Am I arguing that we should throw away our computers and go back to slide rules? Absolutely not! Some problems can only be solved by computer simulation--because we really do not know enough to solve them any other way. > But, most design problems can be solved with simpler, less expensive, less time-consuming methods and tools and more experience and knowledge of basic principles. > wasting time with tools that are not appropriate for their jobs
In my mind, this is much aligned with "premature optimisation is the root of all evil", and its something I've become extremely aware of as I've started getting into hobby CNC. Through this process I've had to learn when precision matter and when it can just be eyeballed, what can be approximated and how much of a fudge factor to use. Floating point accurate simulations just need to be good enough, and it's always expected that issues will arise in the real world. Most processes are forgiving enough that issues can be worked around, and it's a complete waste of time to try to anticipate everything.
At least in my scope of vision, simulations and modeling with uncertainty or tolerances is rare. Models that acknowledge their internal chaotic nature are more common, but not common enough. Modeling with uncertainty is inherently complex, and I'd hazard a guess that your engineering friends are careful enough to only use simulations in specific and key areas that it has an advantage, but are likewise happy to use approximations where necessary.
I'm not sure simulation is why present designs take so long. It's more likely a mixture of bureaucracy, cost-plus contracting creating perverse incentives to stretch out development, and insisting on pushing the envelope as far as possible and maybe past a point of diminishing returns.
The latter might indeed involve a lot of gratuitous simulation and hard number crunching, but it's to get to places you just couldn't get with classical approaches. Of course you can debate the diminishing returns angle and whether that extra 5-10% performance is worth the effort.
It's likely that they've seen deep learning used to solve problems in the past that are more suitable to a simple regression. They may not have seen it used to solve problems where regressions failed.
In your place, I'd dive into why they feel the way they do. Maybe they're right! More likely, maybe you're using deep learning for jobs it isn't best suited.
In a way I understand it, for example if somebody finished their computer vision PhD before Deep Learning and don't want to admit their knowledge is now next to useless for most industry cases...
Jokes on both of them: the DL knowledge is also next to useless for most industry cases.
Personal comment: I think you (mrguyorama) are correct in pointing to the complexity of contemporary structures/problems.
I would state this in terms of the where contemporary progress is being, what sorts of problems are being worked on, etc: considerably further into the fractal of hard problems, and in new regions of the problem domain which were not assailable through manual computation.
The tools being used in other words are necessary and appropriate for what kinds of work are being done today.
Aircraft design (etc.) today is only superficially related to what it was in the author's day. We are now in the hard 20% in a lot of ways.
This person ran it by some colleagues, who all disagreed, and the author took this as evidence in FAVOR of his belief? The hubris...
Simpler methods are more robust than more complex methods.
For example: https://www.rsc.org/images/Arrhenius1896_tcm18-173546.pdf predicted climate change more or less as it happened a more than a century ago. The current models are hugely complex and not that much more accurate because we're trying to simulate a system with a lot of unknowns.
The same is true just about everywhere when you start running ensemble simulation for multiple inputs. No one does because "We have 20% of simulation end up at infinity or 0" is not a very meaningful statement.
There are things you can do efficiently now with modern simulation that would be unthinkable in the heyday of the slide rule. Hell, in the 1980s.
On the other hand, I've seen a lot of time wasted on "analyzing" the wrong things, especially via simulation, merely because the work of setting it up is very approachable. I've watched young engineers struggle hard due to an over-reliance on these approaches, so it isn't just crotchety-old-guy problems. Its' also that, though :)
That’s not to say I would build the house without doing a proper structural engineering analysis and simulation. But not being able to estimate feasibility without doing the full simulation is a real problem.
Overreliance on simulations creates a need for really accurate simulations, which means considering lots of secondary effects and having enough data to support a simulation. This is hard.
The problem with development by hand is that you can't deal well with multiple constraints. Modern electronic design: It can't cost much. It can't use much power. It can't be big. It can't interfere with other devices. It has to have really good performance. You have to do a lot of simulation, tweaking different parameters, to meet all those constraints. Or build a lot of prototypes. You usually can't just do a conservative design and get a saleable product.
If you were designing a car today, and were willing to have 25% more weight, you probably could design it with a slide rule. You'd get a 1954 Buick Roadmaster, a sedan with a curb weight of 1983 kg.
"An engineer is someone who can do for fifty cents what any fool can do for a dollar."
> If you were designing a car today, and were willing to have 25% more weight, you probably could design it with a slide rule. You'd get a 1954 Buick Roadmaster, a sedan with a curb weight of 1983 kg.
Being 25% heavier than necessary is likely far too much. You could definitely design a car using analog tools and calculations to within <5% of the minimum requirements.
This is a great example of where too much precision is a bad thing!
A 1954 Buick Roadmaster had a curb weight of 4,430 lbs. Choosing a random modern car, a 2022 Toyota Camry has a curb weight of 3,310 lbs.
Assuming those as a baseline, each 1% of weight due to "overprovisioning" would be 44.3 and 33.1 lbs respectively. Lowering the load capacity of the vehicle by 5% would mean a 221.5 lb reduction in capacity for the Roadmaster and 165.5 lb for the Camry.
You have to account for not only the precision of your design, but also the precision with which it is used. I seriously doubt I could estimate to within 200 lbs how much the combined weight of all occupants and cargo in my vehicle is at any given time. It's therefore fair to say that the use case for a car is not estimated to within 5% of reality - so the car must be overbuilt by some margin of >5% to account for that.
If the precision of the intended use case is that high, spending additional time to reduce vehicle weight to <5% of the target capacity is wasted. It's better to make it a bit heavier than strictly necessary than it is to spend the resources to know precisely how heavy it needs to be to meet an imprecise requirement.
Most of the complexity of modern cars goes to crash standards which are much more rigorous than in the 1950s. I doubt you could design a car within 5% that meets crash testing standards without simulations or live testing.
Including the emissions and fuel economy requirements?
One of my favorite cars from the slide rule era is the 1966 Ford Mustang.
About the same curb weight as the decades newer Nissan 280ZX except the Mustang with the small V8 can reach about twice the horsepower. But when driven conservatively would almost equal the gas mileage of the small Japanese roadster.
I've known machinists who said the same about CNC. Sure, there are benefits to establishing a good sense of the older ways- but it's not laziness or irresponsibility to embrace new technologies and utilize them for efficiency. There is a whole lot of bias and catastrophizing here, like the author is grieving the perceived loss of analog tools and projecting these emotions into this rather bleak commentary. Look, it's one thing to be nostalgic and appreciate simpler ways of solving/understanding things- but it's a whole nother one to make condescending judgements of value and extending these ideas onto generalizations against people.
It would be ridiculous to produce 10,000,000 widgets with a manual lathe. The increase in time and material waste would be multiplied 10m times, so even a very small improvement would have huge impact on the cost.
It would likely be similarly ridiculous to produce 5 widgets with a CNC. Sure, maybe doing it manually will take an hour per widget instead of five minutes with the CNC, but modeling, creating toolpaths, testing, and optimizing the resultant gcode would likely take more time that just doing it the "inefficient" manual way.
More generally, it seems like it's almost always worthwhile to preserve "the old ways", at least in some form. We don't need our entire workforce of machinists to be able to hop on a manual lathe and knock out parts precisely and efficiently - but if we don't have some that can do that, we're stuck with processes that are extremely inefficient for some jobs. In machining, there will always be a place for someone who specializes in fully manual work. There will always be a place for someone who is an expect in operating and supporting CNC machinery. Now there's also a place for people who are proficient enough in both areas to reliably know which process is appropriate for a given job.
It is almost always faster to use CNC in all cases unless what you are machining is incredibly simple.
Manual machining is likely most used in "unit of one" where the thing is big as large CNC machines are ferociously expensive.
> Am I arguing that we should throw away our computers and go back to slide rules? Absolutely not! Some problems can only be solved by computer simulation--because we really do not know enough to solve them any other way. > But, most design problems can be solved with simpler, less expensive, less time-consuming methods and tools and more experience and knowledge of basic principles. > wasting time with tools that are not appropriate for their jobs
I'm sure the CNC space also has the "next hot thing" that in reality is less efficient (time, materials, process) than older methods, or a method using existing techniques.
There were a chapter about that at the end of the textbook for my digital logic class at Caltech in the early '80s. The chapter was called something like "The Engineer as Dope Pusher".
It gave an example of clothes dryers. The way most clothes dryers worked at the time is that you told them how long to run and how hot to get. The how hot to get part was a simple selector switch. The how long to run part has handled with a simple mechanical timer. You turned the dial until it pointed to the number of minutes you wanted on the label, started the dryer, the timer ticked down, and when it reached zero the dryer stopped.
Those timer mechanism designs were several decades old. They were mass produced, very reliable, very cheap, and when one did break the repairperson could easily replace it. If they didn't have the specific one for your dryer in their truck, or even one from the same manufacturer, no problem. One from a different manufacturer would probably work. The mounting brackets might not match but it was easy for the repairperson to rig something to make it work.
There dryers were extremely easy for users. Select temperature, turn knob to the time you want, press start.
But they are also boring for the dryer designers. So there were dryer designers out there, the author said, who were starting to design their new dryers with digital timers.
Digital was exciting. The engineer got to play with microprocessors which were new at the time. They got to design printed circuit boards, a power supply for the digital electronics, a display, a keypad for input. They got to play around with programming the microprocessor.
But to the consumer that digital dryer control wasn't better. It didn't offer any functionality that the mechanical timer interface did not. It had a much worse interface usually. It was less reliable. It cost more, and it broke the consumer was looking at a more expensive repair. That repair would probably take much longer because the repairperson probably would not have a new controller in their truck
The point was that the engineer should not let their desire to play around with new and fun things take priority over delivering the best solution for the user.
The engineers that a young engineer was likely to seek mentorship from and who would be put in a position to mentor young engineers might be among the best, and so I have no doubt that the author did mostly interact with people that fit his description, but now that he is the experienced engineer / manager he is interacting with the worse engineers, the ones who need attention. As the squeaky wheel gets the grease, the bad engineers will require the most time and management effort to accomplish what good engineers can do without a lot of management / senior engineer time, so from the perspective of a senior engineer most of their time is spent with the worst engineers in their organization.
What I am very confident of, however, is that engineers aren't on average worse than they were back in the good old days.
Modern engineering degrees focus very strongly on use of tools, and contain a modest amount of first principles, and a an almost trivial amount of calculus. A engineering student could do well today with insufficient knowledge to understand the course their seniors undertook. The modern approach is a different way of doing things, with advantages, but not entirely superior.
Where did you go to school? There is (and always has been) a huge difference between what an engineering program at a top school and at some 3rd tier school require of their students. I think you probably went to a fairly competitive program and are comparing what was expected of you and your peers to what is expected of someone to get a degree from a noncompetitive school.
Here's one of several amazing videos from SpaceX simulations. (There are more, but I don't have the link to the others)
I bet some other automakers are probably doing something like this but I don't recall anyone talking about it at any conference yet.
The digital twin model is just a data model. Advanced simulation could be considered AI, but that border gets fuzzy with "just the same math everyone has always done, with more compute."
Source: the one Tesla that i've test driven had a crooked left rear door. Straight from the factory.
Nobody in congress or the senate gives a crap about if the SLS achieves anything, as long it keeps paying for jobs in their home state. Even senior leaders at NASA hate the SLS, and the fact that it hamstrings into using ancient technology that was difficult to use, even before everyone with the knowledge to operate it retired.
NASA would much rather be developing new rocket technology, rather than painstakingly rearranging old rocket technology. But doing that would risk Apollo era jobs, so instead we have the SLS.
He spoke about a project from the 2000's looking to apply an artificial neural net to a medical diagnosis problem. What they did was spend many years of work with domain experts to identify the best features for the net to use. The professor then proceeded to explain that nowadays feature engineering approaches became so much more powerful, that significantly better results could be achieved in a more recent project much faster and without almost any domain expertise.
Except, you know, for the expertise that generated the data in the first place.
It can be argued, since we don't know the ultimate cause of the laws of our universe, that we also rely in abductive reasoning and guide ourselves through models created by correlations based in our experience. But that has happened through millions of years of evolution and we still don't know how to build AI supervisors that can challenge that.
I was pretty disappointed by the credulous acceptance of that nonsense on HN, and the arguments used to rationalize it.
I looked up the author, who turned out to be a ski instructor.
Not that I mind, I don't care about karma. I just found it disappointing.
Contribute -- that's all one can continue to do.
HN is a jewel.
We did lots of experiments, made lots of charts, did lots of curve fitting, and for the first few months were required to use a slide rule instead of a calculator. This was explicitly because (a) we would have to track the magnitudes ourselves and would develop the ability to “sanity check”, and (b) we would be forced to keep our calculations within the same realm of precision as our measurements (mostly made with a ruler).
For me, those were valuable and persistent lessons. There may be a better way to teach them today, but it worked well back then!
Well, yes. That's what "AI" is about: Create some, very complex, generic model and hope that it can encode the problem at hand well enough. Then do a parameter estimation, e.g., from real-world data. Voila, you got yourself a "model".
When I first came in touch with machine-learning engineers, I was dumbfounded. They talked about models all the time and did so in a very smart manner. But not a single one could connect their "model" to the domain at hand. They didn't even understand the question.
The price of collectable cars is also affected by the age of the collectors market. Prior to me it was all about Model-Ts, old '30s era etc that I would see on the collectibles TV shows. GenX was after '60s era big body American muscle. Millenials are collecting 80s era box Chevys. The price of those early Ford Model-T, as an example, has declined because the collectors are too old. And anyone born after WW2 has little nostalgia for them.
Now I'm starting to see '80s Mercedes-Benz 300s at car shows. And the kids are dressing in 80s and 90s fashion, again.
There is no deep meaning to collectibles market. Owning a slide rule was fashionable until they were not. Classic cars, vintage clothes, and comics are basically the same.
Over the course of a two year period all operational and development data (since 1980) was fed into a model with all the records of maintenance and issue.
IBM came back and said, hey all these issues correspond to this parameter “EOT”… what’s that?
EOT stands for “Engine Operating Time”. The insight provided by this model was essentially useless, and their contract was canceled.
While ai is very cool, and interesting I think what the author is really saying is “AI” is really naive optimization where the the implementation is really only as good as the practitioners application knowledge.
Let’s not forget that at the end of the day Neural Nets are really just overfitting data
The way engineered solution go would be:
A) Simulated systems using equation with exact solution or perhaps numeric approximations of the exact solution equations. This combined with principles like conservation of energy allow to talk of the long term behavior of a system. Lots of large bridges were built with pencil-and-paper math before computers.
B) Simulated systems. Things like finite element analysis of car crashes. This allows prediction but not very long term prediction of system behavior. This is the easiest and most reliable way to build a bridge.
C) Approximating systems using only data and deep learning approximations. This lets you do things that A & B can't do but these generally don't do reasonable prediction in any significant timeframe. One could imagine that Dall-E can't design a bridge you'd be confident of walking across.
Not exactly the point of the article but I don't see how this follows. All this is saying is that the price of a collectible item, slide rules specifically from the WW2 era, have fallen.
Collectibles change in price regularly, for plenty of reasons. On the other hand, an engineer or educator who just wants to use slide rules may not care about the specifics of when they were manufactured. The slide rule I purchased on eBay 14 years and 4 months ago as a teaching tool was $6.99 with shipping, and if anything prices appear slighlty higher now even after adjusting for inflation.
I don't know what the demand is for slide rules, and I assume it isn't astonishingly high, but I disagree that inferences can be drawn from the price of items valued for their history rather than their function.
Lies, damn lies, statistics, and computer models.
https://www.nasa.gov/centers/ames/news/releases/2004/antenna...
"Claims on these antennas typically have performance characteristics that violate the physical laws we work under."
Savage indeed..!
But it was already optimized?
> Really, try building one, let alone manufacturing them.
...the bent wires they demonstrate by showing off photographs? And you can tell the computer to optimize for a certain amount of inaccuracy in each bend.
Individual humans do not have the physical ability to not be lazy and irresponsible. In groups, any of these dynamics are amplified.
If humanity is the peak of intelligence for the universe then there's no hope for anything.
Ideally, I'd like one that is as flexible (in application) as possible, durable, and at least decently attractive sitting on my desk. Neither price nor size is a primary consideration for me, but I'd like to buy only one if possible.
And Read Asimov's book on how to use a slide rule https://www.sliderulemuseum.com/Manuals/M220_AnEasyIntroduct...
It's a fascinating instrument, and a lot of cleverness is involved in the choice of scales, plus precision manufacturing. Asimov will show you how to make your own simple slide rule.
Slide rules work because of One Weird Trick -- Addition via sliding one member across another. It's just a question, then, of WHAT one is adding (or subtracting, which is just negative adding). do have fun, I have a small collection, because, you know, nerd.
In terms of versatility, go for slide rules with scales that compute general-purpose functions (circular or hyperbolic functions) rather than special-purpose functions (feet to meters, Celsius to Fahrenheit, compound interest, horsepower to kilowatts). Also, get a duplex rule, not a simplex, since the cost difference is no longer important. And maybe go for a fairly large one; that extra half-digit of precision extends the rule's usefulness to a lot more calculations.
The Slide Rule Universe begs to differ!
https://www.sphere.bc.ca/test/sruniverse.html
Plus, the site is GeoCities Pretty :-)
[Edit: Fixed typo]
With the exception of the part about willing to pay over $50, I can say we are not quite all dead.
Yes. Hopefully those will be minor effects and can be corrected two more papers down the line.
> I am sure that his engineers also use simulation, because as I said, that is what engineers do these days, but my guess is that Musk's executive insights have successfully minimized that in order to save huge amounts of time and money.
My title these days is roughly equivalent to what most people here seem to mean when they speak of "staff engineers". Granted, I'm relatively new to the title, but I feel like I've been approaching problems like a staff engineer would most of my career (~15 years).
I have no idea if the author's guess is correct about Musk, but my own experience tells me that when solving a problem, many people get stuck on trying to accurately estimate how much effort/time/money a given solution would require. Whenever I find myself analyzing a problem, I follow a set path:
1. Brainstorm potential solutions, without regard for how wild they might appear.
2. Roughly outline the potential positive and negative impacts of each - i.e., find the "upper and lower bounds" of each solution's impact
3. Classify the potential solutions into rough categories, by identifying the "decision points" where work toward each solution no longer also progresses toward the other solutions. This builds an informal conceptual "decision tree"
4. Choose what path to take immediately. Often, all of the potential solutions require or would benefit from the same groundwork. If so, no decision needs to be made yet.
5. Once I reach a "fork in the decision tree", refine my estimates of each solution only as much as is necessary to determine that one path down the tree is preferable
6. Continue this process until the solution ultimately presents itself.
I will say that this approach has had mixed results for me. In some environments, I feel like not being able to provide more accurate estimates for all options has led to leadership seeing me as lazy and impulsive. My time at those places has been short and not very enjoyable. In other environments, I've built enough trust with my colleagues that they generally trusted my judgement. My time there has been longer on average, and much more fulfilling.
As I've matured as a professional - and as a person - I've increasingly made the effort to explicitly state the thought process that I use to my peers. I accept (and even seek) disagreement. When I find it, I try to set my perspective aside and focus on understanding the process through which they arrived at their positions. In all cases, this has been because one of us was operating under a starting condition that wasn't shared. _Usually_ this has been a more junior person missing something due to not having encountered it before, but not always. When I'm right I try to be gracious about it. I'm wrong I readily admit that and then go the extra mile later to recognize the person who led me the right direction, preferably by quantifying the impact of their perspective: "We expected that the solution we were pursuing would have taken two weeks to implement; the solution presented by so-and-so reduced that to three days."
> Over-simulation is a issue in many of our industries, and I think it is one of many reasons that our standard of living has gone down over the last six decades.
I don't know that I agree with this statement at all. Regardless of whether or not it's true, the premise of the article as a whole remains valid.
> Why am I even asking these questions? I have lived long enough to know the answer to all of them. Yes! If foolishly placing faith in artificial intelligence is the great existential filter implied by the Fermi paradox, then we may be about to filter ourselves out of existence. Even if it is not, we may further bankrupt ourselves in more ways than monetarily while looking for something to do the thinking for us that we are too lazy and too irresponsible to do for ourselves.
I totally disagree with this conclusion.
AI is just another tool, and knowing when to apply it will be the difference between efficiency and inefficiency. "Placing faith" in a tool is not something I would say that I do. In fact, I don't believe that a person can have "faith" at all - only "convictions" - but that's a conversation for another time... :)
I'm not sure that I entirely agree: I imagine that most people are still able to gut-check proposals, but that the simulations are required to placate naysayers and to check compliance, regulatory, and process checkboxes.
so author is doing the the same thing with reasoning that they complain about in engineering.