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

Groups > comp.programming > #15916 > unrolled thread

A little puzzle.

Back to article view | Back to comp.programming

Contents

  A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-21 20:45 +0000
    Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-21 22:06 +0100
      Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-21 21:21 +0000
        Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-22 09:17 +0100
          Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-22 11:07 +0000
            Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-22 15:17 +0100
          Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-22 11:40 +0000
            Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-22 15:26 +0100
              Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-22 15:28 +0000
                Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-22 16:30 +0100
        Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-22 09:23 +0100
          Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-22 11:08 +0000
          Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-22 12:54 +0000
    Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-21 17:39 -0800
      Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-22 13:00 +0000
        Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-22 05:31 -0800
    Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-22 11:04 +0000
      Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-22 12:53 +0000
        Re: A little puzzle. Paul N <gw7rib@aol.com> - 2022-11-22 05:01 -0800
          Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-22 05:48 -0800
            Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-22 15:31 +0100
        FFs [was Re: A little puzzle] Richard Harnden <richard.nospam@gmail.com> - 2022-11-22 16:29 +0000
      Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 13:57 +0000
        Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 13:58 +0000
        Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-12-14 16:22 +0000
    Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-22 05:24 -0800
      Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-22 15:23 +0000
        Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-23 08:04 -0800
          Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-24 00:06 +0000
            Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-24 04:06 +0000
              Re: A little puzzle. David Brown <david.brown@hesbynett.no> - 2022-11-24 09:29 +0100
                Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-24 13:23 +0000
              Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-24 13:14 +0000
                Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-24 14:00 +0000
                  Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-24 14:59 +0000
                    Re: A little puzzle. Richard Harnden <richard.nospam@gmail.com> - 2022-11-24 19:00 +0000
                      Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-24 20:36 +0000
                Re: A little puzzle. Andreas <nobody@me.com> - 2022-11-27 00:38 +0100
                  Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-27 00:11 +0000
            Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-24 14:51 -0800
              Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-25 09:30 +0100
                Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-25 01:16 -0800
                  Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-25 11:11 +0100
                    Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-25 06:26 -0800
                      Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-25 15:59 +0100
              Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-26 16:25 +0000
                Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-26 19:36 +0100
                  Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-27 02:03 +0000
                    Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-27 11:02 +0100
                    Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-01 04:30 -0800
                      Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-02 00:22 +0000
                        Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-02 22:30 -0800
                          Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-12-03 02:43 -0800
                Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-27 18:38 -0800
    Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-27 02:27 -0800
      Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-27 19:23 -0800
        Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-27 22:59 -0800
          Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-27 23:03 -0800
          Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-28 07:22 -0800
            Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-28 10:20 -0800
              Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-29 04:29 -0800
                Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-29 04:50 -0800
                  Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-29 14:47 +0000
                    Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-29 17:23 +0000
                      Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-29 09:50 -0800
                    Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-30 01:39 -0800
                      Re: A little puzzle. Richard Heathfield <rjh@cpax.org.uk> - 2022-11-30 11:10 +0000
                  Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-30 02:24 -0800
                    Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-30 06:28 -0800
                      Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-01 06:55 -0800
                        Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-12-02 01:54 -0800
    Re: A little puzzle. Richard Harnden <richard.nospam@gmail.com> - 2022-11-28 11:20 +0000
      Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-28 07:30 -0800
        Re: A little puzzle. Richard Harnden <richard.nospam@gmail.com> - 2022-11-28 17:15 +0000
          Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-29 04:03 -0800
            Re: A little puzzle. Richard Harnden <richard.nospam@gmail.com> - 2022-11-29 15:03 +0000
              Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-29 16:13 +0100
                Re: A little puzzle. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-29 17:37 +0000
                  Re: A little puzzle. "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2022-11-29 19:02 +0100
                    Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-29 10:10 -0800
              Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-30 03:32 -0800
                Re: A little puzzle. Julio Di Egidio <julio@diegidio.name> - 2022-11-30 06:36 -0800
                Re: A little puzzle. Richard Harnden <richard.nospam@gmail.com> - 2022-11-30 15:21 +0000
                  Re: A little puzzle. Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-01 06:51 -0800

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

