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

Floating point syntax

Expand Messages
  • Ben Schmidt
    Hi, folks, The earlier thread where Bram asked for comments on floating point syntax, after quite a few suggestions were made and rejected for compatibility
    Message 1 of 15 , Jun 4, 2008
    • 0 Attachment
      Hi, folks,

      The earlier thread where Bram asked for comments on floating point
      syntax, after quite a few suggestions were made and rejected for
      compatibility reasons, petered out. However, two proposals were made
      that I think had merit, and I wonder if people have additional comment
      on them, and perhaps may see them if part of a new thread!

      The first proposal was mine:

      - I pointed out that there is actually possibly ambiguity in the current
      syntax unless a float is required to have a decimal point or exponent,
      as &123.456 could mean float 123.456 or float 123 (123.0) concatenated
      with integer 456. If the requirement is added, the ambiguity is
      removed, but &123 is invalid, which is a bit of a shame.

      - I proposed an alternative syntax that I prefer and I think is likely
      to be more robust in the long run: enclosing floats in curly braces.
      E.g. {123.456}. Specifically, a set of curly braces would be taken to
      represent a float if and only if it is (1) not preceded by a valid
      variable name character and (2) contains a valid float. Nobody came up
      with any reason this would not work.

      The second was a proposal to represent floats as numbers with decimal
      points but no additional punctuation which was implicit in this report
      from Ilya Bobir:

      - I did a search for vim scripts that use concatenation operation
      between two numbers without interleaving space. It appears that
      Google Code Search was able to find only 39 matches and all were
      false positives.

      Nobody gave any reply to the message.

      I would like to note, though, that this doesn't solve the problem for
      exponent notation. However, I suspect a search of vim scripts containing
      numbers of that form would yield even less results, though I have not
      tried it. The search also doesn't take into account expressions that may
      be built dynamically in vim scripts rather than being hard coded, but
      again, I doubt many if any of these exist.

      I personally would prefer either of these syntaxes to the notation with
      the ampersand.

      Do people have further comments/thoughts on this? Is Bram still
      interested in hearing them?

      The earlier thread which contains more details can be read here:

      http://groups.google.com/group/vim_dev/browse_thread/thread/1c8806e536ec12cd

      The relevant posts are at the end. The last 7 or so, which happen to
      nicely form the second page of posts at present.

      Ben.





      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Bram Moolenaar
      ... The . operator only works on strings. There is no automatic conversion of a float to a string, so a . after a float is invalid. And with a single .
      Message 2 of 15 , Jun 4, 2008
      • 0 Attachment
        Ben Schmidt wrote:

        > The earlier thread where Bram asked for comments on floating point
        > syntax, after quite a few suggestions were made and rejected for
        > compatibility reasons, petered out. However, two proposals were made
        > that I think had merit, and I wonder if people have additional comment
        > on them, and perhaps may see them if part of a new thread!
        >
        > The first proposal was mine:
        >
        > - I pointed out that there is actually possibly ambiguity in the current
        > syntax unless a float is required to have a decimal point or exponent,
        > as &123.456 could mean float 123.456 or float 123 (123.0) concatenated
        > with integer 456. If the requirement is added, the ambiguity is
        > removed, but &123 is invalid, which is a bit of a shame.

        The "." operator only works on strings. There is no automatic
        conversion of a float to a string, so a "." after a float is invalid.
        And with a single "." it's part of the float, no matter what follows.

        > - I proposed an alternative syntax that I prefer and I think is likely
        > to be more robust in the long run: enclosing floats in curly braces.
        > E.g. {123.456}. Specifically, a set of curly braces would be taken to
        > represent a float if and only if it is (1) not preceded by a valid
        > variable name character and (2) contains a valid float. Nobody came up
        > with any reason this would not work.

        It would work, but I think &123.456 looks better than {123.456}. And we
        might want to use {} for something else (if possible, since it's already
        used for curly-braces-names).

        > The second was a proposal to represent floats as numbers with decimal
        > points but no additional punctuation which was implicit in this report
        > from Ilya Bobir:
        >
        > - I did a search for vim scripts that use concatenation operation
        > between two numbers without interleaving space. It appears that
        > Google Code Search was able to find only 39 matches and all were
        > false positives.
        >
        > Nobody gave any reply to the message.

        I wonder how you do that search. And if you manage to come up with the
        right pattern, what the number of matches actually means.

        > I would like to note, though, that this doesn't solve the problem for
        > exponent notation. However, I suspect a search of vim scripts containing
        > numbers of that form would yield even less results, though I have not
        > tried it. The search also doesn't take into account expressions that may
        > be built dynamically in vim scripts rather than being hard coded, but
        > again, I doubt many if any of these exist.
        >
        > I personally would prefer either of these syntaxes to the notation with
        > the ampersand.
        >
        > Do people have further comments/thoughts on this? Is Bram still
        > interested in hearing them?

        Yes, but most people appear to be OK with the &123.456 syntax. Thus if
        you want something else, you need to come up with good arguments.

        > The earlier thread which contains more details can be read here:
        >
        > http://groups.google.com/group/vim_dev/browse_thread/thread/1c8806e536ec12cd
        >
        > The relevant posts are at the end. The last 7 or so, which happen to
        > nicely form the second page of posts at present.

        --
        It doesn't really matter what you are able to do if you don't do it.
        (Bram Moolenaar)

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Ilya Bobir
        ... I ve explained how I did the search in my email on that thread. Probably you missed it, so I include this email here. Here it goes: ... If something is
        Message 3 of 15 , Jun 4, 2008
        • 0 Attachment
          Bram Moolenaar wrote:
          > [...]
          >> The second was a proposal to represent floats as numbers with decimal
          >> points but no additional punctuation which was implicit in this report
          >> from Ilya Bobir:
          >>
          >> - I did a search for vim scripts that use concatenation operation
          >> between two numbers without interleaving space. It appears that
          >> Google Code Search was able to find only 39 matches and all were
          >> false positives.
          >>
          >> Nobody gave any reply to the message.
          >>
          >
          > I wonder how you do that search.
          I've explained how I did the search in my email on that thread.
          Probably you missed it, so I include this email here. Here it goes:

          Ilya Bobir wrote:
          > Bram Moolenaar wrote:
          >
          >> [...]
          >>
          >> I would still like feedback on the format of floating point numbers:
          >>
          >> &123.456
          >> &1.23e-3
          >>
          >>
          >
          > I did a search for vim scripts that use concatenation operation between two
          > numbers without interleaving space. It appears that Google Code Search was
          > able to find only 39 matches and all where false positives.
          > Here is the query:
          >
          > http://www.google.com/codesearch?hl=ru&q=+lang:vim+%5E%5Cs*%5B%5E%22%5C+%5D(%22(%5C%5C.%7C%5B%5E%22%5D)*%22%7C%27%5B%5E%27%5D*%27%7C%5B%5E%22%5D)*%5Cs%5Cd%2B%5C.%5Cd%2B%5Cs+-menu&start=30&sa=N
          >
          > And here is a regex I've used (along with explanations). Maybe someone will
          > double check to make sure I did not mistake.
          >
          > lang:vim | Vim script language.
          > ^\s*[^"\ ] | In order to exclude comments the line should
          > | start with anything but ".
          > ( | Catches different kind of strings.
          > " ( \\. | [^"] )* " | Double quoted strings along with escapes
          > | inside the string.
          > | ' [^']* ' | Single quoted strings.
          > | [^"] | All the rest is OK. And there maybe some
          > | staff preceding the digits.
          > )* |
          > \s\d+\.\d+\s | A pattern that I was looking for - two numbers
          > | concatenated without an interleaving space
          > | that are not part of a longer sequence.
          > -menu | menu command uses dot separated numbers to set
          > | priority. There are plenty of them and all
          > | are false positives, so remove all lines with
          > | "menu" string in them.
          >

          If something is hard to understand, please ask, I'll try to explain
          another way. English is not my native language and sometimes I really
          have no clue whether what I write is understandable at all =)

          > And if you manage to come up with the
          > right pattern, what the number of matches actually means.
          >

          The number of matches is the number of lines that have two numbers
          concatenated without interleaving spaces. A real match would mean that
          adding a "common" syntax for floats into Vim script would break a script
          with the match.
          It appeared that all 39 matches was false positives meaning that all of
          them was really something else and was matched only because the pattern
          I've used it not perfect. I checked all 39 matches by hand. You can
          easily see them by following a link in my original e-mail that I've
          quoted above.
          To sum it up, it appears that among all the vim scripts that are indexed
          by Google there are none that use the "common" float syntax to
          concatenate two numbers. This means using the "common" syntax for
          floats will not break any of these scripts.
          There still is a chance that some scripts use dynamically generated
          expressions that have two numbers concatenated without interleaving
          spaces but it is unlikely as one does not need a concatenation operation
          to concatenate numbers when building a dynamic expression - you can just
          put them in the result side by side.

          > Ben Schmidt wrote:
          >> I would like to note, though, that this doesn't solve the problem for
          >> exponent notation. However, I suspect a search of vim scripts containing
          >> numbers of that form would yield even less results, though I have not
          >> tried it. The search also doesn't take into account expressions that may
          >> be built dynamically in vim scripts rather than being hard coded, but
          >> again, I doubt many if any of these exist.
          >>

          If there are no scripts that use two numbers with a dot in between
          without interleaving spaces then it follows that there are none that
          have these kind of numbers with an exponent appended. And it means that
          if the float syntax will be smart enough to tell a float without an
          exponent from a concatenation then adding an exponent as a suffix will
          not introduce any ambiguity. Am I missing something?

          Ilya Bobir

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Bram Moolenaar
          ... It s not perfect and Google code search certainly doesn t contain every Vim script, but it s an indication. ... I meant: Since Google code search contains
          Message 4 of 15 , Jun 4, 2008
          • 0 Attachment
            Ilya Bobir wrote:

            > Bram Moolenaar wrote:
            > > [...]
            > >> The second was a proposal to represent floats as numbers with decimal
            > >> points but no additional punctuation which was implicit in this report
            > >> from Ilya Bobir:
            > >>
            > >> - I did a search for vim scripts that use concatenation operation
            > >> between two numbers without interleaving space. It appears that
            > >> Google Code Search was able to find only 39 matches and all were
            > >> false positives.
            > >>
            > >> Nobody gave any reply to the message.
            > >>
            > >
            > > I wonder how you do that search.
            >
            > I've explained how I did the search in my email on that thread.
            > Probably you missed it, so I include this email here. Here it goes:
            >
            > Ilya Bobir wrote:
            > > Bram Moolenaar wrote:
            > >
            > >> [...]
            > >>
            > >> I would still like feedback on the format of floating point numbers:
            > >>
            > >> &123.456
            > >> &1.23e-3
            > >>
            > >>
            > >
            > > I did a search for vim scripts that use concatenation operation between two
            > > numbers without interleaving space. It appears that Google Code Search was
            > > able to find only 39 matches and all where false positives.
            > > Here is the query:
            > >
            > > http://www.google.com/codesearch?hl=ru&q=+lang:vim+%5E%5Cs*%5B%5E%22%5C+%5D(%22(%5C%5C.%7C%5B%5E%22%5D)*%22%7C%27%5B%5E%27%5D*%27%7C%5B%5E%22%5D)*%5Cs%5Cd%2B%5C.%5Cd%2B%5Cs+-menu&start=30&sa=N
            > >
            > > And here is a regex I've used (along with explanations). Maybe someone will
            > > double check to make sure I did not mistake.
            > >
            > > lang:vim | Vim script language.
            > > ^\s*[^"\ ] | In order to exclude comments the line should
            > > | start with anything but ".
            > > ( | Catches different kind of strings.
            > > " ( \\. | [^"] )* " | Double quoted strings along with escapes
            > > | inside the string.
            > > | ' [^']* ' | Single quoted strings.
            > > | [^"] | All the rest is OK. And there maybe some
            > > | staff preceding the digits.
            > > )* |
            > > \s\d+\.\d+\s | A pattern that I was looking for - two numbers
            > > | concatenated without an interleaving space
            > > | that are not part of a longer sequence.
            > > -menu | menu command uses dot separated numbers to set
            > > | priority. There are plenty of them and all
            > > | are false positives, so remove all lines with
            > > | "menu" string in them.
            > >
            >
            > If something is hard to understand, please ask, I'll try to explain
            > another way. English is not my native language and sometimes I really
            > have no clue whether what I write is understandable at all =)

            It's not perfect and Google code search certainly doesn't contain every
            Vim script, but it's an indication.

            > > And if you manage to come up with the
            > > right pattern, what the number of matches actually means.
            >
            > The number of matches is the number of lines that have two numbers
            > concatenated without interleaving spaces. A real match would mean that
            > adding a "common" syntax for floats into Vim script would break a script
            > with the match.

            I meant: Since Google code search contains only a subset of all the Vim
            scripts, what does it mean not to find a text string there that looks
            like a floating point number? There might be one very important Vim
            script that breaks that isn't in Google code search.

            [...]

            Anyway, here is a patch to accept plain floating point numbers. Goes on
            top of the previous floating point patch. Give it a try and find out if
            any of your scripts break.


            *** ../vim-7.1.311/src/eval.c Thu May 29 21:46:10 2008
            --- src/eval.c Wed Jun 4 22:41:20 2008
            ***************
            *** 4600,4613 ****
            case '7':
            case '8':
            case '9':
            ! vim_str2nr(*arg, NULL, &len, TRUE, TRUE, &n, NULL);
            ! *arg += len;
            ! if (evaluate)
            {
            ! rettv->v_type = VAR_NUMBER;
            ! rettv->vval.v_number = n;
            }
            break;

            /*
            * String constant: "string".
            --- 4799,4847 ----
            case '7':
            case '8':
            case '9':
            ! {
            ! #ifdef FEAT_FLOAT
            ! char_u *p = skipdigits(*arg + 1);
            ! int get_float = FALSE;
            !
            ! /* We accept a float when the format matches
            ! * "[0-9]\+\.[0-9]\+\([eE][+-]\?[0-9]\+\)\?". This is very
            ! * strict to avoid backwards compatibility problems. */
            ! if (p[0] == '.' && vim_isdigit(p[1]))
            ! {
            ! get_float = TRUE;
            ! p = skipdigits(p + 2);
            ! if (*p == 'e' || *p == 'E')
            ! {
            ! ++p;
            ! if (*p == '-' || *p == '+')
            ! ++p;
            ! if (!vim_isdigit(*p))
            ! get_float = FALSE;
            ! else
            ! p = skipdigits(p + 1);
            ! }
            ! if (ASCII_ISALPHA(*p) || *p == '.')
            ! get_float = FALSE;
            ! }
            ! if (get_float)
            {
            ! --*arg; /* pretend there is a '&' TODO: remove */
            ! get_float_tv(arg, rettv, evaluate);
            ! }
            ! else
            ! #endif
            ! {
            ! vim_str2nr(*arg, NULL, &len, TRUE, TRUE, &n, NULL);
            ! *arg += len;
            ! if (evaluate)
            ! {
            ! rettv->v_type = VAR_NUMBER;
            ! rettv->vval.v_number = n;
            ! }
            }
            break;
            + }

            /*
            * String constant: "string".

            --
            It's totally unfair to suggest - as many have - that engineers are socially
            inept. Engineers simply have different objectives when it comes to social
            interaction.
            (Scott Adams - The Dilbert principle)

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Nico Weber
            ... I still haven t seen any good arguments why an editor needs floating point numbers at all, other than hey, it can be done without breaking old scripts
            Message 5 of 15 , Jun 4, 2008
            • 0 Attachment
              > Yes, but most people appear to be OK with the &123.456 syntax. Thus
              > if
              > you want something else, you need to come up with good arguments.

              I still haven't seen any good arguments why an editor needs floating
              point numbers at all, other than "hey, it can be done without breaking
              old scripts with just slightly awkward syntax" :-)

              Nico

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Bill McCarthy
              ... My eval.c is the current release patched by both your latest and John Beckett s fix. You new patch fails with: vim vimfp patch -b -p 0 -i
              Message 6 of 15 , Jun 4, 2008
              • 0 Attachment
                On Wed 4-Jun-08 3:42pm -0600, Bram Moolenaar wrote:

                > Anyway, here is a patch to accept plain floating point numbers. Goes on
                > top of the previous floating point patch. Give it a try and find out if
                > any of your scripts break.

                My eval.c is the current release patched by both your latest
                and John Beckett's fix. You new patch fails with:

                vim\vimfp> patch -b -p 0 -i Brams-may_not_work_with_jb.diff
                patching file src/eval.c
                Hunk #1 FAILED at 4799.
                1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

                I'm not great at reading patch files, but my eval.c does
                contain:

                ===============================================
                case '7':
                case '8':
                case '9':
                vim_str2nr(*arg, NULL, &len, TRUE, TRUE, &n, NULL);
                *arg += len;
                if (evaluate)
                {
                rettv->v_type = VAR_NUMBER;
                rettv->vval.v_number = n;
                }
                break;

                /*
                * String constant: "string".
                ===============================================

                So it looks like - to me - that you patch should patch.

                --
                Best regards,
                Bill


                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Bram Moolenaar
                ... We don t really need :sort either. It s just that it s very convenient to have sorting and floating point numbers for writing scripts that manipulate
                Message 7 of 15 , Jun 5, 2008
                • 0 Attachment
                  Nico Weber wrote:

                  > > Yes, but most people appear to be OK with the &123.456 syntax. Thus
                  > > if you want something else, you need to come up with good arguments.
                  >
                  > I still haven't seen any good arguments why an editor needs floating
                  > point numbers at all, other than "hey, it can be done without breaking
                  > old scripts with just slightly awkward syntax" :-)

                  We don't really need ":sort" either. It's just that it's very
                  convenient to have sorting and floating point numbers for writing
                  scripts that manipulate text.

                  For myself, I often add up columns with amounts. Works easy for
                  integers, currently doesn't work for floating point (it's doable, but
                  a lot of work to implement and you get overflow/underflow problems).

                  --
                  I learned the customs and mannerisms of engineers by observing them, much the
                  way Jane Goodall learned about the great apes, but without the hassle of
                  grooming.
                  (Scott Adams - The Dilbert principle)

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ download, build and distribute -- http://www.A-A-P.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • John Beckett
                  ... I can t reproduce this error. Any chance that you re using a version of patch that fails if the patch includes CR characters, and you have CR?? There
                  Message 8 of 15 , Jun 5, 2008
                  • 0 Attachment
                    Bill McCarthy wrote:
                    > My eval.c is the current release patched by both your latest
                    > and John Beckett's fix. You new patch fails with:
                    >
                    > vim\vimfp> patch -b -p 0 -i Brams-may_not_work_with_jb.diff
                    > patching file src/eval.c Hunk #1 FAILED at 4799.
                    > 1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

                    I can't reproduce this error. Any chance that you're using a version of 'patch' that
                    fails if the patch includes CR characters, and you have CR??

                    There does appear to be one minor glitch in patch 307, namely that it includes
                    "FEAT_FLOAT". However, it doesn't do any harm. Here is a blow-by-blow summary of
                    some tests I just did.

                    I took a clean (no patches) copy of Vim 7.1 source, then applied patches 1 to 311
                    (no float patches).

                    Everything applied cleanly, although there was one trivial warning:
                    patching file src/config.h.in
                    Hunk #1 succeeded at 155 (offset -1 lines).

                    I then applied Bram's float patch issued 2008-04-13. There were lots of "Hunk...
                    succeeded at..." warnings, and one error:
                    patching file src/if_python.c
                    Hunk #1 FAILED at 1130.

                    Manual inspection showed that if_python.c already had the patch that the float patch
                    was trying to apply, so the FAILED message can be ignored. This is due to patch 307
                    (applying to src/if_python.c) already including some float code.

                    I then applied my float patch issued 2008-04-16. There were four "Hunk... succeeded
                    at..." warnings.

                    I then applied Bram's float patch issued 2008-06-05. There was one "Hunk...
                    succeeded at..." warnings.

                    I also tried (on another copy of the source), reversing the last two steps. Exactly
                    the same results (and identical source produced).

                    I haven't had a chance to compile yet. A very quick look at the source suggests that
                    there should be no conflict between my patch and any of Bram's, so I don't know why
                    you got the failure.

                    John


                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Bill McCarthy
                    ... Thanks, John. You were close. I had the proper fileformat settings. However I foolishly copy and pasted the patch instead of using my mail macro to
                    Message 9 of 15 , Jun 5, 2008
                    • 0 Attachment
                      On Thu 5-Jun-08 7:35am -0600, John Beckett wrote:
                      > Bill McCarthy wrote:

                      >> My eval.c is the current release patched by both your latest
                      >> and John Beckett's fix. You new patch fails with:
                      >>
                      >> vim\vimfp> patch -b -p 0 -i Brams-may_not_work_with_jb.diff
                      >> patching file src/eval.c Hunk #1 FAILED at 4799.
                      >> 1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej

                      > I can't reproduce this error. Any chance that you're
                      > using a version of 'patch' that
                      > fails if the patch includes CR characters, and you have CR??
                      ...
                      > I then applied Bram's float patch issued 2008-06-05. There was one "Hunk...
                      > succeeded at..." warnings.

                      Thanks, John. You were close. I had the proper
                      'fileformat' settings. However I foolishly copy and pasted
                      the patch instead of using my mail macro to dump the mail
                      into Gvim (using Unix mailbox format). When I did a vimdiff
                      of the two patches I could clearly see that the tabs were
                      spaces in last night's patch which had failed. With the
                      proper patch:

                      vim\vimfp> patch -b -p 0 -i Bram-dec_point_experiment.diff
                      patching file src/eval.c
                      Hunk #1 succeeded at 5001 (offset 202 lines).

                      I made both Vim and Gvim - thanks for verifying that it
                      worked!

                      Bram, this patch is very nice. Hopefully is will not break
                      others' code.

                      --
                      Best regards,
                      Bill


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Tony Mechelynck
                      On 04/06/08 21:40, Ilya Bobir wrote: [...] ... What about 2.e32 ? Best regards, Tony. -- Cabbage, n.: A familiar kitchen-garden vegetable about as large and
                      Message 10 of 15 , Jun 6, 2008
                      • 0 Attachment
                        On 04/06/08 21:40, Ilya Bobir wrote:
                        [...]
                        > If there are no scripts that use two numbers with a dot in between
                        > without interleaving spaces then it follows that there are none that
                        > have these kind of numbers with an exponent appended. And it means that
                        > if the float syntax will be smart enough to tell a float without an
                        > exponent from a concatenation then adding an exponent as a suffix will
                        > not introduce any ambiguity. Am I missing something?
                        >
                        > Ilya Bobir

                        What about 2.e32 ?

                        Best regards,
                        Tony.
                        --
                        Cabbage, n.:
                        A familiar kitchen-garden vegetable about as large and wise as
                        a man's head.
                        -- Ambrose Bierce, "The Devil's Dictionary"

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Tony Mechelynck
                        ... Works for me: linux:~/.build/vim-test/vim71 # patch --dry-run -p0
                        Message 11 of 15 , Jun 6, 2008
                        • 0 Attachment
                          On 05/06/08 05:05, Bill McCarthy wrote:
                          > On Wed 4-Jun-08 3:42pm -0600, Bram Moolenaar wrote:
                          >
                          >> Anyway, here is a patch to accept plain floating point numbers. Goes on
                          >> top of the previous floating point patch. Give it a try and find out if
                          >> any of your scripts break.
                          >
                          > My eval.c is the current release patched by both your latest
                          > and John Beckett's fix. You new patch fails with:
                          >
                          > vim\vimfp> patch -b -p 0 -i Brams-may_not_work_with_jb.diff
                          > patching file src/eval.c
                          > Hunk #1 FAILED at 4799.
                          > 1 out of 1 hunk FAILED -- saving rejects to file src/eval.c.rej
                          >
                          > I'm not great at reading patch files, but my eval.c does
                          > contain:
                          >
                          > ===============================================
                          > case '7':
                          > case '8':
                          > case '9':
                          > vim_str2nr(*arg, NULL,&len, TRUE, TRUE,&n, NULL);
                          > *arg += len;
                          > if (evaluate)
                          > {
                          > rettv->v_type = VAR_NUMBER;
                          > rettv->vval.v_number = n;
                          > }
                          > break;
                          >
                          > /*
                          > * String constant: "string".
                          > ===============================================
                          >
                          > So it looks like - to me - that you patch should patch.
                          >

                          Works for me:

                          linux:~/.build/vim-test/vim71 # patch --dry-run -p0<patches/Floating\
                          point\ noampersand.eml
                          (Stripping trailing CRs from patch.)
                          patching file src/eval.c
                          Hunk #1 succeeded at 4998 (offset 199 lines).
                          linux:~/.build/vim-test/vim71 #


                          Best regards,
                          Tony.
                          --
                          Getting an education at the University of California is like having
                          $50.00 shoved up your ass, a nickel at a time.

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Bram Moolenaar
                          ... I think it s OK to not allow that and insist on using 2.0e32 . Just like you can t do .5 but need to use 0.5 instead. Rationale: let e32 = times a
                          Message 12 of 15 , Jun 6, 2008
                          • 0 Attachment
                            Tony Mechelynck wrote:

                            > On 04/06/08 21:40, Ilya Bobir wrote:
                            > [...]
                            > > If there are no scripts that use two numbers with a dot in between
                            > > without interleaving spaces then it follows that there are none that
                            > > have these kind of numbers with an exponent appended. And it means that
                            > > if the float syntax will be smart enough to tell a float without an
                            > > exponent from a concatenation then adding an exponent as a suffix will
                            > > not introduce any ambiguity. Am I missing something?
                            > >
                            > > Ilya Bobir
                            >
                            > What about 2.e32 ?

                            I think it's OK to not allow that and insist on using "2.0e32".
                            Just like you can't do ".5" but need to use "0.5" instead.

                            Rationale:
                            let e32 = " times a day"
                            echo 2.e32
                            2 times a day
                            echo 3.e32
                            3 times a day

                            This actually makes sense, so we should keep this backwards compatible.
                            The reasoning that "2.0" is currently not used is that it's not useful to
                            have this in a Vim script, you would write "20" instead.

                            I'm not saying I have accepted the backwards compatibility problem with
                            doing floating point this way, we still need to find that one script
                            that breaks.

                            --
                            A)bort, R)etry, D)o it right this time

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                            \\\ download, build and distribute -- http://www.A-A-P.org ///
                            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Ben Schmidt
                            ... [...] ... Absolutely. Another corner case that I believe wasn t searched for with the regex is simply 2e32 which is presently valid and almost equivalent
                            Message 13 of 15 , Jun 6, 2008
                            • 0 Attachment
                              Bram Moolenaar wrote:
                              > Tony Mechelynck wrote:
                              >
                              >> On 04/06/08 21:40, Ilya Bobir wrote:
                              >> [...]
                              >>> If there are no scripts that use two numbers with a dot in between
                              >>> without interleaving spaces then it follows that there are none that
                              >>> have these kind of numbers with an exponent appended. And it means that
                              >>> if the float syntax will be smart enough to tell a float without an
                              >>> exponent from a concatenation then adding an exponent as a suffix will
                              >>> not introduce any ambiguity. Am I missing something?
                              >>>
                              >>> Ilya Bobir
                              >> What about 2.e32 ?
                              >
                              > I think it's OK to not allow that and insist on using "2.0e32".
                              > Just like you can't do ".5" but need to use "0.5" instead.
                              [...]
                              > This actually makes sense, so we should keep this backwards compatible.
                              > The reasoning that "2.0" is currently not used is that it's not useful to
                              > have this in a Vim script, you would write "20" instead.

                              Absolutely.

                              Another corner case that I believe wasn't searched for with the regex is
                              simply 2e32 which is presently valid and almost equivalent to the above
                              (I think it is two expressions side by side which :echo then
                              concatenates with a space between).

                              > I'm not saying I have accepted the backwards compatibility problem with
                              > doing floating point this way, we still need to find that one script
                              > that breaks.

                              Is it worth changing it for just one script? I would say no. If a
                              handful of scripts, perhaps, because that may indicate that there are
                              many more in the wild that aren't publicly accessible, but just one I'm
                              not sure is enough evidence to go on.

                              Ben.




                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_dev" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • ThoML
                              ... If it s supposed to be a float I think it should IMHO be 2.0e32. This format currently isn t supported for integers it seems. BTW I m glad to see that
                              Message 14 of 15 , Jun 6, 2008
                              • 0 Attachment
                                > Another corner case that I believe wasn't searched for with the regex is
                                > simply 2e32 which is presently valid and almost equivalent to the above

                                If it's supposed to be a float I think it should IMHO be 2.0e32. This
                                format currently isn't supported for integers it seems.

                                BTW I'm glad to see that float will look like a naive user would
                                expect it. Thanks.

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