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

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

Lazy programmers guide to blizz

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

Contents

  Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 00:50 -0700
    Re: Lazy programmers guide to blizz dr.j.r.stockton@gmail.com - 2019-11-01 02:42 -0700
      Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 06:22 -0700
        Re: Lazy programmers guide to blizz Silvio <silvio@internet.com> - 2019-11-01 18:21 +0100
          Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 10:39 -0700
            Re: Lazy programmers guide to blizz Silvio <silvio@internet.com> - 2019-11-02 19:45 +0100
              Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-02 17:57 -0700
          Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 10:42 -0700
    Re: Lazy programmers guide to blizz John G Harris <niam@jghnorth.org.uk.invalid> - 2019-11-01 09:58 +0000
      Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 12:22 -0700
        Re: Lazy programmers guide to blizz dr.j.r.stockton@gmail.com - 2019-11-01 14:02 -0700
          Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 15:19 -0700
    Re: Lazy programmers guide to blizz Arno Welzel <usenet@arnowelzel.de> - 2019-11-01 11:04 +0100
      Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 06:27 -0700
        Re: Lazy programmers guide to blizz Arno Welzel <usenet@arnowelzel.de> - 2019-11-05 11:06 +0100
    Re: Lazy programmers guide to blizz luserdroog <luser.droog@gmail.com> - 2019-11-01 10:44 -0700
      Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 13:19 -0700
        Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-01 13:23 -0700
          Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-02 03:57 -0700
            Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-02 04:02 -0700
            Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-02 04:44 -0700
            Re: Lazy programmers guide to blizz Arno Welzel <usenet@arnowelzel.de> - 2019-11-05 11:20 +0100
          Re: Lazy programmers guide to blizz Arno Welzel <usenet@arnowelzel.de> - 2019-11-05 11:14 +0100
        Re: Lazy programmers guide to blizz luserdroog <luser.droog@gmail.com> - 2019-11-01 14:48 -0700
        Re: Lazy programmers guide to blizz John G Harris <niam@jghnorth.org.uk.invalid> - 2019-11-02 14:23 +0000
          Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-02 08:17 -0700
            Re: Lazy programmers guide to blizz John G Harris <niam@jghnorth.org.uk.invalid> - 2019-11-02 18:12 +0000
              Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-02 17:56 -0700
        Re: Lazy programmers guide to blizz Arno Welzel <usenet@arnowelzel.de> - 2019-11-05 11:14 +0100
          Re: Lazy programmers guide to blizz luserdroog <luser.droog@gmail.com> - 2019-11-05 09:04 -0800
    Re: Lazy programmers guide to blizz Flng Fck <nothanks@invalid.invalid> - 2019-11-04 11:31 +0100
      Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-04 02:46 -0800
        Re: Lazy programmers guide to blizz Gregor Kofler <usenet@gregorkofler.com> - 2019-11-07 14:59 +0100
      Re: Lazy programmers guide to blizz Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-11-04 02:48 -0800
        Re: Lazy programmers guide to blizz Silvio <silvio@internet.com> - 2019-11-05 09:38 +0100

Page 1 of 2  [1] 2  Next page →

#37655 — Lazy programmers guide to blizz

It so boring writing if intervals using < > or > <
And hard to read
Why not simplify 

if(A inside.interval(144-159))
if (A outside.interval(144-159))

Maybe there already is interval functions in javascript?

Alteratively for the operator fixated
if   (144< A <159)
if   (144> A >159)

I know whichone i would prefer......

[toc] | [next] | [standalone]

#37656

On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
> It so boring writing if intervals using < > or > <
> And hard to read
> Why not simplify 
> 
> if(A inside.interval(144-159))
> if (A outside.interval(144-159))

Minus (-), between numbers, is for subtraction

if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>

Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.

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

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

#37660

Den fredag 1 november 2019 kl. 10:42:22 UTC+1 skrev dr.j.r...@gmail.com:
> On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
> > It so boring writing if intervals using < > or > <
> > And hard to read
> > Why not simplify 
> > 
> > if(A inside.interval(144-159))
> > if (A outside.interval(144-159))
> 
> Minus (-), between numbers, is for subtraction
> 
> if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>
> 
> Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.
> 
> -- 
>   (c) John Stockton, near London, UK.  Using Google Groups.           |
>  Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

Well ther is such a thing like interpretate by context but i guess it is a little to highlevel semantic for you bitfiddlers.

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

#37662

On 11/1/19 2:22 PM, Jonas Thörnvall wrote:
> Den fredag 1 november 2019 kl. 10:42:22 UTC+1 skrev dr.j.r...@gmail.com:
>> On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
>>> It so boring writing if intervals using < > or > <
>>> And hard to read
>>> Why not simplify
>>>
>>> if(A inside.interval(144-159))
>>> if (A outside.interval(144-159))
>>
>> Minus (-), between numbers, is for subtraction
>>
>> if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>
>>
>> Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.
>>
>> -- 
>>    (c) John Stockton, near London, UK.  Using Google Groups.           |
>>   Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |
> 
> Well ther is such a thing like interpretate by context but i guess it is a little to highlevel semantic for you bitfiddlers.
> 

No, you just show here (as you have done before) you do not understand 
how programming langues work. They mostly compose which means they 
interpret expressions from the inside out. Hence a-b is parsed as 
subtraction regardless of the context. So a[b-c] could never be the 
sub-array with elements from array a starting at index b through c as 
you would/might see fit. The only way that could work is starting from a 
range operator like .. which might turn b..c into a range allowing 
a[b..c] to define a sub-arrray. This could also make 
(144..159).contains(150) or something similar parseable.
But JavaScript does not have a range operator...

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

#37663

Den fredag 1 november 2019 kl. 18:21:55 UTC+1 skrev Silvio:
> On 11/1/19 2:22 PM, Jonas Thörnvall wrote:
> > Den fredag 1 november 2019 kl. 10:42:22 UTC+1 skrev dr.j.r...@gmail.com:
> >> On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
> >>> It so boring writing if intervals using < > or > <
> >>> And hard to read
> >>> Why not simplify
> >>>
> >>> if(A inside.interval(144-159))
> >>> if (A outside.interval(144-159))
> >>
> >> Minus (-), between numbers, is for subtraction
> >>
> >> if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>
> >>
> >> Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.
> >>
> >> -- 
> >>    (c) John Stockton, near London, UK.  Using Google Groups.           |
> >>   Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |
> > 
> > Well ther is such a thing like interpretate by context but i guess it is a little to highlevel semantic for you bitfiddlers.
> > 
> 
> No, you just show here (as you have done before) you do not understand 
> how programming langues work. They mostly compose which means they 
> interpret expressions from the inside out. Hence a-b is parsed as 
> subtraction regardless of the context. So a[b-c] could never be the 
> sub-array with elements from array a starting at index b through c as 
> you would/might see fit. The only way that could work is starting from a 
> range operator like .. which might turn b..c into a range allowing 
> a[b..c] to define a sub-arrray. This could also make 
> (144..159).contains(150) or something similar parseable.
> But JavaScript does not have a range operator...

That is complete bullshit from start to end how it is parsed and what structure you chose to hold the commands is completly up to the programmer, as Arno just showed above. No the semantics of the language is neither god given or a choice made up on some superb logic. it is based on the choice of convenience or choice  of prefered. 

ENTP choice of prefered seldom go hand with peoples choice of convenicence and that is why most programming languages look like a pile of shit, where one idiocy is stacked by the next. ENTP are master of staple or stack information in what they beleive is a neat package by their knowledge. Wheter it make sense or not really do not concern them that much.

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

#37680

