Computing in Mechanical Engineering?

[CGUE]

I ask all Mechanical Engineers, if you do use a computer programming language to aid in your problem solving and work, which one do you use?
I use Visual Basic For Applications (VBA) which is integrated with Microsoft Excel 97 and onwards, but my university recommends a proper computing course which uses C as a programming language.
(I'm a first year by the way.)

Personally, I think we have moved on from the days of slide rules to now electronic calculators so I find C less interesting and much more difficult to grasp and I find using software such as Microsoft Excel (along with VBA) much better to use due to its popularity, graphical user interface and capabilities.

Spreadsheets aren't just used for financial purposes!

 

[caslav.ilic]

I ask all Mechanical Engineers, if you do use a computer programming language to aid in your problem solving and work, which one do you use?

Of the general-purpose programming languages, I use C/C++ (managed to avoid Fortran most of the time). Of the scripting languages, nowdays Python (formerly Perl). I somehow rarely get into pressing need for specialized mathematics stuff, but here and there it was Matlab (or Octave) and Maple.

Spreadsheets aren't just used for financial purposes!

I consider spreadsheets horrible hellspawn that has befallen unwary engineers, an improvement on hand-held calculators in the same way in which a diesel-powered titanium-built difference engine would improve on a slide rule.

I assert that teaching spreadsheets to engineering students cripples their computational abilities, and should be treated as professional offense.

Yes, I'm having unusually strong opinion here.

(I make no such claim for spreadsheets in other fields, for which I've no knowledge of their particular needs.)

--
Chusslove Illich (Часлав Илић)

 

[Q_Goest]

I've been an engineer for 20 years. Used Fortran, C++, Basic, home-grown programs, Excel and have some limited Mathcad experience. Of these, Excel is my favored program for basic stress analysis (ex: on flat plates, beams, springs, etc...), fluid flow (ex: through pipe, valves, other restrictions), thermodynamic processes (ex: determining fluid conditions in cryogenic systems, steam systems, heat exchangers, other process equipment), heat transfer and even some fairly complex dynamics analysis (ex: I've used for compressor and pump valve dynamics). Also, there are add-ons for Excel that can broaden it's capability (ex: NIST REFPROP).

Engineering in industry is very focused on cost, and spreadsheets make it very easy to do almost any repetitive type analysis quickly while also providing a means of documenting information. There are things it can't do that specialized programs are needed for such as FEA, piping networks (both stress and flow), CFD, etc... but those programs are often so complex that companies have only a handful of engineers who specialize in using only one of them such as CFD.

Perhaps the best reason to use Excel is because (almost always) you have to write the program yourself, and if you don't understand how to do the analysis, you have to figure it out! The same can't be said for canned programs where all the programing has already been done.

 

[Mech_Engineer]

For solving all of my engineering-related analytical problems (that don't involve FEA), I use MathCAD. It's an excellent program in my opinion, and the Mechanical Engineering plugin package for it is invaluable. From calculating stresses to calculating heat flow to estimating electrical skin depth, even symbolically deriving beam equations, I've done a bit of everything in there and it has proven to be a very powerful calculation documentation tool for collaborating with co-workers.

In the end whatever you use is just a tool, and sufficient proficiency with any tool will usually mean you can solve the problem; but in my opinion Excel is a poor choice for engineering caulculations due to its nature- its basically a numerical financial program. Sure, its POSSIBLE to do pretty much anything in there; but having used unit-aware calculations, symbolic manipulation, and data anlysis in MathCAD, I won't ever try to solve an engineering problem in Excel.

Knowing programming languages like C++ or Java can be a stong skill for engineers from a problem-solving standpoint, and can be useful in understanding more about numerical methods of programs you might use. But, using C++ to solve an mechanical engineering problem is kind of re-inventing the wheel because you have to write the program, and then use it. Why not just use a program that already has the groundwork laid out, and you just write the equation and have it solved?

 

[FredGarvin]

I consider spreadsheets horrible hellspawn that has befallen unwary engineers, an improvement on hand-held calculators in the same way in which a diesel-powered titanium-built difference engine would improve on a slide rule.

I assert that teaching spreadsheets to engineering students cripples their computational abilities, and should be treated as professional offense.

Yes, I'm having unusually strong opinion here.

Curious. I'm not saying right or wrong. I must say that you are the only person I have ever seen with a bad opinion of spreadsheets. Granted, you put in the caveat that your field negates their purpose. I guess I'm interested in why you feel this way especially since a spreadsheet is simply a calculator. Having a bad opinion of spreadsheets is akin to not liking electronic calculators. If you have problems that can be broken down into finite differences without having too much of an affect on the outcome, what's the issue?

Personally, I agree with Q and Mech. Not only do they make the repetetive stuff easier, but they aid in documentation. I use MathCad but there are a few things that I just do not like about it. If my company had a license of Mathematica, I would use that. I haven't touched Fortran since college (other engineers at my company do use it though) and I occasionally dabble in VBA, especially for Excel. Then there are the specialized programs that I use daily.

 

[caslav.ilic]

[...] I must say that you are the only person I have ever seen with a bad opinion of spreadsheets. [...]

This is because I've followed somewhat of an unusual educational path for a mechanical engineer. Other people in my position usually went into fields where spreadsheets are unheard of, as using them would be totally out of question -- so they can't have a strong opinion on something that's nowhere near their reach.

[...] I guess I'm interested in why you feel this way especially since a spreadsheet is simply a calculator. Having a bad opinion of spreadsheets is akin to not liking electronic calculators. [...]

Quite correct deduction.

The only reason I don't have bad opinion of hand-held calculators as such, is that their introduction considerably predated capable enough personal computers. They were a revolutionary replacement to slide rules, and so have their place in history. Today, however, the only thing that makes my hair more pointy than seeing a calculator next to a computer monitor, is seeing a spreadsheet on the monitor.

This has the following background. During my high school days, the only place where we needed to crunch any numbers were Physics exams, and there, the calculator; however, at the same time, we had quite a hefty programming syllabus. It was in second year of university, circa 1998., that I first got into a situation where one would, if devoid of computer, need to make a tabulated computation on paper with a calculator. But, by then I had enough programming self-confidence to feel that just carrying such a computation onto computer (i.e. spreadsheet) is a gross underuse of general-purpose computing machines. So, I continued using calculator exclusively on exams, and accordingly kept spreadsheets at bay.

Some time ago, I tried to point out some crucial deficiencies of spreadsheets by posing a few higher level questions, not to go into gritty details.

--
Chusslove Illich (Часлав Илић)

 

[pantaz]

One big downside to VBA is it puts you at the mercy of Microsoft. I have experienced the pain first-hand. I created a relatively complex application in VBA several years ago, automating a tedious and error-prone process. Then the company "upgraded" to the latest Microsoft Office... and my app broke. No heads-up from MS that they were changing the API, no "backwards compatibility", just "CRASH".

 

[engware]

To All:

I have been practicing engineering for a while. Also, I have been dealing with programming for a number of years.

Way back, programming started with Fortan and BASIC.

In my opinion, if one knows one programming language very well, there is no need to fear any new/other language.

I do like MS Office very much. Before, in old days, plotting was very difficult. Today, that is no more the case.

I do like Ms Excel and its connection to BASIC and VBA. This is a great way to make spreadsheet calculations powerful and reduce potential error when working with spreadsheets.

My suggestion is as follows: be open and try to expand your knowledge base when possible ...

Today, sky is the limit when it comes to resources and their capabilities and presenting and sharing your work with others over the Internet ...

Good luck!

Thanks,

Gordan

 

[FrogPad]

Just out of curiosity, does Excel have some type of mathematical library?

As an example, how would you use Excel to solve differential equations? I guess one could setup something simple like a fixed step Euler, or Runge-Kutta method... but crap, I can't imagine a multistep method with Excel.

 

[engware]

FrogPad:

Actually, it is possible to use MS Excel for Euler integration etc.

It get clumsy, but it is possible.

One neds to use BASIC or VBA by creating functions/subroutines. Such routines are connected to cells in a sheet.

By playing with cells and routines, solution is possible when dealing with integration -- plots are easy to get setup displaying the input and output data ...

Thanks,

Gordan

 

[caslav.ilic]

[...] One neds to use BASIC or VBA by creating functions/subroutines. [...]

Given that -- I suppose -- VBA too can be shown to be Turing complete, you can of course do anything with it (albeit not in practical sense, cf. the questions in my linked message). However, once one has moved to VBA for any decent computation, then he had unwittingly 1) demonstrated that spreadsheet is actually crap, 2) chosen probably the poorest of the proper-like replacements for it (VBA as compared to... any other scripting language).

