RE: [boost] Re: Formal Review for Interval Library beginning

From: David Bergman (davidb_at_[hidden])
Date: 2002-09-03 13:26:57

Although I agree completely with your point of view that we might need
iterators even for these "scientific" intervals, I have two questions:

1. Is "numeric_limits::epsilon()" not only a valid step w.r.t. the
numeric type precision in a certain range, like [1, 1+epsilon], and not
necessarily valid elsewhere, i.e., the distance between two consecutive
represented numbers need not be epsilon()? This demands a more
intelligent (and variable) stepper.

2. In the defense of a "discrete" vs "continuous" view: can we not use
the term "non-discrete" or "continuous" with the implicit notion that it
adhers to the underlying (mathematical) concept, such as the real
numbers? It is a bit boring not to be able to use "non-discrete" in
these discussions ;-)

Taking the aforementioned semantics of "discrete", I must make a remark
regarding Guillaume viewing the two proposed traits ("discreteness" and
"analytical property") being antagonistic: I do not see that, what I see
is that a type cannot be analytical unless it is non-discrete, so we
have three categories: (1) discrete, (2) continuous but not analytical
(with the above semantics...) and (3) analytical.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Rozental, Gennadiy
Sent: Tuesday, September 03, 2002 2:02 PM
To: 'boost_at_[hidden]'
Subject: RE: [boost] Re: Formal Review for Interval Library beginning

> > Also, I happen to be abstract enough to not clearly
> distinguish "range"
> > and "interval". There seem to be two discriminators, that might be 
> > implemented as traits: (1) discreteness and (2)analytical
> properties.
> 
> What will "discreteness" provide? It looks to me like these two traits

> are not orthogonal at all; they are antagonistic. Indeed, if you 
> manipulate intervals on a discreet type and are interested in 
> iterators and traversal, then the analytical functions will not be of 
> any use. And vice versa.

  In a sense all types used in numeric computation are "discreet". It's
step that matter. Some will be happy with step equal 1. Some will need
1e-1000. Underlying type used to represent values in program we already
abstracted as template parameter. So in this sense I do not see why int
as internal parameter is worse then double. 
   Iterator concept could also be useful for intervals. Let say I want
to compute am integral over some interval. Would not the iterator be of
some help to implement the algorithm so it would use STL algorithms.
Since as I mentioned before all types are in fact discrete with the step
equal to numeric_limits::epsilon(), it could be a natural step for
iterator. I also should be possible define different step.
  So IMO I do not see to much differences between Interval and Range to
justify to different classes. Though I my be missing something.

Gennadiy.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost