this will be a difficult question to answer, I contacted the author but still no replies I'll give it a shot here:
In the package RCL (http://common-lisp.net/project/rcl/) examples:
(in-package :rcl)
(r-init)
(r "/" 1 5)
RCL> 0.2d0
(r "print" (r% "/" 1 5))
RCL> ;R# [1] 0.2
0.2d0
The above is ok, but
(r "/" 1 0)
RCL>> #<a FLOATING-POINT-OVERFLOW>
broken
(r "print" (r% "/" 1 0))
RCL>> ;R# [1] Inf
#<a FLOATING-POINT-OVERFLOW>
broken
or (r "log" 0)
How to get around this so that when R gets to an inf value my Lisp doesn't break but just gives a message that an inf value is computed; The above is a simple example but there are times when we have during a statistical procedure divisions by zero that nevertheless do not invalidate the results and R returns a final value (like during optimization), but this unfortunately crashes while using RCL.
Ok I got the answer from the author I post here:
support for IEEE floating-point infinities is platform-dependent. The following Lisps work, at least on this system (MacOSX):
SBCL
R> (r "/" 1 0)
.SB-EXT:DOUBLE-FLOAT-POSITIVE-INFINITY
R> (r "log" 0)
.SB-EXT:DOUBLE-FLOAT-NEGATIVE-INFINITY
Allegro CL
R> (r "/" 1 0)
.EXCL:*INFINITY-DOUBLE*
R> (r "log" 0)
.EXCL:*NEGATIVE-INFINITY-DOUBLE*
LispWorks
R> (r "/" 1 0)
+1D++0 #| +1D++0 is double-float plus-infinity
R> (r "log" 0)
-1D++0 #| -1D++0 is double-float minus-infinity
CMUCL doesn't (X86:SIGFPE-HANDLER, no exceptions enabled), but I think this can be fixed (http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#float-traps).
ECL is the last one that I tried, and it's apparently the one you use (I got the same FLOATING-POINT-OVERFLOW exception). It seems that it also allows to disable overflow checks using SI:TRAP-FPE, this might be what you need (the following example is taken from http://www.lispforum.com/viewtopic.php?f=2&t=386):
(let* ((bits (si::trap-fpe 'last nil)))
(prog1 (/ 1.0 0.0)
(si::trap-fpe bits t)))
.SI:SINGLE-FLOAT-POSITIVE-INFINITY
Also this works in general:
(handler-case (r "/" 2 0)
(floating-point-overflow () nil))
Related
Pkg.status() is well-known. However, it outputs to stdout. I need the package names in an iterable, like a list or a vector or so. It would be silly to use Suppressor. How can this be achieved?
Based on the answer below:
for v in values(Pkg.dependencies())
println(v.name)
end
What you are looking for is dependencies()
julia> Pkg.dependencies()
Dict{Base.UUID, Pkg.API.PackageInfo} with 399 entries:
UUID("49dc2e85-a5d0-5ad3-a950-438e2897f1b9") => PackageInfo("Calculus", v"0.5.1", "f641eb0a4f00c343bbc32346e1217b86f3ce9da…
UUID("efcefdf7-47ab-520b-bdef-62a2eaa19f15") => PackageInfo("PCRE2_jll", v"10.40.0+0", nothing, false, false, false, false…
...
This returns an iterator of pars. The value element of the pair contains a PackageInfo element that has the following fields:
julia> fieldnames(Pkg.API.PackageInfo)
(:name, :version, :tree_hash, :is_direct_dep, :is_pinned, :is_tracking_path, :is_tracking_repo, :is_tracking_registry, :git_revision, :git_source, :source, :dependencies)
And here is a sample usage:
julia> for (uuid, dep) in Pkg.dependencies()
dep.is_direct_dep || continue
dep.version === nothing && continue
println("$(dep.name) $(dep.version)")
end
ZipFile 0.10.0
DataFrames 1.4.1
Revise 3.4.0
Symbolics 4.11.1
BenchmarkTools 1.3.1
IJulia 1.23.3
...
I am new to Julia. I am working on a Julia package which the writer is not available.
This is the part of the code where I have a problem with:
function find_partition(model::Model, ms)
ps = Dict{Z3Expr,Vector{Int}}()
for (i, m) in enumerate(ms)
mval = Z3.eval(model, m, false)
println(ps)
println(mval)
println(typeof(mval))
if haskey(ps, mval)
push!(ps[mval], i)
else
push!(ps, mval=>Int[i])
end
end
values(ps)
end
Here is the output:
Dict{Z3.Expr, Vector{Int64}}()
1.0
Z3.ExprAllocated
ERROR: TypeError: in typeassert, expected UInt64, got a value of type UInt32
Stacktrace:
[1] hashindex(key::Z3.ExprAllocated, sz::Int64)
# Base ./dict.jl:169
[2] ht_keyindex(h::Dict{Z3.Expr, Vector{Int64}}, key::Z3.ExprAllocated)
# Base ./dict.jl:284
[3] haskey(h::Dict{Z3.Expr, Vector{Int64}}, key::Z3.ExprAllocated)
# Base ./dict.jl:550
[4] find_partition(model::Z3.ModelAllocated, ms::Vector{Z3.ExprAllocated})
# Absynth.NLSat ~/Desktop/faoc/Absynth/src/nlsat/cfinitesolver.jl:101
I tried following it and found out that somewhere inside dict.jl in Julia, there are such lines
sz = length(h.keys)
...
index = hashindex(key, sz)
And this is the hashindex written somewhere in dict.jl:
hashindex(key, sz) = (((hash(key)::UInt % Int) & (sz-1)) + 1)::Int
It seems that the version of Z3 used in this package is not compatible with the current version of Julia. I am not sure if this package was working in the beginning at all.
Is there any quick fix to this? Like rewriting this part of the code:
if haskey(ps, mval)
push!(ps[mval], i)
else
push!(ps, mval=>Int[i])
in a way that this won't happen? I tried writing like merge!(ps,Dict(mval=>Int[i])) but it's eventually reaching this hashindex function again.
If I install the older versions of Julia, would it be possible to solve this issue or the problem is somewhere else?
How can I pass an NA value from Rcpp to R in a 64 bit vector?
My first approach would be:
// [[Rcpp::export]]
Rcpp::NumericVector foo() {
Rcpp::NumericVector res(2);
int64_t val = 1234567890123456789;
std::memcpy(&(res[0]), &(val), sizeof(double));
res[1] = NA_REAL;
res.attr("class") = "integer64";
return res;
}
But it yields
#> foo()
integer64
[1] 1234567890123456789 9218868437227407266
I need to get
#> foo()
integer64
[1] 1234567890123456789 <NA>
It's really much, much simpler. We have the behaviour of an int64 in R offered by (several) add-on packages the best of which is bit64 giving us the integer64 S3 class and associated behavior.
And it defines the NA internally as follows:
#define NA_INTEGER64 LLONG_MIN
And that is all that there is. R and its packages are foremost C code, and LLONG_MIN exists there and goes (almost) back all the way to founding fathers.
There are two lessons here. The first is the extension of IEEE defining NaN and Inf for floating point values. R actually goes way beyond and adds NA for each of its types. In pretty much the way above: by reserving one particular bit pattern. (Which, in one case, is the birthday of one of the two original R creators.)
The other is to admire the metric ton of work Jens did with the bit64 package and all the required conversion and operator functions. Seamlessly converting all possibly values, including NA, NaN, Inf, ... is no small task.
And it is a neat topic that not too many people know. I am glad you asked the question because we now have a record here.
Alright, I think I found an answer... (not beautiful, but working).
Short Answer:
// [[Rcpp::export]]
Rcpp::NumericVector foo() {
Rcpp::NumericVector res(2);
int64_t val = 1234567890123456789;
std::memcpy(&(res[0]), &(val), sizeof(double));
# This is the magic:
int64_t v = 1ULL << 63;
std::memcpy(&(res[1]), &(v), sizeof(double));
res.attr("class") = "integer64";
return res;
}
which results in
#> foo()
integer64
[1] 1234567890123456789 <NA>
Longer Answer
Inspecting how bit64 stores an NA
# the last value is the max value of a 64 bit number
a <- bit64::as.integer64(c(1, 2, NA, 9223372036854775807))
a
#> integer64
#> [1] 1 2 <NA> <NA>
bit64::as.bitstring(a[3])
#> [1] "1000000000000000000000000000000000000000000000000000000000000000"
bit64::as.bitstring(a[4])
#> [1] "1000000000000000000000000000000000000000000000000000000000000000"
Created on 2020-04-23 by the reprex package (v0.3.0)
we see that it is a 10000.... This can be recreated in Rcpp with int64_t val = 1ULL << 63;. Using memcpy() instead of a simple assign with = ensures that no bits are changed!
When debugging or running julia code in REPL, I usually see error messages showing ... at ./REPL[161]:12 [inlined].... The number 161 means the 161-th evaluation in REPL, I guess. So my question is could we show this number in julia's prompt, i.e. julia [161]> instead of julia>?
One of the advantages of Julia is its ultra flexibility. This is very easy in Julia 0.7 (nightly version).
julia> repl = Base.active_repl.interface.modes[1]
"Prompt(\"julia> \",...)"
julia> repl.prompt = () -> "julia[$(length(repl.hist.history) - repl.hist.start_idx + 1)] >"
#1 (generic function with 1 method)
julia[3] >
julia[3] >2
2
julia[4] >f = () -> error("e")
#3 (generic function with 1 method)
julia[5] >f()
ERROR: e
Stacktrace:
[1] error at .\error.jl:33 [inlined]
[2] (::getfield(, Symbol("##3#4")))() at .\REPL[4]:1
[3] top-level scope
You just need to put the first 2 lines onto your ~/.juliarc and enjoy~
Since there are several changes in the REPL after julia 0.7, these codes do not work in old versions.
EDIT: Well, actually there need a little bit more efforts to make it work in .juliarc.jl. Try this code:
atreplinit() do repl
repl.interface = Base.REPL.setup_interface(repl)
repl = Base.active_repl.interface.modes[1]
repl.prompt = () -> "julia[$(length(repl.hist.history) - repl.hist.start_idx + 1)] >"
end
In clojure I can do something like this:
(def x
;; perform some expensive computation in a new thread
;; the repl is not blocked, so you can go on do something else
(future
(do
(Thread/sleep 500)
3.14)))
;; ... do something else
;; now when you need x
;; just deref the future, get 3.14
#x
Is there something similar to this in R?
On Linux you can fork a process and then collect it later, as illustrated on the help page ?parallel::mccollect(); this is more of a hack than a robust feature like future.
> p <- mcparallel({ Sys.sleep(5); "done" })
> sqrt(1:5)
[1] 1.000000 1.414214 1.732051 2.000000 2.236068
> mccollect(p)
$`15666`
[1] "done"
One can implement a similar strategy with snow::sendCall() / snow::recvResult(); see the implementation of snow::clusterCall() and note that a cluster can be subset, e.g., cl[1] to set a single node to work. (identically named functions are available in the parallel package, but not exported).
To check whether a job has finished, use wait = FALSE. Example:
require(parallel)
p1 = mcparallel({Sys.sleep(90); list(tag = "job1", res = 1})
p2 = mcparallel({Sys.sleep(80); 2})
p3 = mcparallel({Sys.sleep(60); 3})
res = mccollect(list(p1, p2, p3), wait = FALSE)
is.null(res)
If none of these 3 jobs has been finished, then res is NULL.