Computing infinity modulus and zero modulus

32 views

ju...@diegidio.name

Feb 8, 2008, 12:29:43 PM2/8/08
to
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.

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

Feb 8, 2008, 2:46:07 PM2/8/08
to
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. 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 athttp://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,

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

Feb 8, 2008, 5:34:19 PM2/8/08
to
"Mariano_Suárez-Alvarez" <mariano.su...@gmail.com> wrote:
> 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

> > 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?

> > 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)).

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

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

Feb 9, 2008, 11:45:14 PM2/9/08
to
Hi back,

> > 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

Feb 9, 2008, 11:57:32 PM2/9/08
to
> For functions, such as the tangent, I suppose I can keep using my
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

Feb 10, 2008, 12:28:35 AM2/10/08
to
And - I beg your pardon again, I promise this is the last for tonight
- 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

Feb 10, 2008, 5:36:38 AM2/10/08
to
On Feb 8, 8:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:

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

Feb 10, 2008, 10:52:10 AM2/10/08
to
"Mariano_Suárez-Alvarez" <mariano.su...@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)
> >
> > 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

Feb 10, 2008, 12:04:25 PM2/10/08
to
ju...@diegidio.name wrote:
> Hi back,
>
> Thanks for the great answers!

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

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

Feb 10, 2008, 4:06:56 PM2/10/08
to
There is, after all, one specific property I may need to preserve: %
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

Feb 10, 2008, 4:16:03 PM2/10/08
to
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

ju...@diegidio.name

Feb 10, 2008, 4:52:56 PM2/10/08
to
Errata: Sorry, sometimes I make mistakes as a result of later editing
(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

Feb 10, 2008, 7:45:27 PM2/10/08
to
On Feb 10, 1:52 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> "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)
>
> > > 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

Feb 10, 2008, 8:58:44 PM2/10/08
to
"Mariano_Suárez-Alvarez" <mariano.su...@gmail.com> wrote:
> On Feb 10, 1:52 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > "Mariano_Su=E1rez-Alvarez" <mariano.suarezalva...@gmail.com> wrote:
> > > On Feb 8, 8:34 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > > "Mariano_Su=E1rez-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:

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

Feb 10, 2008, 10:16:41 PM2/10/08
to
On Feb 10, 11:58 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> Actually you introduced "the

> 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

Feb 10, 2008, 11:41:50 PM2/10/08
to
ju...@diegidio.name wrote:
> 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

Feb 10, 2008, 11:47:09 PM2/10/08
to
Ok, and thank you for your invaluable support.

If I'll ever manage to ship, this discussion will make an integral
part of the documentation.

Julio

Mariano Suárez-Alvarez

Feb 11, 2008, 12:18:32 AM2/11/08
to

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

Feb 11, 2008, 1:16:03 PM2/11/08
to
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

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,

As for the practical perspective, I suppose extending my algebra to
wheels implies an extension of the set of meaningful operations, and,
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

Feb 11, 2008, 3:28:25 PM2/11/08
to
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,
>
> As for the practical perspective, I suppose extending my algebra to
> wheels implies an extension of the set of meaningful operations, and,
> 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

Feb 11, 2008, 4:13:47 PM2/11/08
to
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

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

Feb 11, 2008, 5:03:54 PM2/11/08
to
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 = 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

Feb 11, 2008, 6:35:28 PM2/11/08
to
> 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. 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

Feb 11, 2008, 6:51:45 PM2/11/08
to
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/~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

Feb 11, 2008, 7:25:40 PM2/11/08
to
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 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

> > > - Show quoted text -- Hide quoted text -

ju...@diegidio.name

Feb 12, 2008, 12:49:56 AM2/12/08
to
As a matter of fact, this discussion is now officially part of the

http://architectando.blogspot.com/2008/02/on-correctness.html

Thank you.

Julio

Mariano Suárez-Alvarez

Feb 12, 2008, 12:56:59 AM2/12/08
to
On Feb 12, 3:49 am, ju...@diegidio.name wrote:
> As a matter of fact, this discussion is now officially part of the
>
> 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

ju...@diegidio.name

Feb 12, 2008, 1:43:24 AM2/12/08
to
> Consider the full set of systems for a given problem: IS* = S + oo + 0/0, where S is the set of bounded correct systems, oo is the set of full-correct systems, and 0/0 is the set of failing systems. IS* so defined can be treated in terms of interval arithmetic.

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

Feb 25, 2008, 2:13:51 PM2/25/08
to
Hello back,

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?

-------

Julio

On Feb 12, 12:25 am, ju...@diegidio.name wrote:

Message has been deleted

David W. Cantrell

Feb 25, 2008, 5:49:30 PM2/25/08
to

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

> -------
>
>
> 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<