alancalvitti

general recent conversations

Discussion on answer by Sjoerd Smit: …

Imported from a comment discussion on mathematica.stackexchang...

alancalvitti

Apr 9, 2019 14:13

Re 'new operators via Curry` - yes, I just gave an example, the position-coded "[Bullet]" Curry.

alancalvitti

Apr 9, 2019 08:09

Fyi the [\Bullet] in Flatten[\[Bullet], 1] is a position-coded Curry syntax defined as

\\[Bullet] /: f_[pre___, \[Bullet] , post___] :=    With[{n = Length[List@pre], m = Length[List@post]} ,     Curry[f, Join[Range[n], {n + m + 1}, Range[m] + n]][pre, post] ];

- please join us for Wolfram Data Science live coding tutorials where we discuss issues such as this, eg Tuesday 4/9 @5 on Twitch.

alancalvitti

Apr 9, 2019 08:09

I sometimes use Function (including in the above Q) but try to minimize use. Here's an example query - typical in my line of work - without using function in the pipe - email me if you'd like to see the input-output. Would be less readable w Function:

data[All,       Query[All, "S"] /* DeleteMissing /*        Query[All, enumerateUnitInterval] /* Values /*        Flatten[\[Bullet], 1] /* GroupBy[Last -> First] /* KeySort][     DeleteMissing][Values /* Merge[Flatten /* medianIQR]][   SortBy["Median"]][All,   graphicsMIQR /* Show[\[Bullet], PlotRange -> {{0, 1}, All}] /*    Dataset]

alancalvitti

Apr 9, 2019 08:09

because Function is saddled with cruft. Operators are syntactically preferable - particularly for dataflows, see for example Mr. Wizard's comments to: V10's Operator Forms - what are they good for?

alancalvitti

Apr 9, 2019 08:09

According to your view, it seems there's no room for Curry at all, as everything can be done with Function. Similarly, there's no point to the WL since everything can be done in assembly, as they are Turing equivalent.

alancalvitti

Apr 9, 2019 08:09

Sjoerd, +1 thanks, this is a nice application (Curry[Append[#1, #2[#1]] &]) but feels like cheating. Was thinking that Curry options could be used to achieve this since in addition to permuting the arguments, repeated options are also allowed eg Curry[f,{1,1}] but I see it would likely have to be extended like Curry[f,{1,2[1]}] or similar syntax to indicate the #2[#1] action from your example. Perhaps mention to JMG?

Discussion between Kuba and alancalvitti

Imported from a comment discussion on mathematica.stackexchang...

alancalvitti

Aug 4, 2017 20:55

So does the approach above work in all cases considered by OP? If so I'll add it to my answer.

alancalvitti

Aug 4, 2017 20:10

Probably a recursive approach would be more robust, using a similar check on the Heads of objects being merged

alancalvitti

Aug 4, 2017 20:06

Try this though: merge[f_][as : {_Association ..}] := Merge[f][as];
merge[f_][nas : {Except[_Association] ..}] := f[nas];

alancalvitti

Aug 4, 2017 20:06

I pointed out ragged Associations are an issue but didn't consider that these come up naturally in the OP's setting.

alancalvitti

Aug 4, 2017 19:14

@Kuba, see edits

alancalvitti

Aug 4, 2017 19:14

Use it as an operator, no different than using Merge by itself or iterated Merge[Merge[...]]

alancalvitti

Aug 4, 2017 19:14

Nest[Merge, expr, n] gives an expression with Merge applied n times to f.

Discussion on answer by Mr.Wizard: Ho…

Imported from a comment discussion on mathematica.stackexchang...

alancalvitti

Mar 27, 2016 09:55

@LeonidShifrin, I've also asked some nice Q's, not necessarily here but on math.se, so what? Get used to a world w/ shifting boundaries like Crimea. Just b/c it's called comments doesn't mean you can't have a Q/A, just like South China Sea doesn't belong to China.

alancalvitti

Mar 27, 2016 09:55

@LeonidShifrin, will ask in main site. There's 2 sides to Q/A: maybe I didn't get it, maybe you didn't explain it.

alancalvitti

Mar 27, 2016 09:55

@LeonidShifrin, thanks but there's no explicit mention in that post of why PatternTest and Condition are special vs, say, Blank. Any more insightful links?

alancalvitti

Mar 27, 2016 09:55

@LeonidShifrin, can you link to the most appropriate discussions please?

alancalvitti

Mar 27, 2016 09:55

@LeonidShifrin, I don't get it, isn't Blank in an expression part of the input to pattern-matching evaluation?

alancalvitti

Mar 27, 2016 09:55

@LeonidShifrin, help me understand: (1 + 2)[c] /. f_[x_] :> {f, x} ==> {3,c} or even (1+2)[c]//Head ==>3 in the context above as there's no explicit PatternTest or Condition.

alancalvitti

Mar 27, 2016 09:55

Re: '...Head is not actually used by the pattern matcher ' , what about in the context of Operate, Inactive, RightComposition. Can you clarify why the pattern matcher is or is not involved?

Discussion on answer by Ehryk: What w…

Imported from a comment discussion on physics.stackexchange.co...

alancalvitti

Jan 14, 2015 07:23

@Ehryk, when oxygen is compressed (diamond anvil cell) first it turns blue, then red, then shiny metal indistinguishable from steel. Where's all that in your description?

Discussion on question by David Carra…

Imported from a comment discussion on mathematica.stackexchang...

alancalvitti

Dec 24, 2014 03:52

@DavidCarraher, be aware the modern definition of number is based on that of number system, see eg beta numbers, which induce bijections between (rational) integers and irrational base representations.

alancalvitti

Dec 24, 2014 03:52

@Szabolcs, "In Mathematica types just describe values, not variables". This dynamic (or optional) typing is worth emphasizing for those interested in modern functional languages. There was just a paper in Comm ACM describing this trend in modern languages.

alancalvitti

Dec 24, 2014 03:52

@DavidCarraher, it's understood that Finite State Machines can't represent countable sets let alone uncountable like the field of reals - floating pt is an approximation. These slides by de Dinechin summarizes key aspects: lipforge.ens-lyon.fr/www/crlibm/documents/cern.pdf.

Discussion with alancalvitti

discuss question

alancalvitti

Apr 16, 2014 03:48

Seems to work, excellent. Will +1.

alancalvitti

Apr 16, 2014 03:47

Ok great, thanks

alancalvitti

Apr 16, 2014 03:42

The problem such an Invisible strategy introduces is testing for whether strings have descenders to keep the space to the right of the string uniform

alancalvitti

Apr 16, 2014 03:40

Ok. I typically use Row, but haven't tested it. If you find a better way please comment on my Q. Thank m_

alancalvitti

Apr 16, 2014 03:35

Great, that's new to me. How would you concatenate it to the visible text?

alancalvitti

Apr 16, 2014 03:30

Ok, better than nothing, though I intend to add additional text to the right of the names. How would you add invisible characters, via Row and Opacity 0?

alancalvitti

Apr 16, 2014 03:26

But not uniformly. Don't you think users should be able to specify something like VerticalAlignment -> Baseline versus VerticalAlignment -> Descenders?

alancalvitti

Apr 16, 2014 03:24

I don't like that some names are more distant from their lifeline than others just b/c of the letters in their name

alancalvitti

Apr 16, 2014 03:24

That's an idea but seems like a hack - why can't it be aligned according to user preference just like the 3rd parameter in Text allows?

alancalvitti

Apr 16, 2014 03:19

Ok, interesting. Is there an option to correct for that differential shift?

alancalvitti

Apr 16, 2014 03:14

q = {
"roentgen" -> {1845, 1923},
"lorentz" -> {1853, 1928},
"zeeman" -> {1865, 1943},
"van der waals" -> {1837, 1923},
"starck" -> {1874, 1957},
"einstein" -> {1879, 1955},
"bohr" -> {1885, 1962},
"ehrenfest" -> {1880, 1933},
"born" -> {1882, 1970},
"schroedinger" -> {1887, 1961},
"pauli" -> {1900, 1958},
"de broglie" -> {1892, 1987},
"heisenberg" -> {1901, 1976},
"dirac" -> {1902, 1984},
"jordan" -> {1902, 1980},
"planck" -> {1858, 1947},
"sommerfeld" -> {1868, 1951},
"brillouin" -> {1889, 1969}

alancalvitti

Apr 16, 2014 03:13

Module[{color1 = Darker@Darker@Blue},
Graphics[
({ #1, #2[[1]]} &~MapIndexed~
SortBy[q, #[[2, 1]] &]) /. {name_ -> {b_, d_}, y_} :> {color1,
Text[Style[name, FontFamily -> "Helvetica",
FontSize -> 12], {(b + 20), y}, {-1, -0.85}],
Thickness[0.0005], Line[{{b, y}, {d, y}}], PointSize[0.005],
Point[{b, y}], Point[{d, y}]},
ImageSize -> 1000,
AspectRatio -> 1/3,
FrameStyle ->
Directive[{Gray, FontSize -> 18, FontFamily -> "Helvetica"}],
Frame -> {Automatic, None, None, None}
]
]

alancalvitti

Apr 16, 2014 03:13

Do you see how in the big graphic, the descenders are shifted upward?

alancalvitti

Apr 16, 2014 03:13

I edited my Q again to show the distinction

alancalvitti

Apr 16, 2014 03:12

Compare that to the original though, descenders are shifted upward - I should have been clearer

alancalvitti

Apr 16, 2014 03:10

alancalvitti

Apr 16, 2014 03:09

The "g" descends lower than the "h"

alancalvitti

Apr 16, 2014 03:09

Yes, I edited to show the issue in M9/OSX10.8

alancalvitti

Apr 16, 2014 03:09

Hello