Guy Macon, do you have anything to contribute?

Spehro Pefhany wrote:
On Mon, 24 May 2004 22:30:59 -0400, the renowned KR Williams
krw@att.biz> wrote:


Just as an aside... Has anyone who loves algebraic calculators
tried to program one? ...as in write the assembler code to
produce the crap?


I think it's pretty trivial- you just use the same setup as you would
for an RPN calculator but with another (narrow) stack for the pending
operators. Whenever the user hits open-paren or you run into a higher
precedence operator you push the intermediate value and pending
operator into the stacks. When the opposite happens you perform the
operation and drop the stack .
Right- that was a homework assignment in my undergraduate course using
PL/I about 10,000 years ago- we were experimenting with stacks at the
time. The problem with RPN is not learning it- but unlearning it, it is
impossible to use a non-RPN calculator again.
 
On Mon, 24 May 2004 22:30:59 -0400, KR Williams wrote:

Just as an aside... Has anyone who loves algebraic calculators
tried to program one? ...as in write the assembler code to
produce the crap? Humans and machines really do think in RPN,
whether they want to admit it or not. ;-)
Computers do for sure, but I can't recall the last time I thought " load
accumulator with beer 6 multiply".


--
"Just machines that make big decisions
programmed by fellas with compassion and vision."
-D. Fagen
(remove yomama)
 
In article <40B34517.7090904@nospam.com>,
Fred Bloggs <nospam@nospam.com> wrote:

Right- that was a homework assignment in my undergraduate course
using PL/I about 10,000 years ago- we were experimenting with
stacks at the time. The problem with RPN is not learning it- but
unlearning it, it is impossible to use a non-RPN calculator
again.
The problem with RPN is exactly that... someone
formalised it with a name.

Engineers instinctively understand the technique of
putting objects onto a stack and working on them in
a top-down fashion.

But what causes trouble it to start off by formalising
it with a name (RPN) and then (worse still) going into
a totally uneccessary and overcomplicated comparison
with (say) Basic's operators and operator precedence.

--
Tony Williams.
 
In article <2ff6b01grn4b0pf1iots8su55ie1oc17lq@4ax.com>,
Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:
[.. evaluation ..]
I think it's pretty trivial- you just use the same setup as you would
for an RPN calculator but with another (narrow) stack for the pending
operators. Whenever the user hits open-paren or you run into a higher
precedence operator you push the intermediate value and pending
operator into the stacks. When the opposite happens you perform the
operation and drop the stack .
Actually, it is easier to always push the value etc. When you hit an
equal or lower priority operator you pop and exec. This way you save
having to have two copies of the code to call the exec.

On a micro with call, return, push, and pop operations it is very easy to
do in assembly. Every 8051 based project I do ends up with the little
debugger code running on it at least during development. It does all the
usual math etc and lets me flog the various busses and ports and things.




--
--
kensmith@rahul.net forging knowledge
 
"Activ8" <reply2group@ndbbm.net> wrote in message
news:1k1bex73ypa3u.dlg@news.individual.net...
On Mon, 24 May 2004 13:33:37 -0700, Richard Henry wrote:

"Activ8" <reply2group@ndbbm.net> wrote in message
news:ica3bixwej4d$.dlg@news.individual.net...

The two or three videos of pump fires they showed on the news, were
extinguished pretty quickly, but one person's clothes caught on fire
and another customer beat it out with his jacket. Ouch.

in re: "...beat it out with his jacket..."

A few months ago, I was driving around in my little town and a big old
ugly
4WD pickup passed by me but stopped ahead of me at a red light. When
the
light turned green, the truck didn't go. Then I noticed smoke pouring
out
of the truck's engine compartment, and then the driver leaping out and
popping the hood. He ripped off his jacket and started beating on what
looked like a fuel fire. Unfortunatley, he was wearing a down-filled
nylon
jacket. Pieces of the nylon layer vaporized (or flash-burned) every
time he
hit the engine block with it, and feathers were floating downwind.

