This is a read-only archive of the old Scratch 1.x Forums.
Try searching the current Scratch discussion forums.

#1 2007-10-11 18:19:44

jaxonwhite
Scratcher
Registered: 2007-10-11
Posts: 2

File does not run all scripts after uploading to gallery.

I've uploaded a file which works fine on my laptop, but does not run all scripts after being loaded into the gallery. Is there some problem with converting the file for display in the gallery?

The problem is related to the "distance to" block. Perhaps there is a round-off error? Or perhaps it's some borderline programming that craps out when being converted?

If it helps, the file is ...
http://scratch.mit.edu/projects/jaxonwhite/42853

any insight is appreciated.

thx

Offline

 

#2 2007-10-11 20:56:33

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: File does not run all scripts after uploading to gallery.

I think that the problem is that you did an EQUALITY test on distance.

Try changing your test from (distance=2) to (distance < 2).

Because the distance is a floating point number, it may never exactly equal 2.

Offline

 

#3 2007-10-11 21:57:19

andresmh
Scratch Team at MIT
Registered: 2007-03-05
Posts: 1000+

Re: File does not run all scripts after uploading to gallery.

kevin is right and by the way, the problem you're experiencing is not related to the fact that the project was added to a gallery


Andres Monroy-Hernandez | Scratch Team at the MIT Media Lab
on identi.ca and  twitter

Offline

 

#4 2007-10-23 22:03:10

jaxonwhite
Scratcher
Registered: 2007-10-11
Posts: 2

Re: File does not run all scripts after uploading to gallery.

thx, people. changing the operator created much more robust performance. still wondering why it worked on the laptop, but not after loading into the gallery. perhaps a difference in the display mode?

Offline

 

#5 2007-10-24 21:40:57

kevin_karplus
Scratcher
Registered: 2007-04-27
Posts: 1000+

Re: File does not run all scripts after uploading to gallery.

There may be a rounding operation that happens in the squeak implementation and not the java implementation, or they may use slightly different floating-point implementations that resulted in one being ending up equal to 2 and the other at 2.000001

The vagaries of floating-point math are why you should never do equality checks on floating-point numbers.

Offline

 

Board footer