script-fu multiplication : not enought argument - gimp

simple multiplication is failling in my script-fu.
the folowing code
(print "hello")
(print (/ 4 3))
(print (* 3 4))
(print "world")
Gives :
"hello"
1,333333333.0
Error: ( : 1) not enough arguments
Any idea ?
Thanks

I ran into a similar problem when trying to add new functionality to someone else's script. I wanted to provide my solution in case anyone else runs into a similar issue.
In this case, there was a '(let* (...))' statement that was being used to initialize some variables. The original author of the script wrote '(let * (...))' - with a space between let and star - which means every vector in the 'let' statement becomes the expected arguments for the '*' statement.
More info: http://docs.racket-lang.org/reference/let.html
Please excuse (and correct if necessary) any incorrect nomenclature regarding Scheme. I have barely just been exposed to it.

Related

Simplify product of roots containing goniometric functions

In Maxima, I am trying to simplify the expression
sqrt(1 - sin(x)) * sqrt(1 + sin(x))
to yield
cos(x)
I properly restricted the definition of x
declare(x, real) $
assume(x > 0, x < %pi/2) $
and tried several simplification commands including radcan, trigsimp, trigreduce and trigexpand, but without any success. How can this be done?
Try trigsimp(rootscontract(expr))
The restrictions you assert do not uniquely determine the simplified result you request.
It would seem both harmless and obviously unnecessary to declare or assume the following:
declare(9, real)
assume(9>0)
and yet, sqrt(9) is still the set {-3, +3}, mathematically speaking, as opposed to "what I learned in 6th grade".
Stavros' suggestion give |cos(x)|, which is not quite what the original questioner wanted.
Another way of getting the same result, one which may more explicitly exhibit the -in general falseness - of the result, is to square and then use the semi-bogus sqrt, that attempts to pick the positive answer.
trigsimp (sqrt(expand(expr^2)));
If you think this is a way of simplifying expr, note that it changes -3 to 3.

F# Compiler Services incorrectly parses program