I pulled over to the curb, well out of the fire range, and walked over
with
the dry-powder fire extinguiisher I keep under the driver seat of my old
Jeep. He was able to get the fire out with one good squirt.
I bought that one in 91, at the latest. It has been strapped by a bungee to
the side of the seat ever since. After the driver was done spraying down
everything in his engine compartment that was smoking, the extinguisher was
completely empty.
 
In article <VvAsc.23009$ZQ.9390@nwrddc03.gnilink.net>,
null@example.net says...
"KR Williams" <krw@att.biz> wrote in message

Just as an aside... Has anyone who loves algebraic calculators
tried to program one? ...as in write the assembler code to
produce the crap?

Well, uh, yeah, that's why people use machines. Same reason you
use a wrench on a bolt instead of your teeth. :)
Think about *teaching*. I used a calculator as a teaching
device. I thought it was something everyone understood.
Humans and machines really do think in RPN,
whether they want to admit it or not. ;-)

Totally untrue. Humans think in a fractal heuristic gestalt, and machines
don't think at all.
Pure poppycock!

--
Keith
 
In article <40B34517.7090904@nospam.com>, nospam@nospam.com
says...
Spehro Pefhany wrote:
On Mon, 24 May 2004 22:30:59 -0400, the renowned KR Williams
krw@att.biz> wrote:


Just as an aside... Has anyone who loves algebraic calculators
tried to program one? ...as in write the assembler code to
produce the crap?


I think it's pretty trivial- you just use the same setup as you would
for an RPN calculator but with another (narrow) stack for the pending
operators. Whenever the user hits open-paren or you run into a higher
precedence operator you push the intermediate value and pending
operator into the stacks. When the opposite happens you perform the
operation and drop the stack .

Right- that was a homework assignment in my undergraduate course using
PL/I about 10,000 years ago- we were experimenting with stacks at the
time. The problem with RPN is not learning it- but unlearning it, it is
impossible to use a non-RPN calculator again.
Well, this *is* the unvarnished truth. I cannot use an algebraic
calculator to this day. It's just not *normal*. Now, if only mu
phone had an RPN calculator...

--
Keith
 
In article <cn6w0nyowqth.1mjp2md8kgm3w.dlg@40tude.net>,
stephensyomamadigital@earthlink.net says...
On Mon, 24 May 2004 22:30:59 -0400, KR Williams wrote:

Just as an aside... Has anyone who loves algebraic calculators
tried to program one? ...as in write the assembler code to
produce the crap? Humans and machines really do think in RPN,
whether they want to admit it or not. ;-)

Computers do for sure, but I can't recall the last time I thought " load
accumulator with beer 6 multiply".
Oh, come on!

Ninety-nine bottles of beer on the stack. Pop one down, pass it
around, ninety-eight bottles of beer on the stack...

You've never heard the song? You must have been a mud-stick in
college. ;-)

--
Keith
 
KR Williams <krw@att.biz> wrote:
Well, this *is* the unvarnished truth. I cannot use an algebraic
calculator to this day. It's just not *normal*. Now, if only mu
phone had an RPN calculator...
I seriously doubt that the folks who program the 'regular' cell phone
calculators bother to use them. At least on mine (Sanyo something-8100), it
uses the 4-way keypad to scroll through your choice of operators... +, -, *,
/, and =. Pressing the 'OK' button (in the center of the 4-way keypad)
executes that function.

Surely assigning + / - / * / / to the various 'ways' on the 4-way keypad and
making 'OK' be '=' would have been simpler and faster for the end user?! It
seems utterly brain-damaged to implement this the way they did. I suppose
they're worried that people will forget which keypad direction corresponds
to which operator and will have lost the manual and hence they'll get tons
of support calls from people who couldn't manage to re-discover it on their
own...

---Joel
 
"Joel Kolstad" <JKolstad71HatesSpam@Yahoo.Com> wrote in message
news:c913ht$jcn$1@news.oregonstate.edu...
KR Williams <krw@att.biz> wrote:
Well, this *is* the unvarnished truth. I cannot use an algebraic
calculator to this day. It's just not *normal*. Now, if only mu
phone had an RPN calculator...

