Computing infinity modulus and zero modulus
ju...@diegidio.name
than passionate about Math, so I'll simply go straight to the point in
my own "language".
I'm writing code to support Complex numbers and operations. My goal is
no operation of any kind should ever return NaN, that is no operation
should be undefined. To make the question simple, I'll focus on the
modulus operator on Reals to start from.
I have found something very promising at http://www.gwiep.net/books/parad09.htm,
and - as far as I get it - with some geometrical reasoning it defines
"zero modulus" as x%0 = 0, and infinity modulus as x%oo = x. The
problem for me is it doesn't cover all other "boundary" cases like oo
%y or oo%oo.
My question is, is there any consistent and well founded way to
achieve that goal? And, broadening a bit, what in such constructed
algebra would be 0/0 and 0^0?
Please note that, as far as I am concerned (and as far as it makes
sense), here both infinity and zero should be taken as
"constants" (yep, it is an actual program what I'm trying to build).
Thanks a lot in advance for any insights,
Julio
---------------------------------------------
Julio Di Egidio
Software Analyst / Programmer
http://julio.diegidio.name
Mariano Suárez-Alvarez
> Please bear with me as I am a professional programmer but nothing more
> than passionate about Math, so I'll simply go straight to the point in
> my own "language".
>
> I'm writing code to support Complex numbers and operations. My goal is
> no operation of any kind should ever return NaN, that is no operation
> should be undefined. To make the question simple, I'll focus on the
> modulus operator on Reals to start from.
>
> and - as far as I get it - with some geometrical reasoning it defines
> "zero modulus" as x%0 = 0, and infinity modulus as x%oo = x. The
> problem for me is it doesn't cover all other "boundary" cases like oo
> %y or oo%oo.
>
> My question is, is there any consistent and well founded way to
> achieve that goal? And, broadening a bit, what in such constructed
> algebra would be 0/0 and 0^0?
>
> Please note that, as far as I am concerned (and as far as it makes
> sense), here both infinity and zero should be taken as
> "constants" (yep, it is an actual program what I'm trying to build).
>
> Thanks a lot in advance for any insights,
The answer depends on what properties you want to preserve.
For example, it is trivial to set up a system in which
x / 0, for non zero x, is defined to be infinity, but in
that system it will no longer be true that
(x / y) * y = x for all x and y
-- m
David W. Cantrell
> On Feb 8, 3:29 pm, ju...@diegidio.name wrote:
> > Please bear with me as I am a professional programmer but nothing more
> > than passionate about Math, so I'll simply go straight to the point in
> > my own "language".
> >
> > I'm writing code to support Complex numbers and operations.
Based on what you say later, you will obviously need to use some
_extension_ of the complex numbers. The simplest is the one-point
extension, C*, obtained by adjoining a single undirected infinity, oo, to
the set of complex numbers. (But unfortunately, I doubt that C* will
actually be adequate for your needs.)
> > My goal is no operation of any kind should ever return NaN, that is no
> > operation should be undefined.
To be picky: I think that Kahan would tell you that NaN is not the same as
"undefined".
But I think I understand your point:
You want operations to return _numbers_ always.
> > To make the question simple, I'll focus on the
> > modulus operator on Reals to start from.
I have my doubts that that's the best way to start, and so I'm not going to
comment on the next paragraph.
> > I have found something very promising at
> > http://www.gwiep.net/books/parad09.htm, and - as far as I get it -
> > with some geometrical reasoning it defines "zero modulus" as x%0 = 0,
> > and infinity modulus as x%oo = x. The problem for me is it doesn't
> > cover all other "boundary" cases like oo %y or oo%oo.
> >
> > My question is, is there any consistent and well founded way to
> > achieve that goal?
For your general goal, I think most people would answer NO.
> > And, broadening a bit, what in such constructed
> > algebra would be 0/0 and 0^0?
Suppose that we're using C*. Then I suggest the following:
1. Adopt the rule that 0*x = 0 for _all_ x.
2. Letting /x denote the reciprocal of x, define /0 = oo and /oo = 0.
3. Define division by x/y = x*(/y).
4. Define log(0) = oo.
5. Define exponentiation by x^y = exp(y*log(x)).
It would then follow that
0/0 = 0*(/0) = 0*oo = 0
and
0^0 = exp(0*log(0)) = exp(0*oo) = exp(0) = 1.
> > Please note that, as far as I am concerned (and as far as it makes
> > sense), here both infinity and zero should be taken as
> > "constants" (yep, it is an actual program what I'm trying to build).
> >
> > Thanks a lot in advance for any insights,
>
> The answer depends on what properties you want to preserve.
Indeed!
> For example, it is trivial to set up a system in which
> x / 0, for non zero x, is defined to be infinity, but in
> that system it will no longer be true that
>
> (x / y) * y = x for all x and y
You say "no longer". But if we were already in the real (or complex) number
system, we had _already_ lost that property.
Of course,
(x / y) * y = x for all x and y
is true, for example, in the system of _positive_ reals. But as soon as 0
is introduced...
David W. Cantrell
ju...@diegidio.name
Thanks for the great answers!
> > The answer depends on what properties you want to preserve.
Ok, point taken. My idea is (naively expressed) that I need something
that tends to show "usual properties far from the boundaries". For
instance, my first application is a function grapher (implying parser
and calculator), and I am after something that would draw functions
"the common way" at least in "common places" across its domain. (Maybe
I could say I would still like a parabola to look like a parabola or
the Mandelbrot set to look like the Mandelbrot set, etc.)
> Suppose that we're using C*. Then I suggest the following: [...]
> But unfortunately, I doubt that C* will actually be adequate for your needs
To be honest, I can only say it looks perfect (btw, I have just read
something about the extended complex plane on Wikipedia, so it makes
even more sense to my intuition). Of course I'm eager to hear what the
inadequacies can be. Trying to contribute, here I'll tell where your
set of rules seems to lead me straight away.
- Besides, for what is worth, that I had already encountered in my
coding a smell of some "zero-prevalence" when converting polar (oo, t)
to rectangular, for t on the boundaries of quadrants;
- To have one only (the undirected) infinity lets me "draw" oo at zero
by convention, that is I can deal with one specific point: x-oo = oo
is its weird counterpart maybe, where oo is someway both the minimum
and the maximum of numbers so that both x<oo and x>oo always hold,
still it "smells consistent"...
- For functions, such as the tangent, I suppose I can keep using my
framework's built-in functions, and that dramatically simplifies my
coding (I'm coding in C#.Net, btw);
- Last but not least, for the modulus operator I finally seem to have
something, even if I don't really get consistent results. Assuming oo-
oo = 0:
Defining modulus by:
x % y = x - y * floor(x * /y)
I get the following:
0 % 0 = 0
x % 0 = x
0 % y = 0
x % oo = x
oo % y = 0
oo % oo = oo
Defining modulus by:
x % y def= x - Prod_n(y) with n>=0 that maximizes Prod_n(y)<=x
I get a different result in last case:
oo % oo = 0
Well, if my calculations are correct and supposing oo = oo, the only
thing I can add is that the result from second definition sounds more
"common" to me - in the sense I have given to this term at the
beginning of the post - but here I'm afraid I'm starting to guess.
As for now, again a big thank you both, I couldn't expect better
feedback.
-LV
On Feb 8, 10:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> "Mariano_Suárez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> > On Feb 8, 3:29 pm, ju...@diegidio.name wrote:
> > > I'm writing code to support Complex numbers and operations.
ju...@diegidio.name
framework's built-in functions
Pardon, to be precise, I mean I can keep built-in functions and
possibly discard the sign of the infinity.
-LV
On Feb 10, 4:45 am, ju...@diegidio.name wrote:
> On Feb 8, 10:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > "Mariano_Suárez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> > > On Feb 8, 3:29 pm, ju...@diegidio.name wrote:
> > > > I'm writing code to support Complex numbers and operations.
> > > > My goal is no operation of any kind should ever return NaN, that is no
> > > > operation should be undefined.- Hide quoted text -
ju...@diegidio.name
- please forget my rumination about oo drawn at zero: much better to
have oo as the only number with no correspondence at all on the
extended complex plane.
-LV
On Feb 10, 4:57 am, ju...@diegidio.name wrote:
> On Feb 10, 4:45 am, ju...@diegidio.name wrote:
> > On Feb 8, 10:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > "Mariano_Suárez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> > > > On Feb 8, 3:29 pm, ju...@diegidio.name wrote:
> > > > > I'm writing code to support Complex numbers and operations.
> > > > > My goal is no operation of any kind should ever return NaN, that is no
> > > > > operation should be undefined.- Hide quoted text -- Hide quoted text -
Mariano Suárez-Alvarez
Huh? The equation
(x / y) * y = x
holds for all x and y for which all the operations are
defined---this condition, of course, simply means that
y is not zero---both in the domain of real and complex
numbers.
-- m
David W. Cantrell
> On Feb 8, 8:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > "Mariano_Suárez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> > > For example, it is trivial to set up a system in which
> > > x / 0, for non zero x, is defined to be infinity, but in
> > > that system it will no longer be true that
> >
> > > (x / y) * y = x for all x and y
> >
> > You say "no longer". But if we were already in the real (or complex)
> > number system, we had _already_ lost that property.
> >
> > Of course,
> >
> > (x / y) * y = x for all x and y
> >
> > is true, for example, in the system of _positive_ reals. But as soon
> > as 0 is introduced...
>
> Huh? The equation
>
> (x / y) * y = x
>
> holds for all x and y for which all the operations are defined
Right. But there is a big difference between "for all x and y" and "for all
x and y for which all the operations are defined"! Had you originally used
the latter qualification, I would not have made any comment.
> ---this condition, of course, simply means that
> y is not zero---both in the domain of real and complex numbers.
Yes. Therefore, in C, for example, we have
(x / y) * y = x for all x and _nonzero_ y
while, for comparison, in C*, we have
(x / y) * y = x for all x and _nonzero finite_ y.
[Indeed, if, as in the part I had snipped, we were to
have 0/0 = 0 and oo/oo = 0, then (x/y)*y = x also holds
if x = 0 and y is _any_ element of C*.]
To look at the comparison in a different light, the set
{(x, y) | (x/y)*y = x, x in C, y in C}
is a subset of
{(x, y) | (x/y)*y = x, x in C*, y in C*}.
David
David W. Cantrell
You're certainly welcome.
> > > The answer depends on what properties you want to preserve.
>
> Ok, point taken. My idea is (naively expressed) that I need something
> that tends to show "usual properties far from the boundaries". For
> instance, my first application is a function grapher (implying parser
> and calculator), and I am after something that would draw functions
> "the common way" at least in "common places" across its domain. (Maybe
> I could say I would still like a parabola to look like a parabola or
> the Mandelbrot set to look like the Mandelbrot set, etc.)
>
> > Suppose that we're using C*. Then I suggest the following: [...]
> > But unfortunately, I doubt that C* will actually be adequate for your
> > needs
>
> To be honest, I can only say it looks perfect (btw, I have just read
> something about the extended complex plane on Wikipedia, so it makes
> even more sense to my intuition). Of course I'm eager to hear what the
> inadequacies can be.
Well, for example, what should exp(oo) be?
There is really no good answer within C*.
> Trying to contribute, here I'll tell where your
> set of rules seems to lead me straight away.
>
> - Besides, for what is worth, that I had already encountered in my
> coding a smell of some "zero-prevalence" when converting polar (oo, t)
> to rectangular, for t on the boundaries of quadrants;
>
> - To have one only (the undirected) infinity lets me "draw" oo at zero
> by convention,
Later amended as:
> - please forget my rumination about oo drawn at zero: much better to
> have oo as the only number with no correspondence at all on the
> extended complex plane.
No correspondence on the complex plane. It's better to think of C* in
terms of the Riemann sphere.
> that is I can deal with one specific point: x-oo = oo
> is its weird counterpart maybe, where oo is someway both the minimum
> and the maximum of numbers so that both x<oo and x>oo always hold,
> still it "smells consistent"...
Hmm. Inequalities don't apply to complex numbers. But if you're thinking
about just the "extended real axis", you might enjoy my discussion of R*,
the one-point extension of R, at
<http://mathworld.wolfram.com/ProjectivelyExtendedRealNumbers.html>.
In R*, we would normally say that oo is unordered with respect to all other
elements. (Neither x<oo nor x>oo ever holds.)
> - For functions, such as the tangent, I suppose I can keep using my
> framework's built-in functions,
Later amended as:
> Pardon, to be precise, I mean I can keep built-in functions and
> possibly discard the sign of the infinity.
> and that dramatically simplifies my coding (I'm coding in C#.Net, btw);
>
> - Last but not least, for the modulus operator I finally seem to have
> something, even if I don't really get consistent results.
> Assuming oo - oo = 0:
IMO, that assumption is not recommendable. Normally, in R* or C*, both
oo + oo and oo - oo are left undefined. But if those were to be defined
within one of those systems, I would suggest, noting that -(oo) = oo, that
you take oo - oo = oo + oo = oo.
Since I have not given much thought to the modulo operation in R* or C*,
I'm still going to refrain from commenting on the following. Sorry. But
just remember, as Mariano said, "The answer depends on what properties you
want to preserve."
> Defining modulus by:
>
> x % y = x - y * floor(x * /y)
>
> I get the following:
>
> 0 % 0 = 0
> x % 0 = x
> 0 % y = 0
> x % oo = x
> oo % y = 0
> oo % oo = oo
>
> Defining modulus by:
>
> x % y def= x - Prod_n(y) with n>=0 that maximizes Prod_n(y)<=x
>
> I get a different result in last case:
>
> oo % oo = 0
>
> Well, if my calculations are correct and supposing oo = oo,
Not much of a supposition! Yes, of course, oo = oo.
David
> the only
> thing I can add is that the result from second definition sounds more
> "common" to me - in the sense I have given to this term at the
> beginning of the post - but here I'm afraid I'm starting to guess.
>
> As for now, again a big thank you both, I couldn't expect better
> feedback.
> On Feb 8, 10:34=A0pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
ju...@diegidio.name
should always return a finite number. This may have a big impact on
the outcome of trigonometric functions. I'll try and elaborate below.
If I keep oo-oo = 0, as well as stick to the original definition of
modulo, I can get:
oo % y = 0, for every y in R*
With this in mind, and trying - as a matter of test[*] - to approach
exp(oo), if I define:
oc = oo + i*oo, where oc in infinity in C* and oo is infinity in R*
x % y = x - n*y, with x,y in R* and n in Nº so that n>=0 maximizes
(n*y)<=x
I get:
oo % 2*pi = 0
cos(oo) = cos(0) = 1
sin(oo) = sin(0) = 0
exp(oo) = oo
exp(i*oo) = exp(0)*cos(oo) + i*exp(0)*sin(oo) = 1*1 + i*1*0 = 1
exp(oc) = exp(oo + i*oo) = exp(oo) * exp(i*oo) = oo * 1 = oo
That is exp(oc) = exp(oo) = oo, where I'm being confident that
exp(oo)=oo is not such a problem since you specifically said there is
no good answer _within C*_ :) Could you spot any significant drawback
with this set of rules? I am going to test[*] an implementation of it!
[*Incidentally: the accepted principle in my profession is: as far as
it passes systems testing (read as far as it doesn't blow), a system
is "correct", and the problem becomes "good" testing. I guess then, in
a sense, we do solve the halting problem in everyday life, though
asymptotically (up to the next failure). This leads me to wander about
some S* set, where S is the set of correct systems for a given problem
(engineringly correct, in the sense I've just given, so on a subset of
all possible input), and oo in S* is the "universally" correct system
for that (for all?) problem(s), that is the one that would behave
correctly whichever the input, though apparently the one (always?) out
of our reach... Does it make any sense? :)]
Julio
> > > > > no operation should be undefined.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
ju...@diegidio.name
> you might enjoy my discussion of R*
It's great, makes it even more clear. One thing above all:
"This [R*] might not be of much interest except for the fact that such
intervals arise in those systems of interval arithmetic that allow
division by intervals containing 0."
Can't say why, but I want this!
Julio
ju...@diegidio.name
(sorry for that [R*] in your quote), sometimes for my lack of English
skills (I'm Italian): that "apparently the one (always?) out of our
reach" about oo in S* should really read "seemingly the one ...", and
"big impact" of % to trigonometric functions above should be
"significant impact" in terms of practical outcomes.
I for one surely improve through failure, as far as I can make a rule
of it: "practical", I have checked in the dictionary... :)
Julio
Mariano Suárez-Alvarez
> "Mariano_Suárez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> > On Feb 8, 8:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > "Mariano_Suárez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> [snip]
> > > > For example, it is trivial to set up a system in which
> > > > x / 0, for non zero x, is defined to be infinity, but in
> > > > that system it will no longer be true that
>
> > > > (x / y) * y = x for all x and y
>
> > > You say "no longer". But if we were already in the real (or complex)
> > > number system, we had _already_ lost that property.
>
> > > Of course,
>
> > > (x / y) * y = x for all x and y
>
> > > is true, for example, in the system of _positive_ reals. But as soon
> > > as 0 is introduced...
>
> > Huh? The equation
>
> > (x / y) * y = x
>
> > holds for all x and y for which all the operations are defined
>
> Right. But there is a big difference between "for all x and y" and "for all
> x and y for which all the operations are defined"! Had you originally used
> the latter qualification, I would not have made any comment.
I tend to consider the qualification "for which all operations
involved are defined" to be unnecessary pedantry: I find it
of no use to make statements about undefined things, and that
phrase only serves the purpose of excluding them.
-- m
David W. Cantrell
> On Feb 10, 1:52 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > On Feb 8, 8:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > [snip]
> > > > > For example, it is trivial to set up a system in which
> > > > > x / 0, for non zero x, is defined to be infinity, but in
> > > > > that system it will no longer be true that
> >
> > > > > (x / y) * y = x for all x and y
> >
> > > > You say "no longer". But if we were already in the real (or
> > > > complex) number system, we had _already_ lost that property.
> >
> > > > Of course,
> >
> > > > (x / y) * y = x for all x and y
> >
> > > > is true, for example, in the system of _positive_ reals. But as
> > > > soon as 0 is introduced...
> >
> > > Huh? The equation
> >
> > > (x / y) * y = x
> >
> > > holds for all x and y for which all the operations are defined
> >
> > Right. But there is a big difference between "for all x and y" and
> > "for all x and y for which all the operations are defined"! Had you
> > originally used the latter qualification, I would not have made any
> > comment.
>
> I tend to consider the qualification "for which all operations
> involved are defined" to be unnecessary pedantry:
Well, you were the first to use that phrase in this thread.
And I certainly don't think something is "unnecessary pedantry" if it keeps
one from making an incorrect assertion.
> I find it
> of no use to make statements about undefined things, and that
> phrase only serves the purpose of excluding them.
Obviously we have a difference of opinion on this matter, and that
difference is probably irreconcilable.
As best I can tell, if, say, we were dealing with the reals (with division
by zero never defined), you would say that
x/0 = 1 for all x
is correct, although "of no use", while I would say that it is simply
incorrect.
David
Mariano Suárez-Alvarez
> And I certainly don't think something is "unnecessary pedantry" if it keeps
> one from making an incorrect assertion.
>
> > I find it
> > of no use to make statements about undefined things, and that
> > phrase only serves the purpose of excluding them.
>
> Obviously we have a difference of opinion on this matter, and that
> difference is probably irreconcilable.
>
> As best I can tell, if, say, we were dealing with the reals (with division
> by zero never defined), you would say that
>
> x/0 = 1 for all x
>
> is correct, although "of no use", while I would say that it is simply
> incorrect.
Well, in this case "x/0" by itself is already meaningless,
as "x/y" means "multiply x by the multiplicative inverse of y"
and, as you know, 0 has no multiplicative inverse. You'll
surely agree that a meaningless statement, such as "x/0 = 1",
does not become meaningful by putting a quantifier before it.
Moreover, this does not depend on whether the quantified is
bounded or not nor, in the second case, on what bound is
imposed on the variable.
Hence for your example I would simply say that the statement
is meaningless, not that it is correct.
-- m
David W. Cantrell
> P.S.
>
> > you might enjoy my discussion of R*
>
> It's great, makes it even more clear. One thing above all:
>
> "This [R*] might not be of much interest except for the fact that such
> intervals arise in those systems of interval arithmetic that allow
> division by intervals containing 0."
>
> Can't say why, but I want this!
Julio,
I regret that I don't have time to look over your recent posts in detail.
As best I can tell, there is no reasonable way to do everything you want in
a system as simple as R* or C*. But above, you seem to indicate an interest
in interval arithmetic. In some system of extended interval arithmetic,
there would, IMO, be a reasonable way to do everything you want. If this
sounds good to you, I strongly recommend that you look at the work of G.
William (Bill) Walster of Sun Microsystems. I hope that you can find some
of his papers on the Web.
David
ju...@diegidio.name
If I'll ever manage to ship, this discussion will make an integral
part of the documentation.
Julio
Mariano Suárez-Alvarez
For something like an extension of arithmetic, it might
be worthwhile being a little unorthodox, then, and try to
write down the actual properties that you expect your
implementation to satisfy and _then_ generate test cases
based on them.
Breaking such a tradition as the accepted principle you mention
might require a justification: in this case, that can be
amply supplied by the fact that those properties expected to
hold are going to be needed in order to document what you've
done.
> oo % 2*pi = 0
> cos(oo) = cos(0) = 1
> sin(oo) = sin(0) = 0
> exp(oo) = oo
> exp(i*oo) = exp(0)*cos(oo) + i*exp(0)*sin(oo) = 1*1 + i*1*0 = 1
> exp(oc) = exp(oo + i*oo) = exp(oo) * exp(i*oo) = oo * 1 = oo
>
> That is exp(oc) = exp(oo) = oo, where I'm being confident that
> exp(oo)=oo is not such a problem since you specifically said there is
> no good answer _within C*_ :) Could you spot any significant drawback
> with this set of rules? I am going to test[*] an implementation of it!
These rules imply that
cos(oo + pi) = cos(oo) * cos(pi) - sin(oo) * sin(pi)
= 1 * (-1) - 0 * 0
= -1
while
cos(oo) = 1.
You did not state it explicitely, but I imagine that
you are assuming that oo + pi = oo. Then in your system
1 = -1.
You probably do not want that ;-)
-- m
ju...@diegidio.name
Someway, by digging the Wikipedia, the inconsistency you have shown
above led me to "wheel theory", and that looks like what I was looking
for: http://en.wikipedia.org/wiki/Wheel_theory
Not that I can already envision a way to implement this extension. In
fact, I could restart with my question over, despite in slightly more
proper terms, and, for instance, still wander what cos(oo), or oo %
2pi for the sake, could ever be, though now on wheels. But, at least,
I am confident about the feasibility of the task.
As for the practical perspective, I suppose extending my algebra to
wheels implies an extension of the set of meaningful operations, and,
iif this extension leads to a "significantly" broader applicability,
then my struggle is justified. Of course, I can't yet "prove" my
premises.
Moreover, the ideal situation from my perspective is that someone had
already implemented an algebra on wheels, and that I could just apply
the basic recipe. I don't need to "reinvent the wheel", so to say.
> those properties expected to hold are going to be needed in order to document what you've done
Yep, I'll be very careful not to crash the Universe! :)
Julio
On Feb 11, 5:18 am, "Mariano Suárez-Alvarez"
> -- m- Hide quoted text -
David W. Cantrell
> Hi Mariano, nice to hear from you!
>
> Someway, by digging the Wikipedia, the inconsistency you have shown
> above led me to "wheel theory", and that looks like what I was looking
> for: http://en.wikipedia.org/wiki/Wheel_theory
I doubt that that is what you're looking for; otherwise, I would already
have mentioned it to you. Why is it not what you're looking for? Well, in
your first post, you specifically said that you wanted to avoid NaN. But
standard floating-point arithmetic is essentially a wheel, and the element
notated as _|_ in wheel theory is essentially the same as NaN in
floating-point arithmetic. For example, 0/0 is _|_ in a wheel and NaN in
floating point. In neither is it reasonable, IMO, to call 0/0 a "number".
> Not that I can already envision a way to implement this extension. In
> fact, I could restart with my question over, despite in slightly more
> proper terms, and, for instance, still wander what cos(oo),
It would have to be _|_, I should think.
> or oo %
> 2pi for the sake, could ever be, though now on wheels. But, at least,
> I am confident about the feasibility of the task.
>
> As for the practical perspective, I suppose extending my algebra to
> wheels implies an extension of the set of meaningful operations, and,
> iif this extension leads to a "significantly" broader applicability,
> then my struggle is justified. Of course, I can't yet "prove" my
> premises.
>
> Moreover, the ideal situation from my perspective is that someone had
> already implemented an algebra on wheels, and that I could just apply
> the basic recipe. I don't need to "reinvent the wheel", so to say.
Before you try to implement a wheel, please compare it with floating-point
arithmetic. And ask yourself how using _|_ might be preferable to using
NaN!
David
ju...@diegidio.name
> you specifically said that you wanted to avoid NaN
Not really! "Undefined" was broader there, trying to define NaN. This
made Mr Cantrell comment, too.
This said, point taken: _|_ is NaN and floating-point is a wheel (and
I'm depressed).
Yet, the question stands, just more and more perfected:
1. Is there an algebraic system where 0/0 is a number?
2. If so, could you describe its interesting[*] properties in basic
terms?
3. And, could you provide a list of rules for computation?
Note: References always welcome.
Julio
David W. Cantrell
> This is too interesting not to follow up by any means... ;)
>
> > you specifically said that you wanted to avoid NaN
>
> Not really! "Undefined" was broader there, trying to define NaN. This
> made Mr Cantrell comment, too.
>
> This said, point taken: _|_ is NaN and floating-point is a wheel (and
> I'm depressed).
>
> Yet, the question stands, just more and more perfected:
>
> 1. Is there an algebraic system where 0/0 is a number?
Of course, if you consider _|_ (or NaN) to be a "number", then such a
system is a wheel. But as I said, I don't consider _|_ to be a number;
indeed, NaN stands for "Not a Number".
In one of my first posts in this thread, I mentioned a system in which
0/0 = 0. I didn't mention then, but it certainly is my opinion, that if 0/0
is to be a real or complex number, 0 is the only reasonable value. [FWIW,
in J, a descendent of APL, 0/0 yields 0.]
> 2. If so, could you describe its interesting[*] properties in basic
> terms?
Please look again at that earlier post of mine. I suspect that you can
derive many of the interesting properties/rules yourself.
> 3. And, could you provide a list of rules for computation?
Ditto.
But when you say "computation", I suspect you mean computation beyond what
is strictly algebraic. For example, you want the trig functions to be
defined always. But suppose we're using R*. There is no reasonable way IMO
to define, say, sin(oo) as an element of R*. OTOH, there is a reasonable
way to define sin(oo) in an interval arithmetic: sin(oo) = [-1, 1]. And I
believe that Walster does exactly that.
David
> Note: References always welcome.
>
> Julio
>
> On Feb 11, 8:28=A0pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > ju...@diegidio.name wrote:
> > > Hi Mariano, nice to hear from you!
> >
> > > Someway, by digging the Wikipedia, the inconsistency you have shown
> > > above led me to "wheel theory", and that looks like what I was
> > > looking for:http://en.wikipedia.org/wiki/Wheel_theory
> >
> > I doubt that that is what you're looking for; otherwise, I would
> > already have mentioned it to you. Why is it not what you're looking
> > for? Well, in your first post, you specifically said that you wanted to
> > avoid NaN. But standard floating-point arithmetic is essentially a
> > wheel, and the element=
>
> > notated as _|_ in wheel theory is essentially the same as NaN in
> > floating-point arithmetic. For example, 0/0 is _|_ in a wheel and NaN
> > in floating point. In neither is it reasonable, IMO, to call 0/0 a
> > "number".
> >
> > > Not that I can already envision a way to implement this extension. In
> > > fact, I could restart with my question over, despite in slightly more
> > > proper terms, and, for instance, still wander what cos(oo),
> >
> > It would have to be _|_, I should think.
> >
> > > or oo %
> > > 2pi for the sake, could ever be, though now on wheels. But, at least,
> > > I am confident about the feasibility of the task.
> >
> > > As for the practical perspective, I suppose extending my algebra to
> > > wheels implies an extension of the set of meaningful operations, and,
> > > iif this extension leads to a "significantly" broader applicability,
> > > then my struggle is justified. Of course, I can't yet "prove" my
> > > premises.
> >
> > > Moreover, the ideal situation from my perspective is that someone had
> > > already implemented an algebra on wheels, and that I could just apply
> > > the basic recipe. I don't need to "reinvent the wheel", so to say.
> >
> > Before you try to implement a wheel, please compare it with
> > floating-point=
ju...@diegidio.name
Yes, I guess so...
> Walster does exactly that
That fact is, I couldn't manage to find any readily available paper
from Walster. I'll try again, as well as re-reading the whole
discussion ground up. At the moment, to be true, I am lost at the very
concept of "number", and I even wander what I am after.
BTW, I have also been looking at interval arithmetic on WP, but I
couldn't get the pregnancy as it gets shortly presented as a tool to
manage error propagation. There is a broader treatment on the German
WP, but I can't read German. Anyway, going back to the German article,
I now notice it shows intervals such as [-oo, oo], and this makes me
very very confident...
I'll report here in case I make any progress.
Thanks again.
Julio
> > > David- Hide quoted text -
David W. Cantrell
> > I suspect you mean computation beyond what is strictly algebraic
>
> Yes, I guess so...
>
> > Walster does exactly that
>
> That fact is, I couldn't manage to find any readily available paper
> from Walster.
Hmm. I couldn't find the listing of his papers which used to be available,
so I used the Wayback Machine. Go to
<http://web.archive.org/web/20050410215323/http://www.mscs.mu.edu/~globsol/walster-papers.html>.
As best I can tell, the links there work.
David
> I'll try again, as well as re-reading the whole
> discussion ground up. At the moment, to be true, I am lost at the very
> concept of "number", and I even wander what I am after.
>
> BTW, I have also been looking at interval arithmetic on WP, but I
> couldn't get the pregnancy as it gets shortly presented as a tool to
> manage error propagation. There is a broader treatment on the German
> WP, but I can't read German. Anyway, going back to the German article,
> I now notice it shows intervals such as [-oo, oo], and this makes me
> very very confident...
>
> I'll report here in case I make any progress.
>
> Thanks again.
>
> Julio
>
> On Feb 11, 10:03=A0pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > ju...@diegidio.name wrote:
> > > This is too interesting not to follow up by any means... ;)
> >
> > > > you specifically said that you wanted to avoid NaN
> >
> > > Not really! "Undefined" was broader there, trying to define NaN. This
> > > made Mr Cantrell comment, too.
> >
> > > This said, point taken: _|_ is NaN and floating-point is a wheel (and
> > > I'm depressed).
> >
> > > Yet, the question stands, just more and more perfected:
> >
> > > 1. Is there an algebraic system where 0/0 is a number?
> >
> > Of course, if you consider _|_ (or NaN) to be a "number", then such a
> > system is a wheel. But as I said, I don't consider _|_ to be a number;
> > indeed, NaN stands for "Not a Number".
> >
> > In one of my first posts in this thread, I mentioned a system in which
> > 0/0 =3D 0. I didn't mention then, but it certainly is my opinion, that
> > if =
> 0/0
> > is to be a real or complex number, 0 is the only reasonable value.
> > [FWIW, in J, a descendent of APL, 0/0 yields 0.]
> >
> > > 2. If so, could you describe its interesting[*] properties in basic
> > > terms?
> >
> > Please look again at that earlier post of mine. I suspect that you can
> > derive many of the interesting properties/rules yourself.
> >
> > > 3. And, could you provide a list of rules for computation?
> >
> > Ditto.
> >
> > But when you say "computation", I suspect you mean computation beyond
> > what=
>
> > is strictly algebraic. For example, you want the trig functions to be
> > defined always. But suppose we're using R*. There is no reasonable way
> > IMO=
>
> > to define, say, sin(oo) as an element of R*. OTOH, there is a
> > reasonable way to define sin(oo) in an interval arithmetic: sin(oo) =3D
> > [-1, 1]. And =
> I
> > believe that Walster does exactly that.
> >
> > David
> >
> >
> >
> > > Note: References always welcome.
> >
> > > Julio
> >
> > > On Feb 11, 8:28=3DA0pm, David W. Cantrell <DWCantr...@sigmaxi.net>
> > > wrote=
> :
> > > > ju...@diegidio.name wrote:
> > > > > Hi Mariano, nice to hear from you!
> >
> > > > > Someway, by digging the Wikipedia, the inconsistency you have
> > > > > shown above led me to "wheel theory", and that looks like what I
> > > > > was looking for:http://en.wikipedia.org/wiki/Wheel_theory
> >
> > > > I doubt that that is what you're looking for; otherwise, I would
> > > > already have mentioned it to you. Why is it not what you're looking
> > > > for? Well, in your first post, you specifically said that you
> > > > wanted t=
> o
> > > > avoid NaN. But standard floating-point arithmetic is essentially a
> > > > wheel, and the element=3D
> >
> > > > notated as _|_ in wheel theory is essentially the same as NaN in
> > > > floating-point arithmetic. For example, 0/0 is _|_ in a wheel and
> > > > NaN in floating point. In neither is it reasonable, IMO, to call
> > > > 0/0 a "number".
> >
> > > > > Not that I can already envision a way to implement this
> > > > > extension. I=
> n
> > > > > fact, I could restart with my question over, despite in slightly
> > > > > mor=
> e
> > > > > proper terms, and, for instance, still wander what cos(oo),
> >
> > > > It would have to be _|_, I should think.
> >
> > > > > or oo %
> > > > > 2pi for the sake, could ever be, though now on wheels. But, at
> > > > > least=
> ,
> > > > > I am confident about the feasibility of the task.
> >
> > > > > As for the practical perspective, I suppose extending my algebra
> > > > > to wheels implies an extension of the set of meaningful
> > > > > operations, and=
> ,
> > > > > iif this extension leads to a "significantly" broader
> > > > > applicability,=
>
> > > > > then my struggle is justified. Of course, I can't yet "prove" my
> > > > > premises.
> >
> > > > > Moreover, the ideal situation from my perspective is that someone
> > > > > ha=
> d
> > > > > already implemented an algebra on wheels, and that I could just
> > > > > appl=
> y
> > > > > the basic recipe. I don't need to "reinvent the wheel", so to
> > > > > say.
> >
> > > > Before you try to implement a wheel, please compare it with
> > > > floating-point=3D
> >
> > > > arithmetic. And ask yourself how using _|_ might be preferable to
> > > > usin=
ju...@diegidio.name
Bingo!!
:)
Julio
P.S. From this point on, the more I say, the more it starts to loose
sense, and I tend to believe this demonstrates that the question is
answered. I desire to thank you, David, for the patience as well as
the invaluable support. I desire to thank you, Mariano, too, because
in a sense you didn't answer, and in that I feel you may have made
this all possible. In a word, this has been a great learning and human
experience for me. I wish you the best.
On Feb 11, 11:51 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> ju...@diegidio.name wrote:
> > > I suspect you mean computation beyond what is strictly algebraic
>
> > Yes, I guess so...
>
> > > Walster does exactly that
>
> > That fact is, I couldn't manage to find any readily available paper
> > from Walster.
>
> Hmm. I couldn't find the listing of his papers which used to be available,
> so I used the Wayback Machine. Go to
> <http://web.archive.org/web/20050410215323/http://www.mscs.mu.edu/~glo...>.
> > > - Show quoted text -- Hide quoted text -
ju...@diegidio.name
documentation for "Radical Engineering":
http://architectando.blogspot.com/2008/02/on-correctness.html
Any radical contribution is welcome.
Thank you.
Julio
Mariano Suárez-Alvarez
> As a matter of fact, this discussion is now officially part of the
> documentation for "Radical Engineering":
>
> http://architectando.blogspot.com/2008/02/on-correctness.html
>
> Any radical contribution is welcome.
From reading that, I can only thank I do not
live near any nuclear power plant whose software
was written by you ;-)
-- m
PS: By the way, please do not top post <http://www.caliburn.nl/
topposting.html>, as
otherwise it becomes quite difficult to understand
what you are replying to.
ju...@diegidio.name
Now, the whole thing is not rigorous, so anything is possible, anyhow
a thinking strikes me: if we reverse the reasoning, we could envision
that - if, for a given problem, we could in general define the sets oo
and 0/0, then we had in general defined their remainder, that is the
set of correct systems!
In practice, this entails that we would never fail.
Unpondered side-question:
- What is the (minimal?) Goedel proposition for interval arithmetic?
Julio
On Feb 12, 5:56 am, "Mariano Suárez-Alvarez"
ju...@diegidio.name
I have in the meantime made a first "naive" port to managed C#.Net of
the whole of ACM's Algorithm 737 (A737). This algorithm is also the
base for A763, which is its F90 port, and some more interval based
libraries like INTBIS, PROFIL/BIAS, etc. The only technical difficulty
is in properly defining machine related parameters (the default
provided set for 80x86 doesn't seem to work very well on my Vista 32
based PC), but I believe this can be easily fixed at any time...
However, I really hope you can enlighten me on a couple of things I
cannot seem to get:
-------
1) After implementing A737, I realize this is probably not what
Walster meant! (Me idiot, two weeks of work to just get what the code
does...)
Walster, in its "Interval Arithmetic Specification" (spec.ps, please
refer to the link Mr Cantrell has kindly provided above), says: "The
defined set of extended real intervals is closed with respect to
arithmetic operations and interval enclosures of real functions". But
in A737 I still see some unrecoverable error conditions for
"operations that cannot be assigned any meaning", namely for IIPOWR,
ILOG and ISQRT when the argument is zero or negative (depending on the
specific function), and for IACOS and IASIN when the argument is not
in [-1,+1]. For instance, this means I still cannot issue a 0**0 and
get a result.
-- Q: Could you please confirm that I have implemented the wrong
algorithm? :)
-------
2) The fact that extended interval arithmetic is closed to any
operation, and the fact that this leads to amazing results in the
realms of non-linear systems analysis and global optimization, makes
me wander why this thing has not become as widespread a new paradigm
as it sounds it should be, and as Walster himself - as far as I get it
- claims it is.
Walster says (as I get it from the manifesto.ps) this is mainly due to
the lack of built-in support for the extended interval type, which
results in inefficient and clumsy implementations. Still, shouldn't
extended interval arithmetic have been already embraced by the
theoretical community at least?
In other words, as a professional programmer and passionate about
computability and related matters, I can just say this extended
interval arithmetic sounds amazing to me, and I even envision it could
have some deep consequences on undecidability issues (I mean Goedel's
theorems and related) as well as P. vs NP. matters, etc. etc. Then why
at least mathematicians do not seem so interested in it?
-- Q: Why is it so?
-------
As always, thank a lot in advance for your insights.
Julio
On Feb 12, 12:25 am, ju...@diegidio.name wrote:
David W. Cantrell
That would seem to be the case. (Note, however, that I am not familiar with
ACM's Algorithm 737.)
> -------
>
> 2) The fact that extended interval arithmetic is closed to any
> operation, and the fact that this leads to amazing results in the
> realms of non-linear systems analysis and global optimization, makes
> me wander why this thing has not become as widespread a new paradigm
> as it sounds it should be, and as Walster himself - as far as I get it
> - claims it is.
>
> Walster says (as I get it from the manifesto.ps) this is mainly due to
> the lack of built-in support for the extended interval type, which
> results in inefficient and clumsy implementations. Still, shouldn't
> extended interval arithmetic have been already embraced by the
> theoretical community at least?
Which theoretical community? Walster's work is well embraced, I think, by
the interval-arithmetic community.
> In other words, as a professional programmer and passionate about
> computability and related matters, I can just say this extended
> interval arithmetic sounds amazing to me, and I even envision it could
> have some deep consequences on undecidability issues (I mean Goedel's
> theorems and related) as well as P. vs NP. matters, etc. etc.
I, OTOH, cannot envision any such thing.
> Then why at least mathematicians do not seem so interested in it?
>
> -- Q: Why is it so?
A better question might be:
Why is interval arithmetic not of greater general interest?
But I'm not the one to answer that.
David
> -------
>
> As always, thank a lot in advance for your insights.
>
> Julio
>
> On Feb 12, 12:25=A0am, ju...@diegidio.name wrote:
> > That's it... with Fortran 77 specification...
> >
> > Bingo!!
> >
> > :)
> >
> > Julio
> >
> > P.S. From this point on, the more I say, the more it starts to loose
> > sense, and I tend to believe this demonstrates that the question is
> > answered. I desire to thank you, David, for the patience as well as
> > the invaluable support. I desire to thank you, Mariano, too, because
> > in a sense you didn't answer, and in that I feel you may have made
> > this all possible. In a word, this has been a great learning and human
> > experience for me. I wish you the best.
> >
> > On Feb 11, 11:51=A0pm, David W. Cantrell <DWCantr...@sigmaxi.net>
> > wrote:
> >
> >
> >
> > > ju...@diegidio.name wrote:
> > > > > I suspect you mean computation beyond what is strictly algebraic
> >
> > > > Yes, I guess so...
> >
> > > > > Walster does exactly that
> >
> > > > That fact is, I couldn't manage to find any readily available paper
> > > > from Walster.
> >
> > > Hmm. I couldn't find the listing of his papers which used to be
> > > availabl=
> e,
> > > so I used the Wayback Machine. Go to
> > > <http://web.archive.org/web/20050410215323/http://www.mscs.mu.edu/~gl
> > > o..=
> .>.
> > > As best I can tell, the links there work.
> >
> > > David
> >
> > > > I'll try again, as well as re-reading the whole
> > > > discussion ground up. At the moment, to be true, I am lost at the
> > > > very=
>
> > > > concept of "number", and I even wander what I am after.
> >
> > > > BTW, I have also been looking at interval arithmetic on WP, but I
> > > > couldn't get the pregnancy as it gets shortly presented as a tool
> > > > to manage error propagation. There is a broader treatment on the
> > > > German WP, but I can't read German. Anyway, going back to the
> > > > German article,=
>
> > > > I now notice it shows intervals such as [-oo, oo], and this makes
> > > > me very very confident...
> >
> > > > I'll report here in case I make any progress.
> >
> > > > Thanks again.
> >
> > > > Julio
> >
> > > > On Feb 11, 10:03=3DA0pm, David W. Cantrell <DWCantr...@sigmaxi.net>
> > > > wr=
> ote:
> > > > > ju...@diegidio.name wrote:
> > > > > > This is too interesting not to follow up by any means... ;)
> >
> > > > > > > you specifically said that you wanted to avoid NaN
> >
> > > > > > Not really! "Undefined" was broader there, trying to define
> > > > > > NaN. T=
> his
> > > > > > made Mr Cantrell comment, too.
> >
> > > > > > This said, point taken: _|_ is NaN and floating-point is a
> > > > > > wheel (=
> and
> > > > > > I'm depressed).
> >
> > > > > > Yet, the question stands, just more and more perfected:
> >
> > > > > > 1. Is there an algebraic system where 0/0 is a number?
> >
> > > > > Of course, if you consider _|_ (or NaN) to be a "number", then
> > > > > such =
> a
> > > > > system is a wheel. But as I said, I don't consider _|_ to be a
> > > > > numbe=
> r;
> > > > > indeed, NaN stands for "Not a Number".
> >
> > > > > In one of my first posts in this thread, I mentioned a system in
> > > > > whi=
> ch
> > > > > 0/0 =3D3D 0. I didn't mention then, but it certainly is my
> > > > > opinion, =
> that
> > > > > if =3D
> > > > 0/0
> > > > > is to be a real or complex number, 0 is the only reasonable
> > > > > value. [FWIW, in J, a descendent of APL, 0/0 yields 0.]
> >
> > > > > > 2. If so, could you describe its interesting[*] properties in
> > > > > > basi=
> c
> > > > > > terms?
> >
> > > > > Please look again at that earlier post of mine. I suspect that
> > > > > you c=
> an
> > > > > derive many of the interesting properties/rules yourself.
> >
> > > > > > 3. And, could you provide a list of rules for computation?
> >
> > > > > Ditto.
> >
> > > > > But when you say "computation", I suspect you mean computation
> > > > > beyon=
> d
> > > > > what=3D
> >
> > > > > is strictly algebraic. For example, you want the trig functions
> > > > > to b=
> e
> > > > > defined always. But suppose we're using R*. There is no
> > > > > reasonable w=
> ay
> > > > > IMO=3D
> >
> > > > > to define, say, sin(oo) as an element of R*. OTOH, there is a
> > > > > reasonable way to define sin(oo) in an interval arithmetic:
> > > > > sin(oo) =
> =3D3D
> > > > > [-1, 1]. And =3D
> > > > I
> > > > > believe that Walster does exactly that.
> >
> > > > > David
> >
> > > > > > Note: References always welcome.
> >
> > > > > > Julio
> >
> > > > > > On Feb 11, 8:28=3D3DA0pm, David W. Cantrell
> > > > > > <DWCantr...@sigmaxi.ne=
> t>
> > > > > > wrote=3D
> > > > :
> > > > > > > ju...@diegidio.name wrote:
> > > > > > > > Hi Mariano, nice to hear from you!
> >
> > > > > > > > Someway, by digging the Wikipedia, the inconsistency you
> > > > > > > > have shown above led me to "wheel theory", and that looks
> > > > > > > > like what=
> I
> > > > > > > > was looking for:http://en.wikipedia.org/wiki/Wheel_theory
> >
> > > > > > > I doubt that that is what you're looking for; otherwise, I
> > > > > > > would=
>
> > > > > > > already have mentioned it to you. Why is it not what you're
> > > > > > > look=
> ing
> > > > > > > for? Well, in your first post, you specifically said that you
> > > > > > > wanted t=3D
> > > > o
> > > > > > > avoid NaN. But standard floating-point arithmetic is
> > > > > > > essentially=
> a
> > > > > > > wheel, and the element=3D3D
> >
> > > > > > > notated as _|_ in wheel theory is essentially the same as NaN
> > > > > > > in=
>
> > > > > > > floating-point arithmetic. For example, 0/0 is _|_ in a wheel
> > > > > > > an=
> d
> > > > > > > NaN in floating point. In neither is it reasonable, IMO, to
> > > > > > > call=
>
> > > > > > > 0/0 a "number".
> >
> > > > > > > > Not that I can already envision a way to implement this
> > > > > > > > extension. I=3D
> > > > n
> > > > > > > > fact, I could restart with my question over, despite in
> > > > > > > > slight=
> ly
> > > > > > > > mor=3D
> > > > e
> > > > > > > > proper terms, and, for instance, still wander what cos(oo),
> >
> > > > > > > It would have to be _|_, I should think.
> >
> > > > > > > > or oo %
> > > > > > > > 2pi for the sake, could ever be, though now on wheels. But,
> > > > > > > > at=
>
> > > > > > > > least=3D
> > > > ,
> > > > > > > > I am confident about the feasibility of the task.
> >
> > > > > > > > As for the practical perspective, I suppose extending my
> > > > > > > > algeb=
> ra
> > > > > > > > to wheels implies an extension of the set of meaningful
> > > > > > > > operations, and=3D
> > > > ,
> > > > > > > > iif this extension leads to a "significantly" broader
> > > > > > > > applicability,=3D
> >
> > > > > > > > then my struggle is justified. Of course, I can't yet
> > > > > > > > "prove" =
> my
> > > > > > > > premises.
> >
> > > > > > > > Moreover, the ideal situation from my perspective is that
> > > > > > > > some=
> one
> > > > > > > > ha=3D
> > > > d
> > > > > > > > already implemented an algebra on wheels, and that I could
> > > > > > > > jus=
> t
> > > > > > > > appl=3D
> > > > y
> > > > > > > > the basic recipe. I don't need to "reinvent the wheel", so
> > > > > > > > to say.
> >
> > > > > > > Before you try to implement a wheel, please compare it with
> > > > > > > floating-point=3D3D
> >
> > > > > > > arithmetic. And ask yourself how using _|_ might be
> > > > > > > preferable t=
> o
> > > > > > > usin=3D
ju...@diegidio.name
> > interval arithmetic sounds amazing to me, and I even envision it could
> > have some deep consequences on undecidability issues (I mean Goedel's
> > theorems and related) as well as P. vs NP. matters, etc. etc.
>
> I, OTOH, cannot envision any such thing.
Well, I could mention many facts here and there, like Smullyan
starting on Goedel's theorems with the assumption that "by expression,
we mean any finite non-empty string" of the given symbols: so no oo
and no o/o. Do we really need these restrictions? Doesn't this sound
like a system that is not closed to all operations? (Actually, the
whole Cantor's diagonalization idea to me sounds very very suspect,
valid up to a certain point along the "proof", than no more valid, and
so we prove... do we really prove anything? This is actually tied to
deeper questions into the very philosophical issues at the base of
logical reasoning, like what is "true", whether the reductio ad
absurdum is an acceptable way of reasoning, and so on, you guys know
much better than me.)
On the other hand, Walster tells about global optimization made
possible by reversing the approach to problem solving: rather than
trying to find the optimal solution, we discard incorrect ones. And to
me this is bloody it! This is what we engineers are doing day by day
in our problem-solving real needs coming from real people. And, in a
very practical sense, it "works" and actually is the only thing that
works.
And I could go on and on with uncountable more "suggestions" I get
from apparently unrelated fields. You know, I don't care at all about
exposing myself to ridiculous, because I am actually too serious and
never cheating. But you guys, *you* should know what I am talking
about, even if I cannot tell it properly.
Anyway I promise I'll be back in a couple of months, or in a couple of
years maybe, or even in a couple of lives, doesn't matter really, I'll
just sooner or later come back when I'll be ready to talk the "proper
language". The fact is, maybe that day I'll have no more questions to
ask, and - with all respect - that day it will be your turn. ;)
> Which theoretical community? Walster's work is well embraced, I think, by
> the interval-arithmetic community.
Where is that? I mean, I have found a lot about interval arithmetic,
but nobody seems to care about "extended interval arithmetic" and how
that means a system _closed to any operation_, and indeed *that* is
not something I could find anywhere apart from the few publications
from Walster and few colleagues of him, and even these are very sparse
and, from the late 90's up to today, the only things I could find are
few patents registered by Walster on behalf of Sun on some specific
techniques, along with a couple of books available from Amazon (I have
just ordered the last one from Walster).
To me this doesn't look like "well embraced". Moreover, to speak about
an "interval community", to my naive understanding of "doing
research", sounds like isolated compartments, which simply cannot be
the case when you want to go deep to the foundations of disciplines.
> A better question might be:
> Why is interval arithmetic not of greater general interest?
Hmm, how "general" you mean? I think any technician like me would
simply love it at first sight if they only knew about it. It's the
"mathematicians" and only them that to me are in question here.
Indeed, while your remark is "correct", and I'd love an answer to the
rephrased question, I hope you won't mind if I dare paraphrase from
you this time: the distinction between "correct although of no use"
and "incorrect" may be a matter of conventions, yet it leads to
dramatically different outcomes.
Julio
> > > > > d- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -...
>
> read more »
mike3
> > In other words, as a professional programmer and passionate about
> > computability and related matters, I can just say this extended
> > interval arithmetic sounds amazing to me, and I even envision it could
> > have some deep consequences on undecidability issues (I mean Goedel's
> > theorems and related) as well as P. vs NP. matters, etc. etc.
>
> I, OTOH, cannot envision any such thing.
>
Me neither.
> > Then why at least mathematicians do not seem so interested in it?
>
> > -- Q: Why is it so?
>
> A better question might be:
> Why is interval arithmetic not of greater general interest?
>
> But I'm not the one to answer that.
>
I'd be wondering though as to what your objection exactly is on wheel
theory.
You seem to object since you do not like the idea of calling the
element _|_ a "number". I don't see why: in the wheel system under
examination, _|_ *is* a "number". But if you insist that "number"
only apply to elements of the sets R and C, and not to elements like
oo and _|_ of certain extensions, then call it something else. But
what name you assign does not affect the theory, and that's what I'm
curious about.
mike3
That's right. What the wheel theory does is reinterpret the
expression x/y, so instead of meaning "multiply x by the
multiplicative inverse of y", it means "multiply x by /y,
where /y is the result of applying a certain unary operation
to y". The axioms that are defined guarantee that if y has a
multiplicative inverse, this is equivalent to the normal sense
of division, but even if such an inverse does not exist, the
expression x/y is still well-defined and meaningful in the
wheel sense of "division", even if it is not so in the usual
sense. Note that attempting to cancel out 0 with the "reciprocal"
/0 does not do that:
0x = -5
(0x)/0 = -5/0
(0x) * /0 = -5 * /0
However, 0x is not necessarily 0. In the end though we see
there's no solution in the wheel of amped-up reals: by the
axioms of wheel theory & the definitions for oo and _|_,
(0x) * /0 = -5 * oo
= oo
We now use the axiom
(x + 0y)z = xz + 0y,
with z = /0, x = 0, y = x. We get
(0x)/0 = 0/0 + 0x
= _|_ + 0x
= _|_.
So, the equation becomes
_|_ = oo
which is false. Hence we could not cancel out zero to try
and get x, just as we would expect since the equation 0x = -5
has no solution not even in the amped-up reals.
David W. Cantrell
> On Feb 25, 3:49 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> I'd be wondering though as to what your objection exactly is on wheel
> theory.
>
> You seem to object since you do not like the idea of calling the
> element _|_ a "number".
It's true that I prefer to think of the element _|_ as "not a number".
Recall that standard floating-point arithmetic is a wheel and, in it,
the element _|_ is denoted NaN, for "Not a Number".
But I don't think that my preference of thinking of _|_ as not a number
actually constitutes an objection to wheel theory.
> I don't see why: in the wheel system under
> examination, _|_ *is* a "number".
Well, it's an element of the system, and that's what's important.
> But if you insist that "number"
> only apply to elements of the sets R and C,
I don't. I'm also happy to apply "number" to elements of N, Z and Q. ;-)
But seriously, here's a question for you:
Do you consider the closed interval [0, 1] to be a number?
> and not to elements like
> oo and _|_ of certain extensions, then call it something else.
I consider oo to be a number. And note that, in the wheel of standard
floating-point arithmetic, -oo and +oo are numbers, as opposed to NaN.
> But what name you assign does not affect the theory,
Exactly.
David W. Cantrell
mike3
> mike3 <mike4...@yahoo.com> wrote:
> > On Feb 25, 3:49 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> [snip]
>
> > You seem to object since you do not like the idea of calling the
> > element _|_ a "number".
>
> It's true that I prefer to think of the element _|_ as "not a number".
> Recall that standard floating-point arithmetic is a wheel and, in it,
> the element _|_ is denoted NaN, for "Not a Number".
>
> But I don't think that my preference of thinking of _|_ as not a number
>
> > I don't see why: in the wheel system under
> > examination, _|_ *is* a "number".
>
> Well, it's an element of the system, and that's what's important.
>
Well, OK, then.
> > But if you insist that "number"
> > only apply to elements of the sets R and C,
>
> I don't. I'm also happy to apply "number" to elements of N, Z and Q. ;-)
>
Which are also elements of R and C, so, well... (since
N c Z c Q c R c C, where "A c B" means "A is a subset of B".)
> But seriously, here's a question for you:
>
> Do you consider the closed interval [0, 1] to be a number?
>
No, it's an interval.
> > and not to elements like
> > oo and _|_ of certain extensions, then call it something else.
>
> I consider oo to be a number. And note that, in the wheel of standard
> floating-point arithmetic, -oo and +oo are numbers, as opposed to NaN.
>
But why do you consider oo to be a number, yet _|_ is not
one? Your objection seems to be based on floating-point
arithmetic, where NaN is just that: NaN, Not a Number,
and then claiming that _|_ = NaN. But the real wheel is
not the same as floating point arithmetic: floating-point
is an approximation of real number arithmetic, as it is
based on fixed-length approximations, although maybe you
are considering an idealized system of infinite-precision
"floating point" arithmetic. Turns out, even that system
is _not_ a wheel, as / is not involutive: /0 = oo and /oo
= 0, but /(-oo) = 0, and yet /0 then equals oo, not -oo. But
the involutary nature of / is required by wheel theory. In
the construction of the real wheel we must extend the real
numbers via projective, not affine, infinity, turning the
line into a loop and setting -oo = oo so /(-oo) = /oo = 0,
and /0 = oo = -oo, avoiding the problem.
> > But what name you assign does not affect the theory,
>
> Exactly.
>
Nope, it doesn't. So, what do you think about wheel theory,
anyway?
David W. Cantrell
> On Mar 2, 8:07 am, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > mike3 <mike4...@yahoo.com> wrote:
> > > On Feb 25, 3:49 pm, David W. Cantrell <DWCantr...@sigmaxi.net>
> > > wrote:
> > [snip]
> > > I'd be wondering though as to what your objection exactly is on
> >
> > > You seem to object since you do not like the idea of calling the
> > > element _|_ a "number".
> >
> > It's true that I prefer to think of the element _|_ as "not a
> > number". Recall that standard floating-point arithmetic is a wheel
> > and, in it, the element _|_ is denoted NaN, for "Not a Number".
> >
> > But I don't think that my preference of thinking of _|_ as not a
> >
> > > I don't see why: in the wheel system under
> > > examination, _|_ *is* a "number".
> >
> > Well, it's an element of the system, and that's what's important.
>
> Well, OK, then.
>
> > > But if you insist that "number"
> > > only apply to elements of the sets R and C,
> >
> > I don't. I'm also happy to apply "number" to elements of N, Z and
> > Q. ;-)
>
> Which are also elements of R and C, so, well... (since
> N c Z c Q c R c C, where "A c B" means "A is a subset of B".)
Not for me. For example, Q is not a subset of R, although of course there
is an isomorphism between Q and a certain subset of R. I'm not being
pedantic. The nature of the elements _as mathematical objects_ has bearing,
at least IMO, later in this post.
> > But seriously, here's a question for you:
> >
> > Do you consider the closed interval [0, 1] to be a number?
You'll see later why I asked that question.
(And I'm glad that you said "No". ;-)
> No, it's an interval.
Of course, it's an interval, a _set_ of real number_s_. But in
interval analysis, it's also referred to as an interval _number_, and
there are arithmetic operations having such numbers as their operands,
etc.
> > > and not to elements like
> > > oo and _|_ of certain extensions, then call it something else.
> >
> > I consider oo to be a number. And note that, in the wheel of standard
> > floating-point arithmetic, -oo and +oo are numbers, as opposed to
> > NaN.
>
> But why do you consider oo to be a number, yet _|_ is not one?
See the end of my response.
> Your objection seems to be based on floating-point arithmetic,
No, it's not at all _based_ on floating-point arithmetic! I was
mentioning floating-point arithmetic merely because I believe that
Kahan et al. got their taxonomy (as to what are and are not numbers) right,
and that taxonomy is codified in an internationally accepted standard.
> where NaN is just that: NaN, Not a Number,
> and then claiming that _|_ = NaN. But the real wheel is
> not the same as floating point arithmetic: floating-point
> is an approximation of real number arithmetic, as it is
> based on fixed-length approximations, although maybe you
> are considering an idealized system of infinite-precision
> "floating point" arithmetic. Turns out, even that system
> is _not_ a wheel, as / is not involutive: /0 = oo and /oo
> = 0, but /(-oo) = 0, and yet /0 then equals oo, not -oo. But
> the involutary nature of / is required by wheel theory. In
> the construction of the real wheel we must extend the real
> numbers via projective, not affine, infinity, turning the
> line into a loop and setting -oo = oo so /(-oo) = /oo = 0,
> and /0 = oo = -oo, avoiding the problem.
What you've said is correct. Certainly standard floating-point
arithmetic merely attempts to approximate a version of extended real
arithmetic.
[You could have said much more. E.g., there are two signed zeros
corresponding to the two signed infinities. One of my "favorite
features" of floating-point arithmetic is that, while -0.0 and +0.0
are equal numerically, their respective reciprocals, -oo and +oo, are
certainly not!
You might be interested to know that, prior to the standard we have
now, consideration was given to requiring that two modes be available:
affine and projective, the latter having just one zero and one
infinity, both unsigned. But the idea of requiring that the projective
mode be available was dropped.]
> > > But what name you assign does not affect the theory,
> >
> > Exactly.
>
> Nope, it doesn't. So, what do you think about wheel theory, anyway?
Let's consider 0/0. I normally prefer a system in which 0/0 = 0, as
mentioned earlier in this thread. Computationally, 0 is hardly a "dead
end". OTOH, I tend to think of _|_ (or NaN) as being a "dead end". But of
course I'm not saying that there is no use for wheel theory; rather, I
would say that, if you're going to go in that direction, then go farther,
doing what Walster has done.
---------------------------------------
Suppose we are dealing with, say, the extended nonnegative reals, [0, +oo].
I think of its infinity as being a number because, as constructed from the
rationals (say, via cuts), it is the same type of mathematical object as
the nonnegative (finite) reals. (Historical anecdote: B. Russell, after
having constructed the nonnegative "reals" from the rationals via cuts,
refers to "the real number infinity".) Thus, since +oo is the same type of
mathematical object as the nonnegative reals, if we are to call them
"numbers", it seems only fair that we should call +oo a number as well.
---------------------------------------
Now back to 0/0. Any real x is a solution of 0*x = 0. Many use that fact to
argue that we should not define 0/0, but others use it to argue that 0/0
could reasonably be defined as the _set_ of all reals. It was, apparently,
the latter sort of reasoning which led to the invention of the wheel (but
using R*, the one-point extension of R, instead of R itself). As supporting
evidence, I cite the 2003 sci.math thread "0 / 0 = 0" in which Jesper
Carlstrom said "The first example of a wheel came from interval arith, with
0/0 being interpreted as the whole projective line, as Cantrell suggests."
So the reason I don't think of _|_ as being _a_ number in the real wheel is
that I think of it instead as being the _set_ of numbers R*. I suppose it's
exactly the same reason that you said earlier that you don't think of
[0, 1] as being a number. But I _do_ think of [0, 1] as being a number in
extended interval arithmetic and, similarly, I think of R* (equivalently,
_|_) as being a number there.
Thus, it's not that I don't think of _|_ as being a number, period. Rather,
it's that I don't think of it as being a number in the real wheel, in which
the structure of _|_ is obviously very different from the structure of all
the other elements, which I do regard as numbers in that wheel. And I do
think of _|_ as being a number in extended interval arithmetic in which the
structure of _|_ is the same as that of all the other elements.
David W. Cantrell
Julio Di Egidio
Pardon me a fast incursion, I hope it's not completely off mark.
If, as I get it, _|_ maps to the "entire interval" in interval arithmetic, what about the "empty interval"?
BTW (and FWIW), with o/o above I was referring to the empty interval.
Julio
David W. Cantrell
[snip]
> If, as I get it, _|_ maps to the "entire interval" in interval
> arithmetic, what about the "empty interval"?
>
> BTW (and FWIW), with o/o above I was referring to the empty interval.
That's a good question, I suppose, and I'm not sure I know the answer.
Very often, in interval arithmetic, only closed intervals are used. The
degenerate case is [c, c], often denoted as simply c. Of course, that
interval is not empty.
But what about using open intervals so that anything of the form (c, c) is
then the empty interval? Well, I can't remember having seen that done, but
that doesn't mean much. (Does Walster ever use the empty interval?)
--------------
On a broader note:
I'm more interested in general "set" arithmetic -- by which I mean a system
in which the operands of arithmetic operations are sets of numbers -- than
specifically in interval arithmetic.
Ramon Moore was the most significant expositor of interval arithmetic, but
set arithmetic (which of course includes interval arithmetic as a special
case) was developed at least as early as 1930 by R.C. Young in work for her
dissertation at Cambridge. (IIRC, Moore was unaware of Young's work when he
wrote _Interval Analysis_ in 1966.) Anyway, there's definitely a place for
the empty set in general set arithmetic, if not in interval arithmetic
itself.
David
Julio Di Egidio
> [snip]
> Does Walster ever use the empty interval?
Yes, definitely he does, and indeed his interval analysis is set-based!!
I've got the book[*] in the meantime. Here are few quotes from the chapter Closed Interval Systems:
<< The Set Foundation For Closed Interval Systems
Finite interval arithmetic, as introduced by Moore (1966) is based on intervals of real numbers. As such, finite interval arithmetic inherits the assumptions, axioms, and limitations of real analysis. Intervals have a dual identity both as numeric entities and as sets. Recognizing this duality is not new. See Moore (1992). What _is_ new is the recognition that because intervals are _sets_ of numbers, the fundamental analysis of intervals can be based on sets as opposed to individual real numbers. See Walster (1996). It is the set-theoretic interval foundation that enables limitations of real and finite interval analysis to be removed.>> (p.48)
<< The (Extended) Containment Constraint
For points within the domain of real BAOs [Basic Arithmetic Operators] and functions, the existing containment constraint must not be changed. Rather, the existing definition must be extended to include otherwise undefined interval operation-operand and function-argument combinations.
The approach taken is to _almost_, but not quite, beg the question of the extended containment constraint's definition. [1st constraint:] Rather then focusing only on the containment constraint of any single expression, consideration is broadened to include the set of _all possible_ containment constraints that result from _any_ algebraic transformation of the given expression. By making this one simple change, the door is opened to the extended containment constraint definition. [2nd constraint:] When algebraically transformed, the result of any expression evaluation must not cause the transformed expression's containment constraint to be violated. This is the key that unlocks the door to the needed generalization.>> (p.50)
<< Empty Sets and Intervals
To close the set-based arithmetic system, it is necessary to define arithmetic operations on empty sets [!!]. The logically consistent definition is for an arithmetic operation to produce the empty set if one or both operands is empty. This result is consistent with [the extended containment set] and is also consistent with the implicit constraint that the arguments of any expression E must be within or at least on the boundary of E's domain of definition, D(E). This implicit constraint can be made explicit to limit values of independent variables in different expressions.>> (p.56)
Follows an example with Sqrt leading me straight to a question: Remind that the book is on closed _real_ interval analysis; I wander if, extending further, with _complex_ closed systems (maybe it's already around?) we wouldn't finally get even rid of the above "implicit constraint". That is, as I'd say, a sort of "key of the "key"".
I could have missed something, but, hopefully, the essential is here.
Last but not least: if all goes well, in a week time I should finalize the alpha version of an interval library, now based directly on Walster's specification (spec.ps, please refer to the link kindly provided above by Mr Cantrell). The code is fully unit-tested. As far as correctness is concerned, I can only hope someone around here could help on the test cases (I mean, pseudo-code or any formal specification is perfect).
There could be much more to do, of course, but I am for the "one step at the time". Just to give an idea: The code (C++) is very simple, because I am implementing the so called real _simple_ system, though there is a _sharp_ and a _full_ system beyond that; in parallel, there is the extension to the complex sets. OTOH, I can say I mean to make an "open project" of this, to produce "free software". Multidisciplinary. You get the picture.
In the meantime, I can only say thank you!
Julio
[*] Eldon Ansen, G. William Walster, "Global Optimization Using Interval Analysis - Second Edition, Revised and Expanded", Dekker, 2004. As a side note, the first edition was from Hansen only, 1992.
Julio Di Egidio
> [...]
> the distinction between "correct although of no use"
> and "incorrect" may be a matter of conventions, yet
> it leads to dramatically different outcomes.
From a logical perspective, the outcome at stake is a mean to discard incorrect (false?) solutions. What this seems to entail - as said - is that even if we may not know what is correct, we can know how to not fail.
Julio
Julio Di Egidio
Since this doesn't appear on Amazon... I'm going again to hand-type. :) Underline stands for bold. There are few (I hope useful) notes for the technician who might be reading.
<< Foreward
Take note, _mathematicians_. Here you will find a new extension of real arithmetic to interval arithmetic for containment sets (csets) in which there are no undefined operand-operator combinations such as previously "_indeterminate_ forms" 0/0, oo - oo, etc.
Take note, _hardware and software engineers, programmers and computer users_. Here you will find arithmetic with containment sets which is exception free, so exception event handling is unnecessary [i.e., any expression is defined on the entire domain].
The main content of the volume consists of _interval algorithms for computing guaranteed enclosures_ of the sets of points where constrained global optimization occurs [though the treatment is strictly formal]. The use of interval methods provides computational proofs of existence and location of global optima. Computer software implementations use outwardly rounded intervals (cset) arithmetic to guarantee that even rounding errors are bounded in the computation. The results are mathematically rigorous.
Computer-aided proofs of theorems and long-standing conjectures in analysis have been carried out using outwardly rounded interval arithmetic, including, for example, the Kepler conjecture - finally proved after 300 years. See "Perspectives on Enclosures Methods", U. Kulish, R. Lohner and A. Fascius (eds.), Springer, 2001.
[...]>>
BTW, sorry...
>> The use of interval methods provides computational proofs of existence and location of global optima.
To me, this connects to the NP question.
:)
Julio
Julio Di Egidio
I glimpse this is a bit like the limit ad infinitum of Goedelization, i.e. the very sentence "containing" it.
And now, really time to stop my "machine". Good night.
Julio
ju...@diegidio.name
numbers".
On Mar 6, 5:48 am, Julio Di Egidio <ju...@diegidio.name> wrote:
> I must dare go past that point [...]
As far as "suggestions" go (and I must tell you they are running light-
speed at the moment), here is a rephrase from the Russel's Paradox:
A set contains numbers, and a number is a set. What then is the empty
set?
Unpondered as it may be...
Julio