Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #37337 > unrolled thread

A proposition for a conditional loop.

Back to article view | Back to comp.lang.javascript

Contents

  A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-23 00:55 -0700
    Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-23 01:05 -0700
      Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-23 01:14 -0700
        Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-23 01:16 -0700
          Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-24 05:12 -0700
    Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-24 22:27 +0200
      Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-24 22:39 -0700
        Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-25 09:05 +0200
          Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-25 02:47 -0700
            Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-25 13:13 +0200
              Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-25 05:13 -0700
                Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-25 15:04 +0200
                  Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-25 06:10 -0700
                    Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-25 15:50 +0100
                      Re: A proposition for a conditional loop. Tim Streater <timstreater@greenbee.net> - 2019-09-25 16:00 +0100
                      Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-25 10:20 -0700
                        Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-25 10:26 -0700
                          Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-25 19:18 +0100
                            Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-25 12:19 -0700
                              Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-26 10:48 +0100
                                Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-26 04:38 -0700
                                  Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-26 18:05 +0100
                                    Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-26 10:54 -0700
                                      Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-27 10:06 +0100
                                        Re: A proposition for a conditional loop. dr.j.r.stockton@gmail.com - 2019-09-27 02:34 -0700
                                        Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 05:32 -0700
                                          Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 05:36 -0700
                                            Re: A proposition for a conditional loop. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-27 20:23 +0100
                                              Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 12:45 -0700
                                                Re: A proposition for a conditional loop. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-27 22:05 +0100
                                                  Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 14:39 -0700
                                                    Re: A proposition for a conditional loop. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-28 00:16 +0100
                                                      Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 17:10 -0700
                                                        Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-28 17:28 +0200
                                                          Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-28 11:34 -0700
                                                            Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-28 22:23 +0200
                                                              Re: A proposition for a conditional loop. Tim Streater <timstreater@greenbee.net> - 2019-09-28 21:42 +0100
                                                              Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-29 07:40 -0700
                                                                Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-29 18:33 +0200
                                                                  Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-29 09:58 -0700
                                                                    Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-29 19:18 +0100
                                                                    Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-29 21:02 +0200
                                                                      Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-29 13:54 -0700
                                                  Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-28 10:41 +0100
                                              Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 13:17 -0700
                                          Re: A proposition for a conditional loop. Tim Streater <timstreater@greenbee.net> - 2019-09-27 13:41 +0100
                                          Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 06:01 -0700
                                            Re: A proposition for a conditional loop. Tim Streater <timstreater@greenbee.net> - 2019-09-27 14:03 +0100
                                          Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-27 19:23 +0100
                                            Re: A proposition for a conditional loop. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-09-27 12:06 -0700
                                              Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-28 14:43 +0100
                            Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-25 21:47 +0100
                              Re: A proposition for a conditional loop. John G Harris <niam@jghnorth.org.uk.invalid> - 2019-09-26 10:49 +0100
                    Re: A proposition for a conditional loop. "R.Wieser" <address@not.available> - 2019-09-25 17:07 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#37406

Den torsdag 26 september 2019 kl. 11:48:58 UTC+2 skrev John G Harris:
> On Wed, 25 Sep 2019 12:19:57 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
> >Den onsdag 25 september 2019 kl. 20:18:11 UTC+2 skrev John G Harris:
> >> On Wed, 25 Sep 2019 10:26:07 -0700 (PDT), Jonas Thörnvall
> >> <jonas.thornvall@gmail.com> wrote:
> >> 
> >>   <snip>
> >> >while not equal
> >> >
> >> >It is just an opinion but it really matter if there is alot of compound statements in the condition.
> >> 
> >> 
> >>   while not equal or not found
> >> 
> >> or you will get into trouble one day.
> >
> >until equal or EOF in the old days, when we had less memory.
> 
> So you agree that there are two reasons for the scan to stop. 
> 
> You want a new kind of statement that lets you code just one of them.
> You want the compiler to write the other code for you. Now tell us how
> you think the compiler will know what needs to be done ?
> 
>   John

