Scratch

B-u-m-p

Text version now? First variable, then list, then text, then back to list? Seems like alot.
The thing is, there's no point in splitting who does what if it's all planned out. 

Nom?

amcerbu wrote:

No, what I'm saying is we write out the code for the program in a

Code:

box inside the forum, then we code it in Scratch.  That way, everyone can see how the program will work, and provide criticism within the forum topic, rather than downloading and re-uploading the project itself.

EDIT: I'm sorry, my previous comment was kinda vague.  I hope this clears that up.

But we could just build the scripts seperetley and number them from 1-10 or howevermany there are. At the end we could just tak them onto eachotherっ。

Hardmath123 wrote:

amcerbu, I think I may have confused you—you job is to insert * for implied multiplication, and check for mismatched brackets (using sci's code). Reporting the innermost bracket set is hpotter134's job. Sorry if I confused you.

I support a grapher.

I support doing things in code boxes.

I think 0s1s will not be possible. The script will be too long. How about something like this:

Code:

When greenflag clicked
{scimonster's coding}
broadcast amcerbu

When I receive amcerbu
{amcerbu's coding}
...

and so on.

@Hardmath123- The method I described earlier for checking for mismatched brackets (using two lists) will be expandable for hpotter134's job, that is, the method for checking for mismatched brackets does not need to be separate from innermost brackets.  I don't think it is practical to separate those two jobs. 

Here is the old description of the bracket method:

amcerbu wrote:

This is how the parentheses locations will work: one temporary variable will increase from 0 until it reaches "(", and another variable will start at that location, and increase until it reaches ")" (and has passed an equal number of "(" and ")" already- we don't want it picking up the first one it stumbles across).  That means that innermost brackets will appear at the end of the parentheses location lists, and in order from left to right.  So...

Code:

a+(b(c+d))
1234567890  //item number in the input list.  
will report as
( list- 3 5 
) list- 0 9

Note- I used 0 instead of 10, didn't want to run out of digits. 

Notice that the innermost brackets - at locations 5 and 9 - are the last members of their respective lists.

Last edited by amcerbu (2011-05-05 12:58:45)

Can i help?

I'm not HardMath123 but what could you help with?

eclown wrote:

Can i help?

Anyway, please could I get some feedback from Hardmath123 about the things mentioned above?

amcerbu wrote:

@Hardmath123- The method I described earlier for checking for mismatched brackets (using two lists) will be expandable for hpotter134's job, that is, the method for checking for mismatched brackets does not need to be separate from innermost brackets.  I don't think it is practical to separate those two jobs. 

Here is the old description of the bracket method:

amcerbu wrote:

This is how the parentheses locations will work: one temporary variable will increase from 0 until it reaches "(", and another variable will start at that location, and increase until it reaches ")" (and has passed an equal number of "(" and ")" already- we don't want it picking up the first one it stumbles across).  That means that innermost brackets will appear at the end of the parentheses location lists, and in order from left to right.  So...

Code:

a+(b(c+d))
1234567890  //item number in the input list.  
will report as
( list- 3 5 
) list- 0 9

Note- I used 0 instead of 10, didn't want to run out of digits. 

Notice that the innermost brackets - at locations 5 and 9 - are the last members of their respective lists.

Ummm, I think we'd be a lot more organized the simple way.

Please read

Hardmath123 wrote:

amcerbu wrote:

This is how the parentheses locations will work: one temporary variable will increase from 0 until it reaches "(", and another variable will start at that location, and increase until it reaches ")" and has passed an equal number of "(" and ")" already- we don't want it picking up the first one it stumbles across.  That means that innermost brackets will appear at the end of the parentheses location lists, and in the order they appear from left to right.  So...

Code:

a + ( b ( c + d ) )
1 2 3 4 5 6 7 8 9 0  //item number in the input list
will report as
( list- 3 5 
) list- 0 9

Note- I used 0 instead of 10, didn't want to run out of digits. 

Notice that the innermost brackets - at locations 5 and 9 - are the last members of their respective lists.

Ummm, I think we'd be a lot more organized the simple way.

Hardmath123, what I described earlier is the easiest way to detect the innermost set of brackets, and at the same time can be used to test for mismatched brackets.  In other words, testing for mismatched brackets should be part of the same code as finding the parentheses hierarchy.

Does anyone else agree?  It doesn't feel like anyone is reading the forum topic anymore.  I don't want to accidentally do hpotter134's job, but I think it should be pointed out that a system like this will make our code much simpler, faster, easier to read, and easier to build upon.

Just to reiterate...

The output list from this method will contain innermost brackets at the end, and when two pairs of brackets are at the same "level", the locations will be adjacent to each other.  So...

5-(1+2)(1-2)

The lists will store first the locations for the brackets in (1+2), and then immediately afterward for those in (1-2), so the evaluation program will start within brackets located at the end of the parentheses lists, and work backwards.  This will provide correct evaluation. 

I am encouraging this system because it functions similarly to how we work problems out with pencil and paper.  Any support?  I'm sorry to be arguing with Hardmath123, but I feel that the code should be as compact, neat, and effective as possible.  In other words, if there is a way to handle two parts of the project at once, it should be used. 

Last edited by amcerbu (2011-05-07 21:13:31)

I would like to help develop Xenon.

Bumping hpotter134's post as well as my own.