> On Oct 28, 2015, at 11:38 PM, Jed Brown wrote:
>
> Barry Smith writes:
>
>> After wasting hours debugging I just realized that gcc __float128
>> REQUIRES that numerical constants be written with a q suffix or
>> first they are treated as double and then converted to __float.
>
> Unsuffi
Barry:
If you would only rewrite PETSc in a numerically oriented programming
language like Fortran, this problem would disappear.
See real(kind=REAL128) in ISO_FORTRAN_ENV, which is part of Fortran 2008.
Of course I am trolling, although I intend to use Fortran 2008 as my way of
getting 128b floa
Adrian Croucher writes:
> The reason I'm using NaNs is that John O'Sullivan asked on here some
> time ago about how to make a SNES abort when something goes wrong in
> the function evaluation (in our case, probably the solution going out
> of range of thermodynamic functions). The answer he got w
Barry Smith writes:
> After wasting hours debugging I just realized that gcc __float128
> REQUIRES that numerical constants be written with a q suffix or
> first they are treated as double and then converted to __float.
Unsuffixed numeric literals are double. It's the semantic of the
lan
hi
The reason I'm using NaNs is that John O'Sullivan asked on here some
time ago about how to make a SNES abort when something goes wrong in
the function evaluation (in our case, probably the solution going out
of range of thermodynamic functions). The answer he got was you could
put a NaN or Inf
After wasting hours debugging I just realized that gcc __float128 REQUIRES
that numerical constants be written with a q suffix or first they are treated
as double and then converted to __float. This means unless the numbers are nice
binary numbers they are only as accurate as double precision
Lisandro Dalcin writes:
> I would also like to have PETSC_SNAN define for signaling NaN.
Is -fp_trap not sufficient?
signature.asc
Description: PGP signature
Dne 28.10.2015 v 20:31 Lisandro Dalcin napsal(a):
On 28 October 2015 at 19:29, Jed Brown wrote:
Barry Smith writes:
I don't want to be in the business of providing NaNs. They are nasty little
beasts. PETSc should allow users to use NaN but should not enable them.
FP non-normal values
> Begin forwarded message:
>
> From: Brian Van Straalen
> Subject: PETSc and DSL development
> Date: October 28, 2015 at 3:24:25 PM CDT
> To: Barry Smith , Lois Curfman McInnes
>
>
>
> Hi there FASTMath PETSc poobahs,
>
>After the FASTMath team had Dan Quinlan discuss DSLs at the last
On 28 October 2015 at 19:29, Jed Brown wrote:
> Barry Smith writes:
>
>> I don't want to be in the business of providing NaNs. They are nasty
>> little beasts. PETSc should allow users to use NaN but should not enable
>> them.
>
> FP non-normal values are also extremely slow on some architect
Barry Smith writes:
> I don't want to be in the business of providing NaNs. They are nasty little
> beasts. PETSc should allow users to use NaN but should not enable them.
FP non-normal values are also extremely slow on some architectures so
it's a bad portability move to use them to identify
I don't want to be in the business of providing NaNs. They are nasty little
beasts. PETSc should allow users to use NaN but should not enable them.
Barry
> On Oct 28, 2015, at 11:04 AM, Jed Brown wrote:
>
> Barry Smith writes:
>
>> There is no portable way that I am aware of in C89 to
Barry Smith writes:
> There is no portable way that I am aware of in C89 to generate a NaN.
Fortunately, we've had C99 for 16 years.
#include
NAN
Is there any architecture where this isn't supported?
signature.asc
Description: PGP signature
There is no portable way that I am aware of in C89 to generate a NaN.
Barry
> On Oct 21, 2015, at 5:36 PM, Adrian Croucher
> wrote:
>
> hi,
>
> You may have looked at this before, but I was wondering if there'd be any
> merit in having a NaN constant (PETSC_NAN or similar) in PETSc?
>
14 matches
Mail list logo
