Tag Info

New answers tagged

5

There are two issues with your code. The first is that you have a variable name clash when using x as the argument in the definition of temp. Changing it to something else, e.g. q, will work in an uncompiled version of your code. fff[σt : {__Real}, sρ : {__?NumericQ}, dt : {__Real}, x_Real, nnt_Integer, dqt_Real, divt_Integer] := Module[{temp, dq = ...


16

What's happening This is not simple by any means. You have encountered another instance of a general situation with lexical scope leaks / emulation / over-protection by symbol renaming. The case at hand is pretty similar to the one discussed here, so you can read the detailed explanation of this behavior in my answer there. Roughly speaking, outer lexical ...


3

Your code can be much simplified. The following rewrite of your code works. wlines = {427.397, 431.958, 450.235, 557.029, 587.092, 605.613, 645.629, 665.223, 669.923, 681.311, 690.468}; wcal = {4.1989123474370302*^02, -5.3957450948852408*^-02, 6.7152505835315814*^-04, -8.6698204011228679*^-07, 5.5523712684399200*^-10}; g[x_] = ...


2

I gave a method for handling this kind of problem in this previous answer. Here I show its application to your problem. expToF[exp_, vars : {(_Symbol | h_Symbol[_Integer]) ..}] := With[{body = exp /. Thread[Rule[vars, Slot /@ Range@Length[vars]]]}, Function[body]] calculateDerivativeAt[xpr_, var_, val_] := Derivative[1][expToF[xpr, {var}]][val] ...


4

The reason for your problem is the automatic renaming that Mathematica makes in cases where the names would clash. Let me give a very basic example (parenthesis for clarity; not required): assign[rhs_] := (f[x_] := rhs) What happens when you call assign[x^2] is that rhs contains the pattern variable x and Mathematica does a renaming so that no bad things ...


1

I'm not sure how general this is, but it works here. Add another argument stating what the variable will be. Then replace the variable with a local variable inside your block. calculateDerivativeAt3[func_, var_] := Block[ {f, fprime, blkVar}, f[blkVar_] = (func /. var -> blkVar); fprime = Derivative[1][f]; fprime[3] ] ...


3

I closed this as a duplicate of Why does this pattern with Plus not work for numbers? but I think I have something that is general enough to be useful, and it's not applicable to that question. We may observe that although a plain use of Block[{Plus}, . . .] does not prevent numeric evaluation of Plus we can still make a substitution that does: Block[{Plus ...


7

I think my answer to Why does this pattern with Plus not work for numbers? is also the answer here. See Plus in the reference manual: Unlike other functions, Plus applies built-in rules before user-defined ones. As a result, it is not possible to make definitions such as 2+2=5. The ability for user-defined rules to supersede built-in ones was ...


4

Note: shown below is an answer to the first version of the OP's question Here is a simple example using scoping constructs, namely Block in this case. The idea is that you can indicate symbols to make local to Block, which implements dynamic scoping: take a look at the "Background and Context" section of its docs for a more complete explanation. Symbols ...


4

As @MarcoB states, you should probably use scoping constructs... If you're opposed to that idea, you can set the Notebooks default context to be Unique to Each Cell Group. I wouldn't recommend that, but it works. You can set that under Evaluation > Notebook's Default Context > Unique to Each Cell Group: Note, to escape this, you need to specify ...



Top 50 recent answers are included