Yeah I noticed that iconmaster. I never really used a debugger before, though, so I didn't understood why it went so quickly through the code without letting me know where the error is.

However, in the template, I only see the notation for a partial derivatives, which is not something I was used to.

Out of curiosity, where in the world approximately are you from (USA here)? I personally prefer the d/dx*(expr) syntax myself and used it most frequently, but apparently the majority of the world uses the d()/dx syntax much more frequently (at least from the studies we've done).

∂<box>/∂<box>

Yes, that is the right one. Just lazyness on my part to avoid searching out a ∂ character while typing. :-)

Trying to type the ' without typing degrees first was challenging.

There are two quick places. First, the shift parenthesis key has a '<box>' on it. This is used to quote (not evaluate) arguments. Mainly, it is applicable for RPN use. You can just remove one of those and you have a single tic mark. Second, the quick character key on the shift-9 function has a tic mark there as well.

Quote from: sailerboy on September 25, 2013, 07:23:58 pm

However, in the template, I only see the notation for a partial derivatives, which is not something I was used to.

Out of curiosity, where in the world approximately are you from? I personally prefer the d/dx*() syntax (USA here), but apparently the majority of the world uses the d()/dx syntax much more frequently (at least from the studies we've done).

I'm from the good ole US of A (California if you want to be precise). I've only ever learned the d/dx*() syntax. I've certainly never seen the ∂ character before. When I looked it up on wikipedia (by searching for "upside down 6"), I got this article: http://en.wikipedia.org/wiki/Partial_derivative

This notation for partial derivatives were certainly not something I've ever seen in math class before, and at first glance, the notation confused me. I'm currently a math minor in university, and I've taken several upper division math classes, and though I've seen the concept of partial derivatives (that's a Calc 1 topic IIRC), I've never seen that notation before.

Would it be hard to, on startup, ask the user's locale? Say, American English vs British English vs Australian English all have their own quirks, and while the differences would be minor, it would prevent confusion like this.

The problem with USA is that they still use the English system (eg miles, Farheneit, pounds) instead of the metric system (km, Celsius, kilograms) that is used almost everywhere else. However, since USA is by far the largest developed market, it can't be ignored, so you pretty much have to let user choose the syntax. That said, it isn't always possible, so sometimes US people have to adapt to standards, I guess.

Even in Canada there are people who use the English system, because we only started using the metric system in the 70's. Since schools weren't developed much back then, most older people have never got used to the metric system and even younger people like me occasionally use the imperial system (for example, i still use pounds for my weight). Stores that sells fruits and other things where the price is based on quantity also display their prices based on pounds as a marketing tactic, since the price per pound looks cheaper than the price per kilograms.

I'm from the good ole US of A (California if you want to be precise). I've only ever learned the d/dx*() syntax.

Yeah, specifically I was referring here to placing the d/dx to the *left* of the expression instead of the expression above the dx part. I didn't realize the derivative symbol itself was unfamiliar!

I had a bug for today, but I forgot it in the hours I've been away from these forums. So I'll just tell you some places where the Help doesn't show up!

Today's bug: There's no Help section when pressing the Help button for the Characters menu, any of the coose boxes (templates, the ! menu, etc.) or the Memory Manager.

Today's Suggestion: There's only 10 graphic variables ever?? If we want to use sprites, we can only use the 10; if we want more, we have to hot-swap them out using DIMGROB, which can't possibly be memory/speed efficient.

The G1-G9 are really meant for temporary scratch locations. For example, they aren't saved on a power cycle or sent to the pc. However, it probably would be good to make sure the other commands work with local or exported grobs. Thanks for the reminder.

Oh. I only said this because it errored out when I tried to use a local variable as a grob.

...Of course, And that's only because I'm still afflicted with the 'error out every time' bug. I'm an idiot. So I guess there's more than 10 grobs after all?

Yeah same. That said, I didn't realize it existed until someone told me, though. I was sure that Help was just some general quick start guide like in some computer apps. I didn't realize it was an help section for almost everything. Maybe the first time the calc is started it should show a pop up notifying the user that the calc has on-calc help and just selecting something in the menu then pressing Help will show how to use that function? Else, maybe update the calc packages so that an updated PDF guidebook comes with them?

Quote from: timwessman on September 26, 2013, 05:04:49 pm

The G1-G9 are really meant for temporary scratch locations. For example, they aren't saved on a power cycle or sent to the pc. However, it probably would be good to make sure the other commands work with local or exported grobs. Thanks for the reminder.

Oh. I only said this because it errored out when I tried to use a local variable as a grob.

...Of course, And that's only because I'm still afflicted with the 'error out every time' bug. I'm an idiot. So I guess there's more than 10 grobs after all?

One workaround about the 10 GROB limit is to simply store multiple sprites or images in one GROB. They can be any size, but I think there is a limit on how much data you can store at once. Just take a part of your sprite sheet, store it into GROB2, dim GROB1 so that it's empty but large enough to fit all your sprites, then copy it in GROB1, then overwrite GROB2 with the next part of your sprite sheet before copying it below the 1st sprite sheet in GROB1, and so on. Then once you are done, GROB2 can be used for other things, such as a parallax background. Just setup a 336x256 GROB2, then fill it with 16x16 sky sprites. Afterward, using for loops, put a tilemap using your sprites and map data of your choice into a GROB3 of the size of your choice (for example, if your map is made of 256x15 tiles, then the GROB should be 4096x240 pixels large.)

Then just copy the necessary 320x240 chunks of GROB2 and 3 into GROB0 (the screen). I am unsure about how fast is this, but hopefully this should work unless the calc has bugs preventing it from doing so.

EDIT: if you are concerned about RAM usage (I think you have 16 MB to yourself and a 4096x240 image should be about 2 MB large and stored temporarily), then you can instead use 8x8 tiles and a 2048x120 image. The calc BLIT command supports scaling, so you can simply display 160x120 chunks at 2x zoom.