On Fri, 2016-09-09 at 12:22 +, Kagamin via Digitalmars-d-learn
wrote:
> On Thursday, 8 September 2016 at 10:26:04 UTC, Russel Winder
> wrote:
> >
> > >
> > > Do they use single assignment a lot?
> >
> > Python has no notion of single assignment. Exactly the
> > opposite, Python allows
On Fri, 2016-09-09 at 14:20 +, jmh530 via Digitalmars-d-learn
wrote:
> […]
>
> What I mean is that Chapel doesn't have a lot of libraries (also
> true for D, but things are getting better). If I'm going to do
> some analysis, it usually takes much less time for me to do it in
>
On Thu, 2016-09-08 at 15:45 +, deXtoRious via Digitalmars-d-learn
wrote:
>
[…]
> It's very early days for Chapel at the moment, but I don't really
> see it as being remotely comparable to D or even Julia, it's much
> closer to a DSL than a general purpose language. That's by no
> means a
On Friday, 9 September 2016 at 13:32:16 UTC, Russel Winder wrote:
Why write algorithms in C or C++ when you can do it in Chapel?
For the moment, the objective answers to that question seem: you
need GPGPU (especially CUDA, which is vastly more convenient to
use from C++ than from anything
On Friday, 9 September 2016 at 13:32:16 UTC, Russel Winder wrote:
Should we be giving up on D and switching to Sparrow?
Most certainly not! I don't think it has to be either D or
Sparrow. There is a quote liked from one of Walter's
presentation. Someone asked the question:
"What happens
On Friday, 9 September 2016 at 13:24:18 UTC, Russel Winder wrote:
For computational work I'd say Chapel was just as productive as
any other language, probably better. This is though likely an
issue on which there is only opinion and no facts.
GPGPU support is not in Chapel as yet I believe,
On Thu, 2016-09-08 at 14:39 +, data pulverizer via Digitalmars-d-
learn wrote:
> […]
>
> I can see where you are coming from, I have taken a look at
> Chapel and high performance computing is their top priority. I
> think they hope that it will be the next Fortran, but I think it
> is very
On Thu, 2016-09-08 at 13:09 +, jmh530 via Digitalmars-d-learn
wrote:
> On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder
> wrote:
> >
> >
> > I am certainly hoping that Chapel will be the language to
> > displace NumPy for serious computation in the Python-sphere.
> > Given
On Thursday, 8 September 2016 at 10:26:04 UTC, Russel Winder
wrote:
Do they use single assignment a lot?
Python has no notion of single assignment. Exactly the
opposite, Python allows everything to be changed at any time.
Then you probably shouldn't pitch them alien concepts?
On Thursday, 8 September 2016 at 10:20:42 UTC, Russel Winder
wrote:
On Wed, 2016-09-07 at 20:29 +, deXtoRious via
Digitalmars-d-learn wrote:
[…]
More to the general point of the discussion, I find that most
scientifically minded users of Python already appreciate some
of the inherent
On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder
wrote:
I am certainly hoping that Chapel will be the language to
displace NumPy for serious computation in the Python-sphere.
Given it's foundation in the PGAS model, it has all the
parallelism needs, both cluster and local, built
On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder
wrote:
I am certainly hoping that Chapel will be the language to
displace NumPy for serious computation in the Python-sphere.
Given it's foundation in the PGAS model, it has all the
parallelism needs, both cluster and local, built
On Wed, 2016-09-07 at 16:21 +, Kagamin via Digitalmars-d-learn
wrote:
> On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder
> wrote:
> >
> > The real problem though is the terrifying error message. I am
> > having a hard time finding a way of pitching them to
> > Pythonistas.
>
On Wed, 2016-09-07 at 20:29 +, deXtoRious via Digitalmars-d-learn
wrote:
>
[…]
> More to the general point of the discussion, I find that most
> scientifically minded users of Python already appreciate some of
> the inherent advantages of lower level statically typed languages
> and often
On Wed, 2016-09-07 at 20:29 +, jmh530 via Digitalmars-d-learn
wrote:
>
[…]
> Are you familiar with Chapel at all? The language allows the user
> to specify a domain with an array, facilitating sparsity or
> arrays distributed across different machines. For some reason I
> was reminded of
On Wednesday, 7 September 2016 at 21:41:20 UTC, data pulverizer
wrote:
Yes, but from a usability point of view this would be very poor
- forcing the user to create a new variable each time they
modified a table. I am aware that databases do this but it is
hidden away.
To be fair, you can
On Wednesday, 7 September 2016 at 21:33:25 UTC, pineapple wrote:
Fuck it, I took an hour to document the most significant
modules.
https://github.com/pineapplemachine/mach.d/tree/master/mach/range
Looks like a step in the right direction!
On Wednesday, 7 September 2016 at 22:11:05 UTC, data pulverizer
wrote:
On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote:
I too come from the R world and I have been playing the game
of flitting between R and C++; using C++ (through RCpp) to
speed up slow things in R for some
On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote:
I too come from the R world and I have been playing the game
of flitting between R and C++; using C++ (through RCpp) to
speed up slow things in R for some time and I have been
looking for a better solution.
What are you doing
On Wednesday, 7 September 2016 at 21:25:30 UTC, jmh530 wrote:
Consider a potential use case. You have an existing data frame
and you want to add a column of data to it that has a different
type than the existing frame. I imagine the function call would
look something like:
auto newFrame =
On Wednesday, 7 September 2016 at 20:29:42 UTC, jmh530 wrote:
Thanks for the reply. It looks like an interesting idea. You
might consider adding this (or a modified version) to a read me
in the range subfolder.
Fuck it, I took an hour to document the most significant modules.
On Wednesday, 7 September 2016 at 20:49:42 UTC, data pulverizer
wrote:
You're quite right that D doesn't need to change at all to
implement something like pandas or dataframes in R, but I am
thinking of how to got further. Very often in data science
applications types will turn up that are
On Wednesday, 7 September 2016 at 21:07:20 UTC, data pulverizer
wrote:
Don't get me wrong, I still think Julia is a very cool
language. My opinion is that we should have more languages.
Let me correct myself ... I think that hyper-meta-programming as
in Sparrow could certainly revolutionize
On Wednesday, 7 September 2016 at 21:01:59 UTC, deXtoRious wrote:
That's just typical press nonsense, and even they quote
Bezanson saying how Julia isn't at all suited to a whole host
of applications. Julia certainly has (justifiable, imho, though
only time will tell) ...
Don't get me wrong,
On Wednesday, 7 September 2016 at 20:57:03 UTC, data pulverizer
wrote:
On Wednesday, 7 September 2016 at 20:29:51 UTC, deXtoRious
wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data
pulverizer wrote:
The "One language to rule them all" motif of Julia has hit
the rocks; one reason is
On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote:
What are you doing with Rcpp that you can't do with D?
That's a very good point, there's nothing that R + C++ can do
that is out of D's reach. But, I wander if we can go further
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
On Wednesday, 7 September 2016 at 15:04:38 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder
wrote:
I really don't see what's not working in this.
Trying to get new D users from Python
On Wednesday, 7 September 2016 at 20:29:51 UTC, deXtoRious wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
The "One language to rule them all" motif of Julia has hit the
rocks; one reason is because they now realize that their
language is being held back because
On Wednesday, 7 September 2016 at 20:37:50 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
I don't see any reason why D can't implement pandas DataFrames
without needing to change the language at all
On Wednesday, 7 September 2016 at 20:37:50 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
For some time I have been considering a problem to do with
creating tables with unbounded types, one of the failed
attempts is here:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
For some time I have been considering a problem to do with
creating tables with unbounded types, one of the failed
attempts is here:
https://forum.dlang.org/thread/gdjaoxypicsxlfvzw...@forum.dlang.org?page=1
I then
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
The "One language to rule them all" motif of Julia has hit the
rocks; one reason is because they now realize that their
language is being held back because the compiler cannot infer
certain types for example:
On Wednesday, 7 September 2016 at 18:55:41 UTC, pineapple wrote:
So the first difference you're likely to notice is that it's
not as well documented. (Sorry. I'm a busy woman. I'll get
around to it.) I try to make up for it with copious unit tests,
which should provide a good example for how
On Wednesday, 7 September 2016 at 15:04:38 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder
wrote:
I really don't see what's not working in this.
Trying to get new D users from Python users is the main
problem.
I came to D from Python/R/Matlab. The
On Wednesday, 7 September 2016 at 18:22:39 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 18:10:45 UTC, pineapple wrote:
You might want to check out the ranges package of the library
I'm working on.
https://github.com/pineapplemachine/mach.d/tree/master/mach/range
There's a lot of
On Wednesday, 7 September 2016 at 18:10:45 UTC, pineapple wrote:
You might want to check out the ranges package of the library
I'm working on.
https://github.com/pineapplemachine/mach.d/tree/master/mach/range
There's a lot of stuff there. Do you mind giving a TL;DR version
of what your
On Tuesday, 6 September 2016 at 14:38:54 UTC, Russel Winder wrote:
and I have no idea just now why it is complaining, nor what to
do to fix it.
You might want to check out the ranges package of the library I'm
working on.
https://github.com/pineapplemachine/mach.d/tree/master/mach/range
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder
wrote:
The real problem though is the terrifying error message. I am
having a hard time finding a way of pitching them to
Pythonistas.
Do they use single assignment a lot?
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder
wrote:
I really don't see what's not working in this.
Trying to get new D users from Python users is the main problem.
I came to D from Python/R/Matlab. The biggest issue for me wasn't
error messages so much as the lack of
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder
wrote:
I'd prefer immutable, but const sometimes has to do. The idea
is to find out how to enforce single assignment in D.
Everything depends on what you mean by "single assignment".
If you mean "I can't use opAssign", then const
On Wednesday, 7 September 2016 at 11:33:08 UTC, Russel Winder
wrote:
C++, error messages
sorry, i loled hard.
On Wed, 2016-09-07 at 09:04 +, Lodovico Giaretta via Digitalmars-d-
learn wrote:
>
[…]
> You have your const fixed-length array. You slice it and you
> obtain a const range to feed map. Now map will not return you an
> array. Because most of the time you don't need it. It will return
> you
On Wed, 2016-09-07 at 09:03 +, ketmar via Digitalmars-d-learn
wrote:
> […]
>
> alas, no jokes here. within the current D sytnax there is simply
> no way to make that error less cryptic. :-(
Well that will be the end of any traction for D then. C++, Java,
Groovy, etc. error messages prove
On Wed, 2016-09-07 at 20:32 +1200, rikki cattermole via Digitalmars-d-
learn wrote:
>
[…]
> Ok, I have it mostly compiling.
>
> void run_mean() {}
> void run_mode() {}
> void run_stdDev() {}
For my code the functions have to be declared within the main function
rather than being at module
On Wed, 2016-09-07 at 08:42 +, Kagamin via Digitalmars-d-learn
wrote:
> https://dpaste.dzfl.pl/0b436b240e3c
But now try adding the writeln function. Then you get the errors.
--
Russel.
=
Dr Russel Winder t: +44
On Wednesday, 7 September 2016 at 08:19:39 UTC, Russel Winder
wrote:
On Tue, 2016-09-06 at 14:50 +, Lodovico Giaretta via
Digitalmars-d- learn wrote:
[…]
From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays
On Wednesday, 7 September 2016 at 08:30:51 UTC, Russel Winder
wrote:
On Tue, 2016-09-06 at 14:53 +, ketmar via
Digitalmars-d-learn wrote:
[…]
exactly. static arrays doesn't have `popFront`, hence
`isInputRange` fails. yet there is no way to tell that to
user, so one should just learn
https://dpaste.dzfl.pl/0b436b240e3c
On 07/09/2016 2:38 AM, Russel Winder via Digitalmars-d-learn wrote:
The code fragment:
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results);
seems entirely reasonable to me.
On Tue, 2016-09-06 at 14:53 +, ketmar via Digitalmars-d-learn
wrote:
>
[…]
> exactly. static arrays doesn't have `popFront`, hence
> `isInputRange` fails. yet there is no way to tell that to user,
> so one should just learn what those cryptic error messages really
> means.
I shall assume
On Tue, 2016-09-06 at 14:50 +, Lodovico Giaretta via Digitalmars-d-
learn wrote:
>
[…]
> From a quick look, it looks like `results` is a
> `const(TickDuration[3])`, that is a fixed-length array. And
> fixed-length arrays aren't ranges. If you explicitly slice them,
> they become dynamic
On Tuesday, 6 September 2016 at 14:50:17 UTC, Lodovico Giaretta
wrote:
From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays aren't ranges. If you explicitly slice
them, they become dynamic arrays, which are ranges.
So
On Tuesday, 6 September 2016 at 14:38:54 UTC, Russel Winder wrote:
The code fragment:
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results);
seems entirely reasonable to me. However
The code fragment:
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results);
seems entirely reasonable to me. However rdmd 20160627 begs to differ:
run_checks.d(20): Error: template
54 matches
Mail list logo
