Re: TI-M: Re: TI-Math Digest V1 #22

[Prev][Next][Index][Thread]

Re: TI-M: Re: TI-Math Digest V1 #22


> Well, doesn't the 89/92+ have a seperate integer type that only holds
> integers (duh)?  Maybe I dreamed I read that somewhere or something ;)

Not according to any of the reverse engineering I've seen; I'll wait and see
what the SDK says.  IIRC, the 83+ SDK indicates that the 83+ uses a single
BCD type for both ints and floats.  TI-GCC, OTOH, has different int and
float types, which may be what's confusing you.

But if TI's CAS supports both integer and floats of an arbitrary length
(limited only by memory), what good would a separate int type be?  Besides,
all the decimal number (float) is, as far as the CAS goes, is an int divide
by another int, with that denominator being a power of 10.  It's quite
simple for both to be represented by BCD numbers, with the only difference
being the exponent. . .

> I'm still a binary proponent, whether it be integers or floats, especially
> for integers.  Even when you have to convert to the decimal system for
> display purposes, speed shouldn't be that much of a concern, and it would
in
> all cases, except for display purposes, be faster than BCD.

I thought that BCD was suposed to be far superior for arbitrarily large
numbers and float multiplication, division, etc.?

> True, not every number with this property is prime, but every prime has
this
> property.

So it's just a bit of a shortcut?  hmmmm

> Actually, I probably could have put in a bit about implementation in my
last
> post ;)  The idea of wheeler factorization is that you can continuously
> trial-divide probable primes without actually checking the
probable-primality
> of those numbers.

Wouldn't it be more efficient to keep a list of primes passed so far and
trial divide by those - testing just the _known_ primes up to that point,
and not all probable ones?

For that matter, it seems that you're better off using some of the ROM to
store a prime number list, rather than test them dynamically, at least until
a certain number is passed (how large would a list of the primes up to 2310
be?  Then let Wheeler kick in if we need larger primes?).  I wonder what my
89 does if I feed it exteremely large prime numbers. . . and I'm feeling
sadistic.

Let's see, head on over to google and search for large mersenne prime
numbers. . . I think that 2^6972593-1 might be a bit too evil to feed to the
calc.  Let's try the 1000th prime number, 7919 - the calc knows it's prime
_instantly_.  Same with 10,479, the 10,000th prime.  1,299,827 takes only a
second, and that's the 100,008th prime number - it takes 822k to list all of
those as ASCII characters, so I have to doubt that TI listed them all; but
wheeler would be way too slow for that.  Your thoughts?

Here's something interesting - it takes about 10 seconds for my calc to
realize that factor(2^2000) is 2^2000 =)

Attempting factor(2^2000-1) is interesting - after about 2 minutes and 50
seconds, it gave me a warning that it may not be fully simplified
(indicating that it's given up =), and 5 seconds later it displayed an
answer.  The largest prime it picked up was 601; it appears to have gotten
stuck on a 582-digit number.

Anyways, I think my inquiry has been taken out way beyond what I expected.
If you need larger primes, don't use a calc to find them; I imagine all the
primes worth listing can fit in a simple table - say, the first 10,000 of
them.

> From experience in coding PrimeASM, the slowest process of this
> implementation was the dividing of the number by each probable-prime, and
I
> think binary integers would be much faster at this than BCD floats (or
even
> BCD integers).

I see, since you have to do the division.  Do you just subtract and check
for zero/carry, or have another algorithm for the binary division?

> While on the implementation idea, there is another approach I've thought
of.
> ... This method might be better to the aforementioned approach.

Sounnds better to me. . .

    -Scott
References: