Swift scientific notation in base 16 - swift

I'm new in Swift language and playing with it. I know in most languages 1.5e3 means 1.5 * 10 ^3 and this is true in Swift. However, when it comes base 16, I have difficulty in understanding it. Below are 2 examples, hope someone can explain what they are:
println(0x12e3)
println(0x12p3)
The results are:
4835
144.0

The first example is not using scientific notation - because e is a valid digit in hexadecimal, this is the number 12E3, which is 4835 in decimal.
(1 * 4096) + (2 * 256) + (14 * 16) + (3 * 1) = 4835
The second example is the hex number 12 (18 in decimal) multiplied by a binary exponent (2 ^ 3), i.e. 8.
8 x 18 = 144
This notation is described in the Swift language documentation.

Related

Number base that makes 32 + 12 = 28 true? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I need to figure out what number base makes the expression 32 + 12 = 28 true. It looks like the second number is signed, I've tried converting to decimal and using 10's complement but haven't gotten an answer that makes sense.
If this is a positional number system, then you can replace the numerals with an expression showing how their digits multiply by the meaning of their columns.
That is,
"32 + 12 = 28"
≣ (3*R^1 + 2*R^0) + (1*R^1 + 2*R^0) = (2*R^1 + 8*R^0)
≣ (3*R + 2*1) + (1*R + 2*1) = (2*R + 8*1)
≣ (3*R + 2) + (1*R + 2) = (2*R + 8)
≣ 4*R + 4 = 2*R + 8
≣ 2*R = 4
≣ R = 2
For some radix R.
You can solve this equation to get the value of R. If you attempt to solve it, you'll see that you get R = 2, which clearly can't be the case, since you have a digit 3 (a base-2 system would only have ... 2 digits. 0, and 1).
Thus, there is no radix R that would allows "32 + 12 = 28" to encode a valid equation.
On the face of it, it looks impossible. Adding positive integers in any base should result in a larger integer; if the second integer is negative, you end up with 20 = 28 which is clearly impossible. Considered modulo arithmetic? 32 mod 4 is 0, 12 mod 4 is 0, 28 mod 4 is 0, 0 + 0 = 0.

Maxima. How to prevent degree calculations

Is it possible for all calculations in the expression for numbers in a power to be prevented? Perhaps by pre-processing the expression or adding tellsimp rules? Or some other way?
For example, to
distrib (10 ^ 10 * (x + 1));
which produces:
1000000000 x + 1000000000
instead issued:
10 ^ 10 * x + 10 ^ 10
And similarly
factor (10 ^ 10 * x + 10 ^ 10);
returned:
10 ^ 10 * (x + 1);
Just as
factor(200);
2^3*5^2
represents power of numbers, only permanently?
Interesting question, although I don't see a good solution. Here's something I tried as an experiment, which is to display integers in factored form. I am working with Maxima 5.44.0 + SBCL.
(%i1) :lisp (defun integer-formatter (x) ($factor x))
INTEGER-FORMATTER
(%i1) :lisp (setf (get 'integer 'formatter) 'integer-formatter)
INTEGER-FORMATTER
(%i1) (x + 1000)^3;
3 3 3
(%o1) (x + 2 5 )
(%i2) 10^10*(x + 1);
2 5 2 5
(%o2) (2 5 ) (x + 1)
This is only a modification of the display; the internal representation is just a single integer.
(%i3) :lisp $%
((MTIMES SIMP) 10000000000 ((MPLUS SIMP) 1 $X))
That seems kind of clumsy, since e.g. 2^(2*5)*5^(2*5) isn't really more comprehensible than 10000000000.
A separate question is whether the arithmetic on 10^10 could be suppressed, so it actually stays as 10^10 and isn't represented internally as 10000000000. I'm pretty sure that would be difficult. Unfortunately Maxima is not too good with retracting identities which are applied, particularly with the built-in identities which are applied to perform arithmetic and other operations.

finding values of x and y using Octal Base system

In finding the values of x and y, if (x567) + (2yx5) = (71yx) ( all in base 8) I proceeded as under.
I assumed x=abc and y=def and followed.
(abc+010 def+101 110+abc 111+101)=(111 001 def abc) //adding ()+()=() and equating LHS=RHS.
abc=111-010=101 which is 5 in base 8 and then def=001-101 which is -4
so x=5 and y=-4
Now the Question is that the answer mentioned in my book is x=4 and y=3.
Is the above method correct.If so,then what's issue here ??
you can't compare the digits beginning with the most significant digit, because you don't know the carry from the digit below. Also a digit cannot have a negative value.
You can start with the least significant digit, because there is no carry:
7 + 5 = 14
so x = 4 with a carry of 1 at the next digit.
now you can rewrite your equation to:
(4567) + (2y45) = (71y4)
now you can look at the second least significant digit (the carry in mind):
6 + 4 + 1 (carry) = 13
so y = 3, also with a carry of 1.
the whole equation is:
(4567) + (2345) = (7134)
which is true for the octal system.

Bin to dec fractional part in perl

Is there any internal function in Perl to convert binary number with fractional part into decimal? I know how to convert integer numbers but what about numbers with a decimal point?
e.g. 1010.1012 = 10.62510
No, there's no builtin that does this.
However, it's easy to calculate. 1010.1012 is simply 10101012 / 23, so
Remove the ".".
Convert the resulting integer.
Divide by 2**$decimal_places.
Or you could do the conversion yourself. 1010.1012 is
1 * 2**3
0 * 2**2
1 * 2**1
0 * 2**0
.
1 * 2**(-1)
0 * 2**(-2)
+ 1 * 2**(-3)
--------------
10.625

Calculations with Real Numbers, Verilog HDL

I noticed that Verilog rounds my real number results into integer results. For example when I look at simulator, it shows the result of 17/2 as 9. What should I do? Is there anyway to define something like a: output real reg [11:0] output_value ? Or is it something that has to be done by simulator settings?
Simulation only (no synthesis). Example:
x defined as a signed input and output_value defined as output reg.
output_value = ((x >>> 1) + x) + 5;
If x=+1 then output value has to be: 13/2=6.5.
However when I simulate I see output_value = 6.
Code would help, but I suspect your not dividing reals at all. 17 and 2 are integers, and so a simple statement like that will do integer division.
17 / 2 = 8 (not 9, always rounds towards 0)
17.0 / 2.0 = 8.5
In your second case
output_value = ((x >>> 1) + x) + 5
If x is 1, x >>> 1 is 0, not 0.5 because you've just gone off the bottom of the word.
output_value = ((1 >>> 1) + 1) + 5 = 0 + 1 + 5 = 6
There's nothing special about verilog here. This is true for the majority of languages.