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

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

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

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.

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

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

| 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

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.

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

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

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

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

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

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

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