Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
May 22, 2012 why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
An interesting post and case for using D in bioinformatics by Pjotr Prins http://blog.thebird.nl/?p=93 |
May 22, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to george | On Tuesday, 22 May 2012 at 16:01:25 UTC, george wrote:
> An interesting post and case for using D in bioinformatics by
> Pjotr Prins
> http://blog.thebird.nl/?p=93
This article is a strong advertisement for D. I agree D will be good for bioinformatics.
Bye,
bearophile
|
May 22, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | Le 22/05/2012 19:40, bearophile a écrit :
> On Tuesday, 22 May 2012 at 16:01:25 UTC, george wrote:
>> An interesting post and case for using D in bioinformatics by
>> Pjotr Prins
>> http://blog.thebird.nl/?p=93
>
> This article is a strong advertisement for D. I agree D will be good for
> bioinformatics.
>
> Bye,
> bearophile
I spreaded the word. This article is great and I 100% agree with it :D
|
May 22, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | deadalnix: >>> http://blog.thebird.nl/?p=93 >>... > I spreaded the word. This article is great and I 100% agree with it :D The article says: >There are a few things I miss in D. For example pattern recognition on unpacking data, which is great in Haskell, Erlang, and Scala (see example [http://www.scala-lang.org/node/120 ]).< The author of that article has missed that D lacks something much simpler than pattern matching, and even more commonly useful. Currently in D you have to write something like: int[2][] directions = [[-1, 0], [1, 0], [0, -1], [0, 1]]; foreach (sx_sy; directions) { immutable sx = sx_sy[0]; immutable sy = sx_sy[1]; // code that uses sx and sy While a less clunky language allows you to unpack them better, something like: auto directions = [tuple(-1, 0), tuple(1, 0), tuple(0, -1), tuple(0, 1)]; foreach (immutable (sx, sy); directions) { // code that uses sx and sy If you use tuples, you want to unpack them often, it's a basic operation on tuples. Bye, bearophile |
May 22, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 5/22/12 12:40 PM, bearophile wrote: > On Tuesday, 22 May 2012 at 16:01:25 UTC, george wrote: >> An interesting post and case for using D in bioinformatics by >> Pjotr Prins >> http://blog.thebird.nl/?p=93 > > This article is a strong advertisement for D. I agree D will be good for > bioinformatics. On reddit: http://www.reddit.com/r/programming/comments/tzpdh/d_is_a_dragon_or_why_d_matters_for_bioinformatics/ Andrei |
May 23, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | "bearophile" , dans le message (digitalmars.D:168160), a écrit : > deadalnix: >>>> http://blog.thebird.nl/?p=93 >>>... >> I spreaded the word. This article is great and I 100% agree with it :D > > The article says: > >>There are a few things I miss in D. For example pattern recognition on unpacking data, which is great in Haskell, Erlang, and Scala (see example [http://www.scala-lang.org/node/120 ]).< > > The author of that article has missed that D lacks something much simpler than pattern matching, and even more commonly useful. Currently in D you have to write something like: > > int[2][] directions = [[-1, 0], [1, 0], [0, -1], [0, 1]]; > foreach (sx_sy; directions) { > immutable sx = sx_sy[0]; > immutable sy = sx_sy[1]; > // code that uses sx and sy > > > While a less clunky language allows you to unpack them better, something like: > > auto directions = [tuple(-1, 0), tuple(1, 0), tuple(0, -1), > tuple(0, 1)]; > foreach (immutable (sx, sy); directions) { > // code that uses sx and sy > > > If you use tuples, you want to unpack them often, it's a basic operation on tuples. This little example raises a question if tuples becomes part of the langage. Should static array have tuple capabilities ? Besides that, it is easy to emulate your example with a little library solution. Maybe something like that should be added to std.range. -- Christophe |
May 23, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to Christophe Travert | Christophe Travert: > This little example raises a question if tuples becomes part of the langage. Should static array have tuple capabilities ? Why not? Fixed-sized arrays are similar to tuples with uniform types. Unpacking short arrays in the same way you unpack tuples *very handy* and it's commonly done in both Python and Haskell (and probably in other languages too): In Python: >>> t = (10, 20) >>> a, b = t >>> a 10 >>> b 20 >>> l = [3, 5] >>> x, y = l >>> x 3 >>> y 5 In Haskell: Prelude> let t = (10, 20) Prelude> let (a, b) = t Prelude> a 10 Prelude> b 20 Prelude> let l = [3, 5] Prelude> let [x, y] = l Prelude> x 3 Prelude> y 5 > Besides that, it is easy to emulate your example with a little > library solution. Maybe something like that should be added to > std.range. What syntax do you suggest? (Generally tuple unpacking/small array unpacking is a so commonly done operation that it needs a clean and very nice syntax, so you often want it as built-in feature). Bye, bearophile |
May 23, 2012 Re: why D matters for Bioinformatics | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 23.05.2012 14:10, bearophile wrote: > Why not? Fixed-sized arrays are similar to tuples with uniform types. > Unpacking short arrays in the same way you unpack tuples *very handy* > and it's commonly done in both Python and Haskell (and probably in other > languages too): > I'd rather see common structure/static array expansion. Then returning struct will be as powerful as multiple value return. The latter can be added sometime later, since tuple is just a plain struct. I expect some form of pattern matching a-la Ecma Script 6 (yeah, I know but idea itself is good). My proposal the is following using a.{ ... } syntax to unpack: Record r = ...; auto a, b, c = r.{ first, third, some_other_field };//a=r.first, b=r.third, c = r.some_other_field With tuples: auto a, b, c = r.{};//a = r[0], b = r[1], c = r[2] auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4] With arrays, exactly the same as tuples: auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4] Tuples with named fields can work in both named and indexed "modes". Indexes must be a valid CT-constant. More over we then have nested unpacking syntax: auto x, i = r.{ something, nested_thing.{ precious_secret} }; //x = r.something, i = r.nested_thing.precious_secret The same with just about any expression: auto point = (a+b()).{ x, y }; //even better - point is now Tuple!(<type of x>, "x", <type of y>, "y") Summarizing it all. For single left-side variable the rewrite of expression is: auto __tmp = <expr>, tuple(__tmp.<spec_1>, __tmp.<spec_2>); For multiple left-side the rewrite of the whole statement is: auto __tmp = <expr>, __1st = __tmp.<spec_1>, __2nd = __tmp.<spec_2> ...; Where spec_x is constructed from: root_0.{ ... root_1.{ .. root_n.{ var_x ... } ... } ... } as root_0.<...>.root_n.var_x If some var_k/root_k happens to be CT index the rewrite is ...[root_k]... or ...[var_k].. So far I think it's the closest thing to multiple value return with natural syntax. It also brings concise syntax for a common general propose task. -- Dmitry Olshansky |
May 23, 2012 Towards better integration of struct/tuple/array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | > My proposal the is following using a.{ ... } syntax to unpack: In short: I think the original proposal of https://github.com/D-Programming-Language/dmd/pull/341 could be enhanced with introduction <expr>.{ <spec> } selectors allowing to cherry pick fields and array elements easily. If we go with Kenji's proposal, this can be treated as cool way to construct tuple by applying selector to an expression. > > Record r = ...; > auto a, b, c = r.{ first, third, some_other_field };//a=r.first, > b=r.third, c = r.some_other_field > > With tuples: > auto a, b, c = r.{};//a = r[0], b = r[1], c = r[2] > auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4] > > With arrays, exactly the same as tuples: > auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4] > > Tuples with named fields can work in both named and indexed "modes". > Indexes must be a valid CT-constant. > > More over we then have nested unpacking syntax: > > auto x, i = r.{ something, nested_thing.{ precious_secret} }; > //x = r.something, i = r.nested_thing.precious_secret > > The same with just about any expression: > > auto point = (a+b()).{ x, y }; > //even better - point is now Tuple!(<type of x>, "x", <type of y>, "y") > > > Summarizing it all. > > For single left-side variable the rewrite of expression is: > auto __tmp = <expr>, tuple(__tmp.<spec_1>, __tmp.<spec_2>); > > For multiple left-side the rewrite of the whole statement is: > auto __tmp = <expr>, __1st = __tmp.<spec_1>, __2nd = __tmp.<spec_2> ...; > > > Where spec_x is constructed from: > > root_0.{ ... root_1.{ .. root_n.{ var_x ... } ... } ... } > > as > root_0.<...>.root_n.var_x > > If some var_k/root_k happens to be CT index the rewrite is > ...[root_k]... or ...[var_k].. > > > So far I think it's the closest thing to multiple value return with > natural syntax. It also brings concise syntax for a common general > propose task. > -- Dmitry Olshansky |
May 23, 2012 Re: Towards better integration of struct/tuple/array | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky Attachments:
| On Wed, May 23, 2012 at 3:00 PM, Dmitry Olshansky <dmitry.olsh@gmail.com>wrote: > My proposal the is following using a.{ ... } syntax to unpack: >> > > In short: > I think the original proposal of > https://github.com/D-**Programming-Language/dmd/pull/**341<https://github.com/D-Programming-Language/dmd/pull/341> > could be enhanced with introduction <expr>.{ <spec> } selectors allowing > to cherry pick fields and array elements easily. > > If we go with Kenji's proposal, this can be treated as cool way to construct tuple by applying selector to an expression. > > >> Record r = ...; >> auto a, b, c = r.{ first, third, some_other_field };//a=r.first, >> b=r.third, c = r.some_other_field >> >> With tuples: >> auto a, b, c = r.{};//a = r[0], b = r[1], c = r[2] >> auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4] >> >> With arrays, exactly the same as tuples: >> auto a, b, c = r.{0, 2, 4}; // a = r[0], b = r[2], c = r[4] >> >> Tuples with named fields can work in both named and indexed "modes". Indexes must be a valid CT-constant. >> >> More over we then have nested unpacking syntax: >> >> auto x, i = r.{ something, nested_thing.{ precious_secret} }; //x = r.something, i = r.nested_thing.precious_secret >> >> The same with just about any expression: >> >> auto point = (a+b()).{ x, y }; >> //even better - point is now Tuple!(<type of x>, "x", <type of y>, "y") >> >> >> Summarizing it all. >> >> For single left-side variable the rewrite of expression is: auto __tmp = <expr>, tuple(__tmp.<spec_1>, __tmp.<spec_2>); >> >> For multiple left-side the rewrite of the whole statement is: >> auto __tmp = <expr>, __1st = __tmp.<spec_1>, __2nd = __tmp.<spec_2> ...; >> >> >> Where spec_x is constructed from: >> >> root_0.{ ... root_1.{ .. root_n.{ var_x ... } ... } ... } >> >> as >> root_0.<...>.root_n.var_x >> >> If some var_k/root_k happens to be CT index the rewrite is ...[root_k]... or ...[var_k].. >> >> >> So far I think it's the closest thing to multiple value return with natural syntax. It also brings concise syntax for a common general propose task. >> >> > > > > -- > Dmitry Olshansky > This is awesome! I really like it! -- Bye, Gor Gyolchanyan. |
Copyright © 1999-2021 by the D Language Foundation