On Fri, Sep 6, 2013 at 2:05 PM, Geoff Canyon wrote:
> Okay, now it's chunking by 7, and checking/avoiding overflows. This little
> baby will multiply two 7,000 digit random numbers in right around a
> second on my machine. Woot! If anyone sees further optimizations let me
> know.
>
Well, I *was
Not sure whether to post this in this thread or the other, but in any case,
here is a routine that adds arbitrarily large positive numbers in any
LC-valid base -- 2 - 36. For the checksum problem, it would be fairly
simple to convert all the values to 64-bits and use this to add them,
either taking
On Sat, Sep 7, 2013 at 2:07 PM, David Bovill wrote:
> The bits I don't quite get yet are:
>
>1. ignore any overflows (just use the lowest 64 bits)
>2. grab an 8-byte chunk as a 64-bit integer
>3. add it to the checksum
>
> My understanding is that I should be:
>
>1. Using binaryDe
You are inspiring me Geoff! Was about to give up on trying to create the
"64 bit checksum" of a movie file in LiveCode and insted take the ruby code
and call it fro the command line - but using your handler I guess I can do
the 64bit Integer calculations. If you guys could give me a few more
pointe
on Fri, 6 Sep 2013 18:34:54
Geoff Canyon wrote:
> ...and both J and bigFact (my LC function) agree that 130! is:
64668554892204736725073043955364852531553594478280496089759523229447819611855261655127070472292684529256839692403980271491207400740421058447377477994593100296357809917746129838031509651
On Fri, Sep 6, 2013 at 2:12 PM, Mark Wieder wrote:
> At first glance that seems impressive, but do you have unit tests for
> this? If they're big random numbers, how do you know the answer is
> right?
>
I haven't done anything terribly thorough but:
1. I have checked each algorithm against the
...and both J and bigFact (my LC function) agree that 130! is:
64668554892204736725073043955364852531553594478280496089759523229447819611855261655127070472292684529256839692403980271491207400740421058447377477994593100296357809917746129838031509651456
And for a th
Okay, now it's chunking by 7, and checking/avoiding overflows. This little
baby will multiply two 7,000 digit random numbers in right around a second
on my machine. Woot! If anyone sees further optimizations let me know.
For fun I wrote a factorial using bigTimesN7 -- bigFact(1100) comes out at
25
Geoff-
Friday, September 6, 2013, 12:05:22 PM, you wrote:
> Okay, now it's chunking by 7, and checking/avoiding overflows. This little
> baby will multiply two 7,000 digit random numbers in right around a second
> on my machine. Woot! If anyone sees further optimizations let me know.
At first gl
On Sep 5, 2013, at 6:11 PM, Mark Schonewille
wrote:
> Perhaps you should add some comments to your script.
What, it's not obvious? ;-)
My first versions of this were list-based, and scaled poorly because of the
line painter's problem (each day the paint bucket is farther away). More than
ab
Jerry,
Please, read my previous e-mail carefully. I didn't write that you can't
do any calculations beyond 15 digits. I wrote that calculations aren't
reliable beyond 15 digits. I made a general statement. You will find a
similar statement in the LiveCode manual.
--
Best regards,
Mark Schon
OK. I woud like to replace the first word of my reply, from "Nope" to "Yep".
All the rest applies.
.Jerry
On Sep 5, 2013, at 5:11 PM, Mark Schonewille
wrote:
> Jerry,
>
> Please, read my previous e-mail carefully. I didn't write that you can't do
> any calculations beyond 15 digits. I wrote
I think LC uses IEEE binary64 floating point format which can represent
integers to 15+ digits exactly (52+1 bit mantissa). However, last time this
came up somebody made an example that gave inconclusive if not downright
confusing results. Its probably platform specific as well.
.Jerry
On Sep 5
Hi Geoff,
LiveCode will do calculations reliably on numbers that are no larger
than 15 digits, i.e. at most 999.
If you do a calculation like
1*2
--> 2
it is easy to see that the result is incorrect.
See page 34 of my book.
Perhaps
I've written bignum routines for addition and multiplication several times
when solving project euler problems. Generally my multiplication functions
bog down at about 200 digits -- i.e. take more than a second to run.
I decided to optimize, and about a dozen iterations later, the below is the
res
Nope. In the message box try 999+111 which gives you a
correct 16 digit sum of two 15 digit numbers. The limit is not in decimal digit
count. The math is binary.
.Jerry
On Sep 5, 2013, at 4:11 PM, Mark Schonewille
wrote:
> Hi Geoff,
>
> LiveCode will do calculations r
16 matches
Mail list logo
