www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Look and think good things about D

reply "bearophile" <bearophileHUGS lycos.com> writes:
I have created two interesting D entries for this Rosettacode 
Task, is someone willing to create a Reddit entry for this? They 
show very different kinds of code in D.

http://rosettacode.org/wiki/Look-and-say_sequence#D

Bye,
bearophile
Nov 14 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:

 I have created two interesting D entries for this Rosettacode 
 Task, is someone willing to create a Reddit entry for this? 
 They show very different kinds of code in D.

 http://rosettacode.org/wiki/Look-and-say_sequence#D

 Bye,
 bearophile



 Using the LDC2 compiler with n=70 the run-time is about 3.74 
 seconds.




Timings for short functional version vs fast would be nice.

--rt
Nov 14 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:


 Timings for short functional version vs fast would be nice.


OK. On the other hand regarding speed the fast version is in 
another world. So the speed comparison will become a little silly.

--------------

Martin Nowak:


 len.uninitializedArray ? Isn't this too much UFCS?


I think it's just enough of UFCS.

Bye,
bearophile
Nov 14 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 OK. On the other hand regarding speed the fast version is in 
 another world. So the speed comparison will become a little 
 silly.


The first program doesn't even compile with ldc2 v.2.063.2, and 
the two programs are quite different in scope...

Bye,
bearophile
Nov 14 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 15 November 2013 at 01:59:27 UTC, bearophile wrote:

 The first program doesn't even compile with ldc2 v.2.063.2, and


Does it compile with dmd 2.063.2? (Is it a D version problem or a 
LDC bug?)

Regards,
Kai
Nov 15 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 Does it compile with dmd 2.063.2? (Is it a D version problem or 
 a LDC bug?)

 Regards,
 Kai


If I find a ldc2 bug I show it in the right newsgroup, so don't 
worry. It's a matter of updates (purity) in a Phobos function.

Bye,
bearophile
Nov 15 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:


 Timings for short functional version vs fast would be nice.


Below the two I have added a note to compare the run-times.

Bye,
bearophile
Nov 14 2013
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 11/15/2013 02:09 AM, bearophile wrote:

 I have created two interesting D entries for this Rosettacode Task


len.uninitializedArray ? Isn't this too much UFCS?
Nov 14 2013
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:

 I have created two interesting D entries for this Rosettacode 
 Task, is someone willing to create a Reddit entry for this? 
 They show very different kinds of code in D.

 http://rosettacode.org/wiki/Look-and-say_sequence#D

 Bye,
 bearophile


I didn't look that closely at the imperative code, but it seems 
to be quite a bit longer than most of the other imperative 
examples. Is this because it's super-optimized?
Nov 14 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Meta:


 I didn't look that closely at the imperative code, but it seems 
 to be quite a bit longer than most of the other imperative 
 examples. Is this because it's super-optimized?


Yes, it's longer because it's optimized.

Bye,
bearophile
Nov 14 2013
prev sibling next sibling parent reply "qznc" <qznc web.de> writes:
On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:

 I have created two interesting D entries for this Rosettacode 
 Task, is someone willing to create a Reddit entry for this? 
 They show very different kinds of code in D.

 http://rosettacode.org/wiki/Look-and-say_sequence#D


The fast version is nearly functional, too. Since memory 
management is not considered a side effect there is only the 
printfs. If the printfs are wrapped into "debug", the function is 
pure.
Nov 14 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
qznc:


 http://rosettacode.org/wiki/Look-and-say_sequence#D


 The fast version is nearly functional, too. Since memory 
 management is not considered a side effect there is only the 
 printfs. If the printfs are wrapped into "debug", the function 
 is pure.


In a system that allows you a more fine-graded management of 
effects through an algebra, memory allocation is an effect. It's 
easy to show D functions annotated with "pure" that aren't pure 
at all because of memory allocation.

Bye,
bearophile
Nov 15 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 02:09, bearophile wrote:

 I have created two interesting D entries for this Rosettacode Task, is
 someone willing to create a Reddit entry for this? They show very
 different kinds of code in D.

 http://rosettacode.org/wiki/Look-and-say_sequence#D


What does this show, that ranges is slow in D?

-- 
/Jacob Carlborg
Nov 14 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jacob Carlborg:


 What does this show, that ranges is slow in D?


It shows that D is awesome. Do you know other languages that 
allow you to write two programs to solve that problem as 
short/simple and as fast as those two? :-)

Bye,
bearophile
Nov 15 2013
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/15/13 7:54 AM, bearophile wrote:

 Jacob Carlborg:


 What does this show, that ranges is slow in D?


 It shows that D is awesome. Do you know other languages that allow you
 to write two programs to solve that problem as short/simple and as fast
 as those two? :-)

 Bye,
 bearophile


Probably Crystal.

Here's what I was able to do in some minutes:

---
if ARGV.length != 1
   puts "missing argument: n"
   exit 1
end

n = ARGV[0].to_i
str = "1"
buffer = String::Buffer.new(20)
n.times do
   puts str.length
   str.each_chunk do |digit, count|
     buffer << '0' + count
     buffer << digit
   end
   str = buffer.to_s
   buffer.clear
end
---

With n=70 it takes about 4.89s. With n=45 it takes about 0.012s.

And with Crystal you could do the second version as well, because you 
have access to low level stuff like pointers. And also, the language is 
pretty new so there's still a lot of optimizations to be done.

I also thought ranges were pretty fast because of their nature. Why are 
they slow in this example?
Nov 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 Here's what I was able to do in some minutes:

 ---
 if ARGV.length != 1
   puts "missing argument: n"
   exit 1
 end

 n = ARGV[0].to_i
 str = "1"
 buffer = String::Buffer.new(20)
 n.times do
   puts str.length
   str.each_chunk do |digit, count|
     buffer << '0' + count
     buffer << digit
   end
   str = buffer.to_s
   buffer.clear
 end

 With n=70 it takes about 4.89s. With n=45 it takes about 0.012s.


This program is much longer in number of tokens to the first D 
program. You can write a D program about as fast as this in about 
the same number of tokens.

Perhaps I should add an intermediate third version that shows 
code that's not as extreme as the two versions there. Thank you 
for the implicit suggestion.



 And with Crystal you could do the second version as well, 
 because you have access to low level stuff like pointers.


In Crystal do you have final switches, gotos, etc too?



 And also, the language is pretty new so there's still
 a lot of optimizations to be done.


And LDC2 will improve in the meantime.



 I also thought ranges were pretty fast because of their nature.


It also matters a lot how you use them, this is normal in 
computer programming.



 Why are they slow in this example?


Just because the first example is not written for speed, I didn't 
even add run-time timings for it at first. And it's not that slow.

Bye,
bearophile
Nov 15 2013
next sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 15 November 2013 at 12:47:21 UTC, bearophile wrote:

 Ary Borenszweig:


 Here's what I was able to do in some minutes:

 ---
 if ARGV.length != 1
  puts "missing argument: n"
  exit 1
 end

 n = ARGV[0].to_i
 str = "1"
 buffer = String::Buffer.new(20)
 n.times do
  puts str.length
  str.each_chunk do |digit, count|
    buffer << '0' + count
    buffer << digit
  end
  str = buffer.to_s
  buffer.clear
 end

 With n=70 it takes about 4.89s. With n=45 it takes about 
 0.012s.


 This program is much longer in number of tokens to the first D 
 program. You can write a D program about as fast as this in 
 about the same number of tokens.

 Perhaps I should add an intermediate third version that shows 
 code that's not as extreme as the two versions there. Thank you 
 for the implicit suggestion.



 And with Crystal you could do the second version as well, 
 because you have access to low level stuff like pointers.


 In Crystal do you have final switches, gotos, etc too?



 And also, the language is pretty new so there's still
 a lot of optimizations to be done.


 And LDC2 will improve in the meantime.



 I also thought ranges were pretty fast because of their nature.


 It also matters a lot how you use them, this is normal in 
 computer programming.



 Why are they slow in this example?


 Just because the first example is not written for speed, I 
 didn't even add run-time timings for it at first. And it's not 
 that slow.

 Bye,
 bearophile