--
Chusslove Illich (Часлав Илић)

 

[engware]

Hi there:

Yes, you are right.

But here is the catch.

With MS Office, either BASIC or VBA come for free. MS Excel provides easy environment to work with and files are very small. Today, everybody has a copy of MS Excel on his/her computer. Therfore, files can be exchanged quickly.

Having created BASIC or VBA routines in MS Excel, one can migrate to VBA.

VBA is not totally free and it needs to be installed as a standalone application. Sharing original VBA files is no longer easy, because people need to have a copy of it installed on their computer. Also, it is possible to provide fully operational VBA applications with a VBA engine, but now the things get complicated.

Actually, there are two Worlds -- MS Office and VBA. There are +s and -s.

In my opinion, please respect MS Office and MS Excel and take advantage of what they bring to the users. They are not perfect from the programming point of view, but knowing the good benefits, go ahead and work with them.

Actually, work with both Worlds -- it is to your advantage ...

Thanks,

Gordan

 

[FrogPad]

So how crazy of computations does one actually do with Excel?

• I mean FORTRAN kills for speed and cluster computing.
• MATLAB is quick and dirty.

I've heard C is used often... I guess it really depends on what is being calculated. But could someone give me an example of what would be done with Excel?

 

[Mech_Engineer]

It can help to look at the problem from an efficiency standpoint. Are you getting paid to solve the problem, or are you getting paid to write a piece of software that solves the problem? In the academic world this might get a little fuzzier, but in private industry it's all about finding the right tool (or person) for the job.

