Should this semantics extend to array bounds checking, i.e. after
the statement
foo[5] := 0;
can the optimizer assume that foo.length >= 6 ?
On Wednesday, 6 August 2014 at 13:31:54 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 August 2014 at 12:41:16 UTC, Artur Skawina via
Digitalmars-d wrote:
The compiler can /assume/ that the condition never fails.
Hence, it does
not need to generate any code to check that the assumption is
vali
On Wednesday, 6 August 2014 at 15:29:13 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 August 2014 at 15:02:10 UTC, Matthias Bentrup
wrote:
is equivalent to
while(running) {
...don't assign to running, don't break...
}
assume(!running);
You have to prove termination to get there? Plain
On Wednesday, 6 August 2014 at 17:08:18 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 August 2014 at 17:03:44 UTC, Marc Schütz wrote:
I guess we're talking past each other. You were saying that
Hoare logic doesn't work with non-terminating loops, and I was
responding that there was no non-ter
On Wednesday, 6 August 2014 at 18:51:05 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 August 2014 at 17:59:06 UTC, Marc Schütz wrote:
The crux is the axiom that is being defined. When you write
`assume(condition)`, the axiom is not:
"`condition` is true."
but:
"When control flow reac
On Thursday, 7 August 2014 at 03:51:02 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 6 August 2014 at 21:33:35 UTC, Timon Gehr wrote:
On 08/06/2014 11:18 PM, Matthias Bentrup wrote:
Ah, I had a different understanding of assume, i.e. placing an
assume(A) at some point in code adds not the axio
On Thursday, 7 August 2014 at 06:32:18 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 7 August 2014 at 05:41:22 UTC, Matthias Bentrup
wrote:
If assume is independent of control flow, then clearly this
cannot be related to assert.
Well, both assume and assert are "independent" of control flow
si
On Thursday, 7 August 2014 at 08:35:21 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 7 August 2014 at 08:12:23 UTC, Matthias Bentrup
wrote:
So the D function (note that "a" is constant)
int silly() {
enum int a = 1;
if( a == 2 ) {
assert( a == 2 );
}
return a;
}
has undefined semantics (
On Wednesday, 12 November 2014 at 12:30:15 UTC, ketmar via
Digitalmars-d wrote:
On Wed, 12 Nov 2014 12:05:25 +
thedeemon via Digitalmars-d wrote:
On Wednesday, 12 November 2014 at 11:05:11 UTC, ketmar via
Digitalmars-d wrote:
> 734003200
> address space" (yes, i'm on 32-bit system, GNU/
On Sunday, 16 November 2014 at 16:02:20 UTC, FrankLike wrote:
It means where you have uint x = arr.length you should have
had size_t x = arr.length from the very beginning.
I test it :
module aatest;
import std.stdio;
import std.datetime;
import std.conv;
size_t[string] aa;
void ada()
{
On Tuesday, 18 November 2014 at 07:04:50 UTC, FrankLike wrote:
Don't profile with out optimzation.
Add "-O -inline -release -boundscheck=off" to your dmd
arguments.
I mean projects moved from x86 to x64, 'cast(int)length ' is
better than 'size_t i=(something).length '.
I think the reason
On Wednesday, 19 November 2014 at 10:03:35 UTC, Don wrote:
On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
Am Tue, 18 Nov 2014 15:01:25 +
schrieb "Frank Like" <1150015...@qq.com>:
> but now ,'int' is enough for use,not huge and not
> small,only enough.
> 'int' is easy to
On Wednesday, 19 November 2014 at 14:04:16 UTC, Don wrote:
No. The point is to get correct semantics. Unsigned types do
not have the correct semantics. Signed types do.
In D both signed and unsigned integers have defined wrapping
semantincs. In C++ signed integers are allowed to format your
On Wednesday, 19 November 2014 at 20:40:53 UTC, bearophile wrote:
Andrei Alexandrescu:
There are related bugs in Java too, e.g. I remember one in
binary search where (i + j) / 2 was wrong because of an
overflow.
This is possible in D too.
Also, Java does have a package for unsigned integer
On Thursday, 20 November 2014 at 13:26:23 UTC, FrankLike wrote:
auto x = foo();
auto y = bar();
auto z = baz();
if (x - y > z) { ... }
This might be a bug, if one of these functions returns an
unsigned
type. Good luck finding that. Note that if all functions
return
unsigned, there isn't
On Friday, 21 November 2014 at 08:54:40 UTC, Daniel Murphy wrote:
"Walter Bright" wrote in message
news:m4mu0q$sc5$1...@digitalmars.com...
> Zero, on the other hand, is usually quite near the typical
> array lengths and
> differences in lengths.
That's true, that's why they are detected soo
On Friday, 21 November 2014 at 15:36:02 UTC, Don wrote:
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright
wrote:
On 11/20/2014 7:11 PM, Walter Bright wrote:
On 11/20/2014 3:25 PM, bearophile wrote:
Walter Bright:
If that is changed to a signed type, then you'll have a
same-only-diff
On Monday, 24 November 2014 at 16:45:35 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via
Digitalmars-d wrote:
this *is* overflow. D just has overflow result defined.
So it basically is and isn't modular arithmetic at the same
time?
Overflow is part of
On Monday, 24 November 2014 at 17:55:06 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 24 November 2014 at 17:12:31 UTC, Matthias Bentrup
wrote:
Overflow is part of modular arithmetic. However, there is no
signed and unsigned modular arithmetic, or, more precisely,
they
are the same.
Would you s
On Saturday, 20 December 2014 at 14:16:05 UTC, bearophile wrote:
If the filtering and mapping functions are pure nothrow:
.map.filter => .filter.map
I think that one doesn't work.
On Wednesday, 24 December 2014 at 16:10:05 UTC, Ola Fosheim
Grøstad wrote:
And we are not talking yesterdays C++, but next gen x86 C++.
That means 4000 intrinsics, auto-vectorization and possibly
whole program optimization...
Do you propose any changes to the language syntax for
auto-vectoriza
On Monday, 12 January 2015 at 13:54:18 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 12 January 2015 at 13:25:26 UTC, Adam D. Ruppe wrote:
On Monday, 12 January 2015 at 11:43:26 UTC, Ola Fosheim
Grøstad wrote:
Does this mean that D will get fast EH?
It is fast already...
What makes you say th
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday, 23 January 2015 at 08:58:11 UTC, Ola Fosheim Grøstad
wrote:
How about banning GC-allocation of classes with destructors?
Uh... what? ^__^
Maybe just ban classes altogether then?
No, don't ban them, that will break to much
On Friday, 23 January 2015 at 21:00:08 UTC, Steven Schveighoffer
wrote:
On 1/23/15 3:40 PM, deadalnix wrote:
On Friday, 23 January 2015 at 13:12:44 UTC, Steven
Schveighoffer wrote:
On 1/23/15 8:05 AM, Matthias Bentrup wrote:
On Friday, 23 January 2015 at 10:53:54 UTC, aldanor wrote:
On Friday,
On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
On 6/18/2014 12:05 AM, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright
wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not
allowed and
On Wednesday, 28 January 2015 at 09:51:09 UTC, Ola Fosheim
Grøstad wrote:
Some languages keep track of parent-child relationships, you
can do it in the typing even. Nevertheless, children ought to
be alive when the parent dies... If the language cannot provide
this, then provide another mechani
On Tuesday, 10 February 2015 at 20:37:16 UTC, Walter Bright wrote:
On 2/9/2015 11:07 PM, deadalnix wrote:
On Tuesday, 10 February 2015 at 07:01:18 UTC, Jacob Carlborg
wrote:
DMD will complain about the second example if warnings are
enabled.
Ok I think that answer the question.
The thing is
On Tuesday, 17 February 2015 at 12:41:51 UTC, Marc Schütz wrote:
On Tuesday, 17 February 2015 at 09:19:55 UTC, Tobias Pankrath
wrote:
On Tuesday, 17 February 2015 at 07:24:43 UTC, Jonathan Marler
wrote:
Relaxing the definition of @nogc to exclude exceptions could
be an acceptable compromise.
On Tuesday, 17 February 2015 at 17:38:20 UTC, Jonathan Marler
wrote:
The reason you can't keep the "thrower's" stack memory around
for the exception handler is because the exception handler may
need that memory. Once the exception is thrown the stack is
unwound to the function that has the exc
On Tuesday, 17 February 2015 at 18:30:24 UTC, Jonathan Marler
wrote:
I thought of the same thing but then realized that it would be
impossible to ensure that the catch block wouldn't stomp on
that memory.
The catcher wouldn't stomp any more on the thrower's memory than
a function stomps on th
On Tuesday, 17 February 2015 at 20:48:07 UTC, Jonathan Marler
wrote:
That would work if you didn't have to unwind the stack but
unfortunately you do. The catch block exists in the context of
the function it is written in. That means it assumes the stack
pointer and stack variables are all in
On Wednesday, 18 February 2015 at 08:13:35 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 18 February 2015 at 00:54:37 UTC, Chris Williams
wrote:
I didn't mean it as a solution. As said, I was just looking
for an intro to the topic, so that I (and others) could
meaningfully contribute or at leas
On Monday, 23 February 2015 at 12:30:55 UTC, Russel Winder wrote:
On Mon, 2015-02-23 at 19:50 +1000, Manu via Digitalmars-d wrote:
O[…]
This is going to sound really stupid... but do people actually
use
exceptions regularly?
I've never used one. When I encounter code that does, I just
find it
When a function makes/destroys multiple references to an object
it should always be safe to coalesce all AddRefs into the first
AddRef and all Releases to into the last Release call.
This could be a small performance win, but opAddRef/opRelease
would need the count as argument or maybe as temp
On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei
Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
This is obviously much better, Andrei.
I think an alternative s
On Saturday, 1 April 2017 at 13:34:58 UTC, Andrei Alexandrescu
wrote:
Walter and I discussed the following promising setup:
Use "throw new scope Exception" from @nogc code. That will
cause the exception to be allocated in a special stack-like
region.
If the catching code uses "catch (scope E
On Tuesday, 19 May 2015 at 05:16:48 UTC, Andrei Alexandrescu
wrote:
[...], but it wrongly returns true for x == 0.
When we're talking about modulo 2^n arithmetic, 0 is in fact a
power of two.
Proof: 2^n mod 2^n == 0.
I think you can make the over/underflow at zero work in your
favor:
bool isPowerOf2(uint x)
{
return (x & -x) > (x - 1);
}
Interestingly dmd computes the a/b with SSE instructions if the
result is cast to int, uint or long, but uses x87 instructions
for the division if the result is cast to ulong.
Can I use these allocators in @nogc code too ?
On Friday, 3 July 2015 at 08:09:11 UTC, Robert burner Schadek
wrote:
On Friday, 3 July 2015 at 02:17:59 UTC, Timon Gehr wrote:
On 07/03/2015 04:17 AM, Timon Gehr wrote:
Bitwise are no math operations, these are CS operations
What does that even mean?
That there are no bitwise operations in
On Friday, 17 July 2015 at 09:13:13 UTC, Daniel N wrote:
On Friday, 17 July 2015 at 08:57:26 UTC, Marc Schütz wrote:
On Thursday, 16 July 2015 at 15:50:15 UTC, Andrei Alexandrescu
wrote:
On 7/15/15 8:49 PM, Mike wrote:
1. "AliasSeq" is no good as evident from the first post that
started
this
On Friday, 14 August 2015 at 09:20:14 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 14 August 2015 at 08:03:34 UTC, Walter Bright wrote:
1. 'real' has enough precision to hold 64 bit integers.
Except for the lowest negative value…
(it has only 63 bits + floating point sign bit)
actually the x8
On Monday, 24 August 2015 at 16:52:54 UTC, Márcio Martins wrote:
I'm posting this here for visibility. This was silently
corrupting our data, and might be doing the same for others as
well.
import std.stdio;
void main() {
double x = 1.2;
writeln(cast(ulong)(x * 10.0));
double y = 1.2 * 1
On Tuesday, 25 August 2015 at 15:19:41 UTC, Márcio Martins wrote:
If you compile it with *GDC* it works fine. If you compile a
port with clang, gcc or msvc, it works right as well. I suspect
it will also work fine with LDC.
The same program "fails" in gcc too, if you use x87 math. Usually
C
On Monday, 21 March 2016 at 11:50:06 UTC, Timothee Cour wrote:
On Mon, Mar 21, 2016 at 4:34 AM, Nick Treleaven via
Digitalmars-d < digitalmars-d@puremagic.com> wrote:
On 14/03/2016 11:32, thedeemon wrote:
filter_map : ('a -> 'b option) -> 'a t -> 'b t
"filter_map f e returns an enumeration
On Tuesday, 26 April 2016 at 08:12:02 UTC, Dominikus Dittes
Scherkl wrote:
On Monday, 25 April 2016 at 22:42:38 UTC, deadalnix wrote:
x & -x is the smallest power of 2 that divides x. Basically,
if x = 1000 , x & -x = 1000 . This is easy to proves
considering -x = ~x + 1 .
Now, x >> 1
If you try to make compile-time FP math behave exactly like
run-time FP math, you'd not only have to use the same precision
in the compiler, but also the same rounding mode, denormal
handling etc., which can be changed at run time
(http://dlang.org/phobos/core_stdc_fenv.html), so the exact same
On Wednesday, 18 May 2016 at 14:29:42 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 18 May 2016 at 12:27:38 UTC, Ola Fosheim Grøstad
wrote:
And yes, half-precision is only 10 bits.
Actually, it turns out that the mantissa is 11 bits. So it
clearly plays louder than other floats. ;-)
The man
On Wednesday, 8 June 2016 at 03:19:18 UTC, Jack Stouffer wrote:
On Wednesday, 8 June 2016 at 03:10:32 UTC, Eugene Wissner wrote:
In D some very important things like exceptions depend on GC.
This is a common misconception. Exceptions do not have to use
the GC, they just often are. All you hav
On Sunday, 25 October 2015 at 19:37:32 UTC, Iakh wrote:
Is it optimal and how do you implement this stuf?
I think it's better to use PMOVMSKB to avoid storing the PCMPEQB
result in memory and you need only one BSF instruction.
On Friday, 13 November 2015 at 09:33:51 UTC, John Colvin wrote:
unsigned: f(v) = v mod 2^n - 1
signed: f(v) = ((v + 2^(n-1)) mod (2^n - 1)) - 2^(n-1)
I guess you meant mod 2^n in both cases...
If you look at how Mathematics deals with this issue, there is
simply no signed or unsigned arithmet
On Friday, 11 December 2015 at 05:25:03 UTC, Shriramana Sharma
wrote:
https://en.wikipedia.org/wiki/IEEE_floating_point#Roundings_to_nearest says
that IEEE 754 provides two options for rounding to nearest: ties to even and
ties away from zero.
However, under
https://github.com/D-Programming-L
On Thursday, 21 January 2016 at 07:43:13 UTC, tsbockman wrote:
On Thursday, 21 January 2016 at 01:49:27 UTC, Timon Gehr wrote:
It only works because compile-time introspection is
ill-defined though. I don't expect it to keep working
indefinitely.
That aspect can easily be replaced by __LINE__
On Saturday, 2 July 2016 at 20:30:03 UTC, Walter Bright wrote:
On 7/2/2016 1:17 PM, Andrei Alexandrescu wrote:
So what's the fastest way to figure that an integral is
convertible to a
floating point value precisely (i.e. no other integral
converts to the same
floating point value)? Thanks! --
On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright
wrote:
The limitations are deliberate based on the idea that
comparison operators need to be consistent and predictable, and
should have a close relationship to the mathematical meaning of
the operators.
In Mathematics the compari
On Thursday, 29 September 2016 at 18:38:42 UTC, Jonathan M Davis
wrote:
Then you could always do something like a.myOp!"<"(b) and
a.myOp!">="(b) if you still want to have the operator in there
somewhere. You can name the functions whatever you want. You
just can't use overloaded operators for
On Tuesday, 11 October 2016 at 04:05:47 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 03:58:59 UTC, Andrei
Alexandrescu wrote:
On 10/10/16 11:00 PM, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei
Alexandrescu wrote:
[...]
If you want to skip a byte it's easy
On Tuesday, 11 October 2016 at 14:24:56 UTC, Andrei Alexandrescu
wrote:
On 10/11/2016 03:30 AM, Matthias Bentrup wrote:
A branch-free version:
void popFront4(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
s = s.ptr[ch
On Tuesday, 11 October 2016 at 15:01:47 UTC, Andrei Alexandrescu
wrote:
On 10/11/2016 10:49 AM, Matthias Bentrup wrote:
void popFrontAsmIntel(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
if (c < 0x80) {
s = s[1 .. $];
} else {
uint l = void;
asm pure nothrow @nogc
On Wednesday, 12 October 2016 at 09:23:53 UTC, Stefan Koch wrote:
On Wednesday, 12 October 2016 at 08:56:59 UTC, Matthias Bentrup
wrote:
[...]
All three are slower than baseline, for my test-case.
What did you test it against.
The blns.txt file mentioned upthread.
On Friday, 14 October 2016 at 15:42:22 UTC, David Nadlinger wrote:
On Friday, 14 October 2016 at 13:07:10 UTC, Johan Engelen wrote:
On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat
wrote:
- this pointer is aligned to N bytes
- this pointer doesn't alias with this pointer
Do you m
On Sunday, 23 October 2016 at 23:17:28 UTC, Stefam Koch wrote:
On Sunday, 23 October 2016 at 19:59:16 UTC, Minas Mina wrote:
On Sunday, 23 October 2016 at 13:04:30 UTC, Stefam Koch wrote:
Hi Guys,
while brushing up on my C and algorithm skills, accidently
created a version of fibbonaci which
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?
I would prefer the syntax
if( (int i = someFunc()) >= 0 )
{
// use i
}
as this matches the already existing assignment express
On Tuesday, 8 November 2016 at 12:56:10 UTC, Johan Engelen wrote:
On Monday, 7 November 2016 at 16:48:55 UTC, John Colvin wrote:
[...]
This reminds me of an LLVM presentation by Chandler, mentioning
that passing by reference may hamper the optimization of code
(because memory becomes involve
65 matches
Mail list logo
