July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jthr4a$3f3$1@digitalmars.com... > On 7/10/12 2:08 PM, Jonathan M Davis wrote: >>> That does seem good to have. What would be a better name than makeRange? >> >> I see no problem with makeRange. It seems like a sensible name to me. >> You're >> taking a sequence of elements and making a range out of them. > > I swear I'd just call it "range". > > Andrei > tuple(1, 2, 3).rangeOf |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On Tue, Jul 10, 2012 at 3:35 AM, Jacob Carlborg <doob@me.com> wrote:
> On 2012-07-10 08:59, Dmitry Olshansky wrote:
>
> Can you do it in other languages?
>>
>
> Sure, in Ruby, but that only works on arrays:
>
> p [5, 3, 5, 6, 8].uniq.map{ |e| e.to_s }.sort
>
> Prints:
>
> ["3", "5", "6", "8"]
>
> --
> /Jacob Carlborg
>
For what it's worth:
e = 10_000_000
a = ((1..e).to_a + (1..e).to_a).sort.uniq.map{ |e| e }
Runs in 21,320 ms on my machine with Ruby 1.9.3 whereas:
auto end = 10_000_000;
auto a = chain(iota(1, end), iota(1, end)).array()
.sort()
.uniq()
.map!(n=>n).array();
Runs in 3,057ms with DMD 2.059. I believe they are largely equivalent but there is probably room for improvement on both. I removed to_s/to!string because I didn't want it allocation bound since we are talking about algorithm and not the GC or string conversion (with string conversion the numbers are 28,646ms for Ruby and 14,113ms for D).
Regards,
Brad Anderson
|
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Daniel Murphy | On 2012-07-10 19:23, Daniel Murphy wrote: > writeln([1, 2, 3].map!"a"()[2]); > > Sort is in place, and therefore requires more than random access, you need > to be able to modify the data you're operating on. > > Something like [3, 4].map!func().selectionSort() could work lazily without > needing to modify the original range, but urrgh. Ok, I think I get it now. -- /Jacob Carlborg |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2012-07-10 19:55, Andrei Alexandrescu wrote: > Clearly this and any documentation can be improved, but I'd say if it > says "range" there there's no assumption "sorted range" there. I think > the main thing that could be expressed better is "unique consecutive". Fair enough. > > I think it would be onerous to mention for each algorithm, although > clearly they all are generic, that they can handle ranges with any > element type. > >> You see how stupid that is. > > That being what? I was trying to point out that one cannot assume how a function behaves just by looking at one example. Specially not a template function. -- /Jacob Carlborg |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 2012-07-10 19:30, Jonathan M Davis wrote: > typeof(bar()) x; > > works. But regardless, given that you're dealing with a return type which is > auto, there's really no other choice. Even if we weren't using voldemort types > for stuff like map, the return type would still be templated and depend on the > actual arguments to map, making writing the type a pain - especially if it's > complicated; until (which _doesn't_ use a voldemort type) is a prime example > of this. You end up with something like Until!("a == b",int[],int) for a basic > call to until, and it gets really nasty if you start chaining function calls > so that the range passed to Until is far more complicated than int[]. Using > ReturnType and typeof becames the sane thing to do (and much more maintainable > too, since you don't have to change it if/when you change the call to map > enough that it's return type changes). It does take some getting used to, but > it works very well. You just have to realize that if you're operating on > ranges, you're generally _not_ caring what they exact type is, and you use > auto and templates a lot. Sometimes converting the result to an array is > exactly what you want to do, but the less you do that, the more efficient your > code will be. First, both using typeof and ReturnType forces me to have the instance variable below the method due to otherwise forward reference errors. Which I really, really don't like. Second, it would be much easier if it would be possible to better name these ranges, something like interfaces but without polymorphism. This as been mentioned several times before. -- /Jacob Carlborg |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2012-07-10 20:04, Andrei Alexandrescu wrote: > Then store an array. "No one's put a gun to yer head." > http://youtu.be/CB1Pij54gTw?t=2m29s That's what I'm doing. -- /Jacob Carlborg |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Anderson | On 2012-07-10 20:53, Brad Anderson wrote: > For what it's worth: > > e = 10_000_000 > a = ((1..e).to_a + (1..e).to_a).sort.uniq.map{ |e| e } > > Runs in 21,320 ms on my machine with Ruby 1.9.3 whereas: > > auto end = 10_000_000; > auto a = chain(iota(1, end), iota(1, end)).array() > .sort() > .uniq() > .map!(n=>n).array(); > > Runs in 3,057ms with DMD 2.059. I believe they are largely equivalent > but there is probably room for improvement on both. I removed > to_s/to!string because I didn't want it allocation bound since we are > talking about algorithm and not the GC or string conversion (with string > conversion the numbers are 28,646ms for Ruby and 14,113ms for D). > For me, using Ruby 1.9.2 and DMD 2.059, D is only just under 10 seconds faster. -- /Jacob Carlborg |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 10 July 2012 at 00:17:12 UTC, Timon Gehr wrote: > I have heard that rumour, but TDPL wisely specifies the behaviour of > the @property attribute as follows: > > 'In particular "property" is recognized by the the compiler > and signals the fact that the function bearing such an attribute must be called without the trailing ().' > > That is exactly the behaviour I described. > > Note that this sentence includes the notion of _calling a function_ > without the trailing () and it even seems to express that the trailing > () is usually optional. No it doesn't. It does have emphasis with 'must' and this likely comes from D having such a long history of the optional (), but that does not make this statement include such a notion. > So TDPL actually describes a subset of what I have in mind. (it seems > to leave out the function = argument case completely.) We should > therefore change where we are headed. The -property is an implementation of what is to come. I was never greatly for property but since we have it it should be fully enforced, otherwise we may as well just drop it. |
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg Attachments:
| On Tue, Jul 10, 2012 at 1:22 PM, Jacob Carlborg <doob@me.com> wrote:
> On 2012-07-10 20:53, Brad Anderson wrote:
>
> For what it's worth:
>>
>> e = 10_000_000
>> a = ((1..e).to_a + (1..e).to_a).sort.uniq.map{ |e| e }
>>
>> Runs in 21,320 ms on my machine with Ruby 1.9.3 whereas:
>>
>> auto end = 10_000_000;
>> auto a = chain(iota(1, end), iota(1, end)).array()
>> .sort()
>> .uniq()
>> .map!(n=>n).array();
>>
>> Runs in 3,057ms with DMD 2.059. I believe they are largely equivalent but there is probably room for improvement on both. I removed to_s/to!string because I didn't want it allocation bound since we are talking about algorithm and not the GC or string conversion (with string conversion the numbers are 28,646ms for Ruby and 14,113ms for D).
>>
>>
> For me, using Ruby 1.9.2 and DMD 2.059, D is only just under 10 seconds faster.
>
> --
> /Jacob Carlborg
>
>
>
I used -O -inline -noboundscheck -release -d to build.
Regards,
Brad Anderson
|
July 10, 2012 Re: Why is std.algorithm so complicated to use? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | On 07/10/2012 09:36 PM, Jesse Phillips wrote: > On Tuesday, 10 July 2012 at 00:17:12 UTC, Timon Gehr wrote: >> I have heard that rumour, but TDPL wisely specifies the behaviour of >> the @property attribute as follows: >> >> 'In particular "property" is recognized by the the compiler >> and signals the fact that the function bearing such an attribute must >> be called without the trailing ().' >> >> That is exactly the behaviour I described. >> >> Note that this sentence includes the notion of _calling a function_ >> without the trailing () and it even seems to express that the trailing >> () is usually optional. > > No it doesn't. It does have emphasis with 'must' and this likely comes > from D having such a long history of the optional (), but that does not > make this statement include such a notion. > I'm sure a lawyer could make a good case out of it. Anyway, TDPL clearly does not document the broken -property behaviour. >> So TDPL actually describes a subset of what I have in mind. (it seems >> to leave out the function = argument case completely.) We should >> therefore change where we are headed. > > The -property is an implementation of what is to come. I was never > greatly for property but since we have it it should be fully enforced, > otherwise we may as well just drop it. I think you may be misunderstanding what @property is about. Given: @property int delegate() foo(){ ... } @property int bar(){ ... } int baz(){ ... } foo(); // calls the delegate. bar(); // illegal baz; // ok, call baz dmd -property gets every single one of these wrong. -property does _not_ enforce @property semantics. It only adds a silly rule that was never part of the @property design. I am astonished that it made it into the compiler. |
Copyright © 1999-2021 by the D Language Foundation