World: r4wp
[!REBOL3] General discussion about REBOL 3
older newer | first last |
BrianH 16-Jan-2013 [571] | The /options refinements was one of the proposals for standard function options; /into was another such proposal. You'd have to look in R3 chat for details. |
GrahamC 16-Jan-2013 [572] | read/lines passes thru .. so I'm not sure what you're saving but not allowing /args |
BrianH 16-Jan-2013 [573] | Looked in chat #1097 (the area where standard options were discussed) and we haven't brought it up there yet, but Carl did a blog about it. |
GrahamC 16-Jan-2013 [574] | uRL? |
BrianH 16-Jan-2013 [575x2] | No idea, I just remember him doing so. |
The main subject of the initial /options proposal was MOLD, to replace all of the MOLD-related system/options settings. | |
Chris 16-Jan-2013 [577] | Still haven't found it -- just another point where you were waiting on changes : ) http://www.rebol.org/aga-display-posts.r?post=r3wp771x2326 |
Gregg 16-Jan-2013 [578] | World going offline for a while. |
Andreas 16-Jan-2013 [579x3] | Retrofitting QUERY would be another alternative to READ/custom. |
Change the signature of query to always include a mode field: QUERY target mode, then you could "default" read actions with READ, read actions with options with QUERY and the options as second parameter, write actions with options with WRITE. | |
I'd prefer using QUERY that way over READ/custom (or better, READ/args), which in turn I'd prefer over (ab)using WRITE. | |
GrahamC 16-Jan-2013 [582x2] | When did this behaviour of rejoin change? >> type? rejoin [ http:// "www.rebol.com" ] == url! >> rejoin [ now/date ] == "17-Jan-2013" |
It's behaving like ajoin for dates | |
GrahamC 17-Jan-2013 [584x6] | oh .. perhaps it never worked like that for dates |
Adrian, when make prep is run, prot-http.r is copied to host-init.r | |
tools/make-host-init.r is where the prot-http.r is included as well as all the others that are included into the binary | |
so looks like we can include our own protocols here | |
Ok, altering make-host-init.r to add schemes does add them to host-init.r but doesn't make the schemes available. I guess they must be initialised somewhere else. | |
Everything seems to end up in boot-code.r | |
AdrianS 17-Jan-2013 [590] | why is host-init.r checked in though, if it's generated? |
GrahamC 17-Jan-2013 [591x4] | mezz/boot-files.r ... add protocols here and they get included into the binary. I managed to add a new scheme to the binary this way |
So, looks like they have to be added in two separate files | |
Adrian, I would guess the directory was just uploaded to git | |
Aren't there also other autogenerated files on git | |
Ladislav 17-Jan-2013 [595x2] | https://groups.google.com/forum/?fromgroups#!topic/Rebol/-s8WtukYj1E You can also discuss here if you prefer, I posted it to GG in hope that even Carl might be able to see or discuss it there... |
No interest to discuss 'Molding decimal numbers "precisely enough"'? | |
Robert 17-Jan-2013 [597x2] | We just did a codecoverage check with R3 using the test-suite. |
So, Andreas and I tipped a priori. So, what's your tip? | |
Ladislav 17-Jan-2013 [599] | What is a "codecoverage check"? |
Andreas 17-Jan-2013 [600x2] | (Just pure line coverage.) |
The number of lines in the R3 C sources which are executed at least once while running the test suite. | |
Ladislav 17-Jan-2013 [602x2] | aha, interesting |
my estimate: 60% | |
Robert 17-Jan-2013 [604] | I did expect that you like this Lad. Which give a good hint, what kind of test-cases are missing. |
Ladislav 17-Jan-2013 [605] | What were your estimates? |
Andreas 17-Jan-2013 [606] | I estimated 20% (based on a perceiving the C sources to contain a high percentage of unused code). |
Robert 17-Jan-2013 [607x2] | my estimate: 40% |
Anyone else before we resolve? | |
Ladislav 17-Jan-2013 [609] | I seem to be overly optimistic, but what the heck... |
BrianH 17-Jan-2013 [610x3] | Ladislav, a statement you made in that Google Groups topic contradicts most of what you have said on the topic on other occasions: On the other hand, nobody doubts that the string "0.1" should suffice to represent the Rebol decimal! 0.1: That is the problem. The value 0.1 can't be precisely represented as an IEEE754 64bit floating point value, it can only be approximated. When "nobody doubts" that it can, they are wrong. MOLD not displaying the value with sufficient precision to show the actual value is the only thing that lets MOLD output a 0.1 at all. When MOLD just uses 15 digits, it outputs "0.1", which may be what you entered, but not what is in memory. What is in memory is 0.10000000000000001, so if you have MOLD autoexpand the number of digits it uses then MOLD 0.1 will output "0.10000000000000001". |
The limit on the number of digits of precision output by MOLD is what lets us pretend that 0.1 is exactly representable in Rebol. $0.1 is exact, but 0.1 is approximate. | |
You already got MOLD/all changed to be this "precise enough" MOLD. Why are you trying to push this change into MOLD without /all? | |
Ladislav 17-Jan-2013 [613] | The value 0.1 can't be precisely represented as an IEEE754 64bit floating point value, it can only be approximated. - yes, correct! However, if you write 0.1 in Rebol, the interpreter (the LOAD function, usually) "understands" it somehow. What I said is that nobody doubts that the string "0.1" can "accurately enough represent the (above mentioned) Rebol value", not that the "Rebol value accurately enough represents the string" (I did not even define what that means). 'When MOLD just uses 15 digits, it outputs "0.1", which may be what you entered, but not what is in memory. What is in memory is 0.10000000000000001, so if you have MOLD autoexpand the number of digits it uses then MOLD 0.1 will output "0.10000000000000001".' - actually, the number "in memory" (it does not matter where the number is, in fact, what matters is just that it is the IEEE-754 64-bit binary floating point number representing "0.1" in accordance with the IEEE-754) is 0.1000000000000000055511151231257827021181583404541015625 in fact. |
BrianH 17-Jan-2013 [614] | So why do you keep saying that 17 digits are sufficient to represent any 64bit floating pouint number? |
Ladislav 17-Jan-2013 [615x2] | 17 digits are sufficient does not mean the same as "17 digits are always necessary". |
Sometimes much less digits suffice. | |
BrianH 17-Jan-2013 [617] | 17 digits aren't sufficient to represent the difference between 0.10000000000000001 and 0.1000000000000000055511151231257827021181583404541015625, so if you say that the real IEEE754 value is 0.1000000000000000055511151231257827021181583404541015625 then you can't show that difference in 17 digits. |
Ladislav 17-Jan-2013 [618x3] | You are ignoring the definitions: 1) there is the IEEE 754 "definition" specifying which number corresponds to 0.1 - I know (using my Rebol script), that it actually is the number 0.1000000000000000055511151231257827021181583404541015625 2) there is my definition specifying which strings "accurately enough" represents the IEEE 754 number 0.1000000000000000055511151231257827021181583404541015625. According to my definition (you can find it defined as a Rebol function in the ML) all of "0.1", "0.10000000000000001" and "0.1000000000000000055511151231257827021181583404541015625" "accurately enough" represent the number. |
This means that any of the three strings can be used as a MOLD result that would be considered "accurate enough" by me. | |
I hope that answers your questions. | |
older newer | first last |