Order of function parameters

[LaRetta]

The order function parameters are listed in a CF matters.  What I do not understand is why it matters.

 

For those who aren't yet aware, if a custom function has three parameters, you must list them in the order specified.  If you switch the order that they appear in the list (drag one up or down), it will (most likely) break the CF.  It does not matter the order they are created in - only the order of the parameters in the CF list.  I thought originally it was because the calculation displays the function parameters and it would matter what was entered where but even that doesn't fit because all FM does is match the parameter name to itself within the calculation similar to Substitute(), doesn't it?   Besides, if I delete the calculation, change the order of parameters and re-create the calc it still breaks.

 

Should not FM read parameters into memory completely before it starts to evaluate?  It reminds me of when (I forget the version, I think 9) had an issue with evaluation order depending upon field creation order.  The evaluation order should not be dependent upon order they appear in the custom function list. 

 

BTW, if anyone wants to test, use a custom function such as BinomDist() by Comment here http://www.briandunning.com/cf/416 or Ray Cologon's UltraLog here http://www.briandunning.com/cf/416.  UltraLog is already done for you - just go to the custom function in the file and drag FieldsToLog to the top of the list and it will break (you must create new calculation after changing the order so you can re-order the parameters there as well).  There is nothing wrong with those custom functions of course; they both are really great  ... it is with FM requiring a specific order of parameter in the list.

 

Then I thought it was because the FIRST parameter requested within the calc needed to be first in the list but that does not hold either.  In UltraLog, FieldsToLog is used first in the calc but it is last in the original CF list.  If first, it breaks. In BinomDist, the first use is Trials and Successes in the Let() and Successes and Cumulative in the calc - neither perfectly match the order requested in the original CF.

 

I've created a few recursive custom functions with more than one parameter and I have never paid any attention to the order and I just add them any old way I think of them, LOL.  I won't any more!! And I would sure appreciate clarity on it.  And yes, this kind of crazy stuff keeps me up at night when I spot it.

 

Added red - this forum was trashing out on me and I could not edit.

[comment]

I don't recall coming across such problem. The only thing that comes to mind is this:
 

just go to the custom function in the file and drag FieldsToLog to the top of the list and it will break (you must create new calculation after changing the order so you can re-order the parameters there as well). 

 
If it's a recursive function, it's being called from at least two locations: once (or more) from within itself and once (or more) from outside (e.g. a calculation field or a script). After re-ordering the function's parameters. you must also re-order the arguments of the function callers - in all the places where the function is being called.

[Lem Alpha]

Hi there,

 

I'm not really sure I understand what bothers you about this, so excuse me if I'm completely missing the spot :

 

the order of parametes matters because it's the only way for the custom function to know which string is what. There is no such thing as "parameter name" when you call that function, as there can be f.i. in an URL

e.g. google.com/#q=sometext&hl=fr

imagine that the server didn't need parameter identification, and that URL was written that way : google.com/#sometext&fr

if you switch the input parameters like this, google.com/#fr&sometext the server would try to search for the text "fr" and try to show only pages in "sometext" language... Because it's the order of the parameters that tells him that "fr" is the text to look for, and "sometext" the selected language of the results.

 

And if you switch the expected parameters order on the server, so that the first string he sees will tell him the language and the second the search request, you would of course have to write any URL in that particular order.

 

Same thing for FM custom functions (and internal I guess, though you can not alter these) : in the definition of your CF, let's say BinomDist, you tell FMP that the first string encountered is "successes", the second "trials", etc.

If you switch them in the definition, but leave all the written calculations unchanged, FMP will understand that the first value you entered (and meant to be "successes" when you originally wrote it) is now the value you want for "trials", and so on. So you would obviously have to rewrite the calcs with the "trials" value first, ...

 

Hope it helps.

[LaRetta]

I really appreciate the help Michael :-). I will do further testing because without a calculation or SOME reference within the file I did not expect the CF to call 'within itself' or load itself at all.

So when a file is opened does a CF load itself and its parameters (and their order) into memory even if not referenced anywhere? If so, it might explain the 'stickie order' I am observing. And if so then why does FM even allow reordering of the parameters?

Do you think the order of their appearance in the list (in CF dialog) matters when it is created before it is even used in a file?

[LaRetta]

Hi Laurent, Thanks for the input! I realize the order matters when you USE a CF that the calculation matches the order of the CF. But what I observe is changing the order BEFORE ever creating a calc to use it. Or better phrased, deleting the calc which used the OLD order, changing the order of the parameters in the CF dialog and then recreating the calc using the new order. The CF breaks. My conclusion is that it is storing the order and it shouldn't. :-) I may need to run more tests or somehow come up with a demo to explain my observations.

This is stand-alone file and not served or even related - just new file on my desktop.

[Lem Alpha]

All right, I didn't get this, and it did seem strange to me that such an experienced member would have that kind of questions...

 

I think I did switch parameters a couple of times, and rewrote the calcs, but I've no memory of such problems.

I definitely will try to reproduce this one of these days (unless you do come up with a demo in the meanwhile)

 

So,  again sorry for the useless answer.

[LaRetta]

No need to apologize. Sometimes I miss obvious things particularly when very tired. And sometimes a newbie has incredible ideas so all input is appreciated - it is Master Mind principle.

