Using TWO trig functions will make SYSTEM Error
And color will work until Xstep or Ystep are above 100, then it's just color glich
Eiyeron wrote:
Using TWO trig functions will make SYSTEM Error
And color will work until Xstep or Ystep are above 100, then it's just color glich
I don't think it's two trig functions specifically, just that my parentheses counting is off. Assuming that my PhD Qual oral exam today goes smoothly (I'm super-duper nervous about it at the moment), I'll look into repairing the parser later this evening. And that's interesting to hear about the Xsteps/Ysteps; I wouldn't expect that to happen unless malloc is doing something odd, but I swear that I check for that.
cos*sin => crash
Cos/sin => crash
cos + sin => crash...
Eiyeron wrote:
cos*sin => crash
Cos/sin => crash
cos + sin => crash...
cos(sin()) -> No crash, I believe. Smile It's not the trig functions themselves, though, trust me on that. It's that I didn't quite fully understand how gCAS2's parse tree assembler worked, and the way that I hacked functions onto operators isn't quite right.
AHelper wrote:
I see you ignored the labels on the casio and used the TI z80 layout Wink
Kerm seems to be in the "make it like a TI" camp (see also Tetris, where he uses the 2nd key). I try to stick to the Casio way of doing it (my games all use the F-keys).
merthsoft wrote:
AHelper wrote:
I see you ignored the labels on the casio and used the TI z80 layout Wink
Kerm seems to be in the "make it like a TI" camp (see also Tetris, where he uses the 2nd key). I try to stick to the Casio way of doing it (my games all use the F-keys).
I use the Function keys entirely here. What exactly am I doing that's TI-style?
KermMartian wrote:
merthsoft wrote:
AHelper wrote:
I see you ignored the labels on the casio and used the TI z80 layout Wink
Kerm seems to be in the "make it like a TI" camp (see also Tetris, where he uses the 2nd key). I try to stick to the Casio way of doing it (my games all use the F-keys).
I use the Function keys entirely here. What exactly am I doing that's TI-style?


AHelper wrote:
I see you ignored the labels on the casio and used the TI z80 layout Wink


It's certainly not a problem or anything. Just two ways of approaching it.
Yes, I saw what he said, but I thought he was joking, since the Prizm labels are "Trace", "Zoom", "Window", "Sketch", "G-Solve", and "G-T", only half of which are relevant to Graph3DP. It doesn't make sense to me to have Trace, Zoom, Window, Z=, Info, Graph, as I would expect the first screen that any application puts me in to be the leftmost of its tabs.

Edit: Ah, ok, as long as it's not a problem. I just did it the way that I expected users would be most familiar with and would find most intuitive.
KermMartian wrote:
Yes, I saw what he said, but I thought he was joking, since the Prizm labels are "Trace", "Zoom", "Window", "Sketch", "G-Solve", and "G-T", only half of which are relevant to Graph3DP. It doesn't make sense to me to have Trace, Zoom, Window, Z=, Info, Graph, as I would expect the first screen that any application puts me in to be the leftmost of its tabs.

Edit: Ah, ok, as long as it's not a problem. I just did it the way that I expected users would be most familiar with and would find most intuitive.


The graph menu itself looks kind of ti-ish (block cursor, not as wide as the screen)

Also, when graphing to graphs at once, why not make one graph all one color and the other all another? (If that's already what you are doing, ignore me Razz)
Currently I'm putting them both into the Z-linked color scheme. I am going to be offering three color schemes eventually: the current system, some kind of white-to-aqua/black-to-aqua height-based system, and a third system where each graph is a single uniform color, as you propose.
KermMartian wrote:
Currently I'm putting them both into the Z-linked color scheme. I am going to be offering three color schemes eventually: the current system, some kind of white-to-aqua/black-to-aqua height-based system, and a third system where each graph is a single uniform color, as you propose.


In the finished product, will it remember what settings you chose? (black or white background, namely - I love the black background)

Also, instead of making f1 bring the trace, z=, etc. menu up, why not use shift like casio does? (or both)
Oh yes, and I also need to add an icon on the graph screen so that people know [F6] changes the background color and [F5] changes the graph color. Yes, I hope to make it both remember the settings you choose (colors, equations, and windows) in a file and be able to load them back.
elfprince13 wrote:
Also, I'm curious if you have any plans to support implicit plots and/or parameterized functions? Being able to port my snow-man from Maple to a hand-held calculator would pretty cool (and might make a nice advertisement for your Youtube demos).

http://img812.imageshack.us/img812/6084/snowmang.jpg


*coughs politely*
I hadn't really considered the possibility of supporting parametrized functions, because it would be fairly challenging, at least for Graph3D v1.0. For a future version, I think it would be a good feature to add, especially if one could use it to graph snowmen!
KermMartian wrote:
I hadn't really considered the possibility of supporting parametrized functions, because it would be fairly challenging, at least for Graph3D v1.0. For a future version, I think it would be a good feature to add, especially if one could use it to graph snowmen!

I have some really sweet (procedural/mathematical surface) visualizations in Maple that would be mind-blowing on a hand-held :D Even if I had to calculate the Frenet-Serret frame equations for my spacecurves by hand or not have reusable user-defined convenience functions, being able to use parameterized and/or implicit plots would be amazing. From a computational perspective, I don't think you're missing anything I used in the Maple spreadsheet I used to make the snowman (except for the Frenet-Serret calculations at the beginning). I've transcribed it here, sans the coloring/lighting/window options. Take a look and tell me if you think I'm wrong (as far as capabilities are concerned), but I could see this as a worthy end-goal for your program.

Quote:
> hatpath := t -> <2*t, 0, -(t-1)^2+1>:
> spacecurve(hatpath(t), t = -1 .. 4):
> TNB := TNBFrame(hatpath(t)):
> T := u -> subs(t = u, TNB[1]): N := u -> subs(t = u, TNB[2]): B := u -> subs(t = u, TNB[3]):
Because poofy hats are styling
> pompombumps := (θ, φ) -> 1+(3/32)*sin(16*θ)*sin(16*φ):
> hatfabric := (s,t) -> 4*cos(s)*N(t)+2*sin(s)*B(t):
Christmas-ish red and green lighting from light2
> mainhatplot := plot3d(hatpath(t)+hatfabric(s, t)*exp(.4*(-1-t)), t = -1 .. 4, s = 0 .. 2*π):
We'll re-use this bit a lot. save it as a convenience function
> ball := (ρ, θ, φ) -> <ρ*sin(φ)*cos(θ), ρ*sin(φ)*sin(θ), ρ*cos(φ)>:
> poofplot := plot3d(hatpath(4)+ball(pompombumps(θ, φ), θ, φ), θ = 0 .. 2*π, φ = 0 .. π):
> poofband := (q, r, s, t, u) -> hatfabric(s, t)+pompombumps(s, u)*(q*cos(u)*cos(s)*N(t)+q*cos(u)*sin(s)*B(t)+r*sin(u)*T(t)):
> bandplot := plot3d(hatpath(-1)+poofband(.5, 1, s, -1, u), s = 0 .. 2*π, u = 0 .. 2*π):
Making some snowballs
> snowman := seq(plot3d(ball(4+2*n, θ, φ)-<4, 0, 2+sum(2*((i+.5)*2), i = 1 .. n)>, θ = 0 .. 2*π, φ = 0 .. π), n = 1 .. 3):
Makes a segmented carrot by scaling the top end of the original segment down towards the tip.
> carrotsegment := (o, r, l, t, s) -> {<-7-o, 0, -7>+<r*t, sqrt(r^2-r^2*t^2)*cos(s), sqrt(r^2-r^2*t^2)*sin(s)>, <-7-o, 0, -7>+<-l*t, (r-r*t)*cos(s), (r-r*t)*sin(s)>}:
> carrot := seq(plot3d(carrotsegment(i, e^(-0.5e-1*i), 7-i, t, s), s = 0 .. 2*π, t = 0 .. 1), i = 0 .. 4);
Another convenience function. Eyes, mouth, buttons
> coal := (θ, φ) -> ball(.75, θ, φ):
> eyes := seq(plot3d(coal(θ, φ)+<-7, -3+6*n, -4.5>, θ = 0 .. 2*π, φ = 0 .. π), n = 0 .. 1):
Magic constants based on the snowball formulation above. This uses a spherical coordinate transform, with the ordered triplet rotated one position to the right so that "vertical" is along the x axis. This allows us to base the mouth curve on a single variable, rather than 2
> mouthsphere := (n, θ, φ) -> <6*cos((7/8)*π)-4, 6*sin((7/8)*π)*cos((9/8)*π+(3/16)*n*π), 6*sin((7/8)*π)*sin((9/8)*π+(3/16)*n*π)-8>+coal(θ, φ):
> mouthplot := seq(plot3d(mouthsphere(n, θ, φ), θ = 0 .. 2*π, φ = 0 .. π), n = 0 .. 4):
See above, only we can get away with just using normal spherical coordinates here, since the buttons only rotate along φ.
> button := (n, θ, φ) -> ball(8, π, (3/8)*π+(1/8)*n*π)-<4, 0, 18>+coal(θ, φ):
> buttons := seq(plot3d(button(n, θ, φ), θ = 0 .. 2*π, φ = 0 .. π), n = 0 .. 2):
> armpath := t -> <-3, t, abs(.25*t)-18>:
Taper the arms so they don't appear open at the end (even though they really are)
> armplot := plot3d(armpath(t)+<e^(-.1*abs(t))*cos(s), 0, e^(-.1*abs(t))*sin(s)>, s = 0 .. 2*π, t = -15 .. 15):
> display({armplot, buttons, carrot, eyes, snowman, bandplot, mainhatplot, mouthplot, poofplot});



Similarly, for this shell: http://img821.imageshack.us/img821/4992/shellrender.png
I tried it today, and I love it, though I wish there were some way to rotate around that other axis in the graph...
Deep Thought wrote:
I tried it today, and I love it, though I wish there were some way to rotate around that other axis in the graph...
Yeah, that's the whole "dynamic axis" thing that I need to do. I want it to always rotate about a pair of virtual axes that are in-out of the screen in the horizontal and vertical directions. Smile
Great job Kerm. This is already better than the best ti-84 3d grapher; as this has color, multiple equations and is on the Prizm. Keep up the good work.
zeldaking wrote:
Great job Kerm. This is already better than the best ti-84 3d grapher; as this has color, multiple equations and is on the Prizm. Keep up the good work.
Thanks very much, Zelda. Smile I look forward to continuing to improve it.
One thing I noticed, that probably needs to be fixed by the next version: Open Graph3D, press the [WINDOW] option, which IIRC is F2. Set XSteps or YSteps (or both!) to a high number, something along the lines of 500. Either when you press EXE to confirm the new [X|Y]Steps value(s), or when you next draw a graph, crashes galore. System memory error. I assume that you're allocating memory, or just pushing and array of vertexes of the graph onto the stack, and with such a high number of steps, I also assume you're filling memory and then some with them, causing the memory error.

If you want, I can test around later to find the safest, highest number of steps that don't cause a crash (on the current version), and report them here, so you can add a catch if any higher numbers are entered and say something along the lines of "TOO HIGH A NUMBER FOR FIELD".
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement