www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Templates problem

reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
The code fragment:

	const results =3D benchmark!(run_mean, run_mode, run_stdDev)(1);
	const times =3D map!((TickDuration t) { return (to!Duration(t)).total!"sec=
onds"; })(results);

seems entirely reasonable to me. However rdmd 20160627 begs to differ:

run_checks.d(20): Error: template std.algorithm.iteration.map!(function (Ti=
ckDuration t) =3D> to(t).total()).map cannot deduce function from argument =
types !()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std.algorithm.iteration.map!(function (TickDu=
ration t) =3D> to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!=
Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]

and I have no idea just now why it is complaining, nor what to do to
fix it.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 06 2016
next sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
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 rdmd 20160627 begs to 
 differ:

 run_checks.d(20): Error: template 
 std.algorithm.iteration.map!(function (TickDuration t) => 
 to(t).total()).map cannot deduce function from argument types 
 !()(const(TickDuration[3])), candidates are:
 /usr/include/dmd/phobos/std/algorithm/iteration.d(450):        std.algorithm.ite
ation.map!(function (TickDuration t) => to(t).total()).map(Range)(Range r) if
(isInputRange!(Unqual!Range))
 Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]

 and I have no idea just now why it is complaining, nor what to 
 do to fix it.


 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 the solution is to call `map` with `results[]` instead of 
`results`.
Sep 06 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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 the solution is to call `map` with `results[]` instead of 
 `results`.


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.

or just get used to always slice arrays, it's cheap. ;-)
Sep 06 2016
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, 2016-09-06 at 14:53 +0000, ketmar via Digitalmars-d-learn
wrote:

=20


[=E2=80=A6]

 exactly. static arrays doesn't have `popFront`, hence=C2=A0
 `isInputRange` fails. yet there is no way to tell that to user,=C2=A0
 so one should just learn what those cryptic error messages really=C2=A0
 means.


I shall assume a ;-) at the end of that. In trying to pitch D to
Pythonistas, having to deal with error messages of this sort is the
fastest route to "F    that I'll just use Python", with D consigned to
the dustbin.

Either that or it will make it very easy to pitch Chapel to
Pythonistas. Which I shall also be trying to do as well =E2=80=93 the idea =
is
to wean Pythonistas off hacking Python to achieve computational speed,
get them into a polyglot approach.

The issue here is having to compete against NumPy and Numba for
performance computation, and Matplotlib for data visualisation. C, C++,
Rust, Go will not cut it as competition in performance computation. D
and Chapel (and X10 and Fortran but I am avoiding them) can. Sort of.
The issue is that Python and Matplotlib should be seen as the partners
rather than competition for D and Chapel. Arcane error messages from D
compilers, are the fastest turn offs imaginable for people coming new
to a language.=C2=A0


 or just get used to always slice arrays, it's cheap. ;-)


Except that it seems you cannot create a range from a const array by
slicing. If the algorithms cannot operate on const arrays then the
algorithms have a problem. If the algorithms have a problem, the
language has a problem.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 07 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 7 September 2016 at 08:30:51 UTC, Russel Winder 
wrote:

 On Tue, 2016-09-06 at 14:53 +0000, 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 a ;-) at the end of that.


alas, no jokes here. within the current D sytnax there is simply 
no way to make that error less cryptic. :-(

even pointing at the failed constraint is fairly hard with 
current DMDFE code (that's why nobody did it yet), and show 
custom error for that is nearly impossible. we can't write "catch 
all" template with static assert, 'cause it catches everything, 
which is not desirable.

i myself didn't found even acceptable solution for this mess. 
sure, at least pointing to failed constraint is something we 
should have, but in your case it is of little help, actually.

probably adding `map` overload which accepts static arrays and 
does `static assert(0, "please use slice for static arrays");` 
may help in this case.
Sep 07 2016
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 09:03 +0000, ketmar via Digitalmars-d-learn
wrote:

 [=E2=80=A6]
=20
 alas, no jokes here. within the current D sytnax there is simply=C2=A0
 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 that error reporting is something you
get right or you have no users that are not working under Stockholm
Syndrome.


 even pointing at the failed constraint is fairly hard with=C2=A0
 current DMDFE code (that's why nobody did it yet), and show=C2=A0
 custom error for that is nearly impossible. we can't write "catch=C2=A0
 all" template with static assert, 'cause it catches everything,=C2=A0
 which is not desirable.
=20
 i myself didn't found even acceptable solution for this mess.=C2=A0
 sure, at least pointing to failed constraint is something we=C2=A0
 should have, but in your case it is of little help, actually.
=20
 probably adding `map` overload which accepts static arrays and=C2=A0
 does `static assert(0, "please use slice for static arrays");`=C2=A0
 may help in this case.


I think bearophile suggested adding amap many moons ago.

I suspect this will never happen due to array(map(=E2=80=A6)) which is fine=
.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 07 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 7 September 2016 at 11:33:08 UTC, Russel Winder 
wrote:

 C++, error messages


sorry, i loled hard.
Sep 07 2016
prev sibling parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, 2016-09-06 at 14:50 +0000, Lodovico Giaretta via Digitalmars-d-
learn wrote:

=20


[=E2=80=A6]

 =C2=A0From a quick look, it looks like `results` is a=C2=A0
 `const(TickDuration[3])`, that is a fixed-length array. And=C2=A0
 fixed-length arrays aren't ranges. If you explicitly slice them,=C2=A0
 they become dynamic arrays, which are ranges.
=20
 So the solution is to call `map` with `results[]` instead of=C2=A0
 `results`.


So trying with results[] leads to:

run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(=
function (TickDuration t) =3D> to(t).total(), const(TickDuration)[]).MapRes=
ult.opIndex is not callable using a const object
run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(=
function (TickDuration t) =3D> to(t).total(), const(TickDuration)[]).MapRes=
ult.opIndex is not callable using a const object
run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(=
function (TickDuration t) =3D> to(t).total(), const(TickDuration)[]).MapRes=
ult.opIndex is not callable using a const object

yes, the message is repeated three times, for unknown reason. Possibly
because the compiler is fairly certain I am not going to believe it.

So the upshot of this is that I can't work with const data, which is
dreadful in these days of single assignment being the way of doing
things.

So what is the way of constructing a range from a const array? If it
involves copying then D is doomed.

And yes I am under stress as I am trying to pitch D to Python people
next week.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 07 2016
next sibling parent reply Kagamin <spam here.lot> writes:
https://dpaste.dzfl.pl/0b436b240e3c
Sep 07 2016
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 08:42 +0000, Kagamin via Digitalmars-d-learn
wrote:

 https://dpaste.dzfl.pl/0b436b240e3c


But now try adding the writeln function. Then you get the errors.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 07 2016
prev sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 7 September 2016 at 08:19:39 UTC, Russel Winder 
wrote:

 On Tue, 2016-09-06 at 14:50 +0000, 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 arrays, which are ranges.
 
 So the solution is to call `map` with `results[]` instead of 
 `results`.


 So trying with results[] leads to:

 run_checks.d(21): Error: mutable method 
 std.algorithm.iteration.MapResult!(function (TickDuration t) => 
 to(t).total(), const(TickDuration)[]).MapResult.opIndex is not 
 callable using a const object
 run_checks.d(21): Error: mutable method 
 std.algorithm.iteration.MapResult!(function (TickDuration t) => 
 to(t).total(), const(TickDuration)[]).MapResult.opIndex is not 
 callable using a const object
 run_checks.d(21): Error: mutable method 
 std.algorithm.iteration.MapResult!(function (TickDuration t) => 
 to(t).total(), const(TickDuration)[]).MapResult.opIndex is not 
 callable using a const object

 yes, the message is repeated three times, for unknown reason. 
 Possibly because the compiler is fairly certain I am not going 
 to believe it.

 So the upshot of this is that I can't work with const data, 
 which is dreadful in these days of single assignment being the 
 way of doing things.

 So what is the way of constructing a range from a const array? 
 If it involves copying then D is doomed.

 And yes I am under stress as I am trying to pitch D to Python 
 people next week.


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 a range that lazily computes its elements on demand. No 
memory allocation at all. You can do a foreach on that range. If 
you need to access those elements more than once, instead of 
recomputing each of them every time it is accessed, you can store 
the results of the map. You simply have to use .array on the map 
result. This will allocate memory and give you an array with your 
results. Otherwise, no allocation at all. That result array can 
be const, if you want. If you need to access your elements only 
once, there's no need to have an array.

I really don't see what's not working in this.

And by the way, there's no need to put const on everything. An 
optimizing compiler is often able to infer things, especially for 
stack allocated local variables.
Sep 07 2016
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 09:04 +0000, Lodovico Giaretta via Digitalmars-d-
learn wrote:

=20


[=E2=80=A6]

 You have your const fixed-length array. You slice it and you=C2=A0
 obtain a const range to feed map. Now map will not return you an=C2=A0
 array. Because most of the time you don't need it. It will return=C2=A0
 you a range that lazily computes its elements on demand. No=C2=A0
 memory allocation at all. You can do a foreach on that range. If=C2=A0
 you need to access those elements more than once, instead of=C2=A0
 recomputing each of them every time it is accessed, you can store=C2=A0
 the results of the map. You simply have to use .array on the map=C2=A0
 result. This will allocate memory and give you an array with your=C2=A0
 results. Otherwise, no allocation at all. That result array can=C2=A0
 be const, if you want. If you need to access your elements only=C2=A0
 once, there's no need to have an array.


The problem for me had been that ranges are mutable or useless since
they are single use destructive things. So yes trying to add immutable
or const to it is breaking the range model.

The real problem though is the terrifying error message. I am having a
hard time finding a way of pitching them to Pythonistas.



 I really don't see what's not working in this.


Trying to get new D users from Python users is the main problem.=C2=A0


 And by the way, there's no need to put const on everything. An=C2=A0
 optimizing compiler is often able to infer things, especially for=C2=A0
 stack allocated local variables.


I'd prefer immutable, but const sometimes has to do. The idea is to
find out how to enforce single assignment in D.=C2=A0


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 07 2016
next sibling parent Lodovico Giaretta <lodovico giaretart.net> writes:
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 is definitely too 
strong. In this case, you can write a simple type wrapper that 
disables opAssign, while providing all other functionalities.

If you mean "Methods do not mutate objects; instead, they return 
new objects, mutated", the issue is deeper. In fact, input ranges 
and output ranges cannot (by definition) fulfill this 
requirement. Other ranges (forward, bidirectional, random) can 
fulfill this requirement, but it's very expensive, as it requires 
a new copy of every range every time you want to popFront or 
popBack. The same goes for every other type with mutable methods. 
If you really want this behaviour, you can easily write (again) a 
type wrapper that forwards every const method call while 
intercepting every mutable method call and applying it to a new 
copy that is returned. But I think it will severely hurt 
performance and readability.
Sep 07 2016
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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 good libraries for a lot of 
things.

Nevertheless, the longer I've been using D, the more I agree that 
there could be some improvements in D's error messages. Andre had 
posted about the Sparrow language a while back
https://forum.dlang.org/thread/ne3265$uef$1 digitalmars.com?page=1
He liked their use of concepts. I think at a minimum it would 
enable better error messages.
Sep 07 2016
parent reply data pulverizer <data.pulverizer gmail.com> writes:
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 biggest issue for me 
 wasn't error messages so much as the lack of good libraries for 
 a lot of things.

 Nevertheless, the longer I've been using D, the more I agree 
 that there could be some improvements in D's error messages. 
 Andre had posted about the Sparrow language a while back
 https://forum.dlang.org/thread/ne3265$uef$1 digitalmars.com?page=1
 He liked their use of concepts. I think at a minimum it would 
 enable better error messages.


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.

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/gdjaoxypicsxlfvzwbvt forum.dlang.org?page=1
I then exchanged emails with Lucian, Sparrows creator and he very 
quickly and simply outlined the solution to the problem. 
Thereafter I read his PhD thesis - one of the most informative 
texts in computer science I have read and very well written.

At the moment, there are lots of languages attempting to solve 
the dynamic-static loop, being able to have features inherent in 
dynamic programming languages, while keeping the safety and 
performance that comes with a static compiled programming 
language, and then doing so in a language that doesn't cause your 
brain to bleed. 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: 
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

A language that can create arbitrary complex programs is the kind 
of thing that changes the world. I don't think D should be left 
out and should take Sparrow very seriously indeed.
Sep 07 2016
next sibling parent reply deXtoRious <dextorious gmail.com> writes:
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: 
 http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/


As an avid user of Julia, I'm going to have to disagree very 
strongly with this statement. The language is progressing very 
nicely and while it doesn't aim to be the best choice for every 
programming task imaginable, it already does an excellent job of 
letting a scientific programmer such as myself do most of my 
workflow in a single language with remarkable performance. 
Furthermore, the article you linked pertains to a simple type 
inference issue, exposed by the design constraints of a 
particular library. While certain design patterns can and often 
do lead to Python-style Julia code with optimal performance, you 
can always get there by manually enforcing type stability at the 
cost of less pretty code.

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 rather write C/C++ code than descend into the likes of 
Cython. D has considerable advantages over C++ in conciseness and 
template facilities for achieving zero cost static polymorphism 
without descending into utter unreadability. Personally, I find 
myself still forced to write most of my non-Julia high 
performance code in C++ due to the available libraries and GPGPU 
support (especially CUDA), but in terms of language properties 
I'd much rather be writing D.
Sep 07 2016
next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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 the compiler cannot infer 
 certain types for example: 
 http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/


 As an avid user of Julia, I'm going to have to disagree very 
 strongly with this statement. The language is progressing very 
 nicely and while it doesn't aim to be the best choice for every 
 programming task imaginable...


Ahem (http://www.wired.com/2014/02/julia/), I'm not saying that 
the Julia founders approved that title, we all know how the press 
can inflate things, but there was a certain rhetoric that Julia 
was creating something super-special that would change everything.
Sep 07 2016
parent reply deXtoRious <dextorious gmail.com> writes:
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 because they now realize that their 
 language is being held back because the compiler cannot infer 
 certain types for example: 
 http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/


 As an avid user of Julia, I'm going to have to disagree very 
 strongly with this statement. The language is progressing very 
 nicely and while it doesn't aim to be the best choice for 
 every programming task imaginable...


 Ahem (http://www.wired.com/2014/02/julia/), I'm not saying that 
 the Julia founders approved that title, we all know how the 
 press can inflate things, but there was a certain rhetoric that 
 Julia was creating something super-special that would change 
 everything.


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) aspirations of being useful in certain areas of 
general computing, not just scientific code, but they are far 
from universal applicability, let alone optimality. If nothing 
else, it's an interesting example of thinking rather far outside 
the usual box of language design, one with demonstrable real 
world applications.
Sep 07 2016
next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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, I still think Julia is a very cool language. 
My opinion is that we should have more languages.
Sep 07 2016
parent data pulverizer <data.pulverizer gmail.com> writes:
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 computing. I think that 
a big deal.
Sep 07 2016
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
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) aspirations of being useful in certain 
 areas of general computing, not just scientific code, but they 
 are far from universal applicability, let alone optimality. If 
 nothing else, it's an interesting example of thinking rather 
 far outside the usual box of language design, one with 
 demonstrable real world applications.


It's also from 2014...
Sep 07 2016
prev sibling parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 20:29 +0000, deXtoRious via Digitalmars-d-learn
wrote:

=20


[=E2=80=A6]

 More to the general point of the discussion, I find that most=C2=A0
 scientifically minded users of Python already appreciate some of=C2=A0
 the inherent advantages of lower level statically typed languages=C2=A0
 and often rather write C/C++ code than descend into the likes of=C2=A0
 Cython. D has considerable advantages over C++ in conciseness and=C2=A0
 template facilities for achieving zero cost static polymorphism=C2=A0
 without descending into utter unreadability. Personally, I find=C2=A0
 myself still forced to write most of my non-Julia high=C2=A0
 performance code in C++ due to the available libraries and GPGPU=C2=A0
 support (especially CUDA), but in terms of language properties=C2=A0
 I'd much rather be writing D.


Or Chapel.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 08 2016
parent reply deXtoRious <dextorious gmail.com> writes:
On Thursday, 8 September 2016 at 10:20:42 UTC, Russel Winder 
wrote:

 On Wed, 2016-09-07 at 20:29 +0000, 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 rather write C/C++ code than descend into 
 the likes of Cython. D has considerable advantages over C++ in 
 conciseness and template facilities for achieving zero cost 
 static polymorphism without descending into utter 
 unreadability. Personally, I find myself still forced to write 
 most of my non-Julia high performance code in C++ due to the 
 available libraries and GPGPU support (especially CUDA), but 
 in terms of language properties I'd much rather be writing D.


 Or Chapel.


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 bad thing, it seems like it could be a very useful tool 
in a few years, but it's never going to completely substitute for 
the likes of Python, C++ or D even for purely scientific 
programming. I'm also a bit concerned about how limited the 
compile time facilities seem there at the moment, but I guess 
we'll just have to wait and see how it develops over the next 
couple of years.
Sep 08 2016
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 2016-09-08 at 15:45 +0000, deXtoRious via Digitalmars-d-learn
wrote:

=20


[=E2=80=A6]

 It's very early days for Chapel at the moment, but I don't really=C2=A0
 see it as being remotely comparable to D or even Julia, it's much=C2=A0
 closer to a DSL than a general purpose language. That's by no=C2=A0
 means a bad thing, it seems like it could be a very useful tool=C2=A0
 in a few years, but it's never going to completely substitute for=C2=A0
 the likes of Python, C++ or D even for purely scientific=C2=A0
 programming. I'm also a bit concerned about how limited the=C2=A0
 compile time facilities seem there at the moment, but I guess=C2=A0
 we'll just have to wait and see how it develops over the next=C2=A0
 couple of years.


In some sense Chapel is a 12 year old programming language, but clearly
it is still a bit of a youngster in many ways. In that Chapel was
developed to deal with programming supercomputers, it is a niche
language for heavyweight computation. But that is exactly what Python
is missing, and whilst NumPy, Numba, Cython, C, C++, Fortran, and D can
help, none of them can make programming parallel systems quite as nice
as a language specifically designed for the job.

Chapel programming has a not dissimilar "feel" to D programming in many
ways, it's just that Chapel is aimed at big kit, and D isn't. The trick
though is that Chapel can be used on little kit as well and in this
sense competes directly with D. The Chapel team are well funded, but
are still focused on big kit, but are turning their attention to
traction and little kit. In this sense Chapel could be a risk to D
traction.

Chapel focuses on arrays so it is very much a competitor to NumPy.
Except that NumPy has many more years of things built on top of it than
Chapel has.

For programming computations for anything other than a small laptop,
I'd choose Chapel over Python/NumPy any day. For visualising the
results teh Python milieu wins hands down.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 10 2016
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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/gdjaoxypicsxlfvzwbvt forum.dlang.org?page=1
 I then exchanged emails with Lucian, Sparrows creator and he 
 very quickly and simply outlined the solution to the problem. 
 Thereafter I read his PhD thesis - one of the most informative 
 texts in computer science I have read and very well written.

 At the moment, there are lots of languages attempting to solve 
 the dynamic-static loop, being able to have features inherent 
 in dynamic programming languages, while keeping the safety and 
 performance that comes with a static compiled programming 
 language, and then doing so in a language that doesn't cause 
 your brain to bleed. 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: 
 http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/


I don't see any reason why D can't implement pandas DataFrames 
without needing to change the language at all
http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
It's just a lot of work.

The simplest I can think of is a struct containing a tuple that 
contains slices of equal length and an array of strings 
containing column names. You could have a specialization with a 
two-dimensional array (or ndslice).
Sep 07 2016
next sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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: 
 https://forum.dlang.org/thread/gdjaoxypicsxlfvzwbvt forum.dlang.org?page=1
 I then exchanged emails with Lucian, Sparrows creator and he 
 very quickly and simply outlined the solution to the problem. 
 Thereafter I read his PhD thesis - one of the most informative 
 texts in computer science I have read and very well written.

 At the moment, there are lots of languages attempting to solve 
 the dynamic-static loop, being able to have features inherent 
 in dynamic programming languages, while keeping the safety and 
 performance that comes with a static compiled programming 
 language, and then doing so in a language that doesn't cause 
 your brain to bleed. 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: 
 http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/


 I don't see any reason why D can't implement pandas DataFrames 
 without needing to change the language at all
 http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
 It's just a lot of work.

 The simplest I can think of is a struct containing a tuple that 
 contains slices of equal length and an array of strings 
 containing column names. You could have a specialization with a 
 two-dimensional array (or ndslice).


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 required but are not 
currently configured for your table. The choice you have is to 
have to modify the code or as scala does give programmers the 
ability to write their own interface to the type so that the it 
can be stored in their DataFrame. The best solution is that the 
data table is able to cope with arbitrary number of types which 
can be done in Sparrow.
Sep 07 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
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 required but are not 
 currently configured for your table. The choice you have is to 
 have to modify the code or as scala does give programmers the 
 ability to write their own interface to the type so that the it 
 can be stored in their DataFrame.


I think part of the difficulty is that you're thinking in terms 
of everything being dynamic. If all your data is statically typed 
in the first place, then I don't see what the issue is.

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 = oldFrame.addCol(newData);
So you just need to ensure that the data frame struct or class 
has an addCol method that returns a new frame with the correct 
type when you add a column.

I'm not familiar with Scala's data frames.


 The best solution is that the data table is able to cope with 
 arbitrary number of types which can be done in Sparrow.


D has support for an arbitrary number of types (tuple, variant, 
algebraic). It's just a matter of putting it together.

Anyway, given that Sparrow is still in its early stages, if you 
actually want to get some work done, D might be a better fit.

On Wednesday, 7 September 2016 at 20:52:26 UTC, data pulverizer 
wrote:

 p.s. it goes beyond just tables, ... having dynamic capability 
 in a static compiled language really does take computing to a 
 different place indeed.


There are some dynamic capabilities in D, such as 
variant/algebraic and Adam Ruppe's jsvar. I only wonder if you 
would lose performance if wanted something fully dynamic. A 
static approach is a good starting place.
Sep 07 2016
parent reply data pulverizer <data.pulverizer gmail.com> writes:
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 = oldFrame.addCol(newData);


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.


 ... I only wonder if you would lose performance if wanted 
 something fully dynamic. A static approach is a good starting 
 place.


Yes you would, which is why I see the hyper-meta route as being 
the potential solution to this issue.
Sep 07 2016
parent jmh530 <john.michael.hall gmail.com> writes:
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 still mutate values within the table. In this 
approach, it's only appending new columns (or inserting them or 
something) that requires a new variable. It shouldn't be an issue 
for adding rows, assuming the underlying table is made from 
slices. It might be possible to do this without creating a 
variable, but I haven't thought about it that carefully.

Moreover, if you're working with slices, then it's a reference 
type. This means that the new variable is not a copy of the old. 
It shouldn't take up much space.
Sep 07 2016
prev sibling parent data pulverizer <data.pulverizer gmail.com> writes:
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
 http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
 It's just a lot of work.

 The simplest I can think of is a struct containing a tuple that 
 contains slices of equal length and an array of strings 
 containing column names. You could have a specialization with a 
 two-dimensional array (or ndslice).


p.s. it goes beyond just tables, ... having dynamic capability in 
a static compiled language really does take computing to a 
different place indeed.
Sep 07 2016
prev sibling parent reply bachmeier <no spam.net> writes:
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 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 good libraries 
 for a lot of things.

 Nevertheless, the longer I've been using D, the more I agree 
 that there could be some improvements in D's error messages. 
 Andre had posted about the Sparrow language a while back
 https://forum.dlang.org/thread/ne3265$uef$1 digitalmars.com?page=1
 He liked their use of concepts. I think at a minimum it would 
 enable better error messages.


 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 with Rcpp that you can't do with D?
Sep 07 2016
next sibling parent data pulverizer <data.pulverizer gmail.com> writes:
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 ....
Sep 07 2016
prev sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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 with Rcpp that you can't do with D?


Sorry I'll correct myself again! Because R is a dynamic 
programming language, you could do things that you could not do 
in D, however they would be very inefficient. 
hyper-meta-programming takes this barrier away.
Sep 07 2016
parent bachmeier <no spam.net> writes:
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 time and I have been 
 looking for a better solution.


 What are you doing with Rcpp that you can't do with D?


 Sorry I'll correct myself again! Because R is a dynamic 
 programming language, you could do things that you could not do 
 in D, however they would be very inefficient. 
 hyper-meta-programming takes this barrier away.


I meant use a combination of R + D rather than R + C++. Any 
bottlenecks can be handled in D as easily as C++. However, if you 
want to go beyond what you can do with Rcpp, it's a different 
story.
Sep 07 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
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?
Sep 07 2016
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 16:21 +0000, Kagamin via Digitalmars-d-learn
wrote:

 On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder=C2=A0
 wrote:

=20
 The real problem though is the terrifying error message. I am=C2=A0
 having a hard time finding a way of pitching them to=C2=A0
 Pythonistas.


=20
 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.

I fear there is a confluence of disjoint subthreads happening here.
Probably my fault.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 08 2016
parent reply Kagamin <spam here.lot> writes:
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?
Sep 09 2016
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 2016-09-09 at 12:22 +0000, Kagamin via Digitalmars-d-learn
wrote:

 On Thursday, 8 September 2016 at 10:26:04 UTC, Russel Winder=C2=A0
 wrote:

=20

=20
 Do they use single assignment a lot?


=20
 Python has no notion of single assignment. Exactly the=C2=A0
 opposite, Python allows everything to be changed at any time.


=20
 Then you probably shouldn't pitch them alien concepts?


Or maybe they need those alien concepts. Consider Python now has type
signatures for functions and methods.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 10 2016
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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. However rdmd 20160627 begs to differ:

 run_checks.d(20): Error: template std.algorithm.iteration.map!(function
(TickDuration t) => to(t).total()).map cannot deduce function from argument
types !()(const(TickDuration[3])), candidates are:
 /usr/include/dmd/phobos/std/algorithm/iteration.d(450):       
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!Range))
 Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]

 and I have no idea just now why it is complaining, nor what to do to
 fix it.


Ok, I have it mostly compiling.

void run_mean() {}
void run_mode() {}
void run_stdDev() {}

void main() {
	import std.datetime;
	import std.algorithm : map;
	import std.conv;
	import std.array;
	
	const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
	const times = map!((TickDuration t) { return 
(to!Duration(t)).total!"seconds"; })(results[]);
	
	import std.stdio;
	foreach(v; times) {
		writeln(v);	
	}
}

However times really can't be const. Since times is an input range which 
gets modified as part of the iterations.

So what exactly do you want times to be? If you want an array .array 
from std.algorithm it which can be const. Either way there is something 
I'm missing as to why const is so important here.
Sep 07 2016
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 20:32 +1200, rikki cattermole via Digitalmars-d-
learn wrote:

=20


[=E2=80=A6]

 Ok, I have it mostly compiling.
=20
 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 level. But this turns out to be a non-
issue.


 void main() {
 	import std.datetime;
 	import std.algorithm : map;
 	import std.conv;
 	import std.array;


I am still not a fan of this import all symbols approach, like the map
import, I would do the same for the other modules' functions used.


 	const results =3D benchmark!(run_mean, run_mode, run_stdDev)(1);
 	const times =3D map!((TickDuration t) { return=C2=A0
 (to!Duration(t)).total!"seconds"; })(results[]);


It turns out my problem was here. See below.


 	import std.stdio;
 	foreach(v; times) {
 		writeln(v);=09
 	}
 }
=20
 However times really can't be const. Since times is an input range
 which=C2=A0
 gets modified as part of the iterations.


Indeed. I keep forgetting that ranges are use once mutable entities,
and there is no option. s/const/auto/ solves the problem, but the more
likely general solution is to retain the const and reify the array. But
it depends on usage, obviously.


 So what exactly do you want times to be? If you want an array .array=C2=


=A0

 from std.algorithm it which can be const. Either way there is
 something=C2=A0
 I'm missing as to why const is so important here.


In this case it isn't as you can't use a constant range. The problem I
am having is when I cannot use const or better immutable. I'm a single
assignment sort of person, but D ranges break all that orthodoxy.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 07 2016
prev sibling parent reply pineapple <meapineapple gmail.com> writes:
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

This topic motivated me to see if my map function worked with 
static arrays. Turns out that somehow I'd neglected to include a 
unit test, and it in fact failed.

Once I've had a chance to commit the couple-line fix, probably in 
a couple hours, this will be a valid program:

     import mach.range : map;
     import std.stdio : writeln;

     void main(){
         const(const(int)[3]) array = [1, 2, 3];
         auto mapped = array.map!(e => e + 1);
         mapped.front.writeln; // 2
         mapped[0].writeln; // 2
         // etc.
     }
Sep 07 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
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 range library does differently than phobos?
Sep 07 2016
parent reply pineapple <meapineapple gmail.com> writes:
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 stuff there. Do you mind giving a TL;DR 
 version of what your range library does differently than phobos?


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 to use any given module.

