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

Groups > comp.os.linux.advocacy > #465275 > unrolled thread

Re: The substantiation that -highhorse asked for

Back to article view | Back to comp.os.linux.advocacy

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-28 08:28 -0400
    Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 09:20 -0700
      Re: The substantiation that -highhorse asked for fr314159@gmail.com - 2018-08-28 11:27 -0700
        Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 11:39 -0700
        Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-29 09:46 -0400
      Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-28 14:52 -0400
        Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 12:20 -0700
    Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 17:21 +0000
      Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-28 14:46 -0400
        Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 19:14 +0000
          Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 12:30 -0700
            Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 20:09 +0000
              Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 13:58 -0700
                Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 21:16 +0000
                  Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 14:31 -0700
                    Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 21:43 +0000
                      Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 15:06 -0700
                        Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 22:26 +0000
                          Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-28 15:35 -0700
                            Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-28 23:14 +0000
                    Re: The substantiation that -highhorse asked for Snit <usenet@gallopinginsanity.com> - 2018-08-28 14:57 -0700
              Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-28 23:11 -0400
                Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-29 06:14 +0000
                  Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-29 09:34 -0400
                    Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-29 14:31 +0000
                      Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-29 11:01 -0700
                        Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-31 12:33 +0000
                          Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-31 09:16 -0700
                            Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-31 16:53 +0000
                              Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-31 10:22 -0700
                                Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-31 17:53 +0000
                                  Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-08-31 11:36 -0700
                                    Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 13:45 +0000
                                      Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 13:59 +0000
                                      Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-09-01 08:15 -0700
                                        Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 16:00 +0000
                                          Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-09-01 11:20 -0700
                      Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-31 15:00 -0400
                        Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-31 19:40 +0000
                          Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-09-01 10:15 -0400
                            Re: The substantiation that -highhorse asked for Steve Carroll <fretwizzer@gmail.com> - 2018-09-01 08:22 -0700
                            Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 16:28 +0000
                              Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-09-01 16:39 -0400
                                Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 22:00 +0000
                                  Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-09-01 18:27 -0400
                                    Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 22:40 +0000
                                      Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-09-01 19:09 -0400
                                        Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-09-01 23:59 +0000
          Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-28 23:01 -0400
            Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-29 06:26 +0000
    Re: The substantiation that -highhorse asked for "F. Russell" <fr@random.info> - 2018-08-28 19:25 +0000
      Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-29 09:32 -0400
        Re: The substantiation that -highhorse asked for fr314159@gmail.com - 2018-08-29 06:46 -0700
          Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-08-29 09:55 -0400
            Re: The substantiation that -highhorse asked for fr314159@gmail.com - 2018-08-29 08:02 -0700
              Re: The substantiation that -highhorse asked for DFS <nospam@nospam.com> - 2018-09-01 10:14 -0400
            Re: The substantiation that -highhorse asked for owl <owl@rooftop.invalid> - 2018-08-29 15:12 +0000

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

#465347

On 8/28/18 2:31 PM, Steve Carroll wrote:
> On Tuesday, August 28, 2018 at 3:17:02 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>>> On Tuesday, August 28, 2018 at 2:09:26 PM UTC-6, owl wrote:
>>>> Steve Carroll <fretwizzer@gmail.com> wrote:
>>>>> On Tuesday, August 28, 2018 at 1:14:23 PM UTC-6, owl wrote:
>>>>>> DFS <nospam@nospam.com> wrote:
>>>>>>> On 8/28/2018 1:21 PM, owl wrote:
>>>>>>>> DFS <nospam@nospam.com> wrote:
>>>>>>>
>>>>>>>>> https://imgur.com/a/JWTIK
>>>>>>>>>
>>>>>>>>> Linux makes you stupid.
>>>>>>>>
>>>>>>>> Those aren't nested if statements.  They are all at the same level.
>>>>>>>
>>>>>>>
>>>>>>> I know.  I didn't say they were nested - I said Feeb tried to remember
>>>>>>> how many levels there were in his junky code.  It's no less crappy just
>>>>>>> because it's one level.
>>>>>>
>>>>>> If you're dealing with a bunch of ranges, a long if-else sequence
>>>>>> might be the only way.
>>>>>
>>>>> Unless I'm not understanding what you mean by 'ranges', I'd tend to
>>>>> think that's a situation that'd lend itself to doing it dynamically. My
>>>>> iterated example above had edges cases, that I would think a range
>>>>> example wouldn't be bothered with.
>>>>
>>>> anon@lowtide:~/code/ifs$ ./blah -7
>>>> a<0
>>>> anon@lowtide:~/code/ifs$ ./blah 0
>>>> a==0
>>>> anon@lowtide:~/code/ifs$ ./blah 7
>>>> a>0 && a<=10
>>>> anon@lowtide:~/code/ifs$ ./blah 11
>>>> a>10 && a<=100
>>>> anon@lowtide:~/code/ifs$ ./blah 13
>>>> a>10 && a<=100
>>>> anon@lowtide:~/code/ifs$ ./blah 14
>>>> fourteen is special!  You get a prize!
>>>> anon@lowtide:~/code/ifs$ ./blah 15
>>>> a>10 && a<=100
>>>> anon@lowtide:~/code/ifs$ ./blah 70
>>>> a>10 && a<=100
>>>> anon@lowtide:~/code/ifs$ ./blah 700
>>>> a>100 && a<=1000
>>>> anon@lowtide:~/code/ifs$ ./blah 7000
>>>> a>1000 && a<=10000
>>>> anon@lowtide:~/code/ifs$ ./blah 70000
>>>> a>10000 && a<=100000
>>>> anon@lowtide:~/code/ifs$ ./blah 700000
>>>> a>100000 && a<=1000000
>>>> anon@lowtide:~/code/ifs$ ./blah 7000000
>>>> a>1000000
>>>> anon@lowtide:~/code/ifs$
>>>
>>> For stuff like that you're not really saving a lot but there is repetition.
>>> Looks to me like, outside of the first two, it's the same thing, no?
>>
>> What do you mean "it's the same thing"?
> 
> Seems to be a lot of:
> 
> ifs$ ./blah xxx
> a > yyy && a <= zzz
> 
>> As described, it tests for ranges.
>> Here it just prints the tested range, but it could do whatever.  The point
>> is, practically any code you write that tested for those ranges would end
>> up being similar.  The tests would have to be done.
>>
>>> And
>>> what's  so "special" about 14?
>>
>> It's an "edge case."
> 
> Why?
> 

Randomly selected to show how it works, I would guess.

-- 
Personal attacks from those who troll show their own insecurity. They 
cannot use reason to show the message to be wrong so they try to feel 
somehow superior by attacking the messenger.

They cling to their attacks and ignore the message time and time again.

<https://youtu.be/H4NW-Cqh308>

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

#465360

On 8/28/2018 4:09 PM, owl wrote:


 > If you're dealing with a bunch of ranges, a long if-else sequence
 > might be the only way.

> anon@lowtide:~/code/ifs$ ./blah -7
> a<0
> anon@lowtide:~/code/ifs$ ./blah 0
> a==0
> anon@lowtide:~/code/ifs$ ./blah 7
> a>0 && a<=10
> anon@lowtide:~/code/ifs$ ./blah 11
> a>10 && a<=100
> anon@lowtide:~/code/ifs$ ./blah 13
> a>10 && a<=100
> anon@lowtide:~/code/ifs$ ./blah 14
> fourteen is special!  You get a prize!
> anon@lowtide:~/code/ifs$ ./blah 15
> a>10 && a<=100
> anon@lowtide:~/code/ifs$ ./blah 70
> a>10 && a<=100
> anon@lowtide:~/code/ifs$ ./blah 700
> a>100 && a<=1000
> anon@lowtide:~/code/ifs$ ./blah 7000
> a>1000 && a<=10000
> anon@lowtide:~/code/ifs$ ./blah 70000
> a>10000 && a<=100000
> anon@lowtide:~/code/ifs$ ./blah 700000
> a>100000 && a<=1000000
> anon@lowtide:~/code/ifs$ ./blah 7000000
> a>1000000
> anon@lowtide:~/code/ifs$


import random

print "Group 1: r<0"
print "Group 2: r==0"
print "Group 3: r>0 && r<=10"
print "Group 4: r>10 && r<=100"
print "Group 5: r>100 && r<=1000"
print "Group 6: r>1000 && r<=10000"
print "Group 7: r>10000 && r<=100000"
print "Group 8: r>100000 && r<=1000000"
print "Group 9: r>1000000"

def printgroup(grp):
	print "Found random number " + str(r) + " in Group " + str(grp)

for j in range(20):
	r = random.randint(-1000,1001)
	if r < 0: 		printgroup(1); exit
	if r > 1000000: printgroup(9); exit
	comps = 
