should be: 10,2 at last record without 1st record. the block analyse () return a list of value and the number of occurence of each value (like a group by and the count function)
I think the bug come from the use the block numbers from () to () with the analyse block
normal result in this case should be:
Your project link just goes to Snap!, not your project.
Oh and it might be the "dta_analyze" function not recognizing the string "10" being the same as the number 10:
Ah yes, that's a bug, but one that I'm probably not going to fix, because it would makes things a lot slower. The issue is that the numbers from 1 to 10 are internally treated as numbers, whereas the "10" is treated as string, hence the 2 entries. For now you can work around this issue by making sure all entries are numbers, just use
_ + 0 when you cons a number to a list of numbers.
One of the dirty secrets of "real" data science is that basically everything is treated as a string all the time until you start doing arithmetic with it.
this is what mystified me:
here, the left list is evaluated as a list of numbers. (or it seem to...)
Waah! Brian is unhappy!
I think slow correct answers are way better than fast wrong answers. This is not something for which users can be expected to invent a workaround.
Probably the right thing is that text inputs that look like numbers should be stored as numbers. (Ones the user types into an input slot, I mean, not necessarily computed ones.)
Well, the equals block converts values to the same type before evaluating.
this is not core Snap! but the data science library, it has been written to deal swiftly with large-ish data sets of up to millions of records. If you want correct-but slow use the lists library, it also has associations that use Snap!-equality.