In terms of functionality, the single-biggest difference is that 
unlike phobos I don't treat arrays or any other collection 
directly as ranges; instead types may provide an `asrange` 
property returning a range that enumerates their contents. This 
architecture allows you to express HOFs as shown in that prior 
post, not having to worry about whether it's safe to treat the 
array itself as a range or whether you have to slice it.

Other significant differences include not requiring 
bidirectional, slicing, random-access ranges to also be saving 
("forward") ranges; (for the most part) supporting immutable 
elements in ranges; and a more clearly defined interface for what 
insertion and removal operations you may perform upon a range and 
how they are expected to behave. There are a few things phobos 
provides that I don't yet, but there's also a handful of things 
implemented in mach.range that aren't in phobos. (My personal 
favorite example of such is its small suite of PRNG 
implementations.)

Also: I just pushed the fix.
Sep 07 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
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 to use any given 
 module.

 In terms of functionality, the single-biggest difference is 
 that unlike phobos I don't treat arrays or any other collection 
 directly as ranges; instead types may provide an `asrange` 
 property returning a range that enumerates their contents. This 
 architecture allows you to express HOFs as shown in that prior 
 post, not having to worry about whether it's safe to treat the 
 array itself as a range or whether you have to slice it.

 Other significant differences include not requiring 
 bidirectional, slicing, random-access ranges to also be saving 
 ("forward") ranges; (for the most part) supporting immutable 
 elements in ranges; and a more clearly defined interface for 
 what insertion and removal operations you may perform upon a 
 range and how they are expected to behave. There are a few 
 things phobos provides that I don't yet, but there's also a 
 handful of things implemented in mach.range that aren't in 
 phobos. (My personal favorite example of such is its small 
 suite of PRNG implementations.)


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.

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 that when you say that asrange returns a range 
that enumerates the contents.
Sep 07 2016
next sibling parent reply pineapple <meapineapple gmail.com> writes:
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.

https://github.com/pineapplemachine/mach.d/tree/master/mach/range
Sep 07 2016
parent jmh530 <john.michael.hall gmail.com> writes:
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!
Sep 07 2016
prev sibling parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 2016-09-07 at 20:29 +0000, jmh530 via Digitalmars-d-learn
wrote:

=20


[=E2=80=A6]

 Are you familiar with Chapel at all? The language allows the user=C2=A0
 to specify a domain with an array, facilitating sparsity or=C2=A0
 arrays distributed across different machines. For some reason I=C2=A0
 was reminded of that when you say that asrange returns a range=C2=A0
 that enumerates the contents.


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 in. Given Chapel there is no need to look at
C++, D, Rust, Cython, etc.=C2=A0

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 08 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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 in. Given 
 Chapel there is no need to look at C++, D, Rust, Cython, etc.


I care about performance, but also about productivity. Chapel 
still has some ways to go on the latter. Also, they are still in 
the early stages of GPU support, I think.
Sep 08 2016
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 2016-09-08 at 13:09 +0000, jmh530 via Digitalmars-d-learn
wrote:

 On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder=C2=A0
 wrote:

=20
=20
 I am certainly hoping that Chapel will be the language to=C2=A0
 displace NumPy for serious computation in the Python-sphere.=C2=A0
 Given it's foundation in the PGAS model, it has all the=C2=A0
 parallelism needs, both cluster and local, built in. Given=C2=A0
 Chapel there is no need to look at C++, D, Rust, Cython, etc.