[(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
	for i, x in enumerate(range(len(comps))):
		if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
		i+=1	



That's 3 if-then-exits to handle 9 comparisons

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

#465361

DFS <nospam@nospam.com> wrote:
> 
> import random
> 
> print "Group 1: r<0"
> print "Group 2: r==0"
> print "Group 3: r>0 && r<=10"
> print "Group 4: r>10 && r<=100"
> print "Group 5: r>100 && r<=1000"
> print "Group 6: r>1000 && r<=10000"
> print "Group 7: r>10000 && r<=100000"
> print "Group 8: r>100000 && r<=1000000"
> print "Group 9: r>1000000"
> 
> def printgroup(grp):
>        print "Found random number " + str(r) + " in Group " + str(grp)
> 
> for j in range(20):
>        r = random.randint(-1000,1001)
>        if r < 0:               printgroup(1); exit
>        if r > 1000000: printgroup(9); exit
>        comps = 
> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>        for i, x in enumerate(range(len(comps))):
>                if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>                i+=1    
> 
> 
> 
> That's 3 if-then-exits to handle 9 comparisons

If you call that 3 ifs, then I get to call this zero ifs:

anon@lowtide:~/code/ifs$ cat goo.c
#include <stdio.h>
#include <stdlib.h>

void flz(void){printf("a<0\n");}
void fgm(void){printf("a>1000000\n");}
void f0(void){printf("a==0\n");}
void f1(void){printf("a>0 && a<=10\n");}
void f2(void){printf("a>10 && a<=100\n");}
void f3(void){printf("a>100 && a<=1000\n");}
void f4(void){printf("a>1000 && a<=10000\n");}
void f5(void){printf("a>10000 && a<=100000\n");}
void f6(void){printf("a>100000 && a<=1000000\n");}

int main(int argc, char *argv[])
{
   int a=0;
   int i=0;
   void (*fp[1000001])(void)={0};
   fp[0]=f0;
   for(i=1;i<=10;i++) fp[i]=f1; 
   for(i=11;i<=100;i++) fp[i]=f2;
   for(i=101;i<=1000;i++) fp[i]=f3;
   for(i=1001;i<=10000;i++) fp[i]=f4;
   for(i=10001;i<=100000;i++) fp[i]=f5;
   for(i=100001;i<=1000000;i++) fp[i]=f6;
   a=atoi(argv[1]);
   (a<0?flz:a>1000000?fgm:fp[a])();  
   return 0;
}
anon@lowtide:~/code/ifs$ 

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

#465367

On 8/29/2018 2:14 AM, owl wrote:
> DFS <nospam@nospam.com> wrote:
>>
>> import random
>>
>> print "Group 1: r<0"
>> print "Group 2: r==0"
>> print "Group 3: r>0 && r<=10"
>> print "Group 4: r>10 && r<=100"
>> print "Group 5: r>100 && r<=1000"
>> print "Group 6: r>1000 && r<=10000"
>> print "Group 7: r>10000 && r<=100000"
>> print "Group 8: r>100000 && r<=1000000"
>> print "Group 9: r>1000000"
>>
>> def printgroup(grp):
>>         print "Found random number " + str(r) + " in Group " + str(grp)
>>
>> for j in range(20):
>>         r = random.randint(-1000,1001)
>>         if r < 0:               printgroup(1); exit
>>         if r > 1000000: printgroup(9); exit
>>         comps =
>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>>         for i, x in enumerate(range(len(comps))):
>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>>                 i+=1
>>
>>
>>
>> That's 3 if-then-exits to handle 9 comparisons
> 
> If you call that 3 ifs, then I get to call this zero ifs:
> 
> anon@lowtide:~/code/ifs$ cat goo.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> void flz(void){printf("a<0\n");}
> void fgm(void){printf("a>1000000\n");}
> void f0(void){printf("a==0\n");}
> void f1(void){printf("a>0 && a<=10\n");}
> void f2(void){printf("a>10 && a<=100\n");}
> void f3(void){printf("a>100 && a<=1000\n");}
> void f4(void){printf("a>1000 && a<=10000\n");}
> void f5(void){printf("a>10000 && a<=100000\n");}
> void f6(void){printf("a>100000 && a<=1000000\n");}
> 
> int main(int argc, char *argv[])
> {
>     int a=0;
>     int i=0;
>     void (*fp[1000001])(void)={0};
>     fp[0]=f0;
>     for(i=1;i<=10;i++) fp[i]=f1;
>     for(i=11;i<=100;i++) fp[i]=f2;
>     for(i=101;i<=1000;i++) fp[i]=f3;
>     for(i=1001;i<=10000;i++) fp[i]=f4;
>     for(i=10001;i<=100000;i++) fp[i]=f5;
>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>     a=atoi(argv[1]);
>     (a<0?flz:a>1000000?fgm:fp[a])();
>     return 0;
> }
> anon@lowtide:~/code/ifs$

affirmative

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

#465379

DFS <nospam@nospam.com> wrote:
> On 8/29/2018 2:14 AM, owl wrote:
>> DFS <nospam@nospam.com> wrote:
>>>
>>> import random
>>>
>>> print "Group 1: r<0"
>>> print "Group 2: r==0"
>>> print "Group 3: r>0 && r<=10"
>>> print "Group 4: r>10 && r<=100"
>>> print "Group 5: r>100 && r<=1000"
>>> print "Group 6: r>1000 && r<=10000"
>>> print "Group 7: r>10000 && r<=100000"
>>> print "Group 8: r>100000 && r<=1000000"
>>> print "Group 9: r>1000000"
>>>
>>> def printgroup(grp):
>>>         print "Found random number " + str(r) + " in Group " + str(grp)
>>>
>>> for j in range(20):
>>>         r = random.randint(-1000,1001)
>>>         if r < 0:               printgroup(1); exit
>>>         if r > 1000000: printgroup(9); exit
>>>         comps =
>>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>>>         for i, x in enumerate(range(len(comps))):
>>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>>>                 i+=1
>>>
>>>
>>>
>>> That's 3 if-then-exits to handle 9 comparisons
>> 
>> If you call that 3 ifs, then I get to call this zero ifs:
>> 
>> anon@lowtide:~/code/ifs$ cat goo.c
>> #include <stdio.h>
>> #include <stdlib.h>
>> 
>> void flz(void){printf("a<0\n");}
>> void fgm(void){printf("a>1000000\n");}
>> void f0(void){printf("a==0\n");}
>> void f1(void){printf("a>0 && a<=10\n");}
>> void f2(void){printf("a>10 && a<=100\n");}
>> void f3(void){printf("a>100 && a<=1000\n");}
>> void f4(void){printf("a>1000 && a<=10000\n");}
>> void f5(void){printf("a>10000 && a<=100000\n");}
>> void f6(void){printf("a>100000 && a<=1000000\n");}
>> 
>> int main(int argc, char *argv[])
>> {
>>     int a=0;
>>     int i=0;
>>     void (*fp[1000001])(void)={0};
>>     fp[0]=f0;
>>     for(i=1;i<=10;i++) fp[i]=f1;
>>     for(i=11;i<=100;i++) fp[i]=f2;
>>     for(i=101;i<=1000;i++) fp[i]=f3;
>>     for(i=1001;i<=10000;i++) fp[i]=f4;
>>     for(i=10001;i<=100000;i++) fp[i]=f5;
>>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>>     a=atoi(argv[1]);
>>     (a<0?flz:a>1000000?fgm:fp[a])();
>>     return 0;
>> }
>> anon@lowtide:~/code/ifs$
> 
> affirmative
> 

But who would write it that way, and why?  Sure, there's no if statements,
but that comes at the expense of 1,000,001 function pointers.  And the
nested ternaries constitute conditional tests anyway.  Not to mention
less readability.  It would run faster, use less stack, and be much more
readable and faster to design and write without error, by just using a
list of ifs.

anon@lowtide:~/code/ifs$ time ./blah 500
a>100 && a<=1000

real    0m0.002s
user    0m0.000s
sys     0m0.000s
anon@lowtide:~/code/ifs$ time ./goo 500
a>100 && a<=1000

real    0m0.020s
user    0m0.008s
sys     0m0.008s
anon@lowtide:~/code/ifs$
 

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

#465395

On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
> DFS <nospam@nospam.com> wrote:
> > On 8/29/2018 2:14 AM, owl wrote:
> >> DFS <nospam@nospam.com> wrote:
> >>>
> >>> import random
> >>>
> >>> print "Group 1: r<0"
> >>> print "Group 2: r==0"
> >>> print "Group 3: r>0 && r<=10"
> >>> print "Group 4: r>10 && r<=100"
> >>> print "Group 5: r>100 && r<=1000"
> >>> print "Group 6: r>1000 && r<=10000"
> >>> print "Group 7: r>10000 && r<=100000"
> >>> print "Group 8: r>100000 && r<=1000000"
> >>> print "Group 9: r>1000000"
> >>>
> >>> def printgroup(grp):
> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
> >>>
> >>> for j in range(20):
> >>>         r = random.randint(-1000,1001)
> >>>         if r < 0:               printgroup(1); exit
> >>>         if r > 1000000: printgroup(9); exit
> >>>         comps =
> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
> >>>         for i, x in enumerate(range(len(comps))):
> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
> >>>                 i+=1
> >>>
> >>>
> >>>
> >>> That's 3 if-then-exits to handle 9 comparisons
> >> 
> >> If you call that 3 ifs, then I get to call this zero ifs:
> >> 
> >> anon@lowtide:~/code/ifs$ cat goo.c
> >> #include <stdio.h>
> >> #include <stdlib.h>
> >> 
> >> void flz(void){printf("a<0\n");}
> >> void fgm(void){printf("a>1000000\n");}
> >> void f0(void){printf("a==0\n");}
> >> void f1(void){printf("a>0 && a<=10\n");}
> >> void f2(void){printf("a>10 && a<=100\n");}
> >> void f3(void){printf("a>100 && a<=1000\n");}
> >> void f4(void){printf("a>1000 && a<=10000\n");}
> >> void f5(void){printf("a>10000 && a<=100000\n");}
> >> void f6(void){printf("a>100000 && a<=1000000\n");}
> >> 
> >> int main(int argc, char *argv[])
> >> {
> >>     int a=0;
> >>     int i=0;
> >>     void (*fp[1000001])(void)={0};
> >>     fp[0]=f0;
> >>     for(i=1;i<=10;i++) fp[i]=f1;
> >>     for(i=11;i<=100;i++) fp[i]=f2;
> >>     for(i=101;i<=1000;i++) fp[i]=f3;
> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
> >>     a=atoi(argv[1]);
> >>     (a<0?flz:a>1000000?fgm:fp[a])();
> >>     return 0;
> >> }
> >> anon@lowtide:~/code/ifs$
> > 
> > affirmative
> > 
> 
> But who would write it that way, and why?  Sure, there's no if statements,
> but that comes at the expense of 1,000,001 function pointers.  And the
> nested ternaries constitute conditional tests anyway.  Not to mention
> less readability.  It would run faster, use less stack, and be much more
> readable and faster to design and write without error, by just using a
> list of ifs.
> 
> anon@lowtide:~/code/ifs$ time ./blah 500
> a>100 && a<=1000
> 
> real    0m0.002s
> user    0m0.000s
> sys     0m0.000s
> anon@lowtide:~/code/ifs$ time ./goo 500
> a>100 && a<=1000
> 
> real    0m0.020s
> user    0m0.008s
> sys     0m0.008s
> anon@lowtide:~/code/ifs$

What are those times representing, your if/else vs the above (or his code)?

JS doesn't have 'range' (like Python) and it's not as fast as C but we
do have 'map' (as does Python, not sure about C?) so if there are no
edge cases it's easy to write (especially when nested). Non-nested: 

console.time('loop'); 
const  comps = [[-1,0],[1,10],[11,100],[101,1000],[1001,10000],[10001,100000],[100001,1000000]];
let result = comps.map(arr => [...Array(arr[1] - arr[0]).keys()]);
console.timeEnd('loop'); 
console.log(result);

I'm only creating the arrays based on your nums here, but even limited
to just doing that, I got this for time (bear in mind, in a browser)...

Chrome: 
1 -39.4169921875ms
2 - 39.699951171875ms
3 - 34.4677734375ms
4 - 38.1787109375ms
5 - 37.77783203125ms

Firefox (surprised the hell outta me!): 
1 -19ms 
2 - 21ms
3 -20ms 
4 -22ms
5 - 20ms

Opera: 
1 - 69.35595703125ms
2 - 65.871826171875ms
3 - 69.5849609375ms
4 - 66.271240234375ms
5 - 63.829833984375ms

Safari no longer runs console.time(), not sure why. Awhile back, when 
it did run it, I tested logging simple for loop iterations against Chrome.
Note that I even start Safari first:  <https://streamable.com/hml2w>

I realize you don't care about browsers any more than you do JS, but 
like Butch said to Sundance about Australia:
"I thought that secretly you wanted to know" ;)

(just watched the flick recently)

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

#465444

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
>> DFS <nospam@nospam.com> wrote:
>> > On 8/29/2018 2:14 AM, owl wrote:
>> >> DFS <nospam@nospam.com> wrote:
>> >>>
>> >>> import random
>> >>>
>> >>> print "Group 1: r<0"
>> >>> print "Group 2: r==0"
>> >>> print "Group 3: r>0 && r<=10"
>> >>> print "Group 4: r>10 && r<=100"
>> >>> print "Group 5: r>100 && r<=1000"
>> >>> print "Group 6: r>1000 && r<=10000"
>> >>> print "Group 7: r>10000 && r<=100000"
>> >>> print "Group 8: r>100000 && r<=1000000"
>> >>> print "Group 9: r>1000000"
>> >>>
>> >>> def printgroup(grp):
>> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
>> >>>
>> >>> for j in range(20):
>> >>>         r = random.randint(-1000,1001)
>> >>>         if r < 0:               printgroup(1); exit
>> >>>         if r > 1000000: printgroup(9); exit
>> >>>         comps =
>> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>> >>>         for i, x in enumerate(range(len(comps))):
>> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>> >>>                 i+=1
>> >>>
>> >>>
>> >>>
>> >>> That's 3 if-then-exits to handle 9 comparisons
>> >> 
>> >> If you call that 3 ifs, then I get to call this zero ifs:
>> >> 
>> >> anon@lowtide:~/code/ifs$ cat goo.c
>> >> #include <stdio.h>
>> >> #include <stdlib.h>
>> >> 
>> >> void flz(void){printf("a<0\n");}
>> >> void fgm(void){printf("a>1000000\n");}
>> >> void f0(void){printf("a==0\n");}
>> >> void f1(void){printf("a>0 && a<=10\n");}
>> >> void f2(void){printf("a>10 && a<=100\n");}
>> >> void f3(void){printf("a>100 && a<=1000\n");}
>> >> void f4(void){printf("a>1000 && a<=10000\n");}
>> >> void f5(void){printf("a>10000 && a<=100000\n");}
>> >> void f6(void){printf("a>100000 && a<=1000000\n");}
>> >> 
>> >> int main(int argc, char *argv[])
>> >> {
>> >>     int a=0;
>> >>     int i=0;
>> >>     void (*fp[1000001])(void)={0};
>> >>     fp[0]=f0;
>> >>     for(i=1;i<=10;i++) fp[i]=f1;
>> >>     for(i=11;i<=100;i++) fp[i]=f2;
>> >>     for(i=101;i<=1000;i++) fp[i]=f3;
>> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
>> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
>> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>> >>     a=atoi(argv[1]);
>> >>     (a<0?flz:a>1000000?fgm:fp[a])();
>> >>     return 0;
>> >> }
>> >> anon@lowtide:~/code/ifs$
>> > 
>> > affirmative
>> > 
>> 
>> But who would write it that way, and why?  Sure, there's no if statements,
>> but that comes at the expense of 1,000,001 function pointers.  And the
>> nested ternaries constitute conditional tests anyway.  Not to mention
>> less readability.  It would run faster, use less stack, and be much more
>> readable and faster to design and write without error, by just using a
>> list of ifs.
>> 
>> anon@lowtide:~/code/ifs$ time ./blah 500
>> a>100 && a<=1000
>> 
>> real    0m0.002s
>> user    0m0.000s
>> sys     0m0.000s
>> anon@lowtide:~/code/ifs$ time ./goo 500
>> a>100 && a<=1000
>> 
>> real    0m0.020s
>> user    0m0.008s
>> sys     0m0.008s
>> anon@lowtide:~/code/ifs$
> 
> What are those times representing, your if/else vs the above (or his code)?
> 

if/else vs the above.
But you can combine the above with DFS's loop and it's just as fast.

anon@lowtide:~/code/ifs$ cat qoo.c
#include <stdio.h>
#include <stdlib.h>

void flz(void){printf("a<0\n");}
void f0(void){printf("a==0\n");}
void f1(void){printf("a>0 && a<=10\n");}
void f2(void){printf("a>10 && a<=100\n");}
void f3(void){printf("a>100 && a<=1000\n");}
void f4(void){printf("a>1000 && a<=10000\n");}
void f5(void){printf("a>10000 && a<=100000\n");}
void f6(void){printf("a>100000 && a<=1000000\n");}
void fgm(void){printf("a>1000000\n");}

int main(int argc, char *argv[])
{
  int i=0;
  int a=0;
  void (*fp[])(void)={flz,f0,f1,f2,f3,f4,f5,f6,fgm};
  int comps[][2]={{-1,0},{0,10},{10,100},{100,1000},
                 {1000,10000},{10000,100000},{100000,1000000}};
  int arrsize=0;
  if(argc!=2)
  {
    fprintf(stderr,"feed me a number\n");
    exit(1);
  }
  arrsize=sizeof(comps)/sizeof(comps[0]);
  a=atoi(argv[1]);
  if (a<0){(fp[0])();}
  else if (a>1000000){(fp[8])();}
  else
  {
    for(i=0;i<arrsize;i++)
    { 
      if((a>comps[i][0]) && (a<=comps[i][1]))
      {
         (fp[i+1])();
         break;
      }
    }
  }
  return 0;
}
anon@lowtide:~/code/ifs$ 
anon@lowtide:~/code/ifs$ time ./qoo 500
a>100 && a<=1000

real    0m0.002s
user    0m0.000s
sys     0m0.000s
anon@lowtide:~/code/ifs$ 



> JS doesn't have 'range' (like Python) and it's not as fast as C but we
> do have 'map' (as does Python, not sure about C?) so if there are no
> edge cases it's easy to write (especially when nested). Non-nested: 
> 

You have to roll your own in C. 

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

#465452

On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
> >> DFS <nospam@nospam.com> wrote:
> >> > On 8/29/2018 2:14 AM, owl wrote:
> >> >> DFS <nospam@nospam.com> wrote:
> >> >>>
> >> >>> import random
> >> >>>
> >> >>> print "Group 1: r<0"
> >> >>> print "Group 2: r==0"
> >> >>> print "Group 3: r>0 && r<=10"
> >> >>> print "Group 4: r>10 && r<=100"
> >> >>> print "Group 5: r>100 && r<=1000"
> >> >>> print "Group 6: r>1000 && r<=10000"
> >> >>> print "Group 7: r>10000 && r<=100000"
> >> >>> print "Group 8: r>100000 && r<=1000000"
> >> >>> print "Group 9: r>1000000"
> >> >>>
> >> >>> def printgroup(grp):
> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
> >> >>>
> >> >>> for j in range(20):
> >> >>>         r = random.randint(-1000,1001)
> >> >>>         if r < 0:               printgroup(1); exit
> >> >>>         if r > 1000000: printgroup(9); exit
> >> >>>         comps =
> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
> >> >>>         for i, x in enumerate(range(len(comps))):
> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
> >> >>>                 i+=1
> >> >>>
> >> >>>
> >> >>>
> >> >>> That's 3 if-then-exits to handle 9 comparisons
> >> >> 
> >> >> If you call that 3 ifs, then I get to call this zero ifs:
> >> >> 
> >> >> anon@lowtide:~/code/ifs$ cat goo.c
> >> >> #include <stdio.h>
> >> >> #include <stdlib.h>
> >> >> 
> >> >> void flz(void){printf("a<0\n");}
> >> >> void fgm(void){printf("a>1000000\n");}
> >> >> void f0(void){printf("a==0\n");}
> >> >> void f1(void){printf("a>0 && a<=10\n");}
> >> >> void f2(void){printf("a>10 && a<=100\n");}
> >> >> void f3(void){printf("a>100 && a<=1000\n");}
> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
> >> >> 
> >> >> int main(int argc, char *argv[])
> >> >> {
> >> >>     int a=0;
> >> >>     int i=0;
> >> >>     void (*fp[1000001])(void)={0};
> >> >>     fp[0]=f0;
> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
> >> >>     a=atoi(argv[1]);
> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
> >> >>     return 0;
> >> >> }
> >> >> anon@lowtide:~/code/ifs$
> >> > 
> >> > affirmative
> >> > 
> >> 
> >> But who would write it that way, and why?  Sure, there's no if statements,
> >> but that comes at the expense of 1,000,001 function pointers.  And the
> >> nested ternaries constitute conditional tests anyway.  Not to mention
> >> less readability.  It would run faster, use less stack, and be much more
> >> readable and faster to design and write without error, by just using a
> >> list of ifs.
> >> 
> >> anon@lowtide:~/code/ifs$ time ./blah 500
> >> a>100 && a<=1000
> >> 
> >> real    0m0.002s
> >> user    0m0.000s
> >> sys     0m0.000s
> >> anon@lowtide:~/code/ifs$ time ./goo 500
> >> a>100 && a<=1000
> >> 
> >> real    0m0.020s
> >> user    0m0.008s
> >> sys     0m0.008s
> >> anon@lowtide:~/code/ifs$
> > 
> > What are those times representing, your if/else vs the above (or his code)?
> > 
> 
> if/else vs the above.
> But you can combine the above with DFS's loop and it's just as fast.

Because what Feeb said about the complier is correct?

> anon@lowtide:~/code/ifs$ cat qoo.c
> #include <stdio.h>
> #include <stdlib.h>
> 
> void flz(void){printf("a<0\n");}
> void f0(void){printf("a==0\n");}
> void f1(void){printf("a>0 && a<=10\n");}
> void f2(void){printf("a>10 && a<=100\n");}
> void f3(void){printf("a>100 && a<=1000\n");}
> void f4(void){printf("a>1000 && a<=10000\n");}
> void f5(void){printf("a>10000 && a<=100000\n");}
> void f6(void){printf("a>100000 && a<=1000000\n");}
> void fgm(void){printf("a>1000000\n");}
> 
> int main(int argc, char *argv[])
> {
>   int i=0;
>   int a=0;
>   void (*fp[])(void)={flz,f0,f1,f2,f3,f4,f5,f6,fgm};
>   int comps[][2]={{-1,0},{0,10},{10,100},{100,1000},
>                  {1000,10000},{10000,100000},{100000,1000000}};
>   int arrsize=0;
>   if(argc!=2)
>   {
>     fprintf(stderr,"feed me a number\n");
>     exit(1);
>   }
>   arrsize=sizeof(comps)/sizeof(comps[0]);
>   a=atoi(argv[1]);
>   if (a<0){(fp[0])();}
>   else if (a>1000000){(fp[8])();}
>   else
>   {
>     for(i=0;i<arrsize;i++)
>     { 
>       if((a>comps[i][0]) && (a<=comps[i][1]))
>       {
>          (fp[i+1])();
>          break;
>       }
>     }
>   }
>   return 0;
> }
> anon@lowtide:~/code/ifs$ 
> anon@lowtide:~/code/ifs$ time ./qoo 500
> a>100 && a<=1000
> 
> real    0m0.002s
> user    0m0.000s
> sys     0m0.000s
> anon@lowtide:~/code/ifs$ 
> 
> 
> 
> > JS doesn't have 'range' (like Python) and it's not as fast as C but we
> > do have 'map' (as does Python, not sure about C?) so if there are no
> > edge cases it's easy to write (especially when nested). Non-nested: 
> > 
> 
> You have to roll your own in C.

I thought so. Here's a JS version using a while loop to repeat and I 
run the function 1000x (but I'm not building the subarrays this time):

'use strict';
console.log("Group 1: r<0");
console.log("Group 2: r==0");
console.log("Group 3: r>0 && r<=10");
console.log("Group 4: r>10 && r<=100");
console.log("Group 5: r>100 && r<=1000");
console.log("Group 6: r>1000 && r<=10000");
console.log("Group 7: r>10000 && r<=100000"); 
console.log("Group 8: r>100000 && r<=1000000"); 
console.log("Group 9: r>1000000"); 
const  arrays = [[-1,0],[1,10],[11,100],[101,1000],[1001,10000],[10001,100000],[100001,1000000]]; 
const rndInt = (min, max) => {
    min = Math.ceil(min);
    max = Math.floor(max);
    return Math.floor(Math.random() * (max - min)) + min;
}

let repeatMe = (num) => {
    console.time('test');
    let x = 0, r;
    let printGroup = grp => console.log(` Found ${r} in Group ${grp}`);
    while(x < num) {
        r = rndInt(-1000,1011);
        r < 0 ? printGroup(1) : false;
        r > 1000 ? printGroup(6) : false;
        arrays.forEach((arr,i) => {
            r > arr[0] && r <= arr[1] ? printGroup(i+2) : false;
        });
        x+=1;
    }
    console.timeEnd('test');
};
repeatMe(1000);

Opera did much better when not creating all the arrays:

Chrome
1 - 132ms
2 - 127ms
3 - 137ms
4 - 129ms
5 - 135ms
6 - 132ms
7 - 131ms
8 - 136ms

Firefox
1 - 154ms
2 - 150ms
3 - 143ms
4 - 135ms
5 - 127ms
6 - 133ms
7 - 127ms
8 - 135ms

Opera
1 - 129ms
2 - 134ms
3 - 135ms
4 - 127ms
5 - 132ms
6 - 131ms
7 - 129ms
8 - 127ms

I ran it 1000x once in each browser while building the arrays 
(using nested forEach for subs), that's a *lot* of elements.

Chrome: 57918.697265625ms
Opera:    56953.428955078125ms
FireFox:  34293ms (wow!)

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

#465453

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
>> >> DFS <nospam@nospam.com> wrote:
>> >> > On 8/29/2018 2:14 AM, owl wrote:
>> >> >> DFS <nospam@nospam.com> wrote:
>> >> >>>
>> >> >>> import random
>> >> >>>
>> >> >>> print "Group 1: r<0"
>> >> >>> print "Group 2: r==0"
>> >> >>> print "Group 3: r>0 && r<=10"
>> >> >>> print "Group 4: r>10 && r<=100"
>> >> >>> print "Group 5: r>100 && r<=1000"
>> >> >>> print "Group 6: r>1000 && r<=10000"
>> >> >>> print "Group 7: r>10000 && r<=100000"
>> >> >>> print "Group 8: r>100000 && r<=1000000"
>> >> >>> print "Group 9: r>1000000"
>> >> >>>
>> >> >>> def printgroup(grp):
>> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
>> >> >>>
>> >> >>> for j in range(20):
>> >> >>>         r = random.randint(-1000,1001)
>> >> >>>         if r < 0:               printgroup(1); exit
>> >> >>>         if r > 1000000: printgroup(9); exit
>> >> >>>         comps =
>> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>> >> >>>         for i, x in enumerate(range(len(comps))):
>> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>> >> >>>                 i+=1
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> That's 3 if-then-exits to handle 9 comparisons
>> >> >> 
>> >> >> If you call that 3 ifs, then I get to call this zero ifs:
>> >> >> 
>> >> >> anon@lowtide:~/code/ifs$ cat goo.c
>> >> >> #include <stdio.h>
>> >> >> #include <stdlib.h>
>> >> >> 
>> >> >> void flz(void){printf("a<0\n");}
>> >> >> void fgm(void){printf("a>1000000\n");}
>> >> >> void f0(void){printf("a==0\n");}
>> >> >> void f1(void){printf("a>0 && a<=10\n");}
>> >> >> void f2(void){printf("a>10 && a<=100\n");}
>> >> >> void f3(void){printf("a>100 && a<=1000\n");}
>> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
>> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
>> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
>> >> >> 
>> >> >> int main(int argc, char *argv[])
>> >> >> {
>> >> >>     int a=0;
>> >> >>     int i=0;
>> >> >>     void (*fp[1000001])(void)={0};
>> >> >>     fp[0]=f0;
>> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
>> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
>> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
>> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
>> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
>> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>> >> >>     a=atoi(argv[1]);
>> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
>> >> >>     return 0;
>> >> >> }
>> >> >> anon@lowtide:~/code/ifs$
>> >> > 
>> >> > affirmative
>> >> > 
>> >> 
>> >> But who would write it that way, and why?  Sure, there's no if statements,
>> >> but that comes at the expense of 1,000,001 function pointers.  And the
>> >> nested ternaries constitute conditional tests anyway.  Not to mention
>> >> less readability.  It would run faster, use less stack, and be much more
>> >> readable and faster to design and write without error, by just using a
>> >> list of ifs.
>> >> 
>> >> anon@lowtide:~/code/ifs$ time ./blah 500
>> >> a>100 && a<=1000
>> >> 
>> >> real    0m0.002s
>> >> user    0m0.000s
>> >> sys     0m0.000s
>> >> anon@lowtide:~/code/ifs$ time ./goo 500
>> >> a>100 && a<=1000
>> >> 
>> >> real    0m0.020s
>> >> user    0m0.008s
>> >> sys     0m0.008s
>> >> anon@lowtide:~/code/ifs$
>> > 
>> > What are those times representing, your if/else vs the above (or his code)?
>> > 
>> 
>> if/else vs the above.
>> But you can combine the above with DFS's loop and it's just as fast.
> 
> Because what Feeb said about the complier is correct?
> 

I don't remember what fabtard said, but there is no performance advantage
to putting the ifs in a loop.  There may coding time advantage if the
the number of conditions is extreme, but a sequence of ifs would still
make what is happening more obvious, and for a relatively small number of
conditions the amount of time spent coding the loop might be greater --
just from care taken to get the array values right, off-by-one issues,
etc -- than a simple sequence of ifs, especially with an editor like
vim which makes code block skeletons so easy to duplicate.  Also, not
all if sequences are going to lend themselves to looping in a way that
would reduce the number of written conditions.

The code for the earlier doo.c, which was designed to remove all if
statements, would not even need the ternary conditional except for the
a<0 and a>1000000 tests.  The rest of it just uses the number passed in
as an index into the function pointer array.  But that array is huge,
and there is a big performance hit, so minimizing the number of ifs is
not necessarily a good thing.

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

#465456

On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
> >> >> DFS <nospam@nospam.com> wrote:
> >> >> > On 8/29/2018 2:14 AM, owl wrote:
> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >>>
> >> >> >>> import random
> >> >> >>>
> >> >> >>> print "Group 1: r<0"
> >> >> >>> print "Group 2: r==0"
> >> >> >>> print "Group 3: r>0 && r<=10"
> >> >> >>> print "Group 4: r>10 && r<=100"
> >> >> >>> print "Group 5: r>100 && r<=1000"
> >> >> >>> print "Group 6: r>1000 && r<=10000"
> >> >> >>> print "Group 7: r>10000 && r<=100000"
> >> >> >>> print "Group 8: r>100000 && r<=1000000"
> >> >> >>> print "Group 9: r>1000000"
> >> >> >>>
> >> >> >>> def printgroup(grp):
> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
> >> >> >>>
> >> >> >>> for j in range(20):
> >> >> >>>         r = random.randint(-1000,1001)
> >> >> >>>         if r < 0:               printgroup(1); exit
> >> >> >>>         if r > 1000000: printgroup(9); exit
> >> >> >>>         comps =
> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
> >> >> >>>         for i, x in enumerate(range(len(comps))):
> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
> >> >> >>>                 i+=1
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
> >> >> >> 
> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
> >> >> >> 
> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
> >> >> >> #include <stdio.h>
> >> >> >> #include <stdlib.h>
> >> >> >> 
> >> >> >> void flz(void){printf("a<0\n");}
> >> >> >> void fgm(void){printf("a>1000000\n");}
> >> >> >> void f0(void){printf("a==0\n");}
> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
> >> >> >> 
> >> >> >> int main(int argc, char *argv[])
> >> >> >> {
> >> >> >>     int a=0;
> >> >> >>     int i=0;
> >> >> >>     void (*fp[1000001])(void)={0};
> >> >> >>     fp[0]=f0;
> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
> >> >> >>     a=atoi(argv[1]);
> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
> >> >> >>     return 0;
> >> >> >> }
> >> >> >> anon@lowtide:~/code/ifs$
> >> >> > 
> >> >> > affirmative
> >> >> > 
> >> >> 
> >> >> But who would write it that way, and why?  Sure, there's no if statements,
> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
> >> >> less readability.  It would run faster, use less stack, and be much more
> >> >> readable and faster to design and write without error, by just using a
> >> >> list of ifs.
> >> >> 
> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
> >> >> a>100 && a<=1000
> >> >> 
> >> >> real    0m0.002s
> >> >> user    0m0.000s
> >> >> sys     0m0.000s
> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
> >> >> a>100 && a<=1000
> >> >> 
> >> >> real    0m0.020s
> >> >> user    0m0.008s
> >> >> sys     0m0.008s
> >> >> anon@lowtide:~/code/ifs$
> >> > 
> >> > What are those times representing, your if/else vs the above (or his code)?
> >> > 
> >> 
> >> if/else vs the above.
> >> But you can combine the above with DFS's loop and it's just as fast.
> > 
> > Because what Feeb said about the complier is correct?
> > 
> 
> I don't remember what fabtard said, but there is no performance advantage
> to putting the ifs in a loop.  There may coding time advantage if the
> the number of conditions is extreme, but a sequence of ifs would still
> make what is happening more obvious, and for a relatively small number of
> conditions the amount of time spent coding the loop might be greater --
> just from care taken to get the array values right, off-by-one issues,
> etc -- than a simple sequence of ifs, especially with an editor like
> vim which makes code block skeletons so easy to duplicate.  Also, not
> all if sequences are going to lend themselves to looping in a way that
> would reduce the number of written conditions.

"For a REAL language, a COMPILED language, the compiler often 
makes optimizing choices such as transforming your for-loop 
into a sequence of if-then statements.  The user can also specify 
that certain loops should be "unrolled" which leads to the 
same behavior. 

In short, there is no great difference between a for-loop and 
an "unrolled" loop sequence." - Feeb

> The code for the earlier doo.c, which was designed to remove all if
> statements, would not even need the ternary conditional except for the
> a<0 and a>1000000 tests. 

From what very little I've read on if vs ternary in C, there isn't much of 
a performance diff (apparently there can be some in certain conditions).

> The rest of it just uses the number passed in
> as an index into the function pointer array.  But that array is huge,
> and there is a big performance hit, so minimizing the number of ifs is
> not necessarily a good thing.

What's worse are the if/else if statements written inside of loops (like I 
had in my earliest example in this thread). But hey, it's JavaScript, no 
one expects it to run fast anyway ;) I was actually surprised by FF, it
was doing 100 million elements in 3-4 seconds *in* a browser (so 
we're talking DOM elements here, not just array elements)... a billion
in ~34.3 secs. What the best time you've gotten in C for such a task?

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

#465458

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
>> >> >> DFS <nospam@nospam.com> wrote:
>> >> >> > On 8/29/2018 2:14 AM, owl wrote:
>> >> >> >> DFS <nospam@nospam.com> wrote:
>> >> >> >>>
>> >> >> >>> import random
>> >> >> >>>
>> >> >> >>> print "Group 1: r<0"
>> >> >> >>> print "Group 2: r==0"
>> >> >> >>> print "Group 3: r>0 && r<=10"
>> >> >> >>> print "Group 4: r>10 && r<=100"
>> >> >> >>> print "Group 5: r>100 && r<=1000"
>> >> >> >>> print "Group 6: r>1000 && r<=10000"
>> >> >> >>> print "Group 7: r>10000 && r<=100000"
>> >> >> >>> print "Group 8: r>100000 && r<=1000000"
>> >> >> >>> print "Group 9: r>1000000"
>> >> >> >>>
>> >> >> >>> def printgroup(grp):
>> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
>> >> >> >>>
>> >> >> >>> for j in range(20):
>> >> >> >>>         r = random.randint(-1000,1001)
>> >> >> >>>         if r < 0:               printgroup(1); exit
>> >> >> >>>         if r > 1000000: printgroup(9); exit
>> >> >> >>>         comps =
>> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>> >> >> >>>         for i, x in enumerate(range(len(comps))):
>> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>> >> >> >>>                 i+=1
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
>> >> >> >> 
>> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
>> >> >> >> 
>> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
>> >> >> >> #include <stdio.h>
>> >> >> >> #include <stdlib.h>
>> >> >> >> 
>> >> >> >> void flz(void){printf("a<0\n");}
>> >> >> >> void fgm(void){printf("a>1000000\n");}
>> >> >> >> void f0(void){printf("a==0\n");}
>> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
>> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
>> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
>> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
>> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
>> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
>> >> >> >> 
>> >> >> >> int main(int argc, char *argv[])
>> >> >> >> {
>> >> >> >>     int a=0;
>> >> >> >>     int i=0;
>> >> >> >>     void (*fp[1000001])(void)={0};
>> >> >> >>     fp[0]=f0;
>> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
>> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
>> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
>> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
>> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
>> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>> >> >> >>     a=atoi(argv[1]);
>> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
>> >> >> >>     return 0;
>> >> >> >> }
>> >> >> >> anon@lowtide:~/code/ifs$
>> >> >> > 
>> >> >> > affirmative
>> >> >> > 
>> >> >> 
>> >> >> But who would write it that way, and why?  Sure, there's no if statements,
>> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
>> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
>> >> >> less readability.  It would run faster, use less stack, and be much more
>> >> >> readable and faster to design and write without error, by just using a
>> >> >> list of ifs.
>> >> >> 
>> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
>> >> >> a>100 && a<=1000
>> >> >> 
>> >> >> real    0m0.002s
>> >> >> user    0m0.000s
>> >> >> sys     0m0.000s
>> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
>> >> >> a>100 && a<=1000
>> >> >> 
>> >> >> real    0m0.020s
>> >> >> user    0m0.008s
>> >> >> sys     0m0.008s
>> >> >> anon@lowtide:~/code/ifs$
>> >> > 
>> >> > What are those times representing, your if/else vs the above (or his code)?
>> >> > 
>> >> 
>> >> if/else vs the above.
>> >> But you can combine the above with DFS's loop and it's just as fast.
>> > 
>> > Because what Feeb said about the complier is correct?
>> > 
>> 
>> I don't remember what fabtard said, but there is no performance advantage
>> to putting the ifs in a loop.  There may coding time advantage if the
>> the number of conditions is extreme, but a sequence of ifs would still
>> make what is happening more obvious, and for a relatively small number of
>> conditions the amount of time spent coding the loop might be greater --
>> just from care taken to get the array values right, off-by-one issues,
>> etc -- than a simple sequence of ifs, especially with an editor like
>> vim which makes code block skeletons so easy to duplicate.  Also, not
>> all if sequences are going to lend themselves to looping in a way that
>> would reduce the number of written conditions.
> 
> "For a REAL language, a COMPILED language, the compiler often 
> makes optimizing choices such as transforming your for-loop 
> into a sequence of if-then statements.  The user can also specify 
> that certain loops should be "unrolled" which leads to the 
> same behavior. 
> 
> In short, there is no great difference between a for-loop and 
> an "unrolled" loop sequence." - Feeb
> 
>> The code for the earlier doo.c, which was designed to remove all if
>> statements, would not even need the ternary conditional except for the
>> a<0 and a>1000000 tests. 
> 
> From what very little I've read on if vs ternary in C, there isn't much of 
> a performance diff (apparently there can be some in certain conditions).
> 
>> The rest of it just uses the number passed in
>> as an index into the function pointer array.  But that array is huge,
>> and there is a big performance hit, so minimizing the number of ifs is
>> not necessarily a good thing.
> 
> What's worse are the if/else if statements written inside of loops (like I 
> had in my earliest example in this thread). But hey, it's JavaScript, no 
> one expects it to run fast anyway ;) I was actually surprised by FF, it
> was doing 100 million elements in 3-4 seconds *in* a browser (so 
> we're talking DOM elements here, not just array elements)... a billion
> in ~34.3 secs. What the best time you've gotten in C for such a task?

Just looping, it looks like about 400 million per second:

anon@lowtide:~/code/ifs$ cat loop.c
#include <stdio.h>

int main(void)
{
  int i=0;
  printf("start\n");
  for(i=0;i<1000000000;i++)
  {
   ;
  }
  printf("done\n");
  return 0;
}
anon@lowtide:~/code/ifs$ time ./loop
start
done

real    0m2.501s
user    0m2.496s
sys     0m0.004s
anon@lowtide:~/code/ifs$ 

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

#465464

On Friday, August 31, 2018 at 11:53:16 AM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >> > On 8/29/2018 2:14 AM, owl wrote:
> >> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >> >>>
> >> >> >> >>> import random
> >> >> >> >>>
> >> >> >> >>> print "Group 1: r<0"
> >> >> >> >>> print "Group 2: r==0"
> >> >> >> >>> print "Group 3: r>0 && r<=10"
> >> >> >> >>> print "Group 4: r>10 && r<=100"
> >> >> >> >>> print "Group 5: r>100 && r<=1000"
> >> >> >> >>> print "Group 6: r>1000 && r<=10000"
> >> >> >> >>> print "Group 7: r>10000 && r<=100000"
> >> >> >> >>> print "Group 8: r>100000 && r<=1000000"
> >> >> >> >>> print "Group 9: r>1000000"
> >> >> >> >>>
> >> >> >> >>> def printgroup(grp):
> >> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
> >> >> >> >>>
> >> >> >> >>> for j in range(20):
> >> >> >> >>>         r = random.randint(-1000,1001)
> >> >> >> >>>         if r < 0:               printgroup(1); exit
> >> >> >> >>>         if r > 1000000: printgroup(9); exit
> >> >> >> >>>         comps =
> >> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
> >> >> >> >>>         for i, x in enumerate(range(len(comps))):
> >> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
> >> >> >> >>>                 i+=1
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
> >> >> >> >> 
> >> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
> >> >> >> >> 
> >> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
> >> >> >> >> #include <stdio.h>
> >> >> >> >> #include <stdlib.h>
> >> >> >> >> 
> >> >> >> >> void flz(void){printf("a<0\n");}
> >> >> >> >> void fgm(void){printf("a>1000000\n");}
> >> >> >> >> void f0(void){printf("a==0\n");}
> >> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
> >> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
> >> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
> >> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
> >> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
> >> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
> >> >> >> >> 
> >> >> >> >> int main(int argc, char *argv[])
> >> >> >> >> {
> >> >> >> >>     int a=0;
> >> >> >> >>     int i=0;
> >> >> >> >>     void (*fp[1000001])(void)={0};
> >> >> >> >>     fp[0]=f0;
> >> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
> >> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
> >> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
> >> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
> >> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
> >> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
> >> >> >> >>     a=atoi(argv[1]);
> >> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
> >> >> >> >>     return 0;
> >> >> >> >> }
> >> >> >> >> anon@lowtide:~/code/ifs$
> >> >> >> > 
> >> >> >> > affirmative
> >> >> >> > 
> >> >> >> 
> >> >> >> But who would write it that way, and why?  Sure, there's no if statements,
> >> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
> >> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
> >> >> >> less readability.  It would run faster, use less stack, and be much more
> >> >> >> readable and faster to design and write without error, by just using a
> >> >> >> list of ifs.
> >> >> >> 
> >> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
> >> >> >> a>100 && a<=1000
> >> >> >> 
> >> >> >> real    0m0.002s
> >> >> >> user    0m0.000s
> >> >> >> sys     0m0.000s
> >> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
> >> >> >> a>100 && a<=1000
> >> >> >> 
> >> >> >> real    0m0.020s
> >> >> >> user    0m0.008s
> >> >> >> sys     0m0.008s
> >> >> >> anon@lowtide:~/code/ifs$
> >> >> > 
> >> >> > What are those times representing, your if/else vs the above (or his code)?
> >> >> > 
> >> >> 
> >> >> if/else vs the above.
> >> >> But you can combine the above with DFS's loop and it's just as fast.
> >> > 
> >> > Because what Feeb said about the complier is correct?
> >> > 
> >> 
> >> I don't remember what fabtard said, but there is no performance advantage
> >> to putting the ifs in a loop.  There may coding time advantage if the
> >> the number of conditions is extreme, but a sequence of ifs would still
> >> make what is happening more obvious, and for a relatively small number of
> >> conditions the amount of time spent coding the loop might be greater --
> >> just from care taken to get the array values right, off-by-one issues,
> >> etc -- than a simple sequence of ifs, especially with an editor like
> >> vim which makes code block skeletons so easy to duplicate.  Also, not
> >> all if sequences are going to lend themselves to looping in a way that
> >> would reduce the number of written conditions.
> > 
> > "For a REAL language, a COMPILED language, the compiler often 
> > makes optimizing choices such as transforming your for-loop 
> > into a sequence of if-then statements.  The user can also specify 
> > that certain loops should be "unrolled" which leads to the 
> > same behavior. 
> > 
> > In short, there is no great difference between a for-loop and 
> > an "unrolled" loop sequence." - Feeb
> > 
> >> The code for the earlier doo.c, which was designed to remove all if
> >> statements, would not even need the ternary conditional except for the
> >> a<0 and a>1000000 tests. 
> > 
> > From what very little I've read on if vs ternary in C, there isn't much of 
> > a performance diff (apparently there can be some in certain conditions).
> > 
> >> The rest of it just uses the number passed in
> >> as an index into the function pointer array.  But that array is huge,
> >> and there is a big performance hit, so minimizing the number of ifs is
> >> not necessarily a good thing.
> > 
> > What's worse are the if/else if statements written inside of loops (like I 
> > had in my earliest example in this thread). But hey, it's JavaScript, no 
> > one expects it to run fast anyway ;) I was actually surprised by FF, it
> > was doing 100 million elements in 3-4 seconds *in* a browser (so 
> > we're talking DOM elements here, not just array elements)... a billion
> > in ~34.3 secs. What the best time you've gotten in C for such a task?
> 
> Just looping, it looks like about 400 million per second:
> 
> anon@lowtide:~/code/ifs$ cat loop.c
> #include <stdio.h>
> 
> int main(void)
> {
>   int i=0;
>   printf("start\n");
>   for(i=0;i<1000000000;i++)
>   {
>    ;
>   }
>   printf("done\n");
>   return 0;
> }
> anon@lowtide:~/code/ifs$ time ./loop
> start
> done
> 
> real    0m2.501s
> user    0m2.496s
> sys     0m0.004s
> anon@lowtide:~/code/ifs$

<https://imgur.com/a/hT5B6QQ>

Chrome (on the left) in ~1 sec, but FF was well over 5x slower. WTF!?

What about if you were creating arrays elements?

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

#465494

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Friday, August 31, 2018 at 11:53:16 AM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
>> >> >> >> DFS <nospam@nospam.com> wrote:
>> >> >> >> > On 8/29/2018 2:14 AM, owl wrote:
>> >> >> >> >> DFS <nospam@nospam.com> wrote:
>> >> >> >> >>>
>> >> >> >> >>> import random
>> >> >> >> >>>
>> >> >> >> >>> print "Group 1: r<0"
>> >> >> >> >>> print "Group 2: r==0"
>> >> >> >> >>> print "Group 3: r>0 && r<=10"
>> >> >> >> >>> print "Group 4: r>10 && r<=100"
>> >> >> >> >>> print "Group 5: r>100 && r<=1000"
>> >> >> >> >>> print "Group 6: r>1000 && r<=10000"
>> >> >> >> >>> print "Group 7: r>10000 && r<=100000"
>> >> >> >> >>> print "Group 8: r>100000 && r<=1000000"
>> >> >> >> >>> print "Group 9: r>1000000"
>> >> >> >> >>>
>> >> >> >> >>> def printgroup(grp):
>> >> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
>> >> >> >> >>>
>> >> >> >> >>> for j in range(20):
>> >> >> >> >>>         r = random.randint(-1000,1001)
>> >> >> >> >>>         if r < 0:               printgroup(1); exit
>> >> >> >> >>>         if r > 1000000: printgroup(9); exit
>> >> >> >> >>>         comps =
>> >> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>> >> >> >> >>>         for i, x in enumerate(range(len(comps))):
>> >> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>> >> >> >> >>>                 i+=1
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
>> >> >> >> >> 
>> >> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
>> >> >> >> >> 
>> >> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
>> >> >> >> >> #include <stdio.h>
>> >> >> >> >> #include <stdlib.h>
>> >> >> >> >> 
>> >> >> >> >> void flz(void){printf("a<0\n");}
>> >> >> >> >> void fgm(void){printf("a>1000000\n");}
>> >> >> >> >> void f0(void){printf("a==0\n");}
>> >> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
>> >> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
>> >> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
>> >> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
>> >> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
>> >> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
>> >> >> >> >> 
>> >> >> >> >> int main(int argc, char *argv[])
>> >> >> >> >> {
>> >> >> >> >>     int a=0;
>> >> >> >> >>     int i=0;
>> >> >> >> >>     void (*fp[1000001])(void)={0};
>> >> >> >> >>     fp[0]=f0;
>> >> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
>> >> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
>> >> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
>> >> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
>> >> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
>> >> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>> >> >> >> >>     a=atoi(argv[1]);
>> >> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
>> >> >> >> >>     return 0;
>> >> >> >> >> }
>> >> >> >> >> anon@lowtide:~/code/ifs$
>> >> >> >> > 
>> >> >> >> > affirmative
>> >> >> >> > 
>> >> >> >> 
>> >> >> >> But who would write it that way, and why?  Sure, there's no if statements,
>> >> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
>> >> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
>> >> >> >> less readability.  It would run faster, use less stack, and be much more
>> >> >> >> readable and faster to design and write without error, by just using a
>> >> >> >> list of ifs.
>> >> >> >> 
>> >> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
>> >> >> >> a>100 && a<=1000
>> >> >> >> 
>> >> >> >> real    0m0.002s
>> >> >> >> user    0m0.000s
>> >> >> >> sys     0m0.000s
>> >> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
>> >> >> >> a>100 && a<=1000
>> >> >> >> 
>> >> >> >> real    0m0.020s
>> >> >> >> user    0m0.008s
>> >> >> >> sys     0m0.008s
>> >> >> >> anon@lowtide:~/code/ifs$
>> >> >> > 
>> >> >> > What are those times representing, your if/else vs the above (or his code)?
>> >> >> > 
>> >> >> 
>> >> >> if/else vs the above.
>> >> >> But you can combine the above with DFS's loop and it's just as fast.
>> >> > 
>> >> > Because what Feeb said about the complier is correct?
>> >> > 
>> >> 
>> >> I don't remember what fabtard said, but there is no performance advantage
>> >> to putting the ifs in a loop.  There may coding time advantage if the
>> >> the number of conditions is extreme, but a sequence of ifs would still
>> >> make what is happening more obvious, and for a relatively small number of
>> >> conditions the amount of time spent coding the loop might be greater --
>> >> just from care taken to get the array values right, off-by-one issues,
>> >> etc -- than a simple sequence of ifs, especially with an editor like
>> >> vim which makes code block skeletons so easy to duplicate.  Also, not
>> >> all if sequences are going to lend themselves to looping in a way that
>> >> would reduce the number of written conditions.
>> > 
>> > "For a REAL language, a COMPILED language, the compiler often 
>> > makes optimizing choices such as transforming your for-loop 
>> > into a sequence of if-then statements.  The user can also specify 
>> > that certain loops should be "unrolled" which leads to the 
>> > same behavior. 
>> > 
>> > In short, there is no great difference between a for-loop and 
>> > an "unrolled" loop sequence." - Feeb
>> > 
>> >> The code for the earlier doo.c, which was designed to remove all if
>> >> statements, would not even need the ternary conditional except for the
>> >> a<0 and a>1000000 tests. 
>> > 
>> > From what very little I've read on if vs ternary in C, there isn't much of 
>> > a performance diff (apparently there can be some in certain conditions).
>> > 
>> >> The rest of it just uses the number passed in
>> >> as an index into the function pointer array.  But that array is huge,
>> >> and there is a big performance hit, so minimizing the number of ifs is
>> >> not necessarily a good thing.
>> > 
>> > What's worse are the if/else if statements written inside of loops (like I 
>> > had in my earliest example in this thread). But hey, it's JavaScript, no 
>> > one expects it to run fast anyway ;) I was actually surprised by FF, it
>> > was doing 100 million elements in 3-4 seconds *in* a browser (so 
>> > we're talking DOM elements here, not just array elements)... a billion
>> > in ~34.3 secs. What the best time you've gotten in C for such a task?
>> 
>> Just looping, it looks like about 400 million per second:
>> 
>> anon@lowtide:~/code/ifs$ cat loop.c
>> #include <stdio.h>
>> 
>> int main(void)
>> {
>>   int i=0;
>>   printf("start\n");
>>   for(i=0;i<1000000000;i++)
>>   {
>>    ;
>>   }
>>   printf("done\n");
>>   return 0;
>> }
>> anon@lowtide:~/code/ifs$ time ./loop
>> start
>> done
>> 
>> real    0m2.501s
>> user    0m2.496s
>> sys     0m0.004s
>> anon@lowtide:~/code/ifs$
> 
> <https://imgur.com/a/hT5B6QQ>
> 
> Chrome (on the left) in ~1 sec, but FF was well over 5x slower. WTF!?
> 

Damn, one sec.  That's fast.  I'm not sure I trust that timer though.
https://johnresig.com/blog/accuracy-of-javascript-time/

The console stuff is flakey on my versions of chrome and ff.  Running your
code with nodejs gives times roughly equal to the C code.


> What about if you were creating arrays elements?

malloc'ed 1GB for a char pointer, and set each char to 'a', and it's
only about ten percent slower than just running the empty loop.

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

#465495

owl <owl@rooftop.invalid> wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:

>> What about if you were creating arrays elements?
> 
> malloc'ed 1GB for a char pointer, and set each char to 'a', and it's
> only about ten percent slower than just running the empty loop.
> 

Similarly, setting stack size limit to 2GB and filling a 1GB char array
takes about 2.5 sec.

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

#465499

On Saturday, September 1, 2018 at 7:45:18 AM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Friday, August 31, 2018 at 11:53:16 AM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
> >> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
> >> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >> >> > On 8/29/2018 2:14 AM, owl wrote:
> >> >> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >> >> >>>
> >> >> >> >> >>> import random
> >> >> >> >> >>>
> >> >> >> >> >>> print "Group 1: r<0"
> >> >> >> >> >>> print "Group 2: r==0"
> >> >> >> >> >>> print "Group 3: r>0 && r<=10"
> >> >> >> >> >>> print "Group 4: r>10 && r<=100"
> >> >> >> >> >>> print "Group 5: r>100 && r<=1000"
> >> >> >> >> >>> print "Group 6: r>1000 && r<=10000"
> >> >> >> >> >>> print "Group 7: r>10000 && r<=100000"
> >> >> >> >> >>> print "Group 8: r>100000 && r<=1000000"
> >> >> >> >> >>> print "Group 9: r>1000000"
> >> >> >> >> >>>
> >> >> >> >> >>> def printgroup(grp):
> >> >> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
> >> >> >> >> >>>
> >> >> >> >> >>> for j in range(20):
> >> >> >> >> >>>         r = random.randint(-1000,1001)
> >> >> >> >> >>>         if r < 0:               printgroup(1); exit
> >> >> >> >> >>>         if r > 1000000: printgroup(9); exit
> >> >> >> >> >>>         comps =
> >> >> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
> >> >> >> >> >>>         for i, x in enumerate(range(len(comps))):
> >> >> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
> >> >> >> >> >>>                 i+=1
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
> >> >> >> >> >> 
> >> >> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
> >> >> >> >> >> 
> >> >> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
> >> >> >> >> >> #include <stdio.h>
> >> >> >> >> >> #include <stdlib.h>
> >> >> >> >> >> 
> >> >> >> >> >> void flz(void){printf("a<0\n");}
> >> >> >> >> >> void fgm(void){printf("a>1000000\n");}
> >> >> >> >> >> void f0(void){printf("a==0\n");}
> >> >> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
> >> >> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
> >> >> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
> >> >> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
> >> >> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
> >> >> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
> >> >> >> >> >> 
> >> >> >> >> >> int main(int argc, char *argv[])
> >> >> >> >> >> {
> >> >> >> >> >>     int a=0;
> >> >> >> >> >>     int i=0;
> >> >> >> >> >>     void (*fp[1000001])(void)={0};
> >> >> >> >> >>     fp[0]=f0;
> >> >> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
> >> >> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
> >> >> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
> >> >> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
> >> >> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
> >> >> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
> >> >> >> >> >>     a=atoi(argv[1]);
> >> >> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
> >> >> >> >> >>     return 0;
> >> >> >> >> >> }
> >> >> >> >> >> anon@lowtide:~/code/ifs$
> >> >> >> >> > 
> >> >> >> >> > affirmative
> >> >> >> >> > 
> >> >> >> >> 
> >> >> >> >> But who would write it that way, and why?  Sure, there's no if statements,
> >> >> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
> >> >> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
> >> >> >> >> less readability.  It would run faster, use less stack, and be much more
> >> >> >> >> readable and faster to design and write without error, by just using a
> >> >> >> >> list of ifs.
> >> >> >> >> 
> >> >> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
> >> >> >> >> a>100 && a<=1000
> >> >> >> >> 
> >> >> >> >> real    0m0.002s
> >> >> >> >> user    0m0.000s
> >> >> >> >> sys     0m0.000s
> >> >> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
> >> >> >> >> a>100 && a<=1000
> >> >> >> >> 
> >> >> >> >> real    0m0.020s
> >> >> >> >> user    0m0.008s
> >> >> >> >> sys     0m0.008s
> >> >> >> >> anon@lowtide:~/code/ifs$
> >> >> >> > 
> >> >> >> > What are those times representing, your if/else vs the above (or his code)?
> >> >> >> > 
> >> >> >> 
> >> >> >> if/else vs the above.
> >> >> >> But you can combine the above with DFS's loop and it's just as fast.
> >> >> > 
> >> >> > Because what Feeb said about the complier is correct?
> >> >> > 
> >> >> 
> >> >> I don't remember what fabtard said, but there is no performance advantage
> >> >> to putting the ifs in a loop.  There may coding time advantage if the
> >> >> the number of conditions is extreme, but a sequence of ifs would still
> >> >> make what is happening more obvious, and for a relatively small number of
> >> >> conditions the amount of time spent coding the loop might be greater --
> >> >> just from care taken to get the array values right, off-by-one issues,
> >> >> etc -- than a simple sequence of ifs, especially with an editor like
> >> >> vim which makes code block skeletons so easy to duplicate.  Also, not
> >> >> all if sequences are going to lend themselves to looping in a way that
> >> >> would reduce the number of written conditions.
> >> > 
> >> > "For a REAL language, a COMPILED language, the compiler often 
> >> > makes optimizing choices such as transforming your for-loop 
> >> > into a sequence of if-then statements.  The user can also specify 
> >> > that certain loops should be "unrolled" which leads to the 
> >> > same behavior. 
> >> > 
> >> > In short, there is no great difference between a for-loop and 
> >> > an "unrolled" loop sequence." - Feeb
> >> > 
> >> >> The code for the earlier doo.c, which was designed to remove all if
> >> >> statements, would not even need the ternary conditional except for the
> >> >> a<0 and a>1000000 tests. 
> >> > 
> >> > From what very little I've read on if vs ternary in C, there isn't much of 
> >> > a performance diff (apparently there can be some in certain conditions).
> >> > 
> >> >> The rest of it just uses the number passed in
> >> >> as an index into the function pointer array.  But that array is huge,
> >> >> and there is a big performance hit, so minimizing the number of ifs is
> >> >> not necessarily a good thing.
> >> > 
> >> > What's worse are the if/else if statements written inside of loops (like I 
> >> > had in my earliest example in this thread). But hey, it's JavaScript, no 
> >> > one expects it to run fast anyway ;) I was actually surprised by FF, it
> >> > was doing 100 million elements in 3-4 seconds *in* a browser (so 
> >> > we're talking DOM elements here, not just array elements)... a billion
> >> > in ~34.3 secs. What the best time you've gotten in C for such a task?
> >> 
> >> Just looping, it looks like about 400 million per second:
> >> 
> >> anon@lowtide:~/code/ifs$ cat loop.c
> >> #include <stdio.h>
> >> 
> >> int main(void)
> >> {
> >>   int i=0;
> >>   printf("start\n");
> >>   for(i=0;i<1000000000;i++)
> >>   {
> >>    ;
> >>   }
> >>   printf("done\n");
> >>   return 0;
> >> }
> >> anon@lowtide:~/code/ifs$ time ./loop
> >> start
> >> done
> >> 
> >> real    0m2.501s
> >> user    0m2.496s
> >> sys     0m0.004s
> >> anon@lowtide:~/code/ifs$
> > 
> > <https://imgur.com/a/hT5B6QQ>
> > 
> > Chrome (on the left) in ~1 sec, but FF was well over 5x slower. WTF!?
> > 
> 
> Damn, one sec.  That's fast.  I'm not sure I trust that timer though.
> https://johnresig.com/blog/accuracy-of-javascript-time/

Yeah, I've heard about this, not good for super high ms accuracy. 
There's actually a performance API that's supposed to provide a
higher accuracy but I've never used it. In general, date and time 
stuff in JavaScript isn't nearly as dialed in as it could be (do a
search on JavaScript's 'Date' data type).

> The console stuff is flakey on my versions of chrome and ff.

How so?

> Running your
> code with nodejs gives times roughly equal to the C code.

I knew it (that you run node.js)! ;)

