On Friday, 20 February 2015 at 08:22:38 UTC, John Colvin wrote:
Maybe I'm missing something, but I don't see anything here that
isn't already covered by built-in slices, opSlice,
opSliceAssign and put.
That's the wrong direction. What you want is a means to query a
unknown container for it's
On Friday, 20 February 2015 at 09:44:36 UTC, John Colvin wrote:
Eh? Knowing the ordering and that the distribution is uniform*
isn't going to be enough to iterate by SIMD. You need to know
the complete iteration scheme.
That's the point of a concept. The concept provides constraints
that in
On Friday, 20 February 2015 at 08:45:23 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 20 February 2015 at 08:22:38 UTC, John Colvin wrote:
Maybe I'm missing something, but I don't see anything here
that isn't already covered by built-in slices, opSlice,
opSliceAssign and put.
That's the wrong
On Thursday, 19 February 2015 at 23:11:16 UTC, Pasqui23 wrote:
On Thursday, 19 February 2015 at 19:32:26 UTC, Andrei
Alexandrescu wrote:
I don't see a need for contiguous ranges if the only
embodiment is T[]. -- Andrei
Yeah,but it could be useful to access where the range is
located
So
On Friday, 20 February 2015 at 01:25:34 UTC, deadalnix wrote:
On Monday, 16 February 2015 at 06:06:19 UTC, Vlad Levenfeld
wrote:
Since C++17, there's a new iterator category: the contiguous
iterator. Check it out:
http://en.cppreference.com/w/cpp/iterator
So, by extension, I think a
and when to preserve
what information under which transformations is tough. Lazily
mapping, say, to increase the volume could meaningfully
preserve sampling rate, but under filtering, zipping or
striding it doesn't make sense.
The sensible thing to do is to have ranges of contiguous ranges:
1
APIs and supporting in-place transformations is also important.
On Thursday, 19 February 2015 at 19:32:26 UTC, Andrei
Alexandrescu wrote:
I don't see a need for contiguous ranges if the only embodiment
is T[]. -- Andrei
Agreed. I don't think that defining contiguous ranges as
implicitly
On Friday, 20 February 2015 at 19:54:20 UTC, Andrei Alexandrescu
wrote:
On 2/20/15 11:09 AM, deadalnix wrote:
On Friday, 20 February 2015 at 12:23:49 UTC, Vlad Levenfeld
wrote:
Yes. A slice is the simplest realization of a contiguous
range. I
argue that it is useful to have structures which
On Friday, 20 February 2015 at 19:47:24 UTC, Pasqui23 wrote:
You could have the best of both worlds this way:
R declaw_filter3(R)(R r)if(is(R:float[stride][],size_t
stride))
and write
ac.declaw_filter3.play;
Stride is tied to alignment and not value type size in the
general case (float
On Friday, 20 February 2015 at 09:44:36 UTC, John Colvin wrote:
*what do you even mean by that? Jargon is only useful when it's
used with precision.
Well, it is also very useful to sound smart and you have no
content to show for it.
On Friday, 20 February 2015 at 12:23:49 UTC, Vlad Levenfeld wrote:
Yes. A slice is the simplest realization of a contiguous range.
I argue that it is useful to have structures which have
slice-like behavior without actually being slices.
I'm still not sure what more complex continuous range
actually being slices.
I'm still not sure what more complex continuous range exists, and if
it is worth the complexity of adding them to the language.
What do contiguous ranges offer that isn't already offered by a random
access range that hasSlicing? If it doesn't offer significantly more
On Friday, 20 February 2015 at 19:09:15 UTC, deadalnix wrote:
I'm still not sure what more complex continuous range exists,
My last post has an example.
and if it is worth the complexity of adding them to the
language.
It might not be, I just find the concept itself interesting.
On Friday, 20 February 2015 at 19:28:38 UTC, H. S. Teoh wrote:
What do contiguous ranges offer that isn't already offered by a
random
access range that hasSlicing? If it doesn't offer significantly
more
power than what we already have,
hasSlicing:
«Returns true if R offers a slicing
On Friday, 20 February 2015 at 12:23:49 UTC, Vlad Levenfeld wrote:
Let me illustrate with an example:
struct AudioClip {
float[2][] samples;
uint sampling_rate;
this (string path) {load (path, samples);}
void play () {some_C_audio_lib_call (samples.ptr,
samples.length,
On 2/20/15 11:09 AM, deadalnix wrote:
On Friday, 20 February 2015 at 12:23:49 UTC, Vlad Levenfeld wrote:
Yes. A slice is the simplest realization of a contiguous range. I
argue that it is useful to have structures which have slice-like
behavior without actually being slices.
I'm still not
On Friday, 20 February 2015 at 19:06:29 UTC, deadalnix wrote:
On Friday, 20 February 2015 at 09:44:36 UTC, John Colvin wrote:
*what do you even mean by that? Jargon is only useful when
it's used with precision.
Well, it is also very useful to sound smart and you have no
content to show for
On Thursday, 19 February 2015 at 11:20:13 UTC, Guillaume Chatelet
wrote:
From this discussion I understand you mainly want to be able to
BitBlt ranges
http://en.wikipedia.org/wiki/Bit_blit
BitBlt covers multi dimensional arrays as well (2D textures)
and might convey the semantic you want
) and might
convey the semantic you want better than Contiguous (too fine grained ?).
Effectively bit blit range is a better name than contiguous range,but as
I have said this and range castable to T[] are not mutually exclusive
concepts.
I don't see a need for contiguous ranges if the only embodiment
On Monday, 16 February 2015 at 06:06:19 UTC, Vlad Levenfeld wrote:
Since C++17, there's a new iterator category: the contiguous
iterator. Check it out:
http://en.cppreference.com/w/cpp/iterator
So, by extension, I think a ContiguousRange would be any
RandomAccessRange which has a member
On Thursday, 19 February 2015 at 19:32:26 UTC, Andrei
Alexandrescu wrote:
I don't see a need for contiguous ranges if the only embodiment
is T[]. -- Andrei
Yeah,but it could be useful to access where the range is located
On Monday, 16 February 2015 at 06:06:19 UTC, Vlad Levenfeld wrote:
Since C++17, there's a new iterator category: the contiguous
iterator. Check it out:
http://en.cppreference.com/w/cpp/iterator
So, by extension, I think a ContiguousRange would be any
RandomAccessRange which has a member
On Tuesday, 17 February 2015 at 15:50:17 UTC, Andrei Alexandrescu
wrote:
for an array r, is r.retro contiguous or not?
I would argue that the only operations which preserve contiguity
are slicing, concatenating and appending; r.retro, r.stride,
r.map!f, etc should yield a RandomAccessRange.
accept contiguous ranges.
On Wednesday, 18 February 2015 at 16:10:30 UTC, Pasqui23 wrote:
No.The main strenght of the range api is its ability to
preserve range categories.The loss of range categories is a
*price* we pay for lazy evalutation,categories wich can be
restored by .array in exchange for the usual price for
and return a slice while preserving
the AudioClip's sampling rate.
My proposal and yours are not mutually exclusive.
A range wich can be casted to T[] is automatically considered
contiguous,but not all contiguous ranges are castable to T[](see
for example BinaryHeap!(T[]) ).
As an aside,I
, in that case people shouldn't
assume that .ptr necessarily points to the first element.
Contiguous ranges would help two useful primitives: r1.before(r2) yields
the portion of r1 before r2 (assumes r2 overlaps r1), and r1.after(r2)
yields the portion of r1 after r2 (same assumption). Basically
r1
On 2/17/15 8:13 AM, bearophile wrote:
Andrei Alexandrescu:
for an array r, is r.retro contiguous or not?
Is the most useful contiguous range forward? So can you name it
ForwardContiguousRange?
Ehm. Attractiveness of concepts increases with the number of cases
(structures + algorithms)
Andrei Alexandrescu:
for an array r, is r.retro contiguous or not?
Is the most useful contiguous range forward? So can you name it
ForwardContiguousRange?
Bye,
bearophile
On Mon, 16 Feb 2015 12:16:50 +, rupert wrote:
If you think you could do a better job than the C++ committee you should
submit a proposal.
https://isocpp.org/std/submit-a-proposal
why he *should* to that? he *may* submit it. when someone sees people
doing shit, he is not obliged to
On Monday, 16 February 2015 at 11:57:36 UTC, FG wrote:
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be
applauded for introducing what may become the biggest source of
typos. :)
Adjoining would
On Monday, 16 February 2015 at 11:57:36 UTC, FG wrote:
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be
applauded for introducing what may become the biggest source of
typos. :)
Adjoining would
Vlad Levenfeld:
a ContiguousRange would be any RandomAccessRange which has a
member called ptr which supports a dereferencing operator *
that yields an ElementType!R. This notion is useful for
functions which might otherwise perform an element-by-element
transfer to an OutputRange via put,
On 2015-02-16 at 07:06, Vlad Levenfeld wrote:
*ContigiousRange* has enough length [...]
LOL. The clearly masochistic C++ committee needs to be applauded for
introducing what may become the biggest source of typos. :)
Adjoining would be easier on the non-native English speakers than
Since C++17, there's a new iterator category: the contiguous
iterator. Check it out: http://en.cppreference.com/w/cpp/iterator
So, by extension, I think a ContiguousRange would be any
RandomAccessRange which has a member called ptr which supports a
dereferencing operator * that yields an
35 matches
Mail list logo
