I'm trying to let i be the square root of -1 (sqrt(-1)). It is a defined value:
i = sqrt(-1)
var i = sqrt(-1);
fill(0, 0, 0);
text(i, 25, 25);
It gives me an error. What happened?
sqrt() is a function that already has a defined behavior. From MDN:
The square root of the given number. If the number is negative, NaN is returned.
NaN is not an error in itself. It's a value that means "not a number" - you can find more information here.
You seem to be thinking about functions and values in a different direction than I would. Looking at this line:
var i = sqrt(-1);
This line isn't saying "define the square root of -1 to be equal to i". It's saying: create a variable named i, and set its value equal to whatever is returned by calling sqrt(-1).
So the code calls sqrt(-1), which returns NaN, so the value of i is NaN. Then when you try to use that value, you'll see NaN.
Related
I cannot find a similar question. But i have a df with some columns highly skewed. I then plan to log transform these columns then standardize. However when i log transform i then get NaNs, should i replace these with 0;s?
log_train[skew_cols]=np.log2(featuresdf[skew_cols]
error i get is:
RuntimeWarning: invalid value encountered in log2
This is separate from the ipykernel package so we can avoid doing imports until
not sure what i am doing wrong
You shouldn't replace with 0's, because np.log(1) is equal to 0. So then both 1, and 0 will be 0 in your log data.
Instead, just +1 your data prior to the log. Therefore log2(1) becomes 0, log2(2) (which was 1) is still 1, then log2(3) (which was 2) is now 1.58)
So the code would be:
log_train[skew_cols]=np.log2(featuresdf[skew_cols]+1)
The other option is to use other scaling methods that can handle 0, such as square root (np.sqrt)
New to elm here, and at first it's driving me absolutely crazy not knowing the ins and outs of this picky language (even after reading a sh**load about it because it's just so different and finicky... I guess that's the nature of a functional lang) so when you try doing a simple thing it's like pulling hair at first.
I am getting the following error:
The right side of (==) is causing a type mismatch.
29| get 0 arrayOfValues == 'X'
^^^
(==) is expecting the right side to be a:
Maybe Char
But the right side is:
Char
Hint: With operators like (==) I always check the left side first. If it seems
fine, I assume it is correct and check the right side. So the problem may be in
how the left and right arguments interact.
Test:
it "blah blah blah" <|
let
someArray =
[ 'P', ' ' ]
in
expect (MyModule.doSomething someArray 'P') to equal 1
MyModule
doSomething : List Char -> Char -> Int
doSomething arrayOfValues symbol =
let
grid =
fromList arrayOfValues
found =
get 0 arrayOfValues == symbol
in
if found then
1
else
0
Now I'm assuming but not sure, that it's getting Nothing or something when trying to pull the first value out of my array but not sure. Maybe Char I assume is returning Nothing? donno, probably have other issues going on with it too.
I'd like to get the code above working, then refactor..I'm sure there's probably a more elegant way to code what I've coded above but first thing's first, fixing this error and understanding it better with the existing code. The error message while nice isn't that obvious to me as to how and what to handle. I have assumptions but not fully sure how to handle the behavior here of whatever is causing the issue.
Unique feature of the elm is certainty. Any variable (which is not of type maybe) will have a value of the defined type for sure.
But when it comes to array or list, it becomes uncertain if the array has an element on index "i". There may be an element and there may not be.
Hence elm has concept of Maybe,
so conceptually
Maybe String = [ Just "string_value" | Nothing ]
the alias for the Array.get is
get : Int -> Array a -> Maybe a
it takes
Int - index and
Array a - array of data type of array element
as parameters and returns
Maybe a - again a is the data type of array element
consider an example
array =
fromList ["one", "two"]
val1 =
get 0 array -- will return 'Just "one"'
val2 =
get 3 array -- will return 'Nothing', since the element does not exists
this way you will always have to handle both the situations, when you have a value and when you don't
case val1 of
Nothing ->
-- Raise some error message
Just val ->
-- `val` is the actual element/value found
and if you always need a default value, you can use
Maybe.withDefault "default_string" val1
this will always return a string value and will return "default_string" when the value is nothing otherwise the actual found value
I want to take the modulus of a value when using Impala and I am aware of the abs() function. When I use this however like such
select abs(value) from table
It returns a value that is rounded to the nearest integer. The documentation found here states that I need to define the numeric_type. have tried this
select abs(float value) from table
but this gives me the following error
AnalysisException: Syntax error in line 1: ... abs(float value) from table ^ Encountered: FLOAT Expected: ALL, CASE, CAST, DEFAULT, DISTINCT, EXISTS, FALSE, IF, INTERVAL, NOT, NULL, TRUNCATE, TRUE, IDENTIFIER CAUSED BY: Exception: Syntax error
Any ideas how I set abs() to return a float?
This should work SELECT cast(Abs(-243.5) as float) AS AbsNum
I think you are misunderstanding the syntax. You call the function as abs(val). The return type is the same as the input type. It should work on integers, decimals, and floats.
If you want a particular type being returned, then you need to pass in that type, perhaps casting to the specific type.
The documentation is:
abs(numeric_type a)
Purpose: Returns the absolute value of the argument.
Return type: Same as the input value
Admittedly, this does look like the type should be part of the function call. But it is really using a programming language-style declaration to show the types that are expected.
Going to be answering my own question here, but I wanted to post this to get some attention in case anyone else ever comes across this.
Within the BusinessObjects Data Services Designer, I have two decimal(36, 10) values, and I'd like to divide one by the other. In order to account for divide-by-zero situations, I have to first check if the denominator is zero, so I end up with an ifthenelse statement like the following:
ifthenelse(Query.Denominator = 0, 0, Query.Numerator / Query.Denominator)
When I execute my job, however, I end up always getting 0 or 1, rather than a decimal value.
And as I said, I already had an answer here, just wanted to provide this for the community.
An ifthenelse statement is interesting, in that it takes its data type from the second parameter. In the code example above, it assumes the correct data type is the data type of the parameter "0", which happens to be an integer.
When the ifthenelse receives a value from "else", it converts it to an integer. So a value of 0.356 becomes 0 and 0.576 becomes 1.
The trick is to cast the "0" to a decimal(36, 10):
ifthenelse(Query.Denominator = 0, cast(0, 'Decimal(36, 10)'), Query.Numerator / Query.Denominator)
Thanks for this, I thought I was going crazy!
Incidentally, for something slightly simpler, this also works:
ifthenelse(Query.Denominator = 0, 0.0, Query.Numerator / Query.Denominator)
Why is it that not the value of b gets printed in the following example but the symbolname? How can I force the printing of the actual dynamic value of the variable?
a = {1, 2, 3};
DynamicModule[{b},
Print[Dynamic[b]];
{Dynamic[a], Dynamic[b]}
,
Initialization :> (b = Length[a]; a = a + 2)
]
output:
b$107
Out[2]= {{3, 4, 5}, 3}
Edit (after reading your answers/comments):
Consider the more simple example, without Initialization code (to get around WReach's example):
a = {1, 2, 3};
DynamicModule[{b = Length[a]},
Print[Dynamic[b]];
{Dynamic[a], Dynamic[b]}
]
output:
During evaluation of In[4]:= b$602
Out[5]= {{1, 2, 3}, 3}
Note, that this example does what I want to if I use Module instead of DynamicModule or leave out Dynamic from the Print line. My concerns are:
Why does this second example fail to print the value of b correctly? There is no Initialization, which (according to the help) contains "an expression to evaluate when the DynamicModule is first displayed". Also according to help: "When DynamicModule is first evaluated, initial assignments for local variables are made first, and then any setting for the Initialization option is evaluated."
The help should read: "Initialization: an expression to evaluate when the result of DynamicModule is first displayed", meaning that a Print statement onscreen does not constitute the "result" of the DynamicModule. If this is correct, then (and only then) I understand why the Print statement does not mean that the Dynamic object appears correctly.
I believe this happens because the Dynamic object b has not been displayed at the time the Print statement is called, and therefore the initialization has not been made. As I recall, Dynamic functionality does not operate until it is actually, visibly displayed.
See Why won't this work? Dynamic in a Select for more information.
In response to your update, my theory is that the Dynamic statement within Print in never displayed by the FrontEnd, and therefore it is never actually initialized. That is, it remains a unique placeholder, waiting to be filled by the dynamic value of b when it is finally displayed.
One may see from the example below that the assignment RHS evaluation takes place before the body Print, at least by measure of the display order in the FrontEnd. Further, we see that Print "goes inside" Dynamic and takes the unique symbol name created by DynamicModule, and prints that. We can use ToString to cause Print to display the entire expression as it is. Likewise, if we extract the symbol name from that string, and convert it to an actual symbol, before printing, we get the expected value that has indeed already been assigned.
alarm := (Print["Initialized!"]; 3)
DynamicModule[{b = alarm},
Print # ToString # Dynamic # b;
Print # Symbol # StringTake[ToString#Dynamic#b, {9, -2}];
Print # Dynamic # b;
];
Output:
Initialized!
Dynamic[b$701]
3
b$701
The crucial behaviour is described under the More Information section of the documentation for DynamicModule:
DynamicModule first gives unique names to local variables in expr,
just like Module, then evaluates the resulting expression, and then
returns a version of this wrapped in DynamicModule.
The exact sequence of events becomes more apparent if you add a Print statement to the Initialization option, thus:
a = {1, 2, 3};
DynamicModule[{b},
Print[Dynamic[b]];
{Dynamic[a], Dynamic[b]}
,
Initialization :> (b = Length[a]; Print["init:", b]; a = a + 2)
]
resulting in three cells:
b$107
Out[7]= {{3, 4, 5}, 3}
init:3
The cell containing b$107 is the result of the Print inside the DynamicModule. Then, we get the result cell (tagged Out[7] here). Finally, we see the third cell output by Print statement in the Initialization.
If you inspect the cell expression of the Out[7] cell, you will find that the localized variable is b$$. This is different from the variable in the first cell, which is b$107. This difference is attributable to the "double scoping" described in the DynamicModule documentation. The b$107 cell contains a Dynamic box, as can be seen if we assign a value to b$107.
Update
In response to the updated question...
Returning to the original expression (without the extra Print in the Initialization), the exact sequence of events is as follows:
First, the body of the DynamicModule is evaluated after giving "unique names to local variables [...] just like Module". That is, this expression is evaluated:
Print[Dynamic[b$107]]; {Dynamic[a], Dynamic[b$107]}
The result of this expression is the list {Dynamic[a], Dynamic[b$107]}. As a side-effect, a dynamic cell containing b$107 is created but that cell is now removed from further consideration as it is not part of the result of the evaluation. Now, "a version of [{Dynamic[a], Dynamic[b$107]}] is wrapped in DynamicModule" and returned. This is evaluated and implicitly printed to produce an output cell expression like this:
Cell[BoxData[
DynamicModuleBox[{$CellContext`b$$ = 3},
RowBox[{"{",
RowBox[{
DynamicBox[ToBoxes[$CellContext`a, StandardForm],
ImageSizeCache->{57., {2., 8.}}], ",",
DynamicBox[ToBoxes[$CellContext`b$$, StandardForm],
ImageSizeCache->{7., {0., 8.}}]}], "}"}],
DynamicModuleValues:>{},
Initialization:>($CellContext`b$$ =
Length[$CellContext`a]; $CellContext`a = $CellContext`a + 2)]], "Output"]
Note particularly that b$107 is renamed to $CellContext`b$$ as a function of DynamicModule symbol localization. The Initialization expression is now evaluated as the box is displayed and visible.
The key point is that the printed cell containing b$107 is not coupled in any way to the final DynamicModule cell.