## digitalmars.D - how to do iota(0,256) with ubytes ? (cf need for iotaInclusive)

Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.

of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to ubyte

Could we have a function with iota_inclusive that has inclusive bounds for
'end' parameter ?
Oct 08 2015
John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.

of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to
ubyte

Could we have a function with iota_inclusive that has inclusive
bounds for 'end' parameter ?
A bounds parameter would be nice, like in std.random.uniform. For anyone googling for a solution to this, here's a workaround: auto b = iota(0, 256).map!"cast(ubyte)a"; Unfortunately this doesn't scale to iterating over all values of long or ulong.
Oct 09 2015
John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.

of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to
ubyte

Could we have a function with iota_inclusive that has
inclusive bounds for 'end' parameter ?
A bounds parameter would be nice, like in std.random.uniform. For anyone googling for a solution to this, here's a workaround: auto b = iota(0, 256).map!"cast(ubyte)a"; Unfortunately this doesn't scale to iterating over all values of long or ulong.
ugh, didn't see other people had posted the same response, the thread got split...
Oct 09 2015
Temtaime <temtaime gmail.com> writes:
On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.

of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to
ubyte

Could we have a function with iota_inclusive that has
inclusive bounds for 'end' parameter ?
A bounds parameter would be nice, like in std.random.uniform. For anyone googling for a solution to this, here's a workaround: auto b = iota(0, 256).map!"cast(ubyte)a"; Unfortunately this doesn't scale to iterating over all values of long or ulong.
Do not use string lambdas. It will be deprecated. map!(a => cast(uint)a) is correct
Oct 11 2015
John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 11 October 2015 at 13:58:24 UTC, Temtaime wrote:
On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.

of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to
ubyte

Could we have a function with iota_inclusive that has
inclusive bounds for 'end' parameter ?
A bounds parameter would be nice, like in std.random.uniform. For anyone googling for a solution to this, here's a workaround: auto b = iota(0, 256).map!"cast(ubyte)a"; Unfortunately this doesn't scale to iterating over all values of long or ulong.
Do not use string lambdas. It will be deprecated.
I'm pretty sure that's not going to happen. Could you point me to something that supports that statement? I know there a few people who *want* them to be deprecated/removed, but that's a very different matter from "will be deprecated".
Oct 11 2015
Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, 11 October 2015 at 15:34:38 UTC, John Colvin wrote:
On Sunday, 11 October 2015 at 13:58:24 UTC, Temtaime wrote:
Do not use string lambdas. It will be deprecated.
I'm pretty sure that's not going to happen. Could you point me to something that supports that statement? I know there a few people who *want* them to be deprecated/removed, but that's a very different matter from "will be deprecated".
Their use is discouraged at this point, but they're used by so much code that I'd be very surprised if they were ever deprecated. And until we have a solution for being able to compare non-string lambdas for equality, they're _defintely_ not going to be deprecated. Regardless, AFAIK, neither Walter nor Andrei has ever stated that they will be removed from Phobos - just that we want to move towards using the newer style lambdas instead. - Jonathan M Davis
Oct 11 2015
Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Sunday, 11 October 2015 at 21:31:27 UTC, Jonathan M Davis
wrote:
Their use is discouraged at this point, but they're used by so
much code that I'd be very surprised if they were ever
deprecated. And until we have a solution for being able to
compare non-string lambdas for equality, they're _defintely_
not going to be deprecated. Regardless, AFAIK, neither Walter
nor Andrei has ever stated that they will be removed from
Phobos - just that we want to move towards using the newer
Besides, `reduce!"a+b"` and `map!"a*a"` are more concise than the lambda versions and can therefore be preferable in some situations.
Oct 12 2015
Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 12 October 2015 at 09:24:12 UTC, Marc Schütz wrote:
On Sunday, 11 October 2015 at 21:31:27 UTC, Jonathan M Davis
wrote:
Their use is discouraged at this point, but they're used by so
much code that I'd be very surprised if they were ever
deprecated. And until we have a solution for being able to
compare non-string lambdas for equality, they're _defintely_
not going to be deprecated. Regardless, AFAIK, neither Walter
nor Andrei has ever stated that they will be removed from
Phobos - just that we want to move towards using the newer
Besides, `reduce!"a+b"` and `map!"a*a"` are more concise than the lambda versions and can therefore be preferable in some situations.
Yeah. I like them, but if it weren't for the fact that regular lambdas can't be compared, it would probably be being pushed as bad practice to use string lambdas. They were already removed from all of the std.algorithm docs because of that. They generally seem to be considered a failure that has been replaced by the shorter lambda syntax that we copied from C#. - Jonathan M Davis
Oct 12 2015
Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
For anyone googling for a solution to this, here's a workaround:

auto b = iota(0, 256).map!"cast(ubyte)a";
Without string lambdas: auto b = iota(0, 256).map!(a => cast(ubyte)a); I would suggest to turn this pattern into a new algorithm typically called iotaOf(T, B, E)(B begin, E end); called as iotaOf!ubyte(0,256) and use `std.conv.to` instead.
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 12 October 2015 at 08:38:39 UTC, Per Nordlöw wrote:
I would suggest to turn this pattern into a new algorithm
typically called

iotaOf(T, B, E)(B begin, E end);

called as

iotaOf!ubyte(0,256)

