Maybe you could port embed Halide ( http://halide-lang.org/ ) in
D?
I'm joking as it must be hard work to port this, but I find
super-impressive that they were able to separate the algorithm
from the optimizations schedules (a la SQL) and still being
able to have good performances..
renoX
On Monday, 2 June 2014 at 22:11:15 UTC, ponce wrote:
[cut]
- normal arithmetic operator throw a trap on integer overflow
(!). This must be incredibly slow.
Well, Apple make their own CPU, so maybe they plan to add 'trap
on integer overflow' operation to the CPU?
The most difficult part is
On Thursday, 4 December 2014 at 06:24:35 UTC, Suminda Dharmasena
wrote:
What I am saying is, if it is introduced in D it should be more
flexible than Rust.
This isn't the first post of you who makes me think that you're a
troll but I'll answer anyway.
Having types for static memory safety
On Saturday, 20 December 2014 at 14:16:05 UTC, bearophile wrote:
When you use UFCS chains there are many coding patterns that
probably are hard to catch for the compiler, but are easy to
optimize very quickly:
[cut]
.reverse.reverse = id
.reverse.reverse is a coding pattern??
;-)
renoX
On Thursday, 20 August 2015 at 16:22:22 UTC, Jonathan M Davis
wrote:
I really don't mind NaN.
Well with silent NaN you have 'x == x' is false which means all
the generic algorithms (silently) fail.
It really doesn't cause problems normally. The problem with
floating point values is
On Wednesday, 19 August 2015 at 14:01:34 UTC, Jonathan M Davis
wrote:
Yeah. I guess that the floating point stuff doesn't quite work
that way thanks to NaN. *sigh* I hate floating point numbers.
Sometimes, you have no choice other than using them, but man
are they annoying.
- Jonathan M