I seriously doubt that the folks who program the 'regular' cell phone
calculators bother to use them. At least on mine (Sanyo something-8100),
it
uses the 4-way keypad to scroll through your choice of operators... +, -,
*,
/, and =. Pressing the 'OK' button (in the center of the 4-way keypad)
executes that function.

Surely assigning + / - / * / / to the various 'ways' on the 4-way keypad
and
making 'OK' be '=' would have been simpler and faster for the end user?!
It
seems utterly brain-damaged to implement this the way they did. I suppose
they're worried that people will forget which keypad direction corresponds
to which operator and will have lost the manual and hence they'll get tons
of support calls from people who couldn't manage to re-discover it on
their
own...

---Joel
Alas Joel, "utterly brain-damaged" is often an accurate description of the
so-called "engineers" who design such user-interface software. My last stove
had an electronic clock, and a countdown timer. If the power goes off the
clock flashes. If the clock flashes, the timer will not work. And a special
long pointy thing is required to stop the clock flashing. And we were in an
area that had lots of power outages. Why the hell would they stop the
(relative) timer working when the clock is flashing?!? wankers.

The stupidest sw decision I have EVER seen was a git I unfortunately work
with. Our product has a 10Mbps RS485 interface, and is sealed to IP67. This
twat wrote a "shut-up" command which turned off the RS485 link, then wrote
its status to an EEPROM so power-cycling wouldnt turn it back on! Then
another twit, in a fit of inspired stupidity, did a global broadcast of this
suicide command (all of these were completely untested), permanently
disabling a CUSTOMERS entire video screen. fuckwits. Our techs had to remove
14 screws to get each individual 12x12 pixel module out and apart, so they
could use JTAG to get the CPU out of its latched state and change the EEPROM
contents. Luckily there was only 1,000 modules (do the maths). Our techs
were NOT happy (hey, whats 28,000 screws between friends - they all had to
be put back, too). Oddly enough there was no actual requirement to turn the
RS485 off - the "programmer" just arbitrarily decided to do it. When asked
why he chose to latch it in EEPROM, he shrugged his shoulders, and said he
arbitrarily chose to do so. AAAAAAAAAAARHG!!!! We re-wrote our video server
app to prevent that command ever being used. Then made him re-write his sw
to remove the suicide command.

Cheers
Terry
 
Terry Given <the_domes@xtra.co.nz> says...

The stupidest sw decision I have EVER seen was a git I unfortunately work
with. Our product has a 10Mbps RS485 interface, and is sealed to IP67. This
twat wrote a "shut-up" command which turned off the RS485 link, then wrote
its status to an EEPROM so power-cycling wouldnt turn it back on! Then
another twit, in a fit of inspired stupidity, did a global broadcast of this
suicide command (all of these were completely untested), permanently
disabling a CUSTOMERS entire video screen. fuckwits. Our techs had to remove
14 screws to get each individual 12x12 pixel module out and apart, so they
could use JTAG to get the CPU out of its latched state and change the EEPROM
contents. Luckily there was only 1,000 modules (do the maths). Our techs
were NOT happy (hey, whats 28,000 screws between friends - they all had to
be put back, too). Oddly enough there was no actual requirement to turn the
RS485 off - the "programmer" just arbitrarily decided to do it. When asked
why he chose to latch it in EEPROM, he shrugged his shoulders, and said he
arbitrarily chose to do so. AAAAAAAAAAARHG!!!! We re-wrote our video server
app to prevent that command ever being used. Then made him re-write his sw
to remove the suicide command.
I see two stupidities here The obvious one is what the "programmer" did
(*Please* tell me they fired him!) The other stupidity is the methods
your company uses to develop products. How does a "programmer" manage
to get his code into a thousand customer units without any peer review,
anyone signing off on his work, or any QA testing?

I would love to come visit your lovely country and set up a proper
project management system for your company, and would pare down my
normal rate to the bare minimum just for the travel opportunity.
Alas, I suspect that the same management that allows untested code
to reach the customers would reject the help. My contact info is on
my web page if I am wrong about this.