Of course there could be any number of argument, but the ones in my code would do just fine with **ONE** if you used do until.

  function pianoSCROLL(){
	nbrOfEV = track[rectrack].midiMess.length;
	var x=0;
	 while (x<nbrOfEV){
	   midiEv=x;
	   //INSIDE KEY PRESSED
	   if(track[rectrack].midiMess[midiEv].data0==NOTE_ON && keyreleased[midiEv]==false){
		  console.log("Pressed Key");
		  ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
		  ctm.fillRect(50,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), rightSide[midiEv],keyHeight);
		  //When ***A NEW*** key pressed a startvoint relative the scrollbar created ***FRONTOFFSET***
		  if(FRONTOFFSET[midiEv]==0) {FRONTOFFSET[midiEv]=scrollBarPos;}
		  rightSide[midiEv]=scrollBarPos-FRONTOFFSET[midiEv];
		 
		     
	   } 
	   //INSIDE KEY RELEASED
	   else if(track[rectrack].midiMess[midiEv].data0==NOTE_OFF && keyreleased[midiEv]==false){
		keyreleased[midiEv]=true;	
		for (var q=midiEv-1;q>=0;q--){
			if(track[rectrack].midiMess[q].data1==track[rectrack].midiMess[midiEv].data1) { 
			console.log("midiEV data1"+track[rectrack].midiMess[midiEv].data1);
			barLength[q]=rightSide[q]-50;
			BACKOFFSET[q]=FRONTOFFSET[q]+barLength[q];
			keyreleased[q]=true;
		    break;
    		}
		}
		
       } 
	   
	   //INSIDE MOVE BAR
	   else if(track[rectrack].midiMess[midiEv].data0==NOTE_ON && keyreleased[midiEv]==true){
		z=midiEv+1;
	    while(z<nbrOfEV){
		  if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
			ctm.fillStyle = "#000a4d";
			ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
			ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
			ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
			
			break;
		  }
		z++;
		}
	   } 
	  x++;
	 }
	 
	}

[toc] | [prev] | [next] | [standalone]

#37412

On Thu, 26 Sep 2019 04:38:59 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>Of course there could be any number of argument, but the ones in my code would do just fine with **ONE** if you used do until.
  <snip>

  z=midiEv;
  do
    ++z;
  until
    (
      ( z == nbrOfEV ) ||
      ( track[rectrack].midiMess[z].data1 ==
        track[rectrack].midiMess[midiEv].data1 )
    );

  /* then do */

  if (z < nbrOfEV)
    {
      ctm.fillStyle = "#000a4d";
      ...
    }

Still looks like *TWO* conditions to me.

  John

[toc] | [prev] | [next] | [standalone]

#37413

Den torsdag 26 september 2019 kl. 19:05:50 UTC+2 skrev John G Harris:
> On Thu, 26 Sep 2019 04:38:59 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >Of course there could be any number of argument, but the ones in my code would do just fine with **ONE** if you used do until.
>   <snip>
> 
>   z=midiEv;
>   do
>     ++z;
>   until
>     (
>       ( z == nbrOfEV ) ||
>       ( track[rectrack].midiMess[z].data1 ==
>         track[rectrack].midiMess[midiEv].data1 )
>     );
> 
>   /* then do */
> 
>   if (z < nbrOfEV)
>     {
>       ctm.fillStyle = "#000a4d";
>       ...
>     }
> 
> Still looks like *TWO* conditions to me.
> 
>   John

No i actually was talking about the inner loops in second and third "main condition" of the if else they would benefit from "du until".

They would not need if condition, it would be in the do until loop statement.
Right?

[toc] | [prev] | [next] | [standalone]

#37426

On Thu, 26 Sep 2019 10:54:59 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>No i actually was talking about the inner loops in second and third "main condition" of the if else they would benefit from "du until".
>
>They would not need if condition, it would be in the do until loop statement.
>Right?

After posting more than 10 articles you still haven't shown us an
example of what code you would like to be able to use.

Meanwhile, I have given you an example that is simple,
straightforward, and clean. It works unchanged in C, C++, C#, and Java
as well as in all versions of ECMAScript.

You would do better to follow my example and stop complaining that
there isn't another way to do it.

  John

[toc] | [prev] | [next] | [standalone]

#37427

On Friday, 27 September 2019 10:06:07 UTC+1, John G Harris  wrote.

Is there any form of loop which CANNOT be coded in JavaScript as
   for (A;B;C) { D }
in which A, B, C, D are suitable script segments, with conditional break and continue allowed in at least D?


-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#37429

Den fredag 27 september 2019 kl. 11:06:07 UTC+2 skrev John G Harris:
> On Thu, 26 Sep 2019 10:54:59 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >No i actually was talking about the inner loops in second and third "main condition" of the if else they would benefit from "du until".
> >
> >They would not need if condition, it would be in the do until loop statement.
> >Right?
> 
> After posting more than 10 articles you still haven't shown us an
> example of what code you would like to be able to use.
> 
> Meanwhile, I have given you an example that is simple,
> straightforward, and clean. It works unchanged in C, C++, C#, and Java
> as well as in all versions of ECMAScript.
> 
> You would do better to follow my example and stop complaining that
> there isn't another way to do it.
> 
>   John
   
do until (track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1)) {z++;} then {
 ctm.fillStyle = "#000a4d";
 ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
 ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
  ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);

}

[toc] | [prev] | [next] | [standalone]

#37430

Den fredag 27 september 2019 kl. 14:32:11 UTC+2 skrev Jonas Thörnvall:
> Den fredag 27 september 2019 kl. 11:06:07 UTC+2 skrev John G Harris:
> > On Thu, 26 Sep 2019 10:54:59 -0700 (PDT), Jonas Thörnvall
> > <jonas.thornvall@gmail.com> wrote:
> > 
> >   <snip>
> > >No i actually was talking about the inner loops in second and third "main condition" of the if else they would benefit from "du until".
> > >
> > >They would not need if condition, it would be in the do until loop statement.
> > >Right?
> > 
> > After posting more than 10 articles you still haven't shown us an
> > example of what code you would like to be able to use.
> > 
> > Meanwhile, I have given you an example that is simple,
> > straightforward, and clean. It works unchanged in C, C++, C#, and Java
> > as well as in all versions of ECMAScript.
> > 
> > You would do better to follow my example and stop complaining that
> > there isn't another way to do it.
> > 
> >   John
>    
> do until (track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1)) {z++;} then {
>  ctm.fillStyle = "#000a4d";
>  ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
>  ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
>   ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
> 
> }

compare with

   while(z<nbrOfEV){
                  if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
                        ctm.fillStyle = "#000a4d";
                        ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
                        ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
                        ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
                        
                        break;
                  }
                z++;
                }
           }

[toc] | [prev] | [next] | [standalone]

#37437

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
<cut>
> compare with
>
>    while(z<nbrOfEV){
>                   if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
>                         ctm.fillStyle = "#000a4d";
>                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
>                         ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
>                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
>                         
>                         break;
>                   }
>                 z++;
>                 }
>            }

One way to do a search for an element is with Array.prototype.find or
similar, but the logic of your example looks very odd, so this soer of
search may not be what you are really doing.

The odd part is that the block of code does not use the element found
but the one being tested against.  If midiEv is < nbrOfEV, then a
matching z certainly will be found.  It might be some z < midiEv but it
will be no later than when z == midiEv.  But in both cases (z < midiEv
and z == midiEv), the body of the 'if' does the same thing.  So,
provided z starts at 0, you are really only testing

  if (midiEv < nbrOfEV) { ... }

Whats more, if nbrOfEV is what is sounds like (the size of the array)
then that test will always be true and you don't need any of this code.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#37438

Den fredag 27 september 2019 kl. 21:23:35 UTC+2 skrev Ben Bacarisse:
> Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
> <cut>
> > compare with
> >
> >    while(z<nbrOfEV){
> >                   if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
> >                         ctm.fillStyle = "#000a4d";
> >                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
> >                         ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
> >                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
> >                         
> >                         break;
> >                   }
> >                 z++;
> >                 }
> >            }
> 
> One way to do a search for an element is with Array.prototype.find or
> similar, but the logic of your example looks very odd, so this soer of
> search may not be what you are really doing.
> 
> The odd part is that the block of code does not use the element found
> but the one being tested against.  If midiEv is < nbrOfEV, then a
> matching z certainly will be found.  It might be some z < midiEv but it
> will be no later than when z == midiEv.  But in both cases (z < midiEv
> and z == midiEv), the body of the 'if' does the same thing.  So,
> provided z starts at 0, you are really only testing
> 
>   if (midiEv < nbrOfEV) { ... }
> 
> Whats more, if nbrOfEV is what is sounds like (the size of the array)
> then that test will always be true and you don't need any of this code.
> 
> -- 
> Ben.

I think you understand the problem wrong Ben but i am not sure, z and nbrOfEv is just positions in a stack/array.

midimess[z] and midimess[nbrOfEv] is the elements "data1" to match.
I do use z to position myself favourly in array because i know "data1" note on will always come before note off. "data1 is the note value" can hold boths.Then i simply increment z to both match.

So in the sequense of note values a data/note on *must* be followd of a data/note off.

I am not sure i think you missunderstood ask John he seem to understand the element match and increment.

Or think of yourself positioning yourself favourly in the stack "the on note" and looking forward "for the off note"

I paint alot of notes and starting with key push one, but that does not mean that key push two is the corresponding off note. You can push alot of keys between and of course you can press same key on and off more then once.

But one thing is true for a ceratain note lets say A! pushed/note on, that specific note A1 must have a note off following.

Basicly it is the same like have 128 light switches that you can press in any order. One thing always remain true you can not turn it on same switch twice "then something really wrong", you have to turn it off before you turn it on again.

I hope that explain what i am doing "recording keystrokes" and "key releases" in realtime and rendering the length of them relative the clock metronome using "bars" of the beat per minute length.

