• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

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.