Wolfram Mathematica - 2013-05-26

« first day (494 days earlier) ← previous day next day → last day (4000 days later) »

12:05 AM

@...Everyone... I've posted a handful of questions since I joined the forum within the last month. If you've happened to comment on one and I didn't +1 your comment but thanked you for it, I'll be going back through and +1'ing accordingly. Just realized you could vote up comments as well, sorry.

@Ghersic Comment upvotes don't provide any rep, so there's no point in upvoting them unnecessarily

Upvote comments only if they're relevant, useful (e.g. if you would've posted the same if you had gotten there earlier), and especially if you want it to "rise up" in a sea of comments. Often times, witty/humorous comments are also upvoted to show appreciation for the joke... and that's fun as well. Upvoting every thing makes them equally useless :)

@rm-rf Ah ok, thank you. I just didn't want people thinking I didn't appreciate the feedback.

@Ghersic You can upvote answers that helped you or are good/useful instead (even if they're not on questions you asked)! :) I'm sure the users would appreciate that (again, no need to leave a comment saying you upvoted, although some regularly do that)

@rm haha true, I'll be appropriately selective. Cool, I don't think I've failed to upvote an answer, even if it wasn't the selected one.

12:31 AM

@Ghersic

12:42 AM

Oh?

@Ethan

12:58 AM

@MichaelE2 or @Rojo Are you around?

1:12 AM

@rm-rf Yea

1:26 AM

@rm-rf Me, too.

Is there a setting to make Manipulate not try to look for "stuff" (data/variables) when reopening a notebook and spit out a series of messages (without using initialization)? I was trying to find a question on that and was wondering if either of you remembered something like that (or knew the answer)

@rm-rf Not sure what you mean

SaveDefinitions?

@rm-rf Me neither. The data/variables are uninitialized on reopening?

@Rojo Bam! Thanks :D

1:42 AM

@rm-rf No prob

My use of `Manipulate` is rather ugly and terrible, in that I don't pay much attention to the "don't compute on the preemptive link" rule, etc. As a highly simplified example of the dirtiness, consider `rand = RandomReal[1, 10];
Manipulate[rand[[i]], {i, 1, 10, 1}]`. Now when you close mma and open this notebook, you'll most likely get some `Part::partd` or similar errors (I didn't test with this since I don't want to shut down mma, but something along these lines will give an error). For other reasons, I can't initialize the variables within the Manipulate

It's an option of Dynamic too, (and dynamicModule)

SaveDefinitions autodefines the Initialization

but it's just convenience I guess

@Rojo Yeah, I totally forgot about that since I don't use it (Dynamic/Manipulate) very often

@rm-rf It's not documented as a Dynamic option however

@rm-rf I thought you were looking for something more sophisticated than SaveDefinitions. It's all good now, right?

1:47 AM

Yup

Hello everybody

may I ask here a simple question?

Alo, go ahead

WTF... sorry... 1 min pls

I have a list generated by: Table[Subscript[\[Sigma], ToString[i] <> ToString[j]], {i, 1, 3}, {j,
1, 3}]

I want to replace all sigmas with equal subscripts with another variable...

but I'm kind of stuck at:

Table[Subscript[\[Sigma], ToString[i] <> ToString[j]], {i, 1, 3}, {j,
1, 3}] /.
Subscript[\[Sigma], ToString[#] <> ToString[#]] -> a & /@ Range[3]

any suggestion on how to do it?

You mean all sigmas_{some number, the same number}?

yes!

exactly

1:58 AM

@RodLm What you did might be ugly but should work if you put your brackets right

Table[Subscript[\[Sigma], ToString[i] <> ToString[j]], {i, 1, 3}, {j,
1, 3}] /. (
Subscript[\[Sigma], ToString[#] <> ToString[#]] -> a & /@ Range[3])

ahah... thank you so much!!

@Rojo +1 !!!

:-D I was almost there... :-P

;)

@Rojo Is there any way to write this with that (almost) unreadable Core Language? I'm just curious...

What do you mean?

Using string patterns, like _ ~~ _ etc...

2:02 AM

@RodLm FWIW, I avoid subscripts, except as an output format:

t = Table[sigma[i, j], {i, 3}, {j, 3}];
t /. sigma[n_, n_] -> a

@RodLm Yeah but it won't look too cool. Subscript[sigma, s_String/;StringMatchQ[s, i_~~i_]]:>a perhpas

Michael si right

@RodLm It might be simpler if you explained why you want this... As Michael said, I completely avoid subscripts as well except for labels

Better not to use strings at all

Array[sigma, {3,3}]/.sigma[n_, n_]:>a

Subscripts bring along a whole bunch of issues that outweighs all the supposed clarity it brings and almost always, is not worth the time

@rm -rf I'm trying to create a covariance matrix using sigma + subscripts...

I know this is something to be avoided... but it's for, say, educational purporses only...

2:04 AM

Use Array, as Rojo showed above... that'll be your cleanest "core language" solution

@RodLm Ok, in that case it's ok (especially if it's for labels/display)

I liked the array option... fast and clean...

Format[\[Sigma][a___]] := Format[Subscript[\[Sigma], a]];
SetAttributes[\[Sigma], Orderless];
Array[\[Sigma], {3, 3}] // MatrixForm

?

yes, that's it... but I'm trying to do this without commas separating the indexes...

Actually I've achieved that the hard way...

@RodLm Then: Format[sigma[i_, j_]] := Subscript[\[Sigma], ToString[i] <> ToString[j]]

Rojo beat me the first time :P

There's an invisible comma too ;D

2:09 AM

@RodLm Another approach I usually use: Normal@SparseArray[{{i_, i_} :> a, {i_, j_} :> σ[i, j]}, {4, 4}]

@RodLm The moral is

don't make a mess of your code and data representation because of how you want it to display

2

You actually CAN choose both separately

:)

@rm -rf hum... SparseArray as an option... good to know

@Rojo that's what I usually do... as said, it's only for educational purposes...

@Rojo I starred that to fulfill your star needs for the week :D

usually I define my variables like "sig" <> ToString[#] & /@ Range[3]

oh sorry.. let me star your posts! thank you guys!

@RodLm Please don't do that! Therein lies the path to infinite pain...

@RodLm no no

lol

2:13 AM

Stooooooop

Haha

ops... ok

That's a little joke between us (from past weeks)

ok... np

2:45 AM

I have a similar question related to figuring out how to get code to input AND display well. Do you guys mind if I ask?

I have a feeling I've begun down this infinite pain path of which we speak...

Go ahead

with the question... not on the path =)

haha ok one second, thanks

I currently have a large expression involving what in Output Form would be subscripted constants, where the plaintext input is kf & kd (which becomes Subscript[k,f], etc.) that I hope to vary (via sliders much later).

and this expression simplifies beautifully when given the expression as expr and: fexpr = FullSimplify[expr /. {kf -> Subscript[k, f], kd -> Subscript[k, d] /. z[p_] -> Subscript[z, p]]

Gah, too late. Here is what I tried to say:

after defining expr, the expression simplifies beautifully given THIS:

fexpr = FullSimplify[ expr /. {kf -> Subscript[k, f], kd -> Subscript[k, d]} /. z[p_] -> Subscript[z, p]]

However, it doesn't seem to simplify nicely at all if I don't first make the replacement with the Subscript, which I know from you fellow's earlier discussion should be avoided.

In particular, FullSimplify seems to leave common multiplied quantities repeated rather than simplifying it and pulling them outside of the parenthesis, as if it doesn't understand it can manipulate "kf" just as it does Subscript[k,f].

3:03 AM

Hmm... That doesn't quite seem right. The replacement shouldn't really affect what FullSimplify does, unless if you've stumbled into some corner case where it matters what letter the symbol is.

Do you have an example of expr where this fails?

I thought so, too! Here I have an example you can copy-paste, which should be more understandable (apologies for how broken the last few lines were):

No worries

It's actually a list of equations, but here it is.

In two steps, inputting the first:

eqns = {z1' == -kf*z1 + kr*z2, z2' == kf*z1 - kr*z2 - kf*z2, z3' == kp*z2}

seqns = eqns /. (lhs : Derivative[1][_][t] == rhs_) -> (lhs == FullSimplify[rhs])

where the second line's output has an RHS which still consists of common quantities (like kf in the RHS of the equation for z2') are not pulled outside of newly created parenthesis as is custom in FullSimplify.

Btw, always use :> for named patterns instead of ->

Ah ok.

3:15 AM

Is that it? Is seqns your expr?

Oh, sorry eqns is a list of three dummy expressions, so the style is more akin to the nastier mess I am actually working with. That also explains why it is generalized to LHS and RHS, for use with a list of equations. Here it seems regardless of changing style to Subscript or not, it doesn't want to simplify well... hmm.

What is z[p_] -> Subscript[z, p] supposed to do?

I don't /think/ I've included subscripting the z values in my dummy example. The whole looks like:

eqns = {z1' == -kf*z1 + kr*z2, z2' == kf*z1 - kr*z2 - kf*z2, z3' == kp*z2}

seqns = eqns /. {kf -> Subscript[k, f], kr -> Subscript[k, r], kp -> Subscript[k, p]} /. (lhs : Derivative[1][_][t] == rhs_) :> (lhs == FullSimplify[rhs])

Ohh I see what you mean, I am not using the kf -> Subscript[k,f] correctly there I don't think; I am very new, sorry. Still though, shouldn't deleting those and telling it to FullSimplify with simply kf, not the subscripted value, still work?

3:31 AM

@Ghersic It should, but I haven't been able to follow what you're doing yet...

Ok, I'll post the two steps again omitting my subscription fail, then explaining why I'm confused about the output.

eqns = {z1' == -kf*z1 + kr*z2, z2' == kf*z1 - kr*z2 - kf*z2, z3' == kp*z2}

seqns = eqns /. (lhs : Derivative[1][_][t] == rhs_) :> (lhs == FullSimplify[rhs])

but I am confused why no change whatsoever occurs despite the instruction to have seqns's RHS be fully simplified (ie. the second in the list of three should read z2'== kf(z1 - z2) rather than z2' == kf z1 - kf z2)

@Ghersic Just back, not following either, but one possible issue is that lhs stands for the whole equation, not the left-hand side. Need more parentheses.

Or like this: (lhs : Derivative[1][_][t]) == rhs_ :> ...

@Ghersic I don't see why it has to be that complicated... lhs_ == rhs_ :> ... is sufficient

The reason nothing is being simplified is because you have a pattern that won't match

There is no expression that matches Derivative[1][_][t] (note the [t]). Instead, you need Derivative[1][_], and an extra pair of () as Michael noted

Ohhhh, just before you typed that I tried without the extra parenthesis and said derp to myself... let me try adding those parenthesis!

For instance, following @rm-rf, try: `{f'[t] == Sin[t]^2 + Cos[t]^2} /.
lhs_ == rhs_ :> (lhs == FullSimplify[rhs])`

3:42 AM

Wow, cheeks reddening. Let me look at this for a moment.

@rm-rf , that is, "without the [t]"*, not "without the extra parenthesis"

Having a little trouble figuring out where these extra parentheses should go... around the RHS of :> ? I had it at one point and then second guessed myself and reloaded the notebook.

Ahh, I see: seqns = eqns /. (lhs : Derivative[1][_]) == rhs_ :> lhs == FullSimplify[rhs]

That seems to separate the kf and kr terms appropriately in the dummy example I've given! I'm running it now in my uglier (larger equations, 120 of them instead of 3) to see if it simplifies these in the same way. Seems to be taking a long time though, I'm hoping it doesn't simply take literally forever as each by themselves seems to simplify fine after a short wait.

@rm-rf @MichaelE2 Thank you guys for helping me troubleshoot this.

4:05 AM

@Ghersic No problem. Good night! or whatever it is

@MichaelE2 Thanks, you too.

@rm-rf You were here long enough to see the jarbled mess of my trying to explain the problem I was having in addition to the triviality of dummy's errors we pinpointed. Obviously, considering I just started heavily using Mathematica within this last month, I'm in a bit over my head in comparing the dummy and actual files I'm working with. I feel like I splashed you a bit when I came up for air there for a second, so sorry for seeming so unprepared.

1 hour later…

5:21 AM

@Ghersic No problem :) Sorry for leaving abruptly — I had just a little over a minute to pack up and run to catch the bus (I did)

@Ghersic I don't know what your expressions look like, but FullSimplify is like a bazooka, when more often than not, you just need a small swiss knife. See this answer (esp the "A few more notes..." section) for a quick introduction:

22

A: What is the difference between a few simplification techniques?

The primary difference between Refine and the two *Simplify functions is that Refine only evaluates the expression according to the assumptions given. It might so happen to be the simplest form when evaluated, but it does not check to see if it is indeed the simplest possible form. You should use...

Sometimes, Simplify is all you need. If that isn't sufficient, you could also try playing with the ComplexityFunction, TimeConstrained, etc., which might help things a little.

6 hours later…

11:45 AM

@halirutan Yessir!

12:31 PM

@YvesKlett Now you come and make fun of it... ts ts ts..

@halirutan sorry, someone starred it and I could not resist :-P

9 hours later…

10:06 PM

Hey @SjoerdC.deVries! Do you know Java/JLink?

Sjoerd C. de Vries

@rm-rf I'm afraid I know very little of it

How so?

@SjoerdC.deVries Ok, no problem. I ran into an issue with a JLink solution for the question you answered earlier (quoted printable)

JavaNew["org.apache.commons.codec.net.QuotedPrintableCodec"]@decode["=FCberhaup‌t", "UTF-8"]

This gives 65533 as the character code for the first char instead of 252 for ü and I don't know why...

(you'll need to do Needs["JLink`"];InstallJava[] prior to that)

btw @halirutan Do you have a clue?

Sjoerd C. de Vries

I'm in bed with my iPad, so I'm afraid no Needs here

Ah, never mind then :)

@rm-rf hmm.. let me check

Sjoerd C. de Vries

10:11 PM

Isn't that the UTF code?

@SjoerdC.deVries "�berhaupt" — This is what I get when I decode.

Sjoerd C. de Vries

UTF is strange. I think you get a two byte code for the ü

Look up UTF-8 on Wikipedia and you'll see

@SjoerdC.deVries Hmm... If I try to get the byte code directly from Java, I get -4 for ü

Sjoerd C. de Vries

252 is in a range forbidden for UTF

-4 is probably 252-256

I think you should convert to ISO Latin or so, not UTF, irrespective of what the OP says

Have to get some sleep now. Will be a difficult day tomorrow.

@SjoerdC.deVries heeyo! That works.

ISO Latin gives ü. So perhaps trying to convert to UTF-8 was the problem

Thanks :)