#15990

Julio Di Egidio <julio@diegidio.name> writes:

> On Monday, 28 November 2022 at 16:22:38 UTC+1, Tim Rentsch wrote:
>
>> Julio Di Egidio <an unrepentant google groups user> writes:
>>
>>>>> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote:

[...]

>>>>>> Consider any ordered measure that "wraps round" -- bearings in
>>>>>> degrees, minutes in the hour, indeed hours in either the 12 or
>>>>>> 24 hour clock.  The problem is to determine if a given value is
>>>>>> in the sub-range specified by a start and an en value.
>>>
>>> Argh!  But you should not have snipped that "beware
>>> of bugs", that was the most important part!! ;)
>>
>> It's your job to beware of bugs, not mine.
>
> I didn't know you were paying me for production level code:

You are under no obligation to post bug-free code.  Similarly I
am under no obligation to correct bugs in your code.  But if you
want your postings to be taken seriously it's important to put
more thought into what is posted and make an effort to avoid
careless mistakes.

> in that case, I'd have asked for the technical requirements,
> not just the functional ones...
>
> IOW, I have have given a mathematical spec written in some
> simply-typed functional language, can be functions on the real
> numbers.  Which is often step one in functional/algorithmic
> design.  Beside that point, one needs technical requirements,
> i.e. info on the concrete numeric types available as a minimum.

Part of the challenge is to figure out what the interface should
be.  The problem is not just a coding exercise.

>>> This one should do the trick:
>>>
>>> ```ts
>>> /** Returns whether x in [lo, hi[ (mod m). */
>>> function inOpenModRange(
>>> x:  number, lo:  number, hi:  number, m:  number
>>> ): boolean {
>>> let x_ = MOD(x - lo, m);
>>> let hi_ = MOD(hi - lo, m);
>>> return x_ < hi_;
>>> }
>>> ```
>>
>> This scheme looks like it will work, as long as the values given
>> don't get too near the edges of representation.  JavaScript
>> represents numeric values using floating point, and that choice
>> leads to some unexpected results when working with large numbers.
>>
>> However, this approach is more complicated than it needs to be.
>> Have you tried looking at the other answers?
>
> That is complicated??  Maybe I haven't looked well enough
> but, honestly, I have not seen anything that is even vaguely as
> clear, and efficient, and to the point.  Have I missed it?

The question can be answered without using any of subtraction,
remainder, or mod, and more than one solution has been posted
demonstrating that property.  Perhaps you missed those answers.

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

#15991

On Tuesday, 29 November 2022 at 13:29:48 UTC+1, Tim Rentsch wrote:
> Julio Di Egidio <ju...@diegidio.name> writes: 
> > On Monday, 28 November 2022 at 16:22:38 UTC+1, Tim Rentsch wrote: 
> >> Julio Di Egidio <an unrepentant google groups user> writes: 
> >>>>> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote:
> [...]
> >>>>>> Consider any ordered measure that "wraps round" -- bearings in 
> >>>>>> degrees, minutes in the hour, indeed hours in either the 12 or 
> >>>>>> 24 hour clock. The problem is to determine if a given value is 
> >>>>>> in the sub-range specified by a start and an en value. 
> >>> 
> >>> Argh! But you should not have snipped that "beware 
> >>> of bugs", that was the most important part!! ;) 
> >> 
> >> It's your job to beware of bugs, not mine. 
> > 
> > I didn't know you were paying me for production level code:
> 
> You are under no obligation to post bug-free code. Similarly I 
> am under no obligation to correct bugs in your code.

That is not what I said: indeed "beware of bugs" is a paraphrase
of Knuth for your info, and what that means.  Morover, modulo
my mistakes, which is another story, my code *is* bug free, just
apparently you are confused about the whole what is what.