--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
have an "impossible" engineering project that only someone like
Doc Brown can solve? My resume is at http://www.guymacon.com/
 
"Guy Macon" <http://www.guymacon.com> wrote in message
news:cuGdnRlNQre91CndRVn-ug@speakeasy.net...
Terry Given <the_domes@xtra.co.nz> says...

The stupidest sw decision I have EVER seen was a git I unfortunately work
with. Our product has a 10Mbps RS485 interface, and is sealed to IP67.
This
twat wrote a "shut-up" command which turned off the RS485 link, then
wrote
its status to an EEPROM so power-cycling wouldnt turn it back on! Then
another twit, in a fit of inspired stupidity, did a global broadcast of
this
suicide command (all of these were completely untested), permanently
disabling a CUSTOMERS entire video screen. fuckwits. Our techs had to
remove
14 screws to get each individual 12x12 pixel module out and apart, so
they
could use JTAG to get the CPU out of its latched state and change the
EEPROM
contents. Luckily there was only 1,000 modules (do the maths). Our techs
were NOT happy (hey, whats 28,000 screws between friends - they all had
to
be put back, too). Oddly enough there was no actual requirement to turn
the
RS485 off - the "programmer" just arbitrarily decided to do it. When
asked
why he chose to latch it in EEPROM, he shrugged his shoulders, and said
he
arbitrarily chose to do so. AAAAAAAAAAARHG!!!! We re-wrote our video
server
app to prevent that command ever being used. Then made him re-write his
sw
to remove the suicide command.

I see two stupidities here The obvious one is what the "programmer" did
(*Please* tell me they fired him!) The other stupidity is the methods
your company uses to develop products. How does a "programmer" manage
to get his code into a thousand customer units without any peer review,
anyone signing off on his work, or any QA testing?

I would love to come visit your lovely country and set up a proper
project management system for your company, and would pare down my
normal rate to the bare minimum just for the travel opportunity.
Alas, I suspect that the same management that allows untested code
to reach the customers would reject the help. My contact info is on
my web page if I am wrong about this.

--
Guy Macon, Electronics Engineer & Project Manager for hire.
Hi Guy,

*CLONK* - the sound of a nail being hit squarely on the head. No, they didnt
fire him. The answer to your question HOW? is simple really: This guy does
what he wants, not what hes told. Which kind of makes one wonder why he
hasnt been fired. Perhaps because he is the only one who knows anything
about the embedded code and the boss is:

1) scared of the down-time associated with bringing someone else up to speed
2) trying to do whats "best" for this guy, as opposed to the company.

This guy is old and emotionally fragile (unstable is probably a better
word), with a penchant for chronic depression. He takes EVERYTHING
personally, ESPECIALLY some "young whippersnapper" like me pointing out
obvious and fundamental problems with his designs. Just to make matters
worse, he is firmly convinced he is a brilliant engineer (actually some of
the firmware he has done is truly brilliant. He just isnt a circuit
designer).

We didnt get on too well at first, because I'm somewhat pushy and he makes a
lot of mistakes. Most of the original "problems" were him not liking me
changing "his baby" even though it didnt work properly. Making it go better
just seemed to add insult to injury, and I aint exactly the sympathetic
type. After we had our responsibilities clearly spelled out by the boss
(basically hes firmware, im hardware) we actually worked OK together. I also
worked pretty hard on being "nice" - using lots of verbiage rather than my
usual "no. whats really going on is...". Problems still arose around
technical issues though - its hard to argue with someone who thinks an
amplifier with a damping factor of 0.5 is a good way of measuring square
waves. Especially when they argue that the amplifier isnt causing the
ringing, despite scope evidence to the contrary.

