Find replace function

It’s actually a perfectly useful function, organizing (not sorting) data by key; and a serious implementation. As for me a more or less readable version is:

Update
I found Programming tools SANDBOX script pic 80 (from the Frequency Distribution Analysis library) to do more or less the same thing, and - admittedly - both a little better, and faster.

  1. DISTRIBUTION OF is not applicable, in this case.
  2. DISTRIBUTION OF is not documented (no on-line HELP or ref.manual description)
  3. Apparently, DISTRIBUTION OF compares lists by reference, not by content - which, in my view, is rather peculiar for such function:

I agree that your version is more readable! Although part of that is the long variable names, and those names could be used as the formal parameters of the functions in PIPE. But that tiny little gray spacer is very cute. :~)

Does (1) mean something other than (3)? If so, could you please expand on (1)?

Yeah, (2) is my fault; I'm going to try to get the manual up to date by Snap!Con.

I imagine (3) is Jens's effort to make the block super fast, but I'll enquire. I agree that testing with EQUAL might make more sense in this context of grouping, but EQUAL is way slower than IDENTICAL, not only for lists, but because of case insensitivity.

By the way, not sorting the keys makes the whole thing take 𝜽(n²) time, because you have to search the entire input for each key, whereas if you sort the keys you can do it in 𝜽(n log n) time.

Updated code

Find and replace code script pic (2)

untitled script pic (38)

I'm going to try out. Thanks!

Update
It appears to work (though generating an extra ring around each result, which can easily be fixed), but I don't understand why. Could you try to explain it to me?

By now I fixed the problem inside the code itself. Still I'm curious as to your quick fix, how it works.

Latest version

Thank you; it's simply a do-nothing block named $nl (= newline). I found it to be useful for dividing code into some kind of paragraphs, for readability purposes. Find and replace code script pic 7

DISTRIBUTION OF reports the number of copies of a data element, the whole of each data element is considered key; both my GROUP BY function, and the similar block from the FDA library, operate on key-value pairs, considering key only item 1 of each data element, and grouping all data elements with the same key.
This dichotomy is completely different from the one between reference (memory position) and content (data).

Then why not offer two separate (and well-documented) DISTRIBUTION OF functions: one superfast but with limited functionality (to be applied primarily on lists with atomic elements), the other for general use but slower? Plus some way to indicate case (in-) sensitivity with the second version.

(the same reasoning as applies on the current superfast implementation of REMOVE DUPLICATES) :wink:

True. I chose not to sort, so as to keep the solution as general as possible (sorting is not trivial for (sub-)lists, command blocks, and some more). However that may be, now that I've found the GROUP BY block in the FDA library, I've concluded my own version to be redundant.

im working on something like that w/ metaprograming blocks rn :D

Did you check out my REPLACE () WITH () IN CODE () ?

Yes, I see now, well done!

OK.

Is it?

No, its cool, but i wanna make my own cuz its fun

That’s a perfectly good reason.
I’m looking forward to see your version.
Good luck, and have fun!

Weird, i thought you guys know snap better than newbies like me. For me snap is a mystery, so idk why it works xd

I’m not sure if that isn’t irony :wink: (that you didn’t indicate it doesn’t mean it isn’t, is it?)
You’re doing pretty advanced stuff for a newbie - in a few months you may be viewed as an “expert” yourself.

We do; one's a primitive and the other's in a library. ;~) But I'll try to remember not to remove the library one, and to improve the documentation.

Which library would that be?
I found a version in the FDA library, but it, too, considers reference, not content:

Oh, I thought you had said that it meets your needs. Sorry.

Actually, no I didn't.
Edit Perhaps you’re erroneously referring to my appreciation of GROUP BY, from the same library.

I've been trying to write a more versatile version of ANALYZE, that can be configured to compare lists by any of 3 methods:

  1. reference-based;
  2. content-based, case-sensitive;
  3. content-based, case-insensitive.

Edit Actually there’s 4 methods (the “reference-based” option applies to (sub-)lists only).

I have not quite succeeded yet (though I'm probably close). In the process I discovered having to rewrite:

  • CONTAINS,
  • INDEX OF, and even:
  • "=".

The thing is, both ANALYZE (aka. DISTRIBUTION OF) and REMOVE DUPLICATES FROM compare reference-based (on lists) or case-sensitive (for text), while CONTAINS, INDEX OF and "=" make content-based and case-insensitive comparisons.

I'll keep y'all posted on my progress.

It just occurred to me that this sort of thing would be easier if we could have invisible optional inputs, not even an arrowhead, but if you hover on the right edge of the block it expands optional input slots with labels (using the formal parameter as the label). This would be an alternative to the visible optional inputs that we'd also have; it'd be intended for inputs that would be (1) rarely used (2) by experts.

This is a top-of-my-head idea, and I don't mean to promise that we'll do anything along these lines, let alone with this particular UI. But I'm proud of the part about using the formal parameter as the label, maybe with a colon appended; that would solve an important use case of the input-group idea with no added UI complexity for the block author.

I’m in doubt as to whether the right edge of blocks would be the best spot to add any more functionality. It’s already the domain of input lists (which BTW can be pretty challenging to evoke, especially when using a tablet).

Perhaps the left edge would be preferable - already being home base of the flash, in practice corresponding to comparison methods cutting corners (such as … ).

Either way, I’d prefer even rarely-used, expert-ish options to be visible. Snap ! - BTW (2) how on earth do you manage to mould an italicized exclamation mark immediately behind a text? - already has a great mechanism for this sort of thing: the read-only input options field with a default value.

untitled script pic 76

It may be a stroke of genius, but I don’t get it. Would you provide an example?

Starting with the easy question, Snap<i>!</i>. My Mac has a feature that lets you set up abbreviations for things you type often, so I have S! set to expand into that.

The thing is, that conflicts with the goal of keeping simple things simple. Users wouldn't know what "c/s" means, so we'd end up with a block like


which would never get past Jens. :~)

So instead my idea is that the block should look just like the existing CONTAINS primitive, but when you hover over the right edge, it turns into


and then clicking on a left-arrowhead deletes that input slot and its label. (Yeah, the spacing is wrong around the arrowheads.) You'd never see a right-arrowhead for these inputs; they're optional, not variadic.

This would allow a block to have a dozen optional inputs, and still look simple in the palette. Some of the network-related blocks have a zillion options and would benefit from this treatment. In the normal case you leave them all with their default value (it doesn't have to be a Boolean, although that'll be common) and the block is short and sweet. But experts can get exactly what they want by making the optional inputs visible.

Without this feature, we could do something like
untitled script pic (2)
in which each arrowhead corresponds to an optional input and you'd have to learn (by opening and closing them) which arrowhead corresponds with the input you want. But that's hideous, right?

Sure. Instead of


you'd just say

in which I'm using the brown oval to mean "optional input with label" (just for discussion purposes; I don't know how we'd actually indicate that category in the UI). The formal parameter, e.g., case-sensitive, with a colon appended, is what's used as the label, so the user doesn't have to type the name twice in the prototype.

Thanks for the hint!

On my iPad I have now configured Autocorrection to replace Snap! with Snap! … well, whatever :smirk: