00:00:00 --- log: started forth/18.10.31
00:18:49 --- join: dys (~dys@tmo-100-141.customers.d1-online.com) joined #forth
00:25:12 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
00:27:57 --- quit: wa5qjh (Remote host closed the connection)
00:30:07 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth
00:30:07 --- quit: wa5qjh (Changing host)
00:30:07 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
00:30:17 --- join: leaverite (~quassel@175.158.225.202) joined #forth
00:30:17 --- quit: leaverite (Changing host)
00:30:17 --- join: leaverite (~quassel@freebsd/user/wa5qjh) joined #forth
00:31:10 --- quit: leaverite (Client Quit)
00:39:16 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
00:54:03 --- quit: dys (Ping timeout: 244 seconds)
00:59:25 --- quit: proteusguy (Ping timeout: 252 seconds)
01:05:08 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
01:05:29 --- join: proteusguy (~proteus-g@110.164.126.166) joined #forth
01:05:29 --- mode: ChanServ set +v proteusguy
01:09:31 --- quit: nighty- (Max SendQ exceeded)
01:10:25 --- quit: smokeink (Ping timeout: 252 seconds)
01:26:27 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
01:33:23 --- join: smokeink (~smokeink@42-200-116-228.static.imsbiz.com) joined #forth
01:48:50 --- quit: proteusguy (Remote host closed the connection)
01:56:12 --- quit: john_cephalopoda (Quit: Trees can see into your soul.)
01:59:56 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
02:03:48 --- quit: ashirase (Ping timeout: 244 seconds)
02:09:53 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
02:10:03 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:13:29 --- quit: siraben (Remote host closed the connection)
02:13:38 --- quit: jimt[m] (Remote host closed the connection)
02:13:43 --- quit: bb010g (Read error: Connection reset by peer)
02:13:44 --- quit: pointfree[m] (Remote host closed the connection)
02:17:06 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
02:26:19 --- join: bb010g (bb010gmatr@gateway/shell/matrix.org/x-olulzjakihyqllpc) joined #forth
02:27:03 --- quit: wa5qjh (Remote host closed the connection)
02:31:04 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth
02:31:04 --- quit: wa5qjh (Changing host)
02:31:04 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
02:33:08 --- quit: nighty- (Quit: Disappears in a puff of smoke)
02:38:45 --- join: tabemann_ (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
02:39:04 --- quit: tabemann (Ping timeout: 250 seconds)
02:57:49 --- join: jimt[m] (jimtmatrix@gateway/shell/matrix.org/x-kelnilwqkzstugct) joined #forth
02:57:49 --- join: pointfree[m] (pointfreem@gateway/shell/matrix.org/x-fzppntxvawqxdjiw) joined #forth
02:57:49 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-omormhipzbtvcmwg) joined #forth
03:10:40 --- quit: siraben (Changing host)
03:10:41 --- join: siraben (sirabenmat@unaffiliated/siraben) joined #forth
03:10:41 --- quit: siraben (Changing host)
03:10:41 --- join: siraben (sirabenmat@gateway/shell/matrix.org/x-omormhipzbtvcmwg) joined #forth
03:14:16 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth
03:52:10 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
03:53:45 --- quit: john_cephalopoda (Remote host closed the connection)
03:54:19 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
04:13:53 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
04:26:35 <KipIngram> Morning guys.
04:31:01 <rdrop-exit> Good evening Kip
04:40:50 <KipIngram> So, for a while yesterday I was sort of psyched about the idea of playing with that coprocessor concept using a circuit I'm planning to put together sometime - it will have a processor, FPGA, RAM, and some other stuff.  It's intended to be a "core launch point" for various things I might decide to build around it.
04:41:38 <KipIngram> But later I realized that the processor I choose will almost certainly have internal RAM, and the Forth will likely fit entirely within it.  So I could still toy with the idea, but I doubt it would wind up giving more performance than just running Forth from internal memory would.
04:42:04 <KipIngram> I could deliberately put the Forth in RAM, just as an experiment to see how much the coprocessor sped th ings up.
04:42:38 <KipIngram> But I doubt it would be useful practicallu; it really needs to be inside the CPU.
04:43:54 <rdrop-exit> Intel's coming out with a x86 CPU+FPGA chip
04:45:22 <rdrop-exit> https://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost
04:45:47 <KipIngram> Ah, interesting.
04:45:59 <KipIngram> That's definitely worth keeping an eye on.
04:46:26 <KipIngram> What I wish Intel would do is to let us microcode their chips.
04:49:19 <KipIngram> Looks like it will likely be an Altera-based FPGA; that works.  They're pretty good.
04:54:47 <rdrop-exit> I imagine this is just a first step towards merging the two technologies.
04:55:34 <KipIngram> I think that's GREAT.
04:56:33 <KipIngram> I've seen a number of "ideas" here and there that I wish would become more mainstream.
04:57:03 <KipIngram> I looked at one processor a couple of years ago that had a nice cache management approach.  Basically the physical RAM showed up in two sections of the address space.
04:57:13 <KipIngram> Using one of those logical ranges you got normal caching behavior.
04:57:27 <KipIngram> But you could access a variable via the other logical range and it wouldn't cache it.
04:57:38 <KipIngram> Such a simple way to give flexibility in that area.
04:58:14 <rdrop-exit> Elegant
05:10:11 <rdrop-exit> I have a paper design for a hard real time oriented stack machine for FPGA, haven't gotten around to finishing it.
05:12:20 <KipIngram> I think Forth has terrific real-time potential.
05:12:32 <KipIngram> I've got a paper/book on that somewhere in my PDF repository.
05:13:42 <rdrop-exit> By hard real time I mean deterministic, no caching, no interrupts, all instructions single cycle, built-in timer/counter instructions.
05:13:49 <KipIngram> Real time programming doesn't really get the street cred it deserves these days.  I had a really sharp and capable kid working on my team at one of my jobs, who looked me straight in the eye and said "it's not possible to make this work 100% of the time."  
05:13:56 <KipIngram> And he was NOT talking about inevitible hardware failures.
05:14:07 <KipIngram> He was talking about making a system meet its real-time operational constraints.
05:14:33 <KipIngram> He wanted to use non-real-time programming techniques, and just take "good enough."
05:14:43 <KipIngram> I just didn't know how to respond to that.
05:16:05 <rdrop-exit> The desktop+server world is all geared towards lowering average case performance.
05:16:18 <rdrop-exit> Determinism flies out the window.
05:16:19 <KipIngram> Right.
05:17:18 <KipIngram> And I'll admit it's gotten harder than it used to be - it's just much harder to pin down timings and so forth these days.
05:17:28 <KipIngram> But it can still be done, if you're willing to reach deep enough down into the stack.
05:17:38 <rdrop-exit> The chip has two sets of stacks for two cooperating processes, any additional concurrency requirements would be handled by coroutines.
05:17:58 <rdrop-exit> No interrupts, not even a timer interrupt.
05:18:01 <KipIngram> Cool.
05:18:49 <rdrop-exit> I miss the days when you could count instruction cycles. :)
05:19:01 <KipIngram> I think a cycle counter is a totally adequate solution for timekeeping.  Just initialize it, if you want to, at startup, and let it run.
05:19:39 <KipIngram> I did a calculation once to see how long it would take the cycle counter in my 64-bit system to roll over; I forget the exact outcome, but it was like 160 years or something like that.
05:20:53 <KipIngram> Ok, just did that again.  A 64-bit counter running at 3 GHz would roll over in about 195 years.
05:21:23 <KipIngram> Of course, when your frequency can change during operation that becomes more problematic.
05:22:23 <KipIngram> Also, I think interrupts have gotten too much cred - in embedded applications devoted to a specific purpose they're not always the way to go.
05:22:39 <KipIngram> A polling loop can sometimes be better, when you KNOW the things are going to happen on a schedule.
05:23:04 <KipIngram> Interrupts are good for handling a large number of diverse events that may or may not happen - you can avoid devoting any CPU resources to "checking on them."
05:23:34 <KipIngram> In that case I described above the application was to move packets of information continuously over an RF link.
05:23:35 <rdrop-exit> I agree, interrupts make a system non-deterministic from the get go
05:23:43 <KipIngram> The packets were generated at a fixed rate and had a fixed size.
05:23:47 <KipIngram> Everything was totally nailed down.
05:23:54 <KipIngram> It was a perfect situation for polling.
05:24:38 <KipIngram> Yes.  If you DO have interrupts in your real-time system, you have to figure out the worst-case impact of them and make sure you still meet your requirements.
05:25:12 <KipIngram> But interrupts are "sexy" or something like that - people feel like you're not being sophisticated enough if you don't have them.
05:25:19 <KipIngram> You must be leaving performance on the table...
05:25:22 <rdrop-exit> It quickly becomes intractable
05:25:26 <KipIngram> "Amateur."
05:25:34 <KipIngram> Not you.
05:25:44 <KipIngram> That attitude toward not using interrupts.
05:26:07 <rdrop-exit> Right, I'm in full agreement with you
05:26:31 <john_cephalopoda> Hah! I got a Forth Mandelbrot: https://thecutecuttlefish.org/tmp/fractal.png
05:26:37 <KipIngram> Oh, cool.
05:26:46 <KipIngram> I want to write one of those at some point.
05:26:52 <john_cephalopoda> They are really simple.
05:27:13 <KipIngram> Yes, the math is for sure.  You do need a bignum package, though, right?
05:27:15 <john_cephalopoda> The wikipedia article has the code, implementing it is trivial.
05:27:26 <rdrop-exit> Nice!
05:27:40 <john_cephalopoda> I am using the ANS float extension for it.
05:28:14 <KipIngram> Can it just keep diving down, indefinitely, or does it run into the limits of its floating point precision eventually?
05:28:15 <john_cephalopoda> At that scale it is enough. If I want to zoom in, it can get a bit more complicated.
05:28:24 <rdrop-exit> brb
05:28:35 <KipIngram> ^ ok, that's what I thought.
05:28:39 <john_cephalopoda> I am pretty sure that it will approach the edge of precision.
05:28:55 <KipIngram> It's really fascinating watching one of those things unfold as you keep diving in.
05:30:43 <john_cephalopoda> I might try to create one in a way that makes it possible to zoom in properly.
05:32:12 <KipIngram> That's what I want to do - I think that will be a big part of the fun for me; implementing the bignum stuff.
05:41:39 --- quit: john_cephalopoda (Quit: Trees can see into your soul. They lurk everywhere.)
05:44:29 <rdrop-exit> I'm thinking of trying out some tweeks to the Forth-83 style vocabulary subsystem
05:45:27 <KipIngram> Ah, neat - what exactly?
05:45:42 <KipIngram> I forget exactly how F83 works on that; vocabularies sort of evolved over the years.
05:46:16 <KipIngram> In my past implementations I've had searches of an individual vocabulary proceed past the root of that vocabulary, and go on into the ancestors.
05:46:35 <KipIngram> I think this time I'm not going to do that - having a vocabulary in my context will mean that vocabulary, and only that vocabulary is searched.
05:46:50 <rdrop-exit> I'd like to just use variables for vocabularies, and just have vocabulary management words take their addresses as parameters
05:47:04 <KipIngram> Right - that makes sense.
05:47:16 <rdrop-exit> Sounds like your using a FIG style vocabularies
05:47:21 <KipIngram> I might try that too - I think it would be easier to "get to" from where I am now.
05:47:33 <KipIngram> Yes, they're closer to fig than anything else.
05:47:47 <KipIngram> I've forgotten the details, but I think there were some slight differences in my last imp.
05:47:57 <KipIngram> For one thing, I support a context stack.
05:48:03 <rdrop-exit> Me too
05:48:06 <KipIngram> Whereas I think in FIG CONTEXT was just a variable.
05:48:24 <KipIngram> I like the "stack of stacks" idea we've discussed a few times here.
05:48:43 <KipIngram> I do think it should be easy to restore the context to the state it was in before you modified it.
05:49:11 <rdrop-exit> stacks of stacks sounds like more sophistication than I need
05:50:17 <rdrop-exit> I prefer to keep things spartan until I really need more
05:50:34 <KipIngram> I think one context stack could possibly get me there too, if invoking a vocabulary doesn't remove the existing instances of it in the stack.
05:50:48 <KipIngram> Then I could just mark the top of stack spot, add whatever I wanted, and then drop back to that stack top.
05:51:06 <KipIngram> You might search a vocabulary more than once that way, but that seems innocuous to me.
05:51:25 <KipIngram> Would just have a slight performance impact, and it would remove a whole layer of extra complication.
05:52:26 <rdrop-exit> In the variant I'm thinking of vocabularies don't do annything on their own, they're just variables.
05:53:57 <rdrop-exit> I'd have a word like USAGE ( va -- ) which pushes the vocabulary onto the context stack.
05:54:28 <rdrop-exit> So you'd do COMMON USAGE or FORTH USAGE etc...
05:55:59 <KipIngram> Right - nice syntax.
05:56:17 --- quit: smokeink (Ping timeout: 268 seconds)
05:56:20 <KipIngram> Ok, I think I like this better.  What I really "liked" was not the stack of stacks idea itself.
05:56:34 <KipIngram> But rather just the ability to restore the context to how you found it before you messed with it.
05:56:49 <rdrop-exit> Right
05:56:52 <KipIngram> So you'd say something like 
05:56:58 <KipIngram> <vocabulary> USE
05:57:02 <KipIngram> or something along those lines.
05:57:39 <KipIngram> Would DEFINITIONS still be used to copy the top of the context stack to CURRENT?
05:57:47 <rdrop-exit> Yes, I was thinking of naming it USAGE
05:58:00 <KipIngram> Ok.
05:58:32 <KipIngram> So what's the particular motivation to not have them "self-add" to the stack?
05:58:37 <rdrop-exit> No DEINITIONS would just take a vocabulary address just like usage
05:58:50 <KipIngram> Ah - that sort of answers the last question.
05:58:52 <KipIngram> I see.
05:59:15 <rdrop-exit> I like to expose addresses in my Forth code, rather than bury them
05:59:15 <KipIngram> So you'd be able to have a vocabulary CURRENT without having it in CONTEXT.
05:59:22 <rdrop-exit> yes
05:59:28 <KipIngram> Makes sense.
06:01:39 <rdrop-exit> The ultimate handle of something in memory is its address, I don't like to hide them too quickly in a layer of abstraction/automation
06:02:30 <rdrop-exit> That's why I don't use the ANS VALUE and TO
06:05:13 <rdrop-exit> Instead of the ANS/83 ONLY, I would have a postfix ONLY ( va -- )
06:05:44 <rdrop-exit> e.g. FORTH ONLY instead of ONLY FORTH
06:06:42 <rdrop-exit> Anyway it's all still just half-baked musings
06:07:06 <KipIngram> I think maybe more than half.
06:07:10 <KipIngram> Sounds pretty sound to me.
06:07:23 <KipIngram> I haven't written this part of mine yet, so I'll throw these ideas into the crock pot.
06:08:50 <rdrop-exit> Thanks, the main disadvantage is more verbiage since a vocabulary doesn't automatically push itself anymore.
06:09:23 <rdrop-exit> Maybe
06:09:59 <rdrop-exit> Instead of FORTH-83's ONLY FORTH ALSO EDITOR DEFINITIONS
06:10:31 <rdrop-exit> I would have to do FORTH ONLY  EDITOR USAGE  EDITOR DEFINITIONS
06:10:54 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
06:11:07 <john_cephalopoda> And hi again.
06:11:12 <rdrop-exit> or something similar
06:11:16 <rdrop-exit> Hi John
06:12:24 <rdrop-exit> Anyways, I'll mull over it some more
06:14:04 <rdrop-exit> But since their variables, it becomes must easier to add other tools that take the vocabulary address as a parameter.
06:14:11 <rdrop-exit> *they're
06:14:27 <rdrop-exit> *much
06:15:17 <rdrop-exit> I'm such a terrible typist :)
06:15:59 <rdrop-exit> You should see my keyboard, only 61 keys
06:16:33 <WilhelmVonWeiner> I just bought a UPMC, with a tiny keyboard
06:16:44 <WilhelmVonWeiner> Typing on this'll be fun.
06:16:54 <rdrop-exit> https://www.reddit.com/r/MechanicalKeyboards/wiki/pok3r
06:17:39 <WilhelmVonWeiner> I used to have a poker 2
06:19:04 <WilhelmVonWeiner> broke it somehow
06:19:14 <WilhelmVonWeiner> now I use an HHKB Pro JP 
06:19:31 <WilhelmVonWeiner> a HHKB? an HHKB? weird
06:20:00 <rdrop-exit> Cool, I'm loving my 3, I have Cherry MX greens
06:20:36 <WilhelmVonWeiner> I've always preferred buckling springs  but MX reds were my poker 2
06:20:46 <WilhelmVonWeiner> since I used it at college
06:21:33 <rdrop-exit> I'm a slow plodding typist, I like the feedback of the greens
06:22:13 <WilhelmVonWeiner> I used to own a bunch of alps switchen keyboards and those were really low profile and nice to type on
06:22:30 <rdrop-exit> Ooh, nice
06:22:38 <WilhelmVonWeiner> if you like greens and haven't tried buckling spring, get a model M 
06:23:00 <rdrop-exit> I used a model M decades ago
06:23:33 <WilhelmVonWeiner> oh real cool
06:24:06 <WilhelmVonWeiner> did your fingers start to hurt after a long stretch using it too?
06:24:11 <WilhelmVonWeiner> that's why i use topre now
06:25:51 <rdrop-exit> I'm a very slow, type a little, pause and think, type a little more type of guy. Never had to do any long stretches of high speed typing.
06:27:05 <WilhelmVonWeiner> I don't know how some programmers do it, just pump out LOC
06:27:48 <rdrop-exit> I used to work with someone who could transcribe realtime a meeting with a dozen people, all interrupting each other
06:27:52 <jackdaniel> actually best contributions decrease number of LOC while preserving functionality and improving readibility
06:28:09 <WilhelmVonWeiner> were they using a stenotype
06:28:29 <rdrop-exit> No a notebook computer
06:28:36 <ttmrichter> WilhelmVonWeiner: I'm more interested in WHY they do it.
06:28:47 <ttmrichter> I'm suspicious of programmers who aren't lazy.
06:29:32 <rdrop-exit> Reminds me of the nerdy guy in Starting Forth with his mile-high stack of printouts :)
06:29:51 <rdrop-exit> Or was that Thinking Forth
06:32:04 <WilhelmVonWeiner> ttmrichter: maybe they spend a lot of time thinkin
06:32:08 <WilhelmVonWeiner> thinkin' forth
06:38:58 <rdrop-exit> Dinner's ready, see you all tomorrow
06:39:14 --- quit: rdrop-exit (Quit: Lost terminal)
06:59:48 <john_cephalopoda> Ok, I improved my Mandelbrot set viewer.
07:03:05 <john_cephalopoda> Now you can navigate around it with WASD and zoom in and out with + and -
07:03:15 <john_cephalopoda> https://thecutecuttlefish.org/mandelbrot1.html
07:03:21 <john_cephalopoda> Try it out! :D
07:15:09 <WilhelmVonWeiner> john_cephalopoda: i was refactoring your game of life and I do think you should read Starting Forth
07:15:09 --- quit: tabemann_ (Ping timeout: 276 seconds)
07:16:07 <WilhelmVonWeiner> some basic words like /MOD, ERASE, +!, RDROP, and the way of thinking introduced really improve the program
07:17:41 <WilhelmVonWeiner> for example your input handler turns from a big pile of IF...THENs with wasted DUPs into https://ghostbin.com/paste/zzdop
07:18:02 <WilhelmVonWeiner> ..."HANDLE-INPUR" lol.
07:18:04 <john_cephalopoda> I read parts of it but it was quite basic in the start so I didn't look much further. I'll read a bit more into it, thanks for the tip.
07:18:49 <WilhelmVonWeiner> Forth is inherently quite basic. Complex systems can arise from simple interaction
07:19:57 <john_cephalopoda> It's always hard to re-read the basics when one already knows them and it is easy to then overlook the following chapters that talk about advanced concepts.
07:29:40 <WilhelmVonWeiner> I will agree that is true
07:57:13 <KipIngram> I have a feeling almost no one comes to Forth from other languages and just immediately starts cranking out top-drawer Forth code.
07:57:22 <KipIngram> It's just "different enough" to make that very unlikely.
07:57:52 <john_cephalopoda> Heh
07:58:47 <WilhelmVonWeiner> so I set up OpenBSD on my umpc...
07:59:13 <WilhelmVonWeiner> gforth is broken on i386 with the current Clang, for the moment :^)
08:01:42 <john_cephalopoda> WilhelmVonWeiner: Have you tried out my mandelbrot set viewer implementation yet?
08:02:00 <WilhelmVonWeiner> let me grab it now
08:03:45 <WilhelmVonWeiner> That's awesome
08:04:45 <john_cephalopoda> :D
08:05:46 <WilhelmVonWeiner> I also didn't know you could put chars in single quotes like that
08:06:05 <WilhelmVonWeiner> must be a gforth thing
08:06:17 <WilhelmVonWeiner> I always use [CHAR]
08:07:25 <WilhelmVonWeiner> lina forth lets you do that with the prefix &
08:07:50 <john_cephalopoda> After ~ 50 zoom levels the floating point precision issue becomes an issue.
08:08:19 <WilhelmVonWeiner> gets a bit slow on my machine too
08:10:00 <john_cephalopoda> When you hold a key, it can't calculate fast enough and will buffer the key press.
08:10:13 <john_cephalopoda> I should maybe just drop those inputs.
08:12:29 <john_cephalopoda> Also I'm sure that the calculations could be optimized in some way.
08:20:41 <WilhelmVonWeiner> i'm just zooming around
08:20:52 <WilhelmVonWeiner> never really bothered with a mandelbrot before
08:25:00 <WilhelmVonWeiner> Surprised F+! isn't a word
08:26:35 <john_cephalopoda> Not hard to add :þ
08:26:51 <KipIngram> It would be better added as a primitive, though.
08:27:33 <WilhelmVonWeiner> Yeah, : F+! F+ F! ; is probably not worth executing
08:27:48 <WilhelmVonWeiner> unless you call it all the time and want to save memory
08:27:56 <john_cephalopoda> : F+! DUP F@ 1e0 F+ F! ;
08:28:15 <WilhelmVonWeiner> oh yeah lol
08:28:49 <WilhelmVonWeiner> i was looking at your code where you F@ and forget it's not already on the stack
08:30:56 <john_cephalopoda> https://thecutecuttlefish.org/tmp/mb2.png
08:31:07 <john_cephalopoda> Pretty interesting feature
08:34:52 <john_cephalopoda> GoL and Mandelbrot is that kind of stuff that I would have never tried out usually but that I felt like doing because I wondered how well it would work in Forth.
08:41:27 <WilhelmVonWeiner> Yeah, I would have never bothered to try that in python
08:41:38 <WilhelmVonWeiner> i'm usually just "why would you want to do that" 
08:42:12 <KipIngram> Sometimes the answer to that, for me, is "because it's there."
09:13:35 <siraben> john_cephalopoda:  What's the best precision of your floating point?
09:13:42 <siraben> That's the biggest barrier to any mandelbrot implementation.
09:14:45 <siraben> Also I've had fun with making a mandelbrot program in other languages to output image files in PBM format https://en.wikipedia.org/wiki/Netpbm_format
09:15:38 <siraben> You can make your images grayscale if you make it output a number J between 0 and N for each pixel where N is the max iterations and J is the iteration number where it diverged.
09:36:07 <john_cephalopoda> siraben: I have been using the gforth floating point numbers for the Mandelbrot set viewer. Not sure how good they are.
09:36:33 <siraben> Probably IEEE 754
09:36:47 <john_cephalopoda> In any case it works up to ~ 50 zoom levels.
09:41:01 <WilhelmVonWeiner> john_cephalopoda: I changed it a bit to use the stack more in the "CALCULATE_MB" and a couple other changes, it should maybe run a little faster? https://gist.github.com/b49d95312bc564237ebe4f4ffb73955b
09:41:22 <WilhelmVonWeiner> At least, I hope floating stack manipulations are faster than memory fetches and stores
09:43:51 <WilhelmVonWeiner> how do you determine the number of zoom levels? Is it the 1000 0 DO in CALCULATE_MB? I know absolutely nothing about what a fractal really is or how it's calculated
09:46:04 <john_cephalopoda> WilhelmVonWeiner: CALCULATE_MB runs a calculation in a loop. It leaves the loop if it has looped 1000 times or if one of the variable becomes larger than 4.
09:46:15 <john_cephalopoda> The number of iterations is the value for that specific pixel.
09:47:19 <WilhelmVonWeiner> oh is it something like "likelihood this pixel exists"
10:03:31 <john_cephalopoda> Not sure. I basically took over that algorithm from wikipedia.
10:04:49 <WilhelmVonWeiner> try to use less variables
10:05:28 <WilhelmVonWeiner> the stack is perfect for variables you use in one scope, or variables you pass around to different functions
10:06:39 <WilhelmVonWeiner> `F(x, y)` in Forth is just `y x F` after all
10:08:34 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
10:10:09 <john_cephalopoda> I'll try to rewrite it to make better use of the stack.
10:11:01 --- quit: MrMobius (Ping timeout: 244 seconds)
10:11:01 --- nick: [1]MrMobius -> MrMobius
10:15:35 <WilhelmVonWeiner> john_cephalopoda: https://ghostbin.com/paste/vekpz/raw
10:16:12 <WilhelmVonWeiner> Without changing anything outside CALCULATE_MB you can use the stack for all its calculations. 
10:16:45 <WilhelmVonWeiner> a ton of stack manipulation could do away with X0 Y0 but those are good variables
10:20:50 --- quit: xek (Ping timeout: 268 seconds)
10:26:55 --- quit: Zarutian (Read error: Connection reset by peer)
10:27:01 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
10:27:14 --- nick: Zarutian_2 -> Zarutian
10:31:08 <john_cephalopoda> Hmm, I'd like to benchmark versions of the algorithm.
10:38:44 --- quit: groovy2shoes (Quit: moritura te salutat)
10:48:04 <john_cephalopoda> I'm sure that the runtime can be improved.
10:48:55 <john_cephalopoda> WilhelmVonWeiner: Why are you using "RECURSE" btw? Won't it call MAIN and put the address of MAIN onto the stack?
10:52:18 --- part: john_cephalopoda left #forth
10:52:23 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
10:52:35 <WilhelmVonWeiner> That's why I RDROP
10:53:08 <WilhelmVonWeiner> the first time it does but the second time round it drops it
10:53:20 <john_cephalopoda> But is that really more efficient than just having an infinite DO loop?
10:53:30 <WilhelmVonWeiner> beats me
10:53:52 <WilhelmVonWeiner> It doesn't alter the flow of code like a regular LOOP
10:53:57 <WilhelmVonWeiner> or BEGIN...UNTIL
10:54:07 <john_cephalopoda> Uh, yeah, that's what I used.
10:54:21 <john_cephalopoda> Not sure if an infinite DO loop would work. 
10:54:30 <john_cephalopoda> Maybe with 0 increments.
10:54:46 <WilhelmVonWeiner> and also in gforth SEE BEGIN and SEE UNTIL
10:54:53 <WilhelmVonWeiner> RDROP RECURSE is probably less code
10:55:04 <WilhelmVonWeiner> idk that's a weak justification - I just like recursion
10:55:45 <john_cephalopoda> I dislike recursion. I didn't like it before Forth and when using it in Forth, it clutters the return stack incredibly fast.
10:55:58 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth
10:56:00 <WilhelmVonWeiner> that's what RDROP is for
10:56:45 <john_cephalopoda> When I do an actual recursion instead of "RDROP+RECURSE as a loop" I can't RDROP the return stack because I need it in the end to return :þ
10:57:21 <john_cephalopoda> With "actual recursion", I mean "A recursion that passes values down the line and passes them up again when it reaches the base case.
10:57:42 <john_cephalopoda> Off to sports (Volleyball), afk.
10:57:46 <WilhelmVonWeiner> You can duplicate whatever's on the return stack before entering your recursive word 
10:58:18 <WilhelmVonWeiner> then RDROP is leaving your "real" return destination untouched
10:58:58 <WilhelmVonWeiner> I mean an "actual recusion" will overflow the return stack eventually lol
10:59:47 <WilhelmVonWeiner> but I wouldn't say it "clutters" it, all those return addresses are about to be used
11:00:15 <WilhelmVonWeiner> enjoy your volleying and balling
11:12:59 --- quit: ncv (Remote host closed the connection)
11:27:57 --- join: dys (~dys@tmo-100-141.customers.d1-online.com) joined #forth
12:44:06 <john_cephalopoda> Back
13:29:03 <john_cephalopoda> Wow, it's amazing how much fun one can have with simple Mandelbrot sets :D
13:40:03 <john_cephalopoda> https://thecutecuttlefish.org/tmp/mb3.png
13:40:18 <john_cephalopoda> Hacked together, with adjustable iteration count and position display.
13:59:19 <john_cephalopoda> Really nice stuff at 262144 iterations and quite some zoom.
15:00:17 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth
15:00:17 --- quit: wa5qjh (Changing host)
15:00:17 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
15:47:34 --- quit: john_cephalopoda (Quit: Trees can see into your soul.)
16:02:54 --- join: smokeink (~smokeink@42-200-116-228.static.imsbiz.com) joined #forth
16:18:25 --- quit: cheater (Ping timeout: 264 seconds)
16:22:49 <siraben> john_cephalopoda:  Yep.  I love the Mandelbrot set, it didn't take much code but it generate beautiful images
16:26:06 <siraben> https://i.imgur.com/NFXBB6j.png
16:26:51 <siraben> it generates*
16:32:21 <siraben> I recommend you add the cardoid checker to your algorithm
16:32:24 <siraben> https://en.wikipedia.org/wiki/Mandelbrot_set#Optimizations
17:33:05 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth
17:33:14 <dave0> hi
17:33:25 --- quit: proteus-guy (Ping timeout: 264 seconds)
17:34:56 --- quit: nighty- (Quit: Disappears in a puff of smoke)
17:36:24 --- join: pierpa (5fea3cf5@gateway/web/freenode/ip.95.234.60.245) joined #forth
17:37:10 --- join: proteus-guy (~proteusgu@2403:6200:88a6:329f:a83d:b396:57d0:7677) joined #forth
17:47:47 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth
17:48:27 --- quit: wa5qjh (Remote host closed the connection)
17:50:13 --- join: wa5qjh (~quassel@175.158.225.194) joined #forth
17:50:13 --- quit: wa5qjh (Changing host)
17:50:13 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth
17:50:23 --- quit: smokeink (Remote host closed the connection)
17:50:45 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
17:59:49 --- quit: tabemann (Ping timeout: 240 seconds)
18:17:38 <KipIngram> Hi Dave.
18:19:13 <dave0> hi KipIngram 
18:31:37 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
19:53:06 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth
20:09:26 --- join: xek (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
20:34:10 <tabemann> how common is it for Forths to have separate data and floating-point stacks?
20:35:15 <tabemann> because Attoforth *could* have a unified data stack provided it was only used on 64-bit systems or the floats were downsided to 32-bit floats on 32-bit systems
20:36:29 <tabemann> but I don't really like that idea, because I'd like to have 64-bit floats on both 64-bit and 32-bit systems without resorting to double cells on 32-bit systems, which would be unportable
20:57:14 --- nick: moonythevampire -> moonythedustpile
21:22:08 --- quit: pierpa (Quit: Page closed)
21:45:56 --- quit: xek (Ping timeout: 244 seconds)
23:59:37 --- join: proteusguy (~proteus-g@110.164.126.166) joined #forth
23:59:37 --- mode: ChanServ set +v proteusguy
23:59:59 --- log: ended forth/18.10.31