Displaying 6 results from an estimated 6 matches for "0x1p".
Did you mean:
0x1
2008 Mar 05
2
[LLVMdev] Error messages in llvm-test
..., 0x0p+0, 0x0p+0, 0x0p+0 }; /* for PHI node */
208 llvm_cbe_z_tmp_0 = llvm_cbe_z_tmp_0__PHI_TEMPORARY;
209 llvm_cbe_y_tmp_0 = llvm_cbe_y_tmp_0__PHI_TEMPORARY;
210 llvm_cbe_x_tmp_0 = llvm_cbe_x_tmp_0__PHI_TEMPORARY;
211 llvm_cbe_tmp19 = (((llvm_cbe_x_tmp_0
+ { 0x1p+0, 0x0p+0, 0x0p+0, 0x0p+0 })
+ { 0x0p+0, 0x1p+0, 0x0p+0, 0x0p+0 })
+ { 0x0p+0, 0x0p+0, 0x1p+0, 0x0p+0 })
+ { 0x0p+0, 0x0p+0, 0x0p+0, 0x1p+0 };
212 llvm_cbe_tmp37 = (((((llvm_cbe_y_tmp_0
+ { 0x1p+0, 0x1p+1, 0x0p+0, 0x0p+0 })...
2011 Nov 02
0
[LLVMdev] Issues in compiler-rt __truncdfsf2 and __extendsfdf2 functions?
Hi all,
We are using compiler-rt for floating point emulation on our DSP core. I
am currently investigating two issues found by running TestFloat [1] on
our core.
The first issue is in __truncdfsf2. __truncdfsf2(0x1p+128) produces
0x1p-128, while the expected result is inf. __truncdfsf2(-0x1p+128)
produces -0x1p-128, while the expected result is -inf. I think the
condition of the else if on line 137 of truncdfsf2.c should be (aAbs >=
overflow) instead of the current (aAbs > overflow) because overflow is
0...
2016 Dec 20
2
Very small numbers in hexadecimal notation parsed as zero
Hi all,
I have noticed incorrect parsing of very small hexadecimal numbers
like "0x1.00000000d0000p-987". Such a hexadecimal representation can
can be produced by sprintf() using the %a flag. The return value is
incorrectly reported as 0 when coercing these numbers to double using
as.double()/as.numeric(), as illustrated in the three examples below:
2016 Dec 21
0
Very small numbers in hexadecimal notation parsed as zero
...ect parsing:
> as.double("0x1.00000000dp-987") # 7.645296e-298, as expected
> as.double("0x1.p-1022") # 2.225074e-308, as expected
Yes, this looks like a bug, indeed.
Similarly convincing is a simple comparison (of even less extreme)
> as.double("0x1p-987")
[1] 7.645296e-298
> as.double("0x1.0000000000p-987")
[1] 0
>
The "bug boundary" seems around here:
> as.double("0x1.000000000000000000000000p-928") # fails
[1] 0
> as.double("0x1p-928")
[1] 4.407213e-280
>
> as.double("0...
2011 Mar 09
2
Anomaly with unique and match
I stumbled onto this working on an update to coxph. The last 6 lines
below are the question, the rest create a test data set.
tmt585% R
R version 2.12.2 (2011-02-25)
Copyright (C) 2011 The R Foundation for Statistical Computing
ISBN 3-900051-07-0
Platform: x86_64-unknown-linux-gnu (64-bit)
# Lines of code from survival/tests/singtest.R
> library(survival)
Loading required package: splines
2016 Mar 02
2
Incorrect return values for APFloat::convertFromString?
...ethod.
1. If I pass the hex representation of the closest value to 0.1 (0x19999Ap-24), everything is fine and opOk is returned. However, if I pass the same value as a decimal string (0.10000002384185791015625), opInexact is set.
2. On the lower end of the scale, the smallest denormal 0x1p-149 returns opOk, but the slightly larger value 0x1.8p-149 has opUnderflow set and (as expected) opInexact.
Is this behavior correct?
--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunho...