digitalmars.D.bugs - [Issue 10466] New: Optional "[]" syntax for std.range.iota too
- d-bugmail puremagic.com (26/26) Jun 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (10/10) Jul 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (11/11) Aug 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (21/26) Aug 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (17/17) Aug 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (10/11) Aug 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (21/26) Aug 31 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (10/12) Aug 31 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
- d-bugmail puremagic.com (11/15) Aug 31 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10466
http://d.puremagic.com/issues/show_bug.cgi?id=10466 Summary: Optional "[]" syntax for std.range.iota too Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc There are _many_ situations where you want to iterate on a full range of an integral value using iota, and you want the iteration variable to be of that type. Unfortunately this doesn't iterate on the last value: iota(ubyte.min, ubyte.max) And this doesn't yield ubytes: iota(ubyte.min, ubyte.max + 1) So a simple solution comes copying from std.random.uniform, using the optional "[]" syntax: iota!"[]"(ubyte.min, ubyte.max) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466 Another use case: auto lazy_lower_case = iota!"[]"('a', 'z'); Currently you should use this that is much less handy (and it doesn't work for other reasons): iota('a', '{') -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466 hsteoh quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hsteoh quickfur.ath.cx I like this idea, though there are some corner cases we need to clarify, namely, what should iota!"(]"(0.0, 1.0, 0.3) and iota!"()"(0.0, 1.0, 0.3) do? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466I like this idea, though there are some corner cases we need to clarify, namely, what should iota!"(]"(0.0, 1.0, 0.3) and iota!"()"(0.0, 1.0, 0.3) do?I don't use iota with floating point arguments, it's too much tricky. I prefer to write code that doesn't make my head hurt trying to understand its exact semantics months later. So my first answer is: disallow FP types for iota(). I know this probably will not happen, so let's see. This is what the arange() function of the Python good numpy library gives for those intervals:array([ 0. , 0.3, 0.6, 0.9])from numpy import arange arange(0.0, 1.0, 0.3)array([ 0. , 0.3, 0.6, 0.9]) So I presume your iotas should give: iota!"(]"(0.0, 1.0, 0.3) ==> [0.3; 0.6; 0.9] iota!"()"(0.0, 1.0, 0.3) ==> [0.3; 0.6; 0.9] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------arange(0.0, 1.0, 0.3)
Aug 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466 Hmm, iota with FP gets tricky, because, for example, 0.1 does not have an exact representation in floating-point. So if you write iota(0.0, 1.0, 0.1), it's unclear whether 1.0 will be included or not (for example, you may end up with 0.999999998 and it gets included, or it may end up with 1.0000001 and get excluded). One example given in the python docs (http://docs.python.org/3/tutorial/floatingpoint.html) is that 0.1 + 0.1 + 0.1 != 0.3, because neither 0.1 nor 0.3 have exact representation in FP. So if you write iota(0.1, 0.3, ...) you might get surprised by the results. Which makes iota!"[]" and iota!"()" unreliable when used with FP. :-( supports ++ and -- or +=, but does not have exact semantics. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466Which makes iota!"[]" and iota!"()" unreliable when used with FP. :-(If you want to keep things simpler and you prefer a safer enhancement (that doesn't forbid future enhancements to support FP) and you want to allow the "[]" syntax only for integral types (including in future BigInt), this is OK for me :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466 Joseph Rushton Wakeling <joseph.wakeling webdrake.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.wakeling webdrake.ne | |t 2013-08-31 00:34:59 PDT ---Hmm, iota with FP gets tricky, because, for example, 0.1 does not have an exact representation in floating-point. So if you write iota(0.0, 1.0, 0.1), it's unclear whether 1.0 will be included or not (for example, you may end up with 0.999999998 and it gets included, or it may end up with 1.0000001 and get excluded).Surely that should be a case of, "use with FP at own risk". There are cases where it might be useful, but as with all things, you need to understand the possibility of rounding error. I got bitten rather amusingly by such an example where I was doing a for () loop across [0, 1] in 0.1 increments. GDC and LDC can handle that, DMD couldn't, and I had to switch to increments that were negative powers of 2. If you can trust the user to implement a for () loop correctly, you can trust them to do the same with iota(). Bottom line -- iota() currently does allow FP numbers and excluding them would be a breaking change. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 31 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466Bottom line -- iota() currently does allow FP numbers and excluding them would be a breaking change.I understand the general meaning of your words, and I could agree, but at the moment there is no D code around shaped as "iota!"(]"(0.0, 1.0, 0.3)", so formally there is no breaking. A code breaking change is when code that used to work suddenly stops working or silently has a different semantics. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 31 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10466 2013-08-31 12:37:42 PDT ---I understand the general meaning of your words, and I could agree, but at the moment there is no D code around shaped as "iota!"(]"(0.0, 1.0, 0.3)", so formally there is no breaking. A code breaking change is when code that used to work suddenly stops working or silently has a different semantics.No, but there is D code shaped around iota(0.0, 1.0, 0.3) which is semantically identical to iota!"[)"(0.0, 1.0, 0.3), which is part of the proposal. So, if there is going to be any "choice of boundary conditions" generalization of iota, it should work as a seamless generalization of all the behaviour it currently supports -- which includes both integral and floating-point types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 31 2013