If the CF somehow stores its parameters then deleting the calc will not RELEASE those parameters so creating a new calc without closing the file in between may not release the order. Then when I create the new calc it gets twisted. I cannot test in the moment (on iPad) but if this is so then the reorder ability in the CF dialog is bad news.

[dansmith65]

Can you explain what you mean when you say the calculation breaks?

[comment]

I did not expect the CF to call 'within itself'

 

A recursive function must at some point call itself - that is how it recurs. Look inside the formula for the function's name.

[LaRetta]

Oh Michael, I know a recursive custom function calls itself  :-) ... I meant that I did not think it called itself (or loaded itself or the order of its parameters) into memory (or was otherwise activated) if it was not used anywhere in the file and not even in a calculation.  We should be able to delete the calc, drag the order of parameters differently, create a new calc using that new order and it should produce the same number result, right?  It does not … not for me. :-/

 

The CFs break differently, Dan, thanks for helping too.  BinomDist() produces a different number result and UltraLog produces a single list of the field names (if you clear) and produces two duplicate rows of everything if you Prep (you can test in the original version of UltraLog I linked above).  I have attached an fp7 and fp12 version (for others to easily test) with BinomDist() example and results are same on Windows XP Professional SP3, 11.0v3 and 12.0v3.  I am using BinomDist()  for this example because the calc is easy to delete and recreate.  If you do these steps exactly, I think you will see what I mean.  Please help me pin this down:

 

1.  Fields are number:  success, trial, probable and cumul.  I named them similarly to the parameters so I would not get confused when re-specifying them in the CF.  To compare results, I needed to be consistent on which field values were used so I do not change the numbers so that the results will tell me if it works the same.

 

2.  CF’s function parameters were created in the order listed within the CF specs.  This new file had the CF created originally in order of:

1. Successes
2. Trials
3. Probability
4. Cumulative

3.  The calculation is also properly in this order and it looks like this:

1. BinomDist ( success; trial; probable; cumul)
2. This calculation produces 10241
3. If you change the numbers in the yellow fields just write down your result so you know the base line for comparison when we change the order.  I pasted my results onto the layout so I would not forget, LOL.
4. the test now starts on #4 below

4. Now delete that calculation completely.  We do not want it influencing the CF or calling it.

 

5. Then go to the CF in Manage > Custom functions and drag the parameters to this order:

1. Cumulative
2. Probability
3. Trials
4. Successes

6. Say OK, OK to exit and then Close FileMaker (to make sure it lets go of everything about that CF in its memory).

 

7. Open file again and create new calc, number, unstored.  When you select BinomDist() it will (of course) now be in this new order as #5 above.

 

8.  Double click each parameter and re-specify to its proper field which results in calculation of: BinomDist ( cumul ; probable ; trial ; success).  Make calc a number and unstored.

 

9.  Place the new calc on your layout.  What do you get?  I get -918791808 -62144

 

If you delete the calc again, drag the CF parameters back to original order as #2 above and re-create the calc, I will bet it works again as your original figure.  Does it?  At least on my OS/FM version, it appears to store the order internally when created (?) and reordering the and re-creating the calc does NOT really change the order of how FM is interpreting it).  I only tested these two custom functions (this and UltraLog) but if it does this on two it most likely will do it on other CFs.  The thing is ... if the order doesn't matter, why do they have ability to reorder?  If it DOES matter then it should work as expected - on both platforms.

 

updated:  actually with this specific order I get -62144.  The number changes depending upon order.

CF_break.zip

Edited November 11, 2012 by LaRetta

[LaRetta]

Does FM not use a Substitute()?  Where the CF has 'successes' it uses the value of 'success'.  Why provide an order option other than to allow the developer to custom or alpha order them for display?  Why allow or care about reorder?  This is my confusion I think.

Would we need to go through the calculation and change it there just because we change the order in the list?  At the very least, FM should protect me (as a User) from my own blunder.  And I have searched for answers on this one.  But then again ... maybe I missed class the day that lesson was shared, LOL 

[comment]

Let me try this once again... 

 

Your step-by-step is missing a step. After:

 

5. Then go to the CF in Manage > Custom functions and drag the parameters...

 

and before:

 

6. Say OK, OK to exit ...

 

there must be an additional step:

 

5B. Modify this line:

discrete + BinomDist ( successes - 1 ; trials ; probability ; 1 ) ;

 

to:

discrete + BinomDist ( 1 ; probability ; trials ; successes - 1 ) ;

 

otherwise the function will break.

[LaRetta]

Comment said, " After re-ordering the function's parameters. you must also re-order the arguments of the function callers - in all the places where the function is being called."

So I DO have to manually change the order where it calls itself within itself? Yep I must have been home sick that day. :^)

[comment]

So I DO have to manually change the order where it calls itself within itself?

 

Yes, of course. A call to the function is a call to the function - it must follow the function's order of parameters, no matter where the call is coming from.

[LaRetta]

Now how else would I want to spend my Saturday night at 8:00 PM than blushing and laughing simultaneously on FMForums. I have never needed to reorder. I could not even think of a reason to want to do it, probably because I've only written a dozen or so recursive CFs. Ahm, moving on ... :-) ... and thank you for your participation ... :-)