I am new to F# and I do not understand how a bit shift works in F#.
I tried the command below in fsi.
> 4
- |>((<<<) 1uy);;
The screen shot is as below.
Why is this result 16uy but not 8uy?
Even confused me more when I tried the command below because the result is 48uy...
> 4
- |>((<<<) 3uy);;
Would you somebody describe me how this works?
From the documentation:
Bitwise left-shift operator. The result is the first operand with bits shifted left by the number of bits in the second operand. Bits shifted off the most significant position are not rotated into the least significant position. The least significant bits are padded with zeros. The type of the second argument is int32.
It's been a while since I've used F#, but assuming its operator prefixing works like Haskell's then the way you've used it:
4 |> ((<<<) 1uy)
will apply 1 as the left-hand argument, and 4 as the right-hand argument:
1 <<< 4
Which will be 16.
To get it to equal 8, try removing the parentheses around the operator itself (meaning it won't be prefixed but instead just partially applied with the right-hand argument) to get:
4 |> (<<< 1uy)
and that should give you 8, assuming it's valid F# syntax.
Related
Is there an erlang equivalent of codePointAt from js? One that gets the code point starting at a byte offset, without modifying the underlying string/binary?
You can use bit syntax pattern matching to skip the first N bytes and decode the first character from the remaining bytes as UTF-8:
1> CodePointAt = fun(Binary, Offset) ->
<<_:Offset/binary, Char/utf8, _/binary>> = Binary,
Char
end.
Test:
2> CodePointAt(<<"πr²"/utf8>>, 0).
960
3> CodePointAt(<<"πr²"/utf8>>, 1).
** exception error: no match of right hand side value <<207,128,114,194,178>>
4> CodePointAt(<<"πr²"/utf8>>, 2).
114
5> CodePointAt(<<"πr²"/utf8>>, 3).
178
6> CodePointAt(<<"πr²"/utf8>>, 4).
** exception error: no match of right hand side value <<207,128,114,194,178>>
7> CodePointAt(<<"πr²"/utf8>>, 5).
** exception error: no match of right hand side value <<207,128,114,194,178>>
As you can see, if the offset is not in a valid UTF-8 character boundary, the function will throw an error. You can handle that differently using a case expression if needed.
First, remember that only binary strings are using UTF-8 in Erlang. Plain double-quote strings are already just lists of code points (much like UTF-32). The unicode:chardata() type represents both of these kinds of strings, including mixed lists like ["Hello", $\s, [<<"Filip"/utf8>>, $!]]. You can use unicode:characters_to_list(Chardata) or unicode:characters_to_binary(Chardata) to get a flattened version to work with if needed.
Meanwhile, the JS codePointAt function works on UTF-16 encoded strings, which is what JavaScript uses. Note that the index in this case is not a byte position, but the index of the 16-bit units of the encoding. And UTF-16 is also a variable length encoding: code points that need more than 16 bits use a kind of escape sequence called "surrogate pairs" - for example emojis like 👍 - so if such characters can occur, the index is misleading: in "a👍z" (in JavaScript), the a is at 0, but the z is not at 2 but at 3.
What you want is probably what's called the "grapheme clusters" - those that look like a single thing when printed (see the docs for Erlang's string module: https://www.erlang.org/doc/man/string.html). And you can't really use numerical indexes to dig the grapheme clusters out from a string - you need to iterate over the string from the start, getting them out one at a time. This can be done with string:next_grapheme(Chardata) (see https://www.erlang.org/doc/man/string.html#next_grapheme-1) or if you for some reason really need to index them numerically, you could insert the individual cluster substrings in an array (see https://www.erlang.org/doc/man/array.html). For example: array:from_list(string:to_graphemes(Chardata)).
There is one thing which I don't understand about reference modification in Cobol.
The example goes like this:
MOVE VARIABLE(VARIABLE2 +4:2) TO VARIABLE3
Now I do not qutie understand what the "+4:2" references to. Does it mean that the first two signs 4 signs after the target are moved? Meaning if for example VARIABLE (the 1st) is filled with "123456789" and VARIABLE2 contains the 2nd and 3rd position within that variable (so"23"), the target is "23 +4" meaning "789". Then the first two positions in the target (indicated by the ":2") are moved to VARIABLE3. So in the end VARIABLE3 would contain "78".
Am I understanding this right or am I making a false assumption about that instruction?
(VARIABLE2 +4:2) is a syntax error, because the starting position must be an arithmetic expression. There must be a space after the + for this reference modification to be valid. And, VARIABLE2 must be numeric and the expression shall evaluate to an integer.
Once corrected, then 4 is added to the content of VARIABLE2. That is the left-most (or starting position) within VARIABLE1 for the move. 2 characters are moved to VARIABLE3. If VARIABLE3 is longer than two characters, the remaining positions are filled with spaces.
From the 2002 COBOL standard:
8.7.1 Arithmetic operators
There are five binary arithmetic operators and two unary arithmetic operators that may be used in arithmetic expressions. They are represented by specific COBOL characters that shall be preceded by a space and followed by a space except that no space is required between a left parenthesis and a unary operator or between a unary operator and a left parenthesis.
Emphasis added.
In a rails 3.2 , ruby 1.9.3 app
Trying to perform a simple -1 action on an integer:
doing this on the model:
order_details[:quantity].to_i - 1
and getting the ArgumentError: invalid radix -1
Tried to look this up online , and found very little documentation.
Any help, pls?
I'm assuming order_details[:quantity] is a String (though the answer is the same regardless).
String#to_i takes an optional argument for the base the number is to be interpreted as. For instance "10101".to_i(2) will parse as base 2, (giving the decimal 21 as a result). Your line of code is being interpreted as
order_details[:quantity].to_i(-1)
and since a base of negative one (-1) makes no sense, it's giving you that error. The solution is to put parentheses around order_details[:quantity].to_i so that it's evaluated first:
(order_details[:quantity].to_i) - 1
Edit:
Or, make sure there's a space separating - from the two arguments (or no spaces on either side) and Ruby should parse it correctly. It might be that your actual code is written as order_details[:quantity].to_i -1 (note no space between - and 1) causing it to read -1 and then pass it as an argument to to_i.
I think your problem is that your code really looks like this:
order_details[:quantity].to_i -1 # with the minus sign right next to the one
Ruby is parsing this as:
order_details[:quantity].to_i(-1)
Method parameters do not (always) need to be wrapped in parenthesis in Ruby, and to_i takes a parameter that specifies the base in which you are counting.
So you could convert base 16 into our normal base ten like:
"0xA".to_i(16)
iamnotmaynard correctly identified it as a syntax error, but I think it's that you need to separate the - and 1. You could put parenthesis around the first element (it works), but that's more short-circuiting improper syntax instead of supplying proper syntax.
Try separating the elements out without parenthesis:
order_details[:quantity].to_i - 1 # with the space between the 1 and minus sign
Is there a good way to format a minus number with zero padding in Erlang? The following works well for unsigned value, but for minus value, zero is padded before the sign.
io:format("~4..0B~n", [42]).
0042
ok
io:format("~4..0B~n", [-42]).
0-42
ok
What I have in mind is the following format.
(ruby)
1.9.2-p290 :004 > sprintf("%05d", -42)
"-0042"
1.9.2-p290 :005 > sprintf("%05d", 42)
"00042"
(python)
>>> "%05d" % -42
'-0042'
>>> "%05d" % 42
'00042'
I've referred to the following questions, but haven't been able to find one which talks about minus values.
How to format a number with padding in Erlang
Erlang: How to transform a decimale into a Hex string filled with zeros
Currently there is no direct way of doing this in Erlang. The padding char is for the whole field and their is no way of padding just the actual value. The precision field is used for the base with which to print the integer. Using ~w does not help as the precision behaves the same way as the field width. I myself have trying to do this very recently and not come up with a simple solution.
EDIT:
If you look here https://github.com/rvirding/luerl/blob/develop/src/luerl_string.erl#L156 there is a function format which does a C sprintf like formatted output. It is written for a Lua implementation and is probably more general than you need, but look at the function print_integer and print_float for the base handling. I have some better functions on the go which I should be pushing this evening.
I have the following code in an attempt to align things in latex using amsmath package:
\begin{alignat}{3}
\text{max} && c^Tx &=\\
\text{s.t.} && Ax &\leq b \\
&& x &\geq 0
\end{alignat}
Basically, i would like for max and s.t. to be in one column, c^Tx, Ax, x to be in second column, and lastly b and 0 to be in the last column. I'm not sure why it doesn't work (it clumps max and c^Tx together for some reason.
if anyone can help me out with this it would be much appreciated!
With math-mode \text{} you should put in some explicit whitespace such as \quad. But max smells like a log-like symbol so you should be using pre-defined \max or self-defined \operatorname{max} instead of \text{max}.
Additionally, the parameter for the alignat environment should be 2 in this case. The param is the number of alignment structures and can be calculated by solving n from a=2n-1 where a is the number of ampersands on a row. However, it doesn't seem to have a difference in this case.
I believe what's happening here is that max and s.t. are being right-aligned, which is running them right up next to c^Tx and Ax. If you just add some whitespace to the right-hand-side of max and s.t., you should be in business.
(Also, laalto is right, you should definitely use \operatorname{max} if max is some sort of operator or function. Though I'm not really sure what you're doing, so maybe it isn't.)