LOL, to explain you are pointing me to a file that I didn't understand in the first place...

I don't think this can be proven via a script. Since the range we are talking about is so huge (10^800). For example, to be mean, let's say FMP is actually indexing the value X you input as Mod(X,10^23) instead to save space. You could test all day (or for years) and never notice that.

But its not just 10^23, such a wrap around code be occurring anywhere, and the range is simply too large to exhaustively test within our lifetimes.

My guess, after some testing is:

  X -> Truncate( GetAsNumber(X); 0 )

for indexing purposes (but I can't *prove* that).

Isn't it the right one with the

Set Variable[$Assign

....in the script I directed you to??

It's not any of the later attempts! It's something I've picked up in one of the latest Petrowski movies, instead of cluttering a scripts readability with endless Set Variable[ lines ...then do it in one swell swoop of a dummy variable setting trigging a Let( assignment stuffing a lot of reps. in a variable.

--sd

I don't know of a good way to test this. "This", I assume, is the limit of how many repetitions you can have. Note that "how many repetitions you can have" is NOT the same thing as "what is the highest repetition number you can have".

The only test that I can think of is to start setting repetitions from 1 to a proposed limit n. On each iteration, you set a new repetition to the number of the current iteration. Then you would start at 1 again, retrieving the values and checking that they match the expectation, i.e. that $variable[$i] = $i. If all the values have been retrieved successfully, you will have proven that you can have at least n repetitions.

Then you can raise n to a higher number, and repeat the test (from 1 again, otherwise you'd be assuming that repetitions are not being re-used).

Such test is a good way to to prove the positive. Proving the negative is more difficult, because you might be proving the limits of your RAM, or some other external limiting factor*.

Alternatively, you might get lucky by stumbling upon the limit (if there is a limit) by random testing. But then I would concentrate on some meaningful numbers. For example, I ran a test setting repetitions around the 32k mark (the limit of repeating FIELDS), then checking that this did not erase reps 0, 1 and 2. But this would prove something only if the test had failed.

---

(*) As Shawn points out, the limiting factor could be your life expectancy....

Edited June 9, 200718 yr by Guest

"This", I assume, is the limit of how many repetitions you can have

... Why would I care about how many repetitions you could have, and why would I attempt to prove that by setting a key at a really high number? I wouldn't really ever expect to want to store more than 100,000 in a variable at any given time in any case.

The only reason I wanted to know was to see how long the string could be for the Encode() CF Shawn proposed earlier.

OK, then I obviously misunderstood. But you still have a problem, because the encoded string can be very short or very long (and anything in between). You need to prove that a very long string will NEVER overwrite a repetition set with with a short string.

Well -- hence my original question, what would happen if a number was to be very long? The only real assumption you can make is that it would be truncated, there is nothing else that a logical program could do to it.. I know assumptions are bad but I mean seriously, what are you going to do with a really long number if it's too long?

My original file attempted in this way (length is for example only):

number = 999999

test[999999]=a

test[999998]=b

Now, if for example, truncation length was three, then that would be the effect of writing:

test[999]=a

test[999]=b

Which would return b for a call to

test[999999]

Anyone with technet feel like trying to get an engineer in there and ask them lol (I mean, even if it is just for show, they have to get one in there every once in a while)

Well.. okay.

But here's the question about your other suggestion, why would the FM engineers think it would be safe to to store a number like Mod(X,10^23) if the chance of collision was even remotely present (in a 1,000,000 solutions in the world performing 100,000 transactions a day) -- I mean wouldn't they have to state a limit on the number of repetitions there other than the limit imposed by the calc definition window used to make the intitial definition?

Anyway, I think that if anyone knows any engineers... LOL... they should ask them.

You are (again) treating a number as if it were text. A number would be most likely folded back to zero, and the most likely limit would be 2^. But it's equally possible that the Set Variable[] step would simply fail to execute when the limit is exceeded.

A number would be most likely folded back to zero

I'm not sure i Understand that term... are you saying that:

5645641324561894324534186412345641684324641324561654346542346545345641 ... 23564 would become 0 if it were too long? I'll reply to the text bit once i work out what you're saying here

Secondly, the Set Variable[] step doesn't fail at 800 digits.

I am saying 2^15 could become 0, if there were only 15 registers to work with. In binary, 2^15 - 1 is "111111111111111". The next higher integer is "1000000000000000". Discard the 1 that doesn't have a register to hold it, and you end up with "000000000000000".

I am not sure what, if any, significance there is to 800 digits.

Here's a nice real-life example for you:

TextColor ( "abc" ; RGB ( 255 ; 255 ; 255 ) + 1 )

Nothing except that if you put 801 in to a calc engine it tells you that you can't evaluate it.

Anyway, I think I'm going to give up one this now. This more than anything was an exercise of curiosity...

In any case, I think I will use the encode() function suggested by Shawn and try to keep my variable name to reasonable 5-8 characters.. thats only a number 16 digits in length.

... yes, but you are saying that it would turn into zero right?

if you put 801 in to a calc engine it tells you that you can't evaluate it.

Well, then I guess this (attached) is impossible...

.. yes, but you are saying that it would turn into zero right?

Not sure what you're asking here.

Impossible.fp7.zip

Well no.. I said that it wouldn't take an 801 digit number not that it wouldn't take a one digit exponential function.

But.. Your little variable trick makes me think that if the number was to large, lets say

(2^1345) * (2^1346) the variable wouldn't set at all... Right??

I was strictly playing devil's advocate with the 10^23 suggestion, and agreeing with comment to the idea this can't be proven.

While I worked there, this was *not* the case, and the variables were being stored in the C++ STL associative container std::map. Which would hold at least 2 billion at once.

The numbers don't won't wrap back before 10^400 or 10^800, and maybe not even then, I don't recall the specifics there.

Wow, love all of the responses. Thanks for all of the help. Had to take a break from working yesterday but I am going to give these ideas a shot. Thanks again everyone.

I don't know what you mean by "one digit exponential function". Surely,

Length ( 2^1345 * 2^1345 ) = 810

However, this limit of 800 digits is interesting. It seems this applies to FIELDS, not to the calc engine itself. Otherwise I cannot explain this:

VarRepLimit.fp7.zip

the variables were being stored in the C++ STL associative container

I didn't see this before I posted, but it would seem to support what my last file suggests. Unfortunately, one cannot really test the limits of the calc engine, when the only test tool available is the calc engine itself.

I believe the 800 digits might be the full amount that can be indexed. The rule was the various calc-engine functions are free to return NaN (not a number, ie "?") if they happen to notice this limit being exceeded, (but they are not required to notice as long as the answer returned is correct instead).

That just might explain the paradox of $j ≠ $j * 1.

But I am curious: why do some function place seemingly arbitrary limits on their parameters, e.g. 2^15 for the Date() function?

I think the idea is that:

  Date( 1; 2^16; 2007 )

is much more likely to be developer error than a real request. Date's are also limited to years <= 4000 for a similar reason.

Admittedly, there is also some "laziness" coming into play here, why spend an extra day writing code to ensure the day and month arguments can go up to 10^400 when 99.999% of all the users would never use this feature anyway, but it would still have to be tested.

Edited June 9, 200718 yr by Guest
one more thing...

Thanks. I thought you were going to say it's a limitation of the perpetual calendar algorithm, or something like that. The actual limit is 32,767 (2^15 - 1), and that's not that many days - less than 90 years or, if you like, about 2.25% of the Filemaker date span.

Hmmmm,

All very interesting. Thanks for the great discussion (and yell at alex time guys.

Surely you meant to say "yell at Alex any time"?

: lol, that's all i have to say at this point.

I thought I might dig this up for no apparent reason.. but looking at the FM 8 tech specs:

Number: Support values from 10^-400 up to 10^400 and the negative values of the same range. Index based on the first 400 significant digits. Up to 1 billion characters per field. The first 400 digits are indexed.

It would sort of make sense to allow array addressing up to that point as well... but then again maybe not... but a potential way to check and take into account the possibility of truncation is perhaps to address one at 10^400 and one at 10^400-1 then try to retrieve those values.

But i forget what other issues we came accross in our discussions so I'm just going to leave it there.