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

Groups > comp.lang.c++ > #15008 > unrolled thread

Setting floating point variable as infinite

Back to article view | Back to comp.lang.c++

Contents

  Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 12:27 +0000
    Re: Setting floating point variable as infinite Marc <marc.glisse@gmail.com> - 2012-03-23 12:34 +0000
      Re: Setting floating point variable as infinite glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-23 12:39 +0000
        Re: Setting floating point variable as infinite gwowen <gwowen@gmail.com> - 2012-03-23 06:21 -0700
        Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 14:39 +0000
          Re: Setting floating point variable as infinite glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-23 20:06 +0000
    Re: Setting floating point variable as infinite Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-23 10:32 -0400
      Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 15:03 +0000
        Re: Setting floating point variable as infinite Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-23 11:50 -0400
          Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-23 19:01 +0000
            Re: Setting floating point variable as infinite Christian Gollwitzer <auriocus@gmx.de> - 2012-03-23 20:26 +0100
            Re: Setting floating point variable as infinite Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-23 19:10 -0400
              Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-24 11:43 +0000
          Re: Setting floating point variable as infinite Miles Bader <miles@gnu.org> - 2012-03-24 09:46 +0900
            Re: Setting floating point variable as infinite Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-23 23:42 -0400
              Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-24 11:31 +0000
              Re: Setting floating point variable as infinite Miles Bader <miles@gnu.org> - 2012-03-24 23:41 +0900
      Re: Setting floating point variable as infinite Andrea Venturoli <ml.diespammer@netfence.it> - 2012-03-24 13:05 +0100
        Re: Setting floating point variable as infinite Victor Bazarov <v.bazarov@comcast.invalid> - 2012-03-24 15:44 -0400
    Re: Setting floating point variable as infinite Leigh Johnston <leigh@i42.co.uk> - 2012-03-24 12:30 +0000
      Re: Setting floating point variable as infinite Gareth Owen <gwowen@gmail.com> - 2012-03-25 07:52 +0100
      Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-25 12:38 +0100
        Re: Setting floating point variable as infinite Leigh Johnston <leigh@i42.co.uk> - 2012-03-25 13:36 +0100
          Re: Setting floating point variable as infinite Leigh Johnston <leigh@i42.co.uk> - 2012-03-25 14:00 +0100
            Re: Setting floating point variable as infinite Leigh Johnston <leigh@i42.co.uk> - 2012-03-25 14:05 +0100
              Re: Setting floating point variable as infinite Rui Maciel <rui.maciel@gmail.com> - 2012-03-25 16:54 +0100

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

#15038

Leigh Johnston <leigh@i42.co.uk> writes:

> Yes there is a better way, use: std::min_element

... but don't forget to handle the empty set case.

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

#15043

Leigh Johnston wrote:

> Yes there is a better way, use: std::min_element

Considering that the values being compared aren't stored and, instead, are 
calculated by an operator which is called for this specific purpose, doesn't 
std::min_element require more than n calls to that operator, n being 
container::size() ?

Another inconvenience is that std::min_element only returns an iterator 
pointing to the element which relates to the smallest value.  If the 
objective is to determine that particular value then using std::min_element 
requires an extra call to that operator.

Meanwhile, the method which has been presented and relies on 
std::numeric_limits<float>::infinity() only requires n calls to the 
operator, and in the end the smallest value is already provided.


Rui Maciel

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

#15045

On 25/03/2012 12:38, Rui Maciel wrote:
> Leigh Johnston wrote:
>
>> Yes there is a better way, use: std::min_element
>
> Considering that the values being compared aren't stored and, instead, are
> calculated by an operator which is called for this specific purpose, doesn't
> std::min_element require more than n calls to that operator, n being
> container::size() ?

No.  Exactly n calls will be made to the operator (predicate).

>
> Another inconvenience is that std::min_element only returns an iterator
> pointing to the element which relates to the smallest value.  If the
> objective is to determine that particular value then using std::min_element
> requires an extra call to that operator.

Hardly a major inconvenience.  An added benefit is the returned iterator 
will point to end() if the container is empty: your method cannot 
distinguish between an empty container and a container that only 
contains elements that evaluate to std::numeric_limits<float>::infinity().

>
> Meanwhile, the method which has been presented and relies on
> std::numeric_limits<float>::infinity() only requires n calls to the
> operator, and in the end the smallest value is already provided.

std::min_element allows you to obtain this information without 
reinventing the wheel.  Bottom line: avoid explicit loops where 
possible; use standard algorithms where possible.

/Leigh

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

#15046

On 25/03/2012 13:36, Leigh Johnston wrote:
> On 25/03/2012 12:38, Rui Maciel wrote:
>> Leigh Johnston wrote:
>>
>>> Yes there is a better way, use: std::min_element
>>
>> Considering that the values being compared aren't stored and, instead,
>> are
>> calculated by an operator which is called for this specific purpose,
>> doesn't
>> std::min_element require more than n calls to that operator, n being
>> container::size() ?
>
> No. Exactly n calls will be made to the operator (predicate).

Sorry slight error there: max((last - first) - 1, 0) calls will be made 
so for a non-empty container that will be n-1 calls.

/Leigh

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

#15047

On 25/03/2012 14:00, Leigh Johnston wrote:
> On 25/03/2012 13:36, Leigh Johnston wrote:
>> On 25/03/2012 12:38, Rui Maciel wrote:
>>> Leigh Johnston wrote:
>>>
>>>> Yes there is a better way, use: std::min_element
>>>
>>> Considering that the values being compared aren't stored and, instead,
>>> are
>>> calculated by an operator which is called for this specific purpose,
>>> doesn't
>>> std::min_element require more than n calls to that operator, n being
>>> container::size() ?
>>
>> No. Exactly n calls will be made to the operator (predicate).
>
> Sorry slight error there: max((last - first) - 1, 0) calls will be made
> so for a non-empty container that will be n-1 calls.

Sorry you are correct; whilst there will be n-1 calls of the predicate 
that will mean more than n calls of your operator inside the predicate. 
  This is only a problem if your operator is an expensive operation; is 
your operator an expensive operation?

/Leigh

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

#15048

Leigh Johnston wrote:

> Sorry you are correct; whilst there will be n-1 calls of the predicate
> that will mean more than n calls of your operator inside the predicate.
> This is only a problem if your operator is an expensive operation; is
> your operator an expensive operation?

At this moment I can't say, but I suspect that it will be expensive.  The 
operator which maps each element to a float is defined through a strategy 
pattern, and currently I don't have any way to know which strategies will be 
implemented.


Rui Maciel

[toc] | [prev] | [standalone]

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

Back to top | Article view | comp.lang.c++

csiph-web