A Math Question (really!)

At the risk of polluting sci.engr.control with cross-posted, slightly OT 
material:

I have had clients send me contracts asking me to indemnify them against 
any and all damage caused to their company by my work.  (FYI, according 
to my $6/minute lawyer, "indemnify" means "insure", and I'm not an 
insurance company).

Everything I do is in the form of fairly abstract analysis and design, 
and it either gets embodied into software by my clients' software 
engineers, or I do just the algorithms which then get embedded into my 
clients' software.  So the performance of _anything_ I do is completely 
at the mercy of my clients' engineering process -- and I've only worked 
for one company, as a consultant, who really had a "good" software 
quality process (and they had to, 'cause the FDA looked over their 
shoulder).

So I could easily see a situation where I do everything right, my client 
screws up the implementation, and I find myself sitting in front of a 
jury of 12 hairdressers, trying to explain software quality practices vs. 
good algorithms.

As I see it, for every right way to embody my work in software, there is 
an infinite number of wrong ways.

Since there just has to be an infinite number of _right_ ways to embody 
my work in software, it leads to the math question:

What sort of infinity is the number of wrong ways to do software, since 
for any given problem there's an infinite number of right ways to solve 
it, and for any given right solution there's an infinite number of wrong 
solutions?

Is it just Aleph 1 (whose definition I dimly remember), or is it Aleph 2, 
or some other infinity?  I _think_, assuming that there are an infinite 
_integer_ number of ways (right and wrong) to do it, then its the same 
infinity both ways (there's a clever and easy proof showing that a 2D 
infinite grid of points has a 1:1 mapping onto a 1D line of points).

So, what do _you_ think?

-- 
http://www.wescottdesign.com

On Sat, 24 Jan 2009 14:45:48 -0600, Tim Wescott <tim@seemywebsite.com>
wrote:

>On Sat, 24 Jan 2009 15:23:23 -0500, Jerry Avins wrote:
>
>> Tim Wescott wrote:
>>> At the risk of polluting sci.engr.control with cross-posted, slightly
>>> OT material:
>>> 
>>> I have had clients send me contracts asking me to indemnify them
>>> against any and all damage caused to their company by my work.  (FYI,
>>> according to my $6/minute lawyer, "indemnify" means "insure", and I'm
>>> not an insurance company).
>>> 
>>> Everything I do is in the form of fairly abstract analysis and design,
>>> and it either gets embodied into software by my clients' software
>>> engineers, or I do just the algorithms which then get embedded into my
>>> clients' software.  So the performance of _anything_ I do is completely
>>> at the mercy of my clients' engineering process -- and I've only worked
>>> for one company, as a consultant, who really had a "good" software
>>> quality process (and they had to, 'cause the FDA looked over their
>>> shoulder).
>>> 
>>> So I could easily see a situation where I do everything right, my
>>> client screws up the implementation, and I find myself sitting in front
>>> of a jury of 12 hairdressers, trying to explain software quality
>>> practices vs. good algorithms.
>>> 
>>> As I see it, for every right way to embody my work in software, there
>>> is an infinite number of wrong ways.
>>> 
>>> Since there just has to be an infinite number of _right_ ways to embody
>>> my work in software, it leads to the math question:
>>> 
>>> What sort of infinity is the number of wrong ways to do software, since
>>> for any given problem there's an infinite number of right ways to solve
>>> it, and for any given right solution there's an infinite number of
>>> wrong solutions?
>>> 
>>> Is it just Aleph 1 (whose definition I dimly remember), or is it Aleph
>>> 2, or some other infinity?  I _think_, assuming that there are an
>>> infinite _integer_ number of ways (right and wrong) to do it, then its
>>> the same infinity both ways (there's a clever and easy proof showing
>>> that a 2D infinite grid of points has a 1:1 mapping onto a 1D line of
>>> points).
>>> 
>>> So, what do _you_ think?
>> 
>> I think it's Aleph null, actually. (I think that's what you had in mind
>> when you wrote Aleph 1.)
>> 
>> First of all, you need to make clear the difference between your work,
>> and the application (by others) of your work, and to rule out the
>> second.
>> 
>> Then you need to know the outside extent of the potential liability, so
>> you know how much insurance to buy and to add to your BoM. That should
>> sober them up!
>> 
>> Jerry
>
>I just say "I'm not an insurance company" and leave it at that.  If I 
>really needed the work my best bet would probably be to get a regular job.