Slightly OT: Why do languages like Ruby (and now Crystal) have to 
state the obvious in an awkward way?

(2...max).each do

Of course you _do_ _each one_ from 2 to max. Is it to make it 
more "human"? If anything, human languages and thinking get rid 
of the superfluous (i.e. the obvious). Just like

x = x + 1 (Pythronizing)
x++; (obvious, concise, all you need).

Buy one, get one free.

(= If you buy one (of these), you will get one (another one of 
these) for free.)

Sorry that was just a rant-om comment :)
Nov 15 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-15 14:07, Chris wrote:


 Slightly OT: Why do languages like Ruby (and now Crystal) have to state
 the obvious in an awkward way?

 (2...max).each do


You can do this as well in Ruby:

for e in 2 ... max
end

But Ruby follows the philosophy that everything is an object. So you 
invoke the "each" method on the range object.


 Of course you _do_ _each one_ from 2 to max. Is it to make it more
 "human"? If anything, human languages and thinking get rid of the
 superfluous (i.e. the obvious). Just like

 x = x + 1 (Pythronizing)
 x++; (obvious, concise, all you need).


This middle ground is possible in Ruby:

x += 1

-- 
/Jacob Carlborg
Nov 15 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/15/13 10:07 AM, Chris wrote:

 On Friday, 15 November 2013 at 12:47:21 UTC, bearophile wrote:

 Ary Borenszweig:


 Here's what I was able to do in some minutes:

 ---
 if ARGV.length != 1
  puts "missing argument: n"
  exit 1
 end

 n = ARGV[0].to_i
 str = "1"
 buffer = String::Buffer.new(20)
 n.times do
  puts str.length
  str.each_chunk do |digit, count|
    buffer << '0' + count
    buffer << digit
  end
  str = buffer.to_s
  buffer.clear
 end

 With n=70 it takes about 4.89s. With n=45 it takes about 0.012s.


 This program is much longer in number of tokens to the first D
 program. You can write a D program about as fast as this in about the
 same number of tokens.

 Perhaps I should add an intermediate third version that shows code
 that's not as extreme as the two versions there. Thank you for the
 implicit suggestion.



 And with Crystal you could do the second version as well, because you
 have access to low level stuff like pointers.


 In Crystal do you have final switches, gotos, etc too?



 And also, the language is pretty new so there's still
 a lot of optimizations to be done.


 And LDC2 will improve in the meantime.



 I also thought ranges were pretty fast because of their nature.


 It also matters a lot how you use them, this is normal in computer
 programming.



 Why are they slow in this example?


 Just because the first example is not written for speed, I didn't even
 add run-time timings for it at first. And it's not that slow.

 Bye,
 bearophile


 Slightly OT: Why do languages like Ruby (and now Crystal) have to state
 the obvious in an awkward way?

 (2...max).each do

 Of course you _do_ _each one_ from 2 to max. Is it to make it more
 "human"?


Absolutely. You are a human and you spend a lot of time reading code. 
The more human the code looks to you, the better, I think, as long as it 
doesn't become too long or too annoying to read, like:

for every number between 2 and max do
   ...
end

