[Radiance-general] Research tools: who what which how?

[Georg Mischler]

The "definitive suggestions" you're hoping for will always necessarily
be highly subjective. If you want help deciding which language to
learn next, you'll have to ask more specific questions.

My personal preference is no secret. Now the discussion here (and on
radiance-dev) has prompted me to finally have a much closer look at
Ruby than before. Unfortunately, that hasn't really improved my
opinion about it...

But is that relevant to you? Since I don't know what you're actually
looking for, I have no idea.

Cheers
-schorsch


Am 2016-04-18 16:31, schrieb Christopher Rush:
> Schorsch, Thanks! Precisely the type of response I was trying to poke
> for. I threw something together in a few minutes from a quick google
> search just to steer the conversation. I certainly didn't do much
> quality comparison, and zero thinking about if any of these are really
> the right way to do it. My primary note is that we can debate the
> optimal, but the collective mental barriers and user-group
> predisposition, and size or quality of searchable online resources
> should be considered. I'm not the best person to consider them since I
> have very little depth in any language, but just noting to keep
> novices like me in mind. I honestly don't know if those make a case
> for any one language, but I felt compelled to add my two cents - since
> everyone else was talking about APIs which I have no concern for.
> 
> I always wish that threads like this one gave me more definitive
> suggestions for putting more effort in any one language (which, of
> course, is asking too much!).
> 
> 
> -----Original Message-----
> From: Georg Mischler [mailto:schorsch at schorsch.com]
> 
> Somewhat off-topic, but...
> 
> Out of curiosity, I played around with those examples a bit.
> I had to slightly modify all of them, first to get Perl and Ruby to run
> at all, and then to make sure all of them produce tabs instead of
> spaces.
> Btw: The Perl version adds an extra tab at the end of each line.
> 
> 
> perl -anF'\t|\n' -e'$n=@F-1 if \!$n;for(0..$n){push@{$$m[$_]},$F[$_]}
> END{print map{join"\t",@$_,"\n"}@$m}'
> 
> python -c "import sys; print('\n'.join('\t'.join(c) for c in
> zip(*(l.split() for l in sys.stdin.readlines() if l.strip()))))"
> 
> ruby -e 'puts readlines.map(&:split).transpose.map(){|x|x*"\t"}'
> 
> 
> The result shows (as expected) that this kind of comparison is utterly
> meaningless. There are simply too many factors out of your control
> that can influence the result. Between Perl and Python, the
> executables that happen to be installed on my box pretty much get the
> opposite result than you reported. Maybe my Python is in better shape
> than yours, because it gets more exercise... ;)
> 
> I'm actually a bit surprised by the bad performance of Perl. One of
> the reasons may be the suboptimal algorithm, which explicitly loops
> through the data in the interpreter. The other two use a functional
> approach, where the heavy lifting is handled in C. Ruby has a slower
> startup time, but its operating performance is much closer to Python.
> I also didn't expect that much of a speed-up with Python 3 over 2.
> 
> The Python version is easy to understand, once you know that the
> builtin function zip() is equivalent to Rubys transpose(). The rest
> is IO and string manipulation. You also may not be familiar with
> generator expressions. Very powerful stuff!
> 
> 
> 150 Kb  (160 x 160 matrix)
> 
> 0.2  perl 5
> 0.1  python 2.7
> 0.02 python 3.4
> 0.4  ruby
> 
> 
> 6 Mb  (1000 x 1000 matrix)
> 
> 1.02  perl 5
> 0.36  python 2.7
> 0.22  python 3.4
> 0.48  ruby 2.1
> 
> 
> 24 Mb  (2000 x 2000 matrix)
> 
> 4.11  perl 5
> 1.74  python 2.7
> 1.13  python 3.4
> 2.41  ruby 2.1
> 
> 
> Cheers
> -schorsch


-- 
Georg Mischler  --  simulations developer  --  schorsch at schorsch com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/