When I see the clause, I strike it out and refuse the work if they
insist.  Usually, if needed, the simple explanation that I'd protect
them about as well as a piece of tissue paper facing a blowtorch is
enough to clarify the situation and let them realize that it makes no
sense at all.

Jon

On 2009-01-24, Tim Wescott <tim@seemywebsite.com> wrote:
>
> I have had clients send me contracts asking me to indemnify them against 
> any and all damage caused to their company by my work.  (FYI, according 
> to my $6/minute lawyer, "indemnify" means "insure", and I'm not an 
> insurance company).

But there *are* liability insurance companies.  If you needed a contract
and were unable to negotiate that clause out, just find an insurance
company that *will* take the risk and pass your insurance cost on to the
client.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Ben Jackson  <ben@ben.com> wrote:

>But there *are* liability insurance companies.  If you needed a contract
>and were unable to negotiate that clause out, just find an insurance
>company that *will* take the risk and pass your insurance cost on to the
>client.

True, but there's some jargon to consider.  "General Liability"
insurance does not cover this type of problem.  You need
E&O (Errors and Omissions)insurance and it is costly.

I'm not entirely sure how practical it is to buy such insurance
for just one problem contract.  Maybe someone with experience
on this point can comment.

Steve

Tim Wescott wrote:

> At the risk of polluting sci.engr.control with cross-posted, slightly OT 
> material:
> 
> I have had clients send me contracts asking me to indemnify them against 
> any and all damage caused to their company by my work.

[...]

The real question is if you are worth to be sued.
The indemnification clause is not that unusual, however it implies 
automatically no more and no less than if you damage their equipment, 
you got to pay. If they want to make you accountable for all kinds of 
direct and indirect consequences, that's a NP-complete problem of theirs 
regardless of this clause.

 From my personal experience, the more BS is included in the contract, 
