Just looking at this page:
http://www.codecodex.com/wiki/index.php?title=Derivative
is there an easy way to make the Lisp print its symbolic expression in infix
notation like the other languages?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Just looking at this page:
>
> http://www.codecodex.com/wiki/index.php?title=Derivative
>
> is there an easy way to make the Lisp print its symbolic expression in infix
> notation like the other languages?
Printing mathematical formulae in infix has nothing to do with that
page, of course, but is indeed something that probably nobody can
obtain a Computer Science degree without doing at some point. Our
data structures and algorithms class back in the day spent a day on
such things, and knowing how to do so without referring to any sources
was part of a qualifying test for at least one programming competition
that I was involved in.
Maybe your problem is simply that you are uneducated. The good news
is that it's curable. The bad news is that it takes a willingness to
learn, which cannot readily be acquired if you lack it.
Ari Johnson <·········@gmail.com> writes:
> Jon Harrop <···@ffconsultancy.com> writes:
>
>> Just looking at this page:
>>
>> http://www.codecodex.com/wiki/index.php?title=Derivative
>>
>> is there an easy way to make the Lisp print its symbolic expression in infix
>> notation like the other languages?
>
> Printing mathematical formulae in infix has nothing to do with that
> page, of course, but is indeed something that probably nobody can
> obtain a Computer Science degree without doing at some point. Our
> data structures and algorithms class back in the day spent a day on
> such things, and knowing how to do so without referring to any sources
> was part of a qualifying test for at least one programming competition
> that I was involved in.
>
> Maybe your problem is simply that you are uneducated. The good news
> is that it's curable. The bad news is that it takes a willingness to
> learn, which cannot readily be acquired if you lack it.
This is, of course, off-topic, but I thought I should also mention
that the Common Lisp and F# code on that page are instructive.
The Common Lisp to generate a data structure which happens to be
Common Lisp code of a type you can readily process and evaluate with
no transformations other than determining the variables and constants
to fill in is:
(defun d (e x)
(cond
((atom e) (if (eq e x) 1 0))
((eq (car e) '+) `(+ ,(d (cadr e) x) ,(d (caddr e) x)))
((eq (car e) '*) `(+ (* ,(cadr e) ,(d (caddr e) x))
The F# code to generate a derivative, whose output is not given but is
probably not readily available for evaluation by F#, is:
type expr =
| Int of int
| Add of expr * expr
| Mul of expr * expr
| Var of string with
static member ( + ) (f, g) = Add(f, g)
static member ( * ) (f, g) = Mul(f, g)
end
let rec d e x = match e with
| Int n -> Int 0
| Add(f, g) -> d f x + d g x
| Mul(f, g) -> f * d g x + g * d f x
| Var v -> Int (if v=x then 1 else 0)
let rec string_of = function
| Int n -> string_of_int n
| Var v -> v
| Add(f, g) -> "("^string_of f^" + "^string_of g^")"
Moreover, to use the CL version, you just do:
(d '(+ (+ (* a (* x x)) (* b x)) c) 'x)
To use the F# version, you evidently need to do all sorts of bookkeeping:
let x = Var "x" and a = Var "a" and b = Var "b" and c = Var "c"
let e = a * x * x + b * x + c
let () = Printf.printf "d %s x = %s\n" (string_of e) (string_of (d e "x"))
Is this part of your defense of why F# is a better, more readable
language than Common Lisp?
Ari Johnson wrote:
> Moreover, to use the CL version, you just do:
>
> (d '(+ (+ (* a (* x x)) (* b x)) c) 'x)
>
> To use the F# version, you evidently need to do all sorts of bookkeeping:
>
> let x = Var "x" and a = Var "a" and b = Var "b" and c = Var "c"
> let e = a * x * x + b * x + c
> let () = Printf.printf "d %s x = %s\n" (string_of e) (string_of (d e
> "x"))
Look at the output from OCaml:
a x + x a + b
and Lisp:
(+ (+ (+ (* A (+ (* X 1) (* X 1))) (* (* X X) 0)) (+ (* B 1) (* X 0))) 0)
I'd like to improve the Lisp...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Ari Johnson wrote:
>> Moreover, to use the CL version, you just do:
>>
>> (d '(+ (+ (* a (* x x)) (* b x)) c) 'x)
>>
>> To use the F# version, you evidently need to do all sorts of bookkeeping:
>>
>> let x = Var "x" and a = Var "a" and b = Var "b" and c = Var "c"
>> let e = a * x * x + b * x + c
>> let () = Printf.printf "d %s x = %s\n" (string_of e) (string_of (d e
>> "x"))
>
> Look at the output from OCaml:
>
> a x + x a + b
>
> and Lisp:
>
> (+ (+ (+ (* A (+ (* X 1) (* X 1))) (* (* X X) 0)) (+ (* B 1) (* X 0))) 0)
>
> I'd like to improve the Lisp...
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> The F#.NET Journal
> http://www.ffconsultancy.com/products/fsharp_journal/?usenet
See my first reply for an explanation of why you are asking questions
that are beneath contempt for any educated programmer. But now I have
to ask: What needs improvement? Is Lisp code bad output from a Lisp
program? How does O'Caml parse "a x + x a + b"?
Ari Johnson <·········@gmail.com> writes:
> Jon Harrop <···@ffconsultancy.com> writes:
>
>> Ari Johnson wrote:
>>> Moreover, to use the CL version, you just do:
>>>
>>> (d '(+ (+ (* a (* x x)) (* b x)) c) 'x)
>>>
>>> To use the F# version, you evidently need to do all sorts of bookkeeping:
>>>
>>> let x = Var "x" and a = Var "a" and b = Var "b" and c = Var "c"
>>> let e = a * x * x + b * x + c
>>> let () = Printf.printf "d %s x = %s\n" (string_of e) (string_of (d e
>>> "x"))
>>
>> Look at the output from OCaml:
>>
>> a x + x a + b
>>
>> and Lisp:
>>
>> (+ (+ (+ (* A (+ (* X 1) (* X 1))) (* (* X X) 0)) (+ (* B 1) (* X 0))) 0)
>>
>> I'd like to improve the Lisp...
>>
> See my first reply for an explanation of why you are asking questions
> that are beneath contempt for any educated programmer. But now I have
> to ask: What needs improvement? Is Lisp code bad output from a Lisp
> program? How does O'Caml parse "a x + x a + b"?
Good point. Run d on the output of d and you get the second
derivative. That doesn't seem to be easy to do with the other
languages.
·······@ncsu.edu (Rob St. Amant) writes:
> Ari Johnson <·········@gmail.com> writes:
>
>> Jon Harrop <···@ffconsultancy.com> writes:
>>
>>> Ari Johnson wrote:
>>>> Moreover, to use the CL version, you just do:
>>>>
>>>> (d '(+ (+ (* a (* x x)) (* b x)) c) 'x)
>>>>
>>>> To use the F# version, you evidently need to do all sorts of bookkeeping:
>>>>
>>>> let x = Var "x" and a = Var "a" and b = Var "b" and c = Var "c"
>>>> let e = a * x * x + b * x + c
>>>> let () = Printf.printf "d %s x = %s\n" (string_of e) (string_of (d e
>>>> "x"))
>>>
>>> Look at the output from OCaml:
>>>
>>> a x + x a + b
>>>
>>> and Lisp:
>>>
>>> (+ (+ (+ (* A (+ (* X 1) (* X 1))) (* (* X X) 0)) (+ (* B 1) (* X 0))) 0)
>>>
>>> I'd like to improve the Lisp...
>>>
>> See my first reply for an explanation of why you are asking questions
>> that are beneath contempt for any educated programmer. But now I have
>> to ask: What needs improvement? Is Lisp code bad output from a Lisp
>> program? How does O'Caml parse "a x + x a + b"?
>
> Good point. Run d on the output of d and you get the second
> derivative. That doesn't seem to be easy to do with the other
> languages.
Yep. This is really a problem of formula simplification. It's worth
noting that a quick, naive implementation of an infixizer in Common
Lisp is 3 lines, plus 6 lines for a join-list to stick the operators
between the operands. That brings the Lisp implementation up to 15
lines, compared with 19 lines for the F# version. As an added bonus,
the Lisp code is quite readable along with the stated advantage of
having Lisp data, not a string, as its output.
Simplification is, of course, an entirely separate topic. It is,
however, worth noting that simplification is easier to do with prefix
notation and a coherent data structure rather than with infix notation
in a string. (That is, of course, unless Mr. Harrop sees fit to
provide an implementation of something that will simplify and
something else that will re-parse the output of the F# implementation
he has pointed us to.)
Rob St. Amant wrote:
> Good point. Run d on the output of d and you get the second
> derivative. That doesn't seem to be easy to do with the other
> languages.
In C++:
f.d(x).d(x)
In both F# and OCaml:
d (d f x) x
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Ari Johnson wrote:
> Is Lisp code bad output from a Lisp program?
The task is to output Mathematica notation, as all of the other languages
do.
> How does O'Caml parse "a x + x a + b"?
It doesn't. A Mathematica parser might be another interesting example
though...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon Harrop <···@ffconsultancy.com> writes:
> Ari Johnson wrote:
>> Is Lisp code bad output from a Lisp program?
>
> The task is to output Mathematica notation, as all of the other languages
> do.
Why? If you want Mathematica notation, just use Mathematica. It
seems to me that Mathematica even does derivatives for you, and has
one of the best symbolic simplifiers on the market. Either you are
less focused than I had thought or you are deliberately moving the
target for no reason other than to troll. Your prior behavior
suggests the latter, and thus until you produce something
fundamentally inconsistent with the same I'll not be responding
anymore. Oh well, it was worth a shot.
Jon Harrop <···@ffconsultancy.com> writes:
> is there an easy way to make the Lisp print its symbolic expression in
> infix notation like the other languages?
Report from a visit at the "Flying Frog Consultancy":
JH: "Hey, look here, this frog is called "Ocaml". Wanna see it fly?"
Visitor: "Hmm, it looks interesting. But...
Oh my god! You smashed it against the wall!"
JH: "But it did fly, didn't it? Wanna see another one flying?
Here, this one is called "F#"."
Visitor: "It looks a little treacherous, nevertheless I would prefer if...
Oh, what a mess, you did it again!"
JH: "Yep. Wanna see a third one?"
Visitor: "By no means! Please, try this one instead."
JH: "Hey, what's happening here? This one is really flying..."
Visitor: "Yes, it is a bird called "Common Lisp". Look how nicely it
circles up into the sky!"
JH: "How nasty! I _want_ them smashed against the wall!"
On Sat, 26 May 2007 18:58:09 +0200, Jon Harrop <···@ffconsultancy.com>
wrote:
>
> Just looking at this page:
>
> http://www.codecodex.com/wiki/index.php?title=Derivative
>
> is there an easy way to make the Lisp print its symbolic expression in
> infix
> notation like the other languages?
>
Get the code for Maxima. It handles infix stuff plus arbitrary precision
floating point arithmetic and pattern matching..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Christian Haselbach
Subject: Re: Printing in infix notation
Date:
Message-ID: <f3ab37$dm8$1@online.de>
Jon Harrop wrote:
> Just looking at this page:
>
> http://www.codecodex.com/wiki/index.php?title=Derivative
>
> is there an easy way to make the Lisp print its symbolic expression in infix
> notation like the other languages?
Yes
From: Christian Haselbach
Subject: Re: Printing in infix notation
Date:
Message-ID: <f3abmf$e01$1@online.de>
Christian Haselbach wrote:
>> is there an easy way to make the Lisp print its symbolic expression in
>> infix
>> notation like the other languages?
>
> Yes
(defun ifx (l)
(if (atom l) l (list (ifx (cadr l)) (car l) (ifx (caddr l)))))
Regards,
Christian
On Sun, 27 May 2007 00:22:28 +0200, Christian Haselbach <······@muon.de>
wrote:
> (defun ifx (l)
> (if (atom l) l (list (ifx (cadr l)) (car l) (ifx (caddr l)))))
Or decrypted:
(defun infix (element)
(if (atom element)
element
(list (infix (second element))
(first element)
(infix (third element)))))
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Christian Haselbach
Subject: Re: Printing in infix notation
Date:
Message-ID: <f3bifd$mas$1@online.de>
John Thingstad wrote:
> On Sun, 27 May 2007 00:22:28 +0200, Christian Haselbach <······@muon.de>
> wrote:
>
>> (defun ifx (l)
>> (if (atom l) l (list (ifx (cadr l)) (car l) (ifx (caddr l)))))
>
> Or decrypted:
You are taking all the fun out of it. ;-)
Regards,
Christian
Christian Haselbach wrote:
>>> is there an easy way to make the Lisp print its symbolic
>>> expression in infix notation like the other languages?
> (defun ifx (l)
> (if (atom l) l (list (ifx (cadr l)) (car l) (ifx (caddr l)))))
Here's an extension that works for arbitrary numbers
of arguments.
(defun infix (expr)
(if (atom expr) expr
(case (length expr)
(0 nil)
(1 (infix (car expr)))
(2 (list (car expr) (infix (cdr expr)))) ;unary
(t
(let ((op (car expr) )
(expr1 (infix (cadr expr)))
(rest (cddr expr) ))
(if (cdr rest)
(append (list expr1 op) (infix (cons op rest)))
(list expr1 op
(infix (car rest)))))))))
* (infix '(+ a (* (/ b c) d (- e) f)))
(A + ((B / C) * D * (- E) * F))
--
Dan
www.prairienet.org/~dsb/
On 27 May, 18:21, Dan Bensen <··········@cyberspace.net> wrote:
> Christian Haselbach wrote:
> >>> is there an easy way to make the Lisp print its symbolic
> >>> expression in infix notation like the other languages?
> > (defun ifx (l)
> > (if (atom l) l (list (ifx (cadr l)) (car l) (ifx (caddr l)))))
>
> Here's an extension that works for arbitrary numbers
> of arguments.
>
> (defun infix (expr)
> (if (atom expr) expr
> (case (length expr)
> (0 nil)
> (1 (infix (car expr)))
> (2 (list (car expr) (infix (cdr expr)))) ;unary
> (t
> (let ((op (car expr) )
> (expr1 (infix (cadr expr)))
> (rest (cddr expr) ))
> (if (cdr rest)
> (append (list expr1 op) (infix (cons op rest)))
> (list expr1 op
> (infix (car rest)))))))))
You can tidy up the T case using mapcan, so it looks something like
this:
(t (cons (infix (second expr))
(mapcan (lambda(x) (list (first expr) (infix x)))
(cddr expr))
YMMV, but personally I find it a bit easier to read.
Chris Russell wrote:
> You can tidy up the T case using mapcan,
> so it looks something like this:
> (t (cons (infix (second expr))
> (mapcan (lambda(x) (list (first expr) (infix x)))
> (cddr expr))
Exactly :)
Thanks.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen wrote:
> Here's an extension that works for arbitrary numbers
> of arguments.
>
> (defun infix (expr)
> (if (atom expr) expr
> (case (length expr)
> (0 nil)
> (1 (infix (car expr)))
> (2 (list (car expr) (infix (cdr expr)))) ;unary
> (t
> (let ((op (car expr) )
> (expr1 (infix (cadr expr)))
> (rest (cddr expr) ))
> (if (cdr rest)
> (append (list expr1 op) (infix (cons op rest)))
> (list expr1 op
> (infix (car rest)))))))))
>
> * (infix '(+ a (* (/ b c) d (- e) f)))
> (A + ((B / C) * D * (- E) * F))
How do you make this remove unnecessary brackets, e.g. (a*b)-2 -> a b - 2?
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
From: Christian Haselbach
Subject: Re: Printing in infix notation
Date:
Message-ID: <f3cu0v$hji$1@online.de>
Jon Harrop wrote:
>
> How do you make this remove unnecessary brackets, e.g. (a*b)-2 -> a b - 2?
>
You don't, it's an algorithm to transform a sane s-expression into an
infix s-expression which is less usable in terms of computability.
Making it even less usable by minimizing brackets according to
unspecified rules was not part of the request.
Apart from learning lisp you might also want to look for literature
about good requirements.
Ah, the feature creeps.
Regards,
Christian
On 27 May, 22:47, Christian Haselbach <······@muon.de> wrote:
> Ah, the feature creeps.
Ha. The initial problem was to map a sequence of elements of the form
A x^n, separated by plus signs, to corresponding elements A n
x^(n-1).
The symbolic application of the product rule, subsequent
simplification and mapping into infix are all far too general and
entirely unneeded.
From: Christian Haselbach
Subject: Re: Printing in infix notation
Date:
Message-ID: <f3d7db$rph$1@online.de>
Chris Russell wrote:
> On 27 May, 22:47, Christian Haselbach <······@muon.de> wrote:
>
>> Ah, the feature creeps.
> Ha. The initial problem was to map a sequence of elements of the form
> A x^n, separated by plus signs, to corresponding elements A n
> x^(n-1).
The initial problem yes, but what Jon asked for was something to map
expression of the form [ATOM] or ([OP] X Y), where X and Y are again
such expressions, to [ATOM] or (X [OP] Y) respectively. This is trivial,
of course.
> The symbolic application of the product rule, subsequent
> simplification and mapping into infix are all far too general and
> entirely unneeded.
Simplification can result in better performance in subsequent usage of
the result in further analysis, assuming you mean something like turning
(+ (a b) (b a)) to (* 2 a b) by simplification and not turning it to "ab
+ ba" (or "2ab" for that matter).
Regards,
Christian
Christian Haselbach wrote:
> Jon Harrop wrote:
>> How do you make this remove unnecessary brackets,
>> e.g. (a*b)-2 -> a b - 2?
> You don't, it's an algorithm to transform a sane s-expression into an
> infix s-expression which is less usable in terms of computability.
> Making it even less usable by minimizing brackets according to
> unspecified rules was not part of the request.
> Apart from learning lisp you might also want to look for literature
> about good requirements.
Ditto on that. Here's a hacked-up monstrosity that seems
to work. It puts everything except * forms in a list,
and then splices everything together.
(defun infix* (expr)
(and expr
(if (atom expr) (list expr)
(case (length expr)
(1 (list (infix* (car expr))))
(2 (list (cons (car expr) (infix* (cadr expr))))) ;unary
(t (let* ((op (car expr))
(expr1 (infix* (cadr expr))))
(if (eql op '*)
(nconc expr1 (mapcan #'infix* (cddr expr)))
(list
(nconc expr1
(mapcan (lambda(x)
(nconc (list op) (infix* x)))
(cddr expr)))))))))))
(defun infix (expr)
(and expr
(let ((expr* (infix* expr)))
(if (atom expr*) expr*
(if (cdr expr*) expr*
(car expr*))))))
* (infix '(+ a (* (/ b c) d (- e) f) g))
(A + (B / C) D (- E) F + G)
--
Dan
www.prairienet.org/~dsb/