Woo, I hope that fixes your issue.

*AHelper awaits Graph3DP updates

It is coming along smoothly! Something odd I noticed when trying to graph a sphere today. Compare the output of these two:

sqrt(36-X^2-Y^2)
(36-X^2-Y^2)^0.5

The former takes a loooong time to run and yields nan or inf; the second runs fast and produces a proper sphere. I'm using the lBasic and lApprox flags, but not the lGroup or lDistribute flags.

powf only supports powers >= 1.0. This is common amoung many powf's for different languages. If you can find a function that accepts it, woo! I need it

Otherwise, I need to find a way for gCAS2 to solve for that without just doing powf... Cookies for anyone that can find a way to do fractional powers without directly solving a power that is a decimal.

Found it! ... only for some http://en.wikipedia.org/wiki/Nth_root#Computing_principal_roots I know that there is a loss of precision, but :-\

The ^0.5 solution works perfectly fine for me. for some reason. Does that not use powf? My sqrt is using this currently for the numeric case:
Code:


Edit: I just remembered, I have another bug. Line 1 does yields a positive equation, Line 2 yields a negative equation:

Code:


Edit #2: One last thing: I have these really terrible lines in my sin() implementation. Help! No floating-point mod as far as I know.
Code:

for the first part, if you use powf for both ^ and sqrt algorithms, then I think I need to either optimize function calling or just convert sqrt --> ^0.5

Second edit, the negative is ignored due to the limitation of op nodes not using a numerical value. I don't know of a simple work-around. I need to see if there is a way to inject a -1*, or if I need to make a special temp op nNEG to just negate a child op. The parser can generate it, although I don't like unary ops using binary nodes, but that should work.

Are you tring to find modf? Also, those lines that you typed... *sigh* Those were problem lines in the 3D renderer. It would fail to work and possible get stuck. You can try to dumpster-dive libc libraries for a modf function

If I finish my game to the point that artwork is needed, I will try to get STL containers ported to the prizm so that you can use giac. Nothing like an Xcas-like frontend on the prizm If you want, try looking at GMP for any IEEE 754 floats.

Aye, I considered using Giac in the past, but I decided it was (at that point) way oversized for my needs. I agree that it would be better to just make sqrt() use ^0.5, but the thing that confuses me is the function's behavior when inside, it should essentially just always be taking the numerical ^0.5 path. Makes me worry about potential function parsing errors. Perhaps I'll try substituting the sqrt with a trig function and see what happens. I shall indeed look for a modf, although I'm having trouble thinking of a way to do something clever with the math.

Once Graph3DP is mature, then focus can be put towards giac. Sure, it works perfectly and it takes anything you throw at it. The only concern with using giac is that Casio might not want the calc banned from tests if it can perform that kind of math.

Also, I originally planned for root( instead of sqrt(, like on the ASM calcs, but due to me not having that function on GlassOS (as powf is retarded in SDCC), stuck with just sqrt(.

I think that such a ban would be more of an issue if we make a standalone CAS than as part of a grapher. Also, why did I not use the following algorithm? Am I missing something here?


Code:

:-\

That works, I think.

:-/

(Things can get interesting when you see the lDegrees flag in the header, just waiting to be used :-X)

Oh, I saw that flag all right. I saw it, made a mental frustration face, and glided onwards. In fact, I think I'll actually handle it in my version of gCAS, even if I don't yet have a place in Graph3DP to turn it on and off. As with the previous gCAS2, I'll have to upstream you my changes.

Edit: Well, that was beyond trivial.

Code:

I kinda stopped doing feature additions since you are working on it, just bug fixes.

That works Just make sure that M_2PI has that toggle. forgetting one can get fun

Err, you lost me there. If unsigned char gcas_alg_func_trig(cas_node **n, cas_eval_level flags, cas_node_type type) {...} has that right before it calls down to msin(), mcos(), or mtan(), why would I have to mess around with the 2PI constant?

I meant that you should make sure that where ever you use 2*π or any other radian function/manipulation that you check for that flag.

Fair enough, but currently the three forward (not inverse, not arc) trig functions are the only place where that's relevant.

*bump* Since we have math.h slash libm now, I added sin, cos, tan, sinh, cosh, tanh, asin, acos, atan, ln, and log to Graph3DP. I've been playing around and testing it (especially since rotation is finally working properly, hurray), and I noticed some odd sqrt behavior. I suspect the problem is that I'm missing some flag to make it do immediate variable substitution:

• sqrt(Y^2+X) yields valid values for all X,Y
  
• sqrt(Y^2+X^2) yields inf for all X,Y and takes a moderate time to calculate.
  
• sqrt(Y^2+(X^2)) yields inf for all X,Y and takes a long time to calculate.
  
• Using ^0.5 instead of sqrt() removes the issues, although calculation time still seems abnormally long
  

The minor problem is that sqrt() is undependable; the bigger problem is that I suspect I need to force it to do immediate variable->constant substitution. Thoughts? I will also investigate on my own, but I'm running on substandard energy levels.

Edit: OK, it seems like when a function returns false because it was instructed to lApprox and the leaves n1 and/or n2 do not contain numbers. It further seems that if that happens, then gcas_tree_eval_step() should fall through to the "// Travel if we didn't simplify" code, which seems to traverse further down, and, theoretically, eventually simplify variables to constants. My nNUMBER case in eval_step(), by the way, looks like this:
Code:
where the constant_simp() code is as follows:
Code:
The investigation continues.

Edit: Found! Here's the diff that fixes the problem:

Code:


Edit #2: I worked past another issue by simplifying how gcas_tree_eval() works; if you'd like, I can show you my simplification. The latest issue is that -(3), while valid, parses as 3 instead of -3. And the issue extends to -func(blah), etc.

*bump* Implemented what seems to be fully-functioning negative operator (pNEG) support. I'd be happy to share the changeset with you if you want, AHelper. If it turns out that this works properly, then a Graph3DP beta may be forthcoming today...

Excelent work with getting loads of stuff added to gCAS2! I would love it if you send me the url for the source or changes

Yes, I went to send you a link to my repository yesterday, only to discover that in changing desks I unplugged the machine on which my repo is stored. As soon as I plug it back in, I shall send you the relevant link.

Still waiting for that link.

so can i use this on my CX and it will work like a CAS and be able to simplify?