the less is their interest in the actual job to be done.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Tim Wescott wrote:
> 
> At the risk of polluting sci.engr.control with cross-posted,
> slightly OT material:
> 
> I have had clients send me contracts asking me to indemnify them
> against any and all damage caused to their company by my work. 
> (FYI, according to my $6/minute lawyer, "indemnify" means
> "insure", and I'm not an insurance company).
> 
> Everything I do is in the form of fairly abstract analysis and
> design, and it either gets embodied into software by my clients'
> software engineers, or I do just the algorithms which then get
> embedded into my clients' software.  So the performance of
> _anything_ I do is completely at the mercy of my clients'
> engineering process -- and I've only worked for one company, as
> a consultant, who really had a "good" software quality process
> (and they had to, 'cause the FDA looked over their shoulder).
> 
> So I could easily see a situation where I do everything right,
> my client screws up the implementation, and I find myself
> sitting in front of a jury of 12 hairdressers, trying to
> explain software quality practices vs. good algorithms.

I think you should consult a real lawyer.  I also suspect you are
getting trapped by historic advice from company lawyers, who have
no idea what is being bought and sold, and the plebes are just
passing that advice on to you.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Jan 24, 3:07&#4294967295;pm, Tim Wescott <t...@seemywebsite.com> wrote:
> At the risk of polluting sci.engr.control with cross-posted, slightly OT
> material:
>
> I have had clients send me contracts asking me to indemnify them against
> any and all damage caused to their company by my work. &#4294967295;(FYI, according
> to my $6/minute lawyer, "indemnify" means "insure", and I'm not an
> insurance company).
>
> Everything I do is in the form of fairly abstract analysis and design,
> and it either gets embodied into software by my clients' software
> engineers, or I do just the algorithms which then get embedded into my
> clients' software. &#4294967295;So the performance of _anything_ I do is completely
> at the mercy of my clients' engineering process -- and I've only worked
> for one company, as a consultant, who really had a "good" software
> quality process (and they had to, 'cause the FDA looked over their
> shoulder).
>
> So I could easily see a situation where I do everything right, my client
> screws up the implementation, and I find myself sitting in front of a
> jury of 12 hairdressers, trying to explain software quality practices vs.
> good algorithms.
>
> As I see it, for every right way to embody my work in software, there is
> an infinite number of wrong ways.
>
> Since there just has to be an infinite number of _right_ ways to embody
> my work in software, it leads to the math question:
>
> What sort of infinity is the number of wrong ways to do software, since
> for any given problem there's an infinite number of right ways to solve
> it, and for any given right solution there's an infinite number of wrong
> solutions?
>
> Is it just Aleph 1 (whose definition I dimly remember), or is it Aleph 2,
> or some other infinity? &#4294967295;I _think_, assuming that there are an infinite
> _integer_ number of ways (right and wrong) to do it, then its the same
> infinity both ways (there's a clever and easy proof showing that a 2D
> infinite grid of points has a 1:1 mapping onto a 1D line of points).
>
> So, what do _you_ think?
>
> --http://www.wescottdesign.com

Hello Tim,

Several of my clients insisted on the insurance and since the
contracts were very lucrative, I got the "errors and omissions"
insurance. Even though the insurance is not cheap, it was less than 1%
of the contract's value. You can try to strike it out and smaller
clients may give in, but I had contracts with two of the top four
cellular providers where I had all of the info on their system,
locations, channel plans, access codes, you name it. They just wanted
their infrastructure protected.

I recall one client wanted me to basically guarantee that the work I
did did not violate any patents. I said I can't guarantee that. And
years later his project is still unbuilt! Just my 2 cents worth.

Clay

On Sat, 24 Jan 2009 19:29:03 -0500, CBFalconer wrote:

> Tim Wescott wrote:
>> 
>> At the risk of polluting sci.engr.control with cross-posted, slightly
>> OT material:
>> 
>> I have had clients send me contracts asking me to indemnify them
>> against any and all damage caused to their company by my work. (FYI,
>> according to my $6/minute lawyer, "indemnify" means "insure", and I'm
>> not an insurance company).
>> 
>> Everything I do is in the form of fairly abstract analysis and design,
>> and it either gets embodied into software by my clients' software
>> engineers, or I do just the algorithms which then get embedded into my
>> clients' software.  So the performance of _anything_ I do is completely
>> at the mercy of my clients' engineering process -- and I've only worked
>> for one company, as a consultant, who really had a "good" software
>> quality process (and they had to, 'cause the FDA looked over their
>> shoulder).
>> 
>> So I could easily see a situation where I do everything right, my
>> client screws up the implementation, and I find myself sitting in front
>> of a jury of 12 hairdressers, trying to explain software quality
>> practices vs. good algorithms.
> 
> I think you should consult a real lawyer.  I also suspect you are
> getting trapped by historic advice from company lawyers, who have no
> idea what is being bought and sold, and the plebes are just passing that
> advice on to you.

Oh, I have no problem knowing what to do, having already gotten advise 
from my (real) lawyer:  "Tim, you're a consultant, not an insurance 
company.  Don't sell insurance".  (I like my lawyer -- he and I agree on 
everything important, he just knows the right way to put it down in 
writing).

-- 
http://www.wescottdesign.com

Tim Wescott wrote:
> At the risk of polluting sci.engr.control with cross-posted, slightly OT 
> material:
> 
> I have had clients send me contracts asking me to indemnify them against 
> any and all damage caused to their company by my work.  (FYI, according 
> to my $6/minute lawyer, "indemnify" means "insure", and I'm not an 
> insurance company).
> 

Do they also offer to pay you for any and all benefit to their company 
through your work?  If not, the contract is pretty unbalanced !

<snip>
> 
> As I see it, for every right way to embody my work in software, there is 
> an infinite number of wrong ways.
> 
> Since there just has to be an infinite number of _right_ ways to embody 
> my work in software, it leads to the math question:
> 
> What sort of infinity is the number of wrong ways to do software, since 
> for any given problem there's an infinite number of right ways to solve 
> it, and for any given right solution there's an infinite number of wrong 
> solutions?
> 
> Is it just Aleph 1 (whose definition I dimly remember), or is it Aleph 2, 
> or some other infinity?  I _think_, assuming that there are an infinite 
> _integer_ number of ways (right and wrong) to do it, then its the same 
> infinity both ways (there's a clever and easy proof showing that a 2D 
> infinite grid of points has a 1:1 mapping onto a 1D line of points).
> 
> So, what do _you_ think?
> 

You are thinking of Aleph 0, also known as "countably infinite".  It's 
basically the number of integers.