[toc] | [prev] | [next] | [standalone]

#37440

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:

> Den fredag 27 september 2019 kl. 21:23:35 UTC+2 skrev Ben Bacarisse:
>> Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
>> <cut>
>> > compare with
>> >
>> >    while(z<nbrOfEV){
>> >                   if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
>> >                         ctm.fillStyle = "#000a4d";
>> >                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
>> >                         ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
>> >                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
>> >                         
>> >                         break;
>> >                   }
>> >                 z++;
>> >                 }
>> >            }
>> 
>> One way to do a search for an element is with Array.prototype.find or
>> similar, but the logic of your example looks very odd, so this soer of
>> search may not be what you are really doing.
>> 
>> The odd part is that the block of code does not use the element found
>> but the one being tested against.  If midiEv is < nbrOfEV, then a
>> matching z certainly will be found.  It might be some z < midiEv but it
>> will be no later than when z == midiEv.  But in both cases (z < midiEv
>> and z == midiEv), the body of the 'if' does the same thing.  So,
>> provided z starts at 0, you are really only testing
>> 
>>   if (midiEv < nbrOfEV) { ... }

This is not quite right, but there's not enough detail to be sure what
you intended.  You certainly don't need any loop when midiEv < nbrOfEV,
but whether you need one when midiEv >= nbrOfEV is not clear.

<cut>
> I am not sure i think you missunderstood ask John he seem to
> understand the element match and increment.

I don't think you understand what John wrote.  It looked to me like his
answer was somewhat tongue-in-cheek.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#37441

Den fredag 27 september 2019 kl. 23:05:36 UTC+2 skrev Ben Bacarisse:
> Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
> 
> > Den fredag 27 september 2019 kl. 21:23:35 UTC+2 skrev Ben Bacarisse:
> >> Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
> >> <cut>
> >> > compare with
> >> >
> >> >    while(z<nbrOfEV){
> >> >                   if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
> >> >                         ctm.fillStyle = "#000a4d";
> >> >                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-5,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
> >> >                         ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
> >> >                         ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
> >> >                         
> >> >                         break;
> >> >                   }
> >> >                 z++;
> >> >                 }
> >> >            }
> >> 
> >> One way to do a search for an element is with Array.prototype.find or
> >> similar, but the logic of your example looks very odd, so this soer of
> >> search may not be what you are really doing.
> >> 
> >> The odd part is that the block of code does not use the element found
> >> but the one being tested against.  If midiEv is < nbrOfEV, then a
> >> matching z certainly will be found.  It might be some z < midiEv but it
> >> will be no later than when z == midiEv.  But in both cases (z < midiEv
> >> and z == midiEv), the body of the 'if' does the same thing.  So,
> >> provided z starts at 0, you are really only testing
> >> 
> >>   if (midiEv < nbrOfEV) { ... }

I do not even get what you are after?
Each drawcycle "animation call" i draw out all notes "played so far".

"will be no later than when z == midiEv" i am totally lost why do you compare two indexes???? It does not make sense? It is the elements that should be same  

If i have the note on, fastest possible way is to increment from IT 
***and find corresponding note off***

If i have the note off fastest possible way is to decrease from IT 
***and find corresponding note on***

> 
> This is not quite right, but there's not enough detail to be sure what
> you intended. 

Read above, what is unclear?

> You certainly don't need any loop when midiEv < nbrOfEV,
> but whether you need one when midiEv >= nbrOfEV is not clear.
> 
> <cut>
> > I am not sure i think you missunderstood ask John he seem to
> > understand the element match and increment.
> 
> I don't think you understand what John wrote.  It looked to me like his
> answer was somewhat tongue-in-cheek.

????? 
I must be totally lost what you talk about it does not make sense to me.

> -- 
> Ben.

Well if you found a faster way to write out the notes using loops and sequential conditions "in a coherent way on screen", congratulations then you beat me. But i want to see it.

I'm still not sure what you mean and suggest, because what you say simply do not make any sense, what problem do you see?

Should we solve it by semantics
While there is notes
Check:
If a note pressed "marked for render as not released"
else  check if that note ***OFF*** is a release "find coreresponding **ON** and mark note on as released boolean. 
else  check if that note ***ON*** is already released "find corresponding **OFF**

I have a feeling that you think that second and third part should be one?
But then you would have to "find" it every time. That does not make sense to me?

There must be a separate find?

As i said i am lost what you mean, but if you guys can make a faster logic route i am interested how that file look.
Because i guess you suggest that i do something unnecessary? 
Well could be but i do not think so.

