digitalmars.D - how to do iota(0,256) with ubytes ? (cf need for iotaInclusive)
- Timothee Cour via Digitalmars-d (8/8) Oct 08 2015 how to do iota(0,256) with ubytes ?
- John Colvin (6/15) Oct 09 2015 A bounds parameter would be nice, like in std.random.uniform.
- John Colvin (3/20) Oct 09 2015 ugh, didn't see other people had posted the same response, the
- Temtaime (3/20) Oct 11 2015 Do not use string lambdas. It will be deprecated.
- John Colvin (5/30) Oct 11 2015 I'm pretty sure that's not going to happen. Could you point me to
- Jonathan M Davis (10/16) Oct 11 2015 Their use is discouraged at this point, but they're used by so
- Marc =?UTF-8?B?U2Now7x0eg==?= (5/13) Oct 12 2015 Besides, `reduce!"a+b"` and `map!"a*a"` are more concise than the
- Jonathan M Davis (8/21) Oct 12 2015 Yeah. I like them, but if it weren't for the fact that regular
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (9/11) Oct 12 2015 Without string lambdas:
- =?UTF-8?B?Tm9yZGzDtnc=?= (3/9) Oct 12 2015 Here's a solution:
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (4/8) Oct 12 2015 What about adding an overload supporting
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (11/14) Oct 12 2015 Ahh, already present of course, according to declaration
- Andrei Alexandrescu (3/9) Oct 12 2015 We can add iota!T() with no arguments that spans the entire range of T
- =?UTF-8?B?Tm9yZGzDtnc=?= (4/6) Oct 12 2015 Clever, as always, Andrei! ;)
- Timothee Cour via Digitalmars-d (7/13) Oct 12 2015 that's only a partial fix:
- Andrei Alexandrescu (5/9) Oct 12 2015 iota!ubyte.drop(1).stride(3)
- Timothee Cour via Digitalmars-d (9/21) Oct 12 2015 That's not a good workaround; it's error-prone in more general cases:
- Andrei Alexandrescu (2/7) Oct 12 2015 Guess I'd pull it. Flattery will take you anywhere :o). -- Andrei
- =?UTF-8?B?Tm9yZGzDtnc=?= (3/5) Oct 12 2015 Got it.
- =?UTF-8?B?Tm9yZGzDtnc=?= (4/8) Oct 12 2015 From a quick glance I couldn't find a way to reuse the existing
- Andrei Alexandrescu (5/11) Oct 12 2015 One possibility (can't look at the code now) is to change the
- Jacques =?UTF-8?B?TcO8bGxlcg==?= (6/14) Oct 12 2015 Wouldn't it be enough changing the overload
- Timon Gehr (18/31) Oct 12 2015 No.
- Timon Gehr (10/16) Oct 12 2015 auto iota(T)(){
- Vladimir Panteleev (3/15) Oct 12 2015 Nice, that'll also be consistent with uniform!T().
- Timon Gehr (2/16) Oct 12 2015 As will iota!"[]".
- Timon Gehr (2/4) Oct 12 2015 iota!"[]" ?
- John Colvin (2/9) Oct 13 2015 Yes please.
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
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
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:ugh, didn't see other people had posted the same response, the thread got split...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
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:Do not use string lambdas. It will be deprecated. map!(a => cast(uint)a) is correcthow 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 11 2015
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: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".On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:Do not use string lambdas. It will be deprecated.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 11 2015
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: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 DavisDo 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
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 style lambdas instead.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
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: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 - Jonathan M DavisTheir 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.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
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
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) and use `std.conv.to` instead.Here's a solution: https://github.com/nordlow/justd/blob/a8b733034b049dc2abeabaa37332e503f39e9066/range_ex.d#L434
Oct 12 2015
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 ubyteWhat about adding an overload supporting iota!ubyte(0, 256) ?
Oct 12 2015
On Monday, 12 October 2015 at 08:20:12 UTC, Per Nordlöw wrote:What about adding an overload supporting 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
On 10/12/15 11:20 AM, Per Nordlöw wrote:On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andreiof course this doesn't work: auto b=iota(ubyte(0), ubyte(256)); //cannot implicitly convert expression (256) of type int to ubyteWhat about adding an overload supporting iota!ubyte(0, 256)
Oct 12 2015
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). -- AndreiClever, as always, Andrei! ;) Should I do a PR?
Oct 12 2015
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). -- AndreiClever, as always, Andrei! ;) Should I do a PR?
Oct 12 2015
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
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 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); }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
On 10/12/15 10:31 PM, Nordlöw wrote:On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:Guess I'd pull it. Flattery will take you anywhere :o). -- AndreiWe can add iota!T() with no arguments that spans the entire range of T (integral). -- AndreiClever, as always, Andrei! ;) Should I do a PR?
Oct 12 2015
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:Guess I'd pull it. Flattery will take you anywhere :o). -- AndreiGot it.
Oct 12 2015
On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?Alexandrescu wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Oct 12 2015
On 10/12/15 11:51 PM, Nordlöw wrote:On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote: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. -- AndreiFrom a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?Alexandrescu wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Oct 12 2015
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:Wouldn't it be enough changing the overload auto iota(E)(E end) to auto iota(E)(E end = E.max) ?From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?Alexandrescu wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Oct 12 2015
On 10/12/2015 11:52 PM, Jacques Müller wrote:On Monday, 12 October 2015 at 20:51:40 UTC, Nordlöw wrote: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 127On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:Wouldn't it be enough changing the overload auto iota(E)(E end) to auto iota(E)(E end = E.max) ?From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?Alexandrescu wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Oct 12 2015
On 10/12/2015 10:51 PM, Nordlöw wrote:On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote: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()); }From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?Alexandrescu wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
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:Nice, that'll also be consistent with uniform!T().On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andreiof course this doesn't work: auto b=iota(ubyte(0), ubyte(256)); //cannot implicitly convert expression (256) of type int to ubyteWhat about adding an overload supporting iota!ubyte(0, 256)
Oct 12 2015
On 10/12/2015 11:02 PM, Vladimir Panteleev wrote:On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:As will iota!"[]".On 10/12/15 11:20 AM, Per Nordlöw wrote:Nice, that'll also be consistent with uniform!T().On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andreiof course this doesn't work: auto b=iota(ubyte(0), ubyte(256)); //cannot implicitly convert expression (256) of type int to ubyteWhat about adding an overload supporting iota!ubyte(0, 256)
Oct 12 2015
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
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:Yes please.Could we have a function with iota_inclusive that has inclusive bounds for 'end' parameter ?iota!"[]" ?
Oct 13 2015