Re: Floating point format for Intel math coprocessors

Hmphh! In Fortran II, we were lucky to get add and subtract. No such thing as .AND. and .OR. there.

Jack

Reply to
Jack Crenshaw
Loading thread data ...

That's what happens when you punch "//JOB T"

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Reply to
Morris Dovey

I was just making a light-hearted comment. I just guessed that someone who has an interest in older technology would have some even older things. Does he have an abacus or two -- just in case?

Ah, yes. I'd forgotten about the ol' divide by zero on the electro-mechanical calculators. And the only "reset" was to pull the plug.

I'll have to think about the use of multiplication tables, especially for the case of packed values.

Addition and subtraction as you say is accommodated by the DAA instruction. Most of the micros only have a decimal-adjust for addition so you have to learn how to subtract by adding the tens- complement of the value being subtracted.

Reply to
Everett M. Greene

Grin!! I did a _LOT_ of work on the 1130. That's where I learned a lot of my Fortran skills. IMO the 1130 was one of IBM's very few really good computers. Ours had

16k of RAM , and one 512k, removable HD. And it supported 100 engineers, plus the accounting dept.

The 1130 OS provided all kinds of neat tricks (remember LOCAL?) to save RAM. I was generating trajectories to the Moon and Mars on it. Its Fortran compiler was designed to be fully functional with 8k of RAM, total. Let's see Bill Gates try _THAT_!!!

Jack

Reply to
Jack Crenshaw

Actually, he does -- several. He seems to be collecting every possible example of mechanical ways to do math. His office wall is a work of art.

Agreed, although some (I think the Z80 was one) worked for subtraction as well. As for multiplication and division, forget it. But if you do the Friden trick of shifting, successive subtraction works pretty well. Still not nearly as fast as binary, of course, but if you have to convert back & forth for I/O anyway, it may still be more efficient to do it in BCD. Plus, you don't have to deal with the bother of a 1 that becomes 0.99999999.

Calculators do everything completely differently. In a calculator (at least the old ones -- modern things like PDA's have RAM to burn), time isn't an issue. The CPU is always waiting for the user anyway, so efficiency of computation isn't required. Saving ROM space is lots more important.

Jack

Reply to
Jack Crenshaw

I use PMTs in my work, so yes.

Excellent. Of course, their might be some subtlety that they didn't include in the physical model which becomes dominant, in the real mccoy. But odds are the physical approximation will get you far, if you are wise about modeling the dimensions (and I don't just mean length here.)

I just like having the theory from which to make such deductions to the specific, as well. Sometimes, interesting ideas can suggest themselves from that. More, it's hard to apply your dimensional analysis to the physical modeling without at least some theory as your guide.

But one uses all the tools available at reasonable cost, I imagine. I'm sure they did, too.

the

It wasn't about money, for me. So that's no incentive for me. I just enjoyed the learning experience.

Yes, in general.

I think there may be a place for name calling is if other avenues of goading fail and it's perceived that there might be some hope with a dash of cold water in the face. Sometimes, it just takes a slap to get a response. If it's done with respect, even if they don't really realize you honestly care about them caring about themselves, then it may work out for the better.

Of course, there's always the risk of a broken relationship as a result. But sometimes it's already broken by that time and this is the only remaining possibility for restoring it. One takes one's chances.

I had

stuck

Hehe. Looks like very interesting work with very interesting people. Excellent!

Yes, Kaypro did good and with reasonable pricing at the time.

I used CP/M a fair amount, too. In general, my only problems were with Persei floppies. Voice coil drive, fast, and I had a few fail on me. The Shugarts just kept working.

I rely on DOS, similarly. Of course, if you've done *any* assembly programming on a DOX x86 with .COM files or have programmed with the early DOS 1.0 function calls, you *know* about the many similarities (identical, sometimes) with CP/M. But there are times when Windows won't boot and that DOS is still ticking away just fine, that I can jump in and use it to get Windows restarted. Another reason I'm still on Win98, by the way.

text, lets

interface. Pity

Okay. It just makes me angry with them, having paid them well and received absolutely NOTHING of value for it. And I keep seeing that carrot in front of my face that I can't quite get. I just have to close my eyes, I guess.

every day,

doesn't

the file, but

restore

Hehe. Noted. I'll remember this example when others rail at the idea of open source and stuff this example into their face. It's a classic, for sure.

to get the