In most cases, it is cheaper for you and your company if you purchase software designed for your application. If you're spending your time writing algorithms to solve ODE's in Excel, or writing your own set of functions you use to solve complex non-linear system of equations in FORTRAN, you're re-inventing the wheel. Most mathematic calculation software (MatLab, Methematica, MathCad, etc.) can solve pretty much any complex problem with relatively few commands. Therefore you spend less time solving the problem and more time doing what you need to.

Sure, you can solve anything in a base-level programming language if you know what you're doing and given enough time. But, it probably isn't a good way to do it...

 

[engware]

Mech Engineer:

You should be encouraging people to do some work on their own instead of saying there is a black box and let's go with the black box -- that is not a good engineering approach ...

In my opinion, people should try something on their own no matter what the problem scope is. For sure use an off the shelf piece of software to help you out and be more efficient. I am not saying, let's reinvent the wheel, but let's make sure that the wheel is spinning in the right direction and there is a sanity test that was completed ...

In a long run, it is always good to have a set of tools developed on your own -- in general, off the shelf software ends up having some kind of a limitation ...

Thanks,

Gordan

 

[Mech_Engineer]

Mech Engineer:

You should be encouraging people to do some work on their own instead of saying there is a black box and let's go with the black box -- that is not a good engineering approach ...

Your opinion is contrary to efficient engineering practices used in industry. Engineering managers would rather purchase a properly supported mathematic suite (or other software package) as a tool for their engineers than have the engineers spend lots of expensive engineering time writing their own software to solve the problem. Period.

In my opinion, people should try something on their own no matter what the problem scope is.

Maybe that's ok for students learning the applications of numerical methods in college, but later on this is not an efficient use of engineering time. No matter what the scope is? Do you really expect people to try and write their own FEA or CFD software rather than purchasing COMSOL or ANSYS? What about a fully parametric solver for PDE's? Software to solve systems of equations in the hundreds? Sounds like a lot of time wasted to me... Unless your company is in the business of developing these algorithms, that's money down the drain.

For sure use an off the shelf piece of software to help you out and be more efficient. I am not saying, let's reinvent the wheel, but let's make sure that the wheel is spinning in the right direction and there is a sanity test that was completed ...

There's a huge difference between understanding an application and the intricacies involved, rather than writing your own software suite to understand it.

 

[engware]

Mech Engineer:

I do appreciate your reply and rational.

Thanks,

Gordan

 

[caslav.ilic]

You should be encouraging people to do some work on their own instead of saying there is a black box and let's go with the black box [...]

Your opinion is contrary to efficient engineering practices used in industry. [...]

