On 01/12/08 08:39, Bill McCarthy wrote:

[...]

> My C docs say a negative number produces a domain error. A

> zero produces a range error. Assuming these Open Watcom

> docs are correct, I've specified the argument must be a

> positive NUMBER or FLOAT, hence my notation (0,inf] - you

> correctly assumed my "(" means open and "]" means closed for

> ranges. Of course it may be better to always consider "inf"

> as open.

>

> Please let me know if you spot any errors or a need for

> clarification.

>

Not sure if it was an error, a need for clarification, or both, or neither.

":echo log(0)" answers -inf

":echo log(log(0))" answers nan

":echo log(log(log(0)))" still answers nan

":echo log( 1. / 0. ) gives three Vim errors (the first of which is

"E15: Invalid expression: / 0. )"

IOW, specific floating-point errors are not handled the same way as

errors on operators which were primarily designed for integers (even if,

like "/", they were later extended to floats). I suppose generating INF

and NaN results, and no exceptions, is correct from the point of view of

the IEEE floating-point standards.

<digression>

And about the interval, I didn't spot it, or my old latin-math high

school teachings would have kicked in, where, indeed, infinity used to

be supposed to be always an open bound. Strictly speaking, log(0) is

undefined and the log function has a minus-infinity limit when its

argument tends towards zero by positive values. In common language, one

could say (except, maybe, at a math exam) that the logarithm of zero

"is" minus infinity, and that's obviously what the IEEE standard (or at

least my gcc version's implementation of it) is following.

However, I learnt algebra (and calculus) on number sets the fullest of

which is the field of complex numbers, which has no infinity element; in

projective geometry I "sort of used" lines with one infinity point

(actually, "infinity" had no meaning from a projective POV but the

"completed affine plane" used to map the projective plane onto the

affine has one line at infinity -- one of my math teachers used to say:

"take a projective plane, remove one line, and what you get is an affine

plane. If instead of removing it you paint it red, what you get is the

completed affine plane". When using analytical geometry, real or complex

numbers (still with no "infinity" number) were still used, the trick

being that instead of using N cartesian coordinates (where N is the

dimension, 2 for a plane, later 3 for 3-dimensional "space") one would

use N+1 real (or complex) coordinates, not all zero and given (how does

one say in English?) "à un facteur près" (modulo an arbitrary common

factor? I don't like using "modulo" in this sense because "modulo", in

math, is usually the arithmetic remainder operation).

</digression>

So a number set with two infinity elements is, I guess, as far as one

could go from the math I learnt and still remain [somewhat] understandable.

I suppose the previous digression is out of place here: if you like math

you probably already knew all of it, and if you don't you probably

skipped it (and rightly so). Ah, well... maybe I just didn't teach math

long enough to lose my passion for analytical geometry (as taught in

upper high school and lower college years, on second-degree curves and

surfaces using, mostly, real polynomials on complex number sets) -- but

i'm starting to digress again. Let's stop before I lose my current

audience. ;-)

Best regards,

Tony.

--

It is something to be able to paint a particular picture, or to carve a

statue, and so to make a few objects beautiful; but it is far more

glorious to carve and paint the very atmosphere and medium through

which we look, which morally we can do. To affect the quality of the

day, that is the highest of arts.

-- Henry David Thoreau, "Where I Live"

--~--~---------~--~----~------------~-------~--~----~

You received this message from the "vim_dev" maillist.

For more information, visit http://www.vim.org/maillist.php

-~----------~----~----~----~------~----~------~--~---- On Mon 1-Dec-08 2:46am -0600, Tony Mechelynck wrote:

>

I build with Make_ming.mak under Windows.

> On 01/12/08 08:39, Bill McCarthy wrote:

> [...]

>> My C docs say a negative number produces a domain error. A

>> zero produces a range error. Assuming these Open Watcom

>> docs are correct, I've specified the argument must be a

>> positive NUMBER or FLOAT, hence my notation (0,inf] - you

>> correctly assumed my "(" means open and "]" means closed for

>> ranges. Of course it may be better to always consider "inf"

>> as open.

>>

>> Please let me know if you spot any errors or a need for

>> clarification.

>>

> Not sure if it was an error, a need for clarification, or both, or neither.

>

> ":echo log(0)" answers -inf

> ":echo log(log(0))" answers nan

> ":echo log(log(log(0)))" still answers nan

> ":echo log( 1. / 0. ) gives three Vim errors (the first of which is

> "E15: Invalid expression: / 0. )"

:echo log(0)

-1.#INFe

:echo log(-1)

-1.#INDe

If I write this in C:

#include <stdio.h>

#include <stdlib.h>

#include <math.h>

int main( void )

{

printf("%g\n",log(0.0));

printf("%g\n",log(-1.0));

return EXIT_SUCCESS;

}

Then compile/link with gcc I get:

-1.#INF

-1.#IND

But when I compile/link with Open Watcom I get:

-inf

-nan

This is quite strange, but not the fault of Vim (except

perhaps that 'e' at the end).

--

Best regards,

Bill

--~--~---------~--~----~------------~-------~--~----~

You received this message from the "vim_dev" maillist.

For more information, visit http://www.vim.org/maillist.php

-~----------~----~----~----~------~----~------~--~--- - On 02/12/08 05:31, Bill McCarthy wrote:
> On Mon 1-Dec-08 2:46am -0600, Tony Mechelynck wrote:

Apparently the MinGW gcc libraries handles infinities and not-a-numbers

>

>> On 01/12/08 08:39, Bill McCarthy wrote:

>> [...]

>>> My C docs say a negative number produces a domain error. A

>>> zero produces a range error. Assuming these Open Watcom

>>> docs are correct, I've specified the argument must be a

>>> positive NUMBER or FLOAT, hence my notation (0,inf] - you

>>> correctly assumed my "(" means open and "]" means closed for

>>> ranges. Of course it may be better to always consider "inf"

>>> as open.

>>>

>>> Please let me know if you spot any errors or a need for

>>> clarification.

>>>

>

>> Not sure if it was an error, a need for clarification, or both, or neither.

>>

>> ":echo log(0)" answers -inf

>> ":echo log(log(0))" answers nan

>> ":echo log(log(log(0)))" still answers nan

>> ":echo log( 1. / 0. ) gives three Vim errors (the first of which is

>> "E15: Invalid expression: / 0. )"

>

> I build with Make_ming.mak under Windows.

>

> :echo log(0)

> -1.#INFe

> :echo log(-1)

> -1.#INDe

>

> If I write this in C:

>

> #include<stdio.h>

> #include<stdlib.h>

> #include<math.h>

>

> int main( void )

> {

> printf("%g\n",log(0.0));

> printf("%g\n",log(-1.0));

> return EXIT_SUCCESS;

> }

>

> Then compile/link with gcc I get:

>

> -1.#INF

> -1.#IND

>

> But when I compile/link with Open Watcom I get:

>

> -inf

> -nan

>

> This is quite strange, but not the fault of Vim (except

> perhaps that 'e' at the end).

>

differently than the Linux gcc libraries (where I saw "-inf" and "nan"

as quoted above) when it comes to display them. (":echo log(-1.0)"

displays "nan" for me, without a sign.)

Notice the sentence near the bottom of ":help sqrt()":

"nan" may be different, it depends on system libraries.

I found it by ":helpgrep \<nan\>" which gives only three matches.

Best regards,

Tony.

--

Eight Megabytes And Continually Swapping.

--~--~---------~--~----~------------~-------~--~----~

You received this message from the "vim_dev" maillist.

For more information, visit http://www.vim.org/maillist.php

-~----------~----~----~----~------~----~------~--~---