utility,

users'

working.

than

redefining user

trying to

Like that's anything new. In the US, at least, it's not just profit but short-term-profit-in-the-next-three-months which drives almost all decisions.

What can I say?? I'm as frustrated and I've not been exposed to it, like you have. It all just baffles me.

hehe. Well, keep at it! I used it for sensor fusion with various phased-array radar and other sensor systems, all with varying characteristics to model. It's worth knowing about!

Of course. I gave a swipe at that point above, in fact. But I added that even then, I've often found better ways -- even in the face of 12 orders of mag. The key to my point isn't that floating point should be entirely avoided. It's that it should be applied with understanding -- and more particularly, in the case of most embedded systems. If Excel crashes out, "Oh, gee. I guess I'll just reboot." You live with it. But in an embedded system, subtle errors crop up if you aren't careful.

Or you can do the analysis to verify that it is impossible for overflow to occur. Which is what I've done in many cases. One should be careful, no matter, I suppose.

Well, you've given me a story early on, about modeling PMTs. Let me tell you one.

Calculating a standard deviation is often done by "smarty pants" programmers with a modified version of the "standard equation" where only one pass through the data is required. You know the one, where you accumulate both a SUM(x) and SUM(x^2). At the end, a difference calculation is used. But in this case, the magnitude of both parts are often quite similar, leaving only the least significant bits in the result.

When this happens, preserving those bits during accumulation can be very important. For example, what often isn't realized is that it is important to pre-sort the data before accumulation so that the smaller numbers can accumulate to larger values

*before* getting swamped out by the accumulation of one of the larger values. If the largest value, for example, were added first, the smaller values might very well truncate out completely as they are accumulated and never get a chance to impact the least significant bits in the summed result, before the difference is taken and they become crucial for the final calculation.

This is only one of many subtle examples. And the analysis is sometimes rather difficult to shepherd well, without training and practice. On the other hand, analyzing integer math is, by comparison, much more of an "undergrad" kind of thing. The issues are more tractable to more people, as a rule.

And in the end, it *is* helpful to remember that it's integer in, integer out, for many embedded systems and it's worth doing to analyze the data flows throughout. My belief is that floating point should be justified by the proponents. But so should integer.

In other words, someone should be paying attention and it should be clear from the record why either integer or floating point is chosen for a particular application. But to be honest, the issues of floating point are more subtle and the skills required to properly analyze it are greater, I think.

In any case, it's good to question someone and make them think about it.

Tell me about it. It's quite common for me to prepare a 10 or

20 page analysis, complete with timing diagrams and mathematical derivations. I'll include error budgets/tolerances in that analysis and show how I got them. Sometimes, people just want me to roll up my sleeves and get the task out. But I need confidence, even if they don't. So I do the work, anyway.

Originally, I'd hoped that others would actually take the chance to point out my errors and help me improve the documents. But most of my target readers just ignore them, assuming I am getting things right, or unable to challenge my points, or unwilling to put in the time. No matter. Now, I just do it mostly for my own sake -- just to help me be sure that I've covered the issues and to provide myself with something to look back on at a later time. It's turned out to help me a lot to get back into the right mindset, when having to return to a project.

So the point often isn't anymore to get input from others. It's more for me. I can live with that.

Sadly, too few programmers have learned numerical methods for analysis -- for example, power functions applied to recurrances. Who today reads through each page of Knuth's 3-vol set, as I did when it came out? (Or his "Concrete Mathematics," published recently, or Chapra and Canale's "Numerical Methods for Engineers" or your own book or a host of others worth studying.)

Times have changed, I suppose.

Jon

Reply to
Jonathan Kirwan

hehe. We had a 16k system, too! The timesharing system I wrote provided timeshared BASIC for 32 users, by the way, and lived in

16k RAM -- 6k for the interpreter and 10k for the swapped user page. Included Chebyshev and mini-max methods for the transcendentals -- something Intel failed to use for their x87 floating point units until the advent of the Pentium, many years later.

Oh, well.

Jon

Reply to
Jonathan Kirwan

In article , Jack Crenshaw wrote: . [hundreds of lines] . .

. . . Open-source alternatives to Mathcad include Rlab, Scilab, and especially Octave. I don't know of any open-source work-alikes for Mathcad specifically, though; in any case, I suspect will interest you.

--

Cameron Laird 
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html
Reply to
Cameron Laird

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.