Beyond the improvement that John suggested, i really would love shortcuts in the logic if possible.

    function pianoSCROLL(){
	nbrOfEV = track[rectrack].midiMess.length;
	var x=0;
	 while (x<nbrOfEV){
	   midiEv=x;
	   //INSIDE KEY PRESSED
	   if(track[rectrack].midiMess[midiEv].data0==NOTE_ON && keyreleased[midiEv]==false){
		  ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
		  ctm.fillRect(50,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), rightSide[midiEv],keyHeight);
		  //When ***A NEW*** key pressed a startvoint relative the scrollbar created ***FRONTOFFSET***
		  if(FRONTOFFSET[midiEv]==0) {FRONTOFFSET[midiEv]=scrollBarPos;}
		  rightSide[midiEv]=scrollBarPos-FRONTOFFSET[midiEv];
       }
       //INSIDE KEY RELEASED
	   else if(track[rectrack].midiMess[midiEv].data0==NOTE_OFF && keyreleased[midiEv]==false){
		keyreleased[midiEv]=true;	
		for (var q=midiEv-1;q>=0;q--){
			if(track[rectrack].midiMess[q].data1==track[rectrack].midiMess[midiEv].data1) { 
				barLength[q]=rightSide[q]-50;
				BACKOFFSET[q]=FRONTOFFSET[q]+barLength[q];
				keyreleased[q]=true;
				break;
    		}
		}
       } 
	   //INSIDE MOVE BAR
	   else if(track[rectrack].midiMess[midiEv].data0==NOTE_ON && keyreleased[midiEv]==true){
		z=midiEv+1;
	    while(z<nbrOfEV){
		  if(track[rectrack].midiMess[z].data1==track[rectrack].midiMess[midiEv].data1){
			ctm.fillStyle = "#000a4d";
			ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv]-6,(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,barLength[midiEv]+50 ,keyHeight+2);
			ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
			ctm.fillRect(scrollBarPos-BACKOFFSET[midiEv],(PistartX+keyHeight*88)-(keyHeight*(track[rectrack].midiMess[midiEv].data1-8)), barLength[midiEv]+50,keyHeight);
			break;
		  }
		z++;
		}
	   } 
	  x++;
	 }
	}

[toc] | [prev] | [next] | [standalone]

#37443

Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
> Den fredag 27 september 2019 kl. 23:05:36 UTC+2 skrev Ben Bacarisse:
<cut>
> I do not even get what you are after?

That's OK.  If what I said was not helpful just ignore it.  I was in two
minds about saying anything in the first place.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#37445

Den lördag 28 september 2019 kl. 01:16:31 UTC+2 skrev Ben Bacarisse:
> Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
> > Den fredag 27 september 2019 kl. 23:05:36 UTC+2 skrev Ben Bacarisse:
> <cut>
> > I do not even get what you are after?
> 
> That's OK.  If what I said was not helpful just ignore it.  I was in two
> minds about saying anything in the first place.
> 
> -- 
> Ben.

Well i really want to know because, maybe it is me that do not get it?
If i am doing something unnecessary or really stupid of course i want to know.

Like try to use a static canvas position for a length for a year or so......

[toc] | [prev] | [next] | [standalone]

#37448

Jonas,

> Well i really want to know because, maybe it is me that do not get it?

Yes, its you.  Definitily.   Multiple people have tried to explain, and in 
multiple ways.

> If i am doing something unnecessary or really stupid of course i
> want to know.