Let's just not confuse counterparts here. From mechanical engineer's viewpoint, MathCAD is to be used in exactly the same capacity as spreadsheet (Excel). There is no reason to use both of them, one "for this" the other "for that".

Meaning, of course, that MathCAD is vastly superior to Excel. It's like a "graphical" Matlab ; one can also write algorithmic functions in it, loops 'n all, which perfectly interact with "ordinary" stuff. Having physical units from the ground-up is really nice too. I myself used it for a lot of university stuff, had to dump it near graduation only because it became too limiting -- too slow, bound to wrong platform, not tractable enough -- for my purposes (that was some 6 years ago, perhaps stuff changed since...) But otherwise, it was a good tool for single-person, non-intensive engineering computations.

With MS Office, either BASIC or VBA come for free. MS Excel provides easy environment to work with and files are very small. Today, everybody has a copy of MS Excel on his/her computer. Therfore, files can be exchanged quickly.

MS Excel (as one particular spreadsheet app) is less available than the workhorses I use or recommend, being two-platforms only. And not everyone has MS Office on his/her computer; I even witnessed an employee (probably a higher-ranked one) of a certain airframe manufacturer, bouncing a file sent to him by a colleague of mine, with note "no MS Office, provide in another format".

Then, as far as I've seen, in the view of heavy spreadsheet users, a spreadsheet app either has to be Excel, or it's useless. Spreadsheets = Excel. This is quite understandable, since due to poor basic concept of spreadsheets, one has to tie himself to a lot of "extra features" (i.e. patches to conceptual defects) provided by one particular heavyweight app. This further reduces practical availability of spreadsheets in general.

However, compared to other problems, availability of spreadsheets is of negligible importance, so I normally don't pull it out of the hat for bashing purposes :) But, you mention here something else in conjuction with availability -- exchange, i.e. collaborative work. This is where spreadsheets are disastrous.

I've yet to see a spreadsheet in wilderness that was developed by more than one person, and modifiable and maintainable by anyone else. At best, people other then the creator used it as a canned solution -- input numbers here, see results there, complain when it spews obvious nonsense. There is no practical way to develop a spreadsheet computation modularly and accountably by several people; no way to track history of changes, of who did what, when, and why. As opposed, this is normal and established practice with any proper programming material (Matlab's .m files amenable too), and can be performed with free and fully cross-platform tools.

Even the creator himself should think twice when modifying a few-month old spreadsheet. There are either no tools, or only very specific and very costly ones (i.e. extremely poorly available) for asserting spreadsheet's sanity over time. E.g. there is no provision for regression tests, in environment where introducing errors is extremely easy. Several reports on that:

http://www.cs.uiowa.edu/~jcryer/JSMTalk2001.pdf
http://panko.shidler.hawaii.edu/ssr/Mypapers/whatknow.htm
http://www.burns-stat.com/pages/Tutor/spreadsheet_addiction.html

--
Chusslove Illich (Часлав Илић)

 

[engware]

caslav.ilic:

I do appreciate your reply and rational.

Thanks,

Gordan

 

[engware]

To All:

Apparently, being engineers and practicing engineering for many, many years, there are different views and opinions on the same subject matter.

Therefore, please do it as it suits your preferences and ways of doing business.

Thanks,

Gordan

 

[minger]

I use FORTRAN everyday. I'm currently in the CFD business, and I find that any code that we use, or write is in FORTRAN. Today's FORTRAN is object oriented, making it completely comparable to C++.

However, I must agree with most in the value of spreadsheet programs. One can quickly examine a particular problem, and can even trust the solution so long as the level of precision required is low (think single precision). The quickness of graphing is also valuable.

Personally, I don't see much use in Matlab. If I have to code something, then I'm going to write it in FORTRAN where I can guarantee myself the precision that I require, and have the code run exponentially faster. Aside from vector/matrix operations (which I can easily get libraries for for any programming language), I'd rather go straight from Excel to hand-coded fortran.

 

[engware]

minger:

I do appreciate your input.

With all the respect to other people expressing their views and preferences, it makes me feel somehow better now -- I am not the only one with this kind of thinking ...

Thanks,

Gordan

 

[FredGarvin]

There's a huge difference between understanding an application and the intricacies involved, rather than writing your own software suite to understand it.