The frustrating part is that this guy just isnt being managed properly.
Letting him dabble (I refuse to call it engineering - he cant even solve a
1st order ODE) with electronics has proven to be costly. Part of the problem
is a change in boss - boss 1 neglected to inform boss 2 about this guys lack
of expertise and need to be carefully (and firmly) managed. the boss change
happened at the same time I moved away and became a contractor. The guy in
closest proximity to the new boss got listened to first. I have a nice
(virtual) paper trail documenting the latest round of mistakes though, and
all of my predictions have come to pass. Boss 2.0 now has a much better
understanding of who to listen to - I can sort of understand it really.
Given 2 people you dont know - a 35yr old and a 55yr old (who is crucial in
another area, and may quit if he doesnt get his own way)- who do you listen
to? I had hoped the simple mathematical proofs I had used to bolster my
original technical complaints would suffice, but alas boss 2.0 didnt appear
to comprehend them. The fact my circuitry all works is almost detrimental :}

Boss 1 is now back on the scene, to repair the chaos which ensued after he
left (boss 2 was dropped in the deep end, and was way too busy not drowning
to swim). It would seem that the disastrous management "experiment" is over,
but I am not holding my breath. These guys know what they are doing wrong.
Its just doing it right they are having difficulty with.

Actually the consultant idea is not bad. Often people are willing to accept
from outsiders what they dismiss from their own staff (Scott Adams sure has
profited from that!)


Cheers
Terry
 
On Tue, 25 May 2004 22:27:18 -0400, KR Williams wrote:

In article <cn6w0nyowqth.1mjp2md8kgm3w.dlg@40tude.net>,
stephensyomamadigital@earthlink.net says...
On Mon, 24 May 2004 22:30:59 -0400, KR Williams wrote:

Just as an aside... Has anyone who loves algebraic calculators
tried to program one? ...as in write the assembler code to
produce the crap? Humans and machines really do think in RPN,
whether they want to admit it or not. ;-)

Computers do for sure, but I can't recall the last time I thought " load
accumulator with beer 6 multiply".

Oh, come on!

Ninety-nine bottles of beer on the stack. Pop one down, pass it
around, ninety-eight bottles of beer on the stack...

You've never heard the song? You must have been a mud-stick in
college. ;-)
Well, I managed to sober up long enough to attend algebra class...
--
"Just machines that make big decisions
programmed by fellas with compassion and vision."
-D. Fagen
(remove yomama)
 
In article <c913ht$jcn$1@news.oregonstate.edu>,
JKolstad71HatesSpam@Yahoo.Com says...
KR Williams <krw@att.biz> wrote:
Well, this *is* the unvarnished truth. I cannot use an algebraic
calculator to this day. It's just not *normal*. Now, if only mu
phone had an RPN calculator...

I seriously doubt that the folks who program the 'regular' cell phone
calculators bother to use them. At least on mine (Sanyo something-8100), it
uses the 4-way keypad to scroll through your choice of operators... +, -, *,
/, and =. Pressing the 'OK' button (in the center of the 4-way keypad)
executes that function.

Surely assigning + / - / * / / to the various 'ways' on the 4-way keypad and
making 'OK' be '=' would have been simpler and faster for the end user?! It
seems utterly brain-damaged to implement this the way they did. I suppose
they're worried that people will forget which keypad direction corresponds
to which operator and will have lost the manual and hence they'll get tons
of support calls from people who couldn't manage to re-discover it on their
own...
Well, I was only being facetious about the cell phone. My cell
phone (LG 4400) calculator is as you suggest. THe *,/,-,+
operators are on the 4-way keypad, with = being the 'ok'. The
decimal point is the '*' key and change-sign on the '#'. A
picture of the 4-way pad and the *# keys are displayed on the LCD
screen, so no manual needed. Perhaps you designed the 4400
calculator? ;-)

--
Keith
 
So, speaking of slide rules... here's a fun little program that at
first seems rather odd, but it's kinda fun. I do enjoy the whole
technological race to build equipment so high tech, it emulates what
already works well.

http://www.thesonicfrog.com/sliderule/sliderule.zip

Have fun!
 
Terry Given <the_domes@xtra.co.nz> says...

Actually the consultant idea is not bad. Often people are willing
to accept from outsiders what they dismiss from their own staff
(Scott Adams sure has profited from that!)
I have had several successful project management jobs where I
solved a major problem by:

[1] Asking the people actually doing the work for the solution that
they have had all along - but management won't listen (and of
course using my expertise to reject any unworkable "solutions"
from the people doing the work -- they aren't always right).