:-P
Nov 15 2013
parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 15 November 2013 at 13:13:51 UTC, Ary Borenszweig 
wrote:

 On 11/15/13 10:07 AM, Chris wrote:

 On Friday, 15 November 2013 at 12:47:21 UTC, bearophile wrote:

 Ary Borenszweig:


 Here's what I was able to do in some minutes:

 ---
 if ARGV.length != 1
 puts "missing argument: n"
 exit 1
 end

 n = ARGV[0].to_i
 str = "1"
 buffer = String::Buffer.new(20)
 n.times do
 puts str.length
 str.each_chunk do |digit, count|
   buffer << '0' + count
   buffer << digit
 end
 str = buffer.to_s
 buffer.clear
 end

 With n=70 it takes about 4.89s. With n=45 it takes about 
 0.012s.


 This program is much longer in number of tokens to the first D
 program. You can write a D program about as fast as this in 
 about the
 same number of tokens.

 Perhaps I should add an intermediate third version that shows 
 code
 that's not as extreme as the two versions there. Thank you 
 for the
 implicit suggestion.



 And with Crystal you could do the second version as well, 
 because you
 have access to low level stuff like pointers.


 In Crystal do you have final switches, gotos, etc too?



 And also, the language is pretty new so there's still
 a lot of optimizations to be done.


 And LDC2 will improve in the meantime.



 I also thought ranges were pretty fast because of their 
 nature.


 It also matters a lot how you use them, this is normal in 
 computer
 programming.



 Why are they slow in this example?


 Just because the first example is not written for speed, I 
 didn't even
 add run-time timings for it at first. And it's not that slow.

 Bye,
 bearophile


 Slightly OT: Why do languages like Ruby (and now Crystal) have 
 to state
 the obvious in an awkward way?

 (2...max).each do

 Of course you _do_ _each one_ from 2 to max. Is it to make it 
 more
 "human"?


 Absolutely. You are a human and you spend a lot of time reading 
 code. The more human the code looks to you, the better, I 
 think, as long as it doesn't become too long or too annoying to 
 read, like:

 for every number between 2 and max do
   ...
 end

 :-P


Well, that was exactly my point. As a human being you don't need 
the patronizing (and highly annoying) "for every number ...". 
This is what you say when you explain it to a newbie. But there 
is no need to spell this out in the syntax. Syntax of programming 
languages is (or should be) like road signs, or any other signs. 
Concise and expressive. Else, what's the point? I know that 
languages like Lua have the philosophy that non-programmers 
should be able to use it. But every human being is capable of 
abstracting things. There is no need for this terrible syntax

(2..max).each do:

end

It doesn't add anything to the code except for useless 
characters. Humans have used signs and acronyms for ages. We can 
cope with it. I once saw the most beautiful encrypted message in 
Arabic, which when read properly unfolds into an array of 
characters and meaning. We humans can deal with it. I still don't 
see why x++; is a problem and has to be spelled out as x = x + 1, 
or even x += 1 (slightly better).

If Ruby programmers had invented spelling, you would "Double U Ar 
I Tee ee" like this. Ha ha ha! :-)
Nov 15 2013
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/15/13 11:39 AM, Chris wrote:

 Well, that was exactly my point. As a human being you don't need the
 patronizing (and highly annoying) "for every number ...". This is what
 you say when you explain it to a newbie. But there is no need to spell
 this out in the syntax. Syntax of programming languages is (or should
 be) like road signs, or any other signs. Concise and expressive. Else,
 what's the point? I know that languages like Lua have the philosophy
 that non-programmers should be able to use it. But every human being is
 capable of abstracting things. There is no need for this terrible syntax

 (2..max).each do:

 end


No need to do that. You can, if you want to. I would have done:

2.upto(max) do
   ...
end


 It doesn't add anything to the code except for useless characters.


What do you mean by useless characters? How do you do it in D?
Nov 15 2013
parent "Chris" <wendlec tcd.ie> writes:
On Friday, 15 November 2013 at 15:20:20 UTC, Ary Borenszweig 
wrote:

 On 11/15/13 11:39 AM, Chris wrote:

 Well, that was exactly my point. As a human being you don't 
 need the
 patronizing (and highly annoying) "for every number ...". This 
 is what
 you say when you explain it to a newbie. But there is no need 
 to spell
 this out in the syntax. Syntax of programming languages is (or 
 should
 be) like road signs, or any other signs. Concise and 
 expressive. Else,
 what's the point? I know that languages like Lua have the 
 philosophy
 that non-programmers should be able to use it. But every human 
 being is
 capable of abstracting things. There is no need for this 
 terrible syntax

 (2..max).each do:

 end


 No need to do that. You can, if you want to. I would have done:

 2.upto(max) do
   ...
 end


 It doesn't add anything to the code except for useless 
 characters.


 What do you mean by useless characters? How do you do it in D?


