Scilab documentation for all versions shows that readb is the exact function I'm looking for but it is not recognized by the interpreter (I get Undefined variable: readb)
I'd love to use
pileofdata = readb(filename.bin, -1, 32) or even something that breaks up the data based on formatted input (ushort, ushort, long long, …) so I get arrays of my information right away.
I could use something to find the length of the binary file then use mgeti for the integers (and skip the floats), but this seems silly/inefficient. This seems to defeat the point of using binary data.
any tips? Thanks.
Related
I am trying to read a .tif-file in julia as a Floating Point Array. With the FileIO & ImageMagick-Package I am able to do this, but the Array that I get is of the Type Array{ColorTypes.Gray{FixedPointNumbers.Normed{UInt8,8}},2}.
I can convert this FixedPoint-Array to Float32-Array by multiplying it with 255 (because UInt8), but I am looking for a function to do this for any type of FixedPointNumber (i.e. reinterpret() or convert()).
using FileIO
# Load the tif
obj = load("test.tif");
typeof(obj)
# Convert to Float32-Array
objNew = real.(obj) .* 255
typeof(objNew)
The output is
julia> using FileIO
julia> obj = load("test.tif");
julia> typeof(obj)
Array{ColorTypes.Gray{FixedPointNumbers.Normed{UInt8,8}},2}
julia> objNew = real.(obj) .* 255;
julia> typeof(objNew)
Array{Float32,2}
I have been looking in the docs quite a while and have not found the function with which to convert a given FixedPoint-Array to a FloatingPont-Array without multiplying it with the maximum value of the Integer type.
Thanks for any help.
edit:
I made a small gist to see if the solution by Michael works, and it does. Thanks!
Note:I don't know why, but the real.(obj) .* 255-code does not work (see the gist).
Why not just Float32.()?
using ColorTypes
a = Gray.(convert.(Normed{UInt8,8}, rand(5,6)));
typeof(a)
#Array{ColorTypes.Gray{FixedPointNumbers.Normed{UInt8,8}},2}
Float32.(a)
The short answer is indeed the one given by Michael, just use Float32.(a) (for grayscale). Another alternative is channelview(a), which generally performs channel separation thus also stripping the color information from the array. In the latter case you won't get a Float32 array, because your image is stored with 8 bits per pixel, instead you'll get an N0f8 (= FixedPointNumbers.Normed{UInt8,8}). You can read about those numbers here.
Your instinct to multiply by 255 is natural, given how other image-processing frameworks work, but Julia has made some effort to be consistent about "meaning" in ways that are worth taking a moment to think about. For example, in another programming language just changing the numerical precision of an array:
img = uint8(255*rand(10, 10, 3)); % an 8-bit per color channel image
figure; image(img)
imgd = double(img); % convert to double-precision, but don't change the values
figure; image(imgd)
produces the following surprising result:
That second "all white" image represents saturation. In this other language, "5" means two completely different things depending on whether it's stored in memory as a UInt8 vs a Float64. I think it's fair to say that under any normal circumstances, a user of a numerical library would call this a bug, and a very serious one at that, yet somehow many of us have grown to accept this in the context of image processing.
These new types arise because in Julia we've gone to the effort to implement new numerical types (FixedPointNumbers) that act like fractional values (e.g., between 0 and 1) but are stored internally with the same bit pattern as the "corresponding" UInt8 (the one you get by multiplying by 255). This allows us to work with 8-bit data and yet allow values to always be interpreted on a consistent scale (0.0=black, 1.0=white).
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 am writing the documentation for a function of an R package I am building.
In order to have a moderately nice aspect for the help file, I need the equivalent of \bar{x} in ASCII:
\eqn{\bar{x}}{ASCII equivalent}
Not sure there's a consensus on the best way to do this, it's more a matter of taste and clarity.
Having faced this issue myself, two solutions I have used are:
y = \eqn{\bar{x}}{xbar}
y = \eqn{\bar{x}}{mean(x)}
The advantage of the latter is that when the help is displayed as ASCII, the user can copy/paste (send) the text to an R process, getting an example value for y. This assumes that \bar{x} is shorthand for the mean, as is often the case.
I like solving my math problems(high school) using R as it is faster than writing on a piece of paper. One problem I'm having is that I have to keep writing the multiplication sign, example:
9x^2 + 24x + 16 yields = Error: unexpected symbol in "9x"
Is there any way in R to multiply 4x, without having to write 4*x but only 4x?
Would save me some time in having to write one extra character the whole time! Thanks
No. Having a number in front of a character without any space simply isn't valid syntax in R.
Take a step back and look at the syntax rules for, say, Excel, Matlab, Python, Mathematica. Every language has its rules, generally (:-) ) with good reason. For example, in R, the following are legal object names:
foo
foo.bar
foo1
foo39
But 39foo is not legal. So if you wanted any sequence [0-9][Letters] or the reverse to indicate multiplication, you'd have a conflict with naming rules.
I'm trying to run a large batch of data through my IDL program, but when I do I get nonsensical results.
If I split up the input and then give each piece to the program separately and then stitch the output together it works fine. This has led to to think there is an overflow problem occurring somewhere in the code, but I haven't had any luck debugging it so far.
Is there a way that I can change the default data type size in IDL so that if I declare a variable such as...
A = functionCall(blah,blah2)
it will initiate the variable as a 32bit value instead of a 16bit (which is the default)?
I know you can do this manually by doing
A = long(functionCall(blah,blah2))
by my code is a few thousand lines long and I'd rather not go through and manually change this for every variable.
If all you want to do is to default to 32-bit integers, you can put a compile_opt statement in your codes. Put
compile_opt defint32
at the top of your routines. Or,
compile_opt idl2
which is shorthand for defint32 and strictarr (enforces using square brackets for indexing). This will make IDL use 32-bit integers everywhere it would normally have used 16-bit integers.
However, I'm not sure how this addresses your 'large data' problem. You may want to use
help, /mem
to check your memory usage.