I saw within the documentation that there is a limit within Dialog to only whole numbers up to 16383 but I believe I read somewhere that the creator hoped to make dialog more arithmetically capable, has this limitation changed at all and if not does it seem possible that it might any time soon? Dialog seems quite interesting but the project I’m working on is heavily reliant on real numbers ranging from -1 to 1 and basic algebra. I would also be interested to see if this hasn’t changed if people have some up with work arounds to represent negatives and real numbers in a way that allows them to be used accurately in calculations. (If it matters I only really need accuracy to two decimal places, three is ideal, four would probably be the most I’d ever use).

Negative and floating point numbers aren’t built in, but negative numbers at least I wrote a library for: Signed Math Library

In theory you could write your own floating point math library in the same way, probably the easiest approach would be to express them as fractions, but something like half-floats could probably be done as well.

Intrigued about your project, keep us updated!

Thanks I’ll definitely mess around with this, I’m still sort of poking around with Dialog and kind of trying to figure out if I can/want to use this for the project I’m working on, before I really delve into learning it, but I’ll take a look at your library and see if me making a similar floating point library seems doable.

In addition of the signed math library mentioned above, which uses lists like `[- 729]`

to represent signed numbers, I thought of another, likely more performant approach. (Although it should not matter a lot).

The idea would be to choose a arbitrary number as a zero, for example 16383 divided by two, which is 8191. Any number below that would be “negative”, and any above positive. (But of course it divides the absolute range by 2.)

For decimal numbers, if you only need numbers between -1 and 1 with 3 decimal places, you could use fixed-point math. So 1000 would represent 1.000, 729 would represent 0.729, and so on. And you could combine that with any method above to get negative numbers.

But I’m just throwing ideas, I haven’t implemented any of those, sorry.

Finally, and while it’s not strictly related, I’ve written some code to be able to use reverse Polish notation in Dialog, if you want something more compact to write than the built-in rules.

Thanks this gives a great place to start if I do end up creating my own implementation. I think your suggestion of fixed point math using a range of 2000 divided by 2 (having 1000 represent 0, 2000 representing +1 and 0 representing -1) may work well for this. I’ll take a look at your extension as well.