MathWizz wrote:
Request: String operators!
Code:
(letter () of []) (join [] and []) (length of [])I need them to make a hash function.
I also want to be able to set value 10 of a list and not have to set value 3.
You don't have to ask for anything that's in BYOB. But they can't all be implemented on the same day!
Offline
bharvey wrote:
MathWizz wrote:
Request: String operators!
Code:
(letter () of []) (join [] and []) (length of [])I need them to make a hash function.
I also want to be able to set value 10 of a list and not have to set value 3.You don't have to ask for anything that's in BYOB. But they can't all be implemented on the same day!
![]()
+1
Offline
Could a few people with a lot of patience try the following in Snap! (with all the variable watchers hidden) and time how long it takes and let me know along with your OS and browser? (And I guess how old your computer is.
)



(I don't advise trying it for lists larger than 100 items.)
Thanks!
Offline
roijac wrote:
@bharvey, it took about 7min *wondering what would happen if i change it to 1000*
![]()
That's about the same as my result. What's your browser and OS? I want to be sure this isn't just a browser problem.
I estimate that 1000 items would take about half a year, extrapolating from the 100 case.
EDIT: Jens and I are having a disagreement about the nature of the problem. We'll see if his upcoming fix fixes it...
Last edited by bharvey (2011-11-20 13:58:23)
Offline
bharvey wrote:
Jens and I are having a disagreement about the nature of the problem. We'll see if his upcoming fix fixes it...
![]()
It's not a fix, it's a feature and it's called atomicity (to be used wisely). Check out the new WARP block!
Offline
Jens wrote:
bharvey wrote:
Jens and I are having a disagreement about the nature of the problem. We'll see if his upcoming fix fixes it...
![]()
It's not a fix, it's a feature and it's called atomicity (to be used wisely). Check out the new WARP block!
what does the warp block do? i put blocks in there and it gives me an error

Offline
warp?
@bharvey, i think your problem was that you didn't use in-place functions, but created new list every time, which had to be saved to RAM etc.
Edit: tried the script on python. works fast, as long you don't make the list longer than 1000 (max. recursive calls issue)
listLength=100 #change here to change the list's length
def cons(a, b):
result=[a]
index=-1
for i in range(len(b)):
index+=1
result.append(b[index])
return result
def cdr(a):
result=[]
index=0
for i in range(len(a)-1):
index+=1
result.append(a[index])
return result
def odds(L):
if len(L)==0: return L
return cons(L[0], evens(cdr(L)))
def evens(L):
if len(L)==0: return L
return odds(cdr(L))
def merge(a, b):
if len(a)==0: return b
if len(b)==0: return a
if a[0]>b[0]:
return cons(b[0], merge(a, cdr(b)))
return cons(a[0], merge(b, cdr(a)))
def sort(L):
if len(L)<2: return L
return merge(sort(odds(L)), sort(evens(L)))
import random
spam=[round(random.random()*10000) for i in range(listLength)]
spam=sort(spam)
print(spam)Last edited by roijac (2011-11-21 08:42:00)
Offline
roijac wrote:
@bharvey, i think your problem was that you didn't use in-place functions, but created new list every time, which had to be saved to RAM etc.
Yes, that was the point of the test. When lists are properly implemented, the operations I called CONS and CDR are very fast, and do not require copying the list each time. Proper implementation is necessary to support functional programming on lists, which we should support!
Offline
bharvey wrote:
nXIII wrote:
If you wanted a super-performant list structure, I could try to implement virtual lists. Then you could have a list of millions of items with no less performance, all in one big page.
I think it's the display, not the accessing, that's at issue.
Sorry, I meant "list-displaying-structure"--that is, a morph. Virtual lists reuse morphs in order to only allocate memory for and display enough items to fit in the viewing pane. That way, only eight or ten morphs would ever be rendered at one time, and the list doesn't even have to create a morph for every single item.
Last edited by nXIII (2011-11-21 15:47:20)
Offline
warped insertion sort example
time it takes to populate a list with random integers and to create a sorted copy on Brian's old MacBookPro and on my ancient PC both running Chrome:
100 items: 1 sec / 1 sec
500 items: 15 secs / 22 secs
1000 items: 1 min 10 secs / 1 min 26 secs
with all watchers hidden.
The WARP block corresponds to the "atomic" check box in BYOB, it runs the code it encompasses as a single block, interrupting only occasionally in order to update the display and to let the user interact. Try it on fractal turtle drawings and enjoy!
P.S.: The list watcher uses a "virtual list displaying structure" in that it only shows a subrange of about 100 cells. It feels slow because I'm only updating it every half second or so in order to allocate more resources to the evaluator, and even then I'm interrupting it while the update is still in progress in order to resume program evaluation again. It's not a DOM/CSS/XML/BMW/CIA/YMCA issue.
with both list watchers showing it takes almost the same time:
100 items: 2 secs
500 items: 22 secs
1000 items: 1 min 10 secs
to populate the unsorted list with random integers and to create and display a sorted copy of it. Where it's slow is below 100 items, because it has to create the cells the first time. But anything above 100 items doesn't take any longer just to display.
P.P.S.: Also new today are REPEAT UNTIL and WAIT UNTIL
Last edited by Jens (2011-11-21 17:23:06)
Offline
nXIII wrote:
Sorry, I meant "list-displaying-structure"--that is, a morph. Virtual lists reuse morphs in order to only allocate memory for and display enough items to fit in the viewing pane. That way, only eight or ten morphs would ever be rendered at one time, and the list doesn't even have to create a morph for every single item.
Oh, I see. That sounds good -- but not until save and load are done!!! (I was going to put a ferocious angry smiley here but the Scratch forum only has innocuous ones.
)
Offline
bharvey wrote:
nXIII wrote:
Sorry, I meant "list-displaying-structure"--that is, a morph. Virtual lists reuse morphs in order to only allocate memory for and display enough items to fit in the viewing pane. That way, only eight or ten morphs would ever be rendered at one time, and the list doesn't even have to create a morph for every single item.
Oh, I see. That sounds good -- but not until save and load are done!!! (I was going to put a ferocious angry smiley here but the Scratch forum only has innocuous ones.
)
is this so high on your list?
yay!
Offline
bharvey wrote:
Update: We both won the argument -- we were both right about different aspects of the problem and need both our solutions.
![]()
Isn't it awesome when it works out that way and no one gets to gloat?
Offline
Sidharth wrote:
Why is the name for the "all but first of" block "cdr" and the "insert at place 1" block called "cons"?
Not the permanent names. But they're historical, from LISP, where functional programming on linked lists originated. CONS is short for CONStruct, because it makes a new pair, the fundamental unit of storage; CDR dates from the first Lisp implementation on an IBM 704 computer, which had an Address and a Decrement in its central processor register, so it's the Contents of the Decrement of the Register; the left half of the pair was the Contents of the Address of the Register. The reason these otherwise silly names have survived is that they lend themselves to combination, so CDDADR ("cuh duh DAA dur") is f(x)=(cdr(cdr(car(cdr x)))).
Note: CONS isn't "insert at place 1"! It does not modify its input list; it makes a new list (which shares storage with the input list). In the BYOB 3 tools this is called ADJOIN (item) TO (list). We're considering (item) IN FRONT OF (list) as an alternative.
Offline