1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Bitten by the integer bug

Discussion in 'Support' started by samintz, Feb 18, 2010.

  1. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,177
    Likes Received:
    11
    I could not find in the documentation anywhere what the definition of an integer is. The help text for @EVAL states that \ and MOD require integer parameters. However, I get wildly different results from using \ vs. /. I expected 10,000 digits. My definition of an integer is a whole number with no fractional part.

    For example:
    Code:
    set rmndr=%@eval[((%b10 / %2) - %@INT[%b10 / %2]) * %2]
     set b10=%@int[%b10 / %2]
    
    gives completely different results from:
    
    set rmndr=%@eval[%b10 MOD %2]
     set b10=%@eval[%b10 \ %2]
    
    -Scott
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,729
    Likes Received:
    80
    I can't make any sense out of your code fragment, but I'm pretty sure
    there's nothing wrong with the modulo operator.

    An integer in TCC is a 64-bit whole number.

    Rex Conn
    JP Software
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    On Fri, 19 Feb 2010 08:11:11 -0500, rconn <> wrote:

    |I can't make any sense out of your code fragment, but I'm pretty sure
    |there's nothing wrong with the modulo operator.

    There's some sort of problem with "\". This is v11.

    v:\> echo %@eval[18756748309283746665 / 2]
    9378374154641873332.5 [this is correct]

    v:\> echo %@eval[18756748309283746665 \ 2]
    4611686018427387903 [no clue what this is]
    --
    - Vince
     
  4. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    605
    Likes Received:
    0
    On Fri, Feb 19, 2010 at 6:38 AM, vefatica <> wrote:



    I believe the maximum 64 bit number (unsigned) is 18446744073709551615,
    smaller than your test number.

    4611686018427387903 is 0x3FFFFFFFFFFFFFFF

    --
    Jim Cook
    2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Monday.
     
  5. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,177
    Likes Received:
    11
    You are correct that MOD works correctly when you feed it 64 bit values.

    I was working on a puzzle ysterday:
    Given the following set of 6 integers: 13000, 33333, 31416, 27813,
    98765 and 43210. If the six integers are all multiplied together and the
    resulting product is converted to base 12(twelve), in how many zeros will
    the resulting value end in?

    Using @eval I got :
    echo %@eval[13000 * 33333 * 31416 * 27813 * 98765 * 43210]
    1615860307974787525450800000

    @convert only works with 64bit values so I had to convert it myself. So I
    figured MOD and \ would do the trick.

    echo %@eval[1615860307974787525450800000 mod 12]
    7

    But this yields a completely different result. I compute the remainder
    (mod operator) by doing: (a/b - integer_part(a/b)) * b
    echo %@eval[((1615860307974787525450800000 / 12) -
    %@INT[1615860307974787525450800000 / 12]) * 12]
    0

    Same with / vs. \:

    echo %@eval[1615860307974787525450800000 / 12]
    134655025664565627120900000

    echo %@eval[1615860307974787525450800000 \ 12]
    768614336404564650

    -Scott


    rconn <> wrote on 02/19/2010 08:11:08 AM:


    using

     
  6. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    On Fri, 19 Feb 2010 09:56:41 -0500, Jim Cook <> wrote:

    |I believe the maximum 64 bit number (unsigned) is 18446744073709551615,
    |smaller than your test number.
    |
    |4611686018427387903 is 0x3FFFFFFFFFFFFFFF

    I thought @EVAL was beyond those limitations.
    --
    - Vince
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | I believe the maximum 64 bit number (unsigned) is
    | 18446744073709551615, smaller than your test number.
    |
    | 4611686018427387903 is 0x3FFFFFFFFFFFFFFF

    with further experimentation it appears that when the any operator requiring
    an integer parameter is used, its left parameter is first truncated to be
    within the legal range of 2's complement 64-bit integers:
    [-2**63,2**63-1]
    (using the conventional mathematical notation of a closed set), then the
    operation is performed.

    This behavior goes back to V9.

    IMHO the observation above (i.e., parameter value truncation) ought to be in
    the help topic f_eval.htm in the section describing operators requiring
    integer parameters.
    --
    HTH, Steve
     
  8. Jim Cook

    Joined:
    May 20, 2008
    Messages:
    605
    Likes Received:
    0
    If you are actually trying to get the answer, I believe it's an easier
    solution to factor each number, and gather the prime factors into 12s. A
    number that ends in x zeros, base b, is a multiple of b^x.

    The factors of your numbers, including ~pi, ~e, and arithmetic sequences:
    13000 = 2 2 2 5 5 5 13
    33333 = 3 41 271
    31416 = 2 2 2 3 7 11 17
    27813 = 3 73 127
    98765 = 5 19753
    43210 = 2 5 29 149

    And, of course 12 = 2 2 3
    The product of your numbers contains 2^7 and 3^3. There are three 12s
    possible so the product of all the numbers is something times 12^3. There
    are three zeroes in the duodecimal representation.


    On Fri, Feb 19, 2010 at 7:40 AM, samintz <> wrote:




    --
    Jim Cook
    2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
    Next year they're Monday.
     
  9. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,177
    Likes Received:
    11
    Yes. That is one way to do it. And is in fact, the solution given. You
    can also use the Windows calculator and just keep dividing by 12 until you
    get a non-integer result. Surprisingly, it has support for all those
    digits.

    However, once @convert refused to work, I *had* to figure it out. So I
    ended up solving a more complex problem.

    -Scott

    Jim Cook <> wrote on 02/19/2010 11:25:43 AM:


    sequences:

    There

    values.

    27813,

    the

    will

    So I

    remainder

    of

    require

    is a

    sure

     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    I was hoping my comment would get some attention. According to the help, "@EVAL supports very large numbers". "\" is (simply?) one of @EVAL's operators, and my example uses only @EVAL. Is "\" really limited to 64-bit integers when the rest (?) of @EVAL is not?

    Code:
    v:\> echo %@eval[18756748309283746660 \ 2]
    4611686018427387903
    
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,729
    Likes Received:
    80
    All operations defined as "integer" with @EVAL are strictly 64-bit. There
    is no (and will be no) support for larger numbers.

    Rex Conn
    JP Software
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,784
    Likes Received:
    29
    On Sun, 28 Feb 2010 22:53:24 -0500, rconn <> wrote:

    |All operations defined as "integer" with @EVAL are strictly 64-bit. There
    |is no (and will be no) support for larger numbers.

    The help says:

    "@EVAL supports very large numbers. The maximum size is 20,000 digits (10,000
    digits to the left of the decimal point and 10,000 decimal places)."

    ... some very large numbers?
    --
    - Vince
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,729
    Likes Received:
    80
    Yes, if you're not using an integer operation. And integer-only operations
    still support 64-bit integers, which is more than you've ever needed!

    Rex Conn
    JP Software
     
  14. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,177
    Likes Received:
    11
    That was true until I needed more. It seems to me that most of the
    integer ops could easily be implemented using your large number library
    vs. the 64-bit library you're currently using.

    A \ B == INT[A / B]
    A MOD B == A - (INT[A/B] * B)
    A << 1 == A * 2
    A >> 1 == INT[A / 2]

    etc.

    -Scott

    rconn <> wrote on 03/01/2010 09:12:08 AM:


    operations

     
  15. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    | ---Quote---
    || The help says:
    ||
    || "@EVAL supports very large numbers. The maximum size is 20,000
    || digits (10,000
    || digits to the left of the decimal point and 10,000 decimal places)."
    ||
    || ... some very large numbers?
    | ---End Quote---
    | Yes, if you're not using an integer operation. And integer-only
    | operations still support 64-bit integers, which is more than you've
    | ever needed!

    Rex, I agree with your opinion about the adequacy of 64-bit integers.
    However, IMHO Vince intended to suggest that HELP topic f_eval.htm should
    make clear the limitations of integer operations, and without disagreeing
    about their adequacy.
    --
    Steve
     

Share This Page