User talk:GordonCharlton: Difference between revisions
→vmax
No edit summary |
(→vmax) |
||
| (9 intermediate revisions by 2 users not shown) | |||
Line 59:
::::::: 25%, huh? That's pretty doable. Another 30 submissions or so and you'll be halfway there. At least as far as non-draft tasks. As for the combinators, yeah, Factor is probably about 50% combinators, lol. I really love that way of programming, though. I find it extremely flexible because you can tweak them as needed with partial application. But I like the library approach you've taken with Quackery. It's great to stick everything but the kitchen sink in a language, but there's something alluring about staring at a single page of words and having almost nothing feel out of reach. --[[User:Chunes|Chunes]] ([[User talk:Chunes|talk]]) 13:54, 27 January 2021 (UTC)
:: You wrote: "And probably even structs with just a few more words." <br>Were you thinking of something like this as a starting point? [http://rosettacode.org/wiki/Call_an_object_method#Quackery zen objects] --[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 19:49, 5 February 2021 (UTC)
::: I was thinking along the lines of objects that support multiple fields accessible by name. --[[User:Chunes|Chunes]] ([[User talk:Chunes|talk]]) 00:38, 9 February 2021 (UTC)
::::Yeah, at the moment they're accessible by number. Numbers could be named. I'll be developing this one slowly as I come across tasks that benefit from it. What's puzzling me at the moment is the best way to dig down into fields in nests within nests. --[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 12:07, 9 February 2021 (UTC)
:::: [http://rosettacode.org/wiki/Probabilistic_choice#Quackery Example of addressing fields by number] --[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 16:55, 9 February 2021 (UTC)
:::::Here you go. [http://rosettacode.org/wiki/Compound_data_type#Quackery Compound data type#Quackery] Thank you for suggesting structs. :-) --[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 22:31, 19 February 2021 (UTC)
== vmax ==
Hi, Gordon. I recently found myself reaching for a <code>vmax</code> that wasn't there when writing a solution for http://rosettacode.org/wiki/Price_fraction#Quackery. I think it might be a nice addition to a future edition of <code>bigrat.qky</code>. :)
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.
| |||