> > What about if you were creating arrays elements?
> 
> malloc'ed 1GB for a char pointer, and set each char to 'a', and it's
> only about ten percent slower than just running the empty loop.

Amazing!

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

#465502

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Saturday, September 1, 2018 at 7:45:18 AM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> wrote:
>> > On Friday, August 31, 2018 at 11:53:16 AM UTC-6, owl wrote:
>> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> > On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
>> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
>> >> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
>> >> >> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
>> >> >> >> >> DFS <nospam@nospam.com> wrote:
>> >> >> >> >> > On 8/29/2018 2:14 AM, owl wrote:
>> >> >> >> >> >> DFS <nospam@nospam.com> wrote:
>> >> >> >> >> >>>
>> >> >> >> >> >>> import random
>> >> >> >> >> >>>
>> >> >> >> >> >>> print "Group 1: r<0"
>> >> >> >> >> >>> print "Group 2: r==0"
>> >> >> >> >> >>> print "Group 3: r>0 && r<=10"
>> >> >> >> >> >>> print "Group 4: r>10 && r<=100"
>> >> >> >> >> >>> print "Group 5: r>100 && r<=1000"
>> >> >> >> >> >>> print "Group 6: r>1000 && r<=10000"
>> >> >> >> >> >>> print "Group 7: r>10000 && r<=100000"
>> >> >> >> >> >>> print "Group 8: r>100000 && r<=1000000"
>> >> >> >> >> >>> print "Group 9: r>1000000"
>> >> >> >> >> >>>
>> >> >> >> >> >>> def printgroup(grp):
>> >> >> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
>> >> >> >> >> >>>
>> >> >> >> >> >>> for j in range(20):
>> >> >> >> >> >>>         r = random.randint(-1000,1001)
>> >> >> >> >> >>>         if r < 0:               printgroup(1); exit
>> >> >> >> >> >>>         if r > 1000000: printgroup(9); exit
>> >> >> >> >> >>>         comps =
>> >> >> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
>> >> >> >> >> >>>         for i, x in enumerate(range(len(comps))):
>> >> >> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
>> >> >> >> >> >>>                 i+=1
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
>> >> >> >> >> >> 
>> >> >> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
>> >> >> >> >> >> 
>> >> >> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
>> >> >> >> >> >> #include <stdio.h>
>> >> >> >> >> >> #include <stdlib.h>
>> >> >> >> >> >> 
>> >> >> >> >> >> void flz(void){printf("a<0\n");}
>> >> >> >> >> >> void fgm(void){printf("a>1000000\n");}
>> >> >> >> >> >> void f0(void){printf("a==0\n");}
>> >> >> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
>> >> >> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
>> >> >> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
>> >> >> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
>> >> >> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
>> >> >> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
>> >> >> >> >> >> 
>> >> >> >> >> >> int main(int argc, char *argv[])
>> >> >> >> >> >> {
>> >> >> >> >> >>     int a=0;
>> >> >> >> >> >>     int i=0;
>> >> >> >> >> >>     void (*fp[1000001])(void)={0};
>> >> >> >> >> >>     fp[0]=f0;
>> >> >> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
>> >> >> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
>> >> >> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
>> >> >> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
>> >> >> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
>> >> >> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
>> >> >> >> >> >>     a=atoi(argv[1]);
>> >> >> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
>> >> >> >> >> >>     return 0;
>> >> >> >> >> >> }
>> >> >> >> >> >> anon@lowtide:~/code/ifs$
>> >> >> >> >> > 
>> >> >> >> >> > affirmative
>> >> >> >> >> > 
>> >> >> >> >> 
>> >> >> >> >> But who would write it that way, and why?  Sure, there's no if statements,
>> >> >> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
>> >> >> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
>> >> >> >> >> less readability.  It would run faster, use less stack, and be much more
>> >> >> >> >> readable and faster to design and write without error, by just using a
>> >> >> >> >> list of ifs.
>> >> >> >> >> 
>> >> >> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
>> >> >> >> >> a>100 && a<=1000
>> >> >> >> >> 
>> >> >> >> >> real    0m0.002s
>> >> >> >> >> user    0m0.000s
>> >> >> >> >> sys     0m0.000s
>> >> >> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
>> >> >> >> >> a>100 && a<=1000
>> >> >> >> >> 
>> >> >> >> >> real    0m0.020s
>> >> >> >> >> user    0m0.008s
>> >> >> >> >> sys     0m0.008s
>> >> >> >> >> anon@lowtide:~/code/ifs$
>> >> >> >> > 
>> >> >> >> > What are those times representing, your if/else vs the above (or his code)?
>> >> >> >> > 
>> >> >> >> 
>> >> >> >> if/else vs the above.
>> >> >> >> But you can combine the above with DFS's loop and it's just as fast.
>> >> >> > 
>> >> >> > Because what Feeb said about the complier is correct?
>> >> >> > 
>> >> >> 
>> >> >> I don't remember what fabtard said, but there is no performance advantage
>> >> >> to putting the ifs in a loop.  There may coding time advantage if the
>> >> >> the number of conditions is extreme, but a sequence of ifs would still
>> >> >> make what is happening more obvious, and for a relatively small number of
>> >> >> conditions the amount of time spent coding the loop might be greater --
>> >> >> just from care taken to get the array values right, off-by-one issues,
>> >> >> etc -- than a simple sequence of ifs, especially with an editor like
>> >> >> vim which makes code block skeletons so easy to duplicate.  Also, not
>> >> >> all if sequences are going to lend themselves to looping in a way that
>> >> >> would reduce the number of written conditions.
>> >> > 
>> >> > "For a REAL language, a COMPILED language, the compiler often 
>> >> > makes optimizing choices such as transforming your for-loop 
>> >> > into a sequence of if-then statements.  The user can also specify 
>> >> > that certain loops should be "unrolled" which leads to the 
>> >> > same behavior. 
>> >> > 
>> >> > In short, there is no great difference between a for-loop and 
>> >> > an "unrolled" loop sequence." - Feeb
>> >> > 
>> >> >> The code for the earlier doo.c, which was designed to remove all if
>> >> >> statements, would not even need the ternary conditional except for the
>> >> >> a<0 and a>1000000 tests. 
>> >> > 
>> >> > From what very little I've read on if vs ternary in C, there isn't much of 
>> >> > a performance diff (apparently there can be some in certain conditions).
>> >> > 
>> >> >> The rest of it just uses the number passed in
>> >> >> as an index into the function pointer array.  But that array is huge,
>> >> >> and there is a big performance hit, so minimizing the number of ifs is
>> >> >> not necessarily a good thing.
>> >> > 
>> >> > What's worse are the if/else if statements written inside of loops (like I 
>> >> > had in my earliest example in this thread). But hey, it's JavaScript, no 
>> >> > one expects it to run fast anyway ;) I was actually surprised by FF, it
>> >> > was doing 100 million elements in 3-4 seconds *in* a browser (so 
>> >> > we're talking DOM elements here, not just array elements)... a billion
>> >> > in ~34.3 secs. What the best time you've gotten in C for such a task?
>> >> 
>> >> Just looping, it looks like about 400 million per second:
>> >> 
>> >> anon@lowtide:~/code/ifs$ cat loop.c
>> >> #include <stdio.h>
>> >> 
>> >> int main(void)
>> >> {
>> >>   int i=0;
>> >>   printf("start\n");
>> >>   for(i=0;i<1000000000;i++)
>> >>   {
>> >>    ;
>> >>   }
>> >>   printf("done\n");
>> >>   return 0;
>> >> }
>> >> anon@lowtide:~/code/ifs$ time ./loop
>> >> start
>> >> done
>> >> 
>> >> real    0m2.501s
>> >> user    0m2.496s
>> >> sys     0m0.004s
>> >> anon@lowtide:~/code/ifs$
>> > 
>> > <https://imgur.com/a/hT5B6QQ>
>> > 
>> > Chrome (on the left) in ~1 sec, but FF was well over 5x slower. WTF!?
>> > 
>> 
>> Damn, one sec.  That's fast.  I'm not sure I trust that timer though.
>> https://johnresig.com/blog/accuracy-of-javascript-time/
> 
> Yeah, I've heard about this, not good for super high ms accuracy. 
> There's actually a performance API that's supposed to provide a
> higher accuracy but I've never used it. In general, date and time 
> stuff in JavaScript isn't nearly as dialed in as it could be (do a
> search on JavaScript's 'Date' data type).
> 
>> The console stuff is flakey on my versions of chrome and ff.
> 
> How so?
> 

Firefox throws errors won't run at all.
Chrome returns instantly but says loop time is: 2.39e+4ms


>> Running your
>> code with nodejs gives times roughly equal to the C code.
> 
> I knew it (that you run node.js)! ;)
> 

