Scratch

OH! I have an idea for a block that can come it a lot of handy! (touching sprites) It reports a list of all the sprites that are touching the calling sprite. This one can't really be... I have a better idea! A (sprite names) block! Oh, wait if everything will become first class the this might become obsolete.    O'well. At least I gave you a few ideas... 

EDIT: 23rd page! (At least for me...)

Last edited by MathWizz (2010-09-02 13:32:49)

fullmoon wrote:

Even if we had a function to convert strings to integer values and vice versa, we still wouldn't be able to build a native dictionary/hash/whatever with string keys, because the integer values would be outside the bounds of the array.

The way hash tables work is that you make a list whose size is a prime number bigger than the number of entries you expect, with an empty list in each element.  Then to hash something, you convert its key to an integer modulo the size of the list, i.e., you use the REMAINDER function to get the value.  Then you add the new element to the list that's in the chosen element of the hash table.

So you can do it with the tools you have.

The classic hash function for text strings is that for each letter/character you say

SET <hashindex> TO (<hashindex> * 32) + (ASCII CODE FOR <char>)

It's 32 rather than, say, 128 or 256 because the high order bits of letters are all the same, so you want to make sure each bit of the result is actually affected by the key, to make sure the values are evenly spread out.

fullmoon wrote:

What we need is for BYOB's arrays to be sparse

Sparse arrays are a good idea, but I think they can be implemented on top of the lists we already have.  Basically a sparse array is a hash table in which the keys are numbers.

bharvey wrote:

The way hash tables work is that you make a list whose size is a prime number bigger than the number of entries you expect...

I'm still trying to wrap my head around that...

I figured out a way to make a dictionary in BYOB without hashing or cycling!

It's always distorted, but I hope you can understand it.

This block takes advantage of the fact that you can use the (copy of [list]) block with a string input to get a list of the string's characters.

Also, you can only use a string with typical characters (ones that are on your keyboard) as indices, but the value can be anything.

Last edited by rubiks_cube_guy238 (2010-09-03 11:19:28)

rubiks_cube_guy238 wrote:

I figured out a way to make a dictionary in BYOB without hashing or cycling!

Cool!  There's a name for your invention; it's called a "trie" (pronounced "try").  It's as fast as hashing, but usually uses more memory (because you're going to have a lot of mostly-empty dictionaries).

This block takes advantage of the fact that you can use the (copy of [list]) block with a string input to get a list of the string's characters.

Oh, weird.  I think that's a bug, but I suppose it doesn't hurt anything.  There's an ALL BUT FIRST LETTER OF block in the tools library, which would be the more straightforward way to do what you're after.

bharvey wrote:

nXIII wrote:

I don't know why, but I'm getting so many bugs in BYOB.

Report them in bugzilla!  Thanks.

But I don't know why they're happening, because I can't, for example, change the color of a custom block (which you can do normally? It gives me an error)

bharvey wrote:

rubiks_cube_guy238 wrote:

I figured out a way to make a dictionary in BYOB without hashing or cycling!

Cool!  There's a name for your invention; it's called a "trie" (pronounced "try").  It's as fast as hashing, but usually uses more memory (because you're going to have a lot of mostly-empty dictionaries).

This block takes advantage of the fact that you can use the (copy of [list]) block with a string input to get a list of the string's characters.

Oh, weird.  I think that's a bug, but I suppose it doesn't hurt anything.  There's an ALL BUT FIRST LETTER OF block in the tools library, which would be the more straightforward way to do what you're after.

I know that there's an a.b.f.l.t. block, but that uses a repeat. I did this because I wanted to be able to create a dictionary where no repeat blocks are used, and can't get any collisions (like you get from hashing).

No, you don't understand. I don't understand hashing either.
My dictionary class doesn't use hashing.

bharvey wrote:

it's called a "trie" (pronounced "try").

Last edited by rubiks_cube_guy238 (2010-09-03 14:45:00)

I think we need to be able to create temporary variables in 3.1.

Why when you can just use a list?
Well, when I make a block, sometimes I want to parse something and turn the contents into a list using the (list ->) block. Unfortunately, I can't find a way to join an old list's items with a new list's items, turning it into one list. Ideally, there should be a block for that, but it wouldn't have many uses. And I can't find a way to do it by creating a custom block without creating a global list (which is a pain).

Temporary variables would solve that problem, and add more functionality to BYOB. I understand it isn't necessarily in line with the "First Class" idea, but it would be a really useful feature.

Does anyone have any alternative solutions in the meantime?

shadow_7283 wrote:

I think we need to be able to create temporary variables in 3.1.

Why when you can just use a list?
Well, when I make a block, sometimes I want to parse something and turn the contents into a list using the (list ->) block. Unfortunately, I can't find a way to join an old list's items with a new list's items, turning it into one list. Ideally, there should be a block for that, but it wouldn't have many uses. And I can't find a way to do it by creating a custom block without creating a global list (which is a pain).

Temporary variables would solve that problem, and add more functionality to BYOB. I understand it isn't necessarily in line with the "First Class" idea, but it would be a really useful feature.

Does anyone have any alternative solutions in the meantime?

You could use upvars in c-shaped command-block reporters.
Yes, I know, "WHAT?!"
Basically, you use upvars instead of return values (hey, you can have more than one!) and put a "Code [" as the last argument. "run (Code)" on the last line of your block, and you have variables for use just inside the reporter.

Last edited by nXIII (2010-09-03 18:44:12)

bharvey wrote:

shadow_7283 wrote:

I think we need to be able to create temporary variables in 3.1.

We have that!  Use the SCRIPT VARIABLES block.  Or am I missing something?

Unfortunately, I can't find a way to join an old list's items with a new list's items, turning it into one list.

There's an APPEND block in the tools library that takes any number of lists as inputs and returns a new list concatenating all their elements.  If you want to reuse an old name to point to this new list, don't use "Make a list"'; set a variable to the original list and then re-set it to the new value when you do the append.

You can't create script variables based on need. For instance, if I wanted to create a variable every time the space key was pressed, I couldn't.

Thanks for the append tip. I'll try it out.

nXIII wrote:

bharvey wrote:

nXIII wrote:

Yes, I know, "WHAT?!"

I think I'll make it my new coding style, super-ultra-explicit contexts.

What? I'm confused.