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 1 of 3  [1] 2 3  Next page →

#465275 — Re: The substantiation that -highhorse asked for

On 12/4/2017 2:11 PM, fr314159@gmail.com wrote:

> This reminds me of something that happened during a university
> class in Introductory Programming (using C of course).
>
> We were in the midst of various programming assignments that
> involved nested if-then-else statements.  One of the students
> who was having trouble began to protest claiming that studies
> have shown that the human brain cannot efficiently comprehend
> nesting levels that are more than three or four levels deep.
> Therefore, he claimed, the class should not have to do such
> assignments.
>
> Needless to say most of the other students just laughed at his
> misery.


Most students laughed... but you sat there stone-faced and silent and 
thought deeply about your VBA tax "program" and tried to remember how 
many levels of if-then-else shitcode you had written.

https://imgur.com/a/JWTIK

Linux makes you stupid.

[toc] | [next] | [standalone]

#465298

On Tuesday, August 28, 2018 at 6:27:59 AM UTC-6, DFS wrote:
> On 12/4/2017 2:11 PM, fr314159@gmail.com wrote:
> 
> > This reminds me of something that happened during a university
> > class in Introductory Programming (using C of course).
> >
> > We were in the midst of various programming assignments that
> > involved nested if-then-else statements.  One of the students
> > who was having trouble began to protest claiming that studies
> > have shown that the human brain cannot efficiently comprehend
> > nesting levels that are more than three or four levels deep.
> > Therefore, he claimed, the class should not have to do such
> > assignments.
> >
> > Needless to say most of the other students just laughed at his
> > misery.
> 
> 
> Most students laughed... but you sat there stone-faced and silent and 
> thought deeply about your VBA tax "program" and tried to remember how 
> many levels of if-then-else shitcode you had written.
> 
> https://imgur.com/a/JWTIK
> 
> Linux makes you stupid.

I once found the need to write this...

    if(data.classData) {classData = data.classData.split('\u229f')} else {return} 
    if(classData[0]) {classData_0 = classData[0].split('\u22A1')} 
    if(classData[1]) {classData_1 = classData[1].split('\u22A0')} 
    if(classData[2]) {classData_2 = classData[2].split('\u22A1')} 
    if(classData[4]) {classData_4 = classData[4].split('\u22A1')} 
    if(classData[10]) {classData_10 = classData[10].split('\u22A0')} 
    if(classData[11]) {classData_11 = classData[11].split('\u22A0')} 
    if(classData[12]) {classData_12 = classData[12].split('\u22A0')} 
    if(data.weaponList){weaponList = data.weaponList.split('\u22A0')} 
    if(data.skillInfo){skillInfo = data.skillInfo.split('\u22A0')} 
    if(data.spellList){spellList = data.spellList.split('\u22A1')} 
    if(data.abilityScores){abilityScores = data.abilityScores.split('\u22A0')} 
    if(data.noteList){noteList = data.noteList.split('\u22A0')} 
    if(data.hitDiceList){hitDiceList = data.hitDiceList.split('\u22A0')} 
    if(data.classResource){classResource = data.classResource.split('\u22A0')} 

... but I questioned whether it made sense to...

let cdArr1 = [0,1,2,4,10,11,12,'weaponList','skillInfo','abilityScores','noteList', 
'hitDiceList','classResource','spellList'], resultArr = [] 
    for(let member of cdArr1 ) { 
      if(classData[member]) { 
        classData[member] = classData[member].split('\u22A0') 
        resultArr.push(classData[member]) 
      } else if(member === 'spellList') { 
        char[member] = char[member].split('\u22A1') 
        resultArr.push(char[member]) 
      } else if(member === 0 || member === 2 || member === 4) { 
        classData[member] = classData[member].split('\u22A1') 
        resultArr.push(classData[member]) 
      } else { 
        char[member] = char[member].split('\u22A0') 
        resultArr.push(char[member]) 
      } 
    } 

The former is definitely more readable but if you had a ton of statements 
to deal with, you'd probably wanna spend the time for the latter, if not... 
maybe you shouldn't bother (unless doing so for a COLA pissing contest). 
What's your cutoff point (and why)?

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

#465326

On Tuesday, August 28, 2018 at 12:20:09 PM UTC-4, Steve Carroll wrote:

> 
> The former is definitely more readable but if you had a ton of statements 
> to deal with, you'd probably wanna spend the time for the latter
>

At the machine language level, to where all of this stuff will be
necessarily reduced, all those nice absractions don't exist.

That's why I continually scoff at the object oriented and functional
programmers, most of whom believe they are like wizards dealing with
a special arcane art.  All of their lofty garbage MUST be reduced
to the ultimately simple "sequence and branch" machine code.

Just follow the machine and stuff that functional/OO up your
ill-functioning asses.

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

#465327

On Tuesday, August 28, 2018 at 12:27:19 PM UTC-6, fr31...@gmail.com wrote:
> On Tuesday, August 28, 2018 at 12:20:09 PM UTC-4, Steve Carroll wrote:
> 
> > 
> > The former is definitely more readable but if you had a ton of statements 
> > to deal with, you'd probably wanna spend the time for the latter
> >
> 
> At the machine language level, to where all of this stuff will be
> necessarily reduced, all those nice absractions don't exist.

I know they don't tax much, I'm just talking about from the viewpoint of
readability.

> That's why I continually scoff at the object oriented and functional
> programmers, most of whom believe they are like wizards dealing with
> a special arcane art. 

LOL! That's truer than people wanna admit... but, there are issues 
with certain things in web world that you aren't considering (if you
saw that screencast I made of Safari vs. Chrome going over a loop
you'd realize that).

> All of their lofty garbage MUST be reduced
> to the ultimately simple "sequence and branch" machine code.
> 
> Just follow the machine and stuff that functional/OO up your
> ill-functioning asses.

How the hell are ya today, Feeb.? Good to see you're back to your old self ;)

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

#465370

On 8/28/2018 2:27 PM, fr314159@gmail.com wrote:


> Just follow the machine and stuff that functional/OO up your
> ill-functioning asses.


Shove your hypocrisy up your ass:

* "In autumn 2012, I was hired by the Hewlett-Packard corporation as
     a C#/.NET programmer... I quit."

* "Within two weeks after I quit that idiotic job I was hired as a
     C#/.NET programmer for a company that produced an e-commerce
     package."

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

#465330

On 8/28/2018 12:20 PM, Steve Carroll wrote:

<snip>


> The former is definitely more readable but if you had a ton of statements
> to deal with, you'd probably wanna spend the time for the latter, if not...
> maybe you shouldn't bother (unless doing so for a COLA pissing contest).
> What's your cutoff point (and why)?


I like the first block better, but if possible I'd format it 
differently, as in the top section of this link:

https://ibb.co/fXJdNp

Ideally I'd shorten the object names, and write some kind of conditional 
assignment statements, as shown at bottom of that link.


Note: I like this imgbb/ibb upload site better than imgur (which has too 
many distractions).

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

#465332

On Tuesday, August 28, 2018 at 12:51:06 PM UTC-6, DFS wrote:
> On 8/28/2018 12:20 PM, Steve Carroll wrote:
> 
> <snip>
> 
> 
> > The former is definitely more readable but if you had a ton of statements
> > to deal with, you'd probably wanna spend the time for the latter, if not...
> > maybe you shouldn't bother (unless doing so for a COLA pissing contest).
> > What's your cutoff point (and why)?
> 
> 
> I like the first block better, 

But at what point would you stop writing it like that?

> but if possible I'd format it 
> differently, as in the top section of this link:
> 
> https://ibb.co/fXJdNp

I'll sometimes condense stuff like that for myself, I usually remember to 
expand it when posting but not always.

> Ideally I'd shorten the object names, and write some kind of conditional 
> assignment statements, as shown at bottom of that link.

I've done this before but I've crept towards using more descriptive names, 
even if when repeated they make it more cluttered. For this particular ex., 
which had a lot more data than what was shown, it made more sense to use 
my latter example, with cdArr1 also being read dynamically. It's still very 
readable IMO. I'm just wondering where the cutoff point is for people.

> Note: I like this imgbb/ibb upload site better than imgur (which has too 
> many distractions).

I know, right (especially with their new UI changes)?

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

#465313

