x^y (x power y) key on HP prime calculator when running in RPN mode seems to have flipped x, y values on the stack.
In other words, for a normal HP RPN calculator: 3 enter 4 x^y will give 4^3 = 64. But HP prime gives 3^4 = 81.
Is this a bug or a feature?
It's a feature. Here's the source of your very understandable confusion:
On "old school" RPN calculators (includes the 15C), the stack had only 4 elements, from bottom to top, X, Y, Z, and T. "T" would replicate when the stack dropped to allow for calculations using a "constant."
Y^X on those calculators was labeled as such because you would first enter your base then the exponent followed by the operation, leaving the Y argument in the "Y" stack register and the "X" argument in the "X" stack register. Hence 3 Enter 4 "Y^X" would give 81.
On the new calculators, there is a massive stack (something I personally saw no use for--I never ran out of stack space doing calculations on the old stack EVER in decades of advanced calculations). It made the prior constant calculations impossible on the new calculators without programming. The elements are now simply numbered 1, 2, 3, 4, 5, etc. For entry order, they figured input order of variables should be alphabetic, hence x^y. Since there are no longer stack labels, there is no longer a contradictory model of a Y register and an X register as before, so 3 Enter 4 "X^Y" still gives 81, but there is no contradictory register entry here, just a memory of how an older machine labeled its registers. I don't think many would have mistaken things if it were still labeled "Y^X" as before, and I'm personally not fond of the change, but I can understand the motivation. It is not a bug.
Both hp 48sx and hp 50g return 81 for the op's exmaple. The keys are labeled y^x, not x^y. I'm not sure at what point HP changed this.
Related
Why do I get different results when using the same code running in different version of MATLAB (2016 vs 2021) for sum(b.*x1) where b is single and x1 is double. How to avoid such error between MATLAB version?
MATLAB v.2021:
sum(b.*x1)
ans =
single
-0.0013286
MATLAB 2016
sum(b.*x1)
ans =
single
-0.0013283
In R2017b, they changed the behavior of sum for single-precision floats, and in R2020b they made the same changes for other data types too.
The change speeds up the computation, and improves accuracy by reducing the rounding errors. Simply put, previously the algorithm would just run through the array in sequence, adding up the values. The new behavior computes the sum over smaller portions of the array, and then adds up those results. This is more precise because the running total can become a very large number, and adding smaller numbers to it causes more rounding in those smaller numbers. The speed improvement comes from loop unrolling: the loop now steps over, say, 8 values at the time, and in the loop body, 8 running totals are computed (they don’t specify the number they use, the 8 here is an example).
Thus, your newer result is a better approximation to the sum of your array than the old one.
For more details (a better explanation of the new algorithm and the reason for the change), see this blog post.
Regarding how to avoid the difference: you could implement your own sum function, and use that instead of the builtin one. I would suggest writing it as a MEX-file for efficiency. However, do make sure you match the newer behavior of the builtin sum, as that is the better approximation.
Here is an example of the problem. Let's create an array with N+1 elements, where the first one has a value of N and the rest have a value of 1.
N = 1e8;
a = ones(N+1,1,'single');
a(1) = N;
The sum over this array is expected to be 2*N. If we set N large enough w.r.t. the data type, I see this in R2017a (before the change):
>> sum(a)
ans =
single
150331648
And I see this in R2018b (after the change for single-precision sum):
>> sum(a)
ans =
single
199998976
Both implementations make rounding errors here, but one is obviously much, much closer to the expected result (2e8, or 200000000).
Trying to figure out how to use MPSCNNConvolution. I have a 4 x 3 image, and a 4 x 3 kernel. I'm setting all the weights to 1, and all the inputs to 1, and I sort of expected to get all 1's back. What I get instead is
12 9 6 3
8 6 4 2
4 3 2 1
The problem is that I don't know whether it's supposed to behave like this or not. I've been all over every shred of Apple doc I can find, every online article, every github repo, and I can't find anything that says what kind of output to expect when the layer is set up correctly.
The pattern holds for differently sized images. A 3 x 2 gives me
6 4 2
3 2 1
And a 2 x 2 gives me
4 2
2 1
I've pushed my "minimal" example to github. It's not small. Xcode 12.4 no longer supports Float16, so there's utility code for floating between Float16 and Float32, plus all the convoluted setup for convolution, and yet more code for trying to un-headache un-safe pointers.
My specific questions: is this output "just the normal behavior" for MPSCNNConvolution? Is there a name for this function/algorithm, something I can look up?
The documentation for MPSCNNConvolution is slightly confusing. To the uninitiated, it might seem that MPSCNNConvolution is a kind of container that holds convolution kernels. This is not the case. MPSCNNConvolution is itself a kernel. Specifically, it weights and sums all the input values under the kernel window. Just a straight sum, no averaging or maxing. What you're seeing is the result of the kernel starting at (0, 0) and sliding way off the right edge, and eventually way off the bottom edge.
Set your kernel offset and your clip rectangle on the input image, and MPSCNNConvolution will work the same way as MPSCNNPooling* kernels and all the others
I'm asked to do a program that asks for two numbers, the first variable for example is 4 and the second is 5, i need the program to show the first variable as 5 and the second one as 4, so i need the variables to exchange their values
Thanks :DDDD
I think you are asking for number swapping logic.So you can use two logic to swap the number
1. By using 3rd variable.
2. Without using 3rd variable.
Their respective logic's are as follows.
Suppose you have x=4,y=5;
take 3rd variable like temp;
temp=x; x=y; y=temp;
and 2nd logic.
x = x+y; y=x-y; x=x-y;
Such questions are usually asked to reduce the space complexity and to do so we take the following approach:
a=a+b;
b=a-b;
a=a-b;
for example we take a=4 and b=5
a becomes 9
b becomes 4
a becomes 5
finally a=5 and b=4 (swapped)
The mode-function in Matlab returns the value that occurs most frequently in a dataset. But "when there are multiple values occurring equally frequently, mode returns the smallest of those values."
This is not very useful for what i am using it for, i would rather have it return a median, or arithmetic mean in the absence of a modal value (as they are at least somewhat in the middle of the distibution). Otherwise the results of using mode are far too much on the low side of the scale (i have a lot of unique values in my distribution).
Is there an elegant way to make mode favor more central values in a dataset (in the absence of a true modal value)?
btw.: i know i could use [M,F] = mode(X, ...), to manually check for the most frequent value (and calculate a median or mean when necessary). But that seems like a bit of an awkward solution, since i would be almost entirely rewriting everything that mode is supposed to be doing. I'm hoping that there's a more elegant solution.
Looks like you want the third output argument from mode. EG:
x = [1 1 1 2 2 2 3 3 3 4 4 4 5 6 7 8];
[m,f,c] = mode(x);
valueYouWant = median(c{1});
Or (since median takes the average of values when there are an even number of entries), in the cases where an even number of values may have the same max number of occurrences, maybe do something like this:
valueYouWant = c{1}(ceil(length(c{1})/2))
I have a QBASIC program that basically consists of formulas and constants, and I want to translate the formulas and constants into a C++ programm. Since the formulas are not rocket science and the program is well documented, I have no problem translating the program, although I have not used or seen QBASIC before.
However, there is an initialization of a variable that reads abc(15) = 9.207134000000001D-02, and I am not sure how to interpret the D-02. I guess I should translate it like abc[15] =0.09207134...., but I'd like to verify if this is correct.
If I recall correctly D-02 means times ten raised to the power minus 2.
So 8.309618000000001D-02 = 8.30961800000000 x 10^(-2)
which is roughly 0.08309618
I also think the D means the type of the number is a double.
EDIT: It's been ages since I wrote any QBASIC code
Yes he is right the D means that the number is a double and the -2 after the D means it is multiplied by 10 to the power of negative 2 which means it is 0.08309618 to the precision of qbasics double precision numbers which is 52 or 54 bits If I remember corectly