Wolfram Mathematica

« first day (868 days earlier) ← previous day next day → last day (3917 days later) »

Sektor

11:02

@rm-rf rm, what should be the code of conduct in cases such as ViviD's ? He's editing old posts adding tags that do not exist and this is the perfect "minor edit" case. Nevertheless this is not sporadic, rather than something on a regular basis.

Yves Klett

11:24

@Sektor I agree on the minor edits, others seemed o.k. (I approved a few of those), but it is an interesting question.

Pickett

I think this answer has not received enough up votes. This is a seriously useful, very non-trivial contribution.

If you haven't seen it yet please take a look.

Sjoerd C. de Vries

12:06

@Pickett Done, Voted.

Meta

Q: Should the Bugs tag be restricted to documented features?

In this question a bug in Mathematica's TableView was reported, which was subsequently confirmed by the community and tagged by belisarius with the bugs tag. TableView is a strange beast, with WRI being very secretive about it. As far as I know it came in the open because it was used somewhere i...

discussion

Sjoerd C. de Vries

@Sektor Given his explosive behavior in the past you may be lead to believe he is up to something. All those small edits add to his rep.

Yves Klett

12:26

@SjoerdC.deVries there seems to be a rep cap at 1k points for edits (at least on SO) ;-)

Sjoerd C. de Vries

@YvesKlett OK, so that'll take him about 100 days then

Yves Klett

@SjoerdC.deVries is there a cap on edits per day as well?

@Sektor related: meta.ux.stackexchange.com/q/1406

and: meta.stackexchange.com/q/212566

Sjoerd C. de Vries

@YvesKlett That's about the amount of daily rep he got from edits lately. Don't know whether there are caps

1 hour later…

Sektor

14:01

@YvesKlett Thank you for the references ! : )

halirutan

14:21

Is someone around who can tell me why the solution of Bob given in his comment here works? I don't know it and I believe the reasoning of Bob is wrong.

He commented in the last line:

> Presumably, because Function has the attribute HoldAll.

which doesn't make sense because although Function has the attribute HoldAll, it doesn't mean that it holds the arguments when you call it!

Most simple example is to set

Pre = (Print[Hold[#]]; #) &

When you now call 2+2 you clearly see that $Pre prints (although held) Hold[4] because the argument 2+2 was already evaluated.

But when the argument # is already evaluated to 4, how on earth can a replacement work?

$Pre = (Print[Hold[#]]; # /. Plus[2, 2] :> 5) &

(the first code must read $Pre = (Print[Hold[#]]; #) &)

Szabolcs

14:45

@halirutan It doesn't work when I try it ... I commented.

halirutan

@Szabolcs Aehm, what? Really? When you set

$Pre = (Print[Hold[#]]; # /. Plus[2, 2] :> 5) &

and you evaluate 2+2 you don't get 5?

Szabolcs

@halirutan I get 5 because what this does is replace all occurrences of 4 by 5, not replace all occurrences of 2+2 by 5.

halirutan

@Szabolcs Oh man... I was so focussed why this does something at all that I didn't noticed the most basic issue.

@Szabolcs Thanks.

Szabolcs

:-)

Yves Klett

@halirutan :D

Wolfram Blog

15:15

Wolfram Blog: How the Wolfram Language Measures Up

posted on June 04, 2014 by Wolfram Blog

Back in 2012, Jon McLoone wrote a program that analyzed the coding examples of over 500 programming languages that were compiled on the wiki site Rosetta Code. He compared the programming language of Mathematica (now officially named the Wolfram Language) to 14 of the most popular and relevant languages, and found that most programs can [...]

kirma

15:45

Blog post reruns? (At least almost.)

Szabolcs

16:18

Feedback on this simple package would be appreciated: bitbucket.org/szhorvat/booleval/src

It's inspired by this post, and it's very similar to Nikie's solution, just put in a package. It is practically an analog of MATLAB's (or APL's) way of computing elementwise conditions on arrays, or filtering arrays. This approach is very fast, but it was difficult to write readably in Mathematica. The packages tries to remedy this: it gives you both convenient notation and speed.

Sjoerd C. de Vries

16:56

@Szabolcs FrontEndVersion->"10.0 for Mac OS X x86 (32-bit, 64-bit Kernel) (April 17, 2014)",

Caught in the act...

Szabolcs

17:08

oops ...

@SjoerdC.deVries Fixed!

Sjoerd C. de Vries

@Szabolcs ;-) BTW shouldn't BoolEval have the HoldAll attribute?

Sjoerd C. de Vries

17:35

@Szabolcs For equality testing result3 = Pick[array, array, 123456] is more than ten times faster than result2 = BoolPick[array, array == 123456]

Szabolcs

@SjoerdC.deVries Well, since Unevaluated is there, it certainly looks like I wanted HoldAll when I originally wrote this, but right now I can't really see why this is necessary ...

@SjoerdC.deVries Yes, that's a special case where the Pick is much better. The main reason for BoolEval is to get rid of all those ugly UnitSteps when trying to speed up things by vectorization. With a small penalty on performance (compared to fully manual vectorization) we get to keep readable and convenient notation.

@SjoerdC.deVries Might be worth including a special case for it though.

It breaks down once starting to use patterns.

also, this use case is quite unlikely to come up anyway

the result is always a number of repetitions of 123456

@Sjoerd Thanks, this is all useful feedback!

Sjoerd C. de Vries

17:50

@Szabolcs Perhaps for this case?

Szabolcs

@SjoerdC.deVries == vs =?

Sjoerd C. de Vries

@Szabolcs No, they are the same

one has got an automatic replacement by a single character

the other hasn't

Szabolcs

yes, got it.

Sjoerd C. de Vries

Obviosuly, not what BoolPick was intended for, but still

Szabolcs

HoldAll might fix that

I think I'm not going to do that, just mention that it is meant to use with arrays that contain numbers (particularly packed arrays).

Sjoerd C. de Vries

17:54

@Szabolcs BTW could you test Expectation[x \[Conditioned] x <= -1.6448,x \[Distributed] NormalDistribution[]] on both of your versions and compare the results?

Szabolcs

it would require other modifications, eventually decreasing performance

@SjoerdC.deVries -2.06267 on both

Sjoerd C. de Vries

and your result on v9. Something wrong there. But the various new versions also differ.

Szabolcs

This result seems correct.

Integrate[x PDF[NormalDistribution[], x], {x, -Infinity, -1.6448}]/
 Integrate[PDF[NormalDistribution[], x], {x, -Infinity, -1.6448}]

also gives -2.06267

Sjoerd C. de Vries

Gets me -2.62667. Wrong again

3 hours later…

Transcript for

Jun3

Jun '144

Jun5

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