Modern math

Clifford Heath wrote in news:ni0bE.35066$ snipped-for-privacy@fx44.iad:

You're an idiot. Did you run it?

It is full color. Unlike your piece of shit code.

This on the other hand, is awesome:

Wow... a total of six monochrome characters.

Mine also polls the array size of the terminal it is run under and operates the mandel array within that. Your POS doesn't get anywhere close to having ANY sophistication.

Lame. No... Very lame.

A complete nightmare--poorly specified, and next to impossible to debug any nontrivial application. That was my conclusion when I last tried to do any real calculation on a spreadsheet--VisiCalc for DOS 1.x, circa

1983. I still have to look at various people's .csv files, and occasionally use a spreadsheet program to do that. But not usually.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC / Hobbs ElectroOptics 
Optics, Electro-optics, Photonics, Analog Electronics 
Briarcliff Manor NY 10510 

http://electrooptical.net 
http://hobbs-eo.com

The design was mine. I was working summers in the physics lab at the University of New Orleans, for 50 cents per hour.

The design was all tubes, which made sense since the counter used five circular-electrode gas-filled dacatron tubes. They were cool.

experiment, and a tube-based kilovolt pulser for microwave spectroscopy.

I learned a lot.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

My wife is reading a book written by an ISS astronaut. It sounds really gross. He complains about the pointless make-work "science" experiments too.

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

There are a very large number of titles you are NOT! LOL

Actually, I think the most fun I ever had was testing array processors. Th ey used ECL gate arrays and at the time ran faster than anything other than a Cray. Some of the machine was very complex with schematics that had box es with inscriptions that read "who knows what this does". lol

It was fun though and ECL was actually easier to debug than TTL because man y problems could be found by analyzing the voltages... or something like th at. Since every line had terminations it showed a lot of faults more clear ly. I don't recall the details, but it was fun. I got pretty good at it u ntil they asked me to design an I/O processor board. That was fun too, but I got a lot more managing which is never fun. I learned a lot about some of the bit slice sequencer chips which is what they used in the I/O boards. In order to add a very complete self test capability I extended the assem bler and got yelled at for that. Jeez!

Rick C.

If you think using $COLUMNS and $LINES, spitting ANSI escape sequences, and writing yet another procedural implementation of Mandelbrot is sophisticated, there's really no hope for you. JL seems to share your idea that only procedural code is really code.

The point about Excel and SQL is that they are pure functional languages; they describe the result to be computed and let the machine figure out how.

Clifford Heath.

John Larkin wrote in news: snipped-for-privacy@4ax.com:

Yet you were touting your capacity to make one as being so much better.

I plot actual metrology data.

John Larkin wrote in news: snipped-for-privacy@4ax.com:

Well, you lost something in the unending learning arena.

I learn every day and I do not diss the rest of the world, and I never claim to have learned it all.

Dopes like you bring out the worst in me. Because you stopped learning decades ago when you thought at some point that you knew it all.

Clifford Heath wrote in news:9S4bE.86337$ snipped-for-privacy@fx13.iad:

You really are an idiot. There are a few ASCII CLI mandelbrot code scripts out there. They are in no way meant to compete with real, high resolution graphical mandelbrot generators, you stupid f*ck. But as bash scripts go, it is a pretty good array generator.

You have no clue what "my ideas" are.

Dumbass... It is not the best mandel code. It is the best ASCII generator.

I have seen some very high resolution deep mandelbrot zooms.

You are an idiot to think that I was talking about the mandelbrot code.

It is a bash script.

Write a better bash script based ASCII mandelbrot array, asshole.

I was making an imaginary number joke.

You are an imaginary number joke.

SQL? Gimmie a break, dork.

Solver from the addins is more general but even then it doesn't always converge on the right answer unless the starting guess is very good indeed (at least with more difficult non-linear fitting problems).

--
Regards, 
Martin Brown

It is a powerful tool and the important thing about it is that it is a completely different way of casting the problem to a conventional programming language so that it has very different systematic errors.

Fencepost errors are extremely rare in well constructed spreadsheets but are incredibly common in procedural languages.