Compile my C and compare since your browser consoles seem to work.

>> > What about if you were creating arrays elements?
>> 
>> malloc'ed 1GB for a char pointer, and set each char to 'a', and it's
>> only about ten percent slower than just running the empty loop.
> 
> Amazing!

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

#465515

On Saturday, September 1, 2018 at 10:00:48 AM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> wrote:
> > On Saturday, September 1, 2018 at 7:45:18 AM UTC-6, owl wrote:
> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> > On Friday, August 31, 2018 at 11:53:16 AM UTC-6, owl wrote:
> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> > On Friday, August 31, 2018 at 10:53:35 AM UTC-6, owl wrote:
> >> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >> > On Friday, August 31, 2018 at 6:33:13 AM UTC-6, owl wrote:
> >> >> >> >> Steve Carroll <fretwizzer@gmail.com> wrote:
> >> >> >> >> > On Wednesday, August 29, 2018 at 8:31:19 AM UTC-6, owl wrote:
> >> >> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >> >> >> > On 8/29/2018 2:14 AM, owl wrote:
> >> >> >> >> >> >> DFS <nospam@nospam.com> wrote:
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> import random
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> print "Group 1: r<0"
> >> >> >> >> >> >>> print "Group 2: r==0"
> >> >> >> >> >> >>> print "Group 3: r>0 && r<=10"
> >> >> >> >> >> >>> print "Group 4: r>10 && r<=100"
> >> >> >> >> >> >>> print "Group 5: r>100 && r<=1000"
> >> >> >> >> >> >>> print "Group 6: r>1000 && r<=10000"
> >> >> >> >> >> >>> print "Group 7: r>10000 && r<=100000"
> >> >> >> >> >> >>> print "Group 8: r>100000 && r<=1000000"
> >> >> >> >> >> >>> print "Group 9: r>1000000"
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> def printgroup(grp):
> >> >> >> >> >> >>>         print "Found random number " + str(r) + " in Group " + str(grp)
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> for j in range(20):
> >> >> >> >> >> >>>         r = random.randint(-1000,1001)
> >> >> >> >> >> >>>         if r < 0:               printgroup(1); exit
> >> >> >> >> >> >>>         if r > 1000000: printgroup(9); exit
> >> >> >> >> >> >>>         comps =
> >> >> >> >> >> >>> [(-1,0),(1,10),(11,100),(101,1000),(1001,10000),(10001,100000),(100001,1000000)]
> >> >> >> >> >> >>>         for i, x in enumerate(range(len(comps))):
> >> >> >> >> >> >>>                 if r > comps[i][0] and r <= comps[i][1]: printgroup(i+2); exit
> >> >> >> >> >> >>>                 i+=1
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> That's 3 if-then-exits to handle 9 comparisons
> >> >> >> >> >> >> 
> >> >> >> >> >> >> If you call that 3 ifs, then I get to call this zero ifs:
> >> >> >> >> >> >> 
> >> >> >> >> >> >> anon@lowtide:~/code/ifs$ cat goo.c
> >> >> >> >> >> >> #include <stdio.h>
> >> >> >> >> >> >> #include <stdlib.h>
> >> >> >> >> >> >> 
> >> >> >> >> >> >> void flz(void){printf("a<0\n");}
> >> >> >> >> >> >> void fgm(void){printf("a>1000000\n");}
> >> >> >> >> >> >> void f0(void){printf("a==0\n");}
> >> >> >> >> >> >> void f1(void){printf("a>0 && a<=10\n");}
> >> >> >> >> >> >> void f2(void){printf("a>10 && a<=100\n");}
> >> >> >> >> >> >> void f3(void){printf("a>100 && a<=1000\n");}
> >> >> >> >> >> >> void f4(void){printf("a>1000 && a<=10000\n");}
> >> >> >> >> >> >> void f5(void){printf("a>10000 && a<=100000\n");}
> >> >> >> >> >> >> void f6(void){printf("a>100000 && a<=1000000\n");}
> >> >> >> >> >> >> 
> >> >> >> >> >> >> int main(int argc, char *argv[])
> >> >> >> >> >> >> {
> >> >> >> >> >> >>     int a=0;
> >> >> >> >> >> >>     int i=0;
> >> >> >> >> >> >>     void (*fp[1000001])(void)={0};
> >> >> >> >> >> >>     fp[0]=f0;
> >> >> >> >> >> >>     for(i=1;i<=10;i++) fp[i]=f1;
> >> >> >> >> >> >>     for(i=11;i<=100;i++) fp[i]=f2;
> >> >> >> >> >> >>     for(i=101;i<=1000;i++) fp[i]=f3;
> >> >> >> >> >> >>     for(i=1001;i<=10000;i++) fp[i]=f4;
> >> >> >> >> >> >>     for(i=10001;i<=100000;i++) fp[i]=f5;
> >> >> >> >> >> >>     for(i=100001;i<=1000000;i++) fp[i]=f6;
> >> >> >> >> >> >>     a=atoi(argv[1]);
> >> >> >> >> >> >>     (a<0?flz:a>1000000?fgm:fp[a])();
> >> >> >> >> >> >>     return 0;
> >> >> >> >> >> >> }
> >> >> >> >> >> >> anon@lowtide:~/code/ifs$
> >> >> >> >> >> > 
> >> >> >> >> >> > affirmative
> >> >> >> >> >> > 
> >> >> >> >> >> 
> >> >> >> >> >> But who would write it that way, and why?  Sure, there's no if statements,
> >> >> >> >> >> but that comes at the expense of 1,000,001 function pointers.  And the
> >> >> >> >> >> nested ternaries constitute conditional tests anyway.  Not to mention
> >> >> >> >> >> less readability.  It would run faster, use less stack, and be much more
> >> >> >> >> >> readable and faster to design and write without error, by just using a
> >> >> >> >> >> list of ifs.
> >> >> >> >> >> 
> >> >> >> >> >> anon@lowtide:~/code/ifs$ time ./blah 500
> >> >> >> >> >> a>100 && a<=1000
> >> >> >> >> >> 
> >> >> >> >> >> real    0m0.002s
> >> >> >> >> >> user    0m0.000s
> >> >> >> >> >> sys     0m0.000s
> >> >> >> >> >> anon@lowtide:~/code/ifs$ time ./goo 500
> >> >> >> >> >> a>100 && a<=1000
> >> >> >> >> >> 
> >> >> >> >> >> real    0m0.020s
> >> >> >> >> >> user    0m0.008s
> >> >> >> >> >> sys     0m0.008s
> >> >> >> >> >> anon@lowtide:~/code/ifs$
> >> >> >> >> > 
> >> >> >> >> > What are those times representing, your if/else vs the above (or his code)?
> >> >> >> >> > 
> >> >> >> >> 
> >> >> >> >> if/else vs the above.
> >> >> >> >> But you can combine the above with DFS's loop and it's just as fast.
> >> >> >> > 
> >> >> >> > Because what Feeb said about the complier is correct?
> >> >> >> > 
> >> >> >> 
> >> >> >> I don't remember what fabtard said, but there is no performance advantage
> >> >> >> to putting the ifs in a loop.  There may coding time advantage if the
> >> >> >> the number of conditions is extreme, but a sequence of ifs would still
> >> >> >> make what is happening more obvious, and for a relatively small number of
> >> >> >> conditions the amount of time spent coding the loop might be greater --
> >> >> >> just from care taken to get the array values right, off-by-one issues,
> >> >> >> etc -- than a simple sequence of ifs, especially with an editor like
> >> >> >> vim which makes code block skeletons so easy to duplicate.  Also, not
> >> >> >> all if sequences are going to lend themselves to looping in a way that
> >> >> >> would reduce the number of written conditions.
> >> >> > 
> >> >> > "For a REAL language, a COMPILED language, the compiler often 
> >> >> > makes optimizing choices such as transforming your for-loop 
> >> >> > into a sequence of if-then statements.  The user can also specify 
> >> >> > that certain loops should be "unrolled" which leads to the 
> >> >> > same behavior. 
> >> >> > 
> >> >> > In short, there is no great difference between a for-loop and 
> >> >> > an "unrolled" loop sequence." - Feeb
> >> >> > 
> >> >> >> The code for the earlier doo.c, which was designed to remove all if
> >> >> >> statements, would not even need the ternary conditional except for the
> >> >> >> a<0 and a>1000000 tests. 
> >> >> > 
> >> >> > From what very little I've read on if vs ternary in C, there isn't much of 
> >> >> > a performance diff (apparently there can be some in certain conditions).
> >> >> > 
> >> >> >> The rest of it just uses the number passed in
> >> >> >> as an index into the function pointer array.  But that array is huge,
> >> >> >> and there is a big performance hit, so minimizing the number of ifs is
> >> >> >> not necessarily a good thing.
> >> >> > 
> >> >> > What's worse are the if/else if statements written inside of loops (like I 
> >> >> > had in my earliest example in this thread). But hey, it's JavaScript, no 
> >> >> > one expects it to run fast anyway ;) I was actually surprised by FF, it
> >> >> > was doing 100 million elements in 3-4 seconds *in* a browser (so 
> >> >> > we're talking DOM elements here, not just array elements)... a billion
> >> >> > in ~34.3 secs. What the best time you've gotten in C for such a task?
> >> >> 
> >> >> Just looping, it looks like about 400 million per second:
> >> >> 
> >> >> anon@lowtide:~/code/ifs$ cat loop.c
> >> >> #include <stdio.h>
> >> >> 
> >> >> int main(void)
> >> >> {
> >> >>   int i=0;
> >> >>   printf("start\n");
> >> >>   for(i=0;i<1000000000;i++)
> >> >>   {
> >> >>    ;
> >> >>   }
> >> >>   printf("done\n");
> >> >>   return 0;
> >> >> }
> >> >> anon@lowtide:~/code/ifs$ time ./loop
> >> >> start
> >> >> done
> >> >> 
> >> >> real    0m2.501s
> >> >> user    0m2.496s
> >> >> sys     0m0.004s
> >> >> anon@lowtide:~/code/ifs$
> >> > 
> >> > <https://imgur.com/a/hT5B6QQ>
> >> > 
> >> > Chrome (on the left) in ~1 sec, but FF was well over 5x slower. WTF!?
> >> > 
> >> 
> >> Damn, one sec.  That's fast.  I'm not sure I trust that timer though.
> >> https://johnresig.com/blog/accuracy-of-javascript-time/
> > 
> > Yeah, I've heard about this, not good for super high ms accuracy. 
> > There's actually a performance API that's supposed to provide a
> > higher accuracy but I've never used it. In general, date and time 
> > stuff in JavaScript isn't nearly as dialed in as it could be (do a
> > search on JavaScript's 'Date' data type).
> > 
> >> The console stuff is flakey on my versions of chrome and ff.
> > 
> > How so?
> > 
> 
> Firefox throws errors won't run at all.
> Chrome returns instantly but says loop time is: 2.39e+4ms
> 
> 
> >> Running your
> >> code with nodejs gives times roughly equal to the C code.
> > 
> > I knew it (that you run node.js)! ;)
> > 
> 
> Compile my C and compare since your browser consoles seem to work.

