When data squared is negative, the data is.................
Frogwatch
Anglia on the subject of Climate Change and global warming, a
programmer complains that the data is so bad that for some reason the
sum of the data squared keeps coming out negative. This means the
data must be................ (try to remember your middle school math
here).
dott.Piergiorgio
I suspect that it's not a case of garbage in, garbage out... I'm more
oriented to think about bug in the implementation of the algorithm,
because I seriously doubt the use of imaginary # in an environment
modeling sw (and less so in engineering, and generally applied sciences)
(the complainer being a programmer, is also a giveaway that is a code,
not data, issue.....)
enough chatter, I'll return to my, well, coding :)
Eugene Griessel
<dott.Pierg...@KAIGUN.fastwebnet.it> wrote:
>Frogwatch ha scritto:
>> In one of the e-mails from the hacked list from the University of East
>> Anglia on the subject of Climate Change and global warming, a
>> programmer complains that the data is so bad that for some reason the
>> sum of the data squared keeps coming out negative. This means the
>> data must be................ (try to remember your middle school math
>> here).
>
>I suspect that it's not a case of garbage in, garbage out... I'm more
>oriented to think about bug in the implementation of the algorithm,
>because I seriously doubt the use of imaginary # in an environment
>modeling sw (and less so in engineering, and generally applied sciences)
Mmmm - I suspect you are refering to what we call "i" - the imaginary
square root of minus one? very useful in electrical engineering.
>
>(the complainer being a programmer, is also a giveaway that is a code,
>not data, issue.....)
>
>enough chatter, I'll return to my, well, coding :)
Eugene L Griessel
Beware of altruism. It is based on self-deception, the root of all evil.
- I post only from Sci.Military.Naval -
Arved Sandstrom
We know where you're going with this. :-) Having said that, like Il
Dottore said, if you'ce got a programmer involved than the odds are
pretty good that it's a program defect. After all, unless they are using
complex numbers (which I doubt) then it's not possible to sum up squared
numbers and get a negative...unless your algorithm is badly coded.
AHS
tankfixer
Therin lies the rub.
There have been people saying the modeling software was flawed...
The True Believers then commenced on a witch hunt to burn the heritics.
Eugene Griessel
wrote:
_the_ modelling software? You speak as if there was a unique piece of
software involved.
Eugene L Griessel
You will find in no park or city
A monument to a committee.
Andrew Robert Breen
Modelling software is /always/ flawed somewhere, as anyone who's worked
with models of any complexity knows. The question is how badly it's
flawed, where/when the flaws manifest and how badly the results are
distorted (and, of course, where the &*^&*%$%ing bug actually is..). Which
is why you routinely compare results from different models and why you do
regulat reality-checks against whatever data is available. Which is
precisely what seems to have been going on.
[The flaws that manifest in halfway well-developed models tend to be quite
subtle ones which only show up around the margins. If the results are
really dam' stupid, they'd have got picked up around and about the first
couple of runs. Been there, dealt with both flavours..]
Any road, the -ve squares thing is a good example of the kind of dam'
silly things that get said in e-mails, particularly when someone is tired
and not thinking straight. Been there and done that too.
--
Andy Breen ~ Not speaking on behalf of the University of Wales, Aberystwyth
Feng Shui: an ancient oriental art for extracting
money from the gullible (Martin Sinclair)
Iain Rae
or you're overflowing your data type if you're dealing with big enough
numbers. Being cynical I would suggest using unsigned double (or more
probably DOUBLE PRECISION )
>
> AHS
Eugene Griessel
wrote:
I doubt this would help - anything squared is always positive and to
get a negative means somewhere, something is wrong at the procedure
level.
Eugene L Griessel
Health is merely the slowest possible rate at which one can die.
Andrew Robert Breen
In any case it's an indication that SOMEONE HAS DONE SOMETHING SILLY (back
when it was starting a variable name with the wrong character and not
explicity defining it..). At least it's the kind of error which draws
attention to itself, rather than lurking. The e-mail will have led to
finger-pointing and chortles in the tea room later that day, though..
Andrew Robert Breen
Trying to stuff the ^2 value into something too small to hold it has that
effect. A certain telescope I've had dealings with would do that id the
received-voltage-squared value was too large: the counters would wrapover
with - ahem - interesting effects, which could include negative values,
depending on how digitisation then went. Made for some minutes[1] of
head-scratching, then we stuffed a bigger resistor in. I'm in no doubt at
all that similar things can be achieved entirely in software.
[1] and - quoted out of context - some of the e-mails sent during that
interval would have given a /wholly/ misleading picture of the eventual
data quality.
Iain Rae
yes and no you can only store a certain range of numbers in a computers
memory location. So if you've got an 8 bit memory location (those were
the days) you can store binary
00000000
to binary
11111111
or 0-255
so 255+1 is either going to be stored as
00000000
or
10000000
depending on which digit you drop. i.e. either 0 or 128, normally you'd
go for 0
If you want signed integers then the convention is usually to use the
left most digit to indicate the sign
so
10000000 is -128
00000000 is 0
01111111 is 127
so 12^2=144 would be
10010000
which is -16 in signed binary
Assuming I've remembered my binary arithmetic correctly.
would be
dott.Piergiorgio
>
> or you're overflowing your data type if you're dealing with big enough
> numbers. Being cynical I would suggest using unsigned double (or more
> probably DOUBLE PRECISION )
there was also the arbitrary precision algorithm, slow re. floating
single/double precision (and even integers...) but all depends on the
volume of number-crunching.
I have never looked at academic computing facility's way of handling
things (save the pwning of a certain vax during early '90s....) but I
suspect that one of the main aspect is striking the balance between
precision and computing time (ballpark example, using maxima or octave
vs. native binary written & compiled in fortran or C )
Best regards from Italy,
Dott. Piergiorgio.
dott.Piergiorgio
>> I doubt this would help - anything squared is always positive and to
>> get a negative means somewhere, something is wrong at the procedure
>> level.
>
> Trying to stuff the ^2 value into something too small to hold it has that
> effect. A certain telescope I've had dealings with would do that id the
> received-voltage-squared value was too large: the counters would wrapover
> with - ahem - interesting effects, which could include negative values,
> depending on how digitisation then went. Made for some minutes[1] of
> head-scratching, then we stuffed a bigger resistor in. I'm in no doubt at
> all that similar things can be achieved entirely in software.
you being in UK academia and having to do with large astronomical
instrument, I can ask if are still around certain bearing & training
mechanism somewhere in the Jodrell Bank area (Naval content here ! ;) )
guy
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Sounds dead right to me!
Guy
Andrew Robert Breen
The elevation racks on the Mk.1B? Yep, still the original recycled
battleship turret rings. The drives were converted to electrical in the
70s (think about then - the Mk1.->1A rebuilding would be the obvious
time to do it), though. The hydraulic motors are long gone.
Think the azimuth bogie wheels are still the original bits from scrapped
steam locomotives too - there were plans to swap 'em in the 80s for new
wheels, as some railway preservationists wanted 'em for a rebuild job,
but I think new ones were made for the preservation guys in the end.
Must get back up to Jodrell at some point (health has militated against
observing campaigns the last few years). It's a fun place to do science.
dott.Piergiorgio
>> you being in UK academia and having to do with large astronomical
>> instrument, I can ask if are still around certain bearing & training
>> mechanism somewhere in the Jodrell Bank area (Naval content here ! ;) )
>
> The elevation racks on the Mk.1B? Yep, still the original recycled
> battleship turret rings. The drives were converted to electrical in the
> 70s (think about then - the Mk1.->1A rebuilding would be the obvious
> time to do it), though. The hydraulic motors are long gone.
Nice to hear that. Of course, I should suppose that in case of
dismantling or major modernization of the radio telescope these will be
given to the IWM as fitting basement of the well-known gate guardian of
said museum ?
(fitting in this case in the sense of "being really appropriate" :) )
It's a pity that parts of the HMS Resolution wasn't used for these
racks, because will be really nice the quip "HMS resolution still not
finished" (referencing to the ship's motto ;) )
ken...@cix.compulink.co.uk
Robert Breen) wrote:
> I'm in no doubt at
> all that similar things can be achieved entirely in software.
With various 16 bit programs adding more than a certain amount of
memory resulted in the program failing because it only had a 16bit
variable for free memory. There was also the case that some OS could get
disc free space wrong because the number wrapped.
Ken Young
Dr. Vincent Quin, Ph.D.
Andrew Robert Breen
Don't you just love it when a freshly-hatched egg thinks it knows what the
rules are around here?
Please, all, feel free to point and laugh..
Eugene Griessel
Breen) wrote:
>In article <Odednarb4Pro34_W...@supernews.com>,
>Dr. Vincent Quin, Ph.D. <dr...@coldine.edu> wrote:
>>ken...@cix.compulink.co.uk wrote:
>>
>>> In article <ldg0u6x...@news.aber.ac.uk>, a...@aber.ac.uk (Andrew
>>> Robert Breen) wrote:
>>>
>>>
>>>>I'm in no doubt at
>>>>all that similar things can be achieved entirely in software.
>>>
>>>
>>> With various 16 bit programs adding more than a certain amount of
>>> memory resulted in the program failing because it only had a 16bit
>>> variable for free memory. There was also the case that some OS could get
>>> disc free space wrong because the number wrapped.
>>>
>>> Ken Young
>>
>>Your post is off topic. Please respect our rules.
>
>Don't you just love it when a freshly-hatched egg thinks it knows what the
>rules are around here?
Especially when it is a fully blown fraud.
Eugene L Griessel
When a man says it's a silly, childish game, it's probably
something his wife can beat him at.
Andrew Robert Breen
Eugene Griessel <eug...@dynagen.co.za> wrote:
>On Sun, 29 Nov 2009 11:58:56 +0000, a...@aber.ac.uk (Andrew Robert
>Breen) wrote:
>
>>In article <Odednarb4Pro34_W...@supernews.com>,
>>Dr. Vincent Quin, Ph.D. <dr...@coldine.edu> wrote:
>>>ken...@cix.compulink.co.uk wrote:
>>>
>>>> In article <ldg0u6x...@news.aber.ac.uk>, a...@aber.ac.uk (Andrew
>>>> Robert Breen) wrote:
>>>>
>>>>
>>>>>I'm in no doubt at
>>>>>all that similar things can be achieved entirely in software.
>>>>
>>>>
>>>> With various 16 bit programs adding more than a certain amount of
>>>> memory resulted in the program failing because it only had a 16bit
>>>> variable for free memory. There was also the case that some OS could get
>>>> disc free space wrong because the number wrapped.
>>>>
>>>> Ken Young
>>>
>>>Your post is off topic. Please respect our rules.
>>
>>Don't you just love it when a freshly-hatched egg thinks it knows what the
>>rules are around here?
>
>Especially when it is a fully blown fraud.
I was basing my reponse more on it being a fully fledged fsckwit.
Either way, it shouldn't let the door hit it on the arse as it leaves.
It's a good door, that one is.
Peter Skelton
Breen) wrote:
>In article <2e85h5d2ooijpmsgl...@4ax.com>,
>Eugene Griessel <eug...@dynagen.co.za> wrote:
>>On Sun, 29 Nov 2009 11:58:56 +0000, a...@aber.ac.uk (Andrew Robert
>>Breen) wrote:
>>
>>>In article <Odednarb4Pro34_W...@supernews.com>,
>>>Dr. Vincent Quin, Ph.D. <dr...@coldine.edu> wrote:
>>>>ken...@cix.compulink.co.uk wrote:
>>>>
>>>>> In article <ldg0u6x...@news.aber.ac.uk>, a...@aber.ac.uk (Andrew
>>>>> Robert Breen) wrote:
>>>>>
>>>>>
>>>>>>I'm in no doubt at
>>>>>>all that similar things can be achieved entirely in software.
>>>>>
>>>>>
>>>>> With various 16 bit programs adding more than a certain amount of
>>>>> memory resulted in the program failing because it only had a 16bit
>>>>> variable for free memory. There was also the case that some OS could get
>>>>> disc free space wrong because the number wrapped.
>>>>>
>>>>> Ken Young
>>>>
>>>>Your post is off topic. Please respect our rules.
>>>
>>>Don't you just love it when a freshly-hatched egg thinks it knows what the
>>>rules are around here?
>>
>>Especially when it is a fully blown fraud.
>
>I was basing my reponse more on it being a fully fledged fsckwit.
>
>Either way, it shouldn't let the door hit it on the arse as it leaves.
>It's a good door, that one is.
There's a little bridge near Bell Island here needing a troll.
Sadly the old one drowned when the fall storms caused a sanitary
system overflow into the storm system in the older part of the
city.
Peter Skelton
ken...@cix.compulink.co.uk
> Your post is off topic. Please respect our rules.
Since when has it been your rules? Ships use computers anyway By the
way if you are going to comment to any off topic poster here you are not
going to have much in the way of free time.
Ken Young
Eugene Griessel
Especially as he is one of the premier off topic posters.
Eugene L Griessel
Do you think there's a God?
Well, SOMEbody's out to get me!
tankfixer
eug...@dynagen.co.za says...
I speak only of the software the the Anglia researschers refused to
share.
Eugene Griessel
wrote:
Yes - true desperation. What an illogical argument.
Eugene L Griessel
He did his work with that peculiar thoroughness of mind
that reveres details, but never quite understands them.
Keith Willshaw
"tankfixer" <paul.c...@gmail.com> wrote in message
news:MPG.2584cc3...@news.bytemine.net...
Why should they share their software and what good would it be if they did ?
Any independent researcher would do far better writing their own, the
algorithms involved are not exactly complex, indeed I'd be inclined to
use off the shelf tools like Mathlab and Excel for much of it.
Note that one of the biggest valid criticisms of the Anglia effort is the
poor
quality of much of its software. Its typical of much of the work you see
carried out in Academia. Typically written by grad students its largely
undocumented and not well error trapped. Its not shrink wrapped code
that you can send to another user. Its largely written to be run from a
command prompt and the user is expected to compile and tweak his own code.
This is necessary because the raw data is in many incompatible formats and
if a new batch of research information comes in the first thing the
researcher has to do is write a new import routine.
As a software engineer with 20+ years experience this troubles me
a little but then I recall the stuff I wrote when I went back to college
in 1984.
Keith
Eugene Griessel
I couldn't have put it better myself. Even now I often get, from
management, "why don't you automate this", and have to once again
explain that the day the customer decides to use an absolutely
standard data input I will automate it - but so long as they send us
crappy data, usually in Excel, everything coming in has to untangled,
validated and put into a form where the main processes can handle it.
If you want any of my programs you will end up with a squiilion
undocumented little subroutines - some of which were only ever used
once. The concept of a university having an "out of the box"
"MSClimatemodeller version 6.001" truly boggles the mind.
Eugene L Griessel
Puritanism - The haunting fear that someone, somewhere, may be happy.
Arved Sandstrom
> "tankfixer" <paul.c...@gmail.com> wrote in message
> news:MPG.2584cc3...@news.bytemine.net...
>> I speak only of the software the the Anglia researschers refused to
>> share.
>
> Why should they share their software and what good would it be if they did ?
> Any independent researcher would do far better writing their own, the
> algorithms involved are not exactly complex, indeed I'd be inclined to
> use off the shelf tools like Mathlab and Excel for much of it.
>
> Note that one of the biggest valid criticisms of the Anglia effort is the
> poor
> quality of much of its software. Its typical of much of the work you see
> carried out in Academia. Typically written by grad students its largely
> undocumented and not well error trapped. Its not shrink wrapped code
> that you can send to another user. Its largely written to be run from a
> command prompt and the user is expected to compile and tweak his own code.
>
> This is necessary because the raw data is in many incompatible formats and
> if a new batch of research information comes in the first thing the
> researcher has to do is write a new import routine.
>
> As a software engineer with 20+ years experience this troubles me
> a little but then I recall the stuff I wrote when I went back to college
> in 1984.
>
> Keith
Reminds me of the scientific programming I did 15 or so years ago, give
or take. Oceanographic data sets to do with what you will. Some data
still on VAXen, some on UNIX machines, some in FOXPro databases on
Windows boxes. Some data on CDs for that matter. Wild variety of UNIX
scripts (gawk, bash, Perl etc) along with proprietary languages, VAX
programs, Matlab scripts, FORTRAN programs. Like you said, some programs
had to be recompiled after tweaking, and some scripts had to be re-edited.
Another project involved borrowing a meteorological modelling software
suite and trying to use it to model Les Suetes winds. Reams of
documentation, but still a very non-trivial exercise to figure out how
to write run scripts and import data.
There was nothing wrong with the work done, nor were the final data
incorrect, but as you said, there's no way you could bundle this stuff
up and hand it over to someone else as an easy-to-use package.
Anyone who wants to get a feel for how lots of scientific software is,
just download and (try to) use things like NCAR graphics, GMT (Generic
Mapping Tools) from U of Hawaii, or apps that work with NetCDF data.
This is not like getting a nice Windows app with an .exe or .msi
installer, and being able to browse in a file chooser to convenient
perfectly-formatted data files so you can run handy utilities off menu
choices.
AHS
Alan Lothian
<keith...@kwillshaw.demon.co.uk> wrote:
> quality of much of its software. Its typical of much of the work you see
> carried out in Academia. Typically written by grad students its largely
> undocumented and not well error trapped.
True story, not immediately relevant to the current issue but of more
than some general relevance. Remember the Access card -- Britain's
second credit card? In 1973, yes, that long ago, I knew a young
programmer, then about five months pregnant. She was living in a tent
in Southend, writing code 12 hours a day or more on frightening,
innumerate-management-led deadlines to get Access up and running on
something like schedule. Constant changes of program specs. (I'd
recently done a low-level stint at IBM so at least I knew what she was
talking about.)
Occasionally she got up to town (ie, for our American friends, London)
where I met her in a certain north London theatre pub. On more than one
occasion. I fancied the pants off her, pregnant or not (no obvious
father around, rather less usual in them thar days) but got nowhere,
probably a good thing for both of us. Liked her lots, though. She was
usually exhausted but relaxed, and inflicted only moderate alcohol
damage on her foetus. But these are irrelevant personal details.
Cut to early '90s. A fellow-member of the East Suffolk Mountain Rescue
Club (it did exist, I assure you) was leading a team of software
engineers who were trying to figure out why cash machines (ATMs for
Americans) all over Britain were falling over in strange ways, almost
always around midnight.
Hours and hours of multi-person expensive time, poring over *exactly*
the code my non-girlfriend and her colleagues had written almost twenty
years before. No, zilch, nada, niente documentation. At least they
still had the source code (or at least a version of it) which is not
always the case. A long ramble of fixes, is how Andy described it.
How hard is it to write into the code "this bit does that"? Very hard,
when you're whacking in hours like that under huge pressure and living
in a tent. Hmm, says Andy. This bit doesn't do anything, let's get rid
of it. Oh, shit. It did something. And so on. Turned out to be a simple
(but very, very deeply buried) stack overflow that was causing the
problem. He did tell me that was the first thing they looked for, but
it was, as I said, very, very deeply buried. Few or no error traps, of
course, and by the '90s the code was handling a lot more data
throughput than it had ever been designed for.
Andy's team got there in the end, but they cost their employer a lot of
dosh. I imagine you have a few similar stories under your own belt.
--
"The past resembles the future as water resembles water" -- Ibn Khaldun
If you wish to email me, try putting a dot between alan and lothian.
Blueyonder is a thing of the past.
Keith Willshaw
"Alan Lothian" <alanl...@mac.com> wrote in message
news:061220091846327414%alanl...@mac.com...
> In article <bbPSm.42890$Dl4....@newsfe08.ams2>, Keith Willshaw
> <keith...@kwillshaw.demon.co.uk> wrote:
>
>
>> quality of much of its software. Its typical of much of the work you see
>> carried out in Academia. Typically written by grad students its largely
>> undocumented and not well error trapped.
>
>
> True story, not immediately relevant to the current issue but of more
> than some general relevance. Remember the Access card -- Britain's
> second credit card? In 1973, yes, that long ago, I knew a young
> programmer, then about five months pregnant. She was living in a tent
> in Southend, writing code 12 hours a day or more on frightening,
> innumerate-management-led deadlines to get Access up and running on
> something like schedule. Constant changes of program specs. (I'd
> recently done a low-level stint at IBM so at least I knew what she was
> talking about.)
>
> Occasionally she got up to town (ie, for our American friends, London)
> where I met her in a certain north London theatre pub. On more than one
> occasion. I fancied the pants off her, pregnant or not (no obvious
> father around, rather less usual in them thar days) but got nowhere,
> probably a good thing for both of us. Liked her lots, though. She was
> usually exhausted but relaxed, and inflicted only moderate alcohol
> damage on her foetus. But these are irrelevant personal details.
>
> Cut to early '90s. A fellow-member of the East Suffolk Mountain Rescue
> Club (it did exist, I assure you)
That would be founded to rescue people from the fearsome peaks
of the Newmarket Ridge with the towering massif of Great Wood Hill
towering over the landscape at all of 420ft above sea level :)
The Cat and Mouse near Wetheringsett was the headquarters of the Mid Suffolk
Mountain Rescue Service IRC, I think they did once turn out to rescue a
drunken
cyclist who had fallen in a ditch on his way home.
> was leading a team of software
> engineers who were trying to figure out why cash machines (ATMs for
> Americans) all over Britain were falling over in strange ways, almost
> always around midnight.
> Hours and hours of multi-person expensive time, poring over *exactly*
> the code my non-girlfriend and her colleagues had written almost twenty
> years before. No, zilch, nada, niente documentation. At least they
> still had the source code (or at least a version of it) which is not
> always the case. A long ramble of fixes, is how Andy described it.
>
> How hard is it to write into the code "this bit does that"? Very hard,
> when you're whacking in hours like that under huge pressure and living
> in a tent. Hmm, says Andy. This bit doesn't do anything, let's get rid
> of it. Oh, shit. It did something. And so on. Turned out to be a simple
> (but very, very deeply buried) stack overflow that was causing the
> problem. He did tell me that was the first thing they looked for, but
> it was, as I said, very, very deeply buried. Few or no error traps, of
> course, and by the '90s the code was handling a lot more data
> throughput than it had ever been designed for.
>
> Andy's team got there in the end, but they cost their employer a lot of
> dosh. I imagine you have a few similar stories under your own belt.
>
I have spent half my life unpicking such code. One of the problems is
that it was often expected that the entire mess would have a short life
and be rewritten within a few years. One of the ironies of the information
technology era is that much of the software running on the sleek new
machines
now available at its core uses ancient code written in Fortran and Cobol
30 years ago. The newer breed of programmer writes very nice user
interfaces in languages such as C++ and C# but the guts are still good
old fashioned F77
Keiith
Alan Lothian
<keith...@kwillshaw.demon.co.uk> wrote:
> "Alan Lothian" <alanl...@mac.com> wrote in message
> news:061220091846327414%alanl...@mac.com...
> > In article <bbPSm.42890$Dl4....@newsfe08.ams2>, Keith Willshaw
> > <keith...@kwillshaw.demon.co.uk> wrote:
> >
>
>
> The Cat and Mouse near Wetheringsett was the headquarters of the Mid Suffolk
> Mountain Rescue Service IRC, I think they did once turn out to rescue a
> drunken
> cyclist who had fallen in a ditch on his way home.
Now just *how the hell* did you know that? It's almost entirely true,
except that it wasn't a drunken cyclist, merely a pedestrian. And he
wasn't exactly rescued. I was the drunken cyclist, who went on to
create crop circles in a pitch-black night in a wheatfield with no
lights whatsoever trying to find the road again. (You swing the bike
around until you make contact with something that's not wheat.) The
crop circles were collateral damage. Fooled tourists, but pissed off
old Michael, whose wheatfield it was, and had a pretty good idea whose
fault it was. Truly, it was not intentional. I had to buy him several
pints of Old Growler.
I am genuinely staggered, Keith. The Cat and Mouse is now with God,
having been sold off as a private house in the mid-90s. And the nearest
high ground was, IIRC and I may not, about 250 ft above sea level. East
Suffolk, remember: nowhere near the mid-Suffolk mountains.
Will comment later on other stuff, but I am, well, permit me to repeat
myself, staggered. Not many people know what a bunch of idiots in
Pages' Green, near as dammit to Wetheringsett, did almost 20 years ago.
(ESMR founded late 1990.) This is a great weirdness. How the hell did
you know about that? I mean, it wasn't a state secret or anything like
that, but...
I think it is time for my slightly-later-than-usual evening pastis.
>
BTW the "club" was simply called "East Suffolk Mountain Rescue".
I still have a very battered sweatshirt. I was the Press Officer, whose
duty was to keep things out of the press. I thought I'd succeeded until
your post this evening. Roy and Anne Booth were the landlord/lady in
question. Memory lane, or what. I think I may abandon the pastis and
have a couple of large whiskies.
I say again, I am staggered, dumbfounded, amazed..... nay, stupified.
Keith Willshaw
Well working as I do in Cambridge I have friends in that part of the world
and
last xmas we were swopping tales. Mine were about various curious goings on
in
remote pubs the Romney Marshes and his dealt with the proceedings at the
Cat and Mouse.
Keith
Andrew Chaplin
Is this a real-life encounter of Usenet with humanity? If so, too funny,
and just cause to promote the medium.
--
Andrew Chaplin
SIT MIHI GLADIUS SICUT SANCTO MARTINO
(If you're going to e-mail me, you'll have to get "yourfinger." out.)
Alan Lothian
Chaplin <ab.ch...@yourfinger.rogers.com> wrote:
>
> Is this a real-life encounter of Usenet with humanity? If so, too funny,
> and just cause to promote the medium.
No question. It'a direct hit. I still can't believe it. There were
only about twenty of us in this lunatic club almost 20 years ago and
Keith knows about it..... lucky he's a friend, and not a Nulabour
police chief. Mind you, they'd have to extradite me now, and I'm
working my way into the mayor's daughter's favour.
Alan Lothian
<keith...@kwillshaw.demon.co.uk> wrote:
<avoiding Keith's awe-inspiring access to ESMR info>
>
> I have spent half my life unpicking such code. One of the problems is
> that it was often expected that the entire mess would have a short life
> and be rewritten within a few years.
And of course it still goes on. But.... it still runs for now, and
nobody has the budget to do it again properly. Hmm.
> One of the ironies of the information
> technology era is that much of the software running on the sleek new
> machines
> now available at its core uses ancient code written in Fortran and Cobol
> 30 years ago.
The analogy with genetic code is a very, very powerful one. Mother
Nature: "I sorted out the phosphate transfer business 3 billion years
ago. OK, it's not the neatest method but it works, so I'm going to go
and evolve something else and leave the phosphate transfer alone. How
about a nifty user interface? I think I'll call it 'nice ass, babe'. "
> The newer breed of programmer writes very nice user
> interfaces in languages such as C++ and C# but the guts are still good
> old fashioned F77
When that 30-years-ago generation dies off (can't be long now, unless
my memory deceives me about their shocking personal habits) there's
going to be real trouble. Some still-functioning code goes back farther
than that, too. I have this image of Old Grandad being dragged from his
nursing home in Bournemouth and presented with a huge pile of
yellowing, line-printed code. "Please, old fella, you must remember
something about it. No, nurse, hold back his medication for half an
hour or so."
Keith Willshaw
Well we still pay one gentleman approaching 70 a consultancy fee
to come in one day a week and help us with the core code, we
whippernappers in our late 50's prefer to tinker with more modern stuff :)
Keith
Arved Sandstrom
> In article <dASSm.90111$VG2....@newsfe23.ams2>, Keith Willshaw
> <keith...@kwillshaw.demon.co.uk> wrote:
>> The newer breed of programmer writes very nice user
>> interfaces in languages such as C++ and C# but the guts are still good
>> old fashioned F77
>
> When that 30-years-ago generation dies off (can't be long now, unless
> my memory deceives me about their shocking personal habits) there's
> going to be real trouble. Some still-functioning code goes back farther
> than that, too. I have this image of Old Grandad being dragged from his
> nursing home in Bournemouth and presented with a huge pile of
> yellowing, line-printed code. "Please, old fella, you must remember
> something about it. No, nurse, hold back his medication for half an
> hour or so."
I've been through a couple of largish mainframe modernization projects
now (still stuck in 'em, somewhat), and my general observation is that
they are a good idea. Contrary to popular opinion, thirty or forty years
ago programming giants did *not* stride the earth and cast pearls of
code unto the masses...odds are pretty good in fact that that business
code written in the '70's is mediocre, just like it's likely to be
today. The code written in the '70's, possibly in a language that was
made obsolete thirty years ago, not only requires someone more expensive
than your average script kiddie to decipher it, but also may need a
senior business user from way back when to review the translation and
see if it still applies.
Wait too long with modernization projects, and the danger is not so much
that you can't eventually figure out the code (let's assume for sake of
argument that we've got source - if you have no source left don't even
wait to modernize), but that you have no business clue as to why the
code is doing what it very clearly is doing. I saw a fair bit of this
occur over the past few years on some of these projects I was/am
associated with - "well, we're not entirely sure why this subroutine
does that, so the new Java method will do exactly what it does."
Enough of this latter problem - poorly documented code that nobody can
trace back to an original business need - and you run the risk of having
the legacy code tell you what your requirements are. "Well, back in 1975
somebody obviously thought it necessary to run the PL654TODS313
subroutine every week on the Snarfinex data tables, so until someone now
can tell me why we don't have to do that anymore we're going to keep on
doing it."
As an aside, I'm starting to lean towards the idea that all you actually
modernize is the data itself. Data gets old and crufty just like code
does. As for the code, my gut feeling now - wonderful propagandized
transformation technologies aside - is that it's cheaper and more
reliable to do a greenfield rewrite.
AHS
Alan Lothian
<dce...@hotmail.com> wrote:
> Alan Lothian wrote:
> > When that 30-years-ago generation dies off (can't be long now, unless
> > my memory deceives me about their shocking personal habits) there's
> > going to be real trouble. Some still-functioning code goes back farther
> > than that, too. I have this image of Old Grandad being dragged from his
> > nursing home in Bournemouth and presented with a huge pile of
> > yellowing, line-printed code. "Please, old fella, you must remember
> > something about it. No, nurse, hold back his medication for half an
> > hour or so."
>
> I've been through a couple of largish mainframe modernization projects
> now (still stuck in 'em, somewhat), and my general observation is that
> they are a good idea. Contrary to popular opinion, thirty or forty years
> ago programming giants did *not* stride the earth and cast pearls of
> code unto the masses...odds are pretty good in fact that that business
> code written in the '70's is mediocre, just like it's likely to be
> today.
Arved, you know a helluva lot more about this game than I do, but I am
not completely ignorant. If you read my first post on this thread, you
will have noted that the 1973 "giants on the earth" of my story
constituted a pregnant woman living in a tent and working 12-hour
shifts.
> The code written in the '70's, possibly in a language that was
> made obsolete thirty years ago, not only requires someone more expensive
> than your average script kiddie to decipher it, but also may need a
> senior business user from way back when to review the translation and
> see if it still applies.
Which brings us back to Old Grandad, only now he's not a programmer,
he's a gin-soaked retired executive. Same problem. "Fucked if I know,
old boy. It was all a long time ago. Now that nifty little Samantha in
Accounts, I remember all about her. Join me in a G & T?."
<snippaggio>
>
> Enough of this latter problem - poorly documented code that nobody can
> trace back to an original business need - and you run the risk of having
> the legacy code tell you what your requirements are.
Now *that* is a powerful and interesting point, which I ought to have
thought of myself but didn't.
> "Well, back in 1975
> somebody obviously thought it necessary to run the PL654TODS313
> subroutine every week on the Snarfinex data tables, so until someone now
> can tell me why we don't have to do that anymore we're going to keep on
> doing it."
Think cell biology.
>
> As an aside, I'm starting to lean towards the idea that all you actually
> modernize is the data itself. Data gets old and crufty just like code
> does. As for the code, my gut feeling now - wonderful propagandized
> transformation technologies aside - is that it's cheaper and more
> reliable to do a greenfield rewrite.
In principle, I am sure you are right. But not if you're the British
government, which regularly spends billions and billions of milk-bottle
tops (or pounds sterling as once they were) on huge software projects
that don't work. Main (but by no means only) reason, of course, is
constant spec-changing, often by competing bits of government, who
can't or won't communicate with each other.
While I don't doubt that sloppy programmers contribute to these
disasters, the real driving force pushing things over the cliff is
incompetent management. It was ever thus.
Keith Willshaw
A few things come to mind here
1) The Data very often needs to be preserved. If you are dealing with data
used to
design and maintain nuclear power plants you cant just throw it away because
you
think its 'crutty'
2) You need a method of reconfiguring that data to meet the needs
of new functionallity while maintaining its integrity and removing database
corruption.
3) You need robust mechanisms to import, export and archive such data
as well as robust audit trails.
4) Sometimes the old adage of 'if it aint broke dont fix it' is true.
Structured
maintainable code can be written in any language and some of the worst
sphagetti I have seen was written using C++ and C#
I have personal experience with two engineering database products that were
written in the early 1980's and which are still used today. The nuclear
power
companies that use them (no names , no pack drill but they are European)
require
the software vendors to support them until at least 2018. The interesting
thing
is that both products are still market leaders in their field and can handle
far
larger models than modern competitors that were written using .NET.
Now the software has transitioned from Prime minicomputers through VAX and
Unix to PC platforms and the GUI has been rewritten several times. Starting
with
GINO and then transitioning through Motif to Windows but the core database,
query and calculation code has scarcely changed. Recently we implemented
full XML I/O capability, the parser was written in Fortran 77 so it could
directly access the subroutines used by the database engine. Its performance
is VERY good and its very robust.
I have seen a number of big bang style rewrites of similar applications fail
disastrously so am somewhat sceptical when the claim is made that such a
policy would be cheaper and more reliable.
Keith
Roger Conroy
"Frogwatch" <dbo...@mindspring.com> wrote in message
news:3bb42199-2e79-4d01...@u7g2000yqm.googlegroups.com...
> In one of the e-mails from the hacked list from the University of East
> Anglia on the subject of Climate Change and global warming, a
> programmer complains that the data is so bad that for some reason the
> sum of the data squared keeps coming out negative. This means the
> data must be................ (try to remember your middle school math
> here).
One cannot draw any logical conclusion about the data but the calculator is
clearly FUBAR.
frank
> Arved Sandstrom <dces...@hotmail.com> wrote:
>
> :
> :As for the code, my gut feeling now - wonderful propagandized
> :transformation technologies aside - is that it's cheaper and more
> :reliable to do a greenfield rewrite.
>
> This is almost always true. Software tends to grow randomly as
> features are added and will eventually outgrow its original design,
> becoming more and more fragile and unmaintainable with time. I'm a
> big fan of "burn it to the ground and start over from requirements".
>
> --
> "The reasonable man adapts himself to the world; the unreasonable
> man persists in trying to adapt the world to himself. Therefore,
> all progress depends on the unreasonable man."
> --George Bernard Shaw
Try that with zzyzx and O'Keefian spaghetti code. Hell get the manual
from AFFTC. Page one, we don't know what this does and we think this
is how it works. Pretty much first paragraph in a nutshell.
And yeah, everything currently flying had its data go through it.