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

New calc func sometimes puts commas in 4 digit numbers (and also breaks clips)

Expand Messages
  • joy8388608
    In case my mention of this got lost in the clutter of a previous message, I have a clip where calc uses NO parameters when adding values but the output values
    Message 1 of 8 , Aug 20, 2012
    • 0 Attachment
      In case my mention of this got lost in the clutter of a previous message, I have a clip where calc uses NO parameters when adding values but the output values under 10,000.00 sometimes have a comma and sometimes do not even though they are all calculated the same way.

      Example line:
      Total = 1234.56 4,567.89

      I also found a clip I use that is broken because calc AUTOMATICALLY inserts commas. Please! This is an unnecessary change which will cause some clips to malfunction. Calc should only put in a grouping comma when ASKED (when the second value in the new third parameter is specified.

      Joy


      [ 123.mp3 ] 09364 KB 00:26:37
      [ 456.mp3 ] 01516 KB 00:04:18
      [ 789.MP3 ] 2,038 KB 01:02:40 <--- wrong in 7.01
      [ 789.MP3 ] 22038 KB 01:02:40 <--- should be

      Joy
    • anachromat
      [joy8388608] ... I agree. Got bit by this today in this old clip: H=add1 ^!Find d+ ROS ^!IfError end ^!InsertText ^$Calc(^$GetSelection$ + 1)$ It simply
      Message 2 of 8 , Aug 20, 2012
      • 0 Attachment
        [joy8388608]
        > In case my mention of this got lost in the clutter
        > of a previous message, I have a clip where calc
        > uses NO parameters when adding values but the output
        > values under 10,000.00 sometimes have a comma
        > and sometimes do not even though they are all
        > calculated the same way.
        >
        > Example line:
        > Total = 1234.56 4,567.89
        >
        > I also found a clip I use that is broken because
        > calc AUTOMATICALLY inserts commas. Please! This is
        > an unnecessary change which will cause some clips
        > to malfunction. Calc should only put in a grouping
        > comma when ASKED (when the second value in the new
        > third parameter is specified.
        > ...

        I agree. Got bit by this today in this old clip:

        H=add1
        ^!Find "\d+" ROS
        ^!IfError end
        ^!InsertText ^$Calc(^$GetSelection$ + 1)$

        It simply looks for the first integer after the current cursor position, and replaces it with the integer one larger. A simple convenience. Now I sometimes have to edit the result by hand to get rid of the unwanted comma. Or add more code to automate that ;-)
      • flo.gehrke
        ... I tested... ^$Calc(^$GetSelection$+1;0;.)$ against a list of 10,000 5-digits-integers and didn t see a single comma in the results (counting ^ d{5} ). I
        Message 3 of 8 , Aug 21, 2012
        • 0 Attachment
          --- In ntb-clips@yahoogroups.com, "anachromat" <tim.peters@...> wrote:
          >
          > Got bit by this today in this old clip:
          >
          > H=add1
          > ^!Find "\d+" ROS
          > ^!IfError end
          > ^!InsertText ^$Calc(^$GetSelection$ + 1)$
          >
          > It simply looks for the first integer after the current cursor
          > position, and replaces it with the integer one larger. A simple
          > convenience. Now I sometimes have to edit the result by hand
          > to get rid of the unwanted comma. Or add more code to automate
          > that ;-)

          I tested...

          ^$Calc(^$GetSelection$+1;0;.)$

          against a list of 10,000 5-digits-integers and didn't see a single comma in the results (counting '^\d{5}').

          I think this accords with the Help: "If only the decimal symbol is specified, then no digit grouping symbol will be used in the result."

          With your parameters '^$Calc(^$GetSelection$+1)$', all integers are grouped like '12,345' in my test.

          Regards,
          Flo
        • Axel Berger
          ... This will undoubtedly break a lot of old tried and tested clips. In most cases users will no longer remember where and how Calc may be used inside them and
          Message 4 of 8 , Aug 21, 2012
          • 0 Attachment
            "flo.gehrke" wrote:
            > With your parameters '^$Calc(^$GetSelection$+1)$', all integers
            > are grouped like '12,345' in my test.

            This will undoubtedly break a lot of old tried and tested clips. In most
            cases users will no longer remember where and how Calc may be used
            inside them and those breakages will occur erratically and come
            unexpected. Not nice.

            This reminds me of the read-only opening of files after the introduction
            of UTF. In all too many cases I did not notice that my old and reliable
            clip had done nothing and much later was surprised by broken and
            unusable files.

            In cases like these it is actually better not to fake a nonexistent
            backwards compatibility and make the old format illegal. Then you'll get
            obvious errors, not hidden malfunctions.

            Axel
          • Don
            Interesting, I ve been struggling with this very issue. I had no idea it may be tied to UTF introduction. I in fact wrote Eric to ask for at the minimum a
            Message 5 of 8 , Aug 21, 2012
            • 0 Attachment
              Interesting, I've been struggling with this very issue. I had no idea
              it may be tied to UTF introduction. I in fact wrote Eric to ask for at
              the minimum a warning that I was operating on a write protected file.
              You get such a warning with a manual find, but not when executing a
              clip. I have been thinking I must have done something wrong to trigger
              this behavior of read only files when I download a file.

              On 8/21/2012 9:05 AM, Axel Berger wrote:
              > This reminds me of the read-only opening of files after the introduction
              > of UTF. In all too many cases I did not notice that my old and reliable
              > clip had done nothing and much later was surprised by broken and
              > unusable files.
            • flo.gehrke
              ... That s what I was afraid of during NT 7.01 betatest. If I don t misunderstand Eric, he was convinced that the great majority of users wasn t affected by
              Message 6 of 8 , Aug 21, 2012
              • 0 Attachment
                --- In ntb-clips@yahoogroups.com, Axel Berger <Axel-Berger@...> wrote:
                >
                > "flo.gehrke" wrote:
                > > With your parameters '^$Calc(^$GetSelection$+1)$', all integers
                > > are grouped like '12,345' in my test.
                >
                > This will undoubtedly break a lot of old tried and tested clips...

                That's what I was afraid of during NT 7.01 betatest. If I don't misunderstand Eric, he was convinced that the great majority of users wasn't affected by the new syntax since they work with US regional settings anyway.

                For me, the consequence was to scan all my clip libraries, searching $Calc$, and checking if any corrections were necessary.

                As I wrote in an earlier message, we'll also see some trouble in the international exchange of clips. Maybe we should consider some new rules when posting clips to the Clip Group. The alternatives could be...

                1. Make clear which regional settings have been used.

                2. Use ^%THOUSAND_SYMB% and ^%DECIMAL_SYMB% in ^$Calc$.

                3. We agree on using US-formats only in this Group.

                In my view, #3 is the easiest solution.

                Regards,
                Flo
              • joy8388608
                ... I want to make sure this point remains clear... It is not the new syntax or regional settings so much (well, for myself and I m guessing most users) the
                Message 7 of 8 , Aug 21, 2012
                • 0 Attachment
                  --- In ntb-clips@yahoogroups.com, "flo.gehrke" <flo.gehrke@...> wrote:
                  >
                  > --- In ntb-clips@yahoogroups.com, Axel Berger <Axel-Berger@> wrote:
                  > >
                  > > "flo.gehrke" wrote:
                  > > > With your parameters '^$Calc(^$GetSelection$+1)$', all integers
                  > > > are grouped like '12,345' in my test.
                  > >
                  > > This will undoubtedly break a lot of old tried and tested clips...
                  >
                  > That's what I was afraid of during NT 7.01 betatest. If I don't misunderstand Eric, he was convinced that the great majority of users wasn't affected by the new syntax since they work with US regional settings anyway.


                  I want to make sure this point remains clear... It is not the new syntax or regional settings so much (well, for myself and I'm guessing most users) the comma that is suddenly appearing in the output from calc. It is a major no-no to change the way a function outputs its' results.

                  And I STILL have not seen a single comment on my mysterious commas appearing in a seemingly random way in 4 digit numbers such as 1234.56. I doubt very much anyone will be able to recreate it, but I can (all the time) using my clip and my data (which is private therefore difficult to share easily). Calc should at the very least be consistently wrong! :)

                  Joy
                • Eric Fookes
                  Hi Axel and Joy, I m sorry the improvements to ^$Calc are creating problems with your old Clips. I m convinced that the new behavior is beneficial to many
                  Message 8 of 8 , Sep 10, 2012
                  • 0 Attachment
                    Hi Axel and Joy,

                    I'm sorry the improvements to ^$Calc are creating problems with your old
                    Clips. I'm convinced that the new behavior is beneficial to many
                    (non-vocal) users, especially those with non-US number symbols.

                    One simple solution to regain the old behavior is to add the
                    ";^%DECIMAL_SYMB%" parameter at the end of ^$Calc in your Clips. Example:

                    ^$Calc(^%Expression%;^%Decimals%;^%DECIMAL_SYMB%)$

                    Or use "." if you want to enforce the US decimal symbol:

                    ^$Calc(^%Expression%;^%Decimals%;".")$

                    --
                    Regards,

                    Eric Fookes
                    http://www.fookes.com/


                    On 21/08/2012 15:05, Axel Berger wrote:
                    > "flo.gehrke" wrote:
                    >> With your parameters '^$Calc(^$GetSelection$+1)$', all integers
                    >> are grouped like '12,345' in my test.
                    >
                    > This will undoubtedly break a lot of old tried and tested clips. In most
                    > cases users will no longer remember where and how Calc may be used
                    > inside them and those breakages will occur erratically and come
                    > unexpected. Not nice.
                    >
                    > This reminds me of the read-only opening of files after the introduction
                    > of UTF. In all too many cases I did not notice that my old and reliable
                    > clip had done nothing and much later was surprised by broken and
                    > unusable files.
                    >
                    > In cases like these it is actually better not to fake a nonexistent
                    > backwards compatibility and make the old format illegal. Then you'll get
                    > obvious errors, not hidden malfunctions.
                    >
                    > Axel
                  Your message has been successfully submitted and would be delivered to recipients shortly.