Perl - Square Root results - perl

I am quite new to the world of Perl and I am stuck with the sqrt function.
By stuck I mean the function is not returning the value it should.
After reading a text file with coordinate information, 8 values are stored in separate variables ($x1, $y1, $x2, $y2 and so forth). Then, a subroutine is called, which calculates the distance between the points and then other things. However, it doesn't do what it is supposed to do because the results of the sqrt function are not the ones they should! I thought it was a problem with how the variables were obtained and stored, but after performing the sqrt with the literal values, it also produces a wrong number.
Here are the values
-2130.07 207.56 -2084.46 210.76 -1892.78 -2525.74 -1938.39 -2528.93
And here are the sqrt calculations...
$side1=sqrt(($x1-$x2)^2+($y1-$y2)^2);
$sidecheck=sqrt((-2130.07-(-2084.46))^2+(207.56-210.76)^2);
Both $side1 and $sidecheck return a value of 6.7823 instead of 45.722.
Is there a way to sort this out? Thanks!

In Perl and few other Languages, the power of a number is not the caret, its a double asterisk. So you need to write
$sidecheck=sqrt((-2130.07-(-2084.46))**2+(207.56-210.76)**2);
The ^ is the bitwise XOR operator. To square a value, use **

Related

random binomial distributed dataset in perl

I try to do in perl what I succeedd in R but is difficult to combine with my downstream needs.
in R I did the following
library("MASS")
d <- rnegbin(100000, mu = 250, theta = 2)
hist(d, breaks=1000, xlim=c(0,1000))
producing the nice graph I need with a peak round 180-200 and a tail to the right.
Could someone help me code the perl equivalent using Math::Random
I tried this but do not get the right shape
use Math::Random qw(random_negative_binomial);
# random_negative_binomial($n, $ne, $p)
# When called in an array context, returns an array of $n outcomes
# generated from the negative binomial distribution with number of
# events $ne and probability of an event in each trial $p.
# When called in a scalar context, generates and returns only one
# such outcome as a scalar, regardless of the value of $n.
# Argument restrictions: $ne is rounded using int(), the result must be positive.
# $p must be between 0 and 1 exclusive.
# I tried different variable values but never got the right shape
my #dist = random_negative_binomial($n, $ne, $p);
what values do I need to mimic the R results?
I need the same range of values on X and the same general shape
Thanks for any help, I did not find illustrated examples of that package
Stephane
I don't know much about statistics, but since nobody else comes forward: I would use the Perl Data Language PDL (which I use for other things) and fetch the PDL::Stats::Distr module. You can find an example that looks somewhat similar to yours here http://pdl-stats.sourceforge.net/Distr.htm. The module includes pmf_binomial (mass function) and mme_binomial (distribution). You will also need the PGPLOT module.
You will need some random data:
$data = pdl 1..100000; ## generate linear 1 - 100000
$data = $data->random; ## make them random between 0..1

Accuracy error in binomials using MATLAB?

The value is absolute integer, not a floating point to be doubted, also, it is not about an overflow since a double value can hold until 2^1024.
fprintf('%f',realmax)
179769313486231570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
The problem I am facing in nchoosek function that it doesn't produce exact values
fprintf('%f\n',nchoosek(55,24));
2488589544741302.000000
While it is a percentage error of 2 regarding that binomian(n,m)=binomial(n-1,m)+binomial(n-1,m-1) as follows
fprintf('%f',nchoosek(55-1,24)+nchoosek(55-1,24-1))
2488589544741301.000000
Ps: The exact value is 2488589544741300
this demo shows
What is wrong with MATLAB?
Your understanding of the realmax function is wrong. It's the maximum value which can be stored, but with such large numbers you have a floating point precision error far above 1. The first integer which can not be stored in a double value is 2^53+1, try 2^53==2^53+1 for a simple example.
If the symbolic toolbox is available, the easiest to implement solution is using it:
>> nchoosek(sym(55),sym(24))
ans =
2488589544741300
There is a difference between something that looks like an integer (55) and something that's actually an integer (in terms of variable type).
The way you're calculating it, your values are stored as floating point (which is what realmax is pointing you to - the largest positive floating point number - check intmax('int64') for the largest possible integer value), so you can get floating point errors. An absolute difference of 2 in a large value is not that unexpected - the actual percentage error is tiny.
Plus, you're using %f in your format string - e.g. asking it to display as floating point.
For nchoosek specifically, from the docs, the output is returned as a nonnegative scalar value, of the same type as inputs n and k, or, if they are different types, of the non-double type (you can only have different input types if one is a double).
In Matlab, when you type a number directly into a function input, it generally defaults to a float. You have to force it to be an integer.
Try instead:
fprintf('%d\n',nchoosek(int64(55),int64(24)));
Note: %d not %f, converting both inputs to specifically integer. The output of nchoosek here should be of type int64.
I don't have access to MATLAB, but since you're obviously okay working with Octave I'll post my observations based on that.
If you look at the Octave source code using edit nchoosek or here you'll see that the equation for calculating the binomial coefficient is quite simple:
A = round (prod ((v-k+1:v)./(1:k)));
As you can see, there are k divisions, each with the possibility of introducing some small error. The next line attempts to be helpful and warn you of the possibility of loss of precision:
if (A*2*k*eps >= 0.5)
warning ("nchoosek", "nchoosek: possible loss of precision");
So, if I may slightly modify your final question, what is wrong with Octave? I would say nothing is wrong. The authors obviously knew of the possibility of imprecision and included a check to warn users when that possibility arises. So the function is working as intended. If you require greater precision for your application than the built-in function provides, it looks as though you'll need to code (or find) something that calculates the intermediate results with greater precision.

