World: r3wp

help round

'round still doesn't work with money though >> round/to to-money 
.125 .001  --> $0.12

Tim, it's probably better to not use money! when rounding.

The rounding may not be to exact cents -- money type only *displays* 
2 decimal points, though it *preserves* more:
   to-money .125
   == $0.13
   second to-money .125
   0.125

Also, I am not seeing the always-down effect you report.
   round/to $.125 .001
   == $0.13    ;; correctly rounded up


Round did go through a couple of development stages. Perhaps your 
version of REBOL has an outdated one. This is the source from the 
version I am using:

round: func [

    {Returns the nearest integer. Halves round up (away from zero) by 
    default
.}
    [catch]
    n [number! money! time!] "The value to round"
    /even "Halves round toward even results"

    /down {Round toward zero, ignoring discarded digits. (truncate)}
    /half-down "Halves round toward zero"
    /floor "Round in negative direction"
    /ceiling "Round in positive direction"
    /half-ceiling "Halves round in positive direction"
    /to "Return the nearest multiple of the scale parameter"
    scale [number! money! time!] "Must be a non-zero value"
    /local m
][
    throw-on-error [
        scale: abs any [scale 1]
        any [number? n scale: make n scale]
        make scale either any [even half-ceiling] [
            m: 0.5 * scale + n
            any [
                all [
                    m = m: m - mod m scale
                    even
                    positive? m - n
                    m - mod m scale + scale
                ]
                m
            ]
        ] [
            any [
                floor
                ceiling

                (ceiling: (found? half-down) xor negative? n down)
                n: add n scale * pick [-0.5 0.5] ceiling
            ]

            either ceiling [n + mod negate n scale] [n - mod n scale]
        ]
    ]
]

As a note: In R3, money! is of much greater precision (infinite?) 
and should round properly using conventional ROUND/TO (once bug #492 
is fixed, that is :-)).

infinite = 27 positions, IIRC ...

thanks, couldn't remember

Uck, this is unsightly:

	>> to-path [
	[    a
	[    b
	[    c
	[    ]
	==
	a/
	b/
	c

Why does it not result in:

	== a/b/c

The newline character is being detected so it is treating each as 
a separate statement.  I would think that isn't a bug but rather 
a feature.

Since the following works fine:

>> to-path [a b c]
== a/b/c

I think it's a bug in to-path.  Why would you possibly want to retain 
that behaviour?

I can understand silently storing newline settings between block 
sessions (I use 'new-line a little to control this behaviour), but 
what scenarios benefit from this when working with paths?

Consider this scenario:

	countries: [
		us "United States"
		fr "France"
		au "Australia"
		uk "United Kingdom"
	]

	foreach code extract countries 2 [
		probe form to-path compose to-block 'users/(code)
	]

I know how to work around it, just don't see the purpose.

chris, there is no purpose, it's just that internally path! = block!, 
so path! behaves exactly like block! does. it probably should strip 
newlines when converting though, or at least ignore them when molding... 
(that is, i'm saying this is a bug.)

perhaps it's a good idea to check on any char that does not belong 
in a path! R3 has a bug where it includes none! as part of a path.

Chris, you raised a good point when you said "Why would you possibly 
want to retain that behavior?".  We wouldn't - add it to RAMBO please.

Gab: just want to be sure, I know that one man's bug is another man's 
feature...

I'll RebIT to that!

sorry I didn't reply sooner.  The version of round I was using was 
on a linux box so it was the latest debian rebol release.  It does 
round up correctly on the windows version I have.

>> build-tag [input type checkbox value test checked] 
== <input type="checkbox" value="test" checked> ; OK

>> build-tag [input type checkbox value test checked /]

== <input type="checkbox" value="test" checked="/"> ; Not OK, but 
required in all XHTM Lstandards.

I'm not sure if it's the best way, but could it be solved by checking 
for /, "/" or #"/" as well as tail position in the block.

What do you mean?

what I mean is that for single-standing tags, like <br>, XHTML 1.0 
and upwards requires them to end with a slash. This creates a correct 
tag for this case:

>> build-tag [input type checkbox value test /]
== <input type="checkbox" value="test" />

But this is not correct:

>> build-tag [input type checkbox value test checked /]
== <input type="checkbox" value="test" checked="/">

build-tag was probably adapted to support the earlier specification.

The correct tag required by XHTML is:
>> build-tag [input type checkbox value test checked checked /]
== <input type="checkbox" value="test" checked="checked" />

is checked="checked" really correct?

interesting. it is correct.

Yep, xhtml requires paired attributes.

>> f: %"test dir"
== %test dir
>> make-dir f
== %test dir/
>> read f
** Access Error: Cannot open /d/rebol/test dir
** Near: read f

I'd say it's a bug

a very old bug

but good it was found. that revealed 4 bugs in R3 there. :-)

eeek!

I make a habit of testing R2 bugs in R3 as well.

I think i've seen this bug before too ....

I have to work around it in my database system.

I'm trying to rename a few 100 directories to conform to a naming 
scheme

It's annoying having to work round this .. and also that rename doesn't 
work except in the current directory.

yes, it's quite annoying

I've been telling my clients for years not to install REBOL applications 
in folders that have a space in the name -- like "program files/rebol"
It just creates too many problems.

My virtual filesystem (in QM) simply doesn't allow them.  Same reason 
-- too many problems...

what problems?

I use them all the time.

There are three ways to handle such directories that I'm aware of:

you can use the short directory format:

change-dir %/c/progra~1/

you can use the long directory format:

change-dir %/c/program files/

or you can just use the native format:

change-dir to-rebol-file "c:/program files/"

If you want to the know the short format for a directory just use 
the dir/x command from the command prompt.

All three of which are a pain.

(one is platform dependent)