SirCmpwn wrote:
real(, identity(, and det( are full Razz
"full"? What about starting at real(50, or det(50, or something along those lines? Also, did you get a chance to look at the Wiki yet? I'd be happy to help you come up with a standardized format for the pages for each of the BASIC libs, like Inputs, Outputs, Details, and help document them.

Edit: Merth, I'm ok with Menu( if you guys are. However, to identify whether DCS is installed, how about using det([[42]]), and seeing if it returns 1337 or just 42?
Well, I don't want to learn more real(, identity(, or det( commands.
Also, I'm at work ATM, and will take a look at the Wiki later, if I have time.
KermMartian wrote:
However, to identify whether DCS is installed, how about using det([[42]]), and seeing if it returns 1337 or just 42?

Smells like an awesome Easter Egg!
merthsoft wrote:
KermMartian wrote:
However, to identify whether DCS is installed, how about using det([[42]]), and seeing if it returns 1337 or just 42?

Smells like an awesome Easter Egg!
For real. +1 For this.
Here's some ideas for Basic routines:


Code:
1)value->Label   (like writeback)
2)dbd(Label) (push a stack item using data at Label)
3)Asm(hex) (native assembly code)
4)AsmComp(hex,var) (store asm code to a var)


Hope no one's already mentioned them...
merthsoft wrote:
KermMartian wrote:
However, to identify whether DCS is installed, how about using det([[42]]), and seeing if it returns 1337 or just 42?

Smells like an awesome Easter Egg!
Nono, as a legit way of detecting whether DCS has libraries available for the user. If nothing is intercepting det([[]]) calls, then it will return 42. If Celtic is the only thing installed, it will return 0. If Doors CS is present and providing DCS and Celtic libs, it will return 1337. Does that sound fair?

anakclusmos wrote:

Code:
1)value->Label   (like writeback)
2)dbd(Label) (push a stack item using data at Label)
3)Asm(hex) (native assembly code)
4)AsmComp(hex,var) (store asm code to a var)

(1) Can you explain this more fully?
(2) THAT would be a fascinating way to do GUI stack manipulation. Anyone have thoughts on this?
(3) Celtic already has this: det(20...
(4) Celtic can already do this too.
ooo, I want stack access from TI Basic ktkxbai
I would very much prefer the original functionality to be unchanged. What if I want to use the DCS libs, and also want the determinant of that matrix? I suppose an if statement that checks if it's a 1x1 matrix would work, but it seems better to not change the actual functions.
SirCmpwn wrote:
ooo, I want stack access from TI Basic ktkxbai
Well, it's sounding like that definitely needs to be something that's allowed, but I'm hearing three main options for how to push to the stack:

(1) token(#,type,"STRINGOFHEX")
(2) token(#,type,[then more specific args based on (type)]
(3) token(#,type,Lbl, and then having STRINGOFHEX at Lbl.

Any thoughts on these options? Do they all make sense?

merthsoft wrote:
I would very much prefer the original functionality to be unchanged. What if I want to use the DCS libs, and also want the determinant of that matrix? I suppose an if statement that checks if it's a 1x1 matrix would work, but it seems better to not change the actual functions.
Well, Celtic already changes det([[single value]] to return 0 instead of (single value), so it wouldn't be a big deal. det( still returns the correct determinant for matrices larger that 1x1.
Can you elaborate on the last one?
Also, Goto to an undefined label
like token(#, LblString
SirCmpwn wrote:
Can you elaborate on the last one?
Something along these lines, I think:


Code:
PROGRAM:MYPROG
:[code goes here]
:token(8,2,S1
:[more code]
:Return
:Lbl S1
:"AA47F1E56E2A


SirCmpwn wrote:
Also, Goto to an undefined label
like token(#, LblString
Is this a library routine suggestion? I don't think I understand.
Still don't follow your code, can you explain what it would do?

Library routine suggestion, yes.
Id use number 3. Kerm, my first idea was to allow users to use hex after a label and you can store to the label like a var for games or change stack item properties before pushing them with dbd(
KermMartian wrote:
Well, Celtic already changes det([[single value]] to return 0 instead of (single value)


And that bugs me.

I think:
(3) token(#,type,Lbl, and then having STRINGOFHEX at Lbl.
Is the best one, that way you can have an actual data segment
SirCmpwn wrote:
Still don't follow your code, can you explain what it would do?
It would push the hex data in the string at Lbl S1 onto the GUIStack, packing it into bytes first, of course.

SirCmpwn wrote:
Library routine suggestion, yes.
But I don't understand why you would want to jump to undefined labels.

Merthsoft wrote:
I think:
(3) token(#,type,Lbl, and then having STRINGOFHEX at Lbl.
Is the best one, that way you can have an actual data segment

Anakclusmos wrote:
Id use number 3. Kerm, my first idea was to allow users to use hex after a label and you can store to the label like a var for games or change stack item properties before pushing them with dbd(
But guys, wouldn't some string manipulation followed by a call with Ans or StrN be so much easier for you (and so much easier for me, too!)? Would you lose something in particular?

IDEA for a routine! Pushing and popping Ans somehow?
So wait, are we just talking about the GUI stack? Is that what will drive with windows and stuff? In that case I'd prefer it probably more as number (2). Maybe allow both? So that you can use hex if you want, but also you can just use predefined functions.

As for pushing/popping ans, that sounds great.
Storing directly over a var is obviously easier than manipulating it.and if you store to an external var you might loose it. Writing back is so much better:)
merthsoft wrote:
So wait, are we just talking about the GUI stack? Is that what will drive with windows and stuff? In that case I'd prefer it probably more as number (2). Maybe allow both? So that you can use hex if you want, but also you can just use predefined functions.
Yeah, we're just talking about the GUI Stack. I agree that (2) seems to be a good option, even though it requires slightly more work from me than (1), because it will be more understandable for beginners and BASIC programmers.

merthsoft wrote:
As for pushing/popping ans, that sounds great.
Nifty. Everyone else?

Anakclusmos wrote:
Storing directly over a var is obviously easier than manipulating it.and if you store to an external var you might loose it. Writing back is so much better:)
Erm, is this an argument in favor of GUIStack push format (3)? I'm a tad confused.
Popping an immediate would be sweet too.
merthsoft wrote:
Popping an immediate would be sweet too.
You mean some equivalent of push Ans \ pop M or something?
  
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
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 2 of 8
» 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