# Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

# Bitten by the integer bug

#### samintz

##### Scott Mintz
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 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]
> ---------

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:

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

I believe the maximum 64 bit number (unsigned) is 18446744073709551615,

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:

> ---Quote---
> > 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]
> > ---------
> ---End Quote---
> 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 09:56:41 -0500, Jim Cook <> wrote:

|I believe the maximum 64 bit number (unsigned) is 18446744073709551615,
|
|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:

> 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:
>
>
>
> ---Quote---
> > ---Quote---
> > > 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
> ---End Quote---
> using
>
>
> ---Quote---
> > > \ 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]
> > > ---------
> > ---End Quote---
> > 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
> >
> >
> >
> >
> ---End Quote---
>
>
>
>

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

> 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:
>
>
>
> ---Quote---
> > 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:
> >
> >
> >
> > ---Quote---
> > > ---Quote---
> > > > 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
> > ---End Quote---
> > using
> >
> >
> > ---Quote---
> > > > \ 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]
> > > > ---------
> > > ---End Quote---
> > > 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
> > >
> > >
> > >
> > >
> > ---End Quote---
> >
> >
> >
> >
> ---End Quote---
>
>
> --
> 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.
>
>
>
>

On Fri, 19 Feb 2010 09:56:41 -0500, Jim Cook <> wrote:

|I believe the maximum 64 bit number (unsigned) is 18446744073709551615,
|
|4611686018427387903 is 0x3FFFFFFFFFFFFFFF

I thought @EVAL was beyond those limitations.
--
- Vince

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

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

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

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

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:

> ---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 Conn
> JP Software
>
>
>
>

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

However, IMHO Vince intended to suggest that HELP topic f_eval.htm should
make clear the limitations of integer operations, and without disagreeing
--
Steve

Replies
4
Views
2K
Replies
13
Views
370
Replies
4
Views
480
Replies
2
Views
652
Replies
8
Views
1K
Replies
4
Views
683
Replies
1
Views
667
Replies
2
Views
614
Replies
10
Views
905
Replies
7
Views
1K
Replies
6
Views
900
Replies
0
Views
906
Replies
5
Views
1K
Replies
7
Views
1K
Replies
2
Views
2K
Replies
14
Views
2K
Replies
6
Views
2K
Replies
8
Views
2K
Replies
1
Views
1K
Replies
6
Views
2K
Replies
2
Views
2K
Replies
7
Views
2K
Replies
3
Views
2K
Replies
6
Views
3K
Replies
11
Views
3K
Replies
2
Views
2K
Replies
4
Views
2K
Replies
4
Views
2K
Replies
6
Views
2K
Replies
2
Views
2K
Replies
2
Views
2K
Replies
6
Views
2K
Replies
4
Views
3K
Replies
1
Views
2K
Replies
3
Views
2K
Replies
6
Views
3K
Replies
7
Views
2K
Replies
4
Views
2K
Replies
12
Views
3K
Replies
3
Views
2K
Replies
7
Views
2K
Replies
8
Views
3K
Replies
2
Views
3K
Replies
4
Views
3K
Replies
4
Views
2K
Replies
15
Views
4K
Replies
8
Views
3K
Replies
8
Views
3K
Replies
4
Views
3K