Sjoerd C. de Vries

10:18 PM

Good to hear that.

10:34 PM

@rm-rf The characterset is wrong. It has to be test.decode("=FC","ISO-8859-1");

Oh.. seems to be already resolved.

@halirutan Yes, I used UTF-8 because the OP asked for it, but it seems like the OP is mistaken

@rm-rf I still don't really understand this. There is an ü in UTF-8 or not?

@halirutan There is, but the quoted printable format is a way to transmit 8-bit charset in 7 a bit charset. So it doesn't make sense to try and convert to anything other than ISO Latin.

Looking up the utf-8 table it is indeed 16^^00FC

I found out only after Sjoerd's hint

10:40 PM

@rm-rf And it doesn't make sense why? Because UTF-8 has many "non-printable" characters and "ISO Latin" not?

@rm-rf Never mind. It seems I never had interest to understand the details of UTF, Unicode, Latin1, ... encoding.

@halirutan No, I think it's because the QP format converts to byte code for ISO Latin 1. This must then be converted to UTF-8. Also, as Sjoerd said, characters with diacritics are 2 bytes in UTF-8

@rm-rf Ahh ok. But regarding to this table especially the äüö are only one byte

@halirutan Isn't it 2? C3 BC?

10:56 PM

@rm-rf hmm, so it's not the Unicode Codposition which is important?

Then this makes sense

That's how I understood it to be (I don't know much about these... it's all trial and error based understanding)

« first day (494 days earlier) ← previous day next day → last day (4000 days later) »

Transcript for

May '1326

Wolfram Mathematica

Welcome! This is the main Mathematica chat room for mathematic...

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile