fyi, new features in version 11.3 here reference.wolfram.com/language/guide/…

@Alucard Thread. Or if you want it as an Association, AssociationMap["c"&, {1, 2, 3}].

@b3m2a1 if I have a custom stylesheet and I want to change the color of the Print output, do you know how I would do that?

@JasonB. Change it for the "Print" style.

If you want here's a workflow to do this automatically:

Get["https://raw.githubusercontent.com/b3m2a1/mathematica-BTools/\
master/Packages/FrontEnd/StylesheetEdits.m"]

StyleSheetNew["Print"]

StyleSheetEdit["Print",
 {FontColor -> Pink}
 ]

Run that in your custom stylesheet

Thanks!

Assuming CurrentValue[EvaluationNotebook[], StyleDefinitions] is "PrivateStylesheetFormatting.nb" or "StylesheetFormatting.nb"

That's how I determine what's a stylesheet and what's not right now. It's a bit clumsy but it gets the job done.

So I have to admit working with the front end leaves me mystified, the only way I was able to start was taking the example of Kuba's dark package notebook and then modifying it

I didn't find the "Print" in this case because it was much farther down I guess

That's how it starts for all of us. The trick is that when you call Print["asdasd"]

It makes a Cell with style "Print"

That's how I knew what style to use

okay, so you Print something, then select the cell and do cmd-shift-e

and you see that "Print" is the second argument of Cell?

So then when you go to your stylesheet notebook if there isn't already a cell with "Local definition for style "Print": ", how do you create one?

I have code for it. I only ever use that package I linked to. But you can always make a new "Input" cell, then type:

Cell[
 StyleData["Print"],
 styleSpecs
 ]

Copy that, cmd-shift-e the cell, and paste it in there

Oh or use this:

