00:00:00 --- log: started retro/06.09.23
00:15:06 --- join: Cheery (n=Cheery@a81-197-19-23.elisa-laajakaista.fi) joined #retro
02:24:33 --- join: thinfu (n=wunderwa@bespin.org) joined #retro
02:26:27 <thinfu> crc: i'm thinking of getting the multisite special at site5.com for 2 years, and if i do, i can give you your own account which would support unlimited sites.. and let you have it for 2 years
03:02:10 <thinfu> nevermind, read a bunch of bad reviews of site5, they used to be good but not anymore i guess :(
05:05:17 --- quit: timlarson ("Leaving")
05:05:59 --- join: timlarson (n=timlarso@user-12l325b.cable.mindspring.com) joined #retro
08:19:33 <Cheery> http://retroforth.net/paste/?id=184
08:19:49 <Cheery> Quartus: that kind of stuff I made for floats. :PP
08:21:55 <Cheery> It doesn't turn back to fractions because I think I'd require unificator or other smart trick for it.
08:22:23 <Cheery> kind of, you are allowed to sum and divide fractions to get further fractions.
08:23:17 <Cheery> or I'm not sure if it works. :/
08:23:53 <Cheery> but anyway you can make those fractions yourself so easily that I do see it as a hard task to make something which converts them back.
08:40:03 <crc> good morning
08:41:49 <Cheery> morning crc. :)
08:52:47 <Cheery> 1 1/2 0 0 seems working. ^^
08:55:21 <Quartus> That's along the lines of what I was suggesting; something to get you off the ground in lieu of a full ASCII<>float conversion.
08:57:27 <Cheery> Quartus: somehow fractions seems being almost better for floating points than that usual real number -form.
08:59:17 <Cheery> 1/3, for example seems more preferable than 1.f/3.f or 0.33333333f
09:03:24 <Quartus> You could also algorithmically derive those fractional values, so you'd be able to say     3 8 fraction 3/8
09:43:19 <Quartus> The notation in Standard Forth, btw, is      1e 3e f/  or  0.333333e
09:46:42 <Quartus> Looking over your code -- 1/4 should be %01000000000000000000000000000000 constant 1/4
09:47:40 <Quartus> also   %00100000000000000000000000000000 constant 1/8
09:48:18 <Quartus> %01100000000000000000000000000000 constant 3/8
09:48:54 <Cheery> oh yeah ^^
09:48:56 <Cheery> sorry.
09:49:23 <Quartus> Your routines don't seem to accept 0, for instance     0 1/3 float    returns 0.5.
09:49:56 <Cheery> that is the problem why I put the fraction in.
09:50:11 <Cheery> because writing 0 1/3 would be simpler that way as well.
09:50:23 <Quartus> Sure. But your word 'float' doesn't properly convert 0 1/3 to 0.333333
09:51:32 <Cheery> of course not, and I intended it doesn't.
09:51:39 <Quartus> ...?
09:52:39 <Quartus> 1 1/3 -> 1.333333     2 1/3 -> 2.333333       so why not     0 1/3 -> 0.333333 ?
09:52:50 <Cheery> the part of zeros is an kind of exception case in floating point format.
09:53:09 <Quartus> Yeah, sure, for 0e.  Not for 0.333333
09:53:57 <Cheery> for 0.333333 as well, because you must 'slide' the mantissa to the negative exponent.
09:54:06 <Cheery> and switch the exponent that way.
09:54:40 <Quartus> Which your 'float' doesn't do for 0 1/3 (or 0 and any other fraction).
09:54:53 <Cheery> yes! :)
09:54:57 <Quartus> It should.
09:55:26 <Cheery> hmm. true, but I wanted to get it working at least little before doing further neat things for it.
09:55:42 <Cheery> I agree it's lame. ;)
09:56:20 <Quartus> I also had trouble following some of the code because you used the 1/2 constant as a general-purpose high-bit for setting the sign of the float.
09:57:16 --- quit: virl ("Verlassend")
09:57:27 <Cheery> the same reason.
09:57:53 <Quartus> Again: ...?   Same reason as what?  You're using a constant that is named 1/2 when it should be named 'high-bit'.
09:58:13 <Quartus> Here's my Gforth translation of the code so far: http://retroforth.net/paste/?id=185
09:58:50 <Quartus> You can test this with           3 3/8 float sp@ sf@ f. -> 3.375
09:59:53 <Cheery> there is one high-bit you missed in required-size -function.
10:00:02 <Quartus> Ok.
10:03:52 <Cheery> Quartus: do you think I should continue striving for the real numbers by writing different method for handling mantissa or continue this further a bit?
10:04:26 <Quartus> All this code is obviated by a real float<->ascii conversion.  Then 1/3 becomes 1e 3e f/ fconstant 1/3
10:05:45 <Quartus> If you wanted the same syntax, it'd be     : 1/3    s>d d>f 1e 3e f/ f+ ;    (presumably set up by a suitable defining word)
10:06:00 <Cheery> yeh, unless I'm doing a nice little extension into the >forth to handle also style: 1/3e :)
10:06:34 <Quartus> I don't see the need for that; 1e 3e f/ isn't exactly verbose.
10:07:48 <Cheery> hmm.
10:08:08 <Quartus> If you find you're using a given fraction a great deal, you could also do        1e 3e f/ fconstant 1/3e
10:09:21 <Quartus> Doing the full conversion routines means you can easily work with both single and double IEEE floats, or some other format, if you wish.
10:09:30 <Quartus> The way you're proceeding means you're stuck in IEEE singles.
10:13:23 <Cheery> yeh.
10:13:39 <Cheery> But I'd need to find the way to handle negative exponents.
10:13:56 <Quartus> Yes, you need to handle exponents both positive and negative.
10:14:40 <Cheery> positive exponents are kind of simple...
10:16:31 <Quartus> Float>ascii is quite simple, with either direction of exponent.  Ascii>float is also not too tough, you're either repeatedly multiplying or dividing by 10.  You can speed that up with a table.
10:18:13 <Quartus> For float>ascii you need to handle a handful of special cases (-/+0, NaN, Inf, etc.), bit-shift the mantissa in the direction of the exponent, and display the resulting two (possibly quite large) integers on opposite sides of a '.'.
10:21:40 <Quartus> For that method, you'd need a buffer twice the size of the max exponent.  So 32 bytes for a single float.
10:25:13 <Cheery> hmm.
10:25:32 <Cheery> what do you mean about bit-shifting the mantissa?
10:26:45 <Quartus> I mean left-align the mantissa in the fraction part of that buffer, put the implicit leading 1-bit in the integer part of the buffer, and then shift left unbiased-exponent times if the unbiased exponent is positive, right if it's negative.
10:27:30 <Quartus> The exponent in an IEEE float is a power-of-two exponent, so bit-shifting is all you need.
10:32:40 <Cheery> jargon overflow. :/ 
10:33:18 <Quartus> What's the binary mantissa of 12.25?
10:35:25 <Cheery> 10001
10:35:42 <Quartus> And the exponent?
10:35:46 <Cheery> 3
10:35:58 <Quartus> But it's not stored that way in the float.  It's biased.
10:36:08 <Cheery> thus, one must add that extra 1 bit to get the real mantissa: 110001
10:36:13 <Cheery> yes.
10:36:35 <Cheery> biased by 127
10:36:37 <Quartus> Right. So the unbiased exponent is 3.  The mantissa is 10001 with an implied leading 1-bit.
10:37:00 <Quartus> So you set up a buffer.  We can do this particular example with a tiny buffer.
10:37:04 <Quartus> 00000 00000
10:37:13 <Quartus> That's integer fraction
10:37:22 <Quartus> So put the mantissa left-aligned in the fraction part.
10:37:28 <Quartus> 00000 10001
10:37:50 <Quartus> (that is to say, if the buffer were larger, it'd be -- for instance -- 0000000 1000100 )
10:37:59 <Quartus> Then put the implied leading 1-bit in the integer part.
10:38:05 <Quartus> 00001 10001
10:38:24 <Quartus> The exponent is 3, which is positive, so shift the whole buffer left 3 bits.
10:38:43 <Quartus> 01100 01000
10:39:49 <Cheery> now we have the 12 in the integer part.
10:40:10 <Quartus> And 8/32 in the fraction.
10:40:38 <Cheery> or 1/4
10:40:42 <Quartus> Right.
10:40:50 <Cheery> but I assume the 8/32 is important notice.
10:40:52 <Cheery> so continue.
10:41:05 <Quartus> Continue?  That's it.  That's 12.25.
10:42:22 <Cheery> oh yeah, I understand, but do you have a method to turn from 8/32 to .25?
10:42:33 <Quartus> I call it 'division'.
10:45:31 <Quartus> In this tiny example, 1000 8 32 */ would do the trick.
10:48:11 <Cheery> lets see. the biggest exponent is 127
10:50:30 <Quartus> In practice very few bit-shifts should be required, as you can determine the nearest byte boundary for the integer/fraction division and shift the remainder.
10:54:22 <Quartus> Of course this is only one method; there are less accurate methods that involve repeatedly dividing the float by 10 and taking the remainder.
10:56:07 --- quit: timlarson ("Leaving")
10:56:25 <Quartus> With this method, you can easily output scientific notation if you prefer it.
10:56:46 <Cheery> 12.5e1 ?
10:57:01 <Quartus> 1.225e1
10:58:41 <Quartus> With an IEEE single float, the largest fraction is 23 bits, as I recall, so you can do the conversions in very simple Forth.
10:58:52 <Quartus> largest mantissa, rather.
10:59:13 <Quartus> So the fractional conversion can be done to six or seven decimal places with */ and nothing else.
10:59:24 <Cheery> (20:21:18) Quartus: For that method, you'd need a buffer twice the size of the max exponent.
10:59:31 <Quartus> That's what I said.
11:01:04 <Quartus> What's the confusion?
11:01:14 <Cheery> so I'd need a buffer twice the size of 127 bits?
11:01:26 <Quartus> Right.  So 254 bits, or 32 bytes.
11:01:37 <Quartus> As I said.
11:02:12 <Quartus> Though in practice you don't need one that large, because you can find the nearest byte boundary and shift relative to that, as I also said :)
11:02:59 <Cheery> and low side of that cell is a fraction and high side of that cell is a integer.
11:03:14 <Cheery> :)
11:03:22 <Cheery> But propably easier this way.
11:03:22 <Quartus> You have to set your goals first.  Is it sufficient to display in scientific notation?  How many digits of precision do you want or need?
11:03:37 <Quartus> cell?
11:03:50 <Cheery> or a doubleword
11:03:56 <Cheery> cell is what retroforth uses.
11:04:21 <Quartus> Cell is what Forth uses.  I'm not asking you to define the word, I mean what are you thinking, that 32 bits is enough?
11:06:35 <Cheery> the mantissa is only 23 bits. so I think it could be enough if I'd shift the exponent rather than the mantissa, then I would extract the both mantissa and fraction with simple methods.
11:07:04 <Quartus> Doesn't work.  But experiment with the method and see where it takes you.
11:09:40 <Quartus> You could bit-copy the appropriate parts of the denormalized mantissa into other buffers and do the bit-shifting there, but it's the same method.
11:12:36 --- join: timlarson (n=timlarso@user-12l325b.cable.mindspring.com) joined #retro
11:16:37 <Cheery> If I just had a bignum library... :)
11:18:13 <Quartus> Another way, though it strikes me as horribly clumsy, would be to convert the denormalized mantissa into decimal and repeatedly multiply or divide it by two accordingly.
11:18:56 <Cheery> It'd be easy to define just two 128bit numbers which are near another.
11:19:09 <Cheery> then left-align the mantissa there...
11:19:22 <thinfu> why do forthers keep reinventing the wheel instead of standing on the shoulders of those before them and pioneering new ground?
11:21:10 <Quartus> RetroForthers do it because rf doesn't have certain capabilities yet. :)
11:25:39 <thinfu> what capabilities are those
11:25:47 <Quartus> Floating-point.
11:25:49 <Quartus> For example.
11:26:14 <thinfu> why is floating-point important?
11:26:38 <thinfu> i don't find ansi or floating-point making much of a difference in coding
11:26:44 <Quartus> Cheery needs it in order to interface with a specific graphics library.
11:26:44 <thinfu> probably string handling is more important than either of those
11:27:09 <thinfu> hmm
11:28:34 <thinfu> how many lines to implement the floating point required for that library?
11:28:36 <thinfu> 8 lines?
11:29:19 <Quartus> If you want to be able to interactively enter and display floating-point numbers, you'd be hard pressed to do it in 8 lines.
11:29:50 <Quartus> 8 very, very long lines, maybe. :)
11:29:57 <Cheery> :D
11:30:24 <thinfu> ok 16 then, a block..
11:30:44 <thinfu> hmmm
11:30:57 <Cheery> yeh, I believe the solution is simple, I just don't know it yet.
11:31:13 <Cheery> or 'know' it. :)
11:31:18 <thinfu> always trivialize the problem until the ocde is ridiculously simple ;P
11:31:26 <Quartus> thinfu, I have seen a few libraries for the conversion between floating-point and ascii; they've all been somewhat longer than that, but it's not a huge undertaking.  It's important to do it carefully, as there are pitfalls.
11:32:09 <thinfu> so the floating point gets passed to the library in ascii format?
11:32:26 <Quartus> No.  Input and diplay in ascii are for the convenience of the programmer.
11:32:47 <thinfu> why not input it in a string?
11:32:56 <thinfu> s" 12.156e10"
11:33:05 <Quartus> The library wants native floats.  But whether it's in a string or not, it still needs converting.
11:34:32 <Cheery> GAAH! It'd be much simpler if people would use octals instead of decimals. >:E
11:34:42 <Cheery> hmm..
11:35:41 <Cheery> see.
11:35:57 <thinfu> shouldn't it take at most 8 lines of code to convert that string into floating? :P
11:36:12 <Cheery> multiply &1000 with &1000, comes &1000000
11:36:14 <Quartus> Just that string, or any number?
11:36:29 <thinfu> well any floatingpoint value in a string
11:36:38 <Quartus> If it's just that number you want, I can convert it here and give you a 32-bit constant.
11:36:53 <Quartus> thinfu, I would be quite astonished to see that done in 8 lines of code.  
11:37:07 <Cheery> multiply &1010 with &1010 and you get: 1100100
11:37:58 <Cheery> 1111101000
11:38:07 <Cheery> 10011100010000
11:38:15 <Cheery> 11000011010100000
11:38:38 <Quartus> Cheery, your 1 and 0 keys appear to be stuck. Did you spill a coke?
11:39:23 <Cheery> nah, 10base E2, E3, and E4
11:39:27 <Cheery> those are.
11:40:02 <Cheery> somewhat like that.
11:50:44 <Cheery> fuck humans!
11:50:50 <Cheery> I use octal >:)
11:52:08 <Cheery> notice: 1.100100 is: 1.44 in octals.
11:56:57 <Quartus> 1.9 in hex.
12:17:51 <thinfu> you mean 1.24 in hex?
12:18:12 <Quartus> Is it?  I wondered.  I didn't check. :)
12:19:01 <thinfu> ah, if you were being sarcastic to shut cheery up, then you should've picked a more improbable number ;P
12:19:16 <Quartus> No, no sarcasm or shutting-up intended.
12:19:18 <Quartus> Just an error.
12:20:26 <thinfu> ah, i thought you were telling him that with the comment about spilling a coke
12:20:55 <Quartus> I was trying to discourage him from typing ever-longer meaningless sequences of binary digits into the channel on that occasion, yes. :)
12:21:10 <thinfu> heh
12:23:31 <Cheery> :)
12:23:49 <Cheery> Hey! They were sequences of binary digits with a meaning. :)
12:24:02 <Quartus> Somehow the meaning was lost.  Must have been the coke.
12:27:21 <thinfu> lost in translation!
12:30:07 <Cheery> yes, this seems more logical sequence: #10 #100 #1000 #10000
12:30:08 <Cheery> ;)
12:44:55 <Cheery> btw. spilling cola to 1 and 0 would be a trick. :D
12:45:11 <Cheery> at least to one where there is no keypad.
12:45:19 <Cheery> or keypad off.
12:46:03 <Cheery> that'd require high physical coordination of liquids.
12:46:17 <Cheery> acrobatic.
12:46:20 <Quartus> I'm sure you're up to the challenge. :)
12:46:47 <Cheery> yeh, that's a circus trick.
12:47:08 <Cheery> 'come and see the super spiller!'
13:55:46 --- quit: Cheery ("Download Gaim: http://gaim.sourceforge.net/")
13:57:25 --- join: Quartus__ (n=Quartus_@209.167.5.1) joined #retro
14:57:40 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #retro
17:26:06 <nighty__> yop
17:35:10 <Quartus> Hi nighty.
22:32:19 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-185-032.pools.arcor-ip.net) joined #retro
22:49:48 --- quit: Snoopy42 (Read error: 110 (Connection timed out))
22:50:00 --- nick: snoopy_1711 -> Snoopy42
22:57:40 --- join: Cheery (n=Cheery@a81-197-19-23.elisa-laajakaista.fi) joined #retro
23:59:59 --- log: ended retro/06.09.23