Hi,

I need to convert timestamps integer numbers (ex: 1647387729) to day/month/year hours:minutes:seconds, so I am using "date" linux command to do so which works well on a terminal.

in pd, I am storing many timestamps in [text define] getting them from [purestjson] externals but as soon as they appears in pd, they all looks like 1.64739e+09 and I have the same resulting date after my conversion... I guess this is a pd number representation limit?

Is it possible to store that big number in pd 0.52 64bit or not? Any possible tricks?

Thanks for your input!

@60hz there are 2 issues: bit depth, and representation of the numbers when they're saved in the patch.

In this case you have both issues: pd can't represent a significand of 30 bits (32-bit floats can only store 24), and the way numbers are saved don't preserve the full precision for some reason.

so you'll have to split the date and time into smaller parts before receiving them in pd. And maybe you can use symbols to store them instead, if you need to store it on 1 line or something.

Thanks @seb-harmonik.ar

so you'll have to split the date and time into smaller parts before receiving them in pd.

Ok, I tried using [makefilename %s] but that's the same issue...
I finally converted the timestamp to symbol on the server side and got it in pd.

I guess that the double precision pd wouldn't get this problem?

@60hz Probably completely ridiculous, but i made this abstraction that adds two numbers encoded as symbols and return the sum as a symbol. So this should add numbers in symbol format of any length.

sym+.zip

Currently only supports positive integers.

@60hz double precision would solve the bit-depth issue, but the textual representation of numbers (floats) would also have to be changed to add precision. (I haven't checked if pd-double does this or not.. katja's page makes it seem like it does though)
here is her description from https://www.katjaas.nl/doubleprecision/doubleprecision.html :

You have probably noticed that single precision floats are represented in Pd with a maximum of 6 significant digits. This is done to hide inconsistencies like 33 * 0.3 = 9.900001, which happens when 7 decimal digits are shown. The limitation to 6 significant digits is however very annoying when we want to type or see large integers, like indexes of long audio buffers.

In calculations, Pd can use all integers from 0 to 2^24 = 16,777,216, over 16 million. Numbers with up to 8 decimal digits. But in the GUI, 1 million is shown in scientific notation as 1e+06. This scientific notation also uses a maximum of 6 significant digits. Therefore, the next representable number is 1.00001e+06, that is 1 million and 10. See below how the result of 2^20 is rounded in the GUI, as an example. The fact that numbers are also stored with patches this way, makes things worse. At 44100 Hz samplerate, one million samples is about 23 seconds - not at all that much. Longer audio buffers are allowed, but handling them in the GUI becomes tricky.

@ingox very clever and it works well with very large numbers too!

@seb-harmonik.ar said:

https://www.katjaas.nl/doubleprecision/doubleprecision.html

Oh yes, I remember to check this in 2011... thanks
"At the time of this writing, 2011" -> funny, maybe pd should be double by default, but I guess all externals would need to be re-compiled again. So we are stuck in the past... since 1996!

So even if I found a way to avoid pd single precision problems with symbols, I still have to store my database inside pd (using [text] and writing a .txt file). But as soon as I need to read my numbers back into [text], again, they come back as truncated formulas in [text define]... so boring.

@60hz said:

But as soon as I need to read my numbers back into [text], again, they come back as truncated formulas in [text define]... so boring.

I wonder if a scripting external would help? That is, if Pd blocks you from using data types appropriate to the task, maybe embed something that isn't subject to the same limitations.

Or pass around these numbers as multiple floats and rejigger them for user facing display.

hjh

All that part could be done in a scripting langage yes... actually I have a javascript server running also.
But I expected to be able to do that simple task easily in pd

@60hz said:

But I expected to be able to do that simple task easily in pd

But Pd isn't really a general purpose programming environment, is it?

Its tolerances seem designed to be good enough for typical DSP tasks but even there, e.g., random access within an audio buffer longer than a few minutes is not really within reach of 32-bit Pd. (The tolerances are ok for oscillators and filters, or triggering short samples while arbitrarily long samples require disk streaming or some intricate tap dancing.)

SC does a better job of pretending to be a general purpose language. It isn't, not really, but it does have more goodies like local stack frames for function calls, a full complement of data structures, error handling (though with one outstanding bug), etc... leading to a funny question on the forum asking if SC has a native SMTP library for sending email... well, we don't have that kind of networking layer so, no. I guess user expectations exceed reality everywhere.

The punchline about floating point representation is that comments are parsed in the same way that object or message boxes are (or, comments used to be, I didn't check in the most recent Pd). Writing eg 10100111 would be truncated to scientific notation.

hjh