=20
 I care about performance, but also about productivity. Chapel=C2=A0
 still has some ways to go on the latter. Also, they are still in=C2=A0
 the early stages of GPU support, I think.


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, but then it isn't in
Python either.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 09 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
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, but then it 
 isn't in Python either.


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 
R/Python/Matlab because they typically already have the libraries 
that can do everything I need.
Sep 09 2016
parent Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Fri, 2016-09-09 at 14:20 +0000, jmh530 via Digitalmars-d-learn
wrote:

 [=E2=80=A6]
=20
 What I mean is that Chapel doesn't have a lot of libraries (also=C2=A0
 true for D, but things are getting better). If I'm going to do=C2=A0
 some analysis, it usually takes much less time for me to do it in=C2=A0
 R/Python/Matlab because they typically already have the libraries=C2=A0
 that can do everything I need.


This is very true: Python has the masses of things built on Python and
NumPy today that make things easy to work with. My feeling is though
that NumPy is not going to survive the next revolution in workstation
and performance laptop hardware. Unless it absorbs the Chapel (or X10)
PGAS model. The fastest way of doing this is to ditch the NumPy
implementation and exchange it for either Chapel or something Chapel
inspired.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 10 2016
prev sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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 in. Given 
 Chapel there is no need to look at C++, D, Rust, Cython, etc.


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 much a domain specific language. They have clearly given 
plenty of thought to distributed computing, parallelization and 
concurrency that could yield some very nice performance 
advantages. However Python's advantage is that it is a dynamic 
language and can act as a front end to algorithms written in 
C/C++ for instance as Google has done with TensorFlow. In the 
future it could even act as a front end to Chapel since they now 
have a C API.