Exactly. I think this needs to be written in stone in every college on the planet. This, I think, goes to the crux of the issue here. Any software tool can be a plus or a minus. It will be a plus if we as engineers are smart users and understand the limitations of applicability and the results presented. Being a smart user also means you should be able to back up an analysis done with any software with some hand calculations as a form of verification and not blindly accepting the output.

 

[FrogPad]

I use FORTRAN everyday. I'm currently in the CFD business, and I find that any code that we use, or write is in FORTRAN. Today's FORTRAN is object oriented, making it completely comparable to C++.

However, I must agree with most in the value of spreadsheet programs. One can quickly examine a particular problem, and can even trust the solution so long as the level of precision required is low (think single precision). The quickness of graphing is also valuable.

Personally, I don't see much use in Matlab. If I have to code something, then I'm going to write it in FORTRAN where I can guarantee myself the precision that I require, and have the code run exponentially faster. Aside from vector/matrix operations (which I can easily get libraries for for any programming language), I'd rather go straight from Excel to hand-coded fortran.

I originally started working on this problem that required a very hefty amount of computing power. I wrote the original code in MATLAB and it was slow, I then used a MATLAB analysis tool to find the bottlenecks in the program, and rewrote the code... it was much faster.

Things were still slow as hell, so what did we do? Wrote it in Fortran. Now the routine was cooking, like 2 minutes to 10 seconds (note that this routine was to be run thousands and thousands of times).

So why did we write it in MATLAB first? It's graphing ability is awesome. You can visualize data so easily. I am a novice when it comes to Fortran, so I don't really know of libraries to plot with. But MATLAB out of the box is nice, it works well, and it really has a lot of awesome libraries written for it.

MATLAB also allowed us to write interactive software (very quickly) to really play with the model that we had.

But, I can see where you are coming from. When I jumped over to use Fortran it was not too bad. Using the IMSL library made it especially nice. I could see if I had a few years experience with Fortran, that maybe I would only use it. However, I don't have the experience and using MATLAB to prototype really does work well.

 

[Cyrus]

As a controls person, I use MATLAB and only matlab. It is GOD.

 

[redargon]

suggestions

Does anyone have any online sources where one could begin to learn different tools? Like tutorials or sample code to get me started. I used Matlab back in varsity, but now it seems apparent that not everyone agrees on what is best. Also, I don't have access to "specialised" programs like Fluent for CFD or even Matlab for that matter. VBA is readily available though as it comes with excel, for example, anyway. I was interested to see it can be used for engineering applications. How? Where can I learn? I feel like a kid that just found out his old dog (excel, in this case) can do new tricks (VBA) and I want to learn how to make him do the tricks I want him to do. I have some basic programming knowledge, like all engineers do, I guess. I did some courses in Turbo Pascal, Java, Matlab and experimented with Assembler for microchips. Looking forward to getting my teeth in

To be more specific, right now I am trying to model fluid flow in a pipe system, and at the moment I just have huge tables with variables and equations floating around and charts to graph the results (really basic and messy stuff). My company doesn't have CFD tools and is not about to buy me a license for one short term project, but they do want some sort of results. I would love to be able to show them visual results, but graphs and numbers would be great too. How can I learn to use my humble Excel spreadsheet optimally.

I'm open to sugesstions, thanks in advance.

 

[Jupiter6]

So how crazy of computations does one actually do with Excel?

• I mean FORTRAN kills for speed and cluster computing.
• MATLAB is quick and dirty.

I've heard C is used often... I guess it really depends on what is being calculated. But could someone give me an example of what would be done with Excel?

I use Excel for everything except for matrices and diff. eqs. Then I use MATLAB. Though it is possible to do diff eqs in excel, I don't bother. What no one has mentioned is the SOLVER in Excel kicks ASS. Let's say you need to choose a bolt size based on assorted loads and fall within a factor of safety. Make the spreadsheet, then backsolve for the bolt size. 10 minutes in Excel. With Matlab it would take an hour because you'd have to work the problem backwards on paper first. Excel imports text files well too. The craziest thing I've seen excel do was solve a linear equation with 5 variables using a prony scheme. Sometimes it would take up to 20 minutes. Some guys even do FFTs in excel. But like I said, Matlab is tops for diff. eqs. and laplace stuff in my book. MATLAB is C based.

 

[engware]

redargon:

Here is an MS Excel sample case dealing with combustion.

