User talk:GordonCharlton: Difference between revisions
→vmax
(bigrats) |
(→vmax) |
||
| (2 intermediate revisions by the same user not shown) | |||
Line 74:
This was my first time really working with bigrats and I found it pretty interesting. Having instant access to numerator and denominator lets you tweak your calculations in ways that aren't readily apparent when working with a single value. But, of course, you need to tread especially lightly on the data stack. --[[User:Chunes|Chunes]] ([[User talk:Chunes|talk]]) 20:19, 9 March 2021 (UTC)
:: Hi, Chunes. Yeah, <code>vmax</code> would be a reasonable addition. OTOH, it's easy enough to code up just when required, and there are a whole lot of other words of similar complexity that would be handy. Feature creep vs. bare essentials.
:: Rationals are definitely an edge case. On the one hand, as you note, instant access to the num and den is convenient. The counter-argument is that rationals are undeniably composite, and having a single nest to represent them would ease the stack pressure. I pondered it a fair bit, and to be honest it could have gone either way. The answer - for me - was that switching between two numbers and a single nest is fairly easy - either with <code>2 pack</code> and <code>unpack</code> or, less cleanly but more efficiently with <code>join</code> and <code>do</code>. The question is, should every bignum word have to unpack its arguments at the start and pack them at the end, or is it preferable to let the programmer put in that additional code just when circumstances suggest it? ... If you would have preferred the former choice, you can put in a little preamble to your code along the lines of
<pre>
[ dip do do v+ join ] is [v+] ( [ [ --> [ ) ( .. and similar for all the other bigrat words ... )
</pre>
:: whereas if I had gone the other route, wrapping <code>[v+]</code> with <code>join dip join [v+] do</code> would be an option, but wouldn't that just feel like so much busywork?
:: In related news, I'm currently adding a new operator - <code>python</code> to allow you to to <code>exec()</code> a string of python script from within Quackery. The code to do that is trivial, but I'm spending so time giving it a workout before I document and release it. Mostly the workout consists of porting in turtle graphics from Python, and ... of course ... I'm using rationals to specify distances and angles. So I'm also experiencing the stack pressure. But... so far ... haven't felt the need to pack rationals onto nests. Anyway, a bit more testing and then I'll add it to The Book.
| |||