>  But if you 
> want your postings to be taken seriously it's important to put

I am certainly not interested in any such cheap abusive "psychology".

> The question can be answered without using any of subtraction,
> remainder, or mod,

No, it cannot.  But feel free to prove me wrong.

> and more than one solution has been posted 
> demonstrating that property. Perhaps you missed those answers.

The answer by Paul N is equivalent to mine, but I have given a
formalization, plus a courtesy implementation of MOD for those
playing with a language that does not have it built-in.

And my formalization was not so much to improve on Paul's
answer anyway, it was more out of the irritation of the several
posts by you and others with the deranged morals but not
even able to state an interface, let alone write few lines of
code that are not imply a horrible mess when at all correct.

How long have you being doing this job?  You come up as yet
another clueless arrogant ass.

Julio

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

#15992

On 29/11/2022 12:50 pm, Julio Di Egidio wrote:
> How long have you being doing this job?  You come up as yet
> another clueless arrogant ass.

Your judgement seems overly hasty. I can assure you on the basis 
of many discussions in which he and I have both participated that 
Tim Rentsch is neither clueless nor an ass.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#15997

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 29/11/2022 12:50 pm, Julio Di Egidio wrote:
>> How long have you being doing this job?  You come up as yet
>> another clueless arrogant ass.
>
> Your judgement seems overly hasty. I can assure you on the basis of
> many discussions in which he and I have both participated that Tim
> Rentsch is neither clueless nor an ass.

And on the basis of observing quite a discussions with Julio Di Egidio,
I am amazed that it took this long get to crude insults.  It's often the
second reply, if not the fist.

-- 
Ben.

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

#15999

On Tuesday, 29 November 2022 at 18:23:12 UTC+1, Ben Bacarisse wrote:
> Richard Heathfield <r...@cpax.org.uk> writes: 
> > On 29/11/2022 12:50 pm, Julio Di Egidio wrote: 
> > 
> >> How long have you being doing this job? You come up as yet 
> >> another clueless arrogant ass. 
> > 
> > Your judgement seems overly hasty. I can assure you on the basis of 
> > many discussions in which he and I have both participated that Tim 
> > Rentsch is neither clueless nor an ass.
> 
> And on the basis of observing quite a discussions with Julio Di Egidio, 
> I am amazed that it took this long get to crude insults. It's often the 
> second reply, if not the fist.

As usual, what a bunch of fucking morons...

But you remain the champion of the fraudulent
suckers around here.

*Plonk*

Julio

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

#16009

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 29/11/2022 12:50 pm, Julio Di Egidio wrote:
>
>> How long have you being doing this job?  You come up as yet
>> another clueless arrogant ass.
>
> Your judgement seems overly hasty.  I can assure you on the basis of
> many discussions in which he and I have both participated that Tim
> Rentsch is neither clueless nor an ass.

Thank you Richard.  How the heck are you?

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

#16011

On 30/11/2022 9:39 am, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> 
>> On 29/11/2022 12:50 pm, Julio Di Egidio wrote:
>>
>>> How long have you being doing this job?  You come up as yet
>>> another clueless arrogant ass.
>>
>> Your judgement seems overly hasty.  I can assure you on the basis of
>> many discussions in which he and I have both participated that Tim
>> Rentsch is neither clueless nor an ass.
> 
> Thank you Richard.  How the heck are you?

You're welcome. Well, haec olim meminisse juvabit (and I am sure 
I need not translate).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#16010

Julio Di Egidio <julio@diegidio.name> writes:

[edited for brevity]

> On Tuesday, 29 November 2022 at 13:29:48 UTC+1, Tim Rentsch wrote:

>..> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote:

>..>> Consider any ordered measure that "wraps round" -- bearings in
>..>> degrees, minutes in the hour, indeed hours in either the 12 or
>..>> 24 hour clock.  The problem is to determine if a given value is
>..>> in the sub-range specified by a start and an en value.

>> The question can be answered without using any of subtraction,
>> remainder, or mod,
>
> No, it cannot.  But feel free to prove me wrong.

At this point I see no reason to try to convince you.

>> and more than one solution has been posted
>> demonstrating that property.  Perhaps you missed those answers.
>
> The answer by Paul N is equivalent to mine, but I have given a
> formalization, plus a courtesy implementation of MOD for those
> playing with a language that does not have it built-in.
>
> And my formalization was not so much to improve on Paul's
> answer anyway, it was more out of the irritation of the several
> posts by you and others with the deranged morals but not
> even able to state an interface,

I posted an interface in my initial response to the lead post of
the thread.  IIANM that response was in fact the first response
of any in the thread.

Which of my earlier posts irritated you, and what parts of them
caused you irritation?

> let alone write few lines of
> code that are not imply a horrible mess when at all correct.

I don't know how to make sense of the restrictive phrase here.

> How long have you being doing this job?  You come up as yet
> another clueless arrogant ass.

I first posted in net news (back when it was called usenet) back
in the mid 1980s.  My first experience with computer programming
was in the late 1960s.  My first exposure to C was in 1978,
reading "The C Programming Language" by Kernighan and Ritchie.
At that time C was roughly the tenth programming language I was
familiar with.

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

#16013

On Wednesday, 30 November 2022 at 11:24:17 UTC+1, Tim Rentsch wrote:
> Julio Di Egidio <ju...@diegidio.name> writes:
> [edited for brevity]
> > On Tuesday, 29 November 2022 at 13:29:48 UTC+1, Tim Rentsch wrote:
> >..> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote: 
> 
> >..>> Consider any ordered measure that "wraps round" -- bearings in 
> >..>> degrees, minutes in the hour, indeed hours in either the 12 or 
> >..>> 24 hour clock. The problem is to determine if a given value is 
> >..>> in the sub-range specified by a start and an en value.
> > 
> >> The question can be answered without using any of subtraction, 
> >> remainder, or mod, 
> > 
> > No, it cannot. But feel free to prove me wrong.
> 
> At this point I see no reason to try to convince you.

You have never had any reason, so that is hardly surprising.

> I first posted in net news (back when it was called usenet) back
> in the mid 1980s. My first experience with computer programming 

So you do not even have the age excuse...   BTW, how do you think
it's called now?  A rhetorical question.

Julio

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

#16020

Julio Di Egidio <julio@diegidio.name> writes:

> On Wednesday, 30 November 2022 at 11:24:17 UTC+1, Tim Rentsch wrote:
>
>> Julio Di Egidio <ju...@diegidio.name> writes:
>> [edited for brevity]
>>
>>> On Tuesday, 29 November 2022 at 13:29:48 UTC+1, Tim Rentsch wrote:
>>> ..> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote:
>>>
>>> ..>> Consider any ordered measure that "wraps round" -- bearings in
>>> ..>> degrees, minutes in the hour, indeed hours in either the 12 or
>>> ..>> 24 hour clock.  The problem is to determine if a given value is
>>> ..>> in the sub-range specified by a start and an en value.
>>>
>>>> The question can be answered without using any of subtraction,
>>>> remainder, or mod,
>>>
>>> No, it cannot.  But feel free to prove me wrong.
>>
>> At this point I see no reason to try to convince you.
>
> You have never had any reason, so that is hardly surprising.

As you may have observed, I often put in time and effort to give
further explanation of an earlier comment.  I'm more likely to do
that when I think the person I'm responding to is interested in
hearing what I have to say.

I hope you will understand if I choose not to read or respond to
your future postings.

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

#16024