Can't do it... too busy... I had to make this for Feeb:

<http://s000.tinyupload.com/?file_id=01895889857412694957>

It took hours and hours of "programming" ;)

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

#465466

On 8/29/2018 10:31 AM, owl wrote:
> DFS <nospam@nospam.com> wrote:
>> On 8/29/2018 2:14 AM, owl wrote:
>>> DFS <nospam@nospam.com> wrote:
>
>> affirmative


> But who would write it that way, and why?  

Someone drunk at 2:14am, because they were drunk.


> Sure, there's no if statements,
> but that comes at the expense of 1,000,001 function pointers.  And the
> nested ternaries constitute conditional tests anyway.  Not to mention
> less readability.  It would run faster, use less stack, and be much more
> readable and faster to design and write without error, by just using a
> list of ifs.

Congrats on beating up your own strawman.

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

#465469

DFS <nospam@nospam.com> wrote:
> On 8/29/2018 10:31 AM, owl wrote:
>> DFS <nospam@nospam.com> wrote:
>>> On 8/29/2018 2:14 AM, owl wrote:
>>>> DFS <nospam@nospam.com> wrote:
>>
>>> affirmative
> 
> 
>> But who would write it that way, and why?  
> 
> Someone drunk at 2:14am, because they were drunk.
> 
> 
>> Sure, there's no if statements,
>> but that comes at the expense of 1,000,001 function pointers.  And the
>> nested ternaries constitute conditional tests anyway.  Not to mention
>> less readability.  It would run faster, use less stack, and be much more
>> readable and faster to design and write without error, by just using a
>> list of ifs.
> 
> Congrats on beating up your own strawman.