It's easy to see that the number of possible programs is countably 
infinite (disregarding silly things, like limits to the size of the 
universe - this is maths, not reality).  Any computable algorithm can be 
run on any Turing-complete machine, such as a Turing machine, a 
Universal Register Machine, or an AVR processor with unlimited memory 
(*not* infinite memory, but *unlimited* memory, meaning you never reach 
its end).  Any software you or anyone else writes can run on this AVR, 
given enough time and memory resources (for example, you could port QEMU 
to it and run Windows in an emulator).

So this gives you a way to turn any possible algorithm or 
implementation, working or not working, into a program on your unlimited 
AVR.  Take the binary object code, think of it as a *very* big integer 
in binary.  There you have a mapping from the space of possible programs 
into the set of integers.  Conversely, any integer could be treated as 
the AVR's program, giving you a reverse mapping (for the really 
pedantic, you can do some tricks to avoid invalid opcodes and the like).

Thus the number of possible programs is countably infinite - aleph 0.

For your interest and information, aleph 1 is two to the power aleph 0. 
  This is clearly bigger than aleph 0 - it's the number of real numbers. 
  The really interesting question is if there is anything between aleph 
0 and aleph 1...

As for your proof about the number of points on a 2D grid being the same 
as the number of points on a ruled line, take a piece of squared paper. 
  Start with a cross in the middle of the page, and then draw a spiral 
through the other crosses, getting gradually bigger.

Since binary comes naturally to these newsgroups, an easy alternative is 
to consider your X-Y points as having two coordinates in binary.  Map 
each X-Y point to your line by mapping bit n of the X coordinate to bit 
2n of your line point, and bit n of the Y coordinate to bit (2n + 1) of 
the line point.

mvh.,

David

David Brown wrote:

> It's easy to see that the number of possible programs is countably 
> infinite (disregarding silly things, like limits to the size of the 
> universe - this is maths, not reality).  Any computable algorithm can be 
> run on any Turing-complete machine, such as a Turing machine, a 
> Universal Register Machine, or an AVR processor with unlimited memory 
> (*not* infinite memory, but *unlimited* memory, meaning you never reach 
> its end).  Any software you or anyone else writes can run on this AVR, 
> given enough time and memory resources (for example, you could port QEMU 
> to it and run Windows in an emulator).

You are right, for turing machines there are an infinite number of
programs. For AVR you'll need a modified structure, because e.g. 16 bit
absolute pointer registers are not very useful for unlimited memory. My
answer was in the context of the question, how many ways there are for Tim
Wescott to do it, maybe I misunderstood it.

> So this gives you a way to turn any possible algorithm or 
> implementation, working or not working, into a program on your unlimited 
> AVR.  Take the binary object code, think of it as a *very* big integer 
> in binary.  There you have a mapping from the space of possible programs 
> into the set of integers.  Conversely, any integer could be treated as 
> the AVR's program, giving you a reverse mapping (for the really 
> pedantic, you can do some tricks to avoid invalid opcodes and the like).
> 
> Thus the number of possible programs is countably infinite - aleph 0.

Another ineresting thing is, that the number of working program is aleph_0
and the number of non-working programs is aleph_0, too. This is because of
the nice property that aleph_0 + aleph_0 = aleph_0. For trying to
understand this, Hilbert's Grand Hotel helps:

http://en.wikipedia.org/wiki/Hilbert's_paradox_of_the_Grand_Hotel

> For your interest and information, aleph 1 is two to the power aleph 0. 
>   This is clearly bigger than aleph 0 - it's the number of real numbers. 
>   The really interesting question is if there is anything between aleph 
> 0 and aleph 1...
> 
> As for your proof about the number of points on a 2D grid being the same 
> as the number of points on a ruled line, take a piece of squared paper. 
>   Start with a cross in the middle of the page, and then draw a spiral 
> through the other crosses, getting gradually bigger.

I don't understand this proof. I assume you mean a archimedean spiral like
this:

http://en.wikipedia.org/wiki/Archimedean_spiral

For which number a and b all points on a grid with infinite small distance
between points, will be coverd?

> Since binary comes naturally to these newsgroups, an easy alternative is 
> to consider your X-Y points as having two coordinates in binary.  Map 
> each X-Y point to your line by mapping bit n of the X coordinate to bit 
> 2n of your line point, and bit n of the Y coordinate to bit (2n + 1) of 
> the line point.

Which point on the line is the point (pi, sqrt(2)) on the plane?

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de