But it was the first time in the world that this had actually been done! So I am a tad proud of my experimental design, data collection and programming of one of the Telecom mainframes that had SPSS on it.
A modification by IBM of the Hollerith card that was invented in the 1890s!!
Used for data input and programming (actually input in the opposite order - program cards followed by the data cards) until the early 1980s. So was paper tape - 5 bit Baud, usually. Telecom got rid of its last paper tape stuff in the late 1980s. It was being used for maintaining the Supply Branch stock database on one of the mainframes. It was replaced (temporarily) by a microcomputer running a 4GL when the last technician who could service the tape reader retired. It was a near thing! They nearly had to re-input about 600+ pages of the stock manual by hand ... .
I was of the opinion that many looms mainly used wooden program 'cards' connected by metal fixings. I know that the Jacquard looms did. I can see that I'll have to research this a bit further ... :lol:.
As Josh Billings famously said: "It's not what a man knows that counts; it's what he knows that just ain't so". Can't recall ATM who "Josh Billings" was a pseudonym for. I'll have to look that up too (checked - see link).
What's my name again? :rotfl:.
A lot of "knowledge" that we all have is basically stuff we have just picked up, and not necessarily critically examined. Just sort of gets absorbed, until challenged. The mark of a sensible person is that when this occurs, they re-examine that "knowledge", and redact it where necessary.
What staggered me when I first bought my '93 Impreza was that the looms that were weaving car seat covers at that time were capable of weaving 80,000 threads simultaneously. Blew me away.
I developed a reconciliation system for staff payroll for Telecom that used around 80,000 of these each fortnight for the payroll deduction suspense reconciliation when the then new computer payroll system kept giving 1 cent rounding errors. T'was I who discovered the rounding error problem, too.
The programming team had used the wrong variable type for computing monetary values. The correct variable type is EBCDIC (the Wikipedia article for this fails to mention its use as a variable type ... ).
EBCDIC variables cannot give rounding errors in monetary calculations. The double precision variable type that was used will almost always give rounding errors of one cent, and this is of extreme importance when balancing (reconciling) cash amounts paid out with the costed amounts that appear in the books of account. Both figures must be identical in accordance with the provisions of the Commonwealth Audit Act, and Generally Accepted Accounting Principles (GAAP) and Accounting Standards.
See the article here regarding some info about dealing with monetary values in computer programming:
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.