[2] Asking the workers if they wish me to present the solution as
being my solution or to give them full credit - the answer is
usually to do whatever will convince management.

[3] Laying out a detailed plan implementing the solution that they
had ignored when their own people suggested it.

Of course there are other cases where I actually had to do some work! :)

If you think it's worth trying, please take a good look at my webpage
at http://www.guymacon.com/ and ask yourself whether my engineering
philosophy and the way I approach problems is agreeable to you. The
page on Mattel has details on how I handled a situation much like what
you describe. If I pass that test, let's talk about whether your
management might be willing to bring in a consultant. I think I can
work with your "crucial in another area, and may quit if he doesn't
get his own way" cow-orker and get the best out of him - this is a
situation I have dealt with many times.

--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
have an "impossible" engineering project that only someone like
Doc Brown can solve? My resume is at http://www.guymacon.com/
 
On Wed, 26 May 2004 10:10:33 -0700, Guy Macon
<http://www.guymacon.com> wrote:

[snip]
If you think it's worth trying, please take a good look at my webpage
at http://www.guymacon.com/ and ask yourself whether my engineering
philosophy and the way I approach problems is agreeable to you. The
page on Mattel has details on how I handled a situation much like what
you describe. If I pass that test, let's talk about whether your
management might be willing to bring in a consultant. I think I can
work with your "crucial in another area, and may quit if he doesn't
get his own way" cow-orker and get the best out of him - this is a
situation I have dealt with many times.
I think he had already died by February, 2000, but did you know Jack
Ryan?

Jack tried to hire me in 1968, but Mrs. Handler wouldn't allow the
benefits I insisted on to endure living in So Cal ;-)

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

I love to cook with wine. Sometimes I even put it in the food.
 
Jim Thompson <thegreatone@example.com> says...

I think he had already died by February, 2000, but did you know Jack
Ryan?
Before my time.

Jack tried to hire me in 1968, but Mrs. Handler wouldn't allow the
benefits I insisted on to endure living in So Cal ;-)
You would have been unhappy.
 
"Guy Macon" <http://www.guymacon.com> wrote in message
news:WpadnQVGW6PlUindRVn-uw@speakeasy.net...
Terry Given <the_domes@xtra.co.nz> says...

Actually the consultant idea is not bad. Often people are willing
to accept from outsiders what they dismiss from their own staff
(Scott Adams sure has profited from that!)

I have had several successful project management jobs where I
solved a major problem by:

[1] Asking the people actually doing the work for the solution that
they have had all along - but management won't listen (and of
course using my expertise to reject any unworkable "solutions"
from the people doing the work -- they aren't always right).

[2] Asking the workers if they wish me to present the solution as
being my solution or to give them full credit - the answer is
usually to do whatever will convince management.

[3] Laying out a detailed plan implementing the solution that they
had ignored when their own people suggested it.

Of course there are other cases where I actually had to do some work! :)

If you think it's worth trying, please take a good look at my webpage
at http://www.guymacon.com/ and ask yourself whether my engineering
philosophy and the way I approach problems is agreeable to you. The
page on Mattel has details on how I handled a situation much like what
you describe. If I pass that test, let's talk about whether your
management might be willing to bring in a consultant. I think I can
work with your "crucial in another area, and may quit if he doesn't
get his own way" cow-orker and get the best out of him - this is a
situation I have dealt with many times.

--
Guy Macon, Electronics Engineer & Project Manager for hire.
Hi Guy,

Having read your resume, I have little doubt that you coudl tell them what
to do. Alas they already know - its getting them to actually do it that is
the hard part (like say sacking the twit the next time he screws up).

Cheers
Terry
 
In message <spp1b01c8eur75hor6tgpnps1jh46q4gcp@4ax.com>, John Larkin
<jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> writes

<snipped>

Both. Of course, HP was dumb enough to quit making RPN calculators,
Saved!

Http://ourworld.compuserve.co.uk/BridgesSci/MCSquared.html

Cheers
--
Keith Wootten
 

Welcome to EDABoard.com

Sponsor

Back
Top