UPDATE:
I now realize that the question was stupid, I should have just filed the issue. In hindsight, I don't see why I even asked this question.
The issue is here: https://github.com/fsharp/FSharp.Compiler.Service/issues/544
Original question:
I'm using FSharp Compiler Services for parsing some F# code.
The particular piece of code that I'm facing right now is this:
let f x y = x+y
let g = f 1
let h = (g 2) + 3
This program yields a TAST without the (+) call on the last line. That is, the compiler service returns TAST as if the last line was just let h = g 2.
The question is: is this is a legitimate bug that I ought to report or am I missing something?
Some notes
Here is a repo containing minimal repro (I didn't want to include it in this question, because Compiler Services require quite a bit of dancing around).
Adding more statements after the let h line does not change the outcome.
When compiled to IL (as opposed to parsed with Compiler Services), it seems to work as expected (e.g. see fiddle)
If I make g a value, the program parses correctly.
If I make g a normal function (rather than partially applied one), the program parses correctly.
I have no priori experience with FSharp.Compiler.Services but nevertheless I did a small investigation using Visual Studio's debugger. I analyzed abstract syntax tree of following string:
"""
module X
let f x y = x+y
let g = f 1
let h = (g 2) + 3
"""
I've found out that there's following object inside it:
App (Val (op_Addition,NormalValUse,D:\file.fs (6,32--6,33) IsSynthetic=false),TType_forall ([T1; T2; T3],TType_fun (TType_var T1,TType_fun (...,...))),...,...,...)
As you can see, there's an addition in 6th line between characters 32 and 33.
The most likely explanation why F# Interactive doesn't display it properly is a bug in a library (maybe AST is in an inconsistent state or pretty-printing is broken). I think that you should file a bug in project's issue tracker.
UPDATE:
Aforementioned object can be obtained in a debbuger in a following way:
error.[0]
(option of Microsoft.FSharp.Compiler.SourceCodeServices.FSharpImplementationFileDeclaration.Entity)
.Item2
.[2]
(option of Microsoft.FSharp.Compiler.SourceCodeServices.FSharpImplementationFileDeclaration.MemberOrFunctionOrValue)
.Item3
.f (private member)
.Value
(option of Microsoft.FSharp.Compiler.SourceCodeServices.FSharpExprConvert.ConvExprOnDemand#903)
.expr

Building Latex/Tex arguments in lua (2)

The same question as Building Lates/Tex arguments in lua with a more complex case :
Part II
A more adequate model :
I try to replace the plot arguments by a lua production:
Original:
\begin{tikzpicture}[line cap=round,line join=round,>=triangle 45,x=1.0cm,y=1.0cm]
\draw[smooth,samples=100,domain=-3.0:2.0] plot(\x,{(\x-1.0)^2.0*(\x+3.0)});
\end{tikzpicture}%
Replacement by a "manual" macro : works fine
\def\tempD{(\x-1)*(\x-1)*(\x+3)}
\begin{tikzpicture}[line cap=round,line join=round,>=triangle 45,x=1.0cm,y=1.0cm]
\draw[smooth,samples=100,domain=-3.0:2.0] plot(\x,{\tempD}); % works fine
\end{tikzpicture}%
Trials to use a string produced by lua to replace the manual macro : still to be found
\begin{tikzpicture}[line cap=round,line join=round,>=triangle 45,x=1.0cm,y=1.0cm]
%\draw[smooth,samples=100,domain=-3.0:2.0] plot(\x,{\strfunc??????}); % the correct \strfuncXX is still to be found !
\end{tikzpicture}%
Trials to find the correct \strfuncXX, taking account egreg's infos :
\def\strfuncA{\luaexec{tex.write("(\\x-1)*(\\x-1)*(\\x+3)")}} % fails in draw, probably because it is not expanded enough as an argument of draw
%\edef\strfuncAA{\luaexec{tex.write("(\\x-1)*(\\x-1)*(\\x+3)")}} % fails because \luaexec non expandable
\def\strfuncB{\directlua{tex.write("(\\x-1)*(\\x-1)*(\\x+3)")}} % fails because \directlua has a problem managing the "\\"
\def\strfuncC{\directlua{tex.write("(x-1)*(x-1)*(x+3)")}}
\edef\strfuncCC{\directlua{tex.write("(x-1)*(x-1)*(x+3)")}} % works fine ... except that we get an expression with xs instead of \xs
\def\strfuncD{\directlua{tex.write("(\string\ x-1)*(\string\ x-1)*(\string\ x+3)")}} % \strfuncD fails (why ?)
%\edef\strfuncDD{\directlua{tex.write("(\string\ x-1)*(\string\ x-1)*(\string\ x+3)")}} % \strfuncD fails so \edef will fail
Moving from \luaexec to \luadirect (or \directlua) created a problem with the compulsory \x I have to produce that I cannot solve.

Why should successive arguments involving method application be parenthesized?

Suppose the following F# function:
let f (x:int) (y:int) = 42
I suspect that the reason I need to parenthesize the arguments in example z2 below is because of type inference; my example might not be great, but it's easy to imagine how things could get very hairy:
let z1 = f 2 3
let z2 = f 2 (f 3 5)
However, the following case is less clear to me:
let rng = System.Random()
let z3 = f 1 rng.Next(5)
z3 doesn't work, with a clear error message:
error FS0597: Successive arguments should be separated by spaces or
tupled, and arguments involving function or method applications should
be parenthesized.
Fixing it is trivial (parenthesize all the things), but what I am not clear about is why such an expression is a problem. I assume this has to do with type inference again, but naively, it seems to me that here, methods having a list of arguments surrounded by a parenthesis would actually make things less potentially ambiguous. Does this have to do with the fact that rng.Next(5) is equivalent to rng.Next 5?
Can someone hint, give an example or explain why this rule is needed, or what type of problems would arise if it were not there?
I think that the problem here is that the code could be treated as:
let z3 = f 1 rng.Next (5)
This would be equivalent to omitting the parentheses and so it would be calling f with 3 arguments (the second being a function value). This sounds a bit silly, but the compiler actually does not strictly insist on having a space between parameters. For example:
let second a b = b
add 5(1) // This works fine and calls 'add 5 1'
add id(1) // error FS0597
add rng.Next(5) // error FS0597
add (rng.Next(5)) // This works fine (partial application)
I think the problem is that if you look at the sequence of the 4 examples in the above snippet, it is not clear which behavior should you get in the second and the third case.
The call rng.Next(5) is still treated in a special way, because F# allows you to chain calls if they are formed by single-parameter application without space. For example rng.Next(5).ToString(). But, for example, writing second(1)(2) is allowed, but second(1)(2).ToString() will not work.

Prolog Code Example: Unification

From an old final for my class:
Here is some prolog code:
mystery(1, 1).
mystery(N, F) :-
N1 is N-1,
mystery(N1,F1),
F is F1*N.
Question 1: What value is unified with P in
mystery(3, P).
Question 2: If a semicolon is pressed after Prolog produces and answer for mystery, and interpreter will eventually report "ERROR: Out of local stack". Why dies this occur, and how could you modify mystery to avoid the error?
Question 1:
I get
P = 6 ?
Question 2:
If I press semi-colon to get all answers, I get an out of local stack error.
I'm not sure what this code is trying to accomplish or how to fix it so I don't go out of local stack. Any ideas?
The out of stack error is probably because, when you get down to mystery(1, F1) which resolves to mystery(1, 1) and ask for more solutions, you hit the next clause, which calls mystery(0, F1). At this point, it tries to find a solution, but the only clause that matches calls for mystery(-1, F1), and that calls for mystery(-2, F1) and so forth. This means that there's matches called for until either the first number wraps around to 1 or you get a stack overflow, since each pending match takes stack space.
#David Thornley already explained why searching for more answers blows up your stack. You could fix it by using a cut operator:
mystery(1, F) :- !, F is 1.
mystery(N, F) :-
N1 is N-1,
mystery(N1,F1),
F is F1*N.
The cut here makes it so that if the first argument is 1, the second rule may not be applied.

Resources