I was surprised to see numpy.ones_like listed in the list of ufuncs here. Is this just an oversight, or is there specific use case?
That is an oversight in the documentation. ones_like is not a ufunc. It is implemented in numpy/core/numeric.py, along with zeros_like and similar functions. It uses the shape and data type of the argument, but it does not perform an elementwise operation.
Related
Following is the signature for the replace method in Pandas API (https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.replace.html)
DataFrame.replace(to_replace=None, value=_NoDefault.no_default, *,
inplace=False, limit=None, regex=False, method=_NoDefault.no_default)
While I understand the API method, I do not understand what does that * refer to in the arguments string. My guess would be that it is something related to *args. Perhaps *-like notation can be used after the second argument, but I wanted some clarity on this
This is to make all arguments after it keyword only. The * catches the third and more unnamed parameters.
Thus in this method, only to_replace and value can be passed directly:
df.replace('a', 'b')
pandas had been transitioning from classical ordered parameter to keyword-only for many methods lately. This improves on usability/readability for many cases. For instance pivot/pivot_table have so far similar parameters but in a different order, which makes it difficult to remember. In the future, enforcing keyword-only will make it unambiguous.
I am learning about higher order functions[HOF] and lambda in Kotlin.
I checked the Kotlin docs but didn't understand it, I found one benefit of HOF:
You can perform any operations on functions that are possible for other non-function values.
so, What are 'non-functional values'?
and What are those 'operations'?
In a higher order function if a lambda is taking two parameters and returning a value, then can't we just use a function for it?
and what is the real scenario when we have return a function?
I have seen real programs in Kotlin, but I haven't seen any use of lambda or HOF in them.
I want to understand why, else many of the features would just go unused.
It's just a part of the Kotlin syntax that makes it more concise and understandable.
For example, try to imagine this code without using lambdas and HOF like map, filter etc:
val sum = listOfInts.filter{it % 2 == 0}.map{it*it}.sumOf{it % 10}
Type-safe builders is a cool thing too.
These functions are widely used in many libraries and frameworks, like Compose by Google. The first thing I remembered - State hoisting pattern.
Comparing the pages for both methods scan and runningFold (from kotlin.collections), the two appear to be identical save for the name.
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/scan.html
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/running-fold.html
Apparently there is no difference, check this out:
runningFold() and runningReduce() are introduced as synonyms for
scan() and scanReduce(). Such names are more consistent with the
related functions fold() and reduce(). In the future, scan() will be
available along with runningFold() since it’s a commonly known name
for this operation. The experimental scanReduce(), however, will be
deprecated and removed soon.
source: https://blog.jetbrains.com/kotlin/2020/05/1-4-m2-standard-library/
Is there any differences on features or performance between them, or it's just an alias for different version.
return types are different. see reference
tensorflow::ops::ResourceApplyAdam
Returns: the created Operation
tensorflow::ops::ApplyAdam
Output: Same as "var".
reference
ResourceApplyAdam
ApplyAdam
Read the Documentation carefully, along with return type, public attributes, public functions are also different
Resource apply adam
Apply Adam
I have been using different forms of Mule's Expression language.
I couldn't figure out the difference between
#[flowVars.myVariable]
and
#[flowVars['myVariable']]
They both give the result when there is a variable. But why do they behave differently when the variable is not present?
Like if the variable being called is not available, then the first expression would result in a exception. Whereas the second expression just gives out a warning or prints out as is, if in a logger message.
Why is this difference?
Also when going through the documentation for Mule 3.6 I found that the second expression is not longer shown in the documentation.
Is the expression #[flowVars['myVariable']] being deprecated?
The difference comes from the way MVEL deals with these two different ways of accessing map entries.
#[flowVars['myVariable']] is equivalent to flowVars.get('myVariable'), which does not fail if the flowVars map does not contain the 'myVariable' entry,
#[flowVars.myVariable] treats the flowVars map as a virtual object, leading to an exception if the 'myVariable' entry is missing because in this case it doesn't resolve to a map get but instead to directly using an object member (either a field or a method), which must exist before being accessed.
I don't think #[flowVars['myVariable']] could be deprecated since it's a core feature provided by MVEL.
Reference: http://mvel.codehaus.org/MVEL+2.0+Property+Navigation#MVEL2.0PropertyNavigation-MapAccess
David has given a nice explanation around your question. To extend that explanation I would just like to add that you can use #[flowVars.?myVariable] to make your code null safe. This is equivalent to #[flowVars['myVariable']].
Regarding #[header:originalFilename], as David said this is not MEL. You can get a list of non-mel expressions which are commonly used in Mule applications in the following link.
http://www.mulesoft.org/documentation/display/current/Non-MEL+Expressions+Configuration+Reference