00:00:00 --- log: started forth/16.07.15 00:05:44 --- quit: wa5qjh (Remote host closed the connection) 00:15:56 --- join: wa5qjh (~Thunderbi@121.54.58.157) joined #forth 00:56:47 --- quit: nal1 (Quit: WeeChat 1.4) 00:58:53 --- quit: nighty (Quit: Disappears in a puff of smoke) 00:59:37 --- join: nighty (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 01:10:59 --- quit: nighty (Quit: Disappears in a puff of smoke) 01:11:46 --- join: nighty (~nighty@d246113.ppp.asahi-net.or.jp) joined #forth 01:16:20 --- join: reepca (~user@184.52.15.40) joined #forth 01:16:44 --- quit: dram (Ping timeout: 260 seconds) 01:46:38 Question... why do most forths handle floating-point with a separate stack? If each float can be one cell, why not just use the standard data stack? 01:47:45 --- quit: nighty (Quit: Disappears in a puff of smoke) 01:49:48 --- join: proteusguy (~proteusgu@183.88.74.56) joined #forth 01:49:48 --- mode: ChanServ set +v proteusguy 02:05:30 reepca: sometimes the floating-point stack would actually reside in the FPU hardware 02:05:44 forcing it onto the parameter stack would sacrifice performance in this case 02:06:41 --- join: true-grue (~true-grue@176.14.216.104) joined #forth 02:19:29 --- quit: proteusguy (Ping timeout: 258 seconds) 02:29:13 --- join: proteusguy (~proteusgu@183.88.74.56) joined #forth 02:29:14 --- mode: ChanServ set +v proteusguy 02:44:10 dys: that makes sense, thanks. 02:45:18 --- quit: reepca (Read error: Connection reset by peer) 02:52:52 --- join: reepca (~user@184.52.15.40) joined #forth 02:57:39 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 02:59:40 --- join: timeslice (~photon@1.132.96.248) joined #forth 03:01:25 --- quit: wa5qjh (Ping timeout: 264 seconds) 03:34:01 --- join: wa5qjh (~Thunderbi@203.111.224.44) joined #forth 03:43:27 --- join: saml_ (~saml@cpe-24-102-97-97.nyc.res.rr.com) joined #forth 04:38:27 --- part: timeslice left #forth 05:33:44 --- join: impomatic_ (~digital_w@host31-52-247-186.range31-52.btcentralplus.com) joined #forth 05:51:13 --- quit: saml_ (Ping timeout: 264 seconds) 05:58:41 --- quit: nighty (Remote host closed the connection) 06:07:28 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:34:01 --- quit: nighty (Remote host closed the connection) 07:14:20 avoid FP if you possibly can!!! :-) 07:17:44 That's idiotic. 07:19:00 oh here we go 07:19:05 DGASAU: what's idiotic now? 07:19:16 Not using FPNs where you have them. 07:19:32 uh-huh 07:19:52 okay then 07:26:13 FP = floating point? 07:35:34 impomatic_: yeah 07:36:12 impomatic_: if the platform you're using has hardware floating point and you feel like moving around 32-bit values, it makes sense 07:37:56 impomatic_: for those of us who don't want a thumping great quad Opteron to power our car keys, floating-point isn't really as important 07:38:32 Floating point is sometimes appropriate, sometimes not. 07:39:06 impomatic_: tbh if I'm doing DSPish stuff on PC hardware I just use floating-point unless there's a compelling reason not to 07:39:51 since even really shitty ARM chips have got multiply-and-accumulate instructions it makes more sense just to use integers for signal processing on that 07:40:11 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 08:03:51 most applications have no need for floating point math. obviously if yours does then use it. I just said avoid it if you can. Too many idiots do money with floats and get what they deserve. 08:13:20 That most appications have no need for FPNs is a huge overstatement. 08:25:42 --- quit: nighty (Remote host closed the connection) 08:26:45 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 08:28:56 --- join: vsg1990 (~vsg1990@pool-173-64-14-42.bflony.fios.verizon.net) joined #forth 08:40:22 --- quit: DGASAU (Ping timeout: 252 seconds) 08:43:23 --- join: Uniju (~frog_styl@cpe-74-78-4-232.mass.res.rr.com) joined #forth 08:49:17 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 09:00:06 --- quit: DGASAU (Ping timeout: 250 seconds) 09:06:10 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 09:13:58 DGASAU, I've seen exactly 2 applications written in forth that "needed" floating point. Why are you just spouting unsupportable assertions. You're arguing points no one even made. No one said never use fp. Just to avoid it if you don't need it. If that isn't the epitome of forth, avoiding unneeded things, I don't know what is. 09:16:17 gordonjcp, ARM is not a pleasant environment for forth to be sure. I got no problem doing fp on a dsp of course. That's what they're there for and they can accept rounding errors without a problem. 09:30:55 much of it is probably cause everyone uses languages where floating point is just another type of variable 09:31:22 and so everyone uses it cause it's there, without thinking about how it's implemented 09:31:41 yep...kinda like regular expressions. There are those who, when faced with a problem say "I'll use floats to compute that!". Now they have two problems. :) 09:49:29 --- join: Indecipherable (~Howl@41.162.59.11) joined #forth 10:19:41 --- join: Keshl_ (~Purple@24.115.181.94.res-cmts.gld.ptd.net) joined #forth 10:19:41 --- quit: Keshl (Read error: Connection reset by peer) 10:43:27 --- nick: Keshl_ -> Keshl 10:55:16 proteusguy: I've mostly only done C and assembler on ARM so far, I was going to look into Forth on it 11:01:23 gordonjcp, well it's not much worse than x86 for forth but that's a low bar. It's just not a "forth friendly" processor. But there are plenty of ARM forths out there. 11:02:57 proteusguy: the 6809 is so ridiculously suitable for forth :-) 11:03:59 gordonjcp, definitely one of my favorite targets. 11:05:17 proteusguy: that's kind of why I picked Forth for reverse-engineering the Ensoniq Mirage hardware 11:06:12 I could have got a MIKBUG-like debugger in far less memory (I have, too, in the sequencer RAM, that can be called from the normal OS) but there's Dave Dunfield's rather idiosyncratic version just sitting right there... 11:11:40 proteusguy: The problem with Forth lovers is that they always interpret "if you don't need it" in their own way. 11:13:12 For instance, if I want to measure time and report average, it is a lot easier to use FPN than do it in a weird way with integers. 11:13:57 You are more likely to assert that "you don't need it" instead of just writing few lines of code to gather and report statistics. 11:15:19 floating-point isn't a wonderful way to measure time 11:16:20 That's not the reason to "avoid FPN" here. 11:16:27 well, it kind of is 11:16:32 No, it isn't. 11:16:37 You don't know the scale upfront. 11:16:42 for the same reason you wouldn't use floating-point to calculate currency 11:16:57 doesn't matter what the scale is 11:17:07 the fractional part cannot be accurate 11:17:24 It has nothing to do with fractional part. 11:18:05 if it's got nothing to do with the fractional part, why use floating point? 11:18:14 The problem is that either you just use FPN, or you use a lot wider integers to cover potential range. 11:19:07 a wider range of *correct* integers, or a narrower range of *incorrect* floating point values 11:19:23 --- quit: Keshl (Read error: Connection reset by peer) 11:19:34 --- join: Keshl (~Purple@24.115.181.94.res-cmts.gld.ptd.net) joined #forth 11:20:13 You need a wider range of integers just to get approximate answer. 11:20:18 o_O 11:20:26 do you know how floating-point works? 11:22:53 --- join: neceve (~neceve@unaffiliated/neceve) joined #forth 11:27:15 Yes, I do. 11:27:31 That's why I know why it is better to use FPN here. 11:28:50 kay 11:29:02 wait, better to use FPN where? 11:29:05 so, right, you know how floating-point cannot accurately reproduce all numbers? 11:29:09 vendan: for measuring time 11:30:15 vendan: for processing timings, for instance. 11:30:34 depends on where you are measuring it, and what kind of api you are getting them from 11:30:38 DGASAU: but you're okay with the idea that comparing two times might not be correct? 11:30:54 I'd prefer if there was a syscall or whatever that returned timings in ticks 11:31:01 What do you call "might not be correct?" 11:31:44 I mean, if you are saying for measuring benchmark times in a program or something like that 11:32:00 --- join: bedah (~bedah@dyndsl-095-033-216-084.ewe-ip-backbone.de) joined #forth 11:32:10 it's ticks down at the hardware level, and then something above may convert it into a float 11:32:14 and that's just wrong, imo 11:32:33 There's a choice: 11:32:40 either you do it with FPNs 11:32:53 or you need wider integers to do it. 11:33:32 DGASAU: can you represent all possible numbers with floats? 11:33:33 I would call bullshit on that 11:34:18 a float is just a number storage mechanism with variable epsilon based on distance from 0 11:34:47 DGASAU: okay, right, do you know how counting in decimal integers works? 11:34:57 like counting your fingers 11:35:43 hold up three fingers 11:35:43 unless you are specifically trading on "oh, this variable epsilon makes it so I can have these huge numbers and these small numbers" without caring about the fact that the huge numbers also have a huge epsilon 11:35:46 you can cound 3 11:35:47 *count 11:35:54 divide 3 by 2 11:36:13 how do you show me that by holding up fingers? 11:36:33 terrible accidents involving a trip to A&E and a shitload of HSE paperwork notwithstanding 11:36:51 cut off a half a finger? lol 11:37:09 no 11:37:15 because then that gives me a 11:37:23 *aaaallllll* the paperwork 11:37:33 but yeah, integers have an epsilon of 1, basically 11:38:05 the fundamental problem is that computers stuck 11:38:09 *suck 11:38:12 and reality sucks 11:38:25 measuring anything over a variable scale is hard 11:38:59 measuring tiny increments on large numbers is always going to be quite hard 11:39:29 well, realistically, adding bits makes a huge diff. 11:39:45 64 bits can store nanoseconds for 584 years 11:39:55 right 11:40:10 it's the difference between accuracy and precision 11:40:33 it's possible to weigh incredibly heavy things down to tiny fractions of a gramme 11:40:38 go to 128 bit and you could store picoseconds from the start of the universe 11:40:43 that's both accurate and precise 11:41:01 otoh I can say that my Landrover weighs about two tonnes 11:41:07 it's accurate, but it's not precise 11:41:19 the guy on the ferry is happy with that level of precision 11:42:27 I've got a forth on a really odd cpu platform, no fpu in sight 11:42:49 decided to just screw the idea of floating point, and wrote a quick little fixed point library 11:42:52 worked pretty well 11:43:07 I rarely use floating point anyway, on non-PC hardware 11:43:36 I've done DSP on a 16MHz AVR 11:44:35 64 bits is only about 18 decimal digits, that's the problem. 11:44:54 "only" 11:44:59 Yes. 11:45:02 there's only 8x8 unsigned multiply so it takes a bit of thinking about 11:45:40 DGASAU: ... that can't represent a number exactly unless it's an exponent of a power of two 11:46:29 and I guess there's "only" 38~39 in a 128 bit number, huh? 11:47:17 18 digits is pretty much on the fringe of relative precision in a number of common problems. 11:48:29 if you are going that far out with a float, you are pretty much shot as well... 11:59:13 --- quit: Indecipherable (Quit: http://i.imgur.com/rWAnqP3.jpg) 12:00:14 The problem with using integer numbers in such tasks is that you have to reserve quite large margins. 12:00:40 I mean, heck, did you know there is no 32bit float value between 12345678 12:00:41 and 12345679? 12:00:46 Basically, out of your 18 digits, you need to waste 6-8 or even 10 digits to accomodate for unpredictable range. 12:01:09 that's pretty shit range there 12:01:18 go further, and you get even larger gaps 12:01:21 The latter leaves you only 8-10 digits to operate. 12:02:02 So you can't even work with quantities in common difference of 5-6 decimal orders. 12:03:17 yeah, but float wastes a ton of range in between 0 and 1 12:10:25 if you actually run the numbers, pretty much 50% of a float's range from minimum value to maximum value is between -1 and 1 12:11:03 if you deal almost exclusively with numbers just from -1 to 1, sure, float is *GREAT* 12:11:16 start getting very far out of there, and it sucks 12:50:38 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 13:23:42 LoL, look at the quit message. 13:30:07 --- quit: vsg1990 (Quit: Leaving) 13:44:28 --- join: Mat4 (~claude@ip5b40bd37.dynamic.kabel-deutschland.de) joined #forth 13:48:36 --- quit: Inode (Quit: ) 14:24:06 --- quit: wa5qjh (Remote host closed the connection) 14:36:01 --- join: ASau (~user@netbsd/developers/asau) joined #forth 14:54:01 --- part: Mat4 left #forth 15:19:06 --- join: Jimadilo (~jim@109.246.9.46) joined #forth 15:29:41 --- quit: neceve (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 15:49:19 --- join: nal (~nal@adsl-64-237-237-103.prtc.net) joined #forth 15:54:49 --- quit: groovy2shoes (Remote host closed the connection) 16:07:30 --- join: karswell` (~user@131.105.115.87.dyn.plus.net) joined #forth 16:10:10 --- quit: karswell (Ping timeout: 276 seconds) 16:16:13 --- quit: bedah (Quit: Ex-Chat) 16:51:08 --- quit: karswell` (Ping timeout: 250 seconds) 16:53:20 --- quit: true-grue (Read error: Connection reset by peer) 16:55:04 --- join: karswell` (~user@131.105.115.87.dyn.plus.net) joined #forth 17:17:45 --- quit: karswell` (Ping timeout: 276 seconds) 18:05:55 --- join: dram (~Thunderbi@112.65.46.78) joined #forth 18:21:50 --- quit: Jimadilo (Quit: WeeChat 1.4) 20:36:14 --- join: Bahman (~Bahman@91.99.189.177) joined #forth 21:03:32 --- quit: Zarutian (Quit: Zarutian) 21:15:16 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 21:53:01 --- quit: dram (Ping timeout: 264 seconds) 21:56:19 --- quit: groovy2shoes (Remote host closed the connection) 21:56:40 --- join: groovy2shoes (~groovy2sh@unaffiliated/groovebot) joined #forth 22:33:55 --- quit: impomatic_ (Quit: http://corewar.co.uk) 22:42:55 --- quit: proteusguy (Ping timeout: 240 seconds) 23:27:16 --- join: dram (~Thunderbi@112.65.46.78) joined #forth 23:41:58 --- join: Bahman_ (~Bahman@91.98.190.222) joined #forth 23:44:32 --- quit: Bahman (Ping timeout: 240 seconds) 23:59:03 --- join: proteusguy (~proteusgu@183.88.32.182) joined #forth 23:59:04 --- mode: ChanServ set +v proteusguy 23:59:59 --- log: ended forth/16.07.15