How so?  I showed that striving for some subjective code "elegance" by
reducing the number of visible ifs (your desire), when carried to the
extreme of zero, is detrimental to performance.  Your code contains the
same number of conditional tests in the loop as would be run without
the loop, takes longer to code, is more prone to errors in construction,
is arguably less readable, is less flexible in condition actions, and
provides no performance benefit.  But somehow that makes it more elegant
than a straight if/else sequence?

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

#465497

On 8/31/2018 3:40 PM, owl wrote:
> DFS <nospam@nospam.com> wrote:
>> On 8/29/2018 10:31 AM, owl wrote:
>>> DFS <nospam@nospam.com> wrote:
>>>> On 8/29/2018 2:14 AM, owl wrote:
>>>>> DFS <nospam@nospam.com> wrote:
>>>
>>>> affirmative
>>
>>
>>> But who would write it that way, and why?
>>
>> Someone drunk at 2:14am, because they were drunk.
>>
>>
>>> Sure, there's no if statements,
>>> but that comes at the expense of 1,000,001 function pointers.  And the
>>> nested ternaries constitute conditional tests anyway.  Not to mention
>>> less readability.  It would run faster, use less stack, and be much more
>>> readable and faster to design and write without error, by just using a
>>> list of ifs.
>>
>> Congrats on beating up your own strawman.
> 
> How so?  I showed that striving for some subjective code "elegance" by
> reducing the number of visible ifs (your desire), when carried to the
> extreme of zero, is detrimental to performance.  