If you have any questions, please let me know.

Thanks,

Gordan

 

[stewartcs]

Mech Engineer:

You should be encouraging people to do some work on their own instead of saying there is a black box and let's go with the black box -- that is not a good engineering approach ...

In my opinion, people should try something on their own no matter what the problem scope is. For sure use an off the shelf piece of software to help you out and be more efficient. I am not saying, let's reinvent the wheel, but let's make sure that the wheel is spinning in the right direction and there is a sanity test that was completed ...

In a long run, it is always good to have a set of tools developed on your own -- in general, off the shelf software ends up having some kind of a limitation ...

Thanks,

Gordan

In order to actually use most of the software on the market, you have to know what is going on inside the software (to a certain extent). This where ones engineering education comes into play. Actual engineers already know the concepts behind what the program is doing. The program is just making the process faster and less error prone. It is pointless for an engineer to have to write a program to get an answer for a problem when there are countless "off-the-shelf" ones out there that work just fine that will certainly have more man-hours put into the development of it than anyone person would writing their own.

CS

 

[Cvan]

MATLAB is incredible. It is, in my opinion the definitive computational programming tool. Not as powerful as a raw programming language on the base levels, but far more solution-oriented.

Just my $.02

 

[Jupiter6]

I've yet to see a spreadsheet in wilderness that was developed by more than one person, and modifiable and maintainable by anyone else. At best, people other then the creator used it as a canned solution -- input numbers here, see results there, complain when it spews obvious nonsense. There is no practical way to develop a spreadsheet computation modularly and accountably by several people; no way to track history of changes, of who did what, when, and why. As opposed, this is normal and established practice with any proper programming material (Matlab's .m files amenable too), and can be performed with free and fully cross-platform tools.

I agree, everybody has their own style when it comes to spreadsheets. Excel does have a "track changes" feature which will keep track of who changed something and when. People rarely use this feature, but it is there. Even in my own spreadsheets, I can't always remember why I did something a couple months ago. So I've gotten into the habit of inserting comments into important cells.

 

[caslav.ilic]

[...] What no one has mentioned is the SOLVER in Excel kicks ASS. [...]

Har, har. Just waited for a mention of that one :)

Excel's solver is good, I'll even say "world class", in a certain sense. But there are two crucial problems with it. (Also, make no mistake, CAS tool like Matlab, MathCAD, etc. will contain such solvers without exception. And there are free libraries of such methods too, for use in custom codes.)

Firstly, while it uses an algorithm which is one of the several well-proven for general optimization, all algorithms of that kind (gradient-based) suffer one theoretical boundary. A boundary which, unfortunatelly, frequently gets lost to a practicing engineer. This boundary is the following: gradient-based methods can find only a local optimum of the goal, i.e. such which is optimal to any near-designs (those obtained by slight variations in design parameters), but without any guarantee to global optimality. Think of an x-y function plot where there are two "valleys" (or "humps"); gradient descent (or ascent) will give you one of them, depending on the starting point, without clue to the existence of the other, which may be better. Excel Solver's users see this effect when it gives different results with different initial cell values. Furthermore, if the goal to optimize is non-smooth (think of that x-y plot with a break in it, e.g. x-segment of undefined y-value), gradient descent methods guarantee exactly nothing for the final value they provide.

Secondly, while Excel's solver can be applied to anything that provides a value to a cell, like some complicated external add-on, thusfar I've seen in the wild, it was always used on the custom-made computations made in basic Excel itself; the number of design parameters ("by changing cells...") was usually single-digit at anyone case. This all amounts to an unusual observation: in the time Excel's Solver will take to crunch the problem, if it were written in e.g. Fortran instead, one could brute force it, do a complete parameter sweep -- the only optimizing "method" guaranteed to give global best solution. (Back to x-y plot, brute force means: subdivide x-axis into problem-significant division -- e.g. airplane wing span into ~10 cm segments -- compute for each x, pick best. Don't think now "But I can do that in Excel too!" as I'm speaking of, say, 5-parameter combinations, each varied for every other, and a worksheet that will take a second or so to evaluate for one combination.)