I tried to help you understand, but you refused to help me understand what 
you where actually after.   No matter what I asked from you, you 
refused/ignored it.   And no questions back asking for clarification of what 
I asked for either. :-(


Even now you are throwing big blobs of - fully unrelated to the problem ! - 
comparisions and code into your messages, and expect us to dig thru it. 
Thats not how its done I'm afraid.  For multiple reasons.

One of them is that in the process of trimming of your question and/or 
examples of al the superfluous stuff you will often find the answer 
yourself.

The below is an impression of what I /think/ you might have been after, but 
as you bluntly refused to provide any specifics I could easily be wrong :

do {
   code1
} until (condition1, condition2} then {
  code2
}

MIND YOU: This is NOT valid JS !

In the above code1 should execute until either condition1 or contition2 is 
true, and code2 should only execute when condition2 is true.

If that is so than the above would be the frankenchild of that "do until" 
and "if" you are after.

Also, you already have posted code which does what you want, and several 
examples where posted that /also/ do what you want.   And I've, again, not 
seen anything explaining to why those code examples where not good enough 
for you. :-(

And by the way: why stop with just /one/ extra loop condition ?    Why not 
go for any abitrary larger number ?   I mean, maybe there are multiple 
things you could be searching for, each with its own block of code that 
needs to be executed for it ?     You know, like this:

do {
   code1
} until (condition1, condition2, condition3, condition4 , ...} then {
  code2
}then {
  code3
}then {
  code4
} ...

MIND YOU: This isn't valid JS either.

Same here, code2 is only executed when condition2 is true, code3 is only 
executed when condition3 is true, etc.


Or maybe, just /maybe/ using of what JS already has combined with the code 
you posted in your message of 25/09 15:10 (though I've removed the cruft) 
would be enough :

i = 1;
while(i < 5) {
  if (condition2) {
     code2;
     break;
  }elseif (condition3) {
     code3;
     break;
  }elseif (condition4) {
     code4;
     break;
  }
  i++;
}

Remark: in the above "i < 5" equals "condition1", and "i++" equals "code1", 
as in the (non-working!) example above it.

Notice how simple this code looks ?   Even with multiple conditions that all 
exit the loop ?    This actually works (if you put actual conditions and 
code into it ofcourse).

And yes, it could become looking ugly with all your actual comparisions and 
code plugged into it (and just maybe /that/ is what your problem is all 
about ...).  Thats not to be helped - though you could put some 
strategically placed blank, or even comment lines into it, visually grouping 
conditions and following codeblocks.

Remark: The above "while" loop could also be done with a "for" loop (would 
probably even look better).


And even though the above (non-working and/or working examples) might not be 
/exactly/ what you where after or thinking of, it should be a hint to what 
your posted examples should look like - together with an explanation 
ofcourse.

***** Helping is a two-way street ! *****

To enable us to help you you will need to help us understand the problem you 
have.   If you cannot do that you should first sit back and think about the 
problem description itself.  Without it everything becomes guesswork - on 
both your and our sides.    And for us that becomes old very fast. (as you 
might have noticed, I'm not the only one who got irritated by the lack of 
clear language).

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#37450

Den lördag 28 september 2019 kl. 17:28:54 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > Well i really want to know because, maybe it is me that do not get it?
> 
> Yes, its you.  Definitily.   Multiple people have tried to explain, and in 
> multiple ways.
> 
> > If i am doing something unnecessary or really stupid of course i
> > want to know.
> 
> I tried to help you understand, but you refused to help me understand what 
> you where actually after.   No matter what I asked from you, you 
> refused/ignored it.   And no questions back asking for clarification of what 
> I asked for either. :-(
> 
> 
> Even now you are throwing big blobs of - fully unrelated to the problem ! - 
> comparisions and code into your messages, and expect us to dig thru it. 
> Thats not how its done I'm afraid.  For multiple reasons.
> 
> One of them is that in the process of trimming of your question and/or 
> examples of al the superfluous stuff you will often find the answer 
> yourself.
> 
> The below is an impression of what I /think/ you might have been after, but 
> as you bluntly refused to provide any specifics I could easily be wrong :
> 
> do {
>    code1
> } until (condition1, condition2} then {
>   code2
> }
> 
> MIND YOU: This is NOT valid JS !
> 
> In the above code1 should execute until either condition1 or contition2 is 
> true, and code2 should only execute when condition2 is true.
> 
> If that is so than the above would be the frankenchild of that "do until" 
> and "if" you are after.
> 
> Also, you already have posted code which does what you want, and several 
> examples where posted that /also/ do what you want.   And I've, again, not 
> seen anything explaining to why those code examples where not good enough 
> for you. :-(
> 
> And by the way: why stop with just /one/ extra loop condition ?    Why not 
> go for any abitrary larger number ?   I mean, maybe there are multiple 
> things you could be searching for, each with its own block of code that 
> needs to be executed for it ?     You know, like this:
> 
> do {
>    code1
> } until (condition1, condition2, condition3, condition4 , ...} then {
>   code2
> }then {
>   code3
> }then {
>   code4
> } ...
> 
> MIND YOU: This isn't valid JS either.
> 
> Same here, code2 is only executed when condition2 is true, code3 is only 
> executed when condition3 is true, etc.
> 
> 
> Or maybe, just /maybe/ using of what JS already has combined with the code 
> you posted in your message of 25/09 15:10 (though I've removed the cruft) 
> would be enough :
> 
> i = 1;
> while(i < 5) {
>   if (condition2) {
>      code2;
>      break;
>   }elseif (condition3) {
>      code3;
>      break;
>   }elseif (condition4) {
>      code4;
>      break;
>   }
>   i++;
> }
> 
> Remark: in the above "i < 5" equals "condition1", and "i++" equals "code1", 
> as in the (non-working!) example above it.
> 
> Notice how simple this code looks ?   Even with multiple conditions that all 
> exit the loop ?    This actually works (if you put actual conditions and 
> code into it ofcourse).
> 
> And yes, it could become looking ugly with all your actual comparisions and 
> code plugged into it (and just maybe /that/ is what your problem is all 
> about ...).  Thats not to be helped - though you could put some 
> strategically placed blank, or even comment lines into it, visually grouping 
> conditions and following codeblocks.
> 
> Remark: The above "while" loop could also be done with a "for" loop (would 
> probably even look better).
> 
> 
> And even though the above (non-working and/or working examples) might not be 
> /exactly/ what you where after or thinking of, it should be a hint to what 
> your posted examples should look like - together with an explanation 
> ofcourse.
> 
> ***** Helping is a two-way street ! *****
> 
> To enable us to help you you will need to help us understand the problem you 
> have.   If you cannot do that you should first sit back and think about the 
> problem description itself.  Without it everything becomes guesswork - on 
> both your and our sides.    And for us that becomes old very fast. (as you 
> might have noticed, I'm not the only one who got irritated by the lack of 
> clear language).
> 
> Regards,
> Rudy Wieser

You just don't understand the problem Rudy that is a fact.

[toc] | [prev] | [next] | [standalone]

#37451

Jonas,

> You just don't understand the problem Rudy that is a fact.

And I've not seen you describe that problem, and thats also a fact.

And pardon me saying so, but without a problem description there isn't much 
than anyone can-or-cannot understand, is there ? /s


Maybe you should just sit down somewhere, and TRY TO DESCRIBE THE PROBLEM. 
First to yourself, and, after you figured it out, to us. As long as you 
refuse to do that there is not much (if anything) any of us can do.

But yes, you're /absolutily right/ : I have /no/ idea what your problem is. 
I also have no idea what your "proposition for a conditional loop" is or 
should look like as JS code - as you have not penned down anything about 
that either ...

Kiddo, you've got some work to do.   Get on it I would say. 'Cause trying to 
make us play a "what is my problem - and than the solution to it" game is 
not really working.  That much should be obvious to you.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#37452

In article <qmofh1$1r3m$1@gioia.aioe.org>, R.Wieser
<address@not.available> wrote:

>Jonas,
>
>> You just don't understand the problem Rudy that is a fact.
>
>And I've not seen you describe that problem, and thats also a fact.
>
>And pardon me saying so, but without a problem description there isn't much 
>than anyone can-or-cannot understand, is there ? /s
>
>
>Maybe you should just sit down somewhere, and TRY TO DESCRIBE THE PROBLEM. 
>First to yourself, and, after you figured it out, to us. As long as you 
>refuse to do that there is not much (if anything) any of us can do.
>
>But yes, you're /absolutily right/ : I have /no/ idea what your problem is. 
>I also have no idea what your "proposition for a conditional loop" is or 
>should look like as JS code - as you have not penned down anything about 
>that either ...
>
>Kiddo, you've got some work to do.   Get on it I would say. 'Cause trying to 
>make us play a "what is my problem - and than the solution to it" game is 
>not really working.  That much should be obvious to you.

An excellent summary of why trying to help Jonas is a waste of time.

-- 
Lady Astor: "Winston, you are drunk!"
Churchill: "And you, madam, are ugly. But I shall be sober in the morning."

[toc] | [prev] | [next] | [standalone]

#37462

Den lördag 28 september 2019 kl. 22:24:11 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > You just don't understand the problem Rudy that is a fact.
> 
> And I've not seen you describe that problem, and thats also a fact.
> 
> And pardon me saying so, but without a problem description there isn't much 
> than anyone can-or-cannot understand, is there ? /s
> 
> 
> Maybe you should just sit down somewhere, and TRY TO DESCRIBE THE PROBLEM. 
> First to yourself, and, after you figured it out, to us. As long as you 
> refuse to do that there is not much (if anything) any of us can do.
> 
> But yes, you're /absolutily right/ : I have /no/ idea what your problem is. 
> I also have no idea what your "proposition for a conditional loop" is or 
> should look like as JS code - as you have not penned down anything about 
> that either ...
> 
> Kiddo, you've got some work to do.   Get on it I would say. 'Cause trying to 
> make us play a "what is my problem - and than the solution to it" game is 
> not really working.  That much should be obvious to you.
> 
> Regards,
> Rudy Wieser

The problem was the use of "extra condition" and "break". But as John showed it isn't necessary. Since it is code for realtime rendering of notes, you do not want unnecessary conditions.

=======================
John write :

  while
    ( track[rectrack].midiMess[z].data1!=
      track[rectrack].midiMess[midiEv].data1) )
    {z++;}
 
  {
   ctm.fillStyle = "#000a4d";
   ctm.fillRect
     (
       scrollBarPos-BACKOFFSET[midiEv]-5,
       (PistartX+keyHeight*88)-
         (keyHeight*(track[rectrack].midiMess[midiEv].data1-8))-1,
       barLength[midiEv]+50 ,keyHeight+2
     );
    ctm.fillStyle = pcolor[track[rectrack].midiMess[midiEv].data1];
    ctm.fillRect
      (
        scrollBarPos-BACKOFFSET[midiEv],
        (PistartX+keyHeight*88)-
          (keyHeight*(track[rectrack].midiMess[midiEv].data1-8)),
        barLength[midiEv]+50,keyHeight
      );
  }

=======================

[toc] | [prev] | [next] | [standalone]

#37463

Jonas,

> The problem was the use of "extra condition" and "break".

No, it wasn't.   Your code as posted at 25/09 15:10 (starting with "Den 
onsdag 25 september 2019 kl. 15:04:26 UTC+2 skrev R.Wieser") ran fine /with/ 
them, and all John gave you is a rather inconsequential (but not fully) 
change.

As for "extra" ?  Are you sure ?  If I may take the intialisation of the "z" 
you're using in the loop still being "z=midiEv+1;" than there might be a 
possibility that your code will crash.   Just hope that "midiEv" will 
/allways/ be lower than "nbrOfEV".   If not ... Indexing beyond the end of 
the array -> Illegal index error.  Crash.

/Your/ origional code on the other hand has no problem with that ...

Remember that paul said that he made a number of assumptions ?   Well, the 
above is one of them.   Are you sure /you/ can make such an assumption ?

In short, you have spend a dozen of messages complaining about an 
undescribed "problem" which might well be none at all, but instead might 
just keep your program from crashing - and are only now pointing at John's 
example code as your solution.

In other words: /you/ still have not (tried to) described the problem, but 
instead evading it by claiming someone else already posted it two days ago 
(I hope you didn't think I wouldn't notice it).

And thats fully besides the fact that none of the dozen messages you posted 
has had ZERO to do with the threads title. :-((

Regards,
Rudy Wieser

P.s.
I'm looking forward to your next thread.  Lets see if you actually learned 
something here (in this thread), or if you wil continue your "guess my 
problem" game.

[toc] | [prev] | [next] | [standalone]

#37464

Den söndag 29 september 2019 kl. 18:33:58 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > The problem was the use of "extra condition" and "break".
> 
> No, it wasn't.   Your code as posted at 25/09 15:10 (starting with "Den 
> onsdag 25 september 2019 kl. 15:04:26 UTC+2 skrev R.Wieser") ran fine /with/ 
> them, and all John gave you is a rather inconsequential (but not fully) 
> change.
> 
> As for "extra" ?  Are you sure ?  If I may take the intialisation of the "z" 
> you're using in the loop still being "z=midiEv+1;" than there might be a 
> possibility that your code will crash.   Just hope that "midiEv" will 
> /allways/ be lower than "nbrOfEV".   If not ... Indexing beyond the end of 
> the array -> Illegal index error.  Crash.

You do not seem to understand the logic, "it says keyreleased" that means note off must been pressed, so there will be a event z-+

> 
> /Your/ origional code on the other hand has no problem with that ...

No because i tried to fix the rendering so i did not care about the logic.

> Remember that paul said that he made a number of assumptions ?   Well, the 
> above is one of them.   Are you sure /you/ can make such an assumption ?

Of course one can always loop the event from start to end, but it isn't smart.

> In short, you have spend a dozen of messages complaining about an 
> undescribed "problem" which might well be none at all, but instead might 
> just keep your program from crashing - and are only now pointing at John's 
> example code as your solution.

Yeah the problem was i thought do until without a negation was more easy to read, but as John showed no extra condition and no break needed "even using while".


> 
> In other words: /you/ still have not (tried to) described the problem, but 
> instead evading it by claiming someone else already posted it two days ago 
> (I hope you didn't think I wouldn't notice it).
> 
> And thats fully besides the fact that none of the dozen messages you posted 
> has had ZERO to do with the threads title. :-((

Yes i proposed a loop logic without negations "do until" to avoid the extra "if" and "break" that "will" be using a for loop, it turned out that when using while no "if" condition and "break" needed "but you can't avoid the negation statement.

While not equal, i simply do not like it i know it is "probably" just semantics, but the readability of code suffers from it
I prefer do until equal, it is more straightforward.
 

> Regards,
> Rudy Wieser
> 
> P.s.
> I'm looking forward to your next thread.  Lets see if you actually learned 
> something here (in this thread), or if you wil continue your "guess my 
> problem" game.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web