Loading ...
Sorry, an error occurred while loading the content.

Re: Runtime Files

Expand Messages
  • Tony Mechelynck
    On 01/12/08 08:39, Bill McCarthy wrote: [...] ... Not sure if it was an error, a need for clarification, or both, or neither. :echo log(0) answers -inf
    Message 1 of 8 , Dec 1, 2008
    • 0 Attachment
      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
      -~----------~----~----~----~------~----~------~--~---
    • Bill McCarthy
      ... I build with Make_ming.mak under Windows. ... -1.#INFe ... -1.#INDe If I write this in C: #include #include #include int
      Message 2 of 8 , Dec 1, 2008
      • 0 Attachment
        On Mon 1-Dec-08 2:46am -0600, Tony Mechelynck wrote:

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

        --
        Best regards,
        Bill


        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Tony Mechelynck
        ... Apparently the MinGW gcc libraries handles infinities and not-a-numbers differently than the Linux gcc libraries (where I saw -inf and nan as quoted
        Message 3 of 8 , Dec 3, 2008
        • 0 Attachment
          On 02/12/08 05:31, Bill McCarthy wrote:
          > On Mon 1-Dec-08 2:46am -0600, Tony Mechelynck wrote:
          >
          >> 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).
          >

          Apparently the MinGW gcc libraries handles infinities and not-a-numbers
          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
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.