Range objects and fancy indexing -- Re: Removing elements from dynamic arrays?
peylow at gmail.com
Wed Nov 1 09:09:37 PST 2006
Bill Baxter skrev:
> Fredrik Olsson wrote:
>> Bill Baxter skrev:
>>> Note that if 3..5 returned a range object, then there would be no
>>> real need for the opSlice methods. They would be replaced by opIndex
>>> overloaed for the range type. E.g opIndex(range r)
>> I cut most of it, as you know what I am referring to anyway :).
>> Ranges and sets are related, in fact in my own sets implementation I
>> have four kinds of sets:
>> - finite sets
> Ok. Is that just numbers or anything?
>> - range sets
> Ok. That must be just numbers. Does that include things like the set
> containing the semi-open real number intervals (1,3] and [5,7)?
Yes. As well as -infinite, and +infinite.
>> - computer sets
> No idea what that is. It sounds like a set of computers, which would be
> hard to implement with just code. :-)
Misspelled, computed set that is. See it as "set operators". For example
the union of sets, etc.
>> - functions sets
> A set of functions? A collection of things like 'int function(int bar)'?
No a set where membership is determined by a function. For example a set
with primes, even integers, etc.
>> This implantation is however an overkill, and way too slow, as it also
>> covers infinite sets. For a compiler feature finite sets is the only
>> realistic goal. But having a infinite set solution as well in the
>> standard lib is good too.
> Haskell's lazy infinite lists are pretty nifty in that regard.
>> I think you should be able to have sets of any type, and ranges of any
>> numeric type. For obvious reasons finite sets of integers can be
>> optimized greatly if used having a special case. And in worst case, I
>> can live with only them (As they make up for 99% of real world cases
>> and a templete implementation can fix the rest).
> Ok, but I think sets of arbitrary objects are also about as common as
> sets of integers.
Common yes, but set arithmetics are not common on them. So for most
implementations a dynamic array is just fine. Some templates array
manipulation, like what I think Oscar Linde posted some months ago would
be fine (map function etc).
>> I would suggest declaring a set as this:
>> int<> foo = <1,2,3>;
>> char<> bar = <'a'..'z', 'A'..'Z'>;
> Y'know there's a reason the < and > are available. It's because their
> use in templates caused annoying ambiguity in C++ when nesting. Your
> sets notation will have the same problem.
> int<int<>> /*oops!*/ foo = <</*oops*/1,2>,<3,4>>/*oops!*/;
> So instead you could follow the lead of templates and use parens with a
> sigil. Like $! Looks sort of like an 'S' for set. :-)
> $int foo = $(1,2,3);
> $char bar = $('a'..'z', 'A'..'Z');
> Urm, nah. People are going to start thinking they're reading Perl or
> BASIC code. The great thing about sets is that 'set' is such a small word.
> auto foo = set([1,2,3]);
> auto bar = set(['a'..'z', 'A'..'Z']);
> Why bother with introducing another syntax?
>> How a range type can be declared, I am not sure. Writing the literals
>> is obvious with the .. operator. But for declaring?
>> int.. foo = 1..42;
>> Just does not look right :).
> Yeh, that does look odd. I don't really see a great need for a special
> range syntax. Have a standard definition for a thing called a 'range',
> and make that be what 1..42 evaluates to.
> range!(int) foo = 1..42;
> auto foo = 1..42;
Well, I do not much care for the actual syntax, I just think <...> looks
nice, and D-like :).
But $ works for me, but as a suffix when declaring, as you might want:
int$ foo; // set of int arrays. $int would be ambiguous.
I do however think a range-specific-syntax is crucial if ranges are to
be first class citizens. Using range!(type) would demote it to a
template hack, and auto would force programmers to initialize.
// Fredrik Olsson
More information about the Digitalmars-d-learn