On Thursday, 1 December 2022 at 15:55:43 UTC+1, Tim Rentsch wrote:
> Julio Di Egidio <ju...@diegidio.name> writes: 
> > On Wednesday, 30 November 2022 at 11:24:17 UTC+1, Tim Rentsch wrote: 
> >> Julio Di Egidio <ju...@diegidio.name> writes: 
> >> [edited for brevity] 
> >>> On Tuesday, 29 November 2022 at 13:29:48 UTC+1, Tim Rentsch wrote: 
> >>> ..> On Monday, 21 November 2022 at 21:45:34 UTC+1, Ben Bacarisse wrote: 
> >>> 
> >>> ..>> Consider any ordered measure that "wraps round" -- bearings in 
> >>> ..>> degrees, minutes in the hour, indeed hours in either the 12 or 
> >>> ..>> 24 hour clock. The problem is to determine if a given value is 
> >>> ..>> in the sub-range specified by a start and an en value. 
> >>> 
> >>>> The question can be answered without using any of subtraction, 
> >>>> remainder, or mod, 
> >>> 
> >>> No, it cannot. But feel free to prove me wrong. 
> >> 
> >> At this point I see no reason to try to convince you. 
> > 
> > You have never had any reason, so that is hardly surprising.
> 
> As you may have observed, I often put in time and effort to give 
> further explanation of an earlier comment. I'm more likely to do 
> that when I think the person I'm responding to is interested in 
> hearing what I have to say. 

You insane retards and the end of the world...  Of course I
tell you about plane crashes and you even more so behave
like a retarded queer.  You do are an utter imbecille.

> I hope you will understand if I choose not to read or respond to 
> your future postings.

Sure I do, you umpteenth piece of fraudulent abusive retard.
But I hope you will understand if every once in a while I still
point out some of the bestiality of your and this bandwagon's
insanity.

After all, if you guys like selling, buying and eating shit, who
am I to tell you not to...  if you retarded cunts didn't shit all
outside your box, that is.

Enough said for now.

Julio

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

#15981

On 21/11/2022 20:45, Ben Bacarisse wrote:
> I wonder if there are any real posters here?  Let's see...
> 
> I came across a trivial programming task that must have been solved a
> thousand times by other programmers, but it had never crossed my path
> until yesterday.  I must be feeling my age because I made a real hash of
> tackling it at first.  Anyway, I thought it might be of interest.
> 
> Consider any ordered measure that "wraps round" -- bearings in degrees,
> minutes in the hour, indeed hours in either the 12 or 24 hour clock.
> The problem is to determine if a given value is in the sub-range
> specified by a start and an en value.
> 
> I was specifically concerned with integer values where the sub-range
> includes the start value but excludes the end value.
> 
> Though I am not sure this merits the term "puzzle", I suggest that
> solutions be posted with some spoiler protection.  Do all the news
> readers used by programmers (or ex programmers) all respect the presence
> of a form-feed character...
> 
> ... like this?  Because that's my favourite way, rather than posting
> lots of dummy lines before the solution.
> 

I think this works ...

int in_subrange(int range, int start, int end, int check)
{
     check %= range;

     if (  ( end < start && (
                (check >= 0 && check <= end)
             || (check >= start && check < range)
             )
           )
        || ( check >= start && check <= end )
        )
             return 1;

     return 0;
}

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

#15983

Richard Harnden <richard.nospam@gmail.com> writes:

> On 21/11/2022 20:45, Ben Bacarisse wrote:
>
>> I wonder if there are any real posters here?  Let's see...
>>
>> I came across a trivial programming task that must have been solved a
>> thousand times by other programmers, but it had never crossed my path
>> until yesterday.  I must be feeling my age because I made a real hash of
>> tackling it at first.  Anyway, I thought it might be of interest.
>>
>> Consider any ordered measure that "wraps round" -- bearings in degrees,
>> minutes in the hour, indeed hours in either the 12 or 24 hour clock.
>> The problem is to determine if a given value is in the sub-range
>> specified by a start and an en value.
>>
>> I was specifically concerned with integer values where the sub-range
>> includes the start value but excludes the end value.
>>
>> Though I am not sure this merits the term "puzzle", I suggest that
>> solutions be posted with some spoiler protection.  Do all the news
>> readers used by programmers (or ex programmers) all respect the presence
>> of a form-feed character...
>> 
>> ... like this?  Because that's my favourite way, rather than posting
>> lots of dummy lines before the solution.
>
> I think this works ...
>
> int in_subrange(int range, int start, int end, int check)
> {
>     check %= range;
>
>     if (  ( end < start && (
>                (check >= 0 && check <= end)
>             || (check >= start && check < range)
>             )
>           )
>        || ( check >= start && check <= end )
>        )
>             return 1;
>
>     return 0;
> }

Have you thought about a case where the values of check, start,
and end are chosen from the interval -9000000000 to 9000000000?
How about the interval -18000000000 to 18000000000?

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

#15984

On 28/11/2022 15:30, Tim Rentsch wrote:
> Richard Harnden <richard.nospam@gmail.com> writes:
> 
>> On 21/11/2022 20:45, Ben Bacarisse wrote:
>>
>>> I wonder if there are any real posters here?  Let's see...
>>>
>>> I came across a trivial programming task that must have been solved a
>>> thousand times by other programmers, but it had never crossed my path
>>> until yesterday.  I must be feeling my age because I made a real hash of
>>> tackling it at first.  Anyway, I thought it might be of interest.
>>>
>>> Consider any ordered measure that "wraps round" -- bearings in degrees,
>>> minutes in the hour, indeed hours in either the 12 or 24 hour clock.
>>> The problem is to determine if a given value is in the sub-range
>>> specified by a start and an en value.
>>>
>>> I was specifically concerned with integer values where the sub-range
>>> includes the start value but excludes the end value.
>>>
>>> Though I am not sure this merits the term "puzzle", I suggest that
>>> solutions be posted with some spoiler protection.  Do all the news
>>> readers used by programmers (or ex programmers) all respect the presence
>>> of a form-feed character...
>>> 
>>> ... like this?  Because that's my favourite way, rather than posting
>>> lots of dummy lines before the solution.
>>
>> I think this works ...
>>
>> int in_subrange(int range, int start, int end, int check)
>> {
>>      check %= range;
>>
>>      if (  ( end < start && (
>>                 (check >= 0 && check <= end)
>>              || (check >= start && check < range)
>>              )
>>            )
>>         || ( check >= start && check <= end )
>>         )
>>              return 1;
>>
>>      return 0;
>> }
> 
> Have you thought about a case where the values of check, start,
> and end are chosen from the interval -9000000000 to 9000000000?
> How about the interval -18000000000 to 18000000000?

Nope, I assume that start and end are between zero and range, and that 
check is greater that zero.

I didn't think about overflows at all.

With unsigned integers ...

int in_subrange(uint_fast64_t range, uint_fast64_t start, uint_fast64_t 
end, uint_fast64_t check)
{
     check %= range;

     if (  ( end < start && (
                check <= end
             || (check >= start && check < range)
             )
           )
        || ( check >= start && check <= end )
        )
             return 1;

     return 0;
}

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

#15989

Richard Harnden <richard.nospam@gmail.com> writes:

