www.digitalmars.com         C & C++   DMDScript  

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

reply 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
next sibling parent reply 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
next sibling parent 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
prev sibling next sibling parent reply 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
parent reply 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
parent reply 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
parent reply 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 
 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
parent 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 
 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.
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 Davis
Oct 12 2015
prev sibling parent reply 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
parent =?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)

 and use `std.conv.to` instead.
Here's a solution: https://github.com/nordlow/justd/blob/a8b733034b049dc2abeabaa37332e503f39e9066/range_ex.d#L434
Oct 12 2015
prev sibling next sibling parent reply 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
What about adding an overload supporting iota!ubyte(0, 256) ?
Oct 12 2015
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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
prev sibling parent reply 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
What about adding an overload supporting iota!ubyte(0, 256)
We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei
Oct 12 2015
next sibling parent reply =?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
next sibling parent reply 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
parent reply 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
parent 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); }
 Just playing devil's advocate.


 Andrei
Oct 12 2015
prev sibling parent reply 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
next sibling parent =?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
prev sibling parent reply =?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
next sibling parent 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
prev sibling next sibling parent reply 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
parent 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
prev sibling parent 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
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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
What about adding an overload supporting iota!ubyte(0, 256)
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
parent 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
What about adding an overload supporting iota!ubyte(0, 256)
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
prev sibling parent reply 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
parent 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!"[]" ?
Yes please.
Oct 13 2015