In my masters thesis I was faced with exactly the problem described above: multi-parameter, multi-optima goal function, and non-smooth at many segments (and aircraft conceptual design computation, on basis of Raymer, Roskam, etc.) I was to thoroughly test a specialized optimizer, having 5-figures/year (or was it 6 for companies?) license fee, on this simple, but conceptually significant problem (the real one would have CFD/CSM simulations in the background, for high-fidelity results, but still displaying same general behavior).

And then I wondered: can I actually know what the best solutions were beforehand, so that I have a hard point to benchmark against? The answer, if I used Excel (or, frankly even Matlab or another CAS in this case) would be plain and simple -- no way. However, I estimated that I could write the basic computation (one set of params in, result out) in C for the same or less time it would take me with anything else (after all, there was just one way to handle these packs of formulas); and that afterwards I can brute force the problem in several hours using 8-16 CPUs (of which there were plenty to harness around the university labs). Using a scripting language (Perl at that time, today I'd use Python), it took me a week to patch a script which will read XML setup of the computation -- with freely exchangable subproblems (e.g. different powerplant, drag models), physical units, nested parameter variations, consistency guards -- and use it to build out of the basic C code both the evaluation model for the 5-figure optimizer, and an MPI-parallel brute force sweeper for getting to the benchmark hardline.

In short, in less time than it would take me to wade through columns just to set up a spaghetti-like computation in Excel, I had a safe-guarded, readable, modular, and maintainable computation, and unlimited-CPU brute force sweeper guaranteeing global optima. In the end, it left me with spare time and means to play around with what-if scenarios, like "how about if a/c was hydrogen-fueled?" :) (I should also note that the call of the Dark Side for the user of the 5-figure heavyweight was not small -- it had a "charming" feature to happily accept an Excel spreadsheet as an evaluation model...)

--
Chusslove Illich (Часлав Илић)

 

[FredGarvin]

I consider spreadsheets horrible hellspawn that has befallen unwary engineers, an improvement on hand-held calculators in the same way in which a diesel-powered titanium-built difference engine would improve on a slide rule.

I assert that teaching spreadsheets to engineering students cripples their computational abilities, and should be treated as professional offense.

I definitely see that you are very well versed in the pluses and minuses of the various methods for computing. I definitely respect your opinions on this and other matters. However, I still don't see anything that supports such a strong assertion as what you said previously.

I see this as a perfect example as you being a smart user and understanding what tools work best for your situation and needs. You have proven that spreadsheets definitely do not suit you for a few good reasons, however you don't really present anything to refute the usefulness of them to the rest of the engineering community.

 

[caslav.ilic]

[...] you don't really present anything to refute the usefulness of them to the rest of the engineering community.

There are degrees of usefulness. Given that spreadsheets are heavily used by engineering community, how could I, or anyone else, present an argument that refutes their utility in total? Is a slide-rule useless, is a hand-held calculator useless? This was not my intention; more specifically, I never try to convince current hardcore spreadsheet users to stop using them. My intention is a subversive one: steer people, young people, waxing and waning in their choice of tools, away from spreedsheats. E.g. in the case of OP, if after reading mine (and others') arguments he becomes more favorable towards taking a "proper computing course", and later tries to apply the knowledge obtained there to tasks in other, programming-unrelated courses, I will have achieved my goal.

On the other hand, if we base conclusions on widespread of use, one could make a similar "utility" claim for Cobol, the programming language once favored in a certain field. One key point in its design was to make it user-friendly, such that it paralleled how people would do things "intuitively". A lot of Cobol code was written in its heyday, and a huge pile of dark-matter Cobol code is still pushing numbers today. And the field is -- yep, finance. How could one then make too a strong claim of Cobol's ill-effects on programmer's abilities? Yet, http://www.tech-faq.com/cobol.shtml (my statement on spreadsheets is a toned-down, inelegant paraphrase of Dijkstra's words); such statements made newcomers think twice before reaching for Cobol, gradually phasing it out of use.

--
Chusslove Illich (Часлав Илић)

 

[Jupiter6]

On the other hand, if we base conclusions on widespread of use, one could make a similar "utility" claim for Cobol, the programming language once favored in a certain field.
--
Chusslove Illich (Часлав Илић)

LOL. I took classes in turbo pascal, fortran and C but I don't think I've ever met anyone who used Cobol. I understand your disdain for spreadsheets but I think a lot of that resulted from your graduate work. Excel can be a wonderful thing depending on whos using it and I have seen some wonderful things.