00:00:00 --- log: started forth/18.11.11
00:31:08 --- quit: wa5qjh (Remote host closed the connection)
01:27:51 --- quit: pierpal (Read error: Connection reset by peer)
01:28:02 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
02:03:56 --- quit: ashirase (Ping timeout: 268 seconds)
02:07:01 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:11:34 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth
02:11:35 --- quit: ncv (Changing host)
02:11:35 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
03:13:15 <dave0> should i let the user supply a buffer for <# # #> or just use a fixed buffer? using a fixed buffer makes the code simpler
03:57:45 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
04:12:23 <WilhelmVonWeiner> whatever's simplest, personally
04:13:51 <WilhelmVonWeiner> "_Do Not Speculate!_ Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each one has 0 probability of realization. If you need an extension later, you can code it later - and probably do a better job than if you did it now." - Chuck Moore
04:14:11 <WilhelmVonWeiner> is having the user supply a buffer speculatrion and extensibility? imo, probably
04:29:50 <dave0> chuck's pretty cool
04:30:55 <dave0> "do a better job later" sounds spot on
04:35:52 <WilhelmVonWeiner> Chuck is incredibly underrated by the wider programming community
04:36:45 <WilhelmVonWeiner> I fear his lessons will be rediscovered by others with far less mental prowess, long after he's gone 
04:38:13 <dave0> hmm interesting.. in my <# # #> i reverse the string (rather than building it backwards in the first place) and i made a "reverse" word that accepted a general string, cos it is potentially useful by itself... but it's only used in #> so far and the code would be simpler if is tailored to #> specifically... that sounds exactly like what chuck said
04:40:37 <dave0> reverse "might be used" to reverse a string
05:26:23 <WilhelmVonWeiner> I have a utils/ folder where I put lines of code that might come in handy
05:28:56 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
05:32:48 <dave0> ah good idea
06:17:22 --- quit: dave0 (Quit: dave's not here)
06:30:16 <KipIngram> Yeah, that is a good idea.
06:30:58 <KipIngram> And yes, I do think Chuck (along with Forth in general) is underrated.
06:31:14 <KipIngram> There are cetain "concepts" that I think nothing gets as right as Forth.
06:31:25 <KipIngram> But you just never hear of it in any "official" curriculum.
06:32:01 <KipIngram> I think that the academic CS community just sort of shuns simplicity of the magnitude Forth offers.
06:32:59 <KipIngram> It's not "flashy" enough.  They cater to things that they can write a bunch of papers about.
06:33:54 <WilhelmVonWeiner> I just don't think people use it enough.
06:34:07 <WilhelmVonWeiner> Write more Forth, and less implementations of Forth.
06:34:15 <WilhelmVonWeiner> s/less/fewer
06:34:18 <KipIngram> Yeah, that's a good point.
06:34:38 <KipIngram> It is easy to wind up with implementation being a hobby, so to speak.
06:34:43 <KipIngram> I'm guilty of that myself, to some degree.
06:37:37 <KipIngram> One reason that happens to me is that my Forth implementations are generally oriented toward embedded environments.
06:37:51 <KipIngram> So when I need to program a desktop, I wind up using other things.
06:38:09 <KipIngram> These days usually Python, unless I need better performance, in which case C.
06:39:04 <KipIngram> I usually don't tie my os filesystem into my Forths in any real way.
06:42:57 <john_cephalopoda> KipIngram: How can one like an OS that one can't make factory factory interfaces with? ;þ
06:43:43 <KipIngram> :-)
06:43:46 <KipIngram> Yeah.
06:43:59 <KipIngram> Mostly above, though, I was talking about why we don't see more *academic* attention to Forth.
06:44:14 <KipIngram> Which of course leads to it not being used.
06:44:19 <KipIngram> No one is taught it in school.
06:44:29 <john_cephalopoda> Forth is simple.
06:44:34 <KipIngram> Yes.
06:44:44 <john_cephalopoda> I don't know what academic things one could do with it.
06:45:10 <KipIngram> Well, that's my point exactly - it doesn't "lend itself" to the whole "academic spectacle" in the way some of the other languages do.
06:45:15 <KipIngram> So people just never HEAR about it.
06:45:20 <john_cephalopoda> With haskell you can discover new monadic stuff and prove some type theory stuff.
06:45:32 <KipIngram> Right.  Exactly that sort of thing.
06:45:46 <WilhelmVonWeiner> Academia isn't that relevant. Academia don't often teach Erlang/Elixir either.
06:45:48 <KipIngram> "Scholars" love that sort of stuff.
06:45:58 <john_cephalopoda> (I don't know much about haskell but it is so complex that you basically need a special lecture just to understand the language's base principles)
06:46:16 <WilhelmVonWeiner> john_cephalopoda: Haskell is actually, fundamentally pretty simple
06:46:23 <WilhelmVonWeiner> people really overcomplicate it
06:46:35 <KipIngram> Well, I haven't found the "simple presentation" of it yet.
06:46:59 <WilhelmVonWeiner> I mean the homepage does a pretty good job
06:47:32 <WilhelmVonWeiner> It's just using functions to transform data from looking like A to looking like B
06:47:43 <KipIngram> I think part of the problem may just be that I'm not "mentally organized" to like functional programming much.
06:48:12 <WilhelmVonWeiner> Forth is mostly functional. Just looks procedural.
06:48:30 <KipIngram> It doesn't have a functional feel to me.
06:48:42 <WilhelmVonWeiner> KipIngram: https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming
06:48:47 <KipIngram> It seems like a very clear "I'm telling the computer what to do" vehicle.
06:48:55 <WilhelmVonWeiner> That is functionality, imo
06:48:56 <KipIngram> I'll take a look.
06:49:15 <WilhelmVonWeiner> "Apply this function to this data. Apply this function to the output."
06:49:20 <WilhelmVonWeiner> etc etc
06:50:37 <KipIngram> Heh.  I like this writer already.
06:54:09 <KipIngram> Ah, I'm seeing now why you are fond of anonymous functions in your Forth.
06:55:07 <WilhelmVonWeiner> hm?
06:55:16 <WilhelmVonWeiner> oh functional, yeah
06:57:33 <KipIngram> So one thing I'm noting here is that at least for me embedded programming feels more natural as an imperative thing.
06:57:46 <KipIngram> I've got this piece of hardware, and I want to drive it through this set of operations.
06:57:53 <KipIngram> Do this, then do that, then do that other thing.
06:59:08 <WilhelmVonWeiner> `f(); g(); h()` lol
06:59:30 <WilhelmVonWeiner> functional doesn't mean your whole program needs to be a single big function
07:00:09 <KipIngram> Right, but right after that she recommends "remove state."
07:00:21 <KipIngram> But my embedded hardware HAS a state, so modeling it in my software feels natural.
07:00:22 <WilhelmVonWeiner> to me it's akin to dataflow programming and data-oriented design
07:00:45 <WilhelmVonWeiner> Yeah I'm never too sure about completely removing state though I usually do it
07:01:02 <WilhelmVonWeiner> I will pass state as a parameter to every function if it's avoiding globality
07:01:36 <WilhelmVonWeiner> but recently, after reading "Programming a Problem Oriented Language", where Chuck tells the reader to GLOBALISE EVERYTHING
07:01:46 <KipIngram> I do see map and reduce as kind of useful.  If I were implementing them I'd probably try to arrange it so the code following the map/reduce word specified teh functionality.
07:01:59 <WilhelmVonWeiner> And then seeing a blogpost on (I think) lobste.rs about global state being good
07:02:00 <KipIngram> It would wind up implemented as a loop of some kind, of course.
07:02:09 <WilhelmVonWeiner> I've kind of changed my mind on it
07:02:46 <WilhelmVonWeiner> why are we localising everything? There is no inherent good in programming, only immediate good
07:04:27 <KipIngram> Probably the simplest way I could think of to implement map would require me to factor the mapped code into a word, then map and reduce would just iterate over the immediately following compiled word.
07:04:40 <KipIngram> As opposed to moving the xt through the data stck.
07:04:43 <KipIngram> stack
07:06:16 <KipIngram> That would likely feel pretty useful to me when I get that system together someday that supports vectors and so forth.
07:06:28 <KipIngram> Because then it would be easy to put an "iterable item" on the stack.
07:09:58 <KipIngram> Some of these functional examples look like they'd definitely be less efficient than their imperative counterparts.
07:11:02 <KipIngram> set_canada_as_country = call(lambda x: 'Canada', 'country')
07:11:14 <KipIngram> vs. 
07:11:26 <KipIngram> country = 'Canada'
07:11:49 <john_cephalopoda> I think the localization is caused by the modularization paradigm that came with OOP.
07:12:12 <john_cephalopoda> With all their getter and setter methods.
07:13:32 <KipIngram> It's a good article.  I think it's another thing that probably "has its place," but I doubt I'll ever decide that it's "best for everything."
07:13:55 <john_cephalopoda> It makes sense - if you are working on a software project and some random function can set the global variable "country" to "Moon", then things could go wrong. But when you have a getter and setter method, you can sanitize what you get as input and make sure that it is an actual country.
07:15:01 <KipIngram> :-)  Or you could just know not to set country to a non-country.
07:15:15 <KipIngram> I do see your point, though.
07:15:20 <KipIngram> It's a form of "defensive programming."
07:15:26 <john_cephalopoda> KipIngram: Tell that to a system security person :þ
07:15:51 <john_cephalopoda> Sanitizing inputs is done wrong so often...
07:16:03 <KipIngram> Right.  It's different in that kind of environment, where you have potentially untrustworthy / un-knowledgeable people involved.
07:16:19 <KipIngram> That's just not my typical environment.
07:17:18 <john_cephalopoda> Of course, if I am working with my Mandelbrot set viewer, nothing can go horribly wrong. But when my stuff is connected to the internet and/or I got users inputting stuff and/or I got several programmers on a project that might send malformed requests to my module, then having some kind of safeguard in place is very, very useful.
07:17:36 <KipIngram> Yes - definiteily two totally different environments.
07:18:07 <john_cephalopoda> Best case my program writes to an unused memory chunk or crashes, worst-case a robot decapitates a worker.
07:19:51 <john_cephalopoda> Well, I had two internships in the functional safety field and it has left me sensitive to that kind of issues.
07:19:56 <KipIngram> Yep.  I get it.
07:21:17 <KipIngram> A typical environment for me (back when I actually got to work in development groups) might have been "receive data packets from a neighbor in a mesh netowrk and forward them to another neighbor closer to the data collection truck."
07:22:27 <KipIngram> The incoming packet is coming from the same bit of code running on the downstream node.  So even though many units are involved, it's still pretty much completely self-contained code.
07:23:15 <KipIngram> Packets are coming at a steady, fixed rate, so I have a window of time to get all of the necessary work done in - real time constraints.
07:23:27 <KipIngram> And obviously we want the code as efficient as possible to minimize battery drain.
07:23:51 <KipIngram> Also, my own unit is acquiring packets that it occasionally drops into the chain.
07:24:17 <KipIngram> This was seismic data, btw.
07:24:47 <KipIngram> We used 5.2 GHz wireless to do the mesh network.  It was sort of our "claim to fame" - no cables between the acquisition units.
07:25:17 <KipIngram> https://wirelessseismic.com/
07:25:29 <KipIngram> That little box on the right in the top picture is the one I was responsible for.
07:25:58 <KipIngram> Wow - I haven't looked at that in a while - that RT3 unit looks pretty cool.
07:26:11 <KipIngram> Quarter million sensors - that's way beyond what we were attempting when I was there.
07:26:48 <KipIngram> I keep hoping for a "happy phone call" from those guys - I own a little slice of the place.  The whole business plan was to gain market share and get acquired.
07:27:55 <KipIngram> Looks like they've built the geophone into the unit now - with the RT2 it was separate and connected to the recording unit with a little cable.
07:32:22 --- join: proteusguy (~proteus-g@2001:44c8:42c3:8148:dc5a:a7e4:98a6:4840) joined #forth
07:32:22 --- mode: ChanServ set +v proteusguy
07:35:04 --- quit: FatalNIX (Changing host)
07:35:04 --- join: FatalNIX (~FatalNIX@unaffiliated/fatalnix) joined #forth
07:35:15 <john_cephalopoda> Looks like a cool project.
07:37:20 <KipIngram> It was pretty fun.  The most fun elements, though, aren't "visible."  We used 24-bit A/D conversion, so the noise floor had to be INSANELY low - there's some really kick-ass analog circuit design in those babies.  I snitched a guy I'd worked with at a prior company to do that.  He's one of those old guys that is just sort of a wizard with analog.
07:37:54 <KipIngram> And each unit has a voltage controlled oscillator for its clock - the communication protocol allowed them to sync with one another and adjust their clock rates for phase lock.
07:38:17 <KipIngram> So you might have 10k of them spread out all over the landscape, but they're effectively working as one circuit - *exactly* the same clock rate, etc.
07:38:31 <KipIngram> That bit I was able to get more into than the analog stuff, and it was FUN.
07:39:51 <john_cephalopoda> In my internships I only did some simple programming (in C).
07:40:08 <KipIngram> WilhelmVonWeiner: I could see doing map without a factored function if there was a word to indicate the end of the map code.
07:40:13 <KipIngram> Something kind of like 
07:40:25 <KipIngram> <parameters> map ...code... end_map ...
07:40:39 <KipIngram> map and end_map could compile that into a loop.
07:41:08 <KipIngram> That's a step toward your "anonymity."
07:41:46 <KipIngram> Or map{ and }
07:42:52 --- quit: proteusguy (Ping timeout: 264 seconds)
07:42:56 <KipIngram> } could be used to close out any sort of "block"; the word that opened the block (map{ or reduce{ or foo{ or bar{) would leave a compile-time code on the stack; } could use it to know exactly what to compile.
07:46:16 <KipIngram> I suppose it would be possible for the array parameter to have nothing in it to iterate on, so map{ would need to be able to jump over the whole thing.  So it would compile similar to a while .. repeat loop.
07:49:05 <john_cephalopoda> Hmm, I feel like inventing a new, minimal Forth and a set of extensions.
07:52:17 <KipIngram> :-)
07:52:20 <KipIngram> Go for it.
07:52:40 <KipIngram> Tell us what you're doing - I love hearing about other people's Forths.
07:53:37 <KipIngram> So that map{ } I just described strikes me mostly as just wrappering the looping contruct.  There's an obviously iterable item on the stack, so it just "knows what to do."
07:54:22 <KipIngram> I haven't really used map and reducein Python, but I do a lot of "for item in items:" loops.
07:54:55 <KipIngram> I always like it when that will work - seems more readable than "for i in range(len(items)):"
07:55:44 <john_cephalopoda> Oh, yeah, that is also very useful in bash. "for i in *; do something with $i...; done"
07:55:53 <KipIngram> Yes.
07:56:16 <john_cephalopoda> Iterating over sets prevents quite some off-by-one errors.
07:56:41 <KipIngram> Yes.
07:59:29 <Zarutian> like they say there are two hard problems in compsci: naming things, cache invaldiation and off-by-one errors.
07:59:42 <KipIngram> :-)
07:59:44 <john_cephalopoda> :D
07:59:50 <Zarutian> Off-by-one errors Dave of EEVblog calls Obiwan Errors
08:01:42 <KipIngram> May the Forth be with you.
08:02:48 <john_cephalopoda> It's pronounced "force"... you are LISPing.
08:02:59 <KipIngram> lmao
08:03:03 <KipIngram> Indeed.
08:07:27 --- join: proteusguy (~proteus-g@cm-134-196-84-56.revip18.asianet.co.th) joined #forth
08:07:27 --- mode: ChanServ set +v proteusguy
08:12:03 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #forth
08:12:55 <SopaXorzTaker> I'm considering writing my own OS kernel that would execute the applications (including device drivers) in a virtual machine for a primitive, Forth-like stack-based language.
08:17:27 <KipIngram> Hi SopaXorzTaker.
08:18:24 <john_cephalopoda> Hey SopaXorzTaker 
08:18:34 <john_cephalopoda> I am thinking about somethingn similar :þ
08:18:46 --- quit: proteusguy (Quit: Leaving)
08:19:00 --- join: proteusguy (~proteus-g@cm-134-196-84-56.revip18.asianet.co.th) joined #forth
08:19:00 --- mode: ChanServ set +v proteusguy
08:19:26 --- quit: proteusguy (Remote host closed the connection)
08:19:44 --- join: proteusguy (~proteus-g@cm-134-196-84-56.revip18.asianet.co.th) joined #forth
08:19:44 --- mode: ChanServ set +v proteusguy
08:29:16 <john_cephalopoda> SopaXorzTaker: Have you got any more information on your project or is it still in its starting phase?
08:29:53 <SopaXorzTaker> john_cephalopoda, not even starting yet
08:30:03 <SopaXorzTaker> just thinking about how esoteric that's going to be
08:30:39 <john_cephalopoda> I don't think very.
08:31:16 <john_cephalopoda> Forth has been run on computers in low-level contexts for a long time.
08:32:04 <SopaXorzTaker> Feb 30, -0, -128:127:64 // A strong solar flare has caused faults in computer systems all around Earth
09:05:56 --- join: tabemann (~androirc@2600:380:c46a:3cdc:f8ef:6345:be20:5630) joined #forth
09:08:38 <tabemann> does anyone know how to implement an asynchronous software timer interrupt, if it is even possible, under Linux?
09:26:06 --- quit: dddddd (Remote host closed the connection)
09:42:33 --- quit: tabemann (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
10:12:44 <john_cephalopoda> Hmm....
10:13:11 <john_cephalopoda> UTF-8 support in Forth isn't trivial.
10:15:53 <john_cephalopoda> Considering 32-bit cells, one cell could fit exactly one UTF-8 max-size character.
10:17:22 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
10:17:26 --- quit: Zarutian (Read error: Connection reset by peer)
10:17:47 --- nick: Zarutian_2 -> Zarutian
10:49:10 --- quit: pierpal (Ping timeout: 252 seconds)
11:04:37 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
11:14:32 <WilhelmVonWeiner> Look up how gforth does it. It's not *that* bad
11:16:44 <Zarutian> utf-8 is surprisingly well designed. You can do byte indexing into a string and then look forward or backward to find where a codepoint starts/ends
11:17:57 <WilhelmVonWeiner> you know the history behind it? doc.cat-v.org/bell_labs/utf-8_history
11:19:20 <WilhelmVonWeiner> weird, cat-v is down? https://web.archive.org/web/20180928001931/doc.cat-v.org/bell_labs/utf-8_history
11:56:29 --- quit: SopaXorzTaker (Quit: Leaving)
12:09:35 <KipIngram> Zarutian: That's a good feature.
12:09:45 <KipIngram> I'm glad they made it like that.
13:07:05 --- join: inode (~inode@unaffiliated/inode) joined #forth
13:23:47 --- quit: pierpal (Ping timeout: 250 seconds)
13:55:20 <DKordic> Zarutian: But Code Point indexing of UTF-8 would still be linear?  
14:12:36 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
14:21:23 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
14:25:35 --- quit: jedb (K-Lined)
14:47:51 --- join: dave0 (~dave@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
14:48:31 <dave0> hi
15:05:35 <WilhelmVonWeiner> hey dave.
15:08:54 <dave0> hi WilhelmVonWeiner 
15:09:01 <dave0> sup?
15:10:13 <WilhelmVonWeiner> Just got back from some quality time with my SO and new mattress
15:10:37 <WilhelmVonWeiner> to completely forget why I was writing some natural logarithm algorithms 
15:10:59 <WilhelmVonWeiner> Implementing a neural network neuron in Forth
15:13:07 <dave0> brb my friend is here
15:18:24 <dave0> back
15:22:58 --- join: smokeink (~smokeink@118.131.144.142) joined #forth
15:35:50 <john_cephalopoda> Hmm, all in all ANS Core isn't bad. It has a lot of useful functions.
15:45:46 --- quit: nighty- (Quit: Disappears in a puff of smoke)
15:50:53 --- quit: pierpal (Ping timeout: 244 seconds)
15:54:10 --- quit: john_cephalopoda (Quit: Trees can see into your soul.)
15:54:31 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
16:06:42 --- quit: dys (Ping timeout: 272 seconds)
16:08:12 --- quit: pierpal (Read error: Connection reset by peer)
16:13:53 --- quit: smokeink (Remote host closed the connection)
16:14:31 --- join: smokeink (~smokeink@42-200-189-163.static.imsbiz.com) joined #forth
16:33:44 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
16:35:52 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
16:37:49 <pointfree> take2, sixel graphics with uncompressed framebuffer  http://ix.io/1rBr ( much faster than pixel by pixel)
16:39:56 <pointfree> I'd probably use the sixel rle compression when printing over the slow uart.
16:42:33 --- quit: nighty- (Max SendQ exceeded)
16:43:03 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth
16:50:32 <pointfree> ...and for animation, just capture and print the differences between the two consecutive frames on top of the old frame.
17:01:50 <WilhelmVonWeiner> so you `type` the whole image?
17:02:38 <pointfree> Yeah
17:03:12 <WilhelmVonWeiner> That's what I changed some farbfeld code to, too. writing to stdout with type
17:04:10 <WilhelmVonWeiner> one question about code style: Was this all indented neatly before i curl'd it from ix.io
17:04:53 <KipIngram> So, I saw a Numberphile video last night that presented an equation that produced all possible rectangular pixel grids, somewhere along the y axis.
17:05:11 <KipIngram> They found the y axis coordinate where the equation printed itself.
17:05:38 <KipIngram> Also found the one where it printed the Numberphile logo.
17:06:06 <pointfree> WilhelmVonWeiner: This is my formatting style for forth code http://www.0xff.in/2016/07/formatting-forth-to-help-you-factor/
17:06:22 <KipIngram> Of course, these y coordinates were HUGE numbers.  Really what it was doing was printing the y coordinate binary representation in column order form.
17:06:41 <KipIngram> I think it was 110 wide by 17 tall.
17:07:01 <WilhelmVonWeiner> pointfree: thanks. cursory glance says I agree
17:07:11 <KipIngram> So essentially you drew the pixel map you were interested in, read it off as a binary number msb in the bottom left, lsb in the top right, by columns, and multiplied by 17.
17:07:31 <WilhelmVonWeiner> just I indent after a `: WORD ` to separate the definition
17:07:56 <KipIngram> pointfree: I like it a lot.
17:07:59 <KipIngram> Very similar to my own.
17:21:35 --- quit: pierpal (Read error: Connection reset by peer)
17:34:04 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
17:34:07 --- join: jedb (jedb@gateway/vpn/mullvad/x-tijhtaxrukgnnvye) joined #forth
17:43:43 --- join: NB0X-Matt-CA (~nonlinear@unaffiliated/discrttm) joined #forth
18:01:28 --- quit: pierpal (Read error: Connection reset by peer)
18:01:39 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
18:08:22 <smokeink> how to prove this?? http://elganzua124.github.io/taocp/OEBPS/Images/ch01/e025_01.png     I arrived to this and got stuck: xn^n<=(x+n)^n-n^n
18:10:00 --- quit: pierpal (Ping timeout: 245 seconds)
18:11:36 <smokeink> don't know how to prove it
18:12:27 * smokeink wrong channel lol
18:35:17 --- quit: dddddd (Remote host closed the connection)
18:46:30 <KipIngram> How did you start your proof, smokeink?
18:46:39 <KipIngram> Oh, oops.
18:46:44 <KipIngram> I'm still interested...
18:46:58 <smokeink> :)
18:46:59 <KipIngram> I think I'd start with a Taylor series expansion.
18:48:40 <smokeink> I tried a naive approach, moved the 1 to the right then rised both sides to the nth power and got this xn^n<=(x+n)^n-n^n which almost seems obvious intuitively but I haven't figured out how to clearly prove it
18:49:22 <KipIngram> Right, I was just thinking about that method about about to try it.
19:02:33 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
19:05:42 <KipIngram> smokeink: You can do what you did, or something close to it to get this:
19:05:42 --- quit: pierpal (Read error: Connection reset by peer)
19:05:55 --- join: pierpal (~pierpal@host192-32-dynamic.1-87-r.retail.telecomitalia.it) joined #forth
19:06:00 <KipIngram> 1+x <= (1+x/n)^n
19:06:27 <KipIngram> Now if you imagine multiplying out the thing on the right, the first term is 1^n = 1, which cancels the 1 on the left.
19:07:00 <KipIngram> Sp x <= (1+x/n)^n - 1
19:07:11 <KipIngram> The -1 just matches up with the first term of the expansion.
19:07:23 <smokeink> right
19:07:38 <smokeink> did that too :) and then??
19:08:16 <KipIngram> The second term is (n,1)*x where (n,1) is the binomial expression factor.  Usually written vertically, with parentheses and n on top and k below.
19:08:44 <smokeink> yeah
19:09:11 <KipIngram> Doesn't that expansion just have n*<var> as the second term?
19:09:20 <KipIngram> In this case it would n*(x/n) = x?
19:09:34 <KipIngram> If so you're done - that cancels the x and you still have a bunch more terms left to go.
19:09:36 <smokeink> right
19:09:42 <smokeink> thank you very much
19:09:48 <KipIngram> So you have 0 <= <all terms of expansion other than the first 2>
19:09:55 <KipIngram> Sure no problem.  :-)  Fun stuff.
19:09:57 <smokeink> :)
19:23:20 --- quit: dave0 (Quit: dave's not here)
20:17:57 --- join: rdrop-exit (~markwilli@112.201.162.180) joined #forth
20:18:17 <rdrop-exit> Good afternoon Forthwrights :-)
20:35:25 <smokeink> good afternoon
20:43:29 --- nick: tabemann_ -> tabemann
20:47:50 <tabemann> hey guys
20:48:57 <tabemann> I wish there were a way to do a software timer interrupt in Linux, so I did not have to do an execution countdown for each word executed, which is really expensive, in order to implement preemptive multitasking
20:51:06 <tabemann> currently all words are executed in a while(task->countdown--){(*task->ip)->code()} loop
20:51:57 <tabemann> which means that for every word executed there is an extra conditional branch, decrement, and compare with zero
20:55:00 <rdrop-exit> Huh? Unix-like OSes are already preemptive
21:24:33 --- join: dave0 (~dave@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
21:25:30 <dave0> re
21:50:21 --- quit: ncv (Remote host closed the connection)
21:51:43 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth
22:12:06 <ttmrichter> tabemann: You mean like alarm() and signal()?
22:34:03 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #forth
22:52:26 <SopaXorzTaker> WilhelmVonWeiner, what's cat-v.org?
23:01:49 --- quit: pierpal (Read error: Connection reset by peer)
23:59:17 --- quit: proteusguy (Ping timeout: 268 seconds)
23:59:59 --- log: ended forth/18.11.11