Can anybody confirm this phenomenon? I'm in MMA 9, maybe someone could try it on a different version?

@Silvia Apparently PossibleZeroQ[] caches...

@0x4A4D Yes that is what I think. But it makes things look like a bug.

Hi, I'm trying to avoid posting a question to the board because it seems there is too much code to go through before I can post a complete question. Think I should better ask on chat first just in case: What limits are there to the inbuilt derivative function f'[x] because I seem to be able to ParametricPlot3D one function but taking any derivative gets me 0 everywhere.

The function is made up with a ton of piecewise defined functions

and various other functions like matrix inverse, etc. etc.

To be a bit more specific, I have a function defined by: zz = yn[#1] . plotvector &; and ParametricPlot3D[zz[t], {t,0,1}] works but ParametricPlot3D[zz'[t], {t,0,1}] produces an empty graph.

Hm... looks like most people are away. I will use (zz[t + 0.001] - zz[t])/0.001 until I figure it out. Thanks in advance to anyone who responds to this, I will be here monitoring the chat but will be on and off

@muzzlator If you can find a sample plotvector and yn such that you have that problem, better to post it

@MichaelE2 you there?

@Rojo Yep. What's up?

@MichaelE2 All good, you?

@Rojo Everything's fine.

Have you ever defined NValues? I'm struggling a little bit with something

@Rojo No. What is it?

Then N@f[9] gives 10` and not 10. Meaning, N@ is applied recursively on the result

So, say, for example, that my intention is the obvious from the following code

Meaning, I'd like N@f[9, 10] to give f[9., 10]

(This case can be done by setting NHoldRest but I can't do that with my real life example)

@Rojo I see. I've never use it.

It doesn't seem to have documentation

@Rojo Hi, thanks for responding, I think a sample "yn" will be too big for chat. I will paste the code somewhere (apologies for its horribleness, I will point to the line that is of issue)

@MichaelE2 No, it's very poor. The only thing I've found is a lie "Mathematica treats numerical values essentially like upvalues. When you define a numerical value for f, Mathematica effectively enters your definition as an upvalue for f with respect to the numerical evaluation operation N. "

@muzzlator Well, but if I invent some basic yn and plotvector it seems to work properly. I can't see an obvious pitfall without the concrete example, sorry :/

@Rojo Can you do what you want to with upvalues? Or does the NValue mechanism intercept?

@MichaelE2 That was what I just tried and succeeded in doing

@MichaelE2 You have to define UpValues[f]= explicitly, but it seems to work, at least when no NValues are defined

@MichaelE2 It seems UpValues beat NValues

Thanks, that's what I'm going to use then

:)

@Rojo Gee, I guess I helped without even knowing what I was talking about. :D

@MichaelE2 ;)

@Rojo, The mathematica file is accessible at: docs.google.com/file/d/0B3zLINXNTpMkS1lYODVwcHNYaFE/…

If you can't be bothered opening it and looking through, I'll try give details another way

@MichaelE2 Crap

@Rojo Uh-oh.

@MichaelE2 If you started the NValue mechamism from the outside, then it doesn't bother to check UpValues. So N@f[2,3] might work but N@{f[2,3]} already fails

Oops, I changed the line I pasted before so it might not pop up under a search. It's now defined with " yn[s_ ? NumericQ] " as I was trying something.

@muzzlator Come ooon, at least make it a global such that by running the initialization cells all is defined. Otherwise it-s a maze

Hehe

Haha apologies. I never intended this file to turn out this big. It sort of just kept growing and became the mess it is at the moment.

So the problem is I have yn defined as the way it is, ParametricPlot3D[yn[k], {k,0,1}] works fine. But ParametricPlot3D[yn'[k], {k,0,1}] doesn't.

Using SO3InterpolationNullCubic[yy, 4, 0.03] as the function I call.

@muzzlator I can't dig in that mess now. But test what yn'[k] returns

@Rojo I can only come up with NHoldRest... :-(

No probs Rojo, if I hate looking at my own code, I'm sure others hate it even more :)

NHoldRestFirst

yn'[1] returns this: Derivative[1][yn$651982][1]

@muzzlator What about wrapping my dear N around it?

Oh, I thought that was addressed to Michael E2

@muzzlator It was

This last was to you

N@yn'[1]

?

I will test it now. Takes a few seconds to run

Same output. Derivative[1][yn$675153][1]

I get the feeling this problem has something to do with my mathematica fundamentals as opposed to limitations of Derivative[]. Maybe the best option is to find a book that teaches the core of the mathematica language.

I find myself too often randomly changing := to = and adding ? NumericQ in the hope something works

@muzzlator I would suggest making the code as small as you can while keeping the issue

so it's easier to dig into, and others feel more inclined to help out

That's a good idea, I should have done that. I will copy the file across and edit it

Does someone know whether I can defrost a frozen chat room? @0x4A4D Do you know whether this is possible?

@halirutan No but given that you are heere

@MichaelE2 But that works with N@yn'[1] at least

@halirutan Are you a friend of NValues?

@Rojo Not for me...(?)

@Rojo I suppose a wrapper with NHoldRest won't work with in the real life case:

ClearAll[f, g];
SetAttributes[g, NHoldRest];
UpValues[g] = {HoldPattern[N[g[x, args__]]] :> g[N@x, args]};
g[x_Real, args__] := f[x, args];
N@{g[2, 3, 4]}

@MichaelE2 OHH, the good old forgot-to-ClearAll[yn]

@Rojo I just know they exist and they have some nice applications but never needed it myself, no.

@halirutan Ok, thanks, no worries

@MichaelE2 The real life application is not so messed up, easy to explain. I have some adt similar to differenceEquation[bla x[n-1]+x[n]==y[n+2]]

and I want that when N is applied to it, then the integers inside x[n+1], y[n+2], etc, remain as integers

and I can't assign attributes to x or y

but I can do whatever to differenceEquation's definitions

Oh great, I've converted everything to text form by accident. Is there an easy way to make it code again?

@muzzlator You mean you changed the cell style?

Change them back

Select cells, alt+9

@MichaelE2 A complex pattern matching such that it only matches if there's still some job for N, in conjunction with NHoldAll, might work. Such as in

I'll try using that for my case. I still have the feeling that we are missing something

@Rojo Is "differenceEquation[bla x[n-1]+x[n]==y[n+2]]" really something like differenceEquation[bla, x[n-1]+x[n]==y[n+2]], where the untouchable equation is a separate argument? Just fishing...

@MichaelE2 Nope, the equation isn't untouchable, the coefficients (none in my example, dumb me) need to be Nized

Say differenceEquation[ 2 x[n-1]+ 6x[n]==234 y[n+2], ...]

@Rojo Gotcha

Hi Rojo, I believe I have made it 100x nicer looking now :) New file: docs.google.com/file/d/0B3zLINXNTpMkVUFLUkFnaEhJTjA/…

So the bottom of the file is now where all the action happens.

BRB

@Rojo Why do UpValues don't work for you again?

@halirutan Because if N is applied from further outside, N is never an upvalue

Say, N@{f[23]}

that will never actually evaluate N@f[23]

so UpValues are of no use

@Rojo Hmm, I see.

Back.

@Rojo "essentially" and "effectively". The two most dangerous words in the Mathematica documentation. It's interesting that UpSet and TagSet both set NValues rather than upvalues in this case. Looks like you can trick it by wrapping the N in HoldPattern or Verbatim, though. I've never used NValues for anything before, but this oddity is very much worth bearing in mind.

@OleksandrR. The wrap trick does not help when N is called from the outside.

f /: HoldPattern[N][f[x_]] := 10;

N[f[9]]

But

N[{f[9]}]

@OleksandrR. There are several examples of that behaviour

@halirutan good point

@Rojo Btw, you have read the stuff about NValues in Wagners book, yes?

@halirutan I haven't read any MMA book I have to admit

@Rojo It's the book we have online now.

@halirutan Yeah, I downloaded it but still didn't have the opportunity/willingness to dig into it, just like 35398 other books I have

@OleksandrR. For example

when you set Format, or MakeBoxes, you set FormatValues

Many cases where when you "Set" you actually UpSet"

or, when you set Default, you set DefaultValues :P

Options too I guess

@Rojo wow, I knew about Format (which I never use, because it's unreliable) but I never noticed that setting upvalues on MakeBoxes also produces FormatValues

@Rojo Here's an untested way that works on your equation -- a little roundabout. Maybe it could be used with NValues.

nCoeffs[eqn_] := Module[{vars = Variables[List @@ eqn], vHeld},
   SetAttributes[vHeld, NHoldAll];
   N[eqn /. Thread[vars -> Array[vHeld, Length[vars]]]] /.
    Thread[Array[vHeld, Length[vars]] -> 1. vars]];

nCoeffs[2 x[n - 1] + 6 x[n] == 234 y[n + 2]]

2. x[-1 + n] + 6. x[n] == 234. y[2 + n]

@MichaelE2 Thanks for the help

@Rojo You're welcome. I hope you find an easy fix.

I think I have found a fix. By using ND in the NumericalCalculus package, I can compute the derivative

This works fine :)

Thanks Rojo and Michael E2

@MichaelE2 I have a workaround that is simple enough but it implies calculating N twice, so if there are integrals or slow stuff, it's a problem. I could cache the results but that would be a small memory leak. Unless N already caches, in which case I'm ok

I have one more basic question which is a lot easier to ask than the last question: Is there an obvious reason for why this works:

ParametricPlot3D[so3toE3[Inverse[yn[s]].ND[yn[k], k, s]], {s, 0, 1}]

but not:

zz[s_ ? NumericQ] := so3toE3[Inverse[yn[s]].ND[yn[k], k, s]];
ParametricPlot3D[zz[k], {k, 0, 1}]

@muzzlator Sorry for abandoning you, I got busy with stuff to finish and in half hour I HAAVE TO go to the cinema (ohh life, oh life :D)

@Rojo no problems, I am learning stuff on my own too so it hasn't been too bad. Currently reading the 'common beginner mistakes' page

@muzzlator Probably, because ParametricPlot3D needs to see a triplet, at least after evaluating the first argumetn symbolically. But I'd have to play around to be sure

Hm I see, Maybe I should use an Evaluate[] somehwere. goes and tries it

@muzzlator I tried what I said and it's not true

I think I just started an infinite loop

OOps. I just realised my variable names might be conflicting

Nope, doesn't change the outcome

@halirutan thanks for the the heads up on the Wagner book. I was unaware of it and I've been looking for a decent discussion on procedural vs. functional programming in mma.

Sometimes it pays to put in a bit of investment to learn something properly so youre not always wasting time with trial and error

@bobthechemist no problem