Can't GetNthRecord using a variable

[comment]

Can't see anything odd - all as expected.

[Genx]

So when you run: New Script_again it gives you the same value twice?

[comment]

No. Why would it?

To be more precise, they set repetition GetAsNumber ( string ), I think.

[Genx]

BAH!! That is the most annyoing thing ever.

Oh well, on the upside, it SEEMS, to take a number string this long:

23134654634321564132416543215643215643242341654234563241465341513425343245342313465463432156413241654321564321564324234165423456324146534151342534324534523134654634321564132416543215643215643242341654234563241465341513425343245345231346546343215641324165432156432156432423416542345632414653415134253432453455

[comment]

You really need to improve on your test methods. You already saw that it TAKES a string - but converts it to something else. So the question is: is your "number string" (??) setting a UNIQUE repetition? Or will the same repetition be recovered with another, much lower, number?

[Genx]

Point definitley taken, but to be honest I was to excited and therefore blind to the fact that there was a number in there.

Oh Well, Shawn's solution is promising nonetheless.

Edited June 9, 2007 by Guest

[Genx]

is your "number string" (??) setting a UNIQUE repetition? Or will the same repetition be recovered with another, much lower, number?

Sorry i was replying to a different post before. Before I posted that, I set two different values.

The first i set using that "number string". The second value, I set using that "number string" less one number on the end. That way, if the number is truncated then it would retrieve the same value.

Edited June 9, 2007 by Guest

[comment]

A number can also roll back to 0 or 1. I don't want to give you hard time (even though it's fun), but you said "point taken" - and you keep jumping to conclusions.

When you design a test to prove/disprove a hypothesis, you must design it in such a way that the result can ONLY be explained by the hypothesis being true or false.

[Genx]

So this isn't adequate?

Untitled.zip

[Genx]

The FileMaker calc engine will accept a number up to 800 digits in length and given that the variable can be specified via calculation I assume that a variable could pick up to the same number of digits.

[comment]

If I understand your hypothesis correctly, then no. All you have proven is that you can set 89 consecutive repetitions, starting at some arbitrary high number, and retrieve them back using the same numbers. But how do you know the repetitions are really indexed with the numbers you think they are?

All you have proven is that IF the numbers are modified on the way in, they are modified the same way on the way out. But you haven't proven that they are NOT modified.

Using your method, I can "prove" that Filemaker stores the passwords in the file. Fact: first, I input my password when I set up my account. Then, when I enter the same password, Filemaker fetches the correct account. Conclusion: the account is indexed by the password.

[comment]

Assuming is nice, but that's all it is. I know of several places where a similar assumption would seem reasonable, but it's incorrect nevertheless.

[Genx]

So how would you prove (or otherwise) disprove the hypothesis?

[Søren Dyhr]

I must say, I don't quite see the advantage of this. Why not simply drop the list into a single variable, then get the one you need by GetValue ($list ; $i )?

Where I would use this, to pad each field's autoenter with one of the reps. For each looping where a new record is crated can tiny adjustments be made to each value in the array if needed, while the alterations are kept. for next looping.

Similar to what I did, here:

http://www.fmforums.com/forum/attachment.php?attid/10846/

...it might not be rocket science, but I would find it usefull!

--sd

[Genx]

I honestly can't think of any way to do this test besides a "I place a key at random number" I return a key "from random number".

I tried on 100,000 values 3 times and I still got the same result -- that every single one of them was at whatever co-ordinate it was put.

Now, the only thing that I can see happening to a number if it's too long is that it get's truncated -- that's obviously not happening. What else can logically happen? Will C just decide to go, ladedededa, lets turn 564132145645615467498748946548944234867894234897456489742348974561489745618941247897474 into 321988455648 because it's the right length... and while we're at it, if we get the number 4564524894354864238948984943243248648943486435486463486486468465486453486423578313215644 we'll also assign it to 321988455648 because those two numbers buth have fourteen 4's in them.

I'm not being ridiculous, but I need to know what to test for if i'm going to test my hypothesis.

Untitled.zip

[comment]

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

[The Shadow]

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

[Søren Dyhr]

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

[comment]

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, 2007 by Guest

[Genx]

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

[comment]

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.

[Genx]

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)

[Genx]

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.

[comment]

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.

[Genx]

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.

[comment]

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.

[comment]

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

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

[Genx]

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.

[Genx]

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

[comment]

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

[Genx]

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

[The Shadow]

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.

[PerryL7]

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.

[comment]

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

[comment]

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.