RFC - Repeat Function Idea

[The Shadow]

Staying on the subject, I'd agree with Mike the name "Range" may be too tied to the output, but then "Count" is too close to a counter/loop thing as well.

It's not that I love the name Range(), but I think its better than Counter(), which makes it seem like its only for use when iterating.

By the way, *if* this function were accepted into the product, it's the human interface designers who come up with the final name - not programmers, and especially not those who don't work there anymore, so I doubt my suggestion to them will have any effect.

I stopped over in Santa Clara today and made my pitch, btw. They seemed interested and will consider it, with no promises, of course.

[Genx]

I can't recall but I'm fairly sure Michael made a suggestion somewhere of "Enumerate" - I would think this would be the most logical word, and its not like FM is afraid of long words e.g. Substitute, PatternCount, MiddleValues ...

Enumerate(low,high)

It also defines a lot better than range:

- to specify one after another

- to mention separately as if in counting; name one by one; specify, as in a list.

Better yet, you could call the function: EnumerateRange(low,high).

Range, at least to me, seems a little vague compared to most of the other FM functions.

Edited December 4, 2007 by Guest

[The Shadow]

Perhaps it's worth noting that a list of values is ALWAYS going to be Text.

So to me, it doesn't matter so much if the output is

    "12/7/2007¶12/14/2007¶12/21/2007¶12/28/2007¶"

or

    "733017¶733024¶733031¶733038¶".

Actually, I can think of situations where I'd prefer the latter.

The way I implemented the prototype code, it always attempts to propagate the type of the first argument, so:

  Let( d = Date(12,7,2007); Range( GetAsNumber(d); d+(4*7)-1; 7 ))

would produce your preferred output.

[Genx]

For what its worth, this basic recursive CF demonstrates how I would think the Range portion of this at least would work...

EnumerateRange( low ; high ; factor )

Case( low <= high  ; low & ¶ & EnumerateRange( low + factor ; high ; factor ) )

I don't think we should lock ourselves into any hardcoded interpretations of variables - the fm engine already knows how to add to different data types, and we have the ability to use those types directly as we need them to get whatever output we desire.

EnumerateRange(0 ; 1000 ; 5)

"0¶5¶10¶...¶995¶1000"

Type cast it...

EnumerateRange( GetAsDate("12/1/07") ; GetAsDate("12/12/07") ; 7)

"12/01/2007¶19/01/2007¶26/01/2007¶...¶7/12/2007"

EnumerateRange( GetAsNumber(GetAsDate("12/1/07")) ; GetAsNumber(GetAsDate("12/12/07")) ; 7)

"732688¶732695¶732702¶...¶733017"

[comment]

Case( low <= high

I don't see why it shouldn't go in the negative direction too, e.g. Enumerate ( 10 ; 0 ; -2 ) returns "10¶8¶6¶4¶2¶0", and Enumerate ( 10 ; 0 ; 2 ) returns "?", I guess.

---

As long as I am nitpicking, "factor" is something you multiply by. I'd pick "increment" or - to keep it the same as the SerialIncrement() function - "incrementBy".

[Genx]

Yeh the factor thought crossed my mind. The negative thought never crossed my mind but its definitley a good point.

EnumerateRange( start ; end ; increment )

If( Case( increment > 0 ; start <= end ; increment < 0 ; end <= start ) ; start & ¶ & EnumerateRange( start + increment ; end ; increment ) )

Lol, or change increment to dincriment... lol get it? Sigh... that has got to be the lamest thing i've ever said, oh well.

.. Ignoring the question mark which would be returned for any invalid submissions.

Edited December 6, 2007 by Guest

[bruceR]

Dear Bruce,

Agnès sent me this recursive version ways before you published yours and advertised it as being a creation of yours, without even mentionning her name in the comments...

Unfortunately, it is still much slower than CustomList, and limited to 10,000 items. More, I'm not sure to understand what's so simple about it all 3 parameters are exactly the same as CustomList's.

Give back to Ceasar...

1. If Agnes sent it to you without my comments - why did she do that? See the only place I've publicly posted it, on Brian Dunning's list, where the very first line mentions Agnes.

2. During my tests while communicating with Agnes on this subject I demonstrated that the claimed speed advantage of her function did not exist.

3. Because of tail recursion, the recursion limit is 50K, not 10K.

4. My CF is about 8 lines of actual function. Leaving aside other issues, it is far easier to understand and modify for your own purposes.

5. Do you complain to people who submit alternate quicksort functions or other custom function variations?

Edited December 16, 2007 by Guest