[Scuddie]

I tried for an hour to try and break this thing, and it isn't letting me fail, so long as I follow standard mathematical procedure.  However, it seems to think that 0.999_=1 .

Suggestions, error handling like ending parenthesis should be present.  Also, how about a root function?  Cubic root of 27 could be written as 3r27, and it would ofcourse resolve to 3.

[Drew]

x=x = 0 seems kinda strange but i guess = isnt an treated as an operater

[Bobboau]

this isn't an algebraic symbol simplifier, it's an arithmitic evaluator, no '='

[Bobboau]

yay!
sin sqrt tan log cos ln!!!

also x#y = the x'th root of y

oh, yeah, modulus (%) is working now.

[Bobboau]

ok,
1)does everything work
2)what else do I need to add

[Scuddie]

1)I don't know the order of the operations for trig/calc (nor do I know trig/calc period ), so I can't tell you.
2)That all depends on what it's used for.  You still haven't told us, yet.

[Bobboau]

well I'm developing this for the materia system, but it'll probly end up getting used in a new HUD system and linked animations.

come on now folks were in the home streach, don't quit on me now...

[kasperl]

Rad/degree?
I do see it is in radians.
You still need to implement ! (3!=1*2*3).
Do we have arctan, arcsin, and arccos?

It doesn't seem to support unreal answers, btw.


We either need constants like pi available, or some kind of accuracy control:
sin(3.1415926) = 1.50996e-007'
(My TI says sin(pi)=0, like it's supposed to.
It does work when not aproaching zero:
cos(3.1415926) = -1.

tan((1/8)3.1415926) = 0.125655
TI:
tan((1/8)pi)=.414213
Perhaps it doesn't  multiply when no char found.
Indeed it doesn't....
tan((1/8)*3.1415926) = 0.414214

It totally dies when you fo
rget to close your bracket.

It still doesn't trow out an error if it doesn't support the operand.
(arcsin(1)=0)

EDIT:
Log and ln work as expected, ditto for #.
We definately need constants though, stuff with e in it just gets odd.)

[Bobboau]

try PI and E

"sin(3.1415926) = 1.50996e-007'" that is what's known as a rounding error, that's as close to right as a computer ever gets.

I need to fix implied multiplication for the closeing side of parenthises aparently.

and also added to the todo list, better parenthises error handleing, it shouldn't be too hard to append the corect number of parenthises to the end of an expression, or at the very least handle it without crashing.

will add arc* and hyperbolic trig functions when I get home tonight. any other unary {y=f(x)} functions anyone wants?

I supose a degree(radian_number) and radian(degree_number) should be added.
and I'll add factorial.
and I'm not going to suport imaginary numbers.

[Col. Fishguts]

Erm...are arcsin(), arccos(), etc. in ?

[Bobboau]

not yet, and if you try to use them it will quite likely crash, at the very least it'll give bizar output if anything.
as I said, I will get them in tonight, it'll be a trivial matter to add these.

[Bobboau]

just thought of something to add, log of a variable base. how's this sound X~B gives you the log(base B) of X

[kasperl]

Well, log(x)/log(b) works fine....

And any operator or function it doesn't recognise will return zero, it seems. It really should return an error, IMHO.

I'm simply looking at the catalog of functions on my TI and putting anything of which I know what it does and isn't in yet.

abs(x)
(wtf is cosh?)
Degree/Rad conversion
Dec-->Frac might be handy, but I doubt it'll work...
int( ). (I think it'll give the rounded int value of anything it gets)
rand might be a good thing somehow....
That was the TI catalog, anyway, dunno about anything else.

Do you want probability calculations?

[Bobboau]

cosh is hyperbolic cosine, I'll be adding all three hyperbolic functions.

the thing with log is, the fewer variables (opperators are counted as variables) used the better, so if I can make an opperator that can do something common with being passed two variables (1 opp + 2 param = 3 variables) rather than useing 6 it'll be twice as fast, the evaluation uses recersive calls to many derived claasses so it is inherently slow as it is.

ipart and fpart would probly come in usefull
abs() definately!
there realy isn't any way to use fractions like that, evaluateing an expression is built from the ground up to return only a floating point value, not another expression. although makeing a function to take a float and display a fraction might be nice to have around in general.
rand() would defenately be useful (I can think of a material for flickering debris would use it right away), two implementations a 'rand' wich returns a number between 0.0 and 1.0 and a range version, I'm thinking 'A?B', returns a value between A and B, though I might want to reserve '?' for posable conditionals later on.

[Bobboau]

ok so the complete list of functions that are not currently suported but will be a short time after I get home tonight are(is? .. anyway):
arcsin(x)
arccos(x)
arctan(x)
hypsin(x)
hypcos(x)
hyptan(x)
degree(x)
radian(x)
!(x)
abs(x)
ipart(x)
fpart(x)
sign(x)
rand {and a binary verion for range, needs to be one charicter long}
~ {log of variable base}

[Col. Fishguts]

Originally posted by Bobboau
not yet, and if you try to use them it will quite likely crash, at the very least it'll give bizar output if anything.
as I said, I will get them in tonight, it'll be a trivial matter to add these.

Ah...I overread that. It doesn't crash though, just returns 0.

For other functions:

- Complex numbers (if there's any use for them)
- sign(x) is handy sometimes

[kasperl]

sign?

Complex numbers, I reallly can't  see any use for those in materials or the HUD....
Same thing with Probability calculation, I geuss.

Some way to do formulas and derivations might be needed somewhere in the HUD thing if you want stuff with distance/speed/accel, but you couldn't do it properly since you don't have a proper formula for anything. I think just doing (f(x)+f(x+h))/h is the only really probably way of working that in. You might want a function for that, if it really saves time.  I can see functions like that being used in the HUD a LOT.

BTW, is there any limit on the number of brackets one can use?

[Col. Fishguts]

sign(x) =

=  1 for x > 0
=  0 for x = 0
= -1 for x < 0

[Bobboau]

added.

I realy don't think that there is any way to do derivitives/integrals properly, there is no way of getting what the value of something was last frame (though frame time should be available) anything that you'd want the information for it will probly have a hard coded ship variable for it anyway. so I don't think I'm even going to contemplate any calc opperations, so no df/dx.

there is no limit on the size or complexity of the function (in theory) and you should be able to use as many parenthises as you want (so long as you make sure you close them all)

[kasperl]

'nother question: Any way at all to do something a bit more permanent then a single frame? It'd be a good thing for the HUD, obviously, and also when you need to do flickering materials you need to record a certain length of time, I would think.
Since framerates can vary greatly, and you don't want to cause a migraine/epiliptic attack for those with a good rig, while those on a slower computer see the flickering once a second. (Gross exeguration, but you get the idea.)

Would SEXP variables be accesable by this part of the code? (I'm thinking HUD here again.)