Rainer Deyke wrote:
Don wrote:
Ah. The important thing that makes this work is that the global FP state
has a clearly defined default. (round-to-nearest, full precision, no
floating point exceptions enabled). Part of the implicit contract of
calling a 'memoisable pure' function is that the
Don wrote:
Ah. The important thing that makes this work is that the global FP state
has a clearly defined default. (round-to-nearest, full precision, no
floating point exceptions enabled). Part of the implicit contract of
calling a 'memoisable pure' function is that the global FP state is in
Rainer Deyke wrote:
Don wrote:
Rainer Deyke wrote:
Don't forget that uses floating point is a transitive property. Any
pure function that calls a pure-but-unmemoisable function is itself
pure-but-unmemoisable.
This is incorrect.
Then I must have misunderstood your proposal. Either you did
Walter Bright wrote:
Brad Roberts wrote:
Walter Bright wrote:
strlen() is safe, while strcpy() and printf() are not.
You sure? Does running beyond the bounds of the array if there's no null
termination count as safe some how? :)
Yes. Memory safety is defined as being free of memory
Don wrote:
The thing you missed is that the non-memoisable pure functions can only
read the global state.
No, I saw that. But if a (pure) function calls another (pure) function
that depends on global state, then the first (pure) function also
depends on global state.
int global_state;
pure
Stewart Gordon wrote:
Don wrote:
snip
Floating point settings are just another case of the same thing,
except that currently violations in relation to the former are allowed.
There's a fundamental difference between them: the floating point
settings are a hardware feature and it is
Walter Bright wrote:
bearophile wrote:
An important purpose of a not bug-prone language is remove as many
undefined situations as possible.
That's right.
If you add that to D2 specs, can
the compiler catch at compile time all cases of violations to that
rule?
Unlikely. But that has to be
Don wrote:
The pure function memoisation issue:
Certain functions may be marked as 'pure', even though they use floating
point (and are therefore dependent on the FP state). The compiler must
be able to prevent memoisation of those functions in cases where the
rounding mode may have changed.
Don wrote:
Walter Bright wrote:
bearophile wrote:
An important purpose of a not bug-prone language is remove as many
undefined situations as possible.
That's right.
If you add that to D2 specs, can
the compiler catch at compile time all cases of violations to that
rule?
Unlikely. But
Rainer Deyke wrote:
Don wrote:
The pure function memoisation issue:
Certain functions may be marked as 'pure', even though they use floating
point (and are therefore dependent on the FP state). The compiler must
be able to prevent memoisation of those functions in cases where the
rounding mode
Walter Bright:
Yes, all the C functions will have to be gone through and separated.
strlen() is safe, while strcpy() and printf() are not.
For some of the removed functions better C-like ones can be provided:
http://www.ddj.com/cpp/214502214
Bye,
bearophile
bearophile wrote:
Walter Bright:
Yes, all the C functions will have to be gone through and separated.
strlen() is safe, while strcpy() and printf() are not.
For some of the removed functions better C-like ones can be provided:
http://www.ddj.com/cpp/214502214
Bye,
bearophile
Just use D
Don Wrote:
I've provided very simple solutions for both of these. I'm getting
pretty irritated that people are acting as though these are difficult
problems and trying to come up with convoluted solutions. Impose minimal
semantics and it becomes trivial.
FWIW, I've liked your proposals,
On Mon, 14 Sep 2009 16:44:48 +0400, Jason House
jason.james.ho...@gmail.com wrote:
Don Wrote:
I've provided very simple solutions for both of these. I'm getting
pretty irritated that people are acting as though these are difficult
problems and trying to come up with convoluted solutions.
Walter Bright wrote:
Don wrote:
We could get close, I think. We could catch all violations in SafeD.
Disallow calling core.stdc.fenv functions from inside SafeD modules,
and provide an RAII object in std.math for changing the rounding mode.
Actually there's probably a few other C functions
Brad Roberts wrote:
Walter Bright wrote:
strlen() is safe, while strcpy() and printf() are not.
You sure? Does running beyond the bounds of the array if there's no null
termination count as safe some how? :)
Yes. Memory safety is defined as being free of memory corruption errors.
Simply
Don wrote:
Rainer Deyke wrote:
Don't forget that uses floating point is a transitive property. Any
pure function that calls a pure-but-unmemoisable function is itself
pure-but-unmemoisable.
This is incorrect.
Then I must have misunderstood your proposal. Either you did a poor job
of
Walter Bright wrote:
Don wrote:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline asm), the rounding mode used
On 2009-09-13 06:14:02 -0400, Don nos...@nospam.com said:
double foo() {
return x() + y();
}
x() and y() can use whichever rounding modes they like, and if they are
impure, they can affect one another, but under this proposal, they
cannot change the meaning of the addition inside foo().
Michel Fortin wrote:
On 2009-09-13 06:14:02 -0400, Don nos...@nospam.com said:
double foo() {
return x() + y();
}
x() and y() can use whichever rounding modes they like, and if they
are impure, they can affect one another, but under this proposal, they
cannot change the meaning of the
Walter Bright wrote:
Don wrote:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline asm), the rounding mode used
Don wrote:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline asm), the rounding mode used for
subsequent
Don wrote:
snip
Floating point settings are just another case of the same thing,
except that currently violations in relation to the former are allowed.
There's a fundamental difference between them: the floating point
settings are a hardware feature and it is IMPOSSIBLE to avoid them.
Walter Bright:
Don:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline asm), the rounding mode used
bearophile wrote:
An important purpose of a not bug-prone language is remove as many
undefined situations as possible.
That's right.
If you add that to D2 specs, can
the compiler catch at compile time all cases of violations to that
rule?
Unlikely. But that has to be weighed against the
Don wrote:
snip
LISTING ONE:
real x = foo(1) + foo(2) + foo(3);
LISTING TWO:
real x1 = foo(1);
real x2 = foo(2);
real x3 = foo(3);
real x = x1 + x2 + x3;
In C and C++ (and currently in D), they are NOT equivalent!
foo() is allowed to change the floating-point rounding mode, so it could
Don wrote:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline asm), the rounding mode used for
subsequent
A quiz:
Conside a function
real foo() {}
This is not pure, so that it may side-effects, but even so, are listings
one and two equivalent?
LISTING ONE:
real x = foo(1) + foo(2) + foo(3);
LISTING TWO:
real x1 = foo(1);
real x2 = foo(2);
real x3 = foo(3);
real x = x1 + x2 + x3;
In C and
Rainer Deyke wrote:
Don wrote:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits.
Even if that function is called 'fesetround'?
Obviously not. In fact, I'd hope to even disallow
#ponce wrote:
Why not imposing a rounding mode (ex : toward minus infinity) ?
And then disallowing to change it in assembly.
You can't impose a rounding mode in a system language: rounding mode is
a crucial feature in a few rare but very important cases. The trick is
to allow those cases
#ponce alil...@gmail.com wrote in message
news:h8adr2$23p...@digitalmars.com...
Why not imposing a rounding mode (ex : toward minus infinity) ?
And then disallowing to change it in assembly.
I mean, you can still do :
round(x) as floor(x + 0.5L)
ceil(x) as floor(x + 1.0L)
Iit would
On 2009-09-10 04:24:38 -0400, Don nos...@nospam.com said:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example, by the use of inline
Michel Fortin wrote:
On 2009-09-10 04:24:38 -0400, Don nos...@nospam.com said:
PROPOSAL:
Change the spec by adding the line to float.html:
If the floating-point rounding mode is changed within a function, it
must be restored before the function exits. If this rule is violated
(for example,
#ponce wrote:
Why not imposing a rounding mode (ex : toward minus infinity) ?
And then disallowing to change it in assembly.
I mean, you can still do :
round(x) as floor(x + 0.5L)
ceil(x) as floor(x + 1.0L)
Iit would cost some precision with large floating-point number, but not much
34 matches
Mail list logo
