From Octave docs about arithmetic operators § x ** y (power operator):
The implementation of this operator needs to be improved.
Ouch. So basically the documentation says "Please be careful, there are problems with this operator" but falls short of specifying what exact problems are to be expected.
What exactly must a user be aware of when using the ** operator in Octave?
Related
i made a rsa-encryption demo to learn julia but ran into a problem.
this should be no issue of overflow and all values fit rsa criteria when i check with python code.
any pointers are welcome. julia is an awesome language and i would like to figure this out.
check these images to see my problem:
You need BigInt(message)^used_e, and similar. The problem you are seeing is integer overvflow before you convert to BigInt. Note that powermod(BigInt(message), used_e, used_N) will be much faster since it will keep all the intermediate numbers smaller.
Note that in Julia x % y is a synonym for the rem(x, y) function “from Euclidean division, returning a value of the same sign as x”, whereas for an RSA implementation, you need the mod function instead, where the result has the same sign as y. (But you really actually want powermod over BigInt here for performance.)
I am coding GL fractional operator in VHDL to put on FPGA. I am using IEEE.fixed_pkg package in order to have the ufixed and sfixed types and their operations
the problem is that I need at some part to to do raising to power calculation ( h**alpha) where both h and alpha are fixed numbers.
when I tried ** operator with ufixed, I got: No feasible entries for infix operator " ** ". I realized that this operation is not implemented in this package
Now, Is there a way to raise to power for fixed numbers (both base and exponent) without writing implementing the operation my self? ( as this is not the focus of the project).
I just realized that there were loads of really useful mathematic symbols when you hold down the Option key on my MacBook.
≤ ≥ ≠ ÷ • « ∑ √
It’s like a wonderland of mathematical symbols and I would love to map these to different functions in R, for wonderous coding.
Edit - I should clarify, I don’t want to set them as variable names, I was hoping to use them in functions. For example ∑ is the mathematical symbol for sum, so:
∑() <- base::sum()
Or square root
√() <- base::sqrt()
Only problem, of course, is that R doesn’t recognize them.
Unexpected Input
I generally program in the Terminal too. Is there any way to force R to recognize special characters?
In Eiffel, the class DOUBLE_MATH defines trigonometric functions. When I see the interface of this class as shown here, it says
cosine (v: REAL_64): REAL_64
-- Trigonometric cosine of radian `v' approximated
-- in the range [-pi/4, +pi/4]
and
sine (v: REAL_64): REAL_64
-- Trigonometric sine of radian `v' approximated
-- in range [-pi/4, +pi/4]
and
tangent (v: REAL_64): REAL_64
-- Trigonometric tangent of radian `v' approximated
-- in range [-pi/4, +pi/4]
It seems to claim that the trigonometric functions will only work in the domain [-pi/4,+pi/4]. However, when I tried using them for other values, they seemed to work.
I am worried that it might occasionally fail, or that the success I saw is in fact a form of undefined behavior that cannot be relied upon.
Is it safe to use the functions outside the given domain? If so, why is this domain specified? If not, why is it made such that the functions work only in this domain?
The functions are implemented as wrappers of the corresponding C functions from math.h. Because Eiffel can be compiled for virtually any platform with a C compiler, the comment makes sure to restrict the domain to most restrictive domains of C compiler implementations. Also, some CPUs provide direct support for trigonometric functions, but their precision goes down if the input value is beyond a given range.
To summarize, you need to check the manual of the C compiler for the platforms you are going to use for the specific ranges of trigonometric functions, or, alternatively, make sure the input value is in the range as specified in the comment.
Very basic Fortran question. The following function returns a NaN and I can't seem to figure out why:
F_diameter = 1. - (2.71828**(-1.0*((-1. / 30.)**1.4)))
I've fed 2.71... in rather than using exp() but they both fail the same way. I've noticed that I only get a NaN when the fractional part (-1 / 30) is negative. Positives evaluate ok.
Thanks a lot
The problem is that you are taking a root of a negative number, which would give you a complex answer. This is more obvious if you imagine e.g.
(-1) ** (3/2)
which is equivalent to
(1/sqrt(-1))**3
In other words, your fractional exponent can't trivially operate on a negative number.
There is another interesting point here I learned today and I want to add to ire_and_curses answer: The fortran compiler seems to compute powers with integers with successive multiplications.
For example
PROGRAM Test
PRINT *, (-23) ** 6
END PROGRAM
work fine and gives 148035889 as an answer.
But for REAL exponents, the compiler uses logarithms: y**x = 10**(x * log(y)) (maybe compilers today do differently, but my book says so). Now that negative logarithms give a complex result, this does not work:
PROGRAM Test
PRINT *, (-23) ** 6.1
END PROGRAM
and even gives an compiler error:
Error: Raising a negative REAL at (1) to a REAL power is prohibited
From an mathematical point of view, this problem seems also be quite interesting: https://math.stackexchange.com/questions/1211/non-integer-powers-of-negative-numbers