I prefer the C style syntax:

foreach (whatever) {
   // ...
} // closes block

All this "end" stuff is superfluous, but at least it closes 
blocks. My pet hate as far as syntax is concerned is Python. The 
indentation (t)error. Change, copy paste > run: Indentation error 
on line ... WTF?! In C style it doesn't matter if you have

if (a > b) { return; }

if (a > b) {
   return;
}

if (a > b)
{
return;
}

or in loops

     foreach (i; array) {
if (i == "Hello!") { break; }
     }

Cleaning up indentation is the programmer's business not the 
language's.
Nov 15 2013
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/15/13 9:47 AM, bearophile wrote:

 Ary Borenszweig:


 Here's what I was able to do in some minutes:

 ---
 if ARGV.length != 1
   puts "missing argument: n"
   exit 1
 end

 n = ARGV[0].to_i
 str = "1"
 buffer = String::Buffer.new(20)
 n.times do
   puts str.length
   str.each_chunk do |digit, count|
     buffer << '0' + count
     buffer << digit
   end
   str = buffer.to_s
   buffer.clear
 end

 With n=70 it takes about 4.89s. With n=45 it takes about 0.012s.


 This program is much longer in number of tokens to the first D program.
 You can write a D program about as fast as this in about the same number
 of tokens.


No. I just counted the tokens and D has more tokens:

http://pastebin.com/XZFf8dsj

It's even longer if I keep all the programs arguments checking (ARGV). 
If I remove that, the program has 45 tokens. The D version has 81 
tokens. And without the imports, D still has 68 tokens.

(well, I didn't count newlines as tokens, so maybe that's unfair because 
newlines in Crystal are significant)

Yes, it's not as functional as D. But only because the language is still 
young.


 Perhaps I should add an intermediate third version that shows code
 that's not as extreme as the two versions there. Thank you for the
 implicit suggestion.



 And with Crystal you could do the second version as well, because you
 have access to low level stuff like pointers.


 In Crystal do you have final switches, gotos, etc too?


No. In this D will always be better, if you really want your program to 
have gotos.


 And also, the language is pretty new so there's still
 a lot of optimizations to be done.


 And LDC2 will improve in the meantime.


And so LLVM, which is what Crystal uses as a backend.


 I also thought ranges were pretty fast because of their nature.


 It also matters a lot how you use them, this is normal in computer
 programming.


But I thought ranges were meant to be fast. No allocations and all of 
that. In fact, I was kind of sad that Crystal doesn't have a similar 
concept so it could never get as fast as D ranges. But if D ranges are 
not fast, what's the point of having them and making everyone use them?


 Why are they slow in this example?


 Just because the first example is not written for speed, I didn't even
 add run-time timings for it at first. And it's not that slow.


Ah, I thought you did. So I misunderstood your timings. Sorry.


 Bye,
 bearophile
Nov 15 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 And so LLVM, which is what Crystal uses as a backend.


LDC2 uses the same back end :-)



 But I thought ranges were meant to be fast. No allocations and 
 all of that. In fact, I was kind of sad that Crystal doesn't 
 have a similar concept so it could never get as fast as D 
 ranges. But if D ranges are not fast, what's the point of 
 having them and making everyone use them?


If you use ranges badly you will get a slow program, if you use 
them well with a good back-end, you will have a fast program.

I have written a third intermediate program, it's longer than 
yours, and it seems much slower than your code:


void main(in string[] args) {
     import std.stdio, std.conv, std.algorithm, std.array;

     immutable n = (args.length == 2) ? args[1].to!uint : 10;
     if (n == 0)
         return;

     auto seq = "1";
     writefln("%2d: n. digits: %d", 1, seq.length);
     foreach (immutable i; 2 .. n + 1) {
         Appender!string result;
         foreach (immutable digit, immutable count; seq.group) {
             result ~= "123"[count - 1];
             result ~= digit;
         }
         seq = result.data;
         writefln("%2d: n. digits: %d", i, seq.length);
     }
}


On my system it runs in 0.34 seconds for n=50. Could you compare 
some of the timings of the various D/Crystal versions on your 
system (using ldc2 for D)?

Bye,
bearophile
Nov 15 2013
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/15/13 10:33 AM, bearophile wrote:

 Ary Borenszweig:


 And so LLVM, which is what Crystal uses as a backend.


 LDC2 uses the same back end :-)



 But I thought ranges were meant to be fast. No allocations and all of
 that. In fact, I was kind of sad that Crystal doesn't have a similar
 concept so it could never get as fast as D ranges. But if D ranges are
 not fast, what's the point of having them and making everyone use them?


 If you use ranges badly you will get a slow program, if you use them
 well with a good back-end, you will have a fast program.

 I have written a third intermediate program, it's longer than yours, and
 it seems much slower than your code:


 void main(in string[] args) {
      import std.stdio, std.conv, std.algorithm, std.array;

      immutable n = (args.length == 2) ? args[1].to!uint : 10;
      if (n == 0)
          return;

      auto seq = "1";
      writefln("%2d: n. digits: %d", 1, seq.length);
      foreach (immutable i; 2 .. n + 1) {
          Appender!string result;
          foreach (immutable digit, immutable count; seq.group) {
              result ~= "123"[count - 1];
              result ~= digit;
          }
          seq = result.data;
          writefln("%2d: n. digits: %d", i, seq.length);
      }
 }


 On my system it runs in 0.34 seconds for n=50. Could you compare some of
 the timings of the various D/Crystal versions on your system (using ldc2
 for D)?


Sure.

This last version you wrote, compiling it with "-enable-inlining 
-release -O3", takes 0.054s (please tell me if I'm missing some flags, 
in Crystal I just used --release). The Crystal version takes 0.031s. I 
also tried with n=70. In D: 9.265s. In Crystal: 4.863s.

I couldn't compile the first version written in D because I get:

Error: pure function '__lambda1' cannot call impure function 'join'

(I think you mentioned this in another post in this thread)

The super-optimized D version, with n=70, takes 1.052s. This is the fastest.

However, I'm starting to think that all those immutable, final switches 
and gotos are useless if they don't give a performance benefit (well, 
final switches do give you more safety). Maybe it's just that D/ldc 
doesn't use the immutability information and everything else to do 
aggressive optimizations?
Nov 15 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

Your timings are good enough for me, I have updated the 
rosettacode page with the third D version.


 However, I'm starting to think that all those immutable, final 
 switches and gotos are useless if they don't give a performance 
 benefit (well, final switches do give you more safety).


In the second D program if you compile with ldc2 the final switch 
gives a significant performance increase :-)



 Maybe it's just that D/ldc doesn't use the immutability 
 information and everything else to do aggressive optimizations?


This was discussed some time ago. Probably there are ways for 
ldc2 to use a little better the static information of well 
annotated D code.

Bye,
bearophile
Nov 15 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ary Borenszweig:


 This last version you wrote, compiling it with 
 "-enable-inlining -release -O3", takes 0.054s (please tell me 
 if I'm missing some flags, in Crystal I just used --release). 
 The Crystal version takes 0.031s. I also tried with n=70. In D: 
 9.265s. In Crystal: 4.863s.


This version is more than twice faster, because group() avoids 
decoding UTF:


void main(in string[] args) {
     import std.stdio, std.conv, std.algorithm, std.array, 
std.string;

     immutable n = (args.length == 2) ? args[1].to!uint : 10;
     if (n == 0)
         return;

     auto seq = ['1'];
     writefln("%2d: n. digits: %d", 1, seq.length);
     foreach (immutable i; 2 .. n + 1) {
         Appender!(typeof(seq)) result;
         foreach (const digit, const count; 
seq.representation.group) {
             result ~= "123"[count - 1];
             result ~= digit;
         }
         seq = result.data;
         writefln("%2d: n. digits: %d", i, seq.length);
     }
}



 I couldn't compile the first version written in D because I get:

 Error: pure function '__lambda1' cannot call impure function 
 'join'


Just remove the "pure" for ldc2.



 However, I'm starting to think that all those immutable, final 
 switches and gotos are useless if they don't give a performance 
 benefit


Adding immutable to variables sometimes helps catch some troubles 
in your code. In a modern language variables should be immutable 
on default, and functions should be pure on default, because the 
default choice should be the faster (if it's equally safe) and 
because when you read code it's simpler to reason on things that 
have less capabilities (like the capability to mutate for a 
value).

Bye,
bearophile
Nov 15 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 15 November 2013 at 13:33:33 UTC, bearophile wrote:

 If you use ranges badly you will get a slow program, if you use 
 them well with a good back-end, you will have a fast program.


And so, what are the rules for not using ranges badly ? What 
should be avoided ?
Nov 17 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
SomeDude:


 And so, what are the rules for not using ranges badly ? What 
 should be avoided ?


A newsgroup post is not large enough to contain an answer to 
this, that requires one or two articles to be written. In general 
writing quick code is partially an art, with the help of the 
profiler.

Bye,
bearophile
Nov 17 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 15 Nov 2013 02:09:52 +0100
schrieb "bearophile" <bearophileHUGS lycos.com>:


 I have created two interesting D entries for this Rosettacode 
 Task, is someone willing to create a Reddit entry for this? They 
 show very different kinds of code in D.
 
 http://rosettacode.org/wiki/Look-and-say_sequence#D
 
 Bye,
 bearophile


APL is awesome!

-- 
Marco
Nov 15 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:

 I have created two interesting D entries for this Rosettacode 
 Task, is someone willing to create a Reddit entry for this? 
 They show very different kinds of code in D.

 http://rosettacode.org/wiki/Look-and-say_sequence#D

 Bye,
 bearophile


I have a task if you are interested, but I didn't bother to login 
to create it.
So if you like, you can create the page...

Here it is:
In a sequence of a million random integers, return the length and 
the indexes of the longest duplicate sequence (display indexes 
counting from one, not zero).

In order for everybody to start with the same random sequence, it 
may be useful to specify a simple implementation for the 
generating function.
Nov 17 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
SomeDude:


 I have a task if you are interested, but I didn't bother to 
 login to create it.
 So if you like, you can create the page...


It's better to discuss this in D.learn, where most of Rosettacode 
matters are discussed. I opened this in the main newsgroup to see 
if someone was willing to post it to Reddit.



 In a sequence of a million random integers, return the length 
 and the indexes of the longest duplicate sequence (display 
 indexes counting from one, not zero).


If you write a first version of D solution I can post task 
description and its D solution in the Rosettacode site. I will 
later make improvements in your code, to make it more uniform 
with the other entries, etc.



 In order for everybody to start with the same random sequence, 
 it may be useful to specify a simple implementation for the 
 generating function.


What function do you suggest? (It should be possible to implement 
on 32-64bit systems, in Haskell, in languages with only 
multi-precision integers, in languages like Ada that give errors 
on overflows, and in Java without unsigned integers).

Bye,
bearophile
Nov 17 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
 What function do you suggest? (It should be possible to 
 implement on 32-64bit systems, in Haskell, in languages with 
 only multi-precision integers, in languages like Ada that give 
 errors on overflows, and in Java without unsigned integers).


The Computer Shootout site uses this one:


int nextRandom() nothrow {
     enum int IM = 139968, IA = 3877, IC = 29573;
     __gshared static int last = 42;
     return last = (last * IA + IC) % IM;
}

void main() {
     import std.stdio;

     foreach (i; 0 .. 100) {
         nextRandom.writeln;
     }
}


Bye,
bearophile
Nov 17 2013