I have
dummytxt←'abcdefghijk'
texttoadd←'down'
rfikv←20 30 50
and need following output
defghijk20down defghijk30down defghijk50down
I can do it with:
scenv←(¯10↑¨(⊂dummytxt),¨⍕¨rfikv),¨⊂texttoadd
but please help me to write without each operator but using rank ⍤
I use Dyalog APL, but please do not use trains.
Thank you
Expressions using Each, like f¨x, can be expressed in terms of Rank as {⊂f⊃⍵}⍤0⊢x (note that ⊢ is to separate the array right operand, 0 from the array right argument x). In other words, on the scalars of the argument we:
disclose the scalar: ⊃⍵
apply the function: f⊃⍵
enclose the result: ⊂f⊃⍵
A similar expression applies for the dyadic case, x f¨y, but we need to:
disclose both scalars: (⊃⍺)…(⊃⍵)
apply the function: (⊃⍺)f(⊃⍵)
enclose the result: ⊂(⊃⍺)f(⊃⍵)
This gives us x{⊂(⊃⍺)f(⊃⍵)}⍤0⊢y. We can thus use Rank to build our own Each operator which allows both monadic and dyadic application of the derived function:
Each←{⍺←⊢ ⋄ ⍺ ⍺⍺{×⎕NC'⍺':⊂(⊃⍺)⍺⍺(⊃⍵) ⋄ ⊂⍺⍺⊃⍵}⍤0⊢⍵}
(¯10↑Each(⊂dummytxt),Each⍕Each rfikv),Each⊂texttoadd
defghijk20down defghijk30down defghijk50down
Alternatively, we can substitute the two simpler equivalences into your expression:
(¯10{⊂(⊃⍺)↑(⊃⍵)}⍤0⊢(⊂dummytxt){⊂(⊃⍺),(⊃⍵)}⍤0{⊂⍕⊃⍵}⍤0⊢rfikv){⊂(⊃⍺),(⊃⍵)}⍤0⊂texttoadd
defghijk20down defghijk30down defghijk50down
Notice that we are enclosing texttoadd so it becomes scalar, and then we use ⍤0 to address that entire scalar, only to disclose it again. Instead, we can use ⍤0 1 to say that want to use the entire vector right argument when applying the function, which in turn doesn't need to disclose its right argument:
(¯10{⊂(⊃⍺)↑(⊃⍵)}⍤0⊢(⊂dummytxt){⊂(⊃⍺),(⊃⍵)}⍤0{⊂⍕⊃⍵}⍤0⊢rfikv){⊂(⊃⍺),⍵}⍤0 1⊢texttoadd
defghijk20down defghijk30down defghijk50down
rfikv and ¯10 are a simple scalars, so disclosing them has no effect:
(¯10{⊂⍺↑(⊃⍵)}⍤0⊢(⊂dummytxt){⊂(⊃⍺),(⊃⍵)}⍤0{⊂⍕⍵}⍤0⊢rfikv){⊂(⊃⍺),⍵}⍤0 1⊢texttoadd
defghijk20down defghijk30down defghijk50down
dummytxt is in the same situation as texttoadd above, but as left argument, so we can skip the enclose-disclose and ask Rank to use the entire vector left argument; ⍤1 0:
(¯10{⊂⍺↑(⊃⍵)}⍤0⊢dummytxt{⊂⍺,(⊃⍵)}⍤1 0{⊂⍕⍵}⍤0⊢rfikv){⊂(⊃⍺),⍵}⍤0 1⊢texttoadd
defghijk20down defghijk30down defghijk50down
This is about as simple as it gets using a general method. However, if we instead observe that the only non-scalar is rfikv, we can treat dummytxt and texttoadd as global constants and express the entire thing as a single ⍤0 function application on rfikv:
{⊂(¯10↑dummytxt,⍕⍵),texttoadd}⍤0⊢rfikv
defghijk20down defghijk30down defghijk50down
Of course, Each can do this too:
{(¯10↑dummytxt,⍕⍵),texttoadd}¨rfikv
defghijk20down defghijk30down defghijk50down
Related
I have seen that there are two similar functions to create lists in maxima: create_list() and makelist(). In both cases, the arguments can be
(<an expression>, <a variable>, <the initial value>, <the final value>, < the step>) or
(<an expression>, <a variable>, <a list of values for the variable>).
What is the difference between these two functions? I have tried a couple of examples and they seem to work in the same way:
makelist(i^i,i,1,3); -> [1,4,27]
create_list(i^i,i,1,3); -> [1,4,27]
makelist(i^i,i,[1,2,3]); -> [1,4,27]
create_list(i^i,i,[1,2,3]); -> [1,4,27]
If you wish, you can create your own function, with its own syntax, in maxima.
For example, there is no operator ".." but this makes it happen.
infix("..",80,80,expr,expr,expr);
You can then define the semantics ...
here I just call a function named range.
(a..b):= range(a,b)
This doesn't provide for all the embroidery that you might like.
I think a superior technique for syntax and semantics is to enhance the "for" loop as in this example:
for i:1 thru 5 do collect i;
which returns [1,2,3,4,5]
All the varied mechanisms for "for", including step size, limit, iterating through sets, etc. can then be included in computing a list explicitly comprising a range. The code for this is about 7 lines of lisp, inserted into the source code for "parse-$do".
I also allow
for i in [a,b] summing f(i) ; which returns f(b)+f(a).
This enhancement is redundant for the (few) people who are comfortable with map, cons, lambda, apply, append ... in Maxima.
The code, which can be read in to any maxima, is here.
https://people.eecs.berkeley.edu/~fateman/lisp/doparsesum.lisp
I wonder if there is any way to make functions defined within the main function be local, in a similar way to local variables. For example, in this function that calculates the gradient of a scalar function,
grad(var,f) := block([aux],
aux : [gradient, DfDx[i]],
gradient : [],
DfDx[i] := diff(f(x_1,x_2,x_3),var[i],1),
for i in [1,2,3] do (
gradient : append(gradient, [DfDx[i]])
),
return(gradient)
)$
The variable gradient that has been defined inside the main function grad(var,f) has no effect outside the main function, as it is inside the aux list. However, I have observed that the function DfDx, despite being inside the aux list, does have an effect outside the main function.
Is there any way to make the sub-functions defined inside the main function to be local only, in a similar way to what can be made with local variables? (I know that one can kill them once they have been used, but perhaps there is a more elegant way)
To address the problem you are needing to solve here, another way to compute the gradient is to say
grad(var, e) := makelist(diff(e, var1), var1, var);
and then you can say for example
grad([x, y, z], sin(x)*y/z);
to get
cos(x) y sin(x) sin(x) y
[--------, ------, - --------]
z z 2
z
(There isn't a built-in gradient function; this is an oversight.)
About local functions, bear in mind that all function definitions are global. However you can approximate a local function definition via local, which saves and restores all properties of a symbol. Since the function definition is a property, local has the effect of temporarily wiping out an existing function definition and later restoring it. In between you can create a temporary function definition. E.g.
foo(x) := 2*x;
bar(y) := block(local(foo), foo(x) := x - 1, foo(y));
bar(100); /* output is 99 */
foo(100); /* output is 200 */
However, I don't this you need to use local -- just makelist plus diff is enough to compute the gradient.
There is more to say about Maxima's scope rules, named and unnamed functions, etc. I'll try to come back to this question tomorrow.
To compute the gradient, my advice is to call makelist and diff as shown in my first answer. Let me take this opportunity to address some related topics.
I'll paste the definition of grad shown in the problem statement and use that to make some comments.
grad(var,f) := block([aux],
aux : [gradient, DfDx[i]],
gradient : [],
DfDx[i] := diff(f(x_1,x_2,x_3),var[i],1),
for i in [1,2,3] do (
gradient : append(gradient, [DfDx[i]])
),
return(gradient)
)$
(1) Maxima works mostly with expressions as opposed to functions. That's not causing a problem here, I just want to make it clear. E.g. in general one has to say diff(f(x), x) when f is a function, instead of diff(f, x), likewise integrate(f(x), ...) instead of integrate(f, ...).
(2) When gradient and Dfdx are to be the local variables, you have to name them in the list of variables for block. E.g. block([gradient, Dfdx], ...) -- Maxima won't understand block([aux], aux: ...).
(3) Note that a function defined with square brackets instead of parentheses, e.g. f[x] := ... instead of f(x) := ..., is a so-called array function in Maxima. An array function is a memoizing function, i.e. if f[x] is called two or more times, the return value is only computed once, and then returned every time thereafter. Sometimes that's a useful optimization when the domain of the function comprises a finite set.
(4) Bear in mind that x_1, x_2, x_3, are distinct symbols, not related to each other, and not related to x[1], x[2], x[3], even if they are displayed the same. My advice is to work with subscripted symbols x[i] when i is a variable.
(5) About building up return values, try to arrange to compute the whole thing at one go, instead of growing the result incrementally. In this case, makelist is preferable to for plus append.
(6) The return function in Maxima acts differently than in other programming languages; it's a little hard to explain. A function returns the value of the last expression which was evaluated, so if gradient is that last expression, you can just write grad(var, f) := block(..., gradient).
Hope this helps, I know it's obscure and complex. The Maxima programming language was not designed before being implemented, and some of the decisions are clearly questionable at the long interval of more than 50 years (!) later. That's okay, they were figuring it out as they went along. There was not a body of established results which could provide a point of reference; the original authors were contributing to what's considered common knowledge today.
Let's say, I want to declare an elliptic integral as
K(k):=elliptic_kc (k^2);
k:=<something like tanh()*coth()...>
The problem is that maxima will always substitute elliptic_kc(x^2) in place of K(x), and k's definition in place of k.
I want to prevent it, while still allowing numeric evaluation of K(), k, and simplifying expressions with these symbols.
...
A function, can be declared as "noun" for disabling substitution. But this also disables its evaluation.
Well, I use various strategies. Sometimes one approach works better than another.
(1) Put a single quote ' on function names to nounify that specific function call. At a later time, ev(expr, nouns) verbifies any nouns, so the functions are called. E.g. foo: 'integrate(sin(x), x); yields a noun expression. Then ev(foo, nouns); (which can be abbreviated to foo, nouns; at the console input) to actually calculate it.
(2) Don't define functions, but just let them be undefined symbols. Then substitute a lambda expression when you want to evaluate them. E.g. foo: f(2); then later subst(f = lambda([x], x + 1), foo);.
(3) Don't assign values, but let them be undefined, then substitute values later on. E.g. foo: a + b; then later subst([a = 123, b = y*z], foo);.
I'm learning about f# and I understand you don't need to use parentheses when calling a function.
Ex
let addOne arg1 =
arg1 + 1
addOne 1
vs
this.GetType()
Why do I have to use parentheses on the second function?
There is a bit of a mismatch between working with .NET libraries and working with F# libraries when it comes to parameters, but you can generally see () not as parentheses, but as a special value of type unit that means "no useful information".
This means that when you say:
addOne 1
You are calling addOne with a value - number 1 - as a parameter. Now, when you apply the same reading to the second example:
this.GetType()
You can read this as calling this.GetType with a value - the special () unit value as a parameter. If you wanted to be consistent, you could write this with space too:
this.GetType ()
In practice, most people will omit the space when calling .NET libraries. When you do not write the space, F# also supports method chaining so you can write e.g. foo().bar().
Many F# functions taking multiple parameters will use the "curried" form, which means that the parameters need to be separated by spaces. For example:
let add a b = a + b
let mul a b = a * b
add 10 (mul 20 3)
Here, you need parentheses around the second expression, so that the compiler knows how to parse the code. This is in contrast with typical .NET methods, which take parameters as a tuple. F# tuples are written as (10, "hello") and so you can see a method call as an ordinary call accepting a tuple:
some.Operation (10, "Hello")
Again, typically you wouldn't write the space here, because you know this is actually a .NET method call, rather than "passing tuple to a function", but conceptually, you can think of it in both ways.
This is the summary - there are a few corner cases where method calls do not really behave like tuples (e.g. when it comes to named parameters), but this way of thinking about it should give you an idea about how things work.
Are the following two examples equivalent?
Example 1:
let x = String::new();
let y = &x[..];
Example 2:
let x = String::new();
let y = &*x;
Is one more efficient than the other or are they basically the same?
In the case of String and Vec, they do the same thing. In general, however, they aren't quite equivalent.
First, you have to understand Deref. This trait is implemented in cases where a type is logically "wrapping" some lower-level, simpler value. For example, all of the "smart pointer" types (Box, Rc, Arc) implement Deref to give you access to their contents.
It is also implemented for String and Vec: String "derefs" to the simpler str, Vec<T> derefs to the simpler [T].
Writing *s is just manually invoking Deref::deref to turn s into its "simpler form". It is almost always written &*s, however: although the Deref::deref signature says it returns a borrowed pointer (&Target), the compiler inserts a second automatic deref. This is so that, for example, { let x = Box::new(42i32); *x } results in an i32 rather than a &i32.
So &*s is really just shorthand for Deref::deref(&s).
s[..] is syntactic sugar for s.index(RangeFull), implemented by the Index trait. This means to slice the "whole range" of the thing being indexed; for both String and Vec, this gives you a slice of the entire contents. Again, the result is technically a borrowed pointer, but Rust auto-derefs this one as well, so it's also almost always written &s[..].
So what's the difference? Hold that thought; let's talk about Deref chaining.
To take a specific example, because you can view a String as a str, it would be really helpful to have all the methods available on strs automatically available on Strings as well. Rather than inheritance, Rust does this by Deref chaining.
The way it works is that when you ask for a particular method on a value, Rust first looks at the methods defined for that specific type. Let's say it doesn't find the method you asked for; before giving up, Rust will check for a Deref implementation. If it finds one, it invokes it and then tries again.
This means that when you call s.chars() where s is a String, what's actually happening is that you're calling s.deref().chars(), because String doesn't have a method called chars, but str does (scroll up to see that String only gets this method because it implements Deref<Target=str>).
Getting back to the original question, the difference between &*s and &s[..] is in what happens when s is not just String or Vec<T>. Let's take a few examples:
s: String; &*s: &str, &s[..]: &str.
s: &String: &*s: &String, &s[..]: &str.
s: Box<String>: &*s: &String, &s[..]: &str.
s: Box<Rc<&String>>: &*s: &Rc<&String>, &s[..]: &str.
&*s only ever peels away one layer of indirection. &s[..] peels away all of them. This is because none of Box, Rc, &, etc. implement the Index trait, so Deref chaining causes the call to s.index(RangeFull) to chain through all those intermediate layers.
Which one should you use? Whichever you want. Use &*s (or &**s, or &***s) if you want to control exactly how many layers of indirection you want to strip off. Use &s[..] if you want to strip them all off and just get at the innermost representation of the value.
Or, you can do what I do and use &*s because it reads left-to-right, whereas &s[..] reads left-to-right-to-left-again and that annoys me. :)
Addendum
There's the related concept of Deref coercions.
There's also DerefMut and IndexMut which do all of the above, but for &mut instead of &.
They are completely the same for String and Vec.
The [..] syntax results in a call to Index<RangeFull>::index() and it's not just sugar for [0..collection.len()]. The latter would introduce the cost of bound checking. Gladly this is not the case in Rust so they both are equally fast.
Relevant code:
index of String
deref of String
index of Vec (just returns self which triggers the deref coercion thus executes exactly the same code as just deref)
deref of Vec