www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10466] New: Optional "[]" syntax for std.range.iota too

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10466






 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?


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:


 from numpy import arange
 arange(0.0, 1.0, 0.3)






array([ 0. ,  0.3,  0.6,  0.9])

 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: -------
Aug 25 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10466







 Which 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10466







 Bottom 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
prev sibling parent d-bugmail puremagic.com writes:
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