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
> 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
"Mariano_Suárez-Alvarez" <mariano.suarezalva...@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 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...
> > 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. > > > My goal is no operation of any kind should ever return NaN, that is no > > > operation should be undefined.
> 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 -
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.
> 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" <mariano.suarezalva...@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 > 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...
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.
"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.
> ---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
> > > 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."
> 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: > > "Mariano_Su=E1rez-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.
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
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
On Feb 10, 5:04 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > > 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: > > > "Mariano_Su=E1rez-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 -
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."
> 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
> 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
> On Feb 10, 5:04 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > > > 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: > > > > "Mariano_Su=E1rez-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 -
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... :)
> 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."
> > 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
> > 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
> > On Feb 10, 5:04 pm, David W. Cantrell <DWCantr...@sigmaxi.net> wrote:
> > > > > > 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: > > > > > "Mariano_Su=E1rez-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 -
> "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.
"Mariano_Suárez-Alvarez" <mariano.suarezalva...@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.
> "Mariano_Suárez-Alvarez" <mariano.suarezalva...@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. > 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.
> 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.
> > 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.
> 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
> 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? :)]
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.
> 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!
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! :)
<mariano.suarezalva...@gmail.com> wrote: > On Feb 10, 7:06 pm, ju...@diegidio.name wrote:
> > 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
> > 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? :)]
> 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.
> > 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!
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 arithmetic. And ask yourself how using _|_ might be preferable to using NaN!
> 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 > arithmetic. And ask yourself how using _|_ might be preferable to using > NaN!
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.
> 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=
> > arithmetic. And ask yourself how using _|_ might be preferable to using > > NaN!
> 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
On Feb 11, 10:03 pm, 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 = 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=
> > > arithmetic. And ask yourself how using _|_ might be preferable to using > > > NaN!
> 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= > g > > > > NaN!
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:
> > 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= > > g > > > > > NaN!
|
