FLOATVAL error with ABS and issue with SQRT

[cbnolok]

.show eval ABS(-1) shows 1. .show floatval ABS(-1) shows 0.000000 and error in console: Bad intrinsic function usage. missing ).

.show eval SQRT(030) shows 6. .show eval SQRT(30) shows 5. So with eval it appear to work properly.

.show floatval SQRT(030) shows 5.77... .show floatval SQRT(30) shows 5.77... It's like now it doesn't do the conversion from hex to decimal.

FLOATVAL doesn't show error in console if i put invalid code inside, like .show FLOATVAL arrraaa, where EVAL arrraaa does.

Also, is it possible to have as intrinsic functions also arcsin, arccos, arctan, arccotan? It should be easy to do since they are already in the c++ header (http://www.cplusplus.com/reference/cmath/); cotan and arccotan appear to not be included, but cotan is 1/tan and arccotan is 90°-arctan (https://en.wikipedia.org/wiki/Inverse_trigonometric_functions).

[coruja747]

FLOATVAL consider args as strings instead numbers, and the convertion string -> number always consider the string as decimal, so you must use args in dec instead text / hex

strangely some functions accept strings, some others only dec, some others both dec/hex, etc. So to create a safe code compatible with all these functions it's recommended always convert the values to dec

so instead use

return <FLOATVAL 123 + ABS(-1)>

you must do something like this

LOCAL.ABS = <eval ABS(-1)>
return <FLOATVAL 123 + <dLOCAL.ABS>>

That's why it accept invalid args like returning 0 instead errors and will always return error. The FLOATVAL code uses too much magic codes so honestly I think it will get bricked if we try change it :P

PS: I'm dumb in trigonometry, but since there's some built-in functions on C++ I can add the ARCSIN / ARCCOS / ARCTAN functions

[cbnolok]

Writing here as a reminder: we should write on the wiki how floatval works, so that people knows that they need to eval the argument.

[Kaylala]

FloatVal is actually a bit broken atm. Math files in sphere need updating (is actually partial issue). Right now Sphere isn't liking anything mathematical using ' ^ ' unary operator and fractions.

test: < Eval 'Value' ^ (5/9) >

This is the EA luck code which I had to write a dirty workaround due to bad mathematical files (Normal Eval and FloatVal could not parse this (And FloatVal is supposed to)). Xun is looking into this, so it is not ALL FloatVals fault.

First, the files won't handle the lengthy fractions of a percent this creates (It is a diminishing return equation).

Second, FloatVal will not even accept '^' as an operator and being valid.

Furthermore, this is a huge issue more mathematically than anything. Xun and I are thinking about the best possible route to fix the issue, as an update to the math files would mean a possible rework of arithmetic in the server itself.

So @coruja747 and @cbnolok ; this is not entirely the fault of FloatVal in itself. The fault lies in the integer system Sphere uses. So the wiki doesn't need an update (Yet). It will if this cannot be resolved.