@b3m2a1 forgive me for my persistence, but how would you apply Thread over Select[ <| a -> 2, {c, d} -> {4, 5}, e -> 5|>, Length[#] > 1 &]]?

@Alucard you could try:

Association@
 KeyValueMap[Thread@*Rule,
  Select[<|a -> 2, {c, d} -> {4, 5}, e -> 5|>, Length[#] > 1 &]]

Unfortunately this destructures it a lot

Oh this is better:

KeyValueMap[AssociationThread,
  Select[<|a -> 2, {c, d} -> {4, 5}, e -> 5|>, Length[#] > 1 &]][[1]]

ah yes, thanks!

it's so simple and yet i could not find it.

@varkor See here

@varkor As for the back-conversion without loss of information, I'm not aware of a better way than really decoding the Real32 yourself. Let me give you an example. When you have your binary representation of the real

bin = ExportString[57.295780181884765625, "Real32"];

then you can re-import it as Integer32 which has the same bit-length. Here, no information will be lost.

If you look at the IntegerDigits in base 2, then this is exactly the bit-pattern that represents your float.

So we can calculate the correct value of your float by multiplying the sign, the exponent and the mantissa ourselves.

decode[str_String] := decode @@ ImportString[str, {"Binary", "Integer32"}];
decode[i_Integer] := With[{d = IntegerDigits[i, 2, 32]},
  (-1)^d[[1]]*2^(FromDigits[d[[2 ;; 9]], 2] - 127)*(1 +
     FromDigits[{d[[10 ;; -1]], 0}, 2])
  ]

Now you can do

In[108]:= N[decode[bin], 30]

Out[108]= 57.2957801818847656250000000000

If you have all your floats in a file, then you use Import. Example:

Export["~/tmp/reals.bin", RandomReal[10, 20], "Real32"]

Now we import them as integers and convert them back

decode /@ Import["~/tmp/reals.bin", "Integer32"]

@Szabolcs how comfortable are you with the packets you pass via LinkWrite and things? I think the FE uses the same system and I want to see if I can leverage this to get some more milage out of it.

@halirutan: thank you very much for doing all that investigation! So essentially the problem is that the precision is not propagated correctly (or as high as I would like)? It seems strange, given that there are other methods to control precision, that none of them seem to work in tandem to address the issue directly. That itself does seem like a flaw.

But actually, as you point out, the manual conversion doesn't seem like too much overhead: I shall try using that method instead! Thank you very much!

@varkor As it turns out, you don't need this conversion.

When only the information about the precision is lost but the bit-pattern is the same, you just need to set precision to see all decimal digits

real = 57.295780181884765625;
realImp = First@ImportString[ExportString[real, "Real32"], "Real32"];

SetPrecision[#, 21] & /@ {real, realImp}

{57.2957801818847656250, 57.2957801818847656250}

@halirutan: oh, amazing! I had tried lots of other methods, but for some reason I hadn't tried that one. That's perfect, thank you very much!

@varkor Depending on what you plan to do with your real numbers, there might not be a reason to do set the precision. All calculations will still be correct. For instance, even if it does not look like it, but real == realImp gives true.

@halirutan: oh, I thought that any calculations were just done to preserve the precision of the values — might not a calculation be rounded to precision MachinePrecision if I don't previously override the before the calculation?

@varkor But machine precision is higher than Real32.

@halirutan: oh, but I thought the problem in the first place was that the result was being output at MachinePrecision (16), which wasn't as great as the required precision (18 to 20)?

@varkor This is a very confusing topic. Keep in mind what Ilian said: There are only two types of reas; machine precision reals (IEEE-754 doubles), and arbitrary precision reals

And it is not to be confused with "number of binary digits".

@halirutan: it certainly is confusing! My understanding was that what Mathematica calls "Precision" is the number of decimal digits to which a value is precise. IEEE 754 uses precision differently, in a binary sense. But because IEEE 754 numbers can correspond to real numbers with extremely long decimal representations, picking a Mathematica precision of 16 is not sufficient for all IEEE 754 numbers.

So it might be safest to explicitly SetPrecision to Infinity on all of them, so they get represented as rationals? But I'll admit I'm still a little unsure that I'm understanding that correctly!

@varkor And the other way around is true as well. For instance 0.1 (which is not representable as finite binary) with an precision of 4 needs 13 bits (plus 8 bit exponent + 1 bit sign) and overall 22 bit.

In[203]:= RealDigits[0.1`4, 2]

Out[203]= {{1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0}, -3}

Yeah, when working with these different representations, it's important to keep track of what terminology is being employed for each component. For context: I'm trying to measure the accuracy of different floating-point numerical (approximation) functions and thought I could use Mathematica to provide a good ground truth by controlling the precision to which the calculations were performed. I have to be careful everything's doing what I expect, though.

I just noted that I will get en error message (Set delayed::Symbol is protected) when doing Plot[ [FormalX], { [FormalX], -4, 4}] in a fresh Notebook in V11.2. Interestingly, I will not get that error for the second time I evaluate the expression and in V10.4 there is no error message at all? Why is this?

@gwr - it seems worse than that, I can't get \\[FormalX] = 2 to evaluate without message

er, \[FormalX] = 2

oops, they are like that on purpose I see

but yours is a bug

@JasonB. Thanks, that is what I figured as there should be no assignment within Plot[] and also if it were an error, why will it not show consistently?

@gwr @JasonB. The only purpose of the FormalX symbols is that you can use them in Integrate, Sum, ... and be sure that they don't have a value. Consider for instance Limit that does not localize the variables. If they have a value, you get wrong results.

@b3m2a1 You mean general MathLink communication? Not 100% comfortable, but if you have a question, ask

@b3m2a1 The kernel communicates with the FE through a MathLink connection, yes (actually, I think it uses 3 links to handle all dynamic stuff)

@Szabolcs I’m trying to wrap my calls to the FE so that I can get a list of responses, rather than pushing them through one-by-one. CallFrontEnd just returns $Failed if multiple return values come through so I was hoping I could circumvent this by passing the appropriate packets. Do you have any idea how this could work? EvaluatePacket just hangs my kernel as I think it returns too soon.