builtin math shouldn't require a --scale argument for floating point math.

[floam]

The old math function wouldn't do this (we cast to an integer in builtin_math.cpp):

~ $ math '3.5*3'
10

bc would print 10.5.

The only way to coax out the right answer is to use --scale, which I consider something kind of unpleasant from our old math function that was an artifact of bc, not something we should want to encourage let alone require. Ideally we could have a nice default where 5.0 printed 5 and 5.0010 printed 5.001 (roughly %g without the exponent stuff).

[ridiculousfish]

Wow, that's gross. Floating point arithmetic ought to just work.

[floam]

Indeed, and I'd say that the scale argument should just go away. People can run math output through printf themselves if they want to tweak it.

[talamus]

the math commandlet is a thin wrapper around bc, so

> math "scale=10; 100/3"

produces what expected.

However, if you set default scale for bc it seems to work with math also.
(There is a scale option in the commandlet code, but it seems to format the (already rounded) output.)

[faho]

the math commandlet is a thin wrapper around bc, so

@talamus: It's not anymore. In 3.0, it's a builtin.

And I don't think we want to add something like "scale". At least not in the way that bc does - without, you can only get integers, and with it, you can't do modulo.

[faho]

So, I've tried to just remove trailing zeroes and "." from the string represenation (unfortunately there's no useful standardized format string for this - %g is almost correct except it switches to 1e15 scientific notation if the numbers get big or small), and that looks okay.

math 5 / 5 results in "1", math 4 / 2 results in "2", math 2 / 3 results in 0.666667 (or something like it).

However, one issue I have here is that test doesn't handle floats, and I'd rather have truncating math with results I can feed to that than to always use math --integer with it.

[zanchey]

What about teaching test to handle floats? That seems like a sensible extension.

[faho]

Sure. I'd add one caveat: We always accept "." as the separator, so scripts don't break across locales just because of numeric crap (AFAICT, there is no POSIX way to read a double that isn't locale-dependent). I've added something like that in math, and I just ended up switching LC_NUMERIC temporarily. In test, it might be possible to accept both (in math it's not because "," is also used for multi-argument functions - what does ncr(2,5) mean?), but I'd lean towards accepting the same numbers for both.

(It's possible that fish should just use LC_NUMERIC=C internally always - which would make this much easier)

[faho]

Okay, printf explicitly tries the user's locale and then C.