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
Those who visit the chat might have seen the question of varkor. I'm posting it here in the hope that I have missed something.
Assume you have a real number
real = 57.295780181884765625;
This number fits exactly into a 32 bit floating point number (known as IEEE-754) as you can verify on this...
@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.
@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 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?
@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.
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?
There is of course a missing "\" here for the FormalXs - but you know what I mean. ;-)
@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.
@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.
@Edmund @Searke @P.Fonseca @halirutan since you are talking about *Q functions: https://mathematica.stackexchange.com/a/159896/5478
Btw there are 224 of them on default context path and only a couple with side errors. So it points in 'lack of clear guidelines for internal developers' rather than 'a fundamental problem of what to expect and error handling in mma'. So, almost nice, almost.