On 11/1/19 6:39 PM, Jonas Thörnvall wrote:
> Den fredag 1 november 2019 kl. 18:21:55 UTC+1 skrev Silvio:
>> On 11/1/19 2:22 PM, Jonas Thörnvall wrote:
>>> Den fredag 1 november 2019 kl. 10:42:22 UTC+1 skrev dr.j.r...@gmail.com:
>>>> On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
>>>>> It so boring writing if intervals using < > or > <
>>>>> And hard to read
>>>>> Why not simplify
>>>>>
>>>>> if(A inside.interval(144-159))
>>>>> if (A outside.interval(144-159))
>>>>
>>>> Minus (-), between numbers, is for subtraction
>>>>
>>>> if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>
>>>>
>>>> Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.
>>>>
>>>> -- 
>>>>     (c) John Stockton, near London, UK.  Using Google Groups.           |
>>>>    Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |
>>>
>>> Well ther is such a thing like interpretate by context but i guess it is a little to highlevel semantic for you bitfiddlers.
>>>
>>
>> No, you just show here (as you have done before) you do not understand
>> how programming langues work. They mostly compose which means they
>> interpret expressions from the inside out. Hence a-b is parsed as
>> subtraction regardless of the context. So a[b-c] could never be the
>> sub-array with elements from array a starting at index b through c as
>> you would/might see fit. The only way that could work is starting from a
>> range operator like .. which might turn b..c into a range allowing
>> a[b..c] to define a sub-arrray. This could also make
>> (144..159).contains(150) or something similar parseable.
>> But JavaScript does not have a range operator...
> 
> That is complete bullshit from start to end how it is parsed and what structure you chose to hold the commands is completly up to the programmer, as Arno just showed above. No the semantics of the language is neither god given or a choice made up on some superb logic. it is based on the choice of convenience or choice  of prefered.
> 
> ENTP choice of prefered seldom go hand with peoples choice of convenicence and that is why most programming languages look like a pile of shit, where one idiocy is stacked by the next. ENTP are master of staple or stack information in what they beleive is a neat package by their knowledge. Wheter it make sense or not really do not concern them that much.
> 

Complete poppycock.

Programming languages uphold some general patterns to give programmers 
some basic principles they can cling to. Composability is one of the 
most important ones. In general, in any programming languages that makes 
sense,

temp_a = expr1
temp_b = expr2
c = temp_a OPERATOR1 temp_b

will, must and shall always yield the same result as

c = (expr1) OPERATOR1 (expr2)

however deep the nesting of subexpressions might be.

if a languages would do what you call "interpretate by context" that 
basic pattern would no longer necessarily hold, sweeping programmers of 
their collective feet.

For the same reason expressions are parsed the same way in whatever 
context they are used. The context will then determine if the expression 
is valid.

I have written compilers for a handful of programming languages and have 
written dozens of expression parses for syntaxes far more complex than 
JavaScript expressions. I know my fair share about parsing. And you are 
completely clueless and out of your depth.

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

#37682

Den lördag 2 november 2019 kl. 19:45:06 UTC+1 skrev Silvio:
> On 11/1/19 6:39 PM, Jonas Thörnvall wrote:
> > Den fredag 1 november 2019 kl. 18:21:55 UTC+1 skrev Silvio:
> >> On 11/1/19 2:22 PM, Jonas Thörnvall wrote:
> >>> Den fredag 1 november 2019 kl. 10:42:22 UTC+1 skrev dr.j.r...@gmail.com:
> >>>> On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
> >>>>> It so boring writing if intervals using < > or > <
> >>>>> And hard to read
> >>>>> Why not simplify
> >>>>>
> >>>>> if(A inside.interval(144-159))
> >>>>> if (A outside.interval(144-159))
> >>>>
> >>>> Minus (-), between numbers, is for subtraction
> >>>>
> >>>> if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>
> >>>>
> >>>> Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.
> >>>>
> >>>> -- 
> >>>>     (c) John Stockton, near London, UK.  Using Google Groups.           |
> >>>>    Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |
> >>>
> >>> Well ther is such a thing like interpretate by context but i guess it is a little to highlevel semantic for you bitfiddlers.
> >>>
> >>
> >> No, you just show here (as you have done before) you do not understand
> >> how programming langues work. They mostly compose which means they
> >> interpret expressions from the inside out. Hence a-b is parsed as
> >> subtraction regardless of the context. So a[b-c] could never be the
> >> sub-array with elements from array a starting at index b through c as
> >> you would/might see fit. The only way that could work is starting from a
> >> range operator like .. which might turn b..c into a range allowing
> >> a[b..c] to define a sub-arrray. This could also make
> >> (144..159).contains(150) or something similar parseable.
> >> But JavaScript does not have a range operator...
> > 
> > That is complete bullshit from start to end how it is parsed and what structure you chose to hold the commands is completly up to the programmer, as Arno just showed above. No the semantics of the language is neither god given or a choice made up on some superb logic. it is based on the choice of convenience or choice  of prefered.
> > 
> > ENTP choice of prefered seldom go hand with peoples choice of convenicence and that is why most programming languages look like a pile of shit, where one idiocy is stacked by the next. ENTP are master of staple or stack information in what they beleive is a neat package by their knowledge. Wheter it make sense or not really do not concern them that much.
> > 
> 
> Complete poppycock.
> 
> Programming languages uphold some general patterns to give programmers 
> some basic principles they can cling to. Composability is one of the 
> most important ones. In general, in any programming languages that makes 
> sense,
> 
> temp_a = expr1
> temp_b = expr2
> c = temp_a OPERATOR1 temp_b
> 
> will, must and shall always yield the same result as
> 
> c = (expr1) OPERATOR1 (expr2)
> 
> however deep the nesting of subexpressions might be.
> 
> if a languages would do what you call "interpretate by context" that 
> basic pattern would no longer necessarily hold, sweeping programmers of 
> their collective feet.
> 
> For the same reason expressions are parsed the same way in whatever 
> context they are used. The context will then determine if the expression 
> is valid.
> 
> I have written compilers for a handful of programming languages and have 
> written dozens of expression parses for syntaxes far more complex than 
> JavaScript expressions. I know my fair share about parsing. And you are 
> completely clueless and out of your depth.