'when carried to the extreme'... strawman in the house!


> Your code contains the
> same number of conditional tests in the loop as would be run without
> the loop, takes longer to code, is more prone to errors in construction,
> is arguably less readable, is less flexible in condition actions, and
> provides no performance benefit.  But somehow that makes it more elegant
> than a straight if/else sequence?


Are you arguing just to argue?  Or did Feeb promise favors?

'Cause his stupid hard-coded one if-then-else for each income bracket is 
silly.  Each year he has to check if the code corresponds one-on-one to 
the number of income brackets.

I'm reasonable; in the past this was my typical code for setting dates 
on an Access screen, after you choose from a list of date periods:

Public Function getStartDate(period As String) As Date
If period = "YTD" Then
   getStartDate = "01-Jan-" & DatePart("yyyy", Date)
  ElseIf period = "Today"         Then getStartDate = Date
  ElseIf period = "Yesterday"     Then getStartDate = Date - 1
  ElseIf period = "Last Week"     Then getStartDate = Date - 6
  ElseIf period = "Last 2 Weeks"  Then getStartDate = Date - 13
  ElseIf period = "Last Month"    Then getStartDate = Date - 30
  ElseIf period = "Last 3 Months" Then getStartDate = Date - 90
  ElseIf period = "Last 6 Months" Then getStartDate = Date - 180
  ElseIf period = "Last Year"     Then getStartDate = Date - 365
  ElseIf period = "Last 2 Years"  Then getStartDate = Date - (365 * 2)
  ElseIf period = "Last 3 Years"  Then getStartDate = Date - (365 * 3)
  ElseIf period = "Last 4 Years"  Then getStartDate = Date - (365 * 4)
  ElseIf period = "Last 5 Years"  Then getStartDate = Date - (365 * 5)
  ElseIf period = "Last 10 Years" Then getStartDate = Date - (365 * 10)
  ElseIf period = "Last 15 Years" Then getStartDate = Date - (365 * 15)
End If

End Function


I could make a couple clunky for...loops, but in this case it's 
inappropriate.

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

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

Back to top | Article view | comp.os.linux.advocacy

csiph-web