Number of outputs from constant anonymous function (anonymous function not known a priori)

This question may initially appear similar to this other question but my situation is a little bit different.
I have a function 'deriv' that takes a symbolic expression as its input, then takes the first derivative of that symbolic expression. That derivative is then converted into an anonymous function using matlabFunction(), and is then evaluated over an array of points. I also use the anonymous function later in some other code.
The problem I'm having is that sometimes the input symbolic expression happens to be linear, and thus the derivative is constant; therefore the anonymous function is also a constant. When I evaluate the anonymous function over the array of points, I only get one output instead of an array of outputs.
Here's some code showing what I'm doing. For the sake of simplicity here, let's assume that the symbolic input expressions will involve only one symbolic variable called q.
function[derivFun,derivVals] = deriv(input)
derivSym = diff(input,q);
derivFun = matlabFunction(derivSym,'vars',q);
evalPoints = [1;2;3;4;5]; %in my true application, a much larger array
derivVals = derivFun(evalPoints);
end
So if the input is q^2, then the output derivVals will be [2;4;6;8;10]. But if the input happens to be, say, 3*q, then derivVals will be 3 (just a single scalar). What I'd like is for derivVals to be [3;3;3;3;3].
That is, I'd like derivVals to be the same size as evalPoints even if the input function happens to be linear (or constant). And I don't know ahead of time what the input expression will be.
Can anyone give suggestions for a scheme that would do that? I understand that a constant anonymous function will just return a single constant scalar, regardless of the size of its input. What I'm hoping for is perhaps some way to recognize when the anonymous function is constant and then still cause derivVals to be the same size as evalPoints.
I know that I could use a for loop to evaluate derivFun for every row of evalPoints, but I'd like to avoid using such a loop if possible.
Thank you for your time and consideration.
I think that this is a slightly simpler solution. The issue is that you're using matlabFunction, which simplifies down the equations and doesn't allow much customization. However, you can create an anonymous function of an anonymous function. Just add the this line right after your matlabFunction line:
derivFun = #(evalPoints)derivFun(evalPoints)+zeros(size(evalPoints));
This only evaluates the original derivFun once. However, I do like you symvar solution (just remember that adding zeros is always better than multiplying ones).
Not 100% sure I got the problem correctly.
Would this solve your issue?:
if isscalar(derivVals)
derivVals = repmat(derivVals, size(evalPoints));
end

convert PDL scalar to Perl scalar

I have a function that uses PDL. The final step is a dot product so it returns a scalar. However, when I try to print this scalar, it is clearly still a piddle and prints like this on screen:
[
[ 3 ]
]
I'm wondering how I can convert it back to the regular Perl scalar so that it prints like:
3
More importantly, what is the consequence if I don't convert and take that piddle on to further arithmetic manipulations in a pure Perl context (that does not involve PDL). Thx!
Use the sclr method, which converts a single-element PDL matrix with any number of dimensions into a simple Perl scalar
my $dotp = sclr($mata x $matb);
To answer the second question ("what is the consequence if I don't convert and take that piddle on to further arithmetic manipulations in a pure Perl context (that does not involve PDL)"); there are two major considerations:
PDL entities ("ndarrays") have overloaded arithmetic so that any Perl scalars used with them will get promoted, and the results will also be ndarrays. For scalar (single-element) ndarrays this is probably undesirable since PDL operations have a performance hit that isn't worth it for a single element
the ndarray shown in the example has one element, but it is 2-dimension (1x1); to be a proper scalar ndarray, you'd do $dotp->squeeze to drop all length-1 dims

Matlab if loop not working

%function [flag] =verify(area)
[FileName,PathName,FilterIndex]= uigetfile('*.tif','Select the signature file');
display(PathName)
m=[PathName,FileName];
area=nor_area(m);
%display(area)
%area=0.8707;
class(area)
flag=0;
extract=xlsread('D:\Project\Image_processing\important\best.xlsx', 'CW4:CW17');
c=numel(extract);
display(c)
l=extract(1);
class(l)
display(l)
for k = 1:c
%x=extract(k);
if (l==area && flag==0)
% display(extract(k));
flag=1;
display(flag)
end
end
display(flag)
The above is my code for verification, i am not able to compare "l==area", even if the values are same am not able to enter inside the loop. If i try passing the value assume l=0.9999 and the area that i obtain to be the same , if i sent l value explicitly it works..!! but if i try using some function and pass the same value it wont work. I have tried checking the type by using class, both returns double.
Can anyone please help me out with this and if this approach is not good, suggest any alternative that may be used.
It is not generally a good idea to compare floats like you are doing (with the == operator) since floats, unlike integer values are subject to round off. See here and here for a discussion on comparing floats in MATLAB.
Essentially you have to check that two floats are 'close enough' rather than exactly equal, which is what == checks for. MATLAB has a built in function eps for determining the floating point precision on your machine, so use that function when comparing floats. See its documentation for more information.
In most cases it is not wise to compare floating point numbers by a == b. Use abs(a-b)<epsilon where epsilonis some small tolerance like 1e-10 instead.