> On 28/11/2022 15:30, Tim Rentsch wrote:
>
>> Richard Harnden <richard.nospam@gmail.com> writes:
>>
>>> On 21/11/2022 20:45, Ben Bacarisse wrote:
>>>
>>>> I wonder if there are any real posters here?  Let's see...
>>>>
>>>> I came across a trivial programming task that must have been
>>>> solved a thousand times by other programmers, but it had never
>>>> crossed my path until yesterday.  I must be feeling my age
>>>> because I made a real hash of tackling it at first.  Anyway, I
>>>> thought it might be of interest.
>>>>
>>>> Consider any ordered measure that "wraps round" -- bearings in
>>>> degrees, minutes in the hour, indeed hours in either the 12 or 24
>>>> hour clock.  The problem is to determine if a given value is in
>>>> the sub-range specified by a start and an en value.
>>>>
>>>> I was specifically concerned with integer values where the
>>>> sub-range includes the start value but excludes the end value.
>>>> [...]
>>>
>>> I think this works ...
>>>
>>> int in_subrange(int range, int start, int end, int check)
>>> {
>>>      check %= range;
>>>
>>>      if (  ( end < start && (
>>>                 (check >= 0 && check <= end)
>>>              || (check >= start && check < range)
>>>              )
>>>            )
>>>         || ( check >= start && check <= end )
>>>         )
>>>              return 1;
>>>
>>>      return 0;
>>> }
>>
>> Have you thought about a case where the values of check, start,
>> and end are chosen from the interval -9000000000 to 9000000000?
>> How about the interval -18000000000 to 18000000000?
>
> Nope, I assume that start and end are between zero and range, and
> that check is greater that zero.

This assumption doesn't match the problem statement (emphasis
added):

    Consider >> any << ordered measure that "wraps round"

What's being asked for is a function that will work with any
ordered measure (that wraps), not just some such measures.  An
example of such a measure is longitude, which goes from -180
to +180 (with one of the two extreme values omitted).  Similarly
there is no reason not to allow a measure that is only positive
integers but does not include zero.  An important part of the
challenge is to come up with a solution that handles these cases
as well as the more obvious ones.

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

#15993

On 29/11/2022 12:03, Tim Rentsch wrote:
> Richard Harnden <richard.nospam@gmail.com> writes:
> 
>> On 28/11/2022 15:30, Tim Rentsch wrote:
>>
>>> Richard Harnden <richard.nospam@gmail.com> writes:
>>>
>>>> On 21/11/2022 20:45, Ben Bacarisse wrote:
>>>>
>>>>> I wonder if there are any real posters here?  Let's see...
>>>>>
>>>>> I came across a trivial programming task that must have been
>>>>> solved a thousand times by other programmers, but it had never
>>>>> crossed my path until yesterday.  I must be feeling my age
>>>>> because I made a real hash of tackling it at first.  Anyway, I
>>>>> thought it might be of interest.
>>>>>
>>>>> Consider any ordered measure that "wraps round" -- bearings in
>>>>> degrees, minutes in the hour, indeed hours in either the 12 or 24
>>>>> hour clock.  The problem is to determine if a given value is in
>>>>> the sub-range specified by a start and an en value.
>>>>>
>>>>> I was specifically concerned with integer values where the
>>>>> sub-range includes the start value but excludes the end value.
>>>>> [...]
>>>>
>>>> I think this works ...
>>>>
>>>> int in_subrange(int range, int start, int end, int check)
>>>> {
>>>>       check %= range;
>>>>
>>>>       if (  ( end < start && (
>>>>                  (check >= 0 && check <= end)
>>>>               || (check >= start && check < range)
>>>>               )
>>>>             )
>>>>          || ( check >= start && check <= end )
>>>>          )
>>>>               return 1;
>>>>
>>>>       return 0;
>>>> }
>>>
>>> Have you thought about a case where the values of check, start,
>>> and end are chosen from the interval -9000000000 to 9000000000?
>>> How about the interval -18000000000 to 18000000000?
>>
>> Nope, I assume that start and end are between zero and range, and
>> that check is greater that zero.
> 
> This assumption doesn't match the problem statement (emphasis
> added):
> 
>      Consider >> any << ordered measure that "wraps round"
> 
> What's being asked for is a function that will work with any
> ordered measure (that wraps), not just some such measures.  An
> example of such a measure is longitude, which goes from -180
> to +180 (with one of the two extreme values omitted).  Similarly > there is no reason not to allow a measure that is only positive
> integers but does not include zero.  An important part of the
> challenge is to come up with a solution that handles these cases
> as well as the more obvious ones.

Okay, so how about this ... ?

int in_subrange(int_fast64_t range_min, int_fast64_t range_max, 
int_fast64_t start, int_fast64_t end, int_fast64_t check)
{
     while ( check < range_min )
         check += range_max - range_min;

     while ( check > range_max )
         check -= range_max - range_min;

     if (  ( end < start && (
                ( check > range_min && check <= end )
             || (check >= start && check < range_max)
             )
           )
        || ( check >= start && check <= end )
        )
             return 1;

     return 0
}

It's okay for check to have 'clocked', range_min, range_max, start and 
end have sensible values.

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

#15994

On 2022-11-29 16:03, Richard Harnden wrote:

> Okay, so how about this ... ?
> 
> int in_subrange(int_fast64_t range_min, int_fast64_t range_max, 
> int_fast64_t start, int_fast64_t end, int_fast64_t check)
> {
>      while ( check < range_min )
>          check += range_max - range_min;

Ring modulo would be range_max - range_min + 1

> It's okay for check to have 'clocked', range_min, range_max, start and 
> end have sensible values.

If the language supports modular and ranged types there is no need to 
check/normalize arguments.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#15998

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2022-11-29 16:03, Richard Harnden wrote:
>
>> Okay, so how about this ... ?
>> int in_subrange(int_fast64_t range_min, int_fast64_t range_max, 
>> int_fast64_t start, int_fast64_t end, int_fast64_t check)
>> {
>>      while ( check < range_min )
>>          check += range_max - range_min;
>
> Ring modulo would be range_max - range_min + 1
>
>> It's okay for check to have 'clocked', range_min, range_max, start
>> and end have sensible values.
>
> If the language supports modular and ranged types there is no need to
> check/normalize arguments.

Part of the specification was that the inputs were intended to be valid,
though maybe that was not very clear.  In the case where this cropped
up, everything was in minutes coming from internal clocks and calendars
where the result were already in the 0-59 range.

In my view, if you need to check the arguments, that's a separate
function because what to do with bad data is so often
application-specific.  Just normalising and carrying on is only one
strategy, and one that can delay detecting bugs.  In your solution, you
normalised the degrees, minutes and seconds into a longitude beforehand,
which is all that was needed in that example.

-- 
Ben.

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

#16000

On 2022-11-29 18:37, Ben Bacarisse wrote:

> In my view, if you need to check the arguments, that's a separate
> function because what to do with bad data is so often
> application-specific.

Yes, validation is a part of the measurement process. Usually datatype 
in which sensors report data and ones used in computations are 
different. Validation happens upon conversion and then, ideally, invalid 
values are excluded per design.

> Just normalising and carrying on is only one
> strategy, and one that can delay detecting bugs.

Sure. E.g. IEEE 754 float design is a perfect example of such bugs when 
computations with non-numbers just continue until too late.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

#16001

On Tuesday, 29 November 2022 at 19:02:19 UTC+1, Dmitry A. Kazakov wrote:
> On 2022-11-29 18:37, Ben Bacarisse wrote: 
> 
> > In my view, if you need to check the arguments, that's a separate 
> > function because what to do with bad data is so often 
> > application-specific.
> 
> Yes, validation is a part of the measurement process. Usually datatype 
> in which sensors report data and ones used in computations are 
> different. Validation happens upon conversion and then, ideally, invalid 
> values are excluded per design.
> 
> > Just normalising and carrying on is only one 
> > strategy, and one that can delay detecting bugs.
> 
> Sure. E.g. IEEE 754 float design is a perfect example of such bugs when 
> computations with non-numbers just continue until too late.

A couple of very nonsensical statements.

But congratulations especially for always
fighting the good fight...

Julio

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

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

Back to top | Article view | comp.programming

csiph-web