Wolfram Mathematica

Szabolcs

8:42 AM

@kirma Let me know if you implement it and if it turns out to work well!

Jacob Akkerboom

9:17 AM

@Pickett Looks great Pickett :). I hope it also gets a lot of stars in chat :P

kirma

9:35 AM

@Szabolcs I have taken a cursory look at Probabilistic Bisection Algorithm (from the thesis you linked) and it sort of works, but obviously requires a better representation of the probability density function than piles of Piecewise expressions. Also, I think I don't entirely understand how to use it on all situations, but I haven't spent more than maybe half an hour on it.

kirma

9:58 AM

@Szabolcs Ah, I think I sort of got it now. The remaining problem is not the algorithm itself... but efficiency of representations.

Szabolcs

@kirma I used this representation. Then it's easy to calculate the median.

kirma

@Szabolcs I thought of creating relatively straight-forward presentation for the problem at hand (basically a list of tuples), and two operations operating on it: distribution reshape and distribution median (or, I suppose mean should be the same in this case?)

Szabolcs

10:35 AM

@Mr.Wizard I have a long answer written up for the question that was just closed ...

Pickett

10:50 AM

@JacobAkkerboom Thanks :)

bobthechemist

11:59 AM

Is there a built-in function akin to PadRight that would not trim list? For Example, I want f[{1,2,3},5] to return {1,2,3,0,0} and f[{1,2,3,4,5,6},5] to return {1,2,3,4,5,6}.

Easy enough to do with a conditional statement; I'm just trying to clean up code if possible.

halirutan

12:22 PM

@bobthechemist Not that I know of, but without conditionals:

PadRight[#1, Max[Length[#1], #2]] &

Kuba

12:40 PM

@halirutan why order of Alternatives matters?

StringCases[
 "test ending",
 "test " ~~ Alternatives @@ {"end", "ending"}
 ]

StringCases[
 "test ending",
 "test " ~~ Alternatives @@ Reverse @ {"end", "ending"}
 ]

halirutan

@Kuba Well, the word alternative already says it: you don't care which one matches because one is an alternative of the other. And with these non-mutual-exclusive string-patterns, this happens :-)

Kuba

@halirutan so there is no logic behind it?

halirutan

@Kuba Hard to say, but from the top of my head I would say it is like using logical Or in testing: if(p || q) then ...

When p is true, then q isn't even tested.

This paradigm is used extensively in programming languages like C and Java

Kuba

@halirutan yes, that's the point, but why longer pattern is found before shorter then?

@halirutan does it mean that the whole pattern is Thread over those Alternatives?

halirutan

@Kuba OK, this is what I get:

This doesn't surprise me. The first alternative is tested first and if it matches, it is used.

@Kuba Can you reformulate your question? Maybe I don't see the point but in the second case the longer pattern is found before shorter one because it is first in the alternative.

Kuba

12:53 PM

@halirutan hmm let's narrow it down:

kirma

@Kuba Alternatives has nothing to do with short-circuiting behaviour of Or. What makes that string pattern find the longer alternative is that like most (extended) regular expression matchers, it tries to greedily match as long substring as possible.

Kuba

StringCases[
 "ending",
 Alternatives @@ {"end", "ending"}
 ]

I'd expect that the algorithm goes like: "e" -> no match, "en"-> no match, "end" -> match -> return

and then even with "ending" first, the "end" will be found first

kirma

Ehm... interesting. I guess it still has some precedence!

Kuba

But it seems I don't know how string pattern matching works! And I thought I know! :(

kirma

As far as I remember, Mma regular expression matcher is built on PCRE matcher under the hood.

Kuba

12:57 PM

@halirutan Am I clear now?

@kirma I'm not sure if I understand your point.

halirutan

@Kuba I guess yes. First, usually string matchers are greedy, as @kirma pointed out.

StringCases["ending", RegularExpression["end(ing)?"]]

StringCases["endin", RegularExpression["end(ing)?"]]

They try to match the longest subsequence.

@Kuba But for your example, I have different understanding of how matching works.

zab

Interesting conversation

halirutan

@Kuba I would have thought that it tests one alternative completely and if it matches, it returns it. It doesn't work characterwise, testing the complete pattern after each bit.

Kuba

@halirutan I agree because of the output. But it seems like not efficient approach, unless I'm missing the general picture.

halirutan

1:21 PM

@Kuba I'm not aware of all the implications either but I didn't shoot myself in the foot

@zab Hi zab

zab

1:42 PM

@halirutan hello!

@ku

@Kuba hello

Kuba

@zab Hi :)

@halirutan It's not like I made a terrible mistake, I wouldn't use such general pattern anyway, I was just confused because the logic implied by output was not intuitive for me.

Pickett

2:36 PM

@Kuba Perhaps it will seem more intuitive to you if you consider cases where the arguments to Alternatives are themselves string patterns. It is not clear how the way you thought it worked would apply to this situation, which Alternatives of course needs to handle.

Kuba

2:52 PM

@Pickett , I'm not sure what do you mean, why ' "e" -> no match, "en"-> no match, "end" -> match -> return ' approach wouldn't be intuitive there too

Pickett

3:06 PM

@Kuba I'm not sure either anymore, I'll have to think more about it.

WReach

4:19 PM

@Kuba The behaviour is due to the depth-first, backtracking implementation of PCRE's standard matching algorithm. That algorithm considers alternatives in the order that they appear and stops searching with the first match.

There is an alternative algorithm that can consider all possible matches, but it comes at a cost and to my knowledge is not accessible from within Mathematica.

Transcript for