User talk:GordonCharlton: Difference between revisions
→vmax
m (→Quackery: oops) |
(→vmax) |
||
| (19 intermediate revisions by 2 users not shown) | |||
Line 27:
::: Which reminds me, I have a question for you about stack comments. Words like <code>witheach</code> have a stack comment like <code>( a --> ) or ( [ --> )</code>. This makes sense strictly from the ''stack'' standpoint, but as a ''word'' contract I find it doesn't give me the picture I'm looking for to understand the word, since there is no indication of the nest it expects following the word. Is this something that could be resolved with a stack comment notation, like <code>( [ . [] --> )</code>? Just spitballing here; the <code>.</code> indicates the word position, while the <code>[]</code> indicates a nest following the word. No wrong answer either way; I understand wanting to keep it simple. --[[User:Chunes|Chunes]] ([[User talk:Chunes|talk]]) 12:39, 26 January 2021 (UTC)
::::I almost included set operations in Quackery, but I decided to let users roll their own in the end. I mostly only put in things that I needed for the REPL - which is why bigrat.qky is an add-on. I ''really'' wanted rational arithmetic, but it's more than bare-bones Quackery, so it got shifted into its own file at an early stage.
::::I would have done sets with bitwise operations. i.e.
::::<lang> Quackery [ 0 ] is empty.set ( --> set )
[ 26 bit 1 - ] constant is set.of.letters ( --> set )
[ char A - bit ] is letter->set.element ( c --> setnum )</lang>
::::and so on. Something along those lines.
::::After the "fun" of coding Quackery in a language where formatting is part of the syntax I would never seek to impose a style on any part of Quackery. Develop your own in-house rules that you are comfortable with. Mine are based solely on making the source-code look super-consistent and fit nicely on a sheet of A4 with 12pt inconsolata for the book. Now they're a habit I feel no need to get out of. Good point about words that use <code>]'[</code> though.<br>[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 15:14, 26 January 2021 (UTC)
::::_____
<br>
::::I looked at ISBN13 Check Digit. I see the Factor influence in <code>filter</code>.<br><br>Um, does <code>' [ [ 1 ] [ 2 ] [ ] [ 3 ] [ 4 ] ] filter [ [] != ]</code> do what you expect? How about:
::::<lang>[ [] swap ]'[ swap
witheach [
dup nested
unrot over do
iff [ dip join ]
else nip
] drop ] is filter ( [ --> [ )</lang>
::::--[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 04:11, 27 January 2021 (UTC)
:::::Good catch! I've made a note to myself to test nests carefully in words that accept general input. I was wanting to check out how easy it would be to introduce a functional feeling to the language and it turns out: quite easy! Also, if you ever feel like adding a solution to a task I've already done, please feel free. Rosetta Code encourages that sort of thing as long as the approach is sufficiently different. --[[User:Chunes|Chunes]] ([[User talk:Chunes|talk]]) 05:28, 27 January 2021 (UTC)
::::::That's a catch I've caught so many times it's become part of my work-flow. Step 1, get it working for simple nests, Step 2, generalise it to nested nests by figuring out where to insert the <code>nested</code>.<br><br>Eventually I want to build a little library of the more useful combinators, but, lacking the background in functional programming (my LISP experience was mostly about consing up lists, and mapcar was rather exotic) I figured that I'd get some Quackery experience under my belt before addressing that. <code>filter</code> and <code>reduce</code> are obvious candidates, but beyond that the list of combinators that Factor offers is quite bewildering to me.<br><br>Indeed. I had noticed that Python users get the functional approach, the iterative approach, the recursive approach, dynamic programming, object oriented, Python 2, Python 3, ... (and then a scrap of Quackery just below it like an impertinent footnote at the end of a long chapter. Which amuses me. I have been tempted to add "Using Quackery" to the end of the the list of Python approaches. (<code>import quackery; print(quackery.quackery('$ "Hello World"')) </code> (or something like that.) LOL.) At the moment my distant mountain is [https://rosettacode.org/wiki/Rosetta_Code:TODO#Ideal_Minimum_Penetration Ideal Minimum Penetration] (fnarr), but if I see an opportunity to add a very different approach to a task I'll certainly add it.<br>--[[User:GordonCharlton|GordonCharlton]] ([[User talk:GordonCharlton|talk]]) 11:54, 27 January 2021 (UTC)
::::::: 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.
| |||