DFS <nospam@nospam.com> wrote:
> On 12/4/2017 2:11 PM, fr314159@gmail.com wrote:
> 
>> This reminds me of something that happened during a university
>> class in Introductory Programming (using C of course).
>>
>> We were in the midst of various programming assignments that
>> involved nested if-then-else statements.  One of the students
>> who was having trouble began to protest claiming that studies
>> have shown that the human brain cannot efficiently comprehend
>> nesting levels that are more than three or four levels deep.
>> Therefore, he claimed, the class should not have to do such
>> assignments.
>>
>> Needless to say most of the other students just laughed at his
>> misery.
> 
> 
> Most students laughed... but you sat there stone-faced and silent and 
> thought deeply about your VBA tax "program" and tried to remember how 
> many levels of if-then-else shitcode you had written.
> 
> https://imgur.com/a/JWTIK
> 
> Linux makes you stupid.

Those aren't nested if statements.  They are all at the same level.

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

#465329

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.

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

#465331

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.

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

#465334

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.

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

#465338

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$ 

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

#465341

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? And 
what's  so "special" about 14?  

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

#465342

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"?  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."

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

#465344

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? 

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

#465345

Steve Carroll <fretwizzer@gmail.com> 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
> 

Yes.  As described above.  You said that is a situation that would
lend itself to doing it dynamically.  Explain how you would do it 
without running the tests.

>> 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? 

It just is.  It doesn't matter why.  You said range tests would not
bother with edge cases.  I let one of the range tests bother with one.

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

#465348

On Tuesday, August 28, 2018 at 3:43:58 PM UTC-6, owl wrote:
> Steve Carroll <fretwizzer@gmail.com> 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
> > 
> 
> Yes.  As described above.  You said that is a situation that would
> lend itself to doing it dynamically.  

I said that "I'd tend to think" it would, not that it necessarily would,
and I said it like that because I didn't know.

> Explain how you would do it 
> without running the tests.
> 
> >> 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? 
> 
> It just is.  It doesn't matter why.  You said range tests would not
> bother with edge cases. 

LOL! I said "I would think" it "wouldn't be bothered with" with them.

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

#465351

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Tuesday, August 28, 2018 at 3:43:58 PM UTC-6, owl wrote:
>> Steve Carroll <fretwizzer@gmail.com> 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
>> > 
>> 
>> Yes.  As described above.  You said that is a situation that would
>> lend itself to doing it dynamically.  
> 
> I said that "I'd tend to think" it would, not that it necessarily would,
> and I said it like that because I didn't know.
> 
>> Explain how you would do it 
>> without running the tests.
>> 
>> >> 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? 
>> 
>> It just is.  It doesn't matter why.  You said range tests would not
>> bother with edge cases. 
> 
> LOL! I said "I would think" it "wouldn't be bothered with" with them.
> 

The requirements of the program determine how you have to write it.
If you need to test against ranges, there's not much of an alternative to
coding the tests.  Same with "edge cases."  If you have to handle them,
you need to code a handler.

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

#465352

On Tuesday, August 28, 2018 at 4:26:57 PM UTC-6, owl wrote:

> The requirements of the program determine how you have to write it.
> If you need to test against ranges, there's not much of an alternative to
> coding the tests.  Same with "edge cases."  If you have to handle them,
> you need to code a handler.

Is this something you do often in sc (test for lots of extant ranges)?

C'mon, what's the deal with 14? I don't wanna guess in case I hit it and
the "prize" turns out to be a copy of Comfortably Numb  ;)

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

#465354

Steve Carroll <fretwizzer@gmail.com> wrote:
> On Tuesday, August 28, 2018 at 4:26:57 PM UTC-6, owl wrote:
> 
>> The requirements of the program determine how you have to write it.
>> If you need to test against ranges, there's not much of an alternative to
>> coding the tests.  Same with "edge cases."  If you have to handle them,
>> you need to code a handler.
> 
> Is this something you do often in sc (test for lots of extant ranges)?
> 

It helped when I was hacking it.

anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 0
A
anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 1
B
anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 2
C
anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 18277
ZZZ
anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 18278
AAAA
anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 12356628
ZZZZY
anon@lowtide:~/code/sc/hack/zzzzz$ ./getlabel 12356629
ZZZZZ
anon@lowtide:~/code/sc/hack/zzzzz$


> C'mon, what's the deal with 14? I don't wanna guess in case I hit it and
> the "prize" turns out to be a copy of Comfortably Numb  ;)


Probably had song 14 on my mind.
https://www.youtube.com/watch?v=hdhkf58dKG4&t=2m5s

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web