digitalmars.D.bugs - [Issue 10762] New: std.range.iota should support any type that has ordered comparisons, incrementing, and addition
- d-bugmail puremagic.com (20/20) Aug 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
- d-bugmail puremagic.com (8/8) Aug 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
- d-bugmail puremagic.com (7/7) Aug 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
- d-bugmail puremagic.com (17/17) Aug 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
- d-bugmail puremagic.com (15/15) Aug 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
- d-bugmail puremagic.com (24/24) Aug 05 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
- d-bugmail puremagic.com (14/25) Aug 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10762
http://d.puremagic.com/issues/show_bug.cgi?id=10762 Summary: std.range.iota should support any type that has ordered comparisons, incrementing, and addition Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: hsteoh quickfur.ath.cx For example, iota should work with Date: auto r = iota(Date(2013,1,1), Date(2014,1,1), dur!"days"(1)); Currently, this is not supported. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10762 hsteoh quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10762 Basically, any type that comparable by "<", supports "++" or addition with the increment type, should work with iota. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10762 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdodra gmail.com Related: [Issue 6447] New: iota(BigInt) too http://d.puremagic.com/issues/show_bug.cgi?id=6447 AFAIK, the only difficulty with making this work is that the return type is currently "CommonType!(Beg, End, Step)". Whereas it should be more like something along the lines of: typeof(CommonType!(Beg, End).init += Step.init); But nothing too difficult to integrate anyways. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10762 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc Elsewhere there was a discussion for: iota!"[]"('a', 'z') iota!"[]"(ubyte.min, ubyte.max) Should enums too be supported? enum MyE { A=1, B=15, C=6, D=9, E=22, F=3 } iota(MyE.B, MyE.E) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10762 There are other considerations as well. Let's say we are calling iota(start,end,inc). Let S=typeof(start), E=typeof(end), I=typeof(inc), C=CommonType!(S,E). Then: 1) Ideally, as long as C.init<end is a valid expression, and start+inc is convertible to type C, then iota(start,end,inc) should be supported. 2) Should we optimize iota(start,end,inc) in the case that I supports integer multiplication? That is to say, if n is an integer, and n*inc (or inc*n) is a type that can be added to values of type C, then we could potentially return a random access range wherein opIndex returns start + i*inc as long as the result < end (we can throw a RangeError if result !< end). This might be a nice optimization for things like BigInt in some cases. 3) If start+inc is *not* supported, but start++ is, then should we support iota(start,end)? 4) If start+inc is *not* supported but start-- is, and end < start, should we support iota(start,end)? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 05 2013
http://d.puremagic.com/issues/show_bug.cgi?id=107622) Should we optimize iota(start,end,inc) in the case that I supports integer multiplication? That is to say, if n is an integer, and n*inc (or inc*n) is a type that can be added to values of type C, then we could potentially return a random access range wherein opIndex returns start + i*inc as long as the result < end (we can throw a RangeError if result !< end). This might be a nice optimization for things like BigInt in some cases.I think providing RA is possible, but at the same time, I doubt there is much usecase for it. iota's prime usecase is iteration I mean. If we can make it happen, then great I guess, but I don't really see it as essential.3) If start+inc is *not* supported, but start++ is, then should we support iota(start,end)? 4) If start+inc is *not* supported but start-- is, and end < start, should we support iota(start,end)?I think that for "iota(end)/iota(start, end)", the constraint should be that "++"/"--" works. For "iota(start, end, step)", then the constraint should be "+=". So I to answer your question, I think that "Yes", we should support iota(start, end) as soon as ++/-- is available. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 06 2013