And again you do not understand what a parser do.

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

#37664

Den fredag 1 november 2019 kl. 18:21:55 UTC+1 skrev Silvio:
> On 11/1/19 2:22 PM, Jonas Thörnvall wrote:
> > Den fredag 1 november 2019 kl. 10:42:22 UTC+1 skrev dr.j.r...@gmail.com:
> >> On Friday, 1 November 2019 07:51:05 UTC, Jonas Thörnvall  wrote:
> >>> It so boring writing if intervals using < > or > <
> >>> And hard to read
> >>> Why not simplify
> >>>
> >>> if(A inside.interval(144-159))
> >>> if (A outside.interval(144-159))
> >>
> >> Minus (-), between numbers, is for subtraction
> >>
> >> if ( Math.abs(A-(144+159)/2 < Math.abs((144-159)/2) )  // use < or <=  - <g>
> >>
> >> Based on that, or on  (A>144 && A<159), you could write a Function, or a Method of the type of A.
> >>
> >> -- 
> >>    (c) John Stockton, near London, UK.  Using Google Groups.           |
> >>   Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |
> > 
> > Well ther is such a thing like interpretate by context but i guess it is a little to highlevel semantic for you bitfiddlers.
> > 
> 
> No, you just show here (as you have done before) you do not understand 
> how programming langues work. They mostly compose which means they 
> interpret expressions from the inside out. Hence a-b is parsed as 
> subtraction regardless of the context. So a[b-c] could never be the 
> sub-array with elements from array a starting at index b through c as 
> you would/might see fit. The only way that could work is starting from a 
> range operator like .. which might turn b..c into a range allowing 
> a[b..c] to define a sub-arrray. This could also make 
> (144..159).contains(150) or something similar parseable.
> But JavaScript does not have a range operator...

You simoply do not understand the idea behind high level languages, that is a problem in itself....

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

#37658

On Fri, 1 Nov 2019 00:50:58 -0700 (PDT), Jonas Thörnvall
<jonas.thornvall@gmail.com> wrote:

>It so boring writing if intervals using < > or > <
>And hard to read
>Why not simplify 
>
>if(A inside.interval(144-159))
>if (A outside.interval(144-159))
>
>Maybe there already is interval functions in javascript?
>
>Alteratively for the operator fixated
>if   (144< A <159)
>if   (144> A >159)
>
>I know whichone i would prefer......

  if (inside(144, A, 159)
    { ... }

*You* write the inside function. 
*You* decide if "inside" includes the boundary values or not.

  John

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

#37666

Den fredag 1 november 2019 kl. 10:58:42 UTC+1 skrev John G Harris:
> On Fri, 1 Nov 2019 00:50:58 -0700 (PDT), Jonas Thörnvall
> <jonas.thornvall@gmail.com> wrote:
> 
> >It so boring writing if intervals using < > or > <
> >And hard to read
> >Why not simplify 
> >
> >if(A inside.interval(144-159))
> >if (A outside.interval(144-159))
> >
> >Maybe there already is interval functions in javascript?
> >
> >Alteratively for the operator fixated
> >if   (144< A <159)
> >if   (144> A >159)
> >
> >I know whichone i would prefer......
> 
>   if (inside(144, A, 159)
>     { ... }
> 
> *You* write the inside function. 
> *You* decide if "inside" includes the boundary values or not.
> 
>   John

Well outside can not hold the boundary values so????...........

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

#37669

On Friday, 1 November 2019 19:22:22 UTC, Jonas Thörnvall  wrote:

 > Well outside can not hold the boundary values so????...........

I refer you to https://en.wikipedia.org/wiki/The_Grand_Old_Duke_of_York, whose Army was notoriously either Up or Down, or in an intermediate boundary state which was neither of those.

The article has the usual English words, and also it has a Dutch version (for EvertJan), and a Brazilian-Portuguese version (my two nearest neighbours are 1 1/3 Brazilian-Portuguese).


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

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

#37671

Den fredag 1 november 2019 kl. 22:02:46 UTC+1 skrev dr.j.r...@gmail.com:
> On Friday, 1 November 2019 19:22:22 UTC, Jonas Thörnvall  wrote:
> 
>  > Well outside can not hold the boundary values so????...........
> 
> I refer you to https://en.wikipedia.org/wiki/The_Grand_Old_Duke_of_York, whose Army was notoriously either Up or Down, or in an intermediate boundary state which was neither of those.
> 
> The article has the usual English words, and also it has a Dutch version (for EvertJan), and a Brazilian-Portuguese version (my two nearest neighbours are 1 1/3 Brazilian-Portuguese).
> 
> 
> -- 
>   (c) John Stockton, near London, UK.  Using Google Groups.           |
>  Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

We are not talking about up and down we are talking about intervals, i see the poor mathematicians introduced confusions into the mathemathical meaning. But that is because they are confused themself.

So if the shoe doesn't fit your lexical ambivalence, try a new range.

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

#37659

On 01.11.19 08:50, Jonas Thörnvall wrote:
> It so boring writing if intervals using < > or > <
> And hard to read
> Why not simplify 
> 
> if(A inside.interval(144-159))
> if (A outside.interval(144-159))
> 
> Maybe there already is interval functions in javascript?
> 
> Alteratively for the operator fixated
> if   (144< A <159)
> if   (144> A >159)

Hmmm...


    A inside.interval(144-159)

vs.

    A >= 144 && A <= 160

And you find the first one really simpler? I don't.

For example: does inside.interval() mean ">=" and "<=" or ">" and "<"?
This is not clear when looking at the code.

But if you prefer this, just create your own function - assuming, that
the interval means including the lower and upper limit:

function between(x, min, max) {
  return x >= min && x <= max;
}




-- 
Arno Welzel
https://arnowelzel.de

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

#37661

Den fredag 1 november 2019 kl. 11:04:17 UTC+1 skrev Arno Welzel:
> On 01.11.19 08:50, Jonas Thörnvall wrote:
> > It so boring writing if intervals using < > or > <
> > And hard to read
> > Why not simplify 
> > 
> > if(A inside.interval(144-159))
> > if (A outside.interval(144-159))
> > 
> > Maybe there already is interval functions in javascript?
> > 
> > Alteratively for the operator fixated
> > if   (144< A <159)
> > if   (144> A >159)
> 
> Hmmm...
> 
> 
>     A inside.interval(144-159)
> 
> vs.
> 
>     A >= 144 && A <= 160
> 
> And you find the first one really simpler? I don't.
> 
> For example: does inside.interval() mean ">=" and "<=" or ">" and "<"?
> This is not clear when looking at the code.
> 
> But if you prefer this, just create your own function - assuming, that
> the interval means including the lower and upper limit:
> 
> function between(x, min, max) {
>   return x >= min && x <= max;
> }
> 
> 
> 
> 
> -- 
> Arno Welzel
> https://arnowelzel.de

Well i would definitly interpretate that the boundaries are inside, because they can't be outside.

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

#37692

On 01.11.19 14:27, Jonas Thörnvall wrote:

> Den fredag 1 november 2019 kl. 11:04:17 UTC+1 skrev Arno Welzel:
>> On 01.11.19 08:50, Jonas Thörnvall wrote:
>>> It so boring writing if intervals using < > or > <
>>> And hard to read
>>> Why not simplify 
>>>
>>> if(A inside.interval(144-159))
>>> if (A outside.interval(144-159))
>>>
>>> Maybe there already is interval functions in javascript?
>>>
>>> Alteratively for the operator fixated
>>> if   (144< A <159)
>>> if   (144> A >159)
>>
>> Hmmm...
>>
>>
>>     A inside.interval(144-159)
>>
>> vs.
>>
>>     A >= 144 && A <= 160
>>
>> And you find the first one really simpler? I don't.
>>
>> For example: does inside.interval() mean ">=" and "<=" or ">" and "<"?
>> This is not clear when looking at the code.
>>
>> But if you prefer this, just create your own function - assuming, that
>> the interval means including the lower and upper limit:
>>
>> function between(x, min, max) {
>>   return x >= min && x <= max;
>> }
>>
>>
>>
>>
>> -- 
>> Arno Welzel
>> https://arnowelzel.de

JFTR: This is a signature which is usally not cited. The delimiter can
be recognized by the trailing space: "-- ". Real usenet clients will
automatically handle this. You should consider using a NNTP server and a
usenet client instead of Google Groups.

> Well i would definitly interpretate that the boundaries are inside, because they can't be outside.

Including the boundaries does not mean "outside".

For example:

x>=10 && x<=20

x can be 10 or 20 and is still inside the range

x>10 && x<20

x must be more than 10 and less then 20 to be inside the range.


And furthermore:

x inside(a-b)

All programming languages I know (shell scripts, C, C++, C#, PHP,
ECMAScript, Java etc.) see "a-b" as "a minus b". And interpreting "-" as
"," depending on the context is just stupid since this would require a
additional code in some cases, for example if a or b are not absolute
values or variables but expressions:

x inside((a-1)-b)

And reading this is even worse: the first "-" is "minus" and the second
"-" would be the "range" operator.

Before you think about how to add new syntax to a language you should
first learn the basics. YACC/LEX may be a good starting point:

http://dinosaur.compilertools.net



-- 
Arno Welzel
https://arnowelzel.de

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

#37665

On Friday, November 1, 2019 at 2:51:05 AM UTC-5, Jonas Thörnvall wrote:
> It so boring writing if intervals using < > or > <
> And hard to read
> Why not simplify 
> 
> if(A inside.interval(144-159))
> if (A outside.interval(144-159))
> 
> Maybe there already is interval functions in javascript?
> 
> Alteratively for the operator fixated
> if   (144< A <159)
> if   (144> A >159)
> 
> I know whichone i would prefer......

When I've needed something like this, I just write a function.

  function within( lower, x, upper ){
    return lower <= x && x < upper;
  }

The half-open interval is very common, eg.

  function httpOK( response ){
    return within( 200, response, 300 );
  }

BTW, (144< A <159) probably doesn't do what you think it should.

For the "outside" interval, just prefix ! (logical NOT) to the
function call.

For a more OO style, how about

class Interval {
  constructor( lower, upper ){
    this.lower = lower;
    this.upper = upper;
    return this;
  }
  inside( x ){
    return this.lower <= x && x < this.upper;
  }
  outside( x ){
    return ! this.inside( x );
  }
}

if( Interval(145, 159).inside(A) ) 
if( Interval(145, 159).outside(A) )

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

#37667

Den fredag 1 november 2019 kl. 18:44:26 UTC+1 skrev luserdroog:
> On Friday, November 1, 2019 at 2:51:05 AM UTC-5, Jonas Thörnvall wrote:
> > It so boring writing if intervals using < > or > <
> > And hard to read
> > Why not simplify 
> > 
> > if(A inside.interval(144-159))
> > if (A outside.interval(144-159))
> > 
> > Maybe there already is interval functions in javascript?
> > 
> > Alteratively for the operator fixated
> > if   (144< A <159)
> > if   (144> A >159)
> > 
> > I know whichone i would prefer......
> 
> When I've needed something like this, I just write a function.
> 
>   function within( lower, x, upper ){
>     return lower <= x && x < upper;
>   }
> 
> The half-open interval is very common, eg.
> 
>   function httpOK( response ){
>     return within( 200, response, 300 );
>   }
> 
> BTW, (144< A <159) probably doesn't do what you think it should.
> 
> For the "outside" interval, just prefix ! (logical NOT) to the
> function call.
> 
> For a more OO style, how about
> 
> class Interval {
>   constructor( lower, upper ){
>     this.lower = lower;
>     this.upper = upper;
>     return this;
>   }
>   inside( x ){
>     return this.lower <= x && x < this.upper;
>   }
>   outside( x ){
>     return ! this.inside( x );
>   }
> }
> 
> if( Interval(145, 159).inside(A) ) 
> if( Interval(145, 159).outside(A) )

You people really fuck up things beyond  semantical an interval can not be inside a number.... It may be outside but you really love to add complexity to problems that is simple. An interval is always a range there is no between in it so interval 1 to 3 always hold 1 and 2 and 3.

But why do feel the urge to change things so they do not make sense  the interval can never be inside A.....

It is utterly stupid...

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

#37668

Den fredag 1 november 2019 kl. 21:19:56 UTC+1 skrev Jonas Thörnvall:
> Den fredag 1 november 2019 kl. 18:44:26 UTC+1 skrev luserdroog:
> > On Friday, November 1, 2019 at 2:51:05 AM UTC-5, Jonas Thörnvall wrote:
> > > It so boring writing if intervals using < > or > <
> > > And hard to read
> > > Why not simplify 
> > > 
> > > if(A inside.interval(144-159))
> > > if (A outside.interval(144-159))
> > > 
> > > Maybe there already is interval functions in javascript?
> > > 
> > > Alteratively for the operator fixated
> > > if   (144< A <159)
> > > if   (144> A >159)
> > > 
> > > I know whichone i would prefer......
> > 
> > When I've needed something like this, I just write a function.
> > 
> >   function within( lower, x, upper ){
> >     return lower <= x && x < upper;
> >   }
> > 
> > The half-open interval is very common, eg.
> > 
> >   function httpOK( response ){
> >     return within( 200, response, 300 );
> >   }
> > 
> > BTW, (144< A <159) probably doesn't do what you think it should.
> > 
> > For the "outside" interval, just prefix ! (logical NOT) to the
> > function call.
> > 
> > For a more OO style, how about
> > 
> > class Interval {
> >   constructor( lower, upper ){
> >     this.lower = lower;
> >     this.upper = upper;
> >     return this;
> >   }
> >   inside( x ){
> >     return this.lower <= x && x < this.upper;
> >   }
> >   outside( x ){
> >     return ! this.inside( x );
> >   }
> > }
> > 
> > if( Interval(145, 159).inside(A) ) 
> > if( Interval(145, 159).outside(A) )
> 
> You people really fuck up things beyond  semantical an interval can not be inside a number.... It may be outside but you really love to add complexity to problems that is simple. An interval is always a range there is no between in it so interval 1 to 3 always hold 1 and 2 and 3.
> 
> But why do feel the urge to change things so they do not make sense  the interval can never be inside A.....
> 
> It is utterly stupid...

So i repeat if (A inside.interval(128-144)) there is no need for anything else.

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

#37673

Den fredag 1 november 2019 kl. 21:23:27 UTC+1 skrev Jonas Thörnvall:
> Den fredag 1 november 2019 kl. 21:19:56 UTC+1 skrev Jonas Thörnvall:
> > Den fredag 1 november 2019 kl. 18:44:26 UTC+1 skrev luserdroog:
> > > On Friday, November 1, 2019 at 2:51:05 AM UTC-5, Jonas Thörnvall wrote:
> > > > It so boring writing if intervals using < > or > <
> > > > And hard to read
> > > > Why not simplify 
> > > > 
> > > > if(A inside.interval(144-159))
> > > > if (A outside.interval(144-159))
> > > > 
> > > > Maybe there already is interval functions in javascript?
> > > > 
> > > > Alteratively for the operator fixated
> > > > if   (144< A <159)
> > > > if   (144> A >159)
> > > > 
> > > > I know whichone i would prefer......
> > > 
> > > When I've needed something like this, I just write a function.
> > > 
> > >   function within( lower, x, upper ){
> > >     return lower <= x && x < upper;
> > >   }
> > > 
> > > The half-open interval is very common, eg.
> > > 
> > >   function httpOK( response ){
> > >     return within( 200, response, 300 );
> > >   }
> > > 
> > > BTW, (144< A <159) probably doesn't do what you think it should.
> > > 
> > > For the "outside" interval, just prefix ! (logical NOT) to the
> > > function call.
> > > 
> > > For a more OO style, how about
> > > 
> > > class Interval {
> > >   constructor( lower, upper ){
> > >     this.lower = lower;
> > >     this.upper = upper;
> > >     return this;
> > >   }
> > >   inside( x ){
> > >     return this.lower <= x && x < this.upper;
> > >   }
> > >   outside( x ){
> > >     return ! this.inside( x );
> > >   }
> > > }
> > > 
> > > if( Interval(145, 159).inside(A) ) 
> > > if( Interval(145, 159).outside(A) )
> > 
> > You people really fuck up things beyond  semantical an interval can not be inside a number.... It may be outside but you really love to add complexity to problems that is simple. An interval is always a range there is no between in it so interval 1 to 3 always hold 1 and 2 and 3.
> > 
> > But why do feel the urge to change things so they do not make sense  the interval can never be inside A.....
> > 
> > It is utterly stupid...
> 
> So i repeat if (A inside.interval(128-144)) there is no need for anything else.

Maybe one should fuck the dots, paragraphs, blips and blops all together and make a semantical correct language that people could program out of the box.

if A inside interval 128-144.
if A bigger then B.
if A smaller then B.
if A eual B.

A=2.
do while A < then B and A length less then 10


A++.
done.

Maybe i make a parser for javascript one day, javascript has nice features but fucked up syntax/semantics.

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

#37674

Den lördag 2 november 2019 kl. 11:57:21 UTC+1 skrev Jonas Thörnvall:
> Den fredag 1 november 2019 kl. 21:23:27 UTC+1 skrev Jonas Thörnvall:
> > Den fredag 1 november 2019 kl. 21:19:56 UTC+1 skrev Jonas Thörnvall:
> > > Den fredag 1 november 2019 kl. 18:44:26 UTC+1 skrev luserdroog:
> > > > On Friday, November 1, 2019 at 2:51:05 AM UTC-5, Jonas Thörnvall wrote:
> > > > > It so boring writing if intervals using < > or > <
> > > > > And hard to read
> > > > > Why not simplify 
> > > > > 
> > > > > if(A inside.interval(144-159))
> > > > > if (A outside.interval(144-159))
> > > > > 
> > > > > Maybe there already is interval functions in javascript?
> > > > > 
> > > > > Alteratively for the operator fixated
> > > > > if   (144< A <159)
> > > > > if   (144> A >159)
> > > > > 
> > > > > I know whichone i would prefer......
> > > > 
> > > > When I've needed something like this, I just write a function.
> > > > 
> > > >   function within( lower, x, upper ){
> > > >     return lower <= x && x < upper;
> > > >   }
> > > > 
> > > > The half-open interval is very common, eg.
> > > > 
> > > >   function httpOK( response ){
> > > >     return within( 200, response, 300 );
> > > >   }
> > > > 
> > > > BTW, (144< A <159) probably doesn't do what you think it should.
> > > > 
> > > > For the "outside" interval, just prefix ! (logical NOT) to the
> > > > function call.
> > > > 
> > > > For a more OO style, how about
> > > > 
> > > > class Interval {
> > > >   constructor( lower, upper ){
> > > >     this.lower = lower;
> > > >     this.upper = upper;
> > > >     return this;
> > > >   }
> > > >   inside( x ){
> > > >     return this.lower <= x && x < this.upper;
> > > >   }
> > > >   outside( x ){
> > > >     return ! this.inside( x );
> > > >   }
> > > > }
> > > > 
> > > > if( Interval(145, 159).inside(A) ) 
> > > > if( Interval(145, 159).outside(A) )
> > > 
> > > You people really fuck up things beyond  semantical an interval can not be inside a number.... It may be outside but you really love to add complexity to problems that is simple. An interval is always a range there is no between in it so interval 1 to 3 always hold 1 and 2 and 3.
> > > 
> > > But why do feel the urge to change things so they do not make sense  the interval can never be inside A.....
> > > 
> > > It is utterly stupid...
> > 
> > So i repeat if (A inside.interval(128-144)) there is no need for anything else.
> 
> Maybe one should fuck the dots, paragraphs, blips and blops all together and make a semantical correct language that people could program out of the box.
> 
> if A inside interval 128-144.
> if A bigger then B.
> if A smaller then B.
> if A eual B.
> 
> A=2.
> do while A < then B and A length less then 10
> 
> 
> A++.
> done.
> 
> Maybe i make a parser for javascript one day, javascript has nice features but fucked up syntax/semantics.

Well evidently even i got damaged by syntax.
A equal 2.
A add 1.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web