Excel is quite handy for looking at modest (by today's standards) experimental datasets - although many universities get a discount on IDL plenty of businesses choose other cheaper alternatives including Excel or free clone implementations of IDL8 or GNU's GDL which is similar.

It started out from a VAX/VMS Fortran heritage a long time ago.

There are other options like MATLAB that sit in between too. It really depends on what sort of problem you are trying to solve which tool is the most appropriate for a quick look see at an idea or new algorithm.

Some of them have much steeper learning curves than Excel.

--
Regards, 
Martin Brown

My first exposure to spreadsheets was in the early 80's as SuperCalc on a Z80 CP/M with a whopping 64k of ram. It was better than VisiCalc.

It is fine as a scratchpad testbed for looking at someone else's data with minimum effort. I also used to believe it was impossible to code reliable applications in it until someone commissioned me to do one.

It is possible and the same code with minor modifications had been running since Excel97 - MS broke it horribly with XL2007 when various serious bugs were introduced in their premature out of the box version. The one that caused me the most grief was the race condition inside their new implementation of drawing graphs.

They also broke the previously correct polynomial fit routine in the charts to make it agree with the faulty implementation in MATLAB :(

These things were eventually fixed but for a while the solution was to add delays inside the charting routines so that the axes scales were defined before it tried to plot the first points on the graph. It was a particular problem for X-Y charts of the sort scientists tend to use.

--
Regards, 
Martin Brown

Yeah, but... if there's no extraordinary attempt to document the process, there's scope for surprises. My pencil notes have numbers, AND units, and some ancillary notes on equipment, conditions, etc. A list of numbers is NOT enough, I want ALL that info together in one place. I mix metric and imperial measurements, and a spreadsheet from a few years ago might, too. Proofreading spreadsheets is necessarily more of an annoyance than any alternate data-record scheme.

Yes, I'm old-fashioned. I've learned to keep a hardcopy of everything important, and if someone else wants 'the data' they can have a copy. The original stays in a bound book, or a very rigid format (with embedded labels and version info) file.

whit3rd wrote in news: snipped-for-privacy@googlegroups.com:

Huh? I am approaching a lab bench with a SMPS to test. I already know what we specd it at in design. My goal is to gather data from an energized unit in loaded and idle modes. So I already know what 'scales' or 'ranges' need to be covered by the chart I wish to plot by hand during the testing. With those numbers in mind I can construct a spreadsheet with no data and a chart printout that has the scales and axis names on it, just like I would if I were laying it out onto a piece of... wait for it... graph paper!

That printed, BLANK (data point wise) paper is where I plot my test data points AND write my notes, etc.... all in one place! Imagine that. I have yet to enter a single bit of collected data into it and it is already proving to be useful.

That would depend on just how good your spreadsheet guy is, and just like a programmer, he needs to be able to comment the whole process to you, either in the sheet code itself or in the meeting you have where he explains its operation to you. At some point you become better at using the tools as well.

I can use a spreadsheet to create a printed form. Let's use a product traveller as an example. The spreadsheet is far better than Word for this as I can make pixel by pixel adjustments to the printed product from a spreadsheet layout, and those spaces I place for the addition of collected data can actually be used for that data.

I have spreadsheets that are meant to be printed out and hung on the wall for each week's ESD equipment testing. Every technician has to test their gear every day and it also allows one to track and monitor lab humidity levels, an important ESD abatement consideration.

This spreadsheet has worksheets that are for print only where all of the data, such as the employee listing and date and lab information which are mutable from lab to lab, are gathered from and pasted into the print job sheet from another sheet. The user fills out the employee data and insures that the date is right, and prints out the ESD test sheet for that week. It has an add 7 function that allows the supervisor to print out future documents for subsequent weeks as the date field is not tied to the actual date.

There is a smal lab, letter sized landscape printed sheet, and a large lab, full sized tabloid print out for up to 63 employees.

Lab names and dates and employee lists are what are mutable.

It really is a good piece of work. I feel like giving it to the group to show you an example of what I can do at the simple, zero process level, with a spreadsheet.

I also use them to make banners and labels, etc. The per pixel adjustment capability allows me to lay out print jobs that cover entire label sets even better than the label makers' overpriced user softwares.

My test data sheets get developed as I develop the power supply design (in that example). Since I know all the parameters we need to test on it, I can make a printed test sheet with zero data on it, but places to put collected data, by hand, it becomes the hard copy of the test event. Folks still want hard copy test data filings, even in our supposed jump to paperless.

An excel chart would graph your date regardless of what you choose to call the numbers plotted. It merely sets up the proper scaling and placement of those number arrays, just as you would in making it by hand. It plots the numbers. It processes NOTHING.

You can perform internal processing on your numbers to convert them to some other unit yourself in the spreadsheet if you wish to present them differently. I think you are complicating this way too much.

Nope. You create the spreadsheet fully proofed. You only use it for real, gathered data if it actually works.

One does not take a pile of data and 'slap together' a 'quick spreadsheet' and get desirable results. The creation of a tool with which to examine one's data is something that demands at the very least a rudimentary requirements analysis, just like a good database admin would do before implementing a database into a system.

No. You are a person that dismissed a certain method long ago, even though it soent decades evolving, you failed to 'add' even the most rudimentary upgrade to your knowledge of it. You must see and know that so many use them for so much that there has to be a robust engine there. What we real men would call... "A tool".

I know that I make use of the TOOLS at my disposal. I think John and other simply cry because Billy succeeded in sucking out more cash than just that for the OS.

Your hand written data sheet is the hard copy of the event. That data can be pumped into a computer and stored in more than a few different ways, and even 'archived' in a specific process your firm can put into its ISO methodology. Computers are useful for storing data, and processing data. We can do one or both with those stored data sets. Only the operator can be held responsible for the information (processed data) he presents to his supervisors and peers. He must bypass any and all known bugs and stay on top of any that get discovered. Seems no different than any other aspect of using a computer to perform certain tasks.

Yes, from the READ ONLY archive.

We call them product travellers, and they get filed. A file for each product, not a binder full of a bunch. A file cabinet fule of individual files (jackets). Each product's history from inital assembly through test gets tracked.

VHDL is code and it's not procedural. Maybe that's why FPFAs tend to have so few bugs compared to uPs running c. I have people advocating adding soft cores programmed in c, so we can get our bug level up to industry standards.

As one zooms into the Mandelbrot Set, where the interesting stuff lurks, doesn't the math precision have to keep going up? Seems like that should get clumsy fast.

Neither is a computer language. Well, SQL a tiny bit.

I rarely see a spreadsheet that includes even a functional title, much less author/date/revision control. I never see comments or operating instructions. Someone who happens across it a few years later will have no idea what it is... probably not even the author.

Our customers send us "forms" to fill out that are horrors. We mostly refuse to do it.

Don't get me started on Word macros, maybe another "computer language."

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

John Larkin wrote in news: snipped-for-privacy@4ax.com:

You simply have no grasp as to what an imaginary number is, eh?

The simplicity of the math is the key... to the entire universe.

Or... is it simply... 42

Really, John. You claim to be so math centric and have spent time in your posts declaring how little math I know (something you could not possibly know anything about), yet you spout things like this, which are obvious indicators that you seriously lack in the realm.

I only use hand plots for personal experiments, like characterizing a part. I take scope and setup photos, too, and we have a system for archiving things like that unofficially. We take no data manually for production testing; that's all automated and formally archived.

What do you do with the paper plot that the tech does by hand? Does she, or some software, also log numerical data from the instruments?

--

John Larkin         Highland Technology, Inc 

lunatic fringe electronics

John Larkin wrote in news: snipped-for-privacy@4ax.com:

Do you use ESD abatement control equipment in your labs, John?

I really shouldn't *give* you this... I meant it as a response to another post by an intelligent poster.

Hell, go find it in my response to him. It has all the elements you describe, and requires no version control as it contains no formulas that would evolve over time.

John Larkin wrote in news: snipped-for-privacy@4ax.com:

Do yours?