Sorry for the amount of text, but I tried to explain everything
in a clear and simple way.
I'm willing to volunteer for adding support for more types in
iota. The relevant discussion is:
https://d.puremagic.com/issues/show_bug.cgi?id=10762
A few preliminary considerations:
- iota() currently r
Francesco Cattoglio:
Do you think this would make sense?
Other things in Phobos work like this. Usually in Phobos Big-O
requirements are more important than keeping the range type
unchanged.
Bye,
bearophile
On Monday, 23 December 2013 at 15:23:45 UTC, bearophile wrote:
If the new iota accepts new types, then no existing code is
using iota for such cases. So you are not breaking code is you
offer a more restricted range for such types, avoiding O(n)
behavior for them.
I do realize this, but I don
Francesco Cattoglio:
- iota() currently returns a Random Access range, and I'm sure
nobody would agree to downgrade the result to a ForwardRange or
an InputRange, because that would break an unknown amount of
code.
...
Everything else ends up being the same as before: popBack() can
be optimi
On Mon, Dec 23, 2013 at 03:00:25PM +, Francesco Cattoglio wrote:
> Sorry for the amount of text, but I tried to explain everything in a
> clear and simple way.
> I'm willing to volunteer for adding support for more types in iota.
> The relevant discussion is:
> https://d.puremagic.com/issues/sh
On Mon, Dec 23, 2013 at 03:30:12PM +, Francesco Cattoglio wrote:
> On Monday, 23 December 2013 at 15:23:45 UTC, bearophile wrote:
> >If the new iota accepts new types, then no existing code is using
> >iota for such cases. So you are not breaking code is you offer a
> >more restricted range for
On 12/23/13 7:00 AM, Francesco Cattoglio wrote:
A few preliminary considerations:
- iota() currently returns a Random Access range, and I'm sure nobody
would agree to downgrade the result to a ForwardRange or an InputRange,
because that would break an unknown amount of code.
Agreed.
- I think
Thank you everyone for the feedback. I made the wrong assumption
about phobos design, I didn't knew that the policy here is "when
needed, relax the range", and now I see it makes perfect sense.
The range will only be a RA range for types that implement (inc *
n) and ((end - begin) / step) (used
Francesco Cattoglio:
I agree. After relaxing the range, we can prefer a specialized
version over the iota(begin, end, 1) version. The latter should
be used as a backup instead for cases where ++ is not
implemented.
One possible disadvantage is when you want an array of various
iota (all of
On Tuesday, 24 December 2013 at 10:38:17 UTC, Francesco Cattoglio
wrote:
The range will only be a RA range for types that implement (inc
* n) and ((end - begin) / step) (used for lenght computation),
otherwise it will be a ForwardRange, because it can't be
directional if we can't compute the la
On Tuesday, 24 December 2013 at 11:05:05 UTC, Jakob Ovrum wrote:
On Tuesday, 24 December 2013 at 10:38:17 UTC, Francesco
Cattoglio wrote:
The range will only be a RA range for types that implement
(inc * n) and ((end - begin) / step) (used for lenght
computation), otherwise it will be a Forward
On Tuesday, 24 December 2013 at 11:05:05 UTC, Jakob Ovrum wrote:
On Tuesday, 24 December 2013 at 10:38:17 UTC, Francesco
Cattoglio wrote:
The range will only be a RA range for types that implement
(inc * n) and ((end - begin) / step) (used for lenght
computation), otherwise it will be a Forward
On Tuesday, 24 December 2013 at 10:44:54 UTC, bearophile wrote:
Francesco Cattoglio:
One possible disadvantage is when you want an array of various
iota (all of the same indexed type, like int) (currently this
doesn't compile), this was a potential use case for me:
void main() {
import
On Tuesday, 24 December 2013 at 11:25:04 UTC, Francesco Cattoglio
wrote:
There's a catch: if we want bidirectional, we need the last
element of the range.
`end` is a parameter to all overloads of `iota`. Note that it is
exclusive, so the first `back` is `--end`, not `end` as passed in
by the
On Tuesday, 24 December 2013 at 11:30:32 UTC, Jakob Ovrum wrote:
On Tuesday, 24 December 2013 at 11:25:04 UTC, Francesco
Cattoglio wrote:
There's a catch: if we want bidirectional, we need the last
element of the range.
Are you sure you understand bidirectional ranges correctly? Any
range that
On Tuesday, 24 December 2013 at 11:47:12 UTC, Francesco Cattoglio
wrote:
Correct, but there's no way to compute "back" with less than
O(n) complexity, unless division by increment is available.
(Actually, I think we can achieve O(log n) with multiplication
alone, but I think it might be lots of
On Tuesday, 24 December 2013 at 11:47:12 UTC, Francesco Cattoglio
wrote:
Correct, but there's no way to compute "back" with less than
O(n) complexity, unless division by increment is available.
I would like to add that I want to compute back because the
current documentation states: Returns a
On 24/12/13 11:38, Francesco Cattoglio wrote:
Ah, nice. There's an unstated assumption here - adding inc n times is the same
as adding n * inc.
Right, completely missed that. I guess checking a few test cases at compile time
is the best one can do. Checking for every n could take some infinite a
On Tuesday, 24 December 2013 at 11:57:04 UTC, Jakob Ovrum wrote:
On Tuesday, 24 December 2013 at 11:47:12 UTC, Francesco
Cattoglio wrote:
Correct, but there's no way to compute "back" with less than
O(n) complexity, unless division by increment is available.
(Actually, I think we can achieve O(
On 24/12/13 12:57, Jakob Ovrum wrote:
Implement `back` is really trivial.
Simplified example:
---
auto iota(T)(T start, T end)
{
static struct Result
{
T start, end;
bool empty() @property { return start == end; }
T front() @property { return start; }
On 24/12/13 13:58, monarch_dodra wrote:
I think you are missing the point of what happens if the step is not 1 (or if
the passed in type can have fractional input). EG:
iota(0, 105, 10);
or
iota(0, 10.5);
In this case, "back" should be 100, and not 95. To compute back, you need to be
able to ev
On Tue, Dec 24, 2013 at 11:57:03AM +, Jakob Ovrum wrote:
> On Tuesday, 24 December 2013 at 11:47:12 UTC, Francesco Cattoglio
> wrote:
> >Correct, but there's no way to compute "back" with less than O(n)
> >complexity, unless division by increment is available. (Actually,
> >I think we can achie
On 24/12/13 16:39, H. S. Teoh wrote:
This code is wrong for iota(1.0, 9.5), because .back must be of the form
start + n*step for some integer n, but in this case end is not an
integral multiple of step away from start. (It's not only wrong for
.back, it also won't terminate because start==end wil
On 12/24/13 3:57 AM, Jakob Ovrum wrote:
bool empty() @property { return start == end; }
This is better start >= end if ordering comparisons are supported.
Andrei
On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
On 24/12/13 13:58, monarch_dodra wrote:
I think you are missing the point of what happens if the step is not 1
(or if
the passed in type can have fractional input). EG:
iota(0, 105, 10);
or
iota(0, 10.5);
In this case, "back" should be 100, a
On Tue, Dec 24, 2013 at 09:10:53AM -0800, Andrei Alexandrescu wrote:
> On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
> >On 24/12/13 13:58, monarch_dodra wrote:
> >>I think you are missing the point of what happens if the step is not
> >>1 (or if the passed in type can have fractional input).
On Tue, Dec 24, 2013 at 09:27:54AM -0800, H. S. Teoh wrote:
> On Tue, Dec 24, 2013 at 09:10:53AM -0800, Andrei Alexandrescu wrote:
> > On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
> > >On 24/12/13 13:58, monarch_dodra wrote:
> > >>I think you are missing the point of what happens if the step
On Tuesday, 24 December 2013 at 18:56:02 UTC, Craig Dillabaugh
wrote:
On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei
Alexandrescu
wrote:
On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
clip
Doesn't think work, or am I missing something?
low + floor( (up-low)/step ) * step
I mean
On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei Alexandrescu
wrote:
On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
On 24/12/13 13:58, monarch_dodra wrote:
I think you are missing the point of what happens if the step
is not 1
(or if
the passed in type can have fractional input). EG:
On Tue, Dec 24, 2013 at 06:57:50PM +, Craig Dillabaugh wrote:
> On Tuesday, 24 December 2013 at 18:56:02 UTC, Craig Dillabaugh
> wrote:
> >On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei Alexandrescu
> >wrote:
> >>On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
> clip
> >
> >Doesn't th
On Tuesday, 24 December 2013 at 19:08:40 UTC, H. S. Teoh wrote:
On Tue, Dec 24, 2013 at 06:57:50PM +, Craig Dillabaugh
wrote:
On Tuesday, 24 December 2013 at 18:56:02 UTC, Craig Dillabaugh
wrote:
>On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei
>Alexandrescu
>wrote:
>>On 12/24/13 5:09
On 12/24/13 10:56 AM, Craig Dillabaugh wrote:
On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei Alexandrescu
wrote:
On 12/24/13 5:09 AM, Joseph Rushton Wakeling wrote:
On 24/12/13 13:58, monarch_dodra wrote:
I think you are missing the point of what happens if the step is not 1
(or if
the p
On 12/24/13 11:17 AM, Craig Dillabaugh wrote:
On Tuesday, 24 December 2013 at 19:08:40 UTC, H. S. Teoh wrote:
On Tue, Dec 24, 2013 at 06:57:50PM +, Craig Dillabaugh wrote:
On Tuesday, 24 December 2013 at 18:56:02 UTC, Craig Dillabaugh
wrote:
>On Tuesday, 24 December 2013 at 17:10:53 UTC, An
On Tue, Dec 24, 2013 at 11:35:49AM -0800, Andrei Alexandrescu wrote:
> On 12/24/13 10:56 AM, Craig Dillabaugh wrote:
> >On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei Alexandrescu
> >wrote:
[.[..]
> >>The integral cases are easy. We need to crack the floating point
> >>case: given numbers low
On 12/24/13 11:59 AM, H. S. Teoh wrote:
On Tue, Dec 24, 2013 at 11:35:49AM -0800, Andrei Alexandrescu wrote:
On 12/24/13 10:56 AM, Craig Dillabaugh wrote:
On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei Alexandrescu
wrote:
[.[..]
The integral cases are easy. We need to crack the floating
On Tue, Dec 24, 2013 at 12:57:02PM -0800, Andrei Alexandrescu wrote:
> On 12/24/13 11:59 AM, H. S. Teoh wrote:
> >On Tue, Dec 24, 2013 at 11:35:49AM -0800, Andrei Alexandrescu wrote:
> >>On 12/24/13 10:56 AM, Craig Dillabaugh wrote:
> >>>On Tuesday, 24 December 2013 at 17:10:53 UTC, Andrei Alexandr
On 12/24/13 1:09 PM, H. S. Teoh wrote:
On Tue, Dec 24, 2013 at 12:57:02PM -0800, Andrei Alexandrescu wrote:
On 12/24/13 11:59 AM, H. S. Teoh wrote:
On Tue, Dec 24, 2013 at 11:35:49AM -0800, Andrei Alexandrescu wrote:
On 12/24/13 10:56 AM, Craig Dillabaugh wrote:
On Tuesday, 24 December 2013 a
On Tue, Dec 24, 2013 at 01:18:34PM -0800, Andrei Alexandrescu wrote:
> On 12/24/13 1:09 PM, H. S. Teoh wrote:
> >On Tue, Dec 24, 2013 at 12:57:02PM -0800, Andrei Alexandrescu wrote:
> >>On 12/24/13 11:59 AM, H. S. Teoh wrote:
> >>>On Tue, Dec 24, 2013 at 11:35:49AM -0800, Andrei Alexandrescu wrote:
On 12/24/13 3:11 PM, H. S. Teoh wrote:
You're missing my point.
It's Christmas, let's be nice to one another :o). The only problem here
is that I didn't explain my point enough, which fostered confusion.
I'm not talking about popBack specifically
here. I'm talking about the problem of accum
Francesco Cattoglio:
Sorry for the amount of text, but I tried to explain everything
in a clear and simple way.
I'm willing to volunteer for adding support for more types in
iota.
Probably directly addressed by issue 10762:
Problem with iota(long)
https://d.puremagic.com/issues/show_bug.cgi?
On Wednesday, 25 December 2013 at 10:58:53 UTC, bearophile wrote:
Probably directly addressed by issue 10762:
[snip]
But if you rewrite iota() also take in account the following:
[snip again]
An important enhancement:
Optional "[]" syntax for std.range.iota too
Wow! That's a lot of stuff needing
On Wed, Dec 25, 2013 at 02:30:45PM +, Francesco Cattoglio wrote:
> On Wednesday, 25 December 2013 at 10:58:53 UTC, bearophile wrote:
[...]
> >(A less important enhancement is issue 11252).
> On the other hand, I have honestly no idea whatsoever about how to
> implement this
[...]
It should onl
On Tuesday, 24 December 2013 at 12:02:54 UTC, Francesco Cattoglio
wrote:
iota(DateTime(2012, 1, 1), DateTime(2013, 1, 1), dur!"days"(5));
can you easily tell what is the "back" element?
If it can't be defined reasonably for a custom step[1], then
simply don't support it when a custom step is p
On 28/12/13 09:06, Jakob Ovrum wrote:
[1] Which I'm not convinced of; e.g. `back` == `DateTime(2013, 1, 1) -
dur!"days"(5)`.
Are you sure that's going to work if the iota covers a leap year? :-)
On Saturday, 28 December 2013 at 12:16:32 UTC, Joseph Rushton
Wakeling wrote:
On 28/12/13 09:06, Jakob Ovrum wrote:
[1] Which I'm not convinced of; e.g. `back` == `DateTime(2013,
1, 1) -
dur!"days"(5)`.
Are you sure that's going to work if the iota covers a leap
year? :-)
And that's exactl
On Tuesday, 24 December 2013 at 15:41:06 UTC, H. S. Teoh wrote:
This code is wrong for iota(1.0, 9.5), because .back must be of
the form
start + n*step for some integer n, but in this case end is not
an
integral multiple of step away from start. (It's not only wrong
for
.back, it also won't ter
On Saturday, 28 December 2013 at 12:16:32 UTC, Joseph Rushton
Wakeling wrote:
Are you sure that's going to work if the iota covers a leap
year? :-)
How would it fail? std.datetime does a good job with leap years
AFAIK.
On 28/12/13 14:58, Jakob Ovrum wrote:
How would it fail? std.datetime does a good job with leap years AFAIK.
Try the attached code. The largest value of DateTime(2012, 1, 1) + dur!"days"(5
* n) that is less than DateTime(2013, 1, 1) is _not_ DateTime(2013, 1, 1) -
dur!"days"(5). :-)
import s
On 28/12/13 14:16, Francesco Cattoglio wrote:
And that's exactly the reason I choose 2012 as an example :D
It's going to get fun if we have to start taking into account leap seconds too
;-)
On a serious note -- I wouldn't worry about what kind of range type you generate
with iota. It'll be
On Saturday, 28 December 2013 at 13:58:40 UTC, Jakob Ovrum wrote:
On Saturday, 28 December 2013 at 12:16:32 UTC, Joseph Rushton
Wakeling wrote:
Are you sure that's going to work if the iota covers a leap
year? :-)
How would it fail? std.datetime does a good job with leap years
AFAIK.
Yes it
On Saturday, 28 December 2013 at 14:09:17 UTC, Joseph Rushton
Wakeling wrote:
Try the attached code. The largest value of DateTime(2012, 1,
1) + dur!"days"(5
* n) that is less than DateTime(2013, 1, 1) is _not_
DateTime(2013, 1, 1) -
dur!"days"(5). :-)
OK, so this has nothing to do with leap
On Saturday, 28 December 2013 at 14:13:08 UTC, Francesco
Cattoglio wrote:
It's always the same "issue": you have to compute the last
element inside iota, you should never rely on the user giving
you ideal inputs.
Alright, so require division for bidirectionality when given a
custom step. Ther
On 28/12/13 17:10, Jakob Ovrum wrote:
OK, so this has nothing to do with leap years, but that 5.days is an improper
step.
Oh, I see -- you're assuming that iota has to be defined with start, end and
step such that end = start + (n * step) for some integer n >= 0.
I can see the case for it,
On Saturday, 28 December 2013 at 16:30:27 UTC, Joseph Rushton
Wakeling wrote:
I can see the case for it, but to me it seems like a too
restrictive requirement.
Yes, I can totally see that. I'm not really invested either way,
because while I see a need for bidirectionality with `iota(start,
en
On Saturday, 28 December 2013 at 16:13:45 UTC, Jakob Ovrum wrote:
Alright, so require division for bidirectionality when given a
custom step. There's no reason division should be required for
bidirectionality in the most common case of iota(start, end).
Ok, now I finally get your point. It goe
On Saturday, 28 December 2013 at 19:22:25 UTC, Francesco
Cattoglio wrote:
On Saturday, 28 December 2013 at 16:13:45 UTC, Jakob Ovrum
wrote:
Alright, so require division for bidirectionality when given a
custom step. There's no reason division should be required for
bidirectionality in the most
On 27 Dec 2013 20:33, "H. S. Teoh" wrote:
>
> On Wed, Dec 25, 2013 at 02:30:45PM +, Francesco Cattoglio wrote:
> > On Wednesday, 25 December 2013 at 10:58:53 UTC, bearophile wrote:
> [...]
> > >(A less important enhancement is issue 11252).
> > On the other hand, I have honestly no idea whatso
57 matches
Mail list logo