However, I feel as if computer programming languages are still in 
this static-dynamic partnership, e.g. Python with C/C++, R and 
Fortran/C/C++. It means language overhead always maintaining code 
in more than one language and always having to amend your 
interface every time you change something in one or the other. In 
essence, nothing fundamentally different is happening with 
current new languages. I hate to sound like a broken record, but 
what Sparrow proposes is a unification in such a way that all 
kinds of overheads go away. Making something like that work with 
the principles of Sparrow would be a revolution in computing.
Sep 08 2016
parent reply Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 2016-09-08 at 14:39 +0000, data pulverizer via Digitalmars-d-
learn wrote:

 [=E2=80=A6]
=20
 I can see where you are coming from, I have taken a look at=C2=A0
 Chapel and high performance computing is their top priority. I=C2=A0
 think they hope that it will be the next Fortran, but I think it=C2=A0
 is very much a domain specific language. They have clearly given=C2=A0
 plenty of thought to distributed computing, parallelization and=C2=A0
 concurrency that could yield some very nice performance=C2=A0
 advantages. However Python's advantage is that it is a dynamic=C2=A0
 language and can act as a front end to algorithms written in=C2=A0
 C/C++ for instance as Google has done with TensorFlow. In the=C2=A0
 future it could even act as a front end to Chapel since they now=C2=A0
 have a C API.


Why write algorithms in C or C++ when you can do it in Chapel? The
point here is that Python folk should look to languages like Chapel and
not C, C++, or even D when they reach the limits of Python performance.

And yes I am trying to get PyChapel to run on Python 3 as well as
Python 2.


 However, I feel as if computer programming languages are still in=C2=A0
 this static-dynamic partnership, e.g. Python with C/C++, R and=C2=A0
 Fortran/C/C++. It means language overhead always maintaining code=C2=A0
 in more than one language and always having to amend your=C2=A0
 interface every time you change something in one or the other. In=C2=A0
 essence, nothing fundamentally different is happening with=C2=A0
 current new languages. I hate to sound like a broken record, but=C2=A0
 what Sparrow proposes is a unification in such a way that all=C2=A0
 kinds of overheads go away. Making something like that work with=C2=A0
 the principles of Sparrow would be a revolution in computing.


But how are they going to get traction?

Should we be giving up on D and switching to Sparrow?

Polyglots programmers tend to be better programmers. This is not
opinion, there is experimental evidence for this in the psychology of
programming literature.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Sep 09 2016
next sibling parent data pulverizer <data.pulverizer gmail.com> writes:
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 when the next great modelling idea comes along?"

Walter:

"D will absorb it"

Link to the youtube vid (https://youtu.be/WKRRgcEk0wg?t=2205)


 Polyglots programmers tend to be better programmers. This is 
 not opinion, there is experimental evidence for this in the 
 psychology of programming literature.


I certainly think that training programmers on lots of different 
programming languages and paradigms will produce better 
programmers on average. I guess the analogy is in multi-lingual 
language training for children. However this does not affect my 
original point on the overhead caused by constantly switching 
languages in development and the host of benefits that would come 
from making Sparrow's programming model work.
Sep 09 2016
prev sibling parent deXtoRious <dextorious gmail.com> writes:
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 else), you're attached to a C++ 
codebase/libraries (calling C code is trivial, C++ far from it 
generally) or you need the low level flexibility afforded by 
C/C++. Personally, I probably won't consider Chapel for serious 
projects until at least the first point is solved.

Of course, there's also a host of subjective reasons -- 
attachment to more familiar languages, difficulty of selling new 
languages to coworkers, preference for larger communities, etc. 
All of those take time to overcome.
Sep 09 2016