Consider this code:
double add(double x, double y) {
return x + y;
}
Is this code pure? Is it nothrow?
Technically, it isn't. If you change the floating-point rounding mode on
the processor, you get a different result for exactly the same inputs.
If you change the floating-point traps, it co
On Fri, 13 Mar 2009 13:52:08 +0300, Don wrote:
Consider this code:
double add(double x, double y) {
return x + y;
}
Is this code pure? Is it nothrow?
Technically, it isn't. If you change the floating-point rounding mode on
the processor, you get a different result for exactly the same in
Denis Koroskin wrote:
On Fri, 13 Mar 2009 13:52:08 +0300, Don wrote:
Consider this code:
double add(double x, double y) {
return x + y;
}
Is this code pure? Is it nothrow?
Technically, it isn't. If you change the floating-point rounding mode
on the processor, you get a different result f
While it's a good suggestion, I think there's a fundamental problem with
it. Suppose a function in the floatingpoint module calls foo() in a
non-floatingpoint module which calls std.math.sin(x). std.math.sin(x) is
marked as "pure" in a non-floatingpoint module. So, inside foo(), it is
assuming
Don wrote:
Extend the parametrized module declaration to include something like
module(system, floatingpoint)
as well as
module(system).
Is compiler-determined memoization a confirmed feature in a near
release? If not, then it doesn't much matter.
Walter Bright wrote:
> While it's a good suggestion, I think there's a fundamental problem with
> it. Suppose a function in the floatingpoint module calls foo() in a
> non-floatingpoint module which calls std.math.sin(x). std.math.sin(x) is
> marked as "pure" in a non-floatingpoint module. So, ins
Walter Bright Wrote:
> While it's a good suggestion, I think there's a fundamental problem with
> it. Suppose a function in the floatingpoint module calls foo() in a
> non-floatingpoint module which calls std.math.sin(x). std.math.sin(x) is
> marked as "pure" in a non-floatingpoint module. So,
Jason House wrote:
Walter Bright Wrote:
While it's a good suggestion, I think there's a fundamental problem
with it. Suppose a function in the floatingpoint module calls foo()
in a non-floatingpoint module which calls std.math.sin(x).
std.math.sin(x) is marked as "pure" in a non-floatingpoint m
Walter Bright wrote:
While it's a good suggestion, I think there's a fundamental problem with
it. Suppose a function in the floatingpoint module calls foo() in a
non-floatingpoint module which calls std.math.sin(x). std.math.sin(x) is
marked as "pure" in a non-floatingpoint module. So, inside f
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that the
rounding mode is back to normal. You're saying that you don't care about
the status flags. So it's your own fault if you get surprising result
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't care
about the status flags. So it's your own fault if you
Don wrote:
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't
care about the status flags. So it's your own
Don wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't
care about the status flags. So it
On 2009-03-14 02:45:27 -0400, Walter Bright said:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't care
about the status flags
Walter Bright wrote:
Don wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call
a non-floatingpoint module, it's your responsibility to make sure
that the rounding mode is back to normal. You're saying that you
don't care about t
Michel Fortin wrote:
On 2009-03-14 02:45:27 -0400, Walter Bright
said:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't
care
Walter Bright wrote:
Don wrote:
The math functions need to work for any rounding mode, not just the
default mode. They also set the status flags correctly. In fact, they
are almost the only functions where this matters!
Ok, then std.math functions cannot be pure in either your or my
proposal
Don wrote:
The math functions need to work for any rounding mode, not just the
default mode. They also set the status flags correctly. In fact, they
are almost the only functions where this matters!
Ok, then std.math functions cannot be pure in either your or my
proposal, so I'm not seeing th
Andrei Alexandrescu wrote:
1. Is it usual to change the FP flags in an application multiple times,
or not? (I never changed them, so please be easy on me.)
Given a complex calculation, one might want to know how sensitive the
result is to roundoff error. Calculating this exactly can be a daunt
Walter Bright wrote:
> While it's a good suggestion, I think there's a fundamental problem with
> it. Suppose a function in the floatingpoint module calls foo() in a
> non-floatingpoint module which calls std.math.sin(x). std.math.sin(x) is
> marked as "pure" in a non-floatingpoint module. So, insi
Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> 1. Is it usual to change the FP flags in an application multiple
>> times, or not? (I never changed them, so please be easy on me.)
>
> Given a complex calculation, one might want to know how sensitive the
> result is to roundoff error. Calculat
Walter Bright wrote:
Don wrote:
The math functions need to work for any rounding mode, not just the
default mode. They also set the status flags correctly. In fact, they
are almost the only functions where this matters!
Ok, then std.math functions cannot be pure in either your or my
proposal
Don wrote:
Walter Bright wrote:
Don wrote:
The math functions need to work for any rounding mode, not just the
default mode. They also set the status flags correctly. In fact, they
are almost the only functions where this matters!
Ok, then std.math functions cannot be pure in either your or
Let's say we have A which is in a floatingpoint module, B which is in a
non-floatingpoint module and C which is marked pure in a
non-floatingpoint module:
-
module A(floatingpoint);
void a()
{
set mode;
b();
restore mode;
}
module B;
Walter Bright wrote:
Let's say we have A which is in a floatingpoint module, B which is in a
non-floatingpoint module and C which is marked pure in a
non-floatingpoint module:
-
module A(floatingpoint);
void a()
{
set mode;
b();
restore mode;
}
-
Joel C. Salomon:
> On the 754r mailing list, the HPC crowd was *very* insistent that static
> modes be explicitly in the standard.
Because in technology lot of things aren't determined on technological merits,
but by politics, money and power. Sometimes behind some of the best things you
can fin
Don wrote:
A has called a function in B. B is not a floatingpoint module, so b()
can only be called when the mode is set back to the default. a()
violates this contract, so a() is incorrect. There's nothing wrong with
b() or c(). If a() wants to call b(), it needs to restore the mode
first; or
bearophile wrote:
> Joel C. Salomon:
>> On the 754r mailing list, the HPC crowd was *very* insistent that static
>> modes be explicitly in the standard.
>
> Because in technology lot of things aren't determined on technological
> merits, but by politics, money and power. Sometimes behind some o
Sun, 15 Mar 2009 13:50:07 -0700, Walter Bright wrote:
> Don wrote:
>> Something interesting about my proposal is that although it is motivated
>> by the purity problem, that's simply a rule for the compiler -- the
>> rules for programmers do not involve purity at all.(See my other post).
>> Do
Sergey Gromov wrote:
Sun, 15 Mar 2009 13:50:07 -0700, Walter Bright wrote:
Don wrote:
Something interesting about my proposal is that although it is motivated
by the purity problem, that's simply a rule for the compiler -- the
rules for programmers do not involve purity at all.(See my other p
Walter Bright wrote:
Don wrote:
A has called a function in B. B is not a floatingpoint module, so b()
can only be called when the mode is set back to the default. a()
violates this contract, so a() is incorrect. There's nothing wrong
with b() or c(). If a() wants to call b(), it needs to resto
On 2009-03-16 04:03:01 -0400, Don said:
In Don's proposal, the following is legal:
-
module A(floatingpoint);
pure void a()
{
set mode;
b();
restore mode;
}
module B(floatingpoint);
pure void b()
{
do stuff;
}
---
Michel Fortin wrote:
On 2009-03-16 04:03:01 -0400, Don said:
In Don's proposal, the following is legal:
-
module A(floatingpoint);
pure void a()
{
set mode;
b();
restore mode;
}
module B(floatingpoint);
pure void b()
{
do st
On 2009-03-16 08:27:28 -0400, Don said:
That requires a new keyord, four new calling conventions, a new name
mangling scheme, compiler insertion of special code, nasty issues with
function pointers, ...
Which isn't much different as adding a new extern(x) option, for which
all these problem
Michel Fortin wrote:
On 2009-03-16 08:27:28 -0400, Don said:
That requires a new keyord, four new calling conventions, a new name
mangling scheme, compiler insertion of special code, nasty issues with
function pointers, ...
Which isn't much different as adding a new extern(x) option, for wh
Don wrote:
Walter Bright wrote:
Don wrote:
A has called a function in B. B is not a floatingpoint module, so b()
can only be called when the mode is set back to the default. a()
violates this contract, so a() is incorrect. There's nothing wrong
with b() or c(). If a() wants to call b(), it ne
Walter Bright wrote:
Don wrote:
Walter Bright wrote:
Don wrote:
A has called a function in B. B is not a floatingpoint module, so
b() can only be called when the mode is set back to the default. a()
violates this contract, so a() is incorrect. There's nothing wrong
with b() or c(). If a() wa
Tue, 17 Mar 2009 03:38:23 -0700, Walter Bright wrote:
> Don wrote:
>> Walter Bright wrote:
>>> Don wrote:
A has called a function in B. B is not a floatingpoint module, so b()
can only be called when the mode is set back to the default. a()
violates this contract, so a() is incorr
of course my example makes no sense
try
pure float square(float x, invariant roundingMode round = default)
{
return x*x;
}
in case that helps
Phil
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't care
about the status flags. So it's your own fault if you
On Sat, 04 Apr 2009 15:19:46 +0400, Philip Miess wrote:
of course my example makes no sense
try
pure float square(float x, invariant roundingMode round = default)
{
return x*x;
}
in case that helps
Phil
I don't see roundingMode used anywhere in your example.
Philip Miess wrote:
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't
care about the status flags. So it's
Denis Koroskin wrote:
On Sat, 04 Apr 2009 15:19:46 +0400, Philip Miess
wrote:
of course my example makes no sense
try
pure float square(float x, invariant roundingMode round = default)
{
return x*x;
}
in case that helps
Phil
I don't see roundingMode used anywhere in your example.
Don wrote:
Philip Miess wrote:
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call a
non-floatingpoint module, it's your responsibility to make sure that
the rounding mode is back to normal. You're saying that you don't
care about the status fla
Philip Miess wrote:
Don wrote:
Philip Miess wrote:
Walter Bright wrote:
Don wrote:
That's true, but if you're in a floatingpoint module, and you call
a non-floatingpoint module, it's your responsibility to make sure
that the rounding mode is back to normal. You're saying that you
don't care
45 matches
Mail list logo
