Subject: extracting function from the list I can not seem to figure out how to extract a function from the list. for example: mathematica gives me output: {{v->x^2}} How do I extract just x^2 out of that list and assign it to a different variable? thank you, edgar Lobachevskiy === Subject: Re: extracting function from the list RelaceAll[] my help you, in the case where you can have more than a single solution you have to decide which solution you whant to use and q= v /. {{v->x^2}}[[1]] will help you. > I can not seem to figure out how to extract a function from the list. > for example: mathematica gives me output: > {{v->x^2}} > How do I extract just x^2 out of that list and assign it to a > different variable? > thank you, > edgar Lobachevskiy === Subject: Do Modules Produce Side Effects? MathGroup: The MathBook definition of Module tells me, Module creates new symbols to represent each of its local variables every time it is called. I am led by this, and other Module descriptions, to conclude Modules do not produce side effects, like Blocks do. However, we have ... In[1]:= m=i^2 Out[1]= i^2 In[2]:= Module[ {}, m=4; 2*m ] Out[2]= 8 In[3]:= m Out[3]= 4 I expected m to remain unchanged from its original i^2. But Module changed m to 4, just as I would expect a Block to do. Am I misunderstanding something about the side effect safety of Modules? Harold === Subject: Re: Do Modules Produce Side Effects? > The MathBook definition of Module tells me, Module creates new > symbols to represent each of its local variables every time it is > called. This is true. But ask yourself, how does Module know what variables are to be considered local and what variables are global? Quite often one will want to mix local and global variables in the same module. Hence, Module will treat as local only those variables named in the first list. If a variable is not listed there, it is assumed to be a global variable. In your example, you did not tell Module to treat 'm' as a local variable. In[1]:= m=i^2 Out[1]= i^2 In[2]:= Module[{m},m=4;2*m] Out[2]= 8 In[3]:= m Out[3]= i^2 > I am led by this, and other Module descriptions, to conclude > Modules do not produce side effects, like Blocks do. Modules can produce side effects as well. It entirely depends on whether one uses global variables inside the module in addition to local variables. Jason -- Dr J. McKenzie Alexander Department of Philosophy, Logic and Scientific Method London School of Economics and Political Science Houghton Street, London WC2A 2AE === Subject: Re: Do Modules Produce Side Effects? Hi Harold, you just have forgotten to declare m in the module as a local variable, using Module[ {m}, m=4; 2*m ] leaves the global m unchanged, as expected. Peter > MathGroup: > The MathBook definition of Module tells me, Module creates new > symbols to represent each of its local variables every time it is > called. I am led by this, and other Module descriptions, to conclude > Modules do not produce side effects, like Blocks do. However, we have > .... > In[1]:= m=i^2 > Out[1]= i^2 > In[2]:= Module[ {}, m=4; 2*m ] > Out[2]= 8 > In[3]:= m > Out[3]= 4 > I expected m to remain unchanged from its original i^2. But Module > changed m to 4, just as I would expect a Block to do. > Am I misunderstanding something about the side effect safety of > Modules? > Harold === Subject: Re: Do Modules Produce Side Effects? > MathGroup: > The MathBook definition of Module tells me, Module creates new > symbols to represent each of its local variables every time it is > called. I am led by this, and other Module descriptions, to conclude > Modules do not produce side effects, like Blocks do. However, we have > ... > In[1]:= m=i^2 > Out[1]= i^2 > In[2]:= Module[ {}, m=4; 2*m ] > Out[2]= 8 > In[3]:= m > Out[3]= 4 > I expected m to remain unchanged from its original i^2. But Module > changed m to 4, just as I would expect a Block to do. > Am I misunderstanding something about the side effect safety of > Modules? > Harold Since you did not localize m by including it in curly brackets it remained a global variable. This is in no sense a side effect but just the standard distinction between local and global. Andrzej Kozlowski Chiba, Japan http://www.mimuw.edu.pl/~akoz/ === Subject: Re: Do Modules Produce Side Effects? sind out what Module creates new symbols to represent EACH OF ITS LOCAL VARIABLES evey time it is called. the local varaibels are in a call Module[{},...] Only Module[ {m}, m=4; 2*m ] will do what you want, because here m *is* a local variable. The construct Module[{},...] is total useless. > MathGroup: > The MathBook definition of Module tells me, Module creates new > symbols to represent each of its local variables every time it is > called. I am led by this, and other Module descriptions, to conclude > Modules do not produce side effects, like Blocks do. However, we have > ... > In[1]:= m=i^2 > Out[1]= i^2 > In[2]:= Module[ {}, m=4; 2*m ] > Out[2]= 8 > In[3]:= m > Out[3]= 4 > I expected m to remain unchanged from its original i^2. But Module > changed m to 4, just as I would expect a Block to do. > Am I misunderstanding something about the side effect safety of > Modules? > Harold === Subject: Animate Re Mathematica 5.0.1.0. What's the difference between Animate vs. creating a table of graphics objects and then animating that? Is Animate more efficient? Helptext says Animate will animate the objects, but it doesn't do so automatically: after collapsing the created cells, I must double click the object to start it moving. Have I missed something? Bruce === Subject: Re: bug in IntegerPart ? >When you say this, however: >But this phrase could also be taken to mean does not affect >evaluation of arguments which is correct. >NO function affects evaluation of its arguments, or if one did, >what would that look like? How about Plot? Plot does evaluate its arguments in a non-standard way as compared to say Exp or Sqrt. So, some functions do affect the way their arguments are evaluated. >Yes, the author probably had something in mind that IS true; but >times. So far as I know, EVERYWHERE the wrapper concept is >mentioned in the documentation, it's incorrect. Or, if it is >correct in some unknown sense, it's a simple matter to link those >references to an explanation. >Many of us are doing WRI's training, consulting, and debugging for >them, negating the value of our work by giving it away for free; >the least WRI can do is respond when we point out confusion in the >documentation. I agree there are several aspects of the documentation that could be made clearer and that the documentation for wrapper functions like BaseForm or Matrix form is an example of documentation that could be made clearer. I don't agree the documentation is clearly incorrect. -- To reply via email subtract one hundred and four === Subject: Re: Three graph into one graph2 = {{0.1, 0.5}, {0.2, 0.6}, {0.3, 0.8}}; graph3 = {{0.1, 0.8}, {0.2, 0.9}, {0.3, 0.10}}; Plot[Exp[x], {x, 0, 0.4}, Epilog -> {AbsolutePointSize[4], {RGBColor[1, 0, 0], Point /@ graph2}, {RGBColor[0, 1, 0], Point /@ graph3}}, PlotRange -> {0, 2}] > suppose I have > y=e^x [where x=0.5 to 1.5]; > and after interpolation I found x ,y values > graph2--values > ............ > x y > 0.1 0.5 > 0.2 0.6 > 0.3 0.8 > --------------- > graph3--values > ........... > x y > 0.1 0.8 > 0.2 0.9 > 0.3 0.10 > Now I want mathematica to plot the graph1 and graph2 > with the give function y=e^x (superimposed). > Please help me . === Subject: Re: on ColorFunction and combined images? when you combine the plots, the ColorFunctionScaling option is removed and the colors computed incorrect and this cause your error. You should do something like mycf[x_] := RGBColor[0, 0, Mod[(x - 350)/20, 1]] pic1 = DensityPlot[350 + 20*x^2, {x, 0, 1}, {y, 0, 1}, ColorFunction -> mycf, Mesh -> False] pic2 = Plot[x^2, {x, 0, 1}]; Show[pic1, pic2]; > Intro: > If I want to combine, say, a density field plot and an overlaid > curve on it, it is rather easy: > pic1 = DensityPlot[x^2, {x, 0, 1}, {y, 0, 1}, Mesh -> False] > pic2 = Plot[x^2, {x, 0, 1}] > Show[pic1, pic2] > My Case: > But say that I am plotting a densify field that that describes, just for > an example, some carbon dioxide concentrations for which a natural scale > (in the air outdoors) is something like 350...370 rather than 0...1. > I can tell DensityPlot to feed the raw concentration values > to the ColorFunction, and I can provide it my own ColorFunction: > mycf[x_] := RGBColor[0, 0, (x - 350)/20] > pic1 = DensityPlot[350 + 20*x^2, {x, 0, 1}, {y, 0, 1}, > ColorFunctionScaling -> False, ColorFunction -> mycf, Mesh -> False] > pic2 = Plot[x^2, {x, 0, 1}] > Show[pic1, pic2] > The Problem: > There is no problem in drawing the pic1, but then when I try to > combine pic1 and pic2 with that Show, I get an error message: > Argument in RGBColor[0, 0, -17.5] is not a real number between 0 and 1. > It apparently happens so that with Show, the pic1 is redrawn and (some > of?) the options that I gave in the original DensityPlot command are not > used anymore. > Is there a way around this problem? > How can I overlay other graphs with densityplots for which I have used my > own colorfunctions? > I think of the following: I could manually scale every function, that I > attempt to plot, to give out values only in the range 0...1. Then > I guess everything should work okay. But an easier way? > -- > Sampo Smolander ............... http://www.cs.helsinki.fi/u/ssmoland/ > Division of Atmospheric Sciences ............. University of Helsinki === Subject: kuen surface kindly I would want to know as the same graphics(kuen surface) is constructed with Mathematica. I enclose the site from where I have taken the graphics http://math.cl.uh.edu/~gray/Gifccsurfs/ccsurfs.html === Subject: Re: kuen surface http://mathworld.wolfram.com/KuenSurface.html > kindly I would want to know as the same graphics(kuen surface) is > constructed with Mathematica. > I enclose the site from where I have taken the graphics > http://math.cl.uh.edu/~gray/Gifccsurfs/ccsurfs.html === Subject: Re: kuen surface > kindly I would want to know as the same graphics(kuen surface) is > constructed with Mathematica. > I enclose the site from where I have taken the graphics > http://math.cl.uh.edu/~gray/Gifccsurfs/ccsurfs.html Buy the book by late Prof. Gray; it's worth the price! Full of Mathematica notebooks and you will at the same time learn Differential Geometry :) JM === Subject: Re: usage logs from mathlm > What software do people use to summarize the information contained > in the usage logs generated by the Mathematica license manager > mathlm? Some of the key statistics in which I am interested are > frontend and kernel usage time by user and operating system (license > class), number of users, and who the users are. > is there a tool that creates statistics on MathKernel usage, > e.g. for xx hours / yy% of time, n kernels were running, > and the like? > We had discussed this privately and came to the > conclusion that you would have to write something that would read > the log file periodically or at the administrators request and > had left it at that unless pressed. And now that you have asked, > I'll see if I can get a script together. > There is nothing available (that I know of) from Wolfram that > does this. just for the benefit(?) of the group, what I do right now is - run a script that invokes 'monitorlm' in regular time intervals Format: - another script will (at request) read this log file and compute simple usage statistics. This approach works fine for me. For Mathematica 4.x I, had a little program that would read the mathlm log file directly and extract the info from there, but I figured out that it needs too much effort to keep up with Wolfram's changes in the log file format... Marcus -- [...] which will be published posthumously or after his death, which ever comes first. -- W. Allen === Subject: Kernel init.m File MathGroup: In the ...5.0ConfigurationKernelinit.m file, I find the following template ... (** User Mathematica initialization file **) (** Decide how to display graphics on this machine **) Begin[System`Private`] (* Hide any symbols which are created *) Which[ $Linked || $ParentLink =!= Null, < hello group. > consider the following error message, is that normal? or my install go bad? > In[34]:= > ClearAll[Global`*] > Off[General::spell1] > Off[General::spell] > Remove[Global`] > Remove::rmnsm: There are no symbols matching Global`. === Subject: Re: Remove[Global`] ?? > I am guessing you are trying to remove all symbols from the Global` context. > If so, should have typed Remove[Global`*] instead of what you did type. I'm in the habit of putting Remove[Global`*] as the first expression in the first evaluatable cell of my notebooks, so that reevaluations of the entire notebook produce a (more or less) clean start. In earlier versions of Matheamtica, this did not produce an error. In later versions it produces an error on the first evaluation of a freshly opened notebook. The workaround is to use x; Remove[Global`*] instead. === Subject: Re: Re: Derivative of Sum There is no such thing, either in Mathematica or in any other symbolic algebra program I know (and that covers quite a few). The reason why there isn't is that there are just no enough general algorithmic transformations one can do with sums or products of variable (symbolic) length that work in sufficiently many cases for this to be useful. Most situations for which such general rules exist, like yours, can be dealt with almost immediately by hand. In Mathematica Sum[f[i],[i,a,b}] where a and/or b are symbolic is not really a sum but just an expression which only becomes one when both a and b are assigned numerical values or when f is an actual function that evaluates to sum summable expression (and even then you will get an answer only if Mathematica knows' the sum in question.) You can try to define your own rules (like Brian Higgins did) that may work in the case that interests you although in almost every case you will be able to do the same by just forgetting about Sum and working only with the expression to be summed. Of course for some purposes it will be enough to simply choose for your summation limit an integer larger than the indices you are intending to work with: D[Sum[a[k]*b[k], {k, 1, 7}], a[5]] b[5] but I assume you already new that. Andrzej Kozlowski Chiba, Japan http://www.mimuw.edu.pl/~akoz/ > No, it not what I need. I am looking for general derivative of the > general > sum. > Michal > Brian Higgins p.92Õe v diskusn.92m p¿.92sp.93vku >> Michal, >> I s this what you want: >> S[p_] := Sum[a[k]b[k], {k, 1, p - 1}] + a[p]b[p] + Sum[a[k]b[k], {k, p >> + 1, n} ] >> In[3]:=D[S[5],b[5]] >> Out[3]=a[5] >> Note that differentiating a series term-by-term may not always give >> you the incorrect answer. >> Brian >> message > Is Mathematica 5 able to compute the folowing problem: > !(S = Sum[(a_k) b_k, {k, 1, n}]) > then should be > !([PartialD]_(a_i) S = b_i) but the Mathematica gives 0. === Subject: Re: Derivative of Sum No, it not what I need. I am looking for general derivative of the general sum. Michal Brian Higgins p.92Õe v diskusn.92m p¿.92sp.93vku > Michal, > I s this what you want: > S[p_] := Sum[a[k]b[k], {k, 1, p - 1}] + a[p]b[p] + Sum[a[k]b[k], {k, p > + 1, n} ] > In[3]:=D[S[5],b[5]] > Out[3]=a[5] > Note that differentiating a series term-by-term may not always give > you the incorrect answer. > Brian > Is Mathematica 5 able to compute the folowing problem: > !(S = Sum[(a_k) b_k, {k, 1, n}]) > then should be > !([PartialD]_(a_i) S = b_i) but the Mathematica gives 0. === Subject: RE: extracting function from the list variable = v /. result // First > -----Original Message----- === > Subject: extracting function from the list > I can not seem to figure out how to extract a function from the list. > for example: mathematica gives me output: > {{v->x^2}} > How do I extract just x^2 out of that list and assign it to a > different variable? > thank you, > edgar Lobachevskiy === Subject: Re: Re: bug in IntegerPart ? >> The subset of rationals that can be expressed in decimal isn't >> especially useful for exact calculation anyway. > Would you be more specific, please? It sounds like a first class > nonsense but I don't want to jump the gun. He's referring to the fact that many rationals, such as 2/3, lack a finite representation in decimal. === Subject: Re: Re: bug in IntegerPart ? >> NO function affects evaluation of its arguments, or if one did, what >> would that look like? > How about Plot? Plot does evaluate its arguments in a non-standard way > as compared to say Exp or Sqrt. So, some functions do affect the way > their arguments are evaluated. In addition, some functions can have the attribute HoldFirst, whose sole purpose is to affect the evaluation of arguments. In the case of HoldFirst, the first argument isn't evaluated. Set has the attribute HoldFirst because if you evaluate m=10 Set[m, 2*m] you probably want to assign 20 to m, rather than attempt to assign 20 to 10, which will produce an error because 10 isn't an lvalue. Jason -- Dr J. McKenzie Alexander Department of Philosophy, Logic and Scientific Method London School of Economics and Political Science Houghton Street, London WC2A 2AE === Subject: Re: bug in IntegerPart ? > I have feeling speaking to deaf ears. Let me try again. > We feel the same way. Please listen. > I made a constructive > suggestion. (1) Treat all decimals as exact numbers. In this way > number of problems arising on the border between Machine Precision and > Big Number Arithmetic would disappear. The mapping between decimals in > mathematics and Mathematica would become bijection. (2) Introduce a > new notation or alternatively a programming switch for inexact numbers > that would follow IEEE rules. > As a Mathematica user, I don't find this constructive. It would break > practically everything I've done in Mathematica in the last 15 years. Your apocalyptic vision is completely groundless. In reality it would break nothing or almost nothing. Mathematica already has switches for machine and arbitrary precision. Decimals would go by default to arbitrary precision branch. Assuming that Î..' extension would be chosen numbers like 1.3.. would go through current machine precision branch. Two function would be added to move between types 1.3..-> 1.3 and 1.3 -> 1.3.. The only significant change from users' point of view would be slower execution of legacy code that uses decimals. Benefits would include (1) intuitive and much cleaner approach to various types of numerical computation; no more postings on math group on why 34.123*89 is not 3036.947 or why IntegerPart[(1.65 - 1.3)/0.007] is not 50. (2) the elimination of problems on the boundary between machine and big number arithmetic (3) the elimination of hardware dependence (the boundary mentioned in (2) is different on 32 and 64 bit machines, I believe). Again, the changes would require a small modification of the parser, mowing around some numerical computation switches, and adding two functions, all that with minimal impact on users. Actually, I am very curious what are you doing with the decimals that when treated as exact numbers it breaks your code drastically. I hope you agree that Mathematica should produce the same output no matter what hardware. Type 0.100... . On 32 bit processor if the number of zeros is 16 or less, Precision will return the same result (MachinePrecision). If number of zeros is greater then 16, the precision will gradually increase with the number of zeros added. Precision[0.50000000000000000] => MachinePrecision Precision[0.500000000000000000] =>17. If you have 64 bit processor, your MachinePrecision is greater and the expected result for the second input is Precision[0.500000000000000000] => MachinePrecision Remember, however, now MachinePrecision is different then before. In all these cases the binary representation is finite ( 0.1) and. If you want to be precise, when typing decimal numbers, you need to keep track how many trailing zeros add and additionally what hardware the program is going to run on. You might indifferent to that, but it matters to me. > The notation 1.65 in Mathematica means, *by definition*, an approximate > number within machine precision of 1.65. You may not like this > definition, but it's fundamental to the Mathematica language, and most > of us who *actually use* Mathematica find it perfectly natural. If the Let me assure you, I do use Mathematica.:-) > number's got a . in it, it's approximate. Period :-) Period? :-) You sound like Mr. Lichtblau. :-) > If you want an exact rational number, use 165/100. What's so hard about > that? It is nuissance and it's ugly. > The subset of rationals that can be expressed in decimal isn't > especially useful for exact calculation anyway. Would you be more specific, please? It sounds like a first class nonsense but I don't want to jump the gun. > Both developers and users will have > precision or speed as needed without compromising mathematical clarity > and precision. > We already have this. We don't. :-) > The notation just doesn't match your prejudices. ??? > -jpd === Subject: Re: bug in IntegerPart ? >>We have agreed to no such thing. By universal convention (okay, >>universal - 1), 1.65 is an approximate number. >Ok, I will agree (for a moment :-)). What is that something that >you are approximating with 0.35? Is that >NumberForm[0.35, 100] => 0.35 >NumberForm[1.65-1.3,15] => 0.35 0.35 >NumberForm[1.65 - 1.3, 16] => 0.3499999999999999 0.3499999999999999 >Oops, it looks like I came accross a bug. What bug? Mathematica as designed converts the numbers 1.65 and 1.3 to finite binary representations. These representations are the closest finite binary representations to the given decimal numbers. Mathematica then performs the subtraction. But because the finite binary representations cannot exactly represent the input, the result is not exactly the same as if the subtraction was done in decimal arithmetic. At the end of all this, you use NumberForm to control the number of digits displayed. When you chose to display a sufficient number of digits, then it becomes apparent the binary number resulting from 1.65 - 1.3 differs from the closest binary representation of 0.35. A bug is an operation that performs differently than design or documentation. A difference in performance from *your* expectation is not necessarily a bug. >Do you claim that 'approximate' are decimals that don't have finite >binary representation or all decimals? Just asking. :-) I doubt Daniel Lichtblau makes any such claim as there are clearly an infinite set of decimals that have finite binary representation. For example, 0.5 has the finite binary representation 0.1 -- To reply via email subtract one hundred and four === Subject: Re: Numerically computing partial derivatives > I am working with a maximum likelihood problem in econometrics. With > some effort I can get Mathematica v5.0 to maximize the function. In order to > derive standard errors of the estimates, however, I need to calculate > the Hessian of the function at the optimal solution. This requires, of > course, calculating the set of second derivatives of the function. Due > to the nature of the function, however, neither the built-in D or ND > operator seem to work (note: The function contains a term of the form > Log[Det[I-rho*W]], where I is the nxn Identity matrix, rho is a real, > and W is a non-symmetric (sparse) matrix of reals, or order n. In > practice, n > 1000 at times. As a result, symbolic differentiation is > not feasible. In addition, when I use ND [], I get nonsensical answers. I assume you realize that Log[Det[I-rho W]] == Sum[Log[1-rho lambda[i]],{i,n}] where lambda[i] is the i-th eigenvalue of W. Can't you use this to achieve symbolic differentiation? Paul -- Paul Abbott Phone: +61 8 9380 2734 School of Physics, M013 Fax: +61 8 9380 1014 The University of Western Australia (CRICOS Provider No 00126G) 35 Stirling Highway Crawley WA 6009 mailto:paul@physics.uwa.edu.au AUSTRALIA http://physics.uwa.edu.au/~paul === Subject: Re: Numerically computing partial derivatives Hi Mark, Here's a numerical Hessian program that's based on a numerical gradient but it might suit your needs. Options[NGrad] = (Options[NHessian] = {StepSize -> .005}); varspattern := {_Symbol..}|{Subscript[_Symbol,_]..}|{_Symbol[_Integer]..}; NGrad[f_, x:varspattern, opts___?OptionQ][p:{(_)..}]/; Length[x]==Length[p] := Module[{h=N[StepSize/.{opts}/.Options[NGrad]],n=Length[p],pp,hI}, pp = PadRight[{}, n, {p}]; hI = h*IdentityMatrix[n]; ((f/.Thread[x->#]&)/@(pp+hI)-(f/.Thread[x->#1]&)/@(pp-hI))/(2*h)] NHessian[f_, x:varspattern, opts___?OptionQ][p:{(_)..}]/; Length[x]==Length[p] := NGrad[NGrad[f, x, opts][x], x, opts][p] Example: vars = Array[x, 5]; fn = Plus @@ (vars^2)*(x[1]-x[2]) pt = Table[Random[], {5}]; NHessian[fn, vars][pt]// MatrixForm and for comparison, (D[D[fn,#]& /@ vars,#] &/@ vars /.Thread[vars->pt])//MatrixForm Note: Beware of using very small stepsizes! ----- Selwyn Hollis http://www.math.armstrong.edu/faculty/hollis (edit reply-to to reply) > I am working with a maximum likelihood problem in econometrics. With > some effort I can get Mathematica v5.0 to maximize the function. In > order to > derive standard errors of the estimates, however, I need to calculate > the Hessian of the function at the optimal solution. This requires, of > course, calculating the set of second derivatives of the function. Due > to the nature of the function, however, neither the built-in D or ND > operator seem to work (note: The function contains a term of the form > Log[Det[I-rho*W]], where I is the nxn Identity matrix, rho is a real, > and W is a non-symmetric (sparse) matrix of reals, or order n. In > practice, n > 1000 at times. As a result, symbolic differentiation is > not feasible. In addition, when I use ND [], I get nonsensical answers. > As a result, I'd like to use a simple numerical differentiation scheme > based upon a Taylor-expansion, e.g., the simplest being df(x)/dx = > (f(x+h)-f(x)) / h. I thought that before I code or two or three-point > algorithm I would check on the list and see if anyone had already > written code for a numerical Hessian. > Mark === Subject: Re: Numerically computing partial derivatives I think you should be able to make a lot of progress analytically. I attach an extract from one of my papers in which I compute the first derivative of a quantity that is closely related to yours. The main tricks to use are log det = trace log, the Baker-Hausdorff identity for expanding logs of products of matrices, trace(commutator)=0, etc. I presume these sorts of tricks can be used to compute the Hessian as well. Select from (******** to *********) and paste into Mathematica. Steve Luttrell CreatedBy='Mathematica 5.0' Mathematica-Compatible Notebook This notebook can be used with any Mathematica-compatible application, such as Mathematica, MathReader or Publicon. The data for the notebook starts with the line containing stars above. To get the notebook into a Mathematica-compatible application, do one of the following: * Save the data starting with the line of stars above into a file with a name ending in .nb, then open the file inside the application; * Copy the data starting with the line of stars above to the clipboard, then use the Paste menu command inside the application. Data for notebooks contains only printable 7-bit ASCII and can be sent directly in email or through ftp in text mode. Newlines can be CR, LF or CRLF (Unix, Macintosh or MS-DOS style). NOTE: If you modify the data for this notebook not in a Mathematica- compatible application, you must delete the line below containing the word CacheID, otherwise Mathematica-compatible applications may try to use invalid cache data. For more information on notebooks and Mathematica-compatible applications, contact Wolfram Research: web: http://www.wolfram.com email: info@wolfram.com phone: +1-217-398-0700 (U.S.) Notebook reader applications are available free of charge from Wolfram Research. *******************************************************************) (*CacheID: 232*) (*NotebookFileLineBreakTest NotebookFileLineBreakTest*) (*NotebookOptionsPosition[ 4550, 141]*) (*NotebookOutlinePosition[ 5349, 170]*) (* CellTagsIndexPosition[ 5274, 164]*) (*WindowFrame->Normal*) Notebook[{ Cell[CellGroupData[{ Cell[TextData[{ StyleBox[Differentiating, FontSlant->Italic], log det }], Title], Cell[TextData[{ We differentiate the logarithm of the determinant of a matrix-valued quantity. We use this in order to differentiate , ButtonBox[equation, ButtonData:>Eq:LowerBoundIntegrated, ButtonStyle->Hyperlink], (, XXX, ), so we present the derivation using an appropriate notation. }], Text], Cell[BoxData[ FormBox[GridBox[{ {(Step 1), ([Delta] log[ det([Pi] [Sigma]^[Prime])]), ((=)((-log[ det([Pi](([Sigma]^[Prime])^(-1) + ( [Delta][Sigma]^[Prime])^(-1)))]) + log[det([Pi] ([Sigma]^[Prime])^(-1))]))}, {(Step 2), , ((=)((-tr[ log((([Sigma]^[Prime])^(-1))( 1 + ([Sigma]^[Prime]) ([Delta][Sigma] ^[Prime])^(-1)))]) + tr[log(([Sigma]^[Prime])^(-1))]))}, {(Step 3), , ((=)(-tr[ log(1 + ([Sigma]^[Prime]) ([Delta][Sigma]^ [Prime])^(-1))]))}, {(Step 4), , (([TildeEqual])(-((tr[([Sigma]^[Prime]) ([Delta][Sigma]^[Prime])^(-1)])(.))))} }], TraditionalForm]], NumberedEquation, TextAlignment->AlignmentMarker, GridBoxOptions->{ColumnAlignments->{Left}}], Cell[< We justify the various stages of this manipulation as follows: >, Text], Cell[TextData[{ Step 1. Matrix invert , Cell[BoxData[ (TraditionalForm`[Sigma]^[Prime])]], , which introduces a minus sign outside the logarithm function. In order to calculate the derivative, write the difference that results from changing , Cell[BoxData[ (TraditionalForm`([Sigma]^[Prime])^(-1))]], infinitesimally. }], Text], Cell[TextData[{ Step 2. Use the identity , Cell[BoxData[ (TraditionalForm`log[det(X)] = tr[log(X)])]], . }], Text], Cell[TextData[{ Step 3. Use the identity , Cell[BoxData[ (TraditionalForm`log(X Y) = log(X) + log(Y) + ((commutator terms from the Baker - Hausdorff identity)))]], to obtain , Cell[BoxData[ (TraditionalForm`tr[log(X Y)] = tr[log(X)] + tr[log(Y)])]], which causes a pair of terms to cancel, leaving only the infinitesimal part. Note that the trace of any commutator is zero. }], Text], Cell[TextData[{ Step 4. Expand the logarithm using , Cell[BoxData[ (TraditionalForm`log(1 + X) = X + [ScriptCapitalO](X^2))]], . }], Text, CellTags->Ed:Change2] }, Open ]] }, FrontEndVersion->5.0 for Microsoft Windows, ScreenRectangle->{{0, 1280}, {0, 941}}, WindowSize->{686, 740}, WindowMargins->{{0, Automatic}, {Automatic, 0}}, StyleDefinitions -> Report.nb ] (******************************************************************* Cached data follows. If you edit this Notebook file directly, not using Mathematica, you must remove the line containing CacheID at the top of the file. The cache data will then be recreated when you save this file from within Mathematica. *******************************************************************) (*CellTagsOutline CellTagsIndex->{ Ed:Change2->{ Cell[4338, 131, 196, 7, 29, Text, CellTags->Ed:Change2]} } *) (*CellTagsIndex CellTagsIndex->{ {Ed:Change2, 5177, 157} } *) (*NotebookFileOutline Notebook[{ Cell[CellGroupData[{ Cell[1776, 53, 97, 4, 81, Title], Cell[1876, 59, 334, 9, 46, Text], Cell[2213, 70, 1043, 22, 89, NumberedEquation], Cell[3259, 94, 86, 2, 29, Text], Cell[3348, 98, 379, 10, 46, Text], Cell[3730, 110, 135, 5, 29, Text], Cell[3868, 117, 467, 12, 63, Text], Cell[4338, 131, 196, 7, 29, Text, CellTags->Ed:Change2] }, Open ]] } ] *) (******************************************************************* End of Mathematica Notebook file. *******************************************************************) === Subject: Working with binaries Is it possible with mathematica to work with binaries? I did it in another system by typing: OutputBase := Binary. I was also trying to find the function NOT, i.e. that function which gives: !1 = 0 !0 = 1 I found in the help BitNot, but BitNot[1] gives me -2. Luca