juliamath / decfp.jl Goto Github PK
View Code? Open in Web Editor NEWJulia IEEE decimal floating-point via the Intel decimal-float library
License: Other
decfp.jl's People
Contributors
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
![femtocleaner[bot] avatar](https://avatars.githubusercontent.com/in/4123?v=4 "femtocleaner[bot]")
Stargazers
Watchers
Forkers
scottpjones hyiltiz abhijithch nkottary tkelman pallharaldsson ranjanan nicolaspayette jmkuhn kristofferc simonbyrne wookay fredrikekre standardgalactic lvyitian ssingh13-rms ancapdev dantaras ranocha fingolfin sprigdecfp.jl's Issues
tryparse
- Need a
tryparseequivalent. - Also, don't throw an error on
d"nan".
Windows binaries failure
Unfortunately, the Appveyor tests are indicating that the Windows binaries I generated (via MinGW) aren't correct. Something in my cross-compile build script must be wrong.
StackOverflow when using DecFP on 32-bit Linux
On Ubuntu 16.04 32-bit:
julia> using DecFP
ERROR: LoadError: StackOverflowError:
while loading /home/omus/.julia/v0.5/DecFP/src/DecFP.jl, in expression starting on line 72Tag a new release
It looks like there is an isapprox failure on 0.4, and a concerning segfault that happened on the linux nightly travis build, but not osx.
implement Base.hash(x::DecFP.DecimalFloatingPoint)
We could use Base.hash(x::DecFP.DecimalFloatingPoint, h::UInt) = hash(x.x, h). But I have thought of a problem:
If x and y are of type Dec64, and if x == y, then we must be able to guarantee hash(x) == hash(y). Since the definition of Base.:(==)(x::Dec64, y::Dec64) makes a ccall to the Intel Decimal Floating-Point Math Library, I doubt that x == y will imply hash(x.x) == hash(y.x).
Any ideas about how we can provide a good hash function for use in Julia's Dict, Set, etc?
exception handling
Look at the global exceptions flag and throw an error as needed.
conversions to/from integers
round, trunc, ceil, etc.
InexactError for parsing/conversion
I am running Julia 0.7.0 on Linus/CentOS and get the following InexactError,
julia> parse(Dec64, "3935767060.093896713")
ERROR: InexactError: parse(Dec64, 3935767060.093896713)
Stacktrace:
[1] parse(::Type{Dec64}, ::String) at /home/user/.julia/packages/DecFP/3jJW7/src/DecFP.jl:66
[2] top-level scope at none:0
julia> parse(Float64, "3935767060.093896713")
3.935767060093897e9
Parsing the value to Float64 works fine. But it fails to parse to Dec64. Any idea why it happens? Thanks!
caller access to exception flags
Right now, I'm clearing the exception flags after calling a function and possibly checking them. It might be nice to allow more flexible handling of them. e.g. leave them uncleared and let the caller check them if she wants to.
Ideally, I would imitate what Julia does with fp exception flags for binary fp, but there doesn't seem to be much there right now. cc @andreasnoack
mod, rem
export them
Package compatibility caps
norm(Dec32[1,2], 2) Inexact error
julia> a = Dec32[1,2]
2-element Array{DecFP.Dec32,1}:
1.0
2.0
julia> norm(a, 2)
ERROR: MethodError: no method matching InexactError(::UInt8, ::Symbol, ::Type{DecFP.Dec32}, ::DecFP.Dec64)
Closest candidates are:
InexactError(::Symbol, ::Any, ::Any) at C:\Users\user\.julia\v0.6\Compat\src\Compat.jl:609
Stacktrace:
[1] #xchk#5(::UInt8, ::Function, ::DecFP.Dec32, ::UInt8, ::Vararg{Any,N} where N) at C:\Users\user\.julia\v0.6\DecFP\src\DecFP.jl:355
[2] generic_vecnorm2(::Array{DecFP.Dec32,1}) at .\linalg\generic.jl:367
[3] vecnorm(::Array{DecFP.Dec32,1}, ::Int64) at .\linalg\generic.jl:445
[4] norm(::Array{DecFP.Dec32,1}, ::Int64) at .\linalg\generic.jl:540BoundsError in `transpose(::Vector{Dec128})`
Attempting to transpose a vector of Dec128 fails with a BoundsError on Julia v0.5 and v0.6, running in Ubuntu 14.04 and macOS. I can reproduce this both on the last tagged release of DecFP and on master.
julia> transpose(zeros(Dec128, 5))
ERROR: BoundsError: attempt to access 5-element Array{DecFP.Dec128,1} at index [6]
in prod_next at ./iterator.jl:527 [inlined]
in next at ./iterator.jl:538 [inlined]
in next at ./generator.jl:25 [inlined]
in collect_to!(::Array{DecFP.Dec128,2}, ::Base.Generator{Base.Prod2{Base.OneTo{Int64},Array{DecFP.Dec128,1}},Base.##207#208}, ::Int64, ::Tuple{Int64,Int64,Nullable{DecFP.Dec128},Bool}) at ./array.jl:340
in collect(::Base.Generator{Base.Prod2{Base.OneTo{Int64},Array{DecFP.Dec128,1}},Base.##207#208}) at ./array.jl:308
in transpose(::Array{DecFP.Dec128,1}) at ./arraymath.jl:459This occurs regardless of the length of the vector:
julia> transpose(zeros(Dec128, 1))
ERROR: BoundsError: attempt to access 1-element Array{DecFP.Dec128,1} at index [2]
in prod_next at ./iterator.jl:527 [inlined]
in next at ./iterator.jl:538 [inlined]
in next at ./generator.jl:25 [inlined]
in collect_to!(::Array{DecFP.Dec128,2}, ::Base.Generator{Base.Prod2{Base.OneTo{Int64},Array{DecFP.Dec128,1}},Base.##207#208}, ::Int64, ::Tuple{Int64,Int64,Nullable{DecFP.Dec128},Bool}) at ./array.jl:340
in collect(::Base.Generator{Base.Prod2{Base.OneTo{Int64},Array{DecFP.Dec128,1}},Base.##207#208}) at ./array.jl:308
in transpose(::Array{DecFP.Dec128,1}) at ./arraymath.jl:459reshape() works fine, and transpose() works fine for vectors of Dec64 and Dec32. Transpose also works for 2-dimensional arrays of Dec128.
size() and length() give the right answers:
julia> length(zeros(Dec128, 5))
5
julia> size(zeros(Dec128, 5))
(5,)Any ideas?
Printing of Decs
The following example has received some attention lately
julia> d"1.05"*d"0.7"
+735E-3I wondered if it would be possible to print this similarly to how the binary floats are printed, i.e. such the result is +7.35E-1?
Cross-compiling build error
@stevengj, I'm trying out building the shared library via BinaryBuilder, but I'm hitting this error while cross-compiling for windows 64-bit
src/bid_flag_operations.c: In function ‘__bid_ms_restore_flags’:
src/bid_flag_operations.c:372:20: error: ‘_SW_INEXACT’ undeclared (first use in this function)
if(crt_flags & _SW_INEXACT)
^~~~~~~~~~~
src/bid_flag_operations.c:372:20: note: each undeclared identifier is reported only once for each function it appears in
src/bid_flag_operations.c:378:20: error: ‘_SW_UNDERFLOW’ undeclared (first use in this function)
if(crt_flags & _SW_UNDERFLOW)
^~~~~~~~~~~~~
src/bid_flag_operations.c:384:20: error: ‘_SW_OVERFLOW’ undeclared (first use in this function)
if(crt_flags & _SW_OVERFLOW)
^~~~~~~~~~~~
src/bid_flag_operations.c:390:20: error: ‘_SW_ZERODIVIDE’ undeclared (first use in this function)
if(crt_flags & _SW_ZERODIVIDE)
^~~~~~~~~~~~~~
src/bid_flag_operations.c:396:20: error: ‘_SW_INVALID’ undeclared (first use in this function)
if(crt_flags & _SW_INVALID)
^~~~~~~~~~~
src/bid_flag_operations.c:403:20: error: ‘_SW_DENORMAL’ undeclared (first use in this function)
if(crt_flags & _SW_DENORMAL)
^~~~~~~~~~~~
make: *** [makefile:356: bid_flag_operations.obj] Error 1
I tried to follow your logic as closely as possible in deps/build.jl file, for windows specifically, but still see this error. Any tips? Have you seen this before?
Negative exponentiation is flawed
The following causes an error:
julia> (2one(Dec128))^(-10)
ERROR: DomainError with -10:
Cannot raise an integer x to a negative power -10.
Convert input to float.
Stacktrace:
[1] throw_domerr_powbysq(::Dec128, ::Int64) at ./intfuncs.jl:173
[2] power_by_squaring(::Dec128, ::Int64) at ./intfuncs.jl:196
[3] ^ at ./intfuncs.jl:221 [inlined]
[4] literal_pow(::typeof(^), ::Dec128, ::Val{-10}) at ./intfuncs.jl:247
[5] top-level scope at none:0
This happens when you try to use Givens rotations on DecFP numbers.
Error tagging new release
The URL of this package does not match that stored in METADATA.jl.
cc: @quinnj
Base.Printf.function() deprecated in Julia 1.4
Base.Printf needs to be changed to Printf.Printf with the dependency of Printf added to the top.
I am not sure how this change effects other versions of Julia and it looks like the Compat.jl package has been solving this problem up to 1.3.
I do a lot of work with the OmniSci.jl package and had to make this change to keep using the package, so at least this problem has a documented fix for anyone who is facing similar problems.
Unable to precompile on Julia v0.6.3
using DecFP results in
julia> using DecFP
INFO: Precompiling module DecFP.
Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x21f76c22 -- _bid128_sub at C:\Users\jr\.julia\v0.6\DecFP\deps\usr\bin\libbid.dll (unknown line)
while loading C:\Users\jr\.julia\v0.6\DecFP\src\DecFP.jl, in expression starting on line 413
_bid128_sub at C:\Users\jr\.julia\v0.6\DecFP\deps\usr\bin\libbid.dll (unknown line)
_sub at C:\Users\jr\.julia\v0.6\DecFP\src\DecFP.jl:139
unknown function (ip: 0000000017F10C8F)
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gf.c:1926
macro expansion at C:\Users\jr\.julia\v0.6\DecFP\src\DecFP.jl:414 [inlined]
anonymous at .\<missing> (unknown line)
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_toplevel_eval_flex at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:589
jl_eval_module_expr at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:205
jl_toplevel_eval_flex at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:480
jl_parse_eval_all at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\ast.c:873
jl_load at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:616 [inlined]
jl_load_ at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:623
include_from_node1 at .\loading.jl:576
unknown function (ip: 00000000032DAF91)
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gf.c:1926
include at .\sysimg.jl:14
unknown function (ip: 00000000031336A1)
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gf.c:1926
do_call at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\interpreter.c:75
eval at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\interpreter.c:242
jl_interpret_toplevel_expr at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\interpreter.c:34
jl_toplevel_eval_flex at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:577
jl_toplevel_eval_in at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\builtins.c:496
anonymous at .\<missing>:2
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_toplevel_eval_flex at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\toplevel.c:589
jl_toplevel_eval_in at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\builtins.c:496
eval at .\boot.jl:235
unknown function (ip: 000000000328E3A5)
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gf.c:1926
process_options at .\client.jl:286
_start at .\client.jl:371
unknown function (ip: 00000000032EB80E)
jl_call_fptr_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:339 [inlined]
jl_call_method_internal at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\julia_internal.h:358 [inlined]
jl_apply_generic at /home/Administrator/buildbot/worker/package_win64/build/src/home/Administrator/buildbot/worker/package_win64/build/src\gf.c:1926
jl_apply at /home/Administrator/buildbot/worker/package_win64/build/src\julia.h:1424 [inlined]
true_main at /home/Administrator/buildbot/worker/package_win64/build/ui\repl.c:127
wmain at /home/Administrator/buildbot/worker/package_win64/build/ui\repl.c:264
__tmainCRTStartup at /usr/src/debug/mingw64-x86_64-runtime-5.0.3-1/crt\crtexe.c:329
mainCRTStartup at /usr/src/debug/mingw64-x86_64-runtime-5.0.3-1/crt\crtexe.c:212
BaseThreadInitThunk at C:\Windows\system32\kernel32.dll (unknown line)
RtlUserThreadStart at C:\Windows\SYSTEM32\ntdll.dll (unknown line)
Allocations: 1477079 (Pool: 1475846; Big: 1233); GC: 0
ERROR: Failed to precompile DecFP to C:\Users\jr\.julia\lib\v0.6\DecFP.ji.
Stacktrace:
[1] compilecache(::String) at .\loading.jl:710
[2] _require(::Symbol) at .\loading.jl:497
[3] require(::Symbol) at .\loading.jl:405
julia> versioninfo()
Julia Version 0.6.3
Commit d55cadc350* (2018-05-28 20:20 UTC)
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, broadwell)
On v0.6.2 and v0.7-alpha.0 precompilation is fine.
Windows and MacOS binaries
Need precompiled binaries for these platforms.
exp10(Dec128(0)) produces incorrect result
julia> exp10(Dec32(0))
+1E+0
julia> exp10(Dec64(0))
+1E+0
julia> exp10(Dec128(0))
+0E+0
Dec128 Julia codegen bug
opening an issue to track progress on JuliaLang/julia#21216
incorrect floatmin?
We currently use the definition Base.floatmin(::Type{$T}) = $(_nextfloat(zero(T))).
However, floatmin in Julia is defined to give the smallest non-subnormal value. For binary floating point, this is actually nextfloat(zero(T)) / eps(T), so maybe we should use the same definition?
0.5/0.6 weirdness
@stevengj, any idea what's going on here? Some kind of library version error maybe?
Julia 0.5
julia> DecFP._nextfloat(one(Dec32))
+1000001E-6Julia 0.6
julia> DecFP._nextfloat(one(Dec32))
+9999999E-7Doesn't work in DifferentialEquations
Following the example given here
With
Julia version
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.0.3 (2018-12-18)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
Julia status
julia> Pkg.status()
Status `~/.julia/environments/v1.0/Project.toml`
[7e558dbc] ArbNumerics v0.2.6
[55939f99] DecFP v0.4.7
[225cb15b] DiffEqTutorials v0.0.0 #master (https://github.com/JuliaDiffEq/DiffEqTutorials.jl)
[0c46a032] DifferentialEquations v5.3.1
[ffa9a821] DocumentFormat v0.2.0
[7073ff75] IJulia v1.15.2
[2b0e0bc5] LanguageServer v0.5.0
[2edaba10] Nemo v0.11.1
[9b87118b] PackageCompiler v0.5.1
[91a5bcdd] Plots v0.22.4
[d330b81b] PyPlot v2.6.3
[0d4725de] Readables v0.2.0
[90137ffa] StaticArrays v0.10.2
[b3cc710f] StaticLint v0.0.2
[cf896787] SymbolServer v0.1.0
[1986cc42] Unitful v0.14.0
LoadError on julia v0.4
I get the following error when using DecFP:
_
_ _ _(_)_ | A fresh approach to technical computing
(_) | (_) (_) | Documentation: http://docs.julialang.org
_ _ _| |_ __ _ | Type "?help" for help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 0.4.2 (2015-12-06 21:47 UTC)
_/ |\__'_|_|_|\__'_| | Official http://julialang.org release
|__/ | x86_64-linux-gnu
julia> using DecFP
ERROR: LoadError: MethodError: `setprecision` has no method matching setprecision(::Function, ::Int64)
Closest candidates are:
setprecision(::Any)
setprecision(::Any, ::Type{BigFloat}, ::Any)
setprecision(::Type{BigFloat}, ::Any)
[inlined code] from /home/nishanth/.julia/v0.4/DecFP/src/DecFP.jl:138
in anonymous at no file:0
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:304
in require at ./loading.jl:243
while loading /home/nishanth/.julia/v0.4/DecFP/src/DecFP.jl, in expression starting on line 63
sqrt on Dec32 is painfully slow and allocates
julia> using DecFP
julia> af = rand(Float32);
julia> ad = Dec32(af);
julia> using BenchmarkTools
julia> @btime sqrt($af)
1.093 ns (0 allocations: 0 bytes)
0.8627168f0
julia> @btime sqrt($ad)
5.531 μs (15 allocations: 720 bytes)
0.862717Interestingly, raising to power 0.5 is much faster and does not allocate:
julia> exf = Float32(0.5); exd = Dec32(0.5);
julia> @btime ($af)^($exf)
6.564 ns (0 allocations: 0 bytes)
0.8627168f0
julia> @btime ($ad)^($exd)
117.763 ns (0 allocations: 0 bytes)
0.862717Low-level Constructors
@stevengj, what are the options for low level construction of a Dec64 type? I poked around the source code, but it seems like pretty much everything funnels through parse. I ask because I'm looking at ODBC interop, where the ODBC SQL type is defined as
const SQL_MAX_NUMERIC_LEN = 16
immutable SQLNumeric
precision::SQLCHAR
scale::SQLSCHAR
sign::SQLCHAR
val::NTuple{SQL_MAX_NUMERIC_LEN,SQLCHAR}
endwhich the ODBC driver manager would fill in the bits, and then ODBC.jl defines the appropriate conversion routine from SQLNumeric to Dec64. Any thoughts or perhaps I need to dig into the Intel header files a little.
Comparison with Rational
exact comparisons with binary values/directed conversions
Currently
julia> using DecFP
julia> d64"1e100" == 1e100
truewhich might seem reasonable, except that
julia> big(1e100)
1.000000000000000015902891109759918046836080856394528138978132755774783877217038e+100Since the library doesn't appear to offer comparisons, the one option would be to do it via directed conversions, e.g.
<(x::Float64, y::Dec64) = x < Float64(y, RoundUp)
<=(x::Float64, y::Dec64) = x <= Float64(y, RoundDown)
==(x::Float64, y::Dec64) = x == Float64(y, RoundUp) == Float64(y, RoundDown)Is it possible to do this without touching the global rounding mode?
Lacking randn()
Neither rand(Dec64) nor randn(Dec64) works.
Pkg.test() on windows with Julia-0.5 fails
julia> Pkg.test("DecFP")
INFO: Testing DecFP
TESTING DecFP.Dec32 ...
Test Failed
Expression: @d32_str("3.2") * @d32_str("4.5") == @d32_str("14.4")
Evaluated: +4619304E-100 == +4619304E-100
ERROR: LoadError: There was an error during testing
in record(::Base.Test.FallbackTestSet, ::Base.Test.Fail) at .\test.jl:397
in do_test(::Base.Test.Returned, ::Expr) at .\test.jl:281
in macro expansion; at C:\Users\julia\AppData\Local\JuliaPro-0.5.0.1\pkgs-0.5.0
.1\v0.5\DecFP\test\runtests.jl:13 [inlined]
in anonymous at .\<missing>:?
in include_from_node1(::String) at .\loading.jl:488
in process_options(::Base.JLOptions) at .\client.jl:262
in _start() at .\client.jl:318
while loading C:\Users\julia\AppData\Local\JuliaPro-0.5.0.1\pkgs-0.5.0.1\v0.5\De
cFP\test\runtests.jl, in expression starting on line 9
================================[ ERROR: DecFP ]================================
failed process: Process(`'C:\Users\julia\AppData\Local\JuliaPro-0.5.0.1\Julia-0.
5.0\bin\julia' -Cx86-64 '-JC:\Users\julia\AppData\Local\JuliaPro-0.5.0.1\Julia-0
.5.0\lib\julia\sys.dll' --compile=yes --depwarn=yes --check-bounds=yes --code-co
verage=none --color=yes --compilecache=yes 'C:\Users\julia\AppData\Local\JuliaPr
o-0.5.0.1\pkgs-0.5.0.1\v0.5\DecFP\test\runtests.jl'`, ProcessExited(1)) [1]
================================================================================
ERROR: DecFP had test errors
in #test#61(::Bool, ::Function, ::Array{AbstractString,1}) at .\pkg\entry.jl:74
0
in (::Base.Pkg.Entry.#kw##test)(::Array{Any,1}, ::Base.Pkg.Entry.#test, ::Array
{AbstractString,1}) at .\<missing>:0
in (::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#test,Tuple{Array{Abstract
String,1}}})() at .\pkg\dir.jl:31
in cd(::Base.Pkg.Dir.##2#3{Array{Any,1},Base.Pkg.Entry.#test,Tuple{Array{Abstra
ctString,1}}}, ::String) at .\file.jl:48
in #cd#1(::Array{Any,1}, ::Function, ::Function, ::Array{AbstractString,1}, ::V
ararg{Array{AbstractString,1},N}) at .\pkg\dir.jl:31
in (::Base.Pkg.Dir.#kw##cd)(::Array{Any,1}, ::Base.Pkg.Dir.#cd, ::Function, ::A
rray{AbstractString,1}, ::Vararg{Array{AbstractString,1},N}) at .\<missing>:0
in #test#3(::Bool, ::Function, ::String, ::Vararg{String,N}) at .\pkg\pkg.jl:25
8
in test(::String, ::Vararg{String,N}) at .\pkg\pkg.jl:258
switch to decNumber?
@ScottPJones points out that the IBM decNumber package (under the ICU license) may be more portable than the Intel package, and supports more formats. We might consider switching to it, instead of the Intel library.
(A more complex option would be to link to both libraries: using Intel where the performance is better, and decNumber where it supports more functionality.)
Would be interesting to compare the performance of the two libraries.
Make DecFP package thread safe
Although the multithreading support in Julia v0.6 is still classified as experimental, I assume that the goal is to have it fully working (and have packages work correctly when threads are used) by the time v1.0 is released.
Currently, the DecFP uses a single buffer (_buffer) used when converting a decimal to a string,
as well as C globals for rounding mode and exception flags.
When using threads, the buffer would need to be stored in thread-local storage or locking used when using the buffer, and the rounding mode and exception flags would need to also be in thread-local storage (and the Intel package compiled to pass those on every call instead of using global values).
0.3 compatibility
Currently, it only works with 0.4, which is not really acceptable.
switch to stdlib Printf
see Compilation fails on new Julia builds
JuliaMath/Quadmath.jl#39
to submit for a PR, it also need that Transitioning from REQUIRE to Project.toml
https://github.com/JuliaRegistries/Registrator.jl/#transitioning-from-require-to-projecttoml
round functions
The Intel supports round in all of the various rounding directions, so we should export this.
nextfloat/prevfloat etc.
Various fp-specific functions be implemented:
-
nextfloat/prevfloatvia__bid32_nexttowardetc. - also
typemax/typemin,realmax/realmin - also
eps -
sign,signbit -
reinterpretto integer types (automatic since we have abitstype) -
bswap
String parsing doesn't work for Dec128 type
On v0.6.2, I ran into the following problem:
julia> parse(Dec128, "56123")
56123.0
julia> parse(Dec128, "561234")
0.0I'll try to figure it out and submit a PR later, unless you already have a fix in the works for this.
string macro naming
@ScottPJones noticed DecFP and DoubleFloats both export 'd64'. I was unaware of DecFP's use. I wiil post a more general-purpose suggestion on discourse dev after sleeping on it to help others avoid this going forward. I'll change my naming then.
printf formatting
Is there an easy way to print a Dec type in a decimal representation, like the %f style?
Update AppVeyor after migration to JuliaMath
We'd need to set up AppVeyor again. I'm not completely sure how to do it correctly for organizations.
Tag new release?
Hello, I noticed that there are commits to master after the previous release that fix depwarns. Would you mind tagging a new release please? Thanks in advance.
Build error when using DecFP on 32-bit arm7l
On Debian Stretch ARM platform (Beaglebone):
`julia> Pkg.add("DecFP")
INFO: Installing DecFP v0.4.3
INFO: Building DecFP
=====================================================================[ ERROR: DecFP ]======================================================================
LoadError: Your platform arm-linux-gnueabihf is not supported by this package!
while loading /root/.julia/v0.6/DecFP/deps/build.jl, in expression starting on line 32
===========================================================================================================================================================
=====================================================================[ BUILD ERRORS ]======================================================================
WARNING: DecFP had build errors.
- packages with build errors remain installed in /root/.julia/v0.6
- build the package(s) and all dependencies with `Pkg.build("DecFP")`
- build a single package by running its `deps/build.jl` script
===========================================================================================================================================================
INFO: Package database updated
INFO: METADATA is out-of-date — you may not have the latest version of DecFP
INFO: Use `Pkg.update()` to get the latest versions of your packages
`
lgamma is decprecated in SpecialFunctions
tests
Need more.
display bug near realmin
julia> realmin(d64"3.4")
I.nfe+2147483244
julia> realmin(Dec64)
Error showing value of type DecFP.Dec64:
ERROR: BoundsError: attempt to access 326-element Array{UInt8,1} at index [327]
Stacktrace:
[1] ini_dec(::DecFP.Dec64, ::Int64) at /Users/stevenj/.julia/v0.6/DecFP/src/DecFP.jl:167
[2] show(::IOContext{Base.Terminals.TTYTerminal}, ::DecFP.Dec64) at /Users/stevenj/.julia/v0.6/DecFP/src/DecFP.jl:75
[3] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::MIME{Symbol("text/plain")}, ::DecFP.Dec64) at ./REPL.jl:122
[4] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::DecFP.Dec64) at ./REPL.jl:125
[5] display(::DecFP.Dec64) at ./multimedia.jl:194
[6] eval(::Module, ::Any) at ./boot.jl:235
[7] print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, ::Bool, ::Void) at ./REPL.jl:144
[8] print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) at ./REPL.jl:129
[9] (::Base.REPL.#do_respond#16{Bool,Base.REPL.##26#36{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState, ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at ./REPL.jl:646cc @jmkuhn
floating point exceptions on Windows
The package appears to be enabling trapping of floating point exceptions, and not setting them back, see JuliaLang/julia#18065 (comment)
Into standard JuliaLang library
Do you think it should every make into the standard library so that we can use it WITHOUT Using this library? Maybe merging it into the Base would be great.
New tag?
Hi,
The last tagged version of DecFP comes with a ton of deprecation warnings. I didn't see any outstanding PRs so fixed them myself. While preparing a PR, I realized that the deprecation warnings are fixed on master.
Is there anything holding up tagging a new version so that newbies (like me) do not get scared away from ODBC.jl by seeing the deprecation warnings?
Thanks
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.