Memory limit

Scripting Forums AppleScript | Mac OS X
#1

Im making a program that deals with VERY large numbers. Unfortunately Applescript keeps giving me this error: The result of a numeric operation was too large. Is there a way to allow AppleScript to deal with large numbers like this, maybe by dividing by a big number then converting to string and shifting decimal point? I need an exact code. Here’s mine now (it’s supposed to find prime #'s):

tell application "Finder"
	say "Prime numbers:"
	display dialog "Press \"Begin\" to start the prime count." with title "Prime Numbers" buttons {"Cancel", "Begin"} default button 2
	set p to 2
	display dialog "2" with title "Prime Numbers" buttons {"Cancel", "Next"} default button 2
	repeat
		set oldP to p
			set p to ((2 ^ p) - 1)
		display dialog ((p as string) & "
	(2^" & (oldP as string) & " - 1)") buttons {"Cancel", "Next"} default button 2 with title "Prime Numbers"
	end repeat
end tell

Also, is there a way to remove the usage of e in a number? If not, its fine, I just want the big numeric operation err to go away :slight_smile:

Thanks in advance!

#2

You might want to read this discussion of what AppleScript can do with numbers.

#3

Ok, just read it, but still… Is there any possible way of removing this limit? Even if it’s just something in my code, not other peoples? Thanks

#4

No in general you can’t change the limitations from applescript code and that’s good thing. You can’t change number notations by default, it would mess up the CPU of your machine and eventually you’ll get a kernel panic. When an application compares a 16 bit integer with a 32 bit integer it would always be false. But when the number of the 32 bit integer is higher that the highest possible number of the 16 bit integer your application would crash. Well even if Applescript has it’s own virtual memory (stack) you will get eventually the same problems.

Applescript uses default integers. This means a integer in applescript is 64 bit. For higher values you need a double precision floating point. So your class would be a ‘real’ which is equivalent to a signed 1024 integer.

#5

You’ll have to use bignums. Here’s a big factorial function (based somewhat on code found on Wikipedia):

on bigFactorial(factor)
	set bignum to {1}
	repeat with n from 1 to factor
		set carry to 0
		repeat with i in bignum
			set d to i * n + carry
			set contents of i to d mod 1.0E+8 as integer -- 8 digits per unit (keep within the integer limits)
			set carry to d div 1.0E+8
		end repeat
		if carry > 0 then set end of bignum to carry as integer
	end repeat
	set text item delimiters to " "
	return (end of bignum as text) & (do shell script "printf %08d " & reverse of items 1 thru -2 of bignum)
end bigFactorial

[edit] You could also try doing it with method calls via Automator Runner.

#6

Could you repost my code above using either bigruns or automater runner? Thx

#7

Not really. Running in 64-bit it stores them as 64-bit, but half the bits are unused. AppleScript’s integers only go to (2^29) - 1; a couple of bits are used to signify that there’s no indirection involved.

#8

Really? But this code works:

2 ^ 31 - 1 as integer
 --> 2.147483647E+9

Though at 2^29 it starts adding E.

#9

You forgot the next line:

class of result --> real

When you exceed the limit, it automatically provides reals (though once upon a time it didn’t).

#10

Yeah, just noticed that. Weird though, because the real is only correct up to 2 ^ 31 - 1. After that it will be incorrect but the cast won’t error until over 2^63 + 1024.

#11

I’m not sure what you mean. AppleScript doesn’t do casts. This:

2 ^ 32 as integer

gives a result of 0 here.

#12

Sorry, coercion. I mean incorrect as in not the same value. 2.147483647E+9 is the same as 2^31 - 1, but 0 is not the same as 2^32.

#13

I gather the 32-bit limits were kept in the move to 64-bit, for consistency. Pity they weren’t just fixed.

But the take-home message is not to try to use integers for big numbers. And floats work well for integers up to a very high number anyway.