World: r3wp
[Core] Discuss core issues
older newer | first last |
Henrik 9-Jul-2008 [10754] | Tim, it's probably better to not use money! when rounding. |
Sunanda 9-Jul-2008 [10755x2] | 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] ] ] ] | |
Henrik 9-Jul-2008 [10757] | 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 :-)). |
Pekr 9-Jul-2008 [10758] | infinite = 27 positions, IIRC ... |
Henrik 9-Jul-2008 [10759] | thanks, couldn't remember |
Chris 13-Jul-2008 [10760x2] | Uck, this is unsightly: >> to-path [ [ a [ b [ c [ ] == a/ b/ c |
Why does it not result in: == a/b/c | |
[unknown: 5] 13-Jul-2008 [10762x2] | 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 | |
Chris 13-Jul-2008 [10764x4] | 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. | |
Gabriele 14-Jul-2008 [10768] | 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.) |
Henrik 14-Jul-2008 [10769] | 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. |
[unknown: 5] 14-Jul-2008 [10770] | 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. |
Chris 14-Jul-2008 [10771] | Gab: just want to be sure, I know that one man's bug is another man's feature... |
eFishAnt 14-Jul-2008 [10772] | I'll RebIT to that! |
TimW 17-Jul-2008 [10773] | 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. |
Henrik 21-Jul-2008 [10774x2] | >> 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. | |
Geomol 21-Jul-2008 [10776] | What do you mean? |
Henrik 21-Jul-2008 [10777] | 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="/"> |
[unknown: 5] 21-Jul-2008 [10778] | build-tag was probably adapted to support the earlier specification. |
Davide 21-Jul-2008 [10779] | The correct tag required by XHTML is: >> build-tag [input type checkbox value test checked checked /] == <input type="checkbox" value="test" checked="checked" /> |
Henrik 21-Jul-2008 [10780x2] | is checked="checked" really correct? |
interesting. it is correct. | |
Chris 21-Jul-2008 [10782] | Yep, xhtml requires paired attributes. |
Graham 23-Jul-2008 [10783] | >> f: %"test dir" == %test dir >> make-dir f == %test dir/ >> read f ** Access Error: Cannot open /d/rebol/test dir ** Near: read f |
Henrik 23-Jul-2008 [10784] | I'd say it's a bug |
Graham 23-Jul-2008 [10785] | a very old bug |
Henrik 23-Jul-2008 [10786] | but good it was found. that revealed 4 bugs in R3 there. :-) |
Graham 23-Jul-2008 [10787] | eeek! |
Henrik 23-Jul-2008 [10788] | I make a habit of testing R2 bugs in R3 as well. |
Graham 23-Jul-2008 [10789] | I think i've seen this bug before too .... |
Henrik 23-Jul-2008 [10790] | I have to work around it in my database system. |
Graham 23-Jul-2008 [10791x2] | 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. | |
Henrik 23-Jul-2008 [10793] | yes, it's quite annoying |
Sunanda 23-Jul-2008 [10794] | 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. |
Chris 23-Jul-2008 [10795] | My virtual filesystem (in QM) simply doesn't allow them. Same reason -- too many problems... |
[unknown: 5] 23-Jul-2008 [10796x4] | 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. | |
Chris 23-Jul-2008 [10800x2] | All three of which are a pain. |
(one is platform dependent) | |
[unknown: 5] 23-Jul-2008 [10802] | Pain as compared to what? |
Chris 23-Jul-2008 [10803] | Not dealing with spaces. |
older newer | first last |