I posted some sum-up on my github.
https://preview.tinyurl.com/y6sprdbq
further: Templates work by pattern matching.
When you say
quickSort(T)(T[] r)
You are saying, match the parameter T[] to what is passed, and if it's a
match, set T to the part of the parameter that matches. Therefore:
int[] => T = int
ubyte[] => T = ubyte
But if you leave off the arr
Thanks you very much Ali,
I will try to wrap my head around your inputs, and get a better
understanding of ranges in the process. I feel there is a lot of
power in D ranges, and like the hammer of Thor, I am not worthy
yet :)
On 9/12/20 11:25 AM, jerome wrote:
>
> import std.stdio : writeln;
> import std.algorithm.sorting;
>
> pure void quickSort(T) (T[] r)
> {
>if (r.length > 1)
>{
> size_t p = pivotPartition(r, r.length-1)
Hi fellow coders, I spent a couple of hours to implement a
working, basic, quicksort. Practicing D. It finally boils down to
that (intent to use the std, not to rewrite swap, etc):
import std.stdio : writeln;
import std.algorithm.sorting;
pure void quickSort(T
On Tuesday, 8 July 2014 at 20:50:01 UTC, Nordlöw wrote:
Also related:
http://forum.dlang.org/thread/eaxcfzlvsakeucwpx...@forum.dlang.org#post-mailman.2809.1355844427.5162.digitalmars-d:40puremagic.com
On Tuesday, 8 July 2014 at 20:50:01 UTC, Nordlöw wrote:
I recall that Python's default sorting algorithm is related to
this, right?
https://en.wikipedia.org/wiki/Timsort
After having read
http://togototo.wordpress.com/2014/06/20/the-magic-forest-problem-revisited-rehabilitating-java-with-the-aid-of-d/
I stared at
forest_t[] quickSort(forest_t[] fors) pure nothrow {
if (fors.length >= 2) {
auto parts = partition3!(forLessThan)(fors, fors[$
On Fri, Feb 14, 2014 at 3:24 PM, bearophile wrote:
> Meta:
>
>
>> While it is heavier than Haskell's syntax, I have been consistently and
>> pleasantly surprised by how powerful D's template pattern matching is (bugs
>> notwithstanding). I wonder how well-known this is outside this mailing
>> list
Meta:
While it is heavier than Haskell's syntax, I have been
consistently and pleasantly surprised by how powerful D's
template pattern matching is (bugs notwithstanding). I wonder
how well-known this is outside this mailing list...
I keep reading blog posts that use Haskell and present supp
On Friday, 14 February 2014 at 06:05:08 UTC, Philippe Sigaud
wrote:
`alias` is just a bit of syntax sugar, it does not (at least for
2.064) have the same power than fully defining a template and
the `is(...)` expression.
Right. What I was saying, however, is it is strange to me that
this code
Philippe Sigaud:
So yes, D does not have Haskell nice syntax for pattern
matching.
I'd like some of such syntax for templates (and a little
different syntax added to match structs inside switch statements:
https://d.puremagic.com/issues/show_bug.cgi?id=596 ).
Bye,
bearophile
On Fri, Feb 14, 2014 at 3:54 AM, Meta wrote:
> It seems strange that it would choke now, as Cons is a struct. Therefore,
> Cons!(Three, ...) should create a new type, and `L: Cons!(a, b), a, b`
> shouldn't be any trouble to destructure into two types, `Three` and
> `Cons!(Two, ...)`. It had no pr
On Friday, 14 February 2014 at 02:41:12 UTC, bearophile wrote:
Meta:
alias list1 = Cons!(Three, Cons!(Two, Cons!(Four, Cons!(One,
Nil;
alias numlHead(L: Cons!(a, b), a, b) = a;
alias numlTail(L: Cons!(a, b), a, b) = b;
But the compiler is complaining loudly about a mismatch:
/d43/f234
Meta:
alias list1 = Cons!(Three, Cons!(Two, Cons!(Four, Cons!(One,
Nil;
alias numlHead(L: Cons!(a, b), a, b) = a;
alias numlTail(L: Cons!(a, b), a, b) = b;
But the compiler is complaining loudly about a mismatch:
/d43/f234.d(39): Error: template instance numlHead!(list1) does
not matc
Coming back to this after a few days. I got a bit farther, but
I'm running into trouble with the template args pattern matching.
I'd like to turn this code:
list1 :: Cons Three (Cons Two (Cons Four (Cons One Nil)))
list1 = undefined
numlHead :: Cons a b -> a
numlHead = const undefined
nu
alias One = Typedef!(Succ!Zero);
alias Two = Typedef!(Succ!One);
alias Three = Typedef!(Succ!Two);
alias Four = Typedef!(Succ!Three);
Note that you need a "cookie" for those Typedefs, otherwise
they are not useful.
They are different types, so my comment is wrong :-) I don't
understand why y
On Tuesday, 11 February 2014 at 19:13:01 UTC, Philippe Sigaud
wrote:
On Mon, Feb 10, 2014 at 6:12 PM, Meta
wrote:
I'm trying to write a D implementation of Haskell's "type level
quicksort"[0], but I'm already running into problems with
std.typecons.Typedef. I hav
On Mon, Feb 10, 2014 at 6:12 PM, Meta wrote:
> I'm trying to write a D implementation of Haskell's "type level
> quicksort"[0], but I'm already running into problems with
> std.typecons.Typedef. I have tried to translate this Haskell code:
> alias One = Typed
Note that you need a "cookie" for those Typedefs, otherwise
they are not useful. Unless this gets implemented:
http://d.puremagic.com/issues/show_bug.cgi?id=12100
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=11828
Bye,
bearophile
Meta:
alias One = Typedef!(Succ!Zero);
alias Two = Typedef!(Succ!One);
alias Three = Typedef!(Succ!Two);
alias Four = Typedef!(Succ!Three);
Note that you need a "cookie" for those Typedefs, otherwise they
are not useful. Unless this gets implemented:
http://d.puremagic.com/issues/show_bug.cg
On Monday, 10 February 2014 at 17:12:11 UTC, Meta wrote:
I tried defining a static opCall in the Zero struct that
doesn't take any arguments, but that didn't make a difference.
I'm guessing this is a bug with Typedef, but does anyone have
an idea of where that bug might be?
I would say it's
I'm trying to write a D implementation of Haskell's "type level
quicksort"[0], but I'm already running into problems with
std.typecons.Typedef. I have tried to translate this Haskell code:
data Zero
data Succ a
-- booleans
data True
data False
-- lists
On Wednesday, September 14, 2011 14:36 bearophile wrote:
> Jonathan M Davis:
> > So, basically, you just want to shorten your code by wrapping array(func)
> > in a afunc function, and you think that this happens enough with map and
> > filter enough to merit putting these functions into Phobos.
>
Jonathan M Davis:
> So, basically, you just want to shorten your code by wrapping array(func) in
> a
> afunc function, and you think that this happens enough with map and filter
> enough to merit putting these functions into Phobos.
There is also the point 3) that you have not seen, plus the n
On Wednesday, September 14, 2011 07:46:37 bearophile wrote:
> Jonathan M Davis:
> > What would that gain you over passing the result of map or filter to
> > std.array.array?
>
> 1) The code gets shorter
> 2) The code gets a bit less noisy, because () add noise.
> 3) You use a single function inste
Jonathan M Davis:
> What would that gain you over passing the result of map or filter to
> std.array.array?
1) The code gets shorter
2) The code gets a bit less noisy, because () add noise.
3) You use a single function instead of two, so you reduce the number of chunks
your brain has to manage.
On Wednesday, September 14, 2011 06:09:52 bearophile wrote:
> %u:
> > i have qustion why filter can't return int[]
>
> Because a lazy filter is handy, you often don't need a real array result, a
> lazy sequence is enough. A lazy sequence avoids the memory allocation of
> the output array. In D pro
%u:
> i have qustion why filter can't return int[]
Because a lazy filter is handy, you often don't need a real array result, a
lazy sequence is enough. A lazy sequence avoids the memory allocation of the
output array. In D programs often the slowest parts are the memory allocations.
On the othe
On Wednesday, September 14, 2011 05:43:37 %u wrote:
> i have qustion why filter can't return int[]
> and if lambda return the last Expression without return keyword it would
> much cleaner
filter can't return int[]. filter does not alter the original array. It returns
a new range with only the e
i have qustion why filter can't return int[]
and if lambda return the last Expression without return keyword it would much
cleaner
On 09/14/2011 04:12 AM, Timon Gehr wrote:
On 09/14/2011 03:34 AM, hdsh wrote:
this my try
int[] quickSort(int[] arr) {
int[] result = quickSort(filter!(arr< arr[0])(arr)) ~ arr[0] ~
quickSort(filter!(arr> arr[0])(arr));
}
but it fail to compile
Note that this approach is an inefficie
On 09/14/2011 03:34 AM, hdsh wrote:
this my try
int[] quickSort(int[] arr) {
int[] result = quickSort(filter!(arr< arr[0])(arr)) ~ arr[0] ~
quickSort(filter!(arr> arr[0])(arr));
}
but it fail to compile
Note that this approach is an inefficient way of implementing a sorting
r
On Wednesday, September 14, 2011 01:34:34 hdsh wrote:
> this my try
>
> int[] quickSort(int[] arr) {
> int[] result = quickSort(filter!(arr < arr[0])(arr)) ~ arr[0] ~
> quickSort(filter!(arr > arr[0])(arr));
> }
>
> but it fail to compile
filter does not ret
this my try
int[] quickSort(int[] arr) {
int[] result = quickSort(filter!(arr < arr[0])(arr)) ~ arr[0] ~
quickSort(filter!(arr > arr[0])(arr));
}
but it fail to compile
35 matches
Mail list logo