Number to text conversion returns scientific notation which text to number conversion can't parse

when converting floats to text, small and large floats turn into scientific notation:

$0.0001$ => 1.0E-4
$10000000.1$ => 1.0E7

however numbers in scientific notation are treated as text by operators and math functions:

lv(n, 0.0001)
mu(abs, #n) => mu: invalid numeric argument: 1.0e-4

this makes math unreliable because anything that could be a small number might return a string instead of a number, which then breaks everything relying on it.

a workaround is to run your result through mu(round, [num], 9), since it never prints scientific notation, but this is one of the worst bugs when it comes to writing complex formulas.

1 Like

Fixed in the next build out probably today (greather than 3.74b328518)

copy-pasting from the discord so it doesn’t get lost:

I had some time to give it a shot and I am sad to report it is only half fixed:

$0.00001$ => 0.00001
$0.00001 + ""$ => 1.0E-5
$tc(cut, 0.00001, 0, 99)$ => 1.0E-5

seems like there is a separate number → string conversion within the formula and when stringifying the output of a formula.


sidenote, a similar thing happens with dates:

$dp()$ => 2023y10M15d10h0m0s
$dp() + ""$ => 1.69735654E9 /* I suppose because + tries to convert to number first */
$tc(cut, dp(), 0, 99)$ => 2023-10-15T10:00:00.000+00:00

though the ISO format output can be useful sometimes, so maybe don’t axe it completely :​)

1 Like

This is fixed but this:

Can not, when you use dp() in a number context it will use it as a number of seconds since epoch, so you can add seconds to it, you can still get a date by using dp(dp() + 5) for example

1 Like

This topic was automatically closed 25 days after the last reply. New replies are no longer allowed.