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 3 of 3 — ← Prev page 1 2 [3]

#37465

On Sun, 29 Sep 2019 09:58:18 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:


  <snip>
>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.

You can say
  if it's not the one you want then move to the next one.

Or you can say
  find the one you want somehow, and, by the way, here's how to move
to the next one.

The first says what the computer must do. I reckon it's easier to see
that it's right, easier to notice that the starting value needs to be
right, and easier to notice that you mustn't fall off the end (or must
check that that can't happen).

  John

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

#37466

Jonas,

> You do not seem to understand the logic

You still don't get it do you ? I DON'T CARE.  I'm not spending /any/ time 
trying to dig thru whatever humongous code you post in search for any logic 
you might have put in there.  If-and-when there is /any/ logic involved I 
expect YOU to tell us.

> "it says keyreleased"

Where ?   Not in your last code as present in the message I responded to.

> so there will be a event z-+

Good for you.   Just wanted to warn you about the possibility of the code 
(that I was able to see) being picky.

> but as John showed no extra condition and no break needed "even using 
> while".

:-) I think he showed you a bit more.   Where you had two comparisions (one 
for down, one for up) you now have none.

> Yes i proposed a loop logic without negations

No you didn't.   Feel free to point us to where you described that new loop 
and an example of its usage though.   And no, coughing up a few words with 
arrows from one to the other is not any kind of explanation or example. :-\

> While not equal, i simply do not like it i know it is "probably" just
> semantics, but the readability of code suffers from it

That is why you have remarks at your disposal.  When stuff gets hairy you 
can (and should!) always put a discription next to that code.  As I already 
said, use them.

But, I'm signing off.  I've said what I wanted to say.  Lets see if you do 
something with it.

Regards,
Rudy Wieser

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

#37471

Den söndag 29 september 2019 kl. 21:02:22 UTC+2 skrev R.Wieser:
> Jonas,
> 
> > You do not seem to understand the logic
> 
> You still don't get it do you ? I DON'T CARE.  I'm not spending /any/ time 
> trying to dig thru whatever humongous code you post in search for any logic 
> you might have put in there.  If-and-when there is /any/ logic involved I 
> expect YOU to tell us.
> 
> > "it says keyreleased"
> 
> Where ?   Not in your last code as present in the message I responded to.
> 
> > so there will be a event z-+
> 
> Good for you.   Just wanted to warn you about the possibility of the code 
> (that I was able to see) being picky.
> 
> > but as John showed no extra condition and no break needed "even using 
> > while".
> 
> :-) I think he showed you a bit more.   Where you had two comparisions (one 
> for down, one for up) you now have none.
> 
> > Yes i proposed a loop logic without negations
> 
> No you didn't.   Feel free to point us to where you described that new loop 
> and an example of its usage though.   And no, coughing up a few words with 
> arrows from one to the other is not any kind of explanation or example. :-\
>
I start to think something seriously wrong with you Rudy. my First post.

step=1;
x="something"
do until (this equal that) { inc x, step}
then do { whatever }


 
> > While not equal, i simply do not like it i know it is "probably" just
> > semantics, but the readability of code suffers from it
> 
> That is why you have remarks at your disposal.  When stuff gets hairy you 
> can (and should!) always put a discription next to that code.  As I already 
> said, use them.
> 
> But, I'm signing off.  I've said what I wanted to say.  Lets see if you do 
> something with it.
> 
> Regards,
> Rudy Wieser

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

#37446

On Fri, 27 Sep 2019 22:05:27 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>Jonas Thörnvall <jonas.thornvall@gmail.com> writes:
  <snip>
>> 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.

Tongue-in-cheek : No
Exasperated     : Yes

  John

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

#37439

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.

Well i remember solving some hard problem in the late 70's-80's i think it was related to factoring.

https://tl.net/blogs/67008-light-bulbs-math-problem

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

#37431

In article <aa338903-0be3-4046-bdf0-866919d78d0b@googlegroups.com>,
Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:

>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)-(keyHeig
>ht*(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);
>
>}

Stop posting unreadable bollocks you fool.

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

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

#37432

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);
> 
> }

Now you may think that the do until require also less then nmbrOfEv but that condition already satisfied. There is guaranteed to be a match. Because of the outer conditions.

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

#37433

In article <dc9ed013-9388-4f53-b076-00dc344a1a49@googlegroups.com>,
Jonas Thörnvall <jonas.thornvall@gmail.com> wrote:

>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)-(keyH
>>  eight*(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)-(keyHe
>>   ight*(track[rectrack].midiMess[midiEv].data1-8)),
>>   barLength[midiEv]+50,keyHeight);
>> 
>> }
>
>Now you may think that the do until require also less then nmbrOfEv but that
>condition already satisfied. There is guaranteed to be a match. Because of
>the outer conditions.

I don't think anything about it, because it is unreadable. No one is
going to read this rubbish. Try a simple example instead.

-- 
What power have you got?
Where did you get it from?
In whose interests do you use it?
To whom are you accountable?
How do we get rid of you?

Tony Benn

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

#37435

On Fri, 27 Sep 2019 05:32:05 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

  <snip>
>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);
>
>}


=======================
You write :

  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
        );
    }


=======================
I 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
      );
  }

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

I deleted two words, replaced one word, and negated one operator.
I win.

  John

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

#37436

Den fredag 27 september 2019 kl. 20:23:45 UTC+2 skrev John G Harris:
> On Fri, 27 Sep 2019 05:32:05 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
>   <snip>
> >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);
> >
> >}
> 
> 
> =======================
> You write :
> 
>   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
>         );
>     }
> 
> 
> =======================
> I 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
>       );
>   }
> 
> =======================
> 
> I deleted two words, replaced one word, and negated one operator.
> I win.
> 
>   John

Great John! I think i will use that one instead of my if clause. It must be a gain without the If condition?

Well you already won when you showed me a faster way to do it with while, i like  it. I should come up with that solution myself.

How much faster will it be without the if clause is there a way to test?

Is the amount of work equal for finding, equal to as not equal to?
There could be a speed penalty for the not???

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

#37447

On Fri, 27 Sep 2019 12:06:48 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

   <snip>
>Is the amount of work equal for finding, equal to as not equal to?
>There could be a speed penalty for the not???

If they are strings then there can't be much difference between == and
!=. At worst, some browsers might take a nanosecond or so longer to do
one of them, but you don't know which.

  John

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

#37394

On Wed, 25 Sep 2019 19:18:05 +0100, John G Harris
<niam@jghnorth.org.uk.invalid> wrote:

>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

Oh dear! My translation into Jonasese went horribly wrong. That should
be 

  while not equal and not finished yet

>or you will get into trouble one day.

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

#37401

On Wed, 25 Sep 2019 21:47:16 +0100, John G Harris
<niam@jghnorth.org.uk.invalid> wrote:

>On Wed, 25 Sep 2019 19:18:05 +0100, John G Harris
><niam@jghnorth.org.uk.invalid> wrote:
>
>>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
>
>Oh dear! My translation into Jonasese went horribly wrong. That should
>be 

On second thoughts, my translation into Jonasese was very 
accurate : no-one could understand it.


>  while not equal and not finished yet
>
>>or you will get into trouble one day.

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

#37383

Jonas,

> Is one should use do until instead of.... while-> if -> break
> How hard can it be to understand?

Very, as those are just loose words to me.  Its the way /you/ give meaning 
to them is the question here.

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

I already mentioned that I have zero wish to try to remove crap from 
examples, hoping that I actually find what everything is about.  So, a big 
fat fail here too.   :-(

Also, your above example - even when I replace the whole 
useless-to-the-problem condition and contents of that the "if" with some 
token one and change the loopcounter variable to a common "i" - doesn't tell 
me, by a /long/ shot, what your problem is.    What is /wrong/ with that 
code ?   *THAT* is what you are supposed to be explaining.  What it 
currently does, and what (you think) it should do instead.

Besides, what you have there has /nothing/ to do with a "do until", so you 
lost me again in that regard. :-(

And to be blunt about it : from my POV it looks as if you are jumping from 
the heel onto the branch.

But, it looks like you keep yourself above actually  try to explain, even 
when explicitily asked (demanded in this case) to do so.  So be it.  But I 
told you what the result would be.  Goodbye.

Regards,
Rudy Wieser

[toc] | [prev] | [standalone]

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

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

csiph-web