I've start improving some old R code and find that next functions are deprecated:
real creates a double precision vector of the specified length. Each element of the vector is equal to 0.
as.real attempts to coerce its argument to be of double type.
is.real returns TRUE or FALSE depending on whether its argument is of double type or not.
And what to use instead?
Wow, that's pretty old code. I think you'll be fine with double, as.double, and is.double.
Related
I'm trying to pass a three-dimensional data structure to Stan (in RStan) where the entries must be integers, because a function down-stream requires that. However I'm having trouble declaring it.
I tried the straight-forward approach:
int x[n,n,k];
But that gave me the error
mismatch in number dimensions declared and found in context; ... dims declared=(n,n,k); dims found=(n*n*k)
meaning, clearly, the input array is getting flattened, for some reason (that I don't understand). I'm giving it a simple 3d array, no NAs, the dimensions look right before I pass it. And in fact, the same things is happening for 2d arrays, as well, meaning I can't even declare a set of 2d matrices, as a workaround.
Then I tried
row_vector[K] x[N,N];
but that gives back real, not int. And when I do something like
int row_vector[K] x[N,N];
that's just not proper syntax.
I also tried passing logical values, hoping they'd be re-cast as ints, but no. I passed arrays, I passed them cast with as.matrix, I checked their dimension both before and after being put into the data list.
This is with R version 3.4.1 on OSX 10.11.6, using the most recent version of stan, that was just compiled from source, today.
What am I missing? OR, how might I cast a single real to an integer, so that the integer-requiring function doesn't break?
(And, WHERE is the documentation? The best I can find is long-dead comment threads.)
I just want to know how to convert an array{Float64,1} to a Float64? in julia
utility= rand(1)*row*c*(1-x)
it gives me error "array of size (1,) passed as objective; only scalar objectives are allowed"
Just use rand() instead of rand(1). The former returns a random Float64 value, whereas the latter returns a 1-dimensional array with one element in it. Better to keep everything as scalars in the first place if it's possible to do so.
Generally though, you can't convert a vector v to a scalar. There may be more than one element in it, in which case the conversion isn't well defined. What you can do, however, is index into the vector to extract one of its values.
Why are the following all "numeric"?
class(ceiling(3))
class(ceiling(3L))
class(ceiling(3.1))
class(floor(2))
class(floor(2L))
class(floor(2.1))
This seems like one arithmetic operation where the result is unambiguously an integer (unlike, say, exponentiation), regardless of inputs (it's an error to pass a complex number).
I tried poking around for an answer related in the underlying C code but didn't really get anywhere.
I also learned that, while "%/%"(x,y) should also always be an integer, the class of the results depends on the input types, e.g. 5%/%2, 6%/%2 and 6%/%2L are all numeric, but 5L%/%2L and 6L%/%2L are both integer (something about this is mentioned in ?Arithmetic); this doesn't really make sense to me either, but at least it's documented.
Is there a simple reason for returning numeric objects from ceiling and floor? If it were about inefficiency due to re-casting (which seems may be the case for integer division), I would expect class(ceiling(3L)) to be "integer", so what's going on?
I don't know if this is why ceiling was designed to return numeric, but the following example shows the limitations ceiling would have if it actually returned an integer:
options(digits = 15)
.Machine$integer.max + 1.4
#[1] 2147483648.4
ceiling(.Machine$integer.max + 1.4)
#[1] 2147483649
as.integer(ceiling(.Machine$integer.max + 1.4))
#[1] NA
#Warning message:
#NAs introduced by coercion
That said, there is no good reason that I see why ceiling doesn't return an integer when given an integer input.
This is similar to my previous question, but a bit more complicated.
Before I was defining a type with an associated integer as a parameter, Intp{p}. Now I would like to define a type using a vector as a parameter.
The following is the closest I can write to what I want:
type Extp{g::Vector{T}}
c::Vector{T}
end
In other words, Extp should be defined with respect to a Vector, g, and I want the contents, c, to be another Vector, whose entries should be the of the same type as the entries of g.
Well, this does not work.
Problem 1: I don't think I can use :: in the type parameter.
Problem 2: I could work around that by making the types of g and c arbitary and just making sure the types in the vectors match up in the constructor. But, even if I completely take everything out and use
type Extp{g}
c
end
it still doesn't seem to like this. When I try to use it the way I want to,
julia> Extp{[1,1,1]}([0,0,1])
ERROR: type: apply_type: in Extp, expected Type{T<:Top}, got Array{Int64,1}
So, does Julia just not like particular Vectors being associated with types? Does what I'm trying to do only work with integers, like in my Intp question?
EDIT: In the documentation I see that type parameters "can be any type at all (or an integer, actually, although here it’s clearly used as a type)." Does that mean that what I'm asking is impossible, and that that only types and integers work for Type parameters? If so, why? (what makes integers special over other types in Julia in this way?)
In Julia 0.4, you can use any "bitstype" as a parameter of a type. However, a vector is not a bitstype, so this is not going to work. The closest analog is to use a tuple: for example, (3.2, 1.5) is a perfectly valid type parameter.
In a sense vectors (or any mutable object) are antithetical to types, which cannot change at runtime.
Here is the relevant quote:
Both abstract and concrete types can be parameterized by other types
and by certain other values (currently integers, symbols, bools, and
tuples thereof).
So, your EDIT is correct. Widening this has come up on the Julia issues page (e.g., #5102 and #6081 were two related issues I found with some discussion), so this may change in the future - I'm guessing not in v0.4 though. It'd have to be an immutable type really to make any sense, so not Vector. I'm not sure I understand your application, but would a Tuple work?
It looks like the default for WinDbg is to display ints in decimal and unsigned ints in hexadecimal.
Is there a way to show all in decimal?
I tried using the n command mentioned here
It gives me syntax error though:
:086> n[10]
^ Syntax error in 'n[10]'
Any idea what am I doing wrong?
It seems that you are using square brackets when you shouldn't. On the MSDN page, those square brackets are there to show that the radix argument is optional.
When the argument is left off, the current radix is displayed to you.
0:000> n
base is 10
When you provide the argument (with no square brackets) the current radix is changed and echoed back to you.
0:000> n 16
base is 16
A commonly used trick once the base is set is to use the ? (Evaluate Expression) command to convert numbers to the new base (in this example, base 16).
0:000> ? 0n10
Evaluate expression: 10 = 0000000a
0:000> ? 0y11
Evaluate expression: 11 = 00000003
To convert from hex (base 16) back to decimal:
0:000> ? a
Evaluate expression: 10 = 0000000a
Remember that once the base is set, both input and output are affected meaning that when you want to enter a number that isn't is the current base, you will need to specify the base as was done above in the final example. Further reading on how numbers are handled in the MASM-like syntax is available here.
But back to your original question...
Yes, n 10 should be enough to force numbers to be displayed in decimal. If for some reason there is a problem, you can always use the ? command as shown above to perform the conversion.
Extended article describing how WinDbg evaluates expressions (including details on the impact of the n command) available here:
https://www.osronline.com/article.cfm?id=540
try using the command:-
.enable_long_status 0