Here's a solution: https://github.com/nordlow/justd/blob/a8b733034b049dc2abeabaa37332e503f39e9066/range_ex.d#L434
Oct 12 2015
Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to
ubyte
Oct 12 2015
Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 12 October 2015 at 08:20:12 UTC, Per Nordlöw wrote:

iota!ubyte(0, 256)

?
Ahh, already present of course, according to declaration auto iota(B, E)( B begin, E end ) if (isIntegral!(CommonType!(B, E)) || isPointer!(CommonType!(B, E))); This will make `B` be ubyte and `E` be int. I guess current behaviour is to return a range where `ElementType` is `CommonType!(ubyte, int)` which is `int`.
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/15 11:20 AM, Per Nordlöw wrote:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to ubyte
We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu
wrote:
We can add iota!T() with no arguments that spans the entire
range of T (integral). -- Andrei
Clever, as always, Andrei! ;) Should I do a PR?
Oct 12 2015
Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
that's only a partial fix:
I also would like to express:

iotaInclusive(1,256)
iotaInclusive(1,256,3)

etc

On Mon, Oct 12, 2015 at 12:31 PM, Nordl=C3=B6w via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:

We can add iota!T() with no arguments that spans the entire range of T
(integral). -- Andrei
Clever, as always, Andrei! ;) Should I do a PR?
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/15 10:55 PM, Timothee Cour via Digitalmars-d wrote:
that's only a partial fix:
I also would like to express:

iotaInclusive(1,256)
iota!ubyte.drop(1)
iotaInclusive(1,256,3)
iota!ubyte.drop(1).stride(3) Just playing devil's advocate. Andrei
Oct 12 2015
Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, Oct 12, 2015 at 1:41 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

On 10/12/15 10:55 PM, Timothee Cour via Digitalmars-d wrote:

that's only a partial fix:
I also would like to express:

iotaInclusive(1,256)
iota!ubyte.drop(1) iotaInclusive(1,256,3)

iota!ubyte.drop(1).stride(3)
That's not a good workaround; it's error-prone in more general cases: auto fun(ubyte a, ubyte stride){ // return iotaInclusive(a,256, stride);// simple // error prone with your suggestion: auto b=some function of a, stride; return iota!ubyte.drop(b).stride(stride); }

Andrei
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/15 10:31 PM, Nordlöw wrote:
On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
We can add iota!T() with no arguments that spans the entire range of T
(integral). -- Andrei
Clever, as always, Andrei! ;) Should I do a PR?
Guess I'd pull it. Flattery will take you anywhere :o). -- Andrei
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu
wrote:
Guess I'd pull it. Flattery will take you anywhere :o). --
Andrei
Got it.
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu
wrote:
Alexandrescu wrote:
We can add iota!T() with no arguments that spans the entire
range of T
(integral). -- Andrei
From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/15 11:51 PM, Nordlöw wrote:
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:
Alexandrescu wrote:
We can add iota!T() with no arguments that spans the entire range of T
(integral). -- Andrei
From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?
One possibility (can't look at the code now) is to change the implementation to use a closed interval for state, then use that. But then you still need to mind overflow. Whole range is just a bit special like that. -- Andrei
Oct 12 2015
Jacques =?UTF-8?B?TcO8bGxlcg==?= <jacques.mueller gmx.de> writes:
On Monday, 12 October 2015 at 20:51:40 UTC, Nordlöw wrote:
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu
wrote:
Alexandrescu wrote:
We can add iota!T() with no arguments that spans the entire
range of T
(integral). -- Andrei
From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?
Wouldn't it be enough changing the overload auto iota(E)(E end) to auto iota(E)(E end = E.max) ?
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
On 10/12/2015 11:52 PM, Jacques Müller wrote:
On Monday, 12 October 2015 at 20:51:40 UTC, Nordlöw wrote:
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:
Alexandrescu wrote:
We can add iota!T() with no arguments that spans the entire range of T
(integral). -- Andrei
From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?
Wouldn't it be enough changing the overload auto iota(E)(E end) to auto iota(E)(E end = E.max) ?
No. import std.range; writeln(iota(byte.max)); starts at 0 | v [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126] ^ | ends before 127
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
On 10/12/2015 10:51 PM, Nordlöw wrote:
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:
Alexandrescu wrote:
We can add iota!T() with no arguments that spans the entire range of T
(integral). -- Andrei
From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?
auto iota(T)(){ import std.range; return chain(iota(T.min,T.max),only(T.max)); } void main(){ import std.stdio; writeln(iota!byte()); writeln(iota!dchar()); }
Oct 12 2015
On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu
wrote:
On 10/12/15 11:20 AM, Per Nordlöw wrote:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to
ubyte
We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Nice, that'll also be consistent with uniform!T().
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
On 10/12/2015 11:02 PM, Vladimir Panteleev wrote:
On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
On 10/12/15 11:20 AM, Per Nordlöw wrote:
On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to ubyte
We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Nice, that'll also be consistent with uniform!T().
As will iota!"[]".
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
On 10/09/2015 04:41 AM, Timothee Cour via Digitalmars-d wrote:
Could we have a function with iota_inclusive that has inclusive bounds
for 'end' parameter ?
iota!"[]" ?
Oct 12 2015
John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 12 October 2015 at 13:17:32 UTC, Timon Gehr wrote:
On 10/09/2015 04:41 AM, Timothee Cour via Digitalmars-d wrote:
Could we have a function with iota_inclusive that has
inclusive bounds
for 'end' parameter ?
iota!"[]" ?