1. Phix value() function
- Posted by RobertS in January
- 593 views
This is about something old, unurgent and probably of limited general interest …
The Phix documentation says about sequence s = value(string st):
Note this is an "inherited" routine, that I don’t much like. Whenever I try to use it, I tend to get stuck, give up, and roll my own. However if it works for you, then fine.
It luckily works for me — converting strings to numbers is something I can't do without — but, what is wrong with value(), and is there a recommended alternative? (Sorry if I've missed something obvious.)
Also,
After reading one valid representation of a phix object, value() will stop reading and ignore any additional characters in the string. For example, "36" and "36P" will both give you {GET_SUCCESS, 36}.
What I do, rather clumsily, to decide whether a string is actually a valid number, is that I add "9" to the string, and see whether this changes the value — in the above example, "36" and "369" give different values (so, yes, 36 is a number), while the values of "36P" and "36P9" will be the same (therefore, 36P is not a number). It works, but is there a less clumsy way to decide?
As I've said, it works for me, but Pete's threat regarding inherited routines, "any grief may lead to an offending routine simply being removed rather than fixed," has me worried! :)
Robert
2. Re: Phix value() function
- Posted by petelomax in January
- 584 views
Try to_number() or to_integer()
There are also some subtle inaccuracies inherent with conversion to human-readable decimal and back.
Some numbers deserve printing to 3 or 4 more digits than you might first think, and some (can't remember
which but 0.3 probably isn't one) where you might assume "0.300000000000000001" is more accurate but
it turns out that "0.3" is actually better. While [de]serialise() are somewhat more opaque, they are much
safer (for squirting over the internet as hex-encoded bytes) and both shorter/faster and more accurate
than get/value().
Those warnings have been there quite a while, and nothing has yet suffered that fate/threat. They seem to
do their job of making people consider alternatives, and not rely on them too heavily or expect miracles.
3. Re: Phix value() function
- Posted by RobertS in January
- 558 views
Thank you, I hadn't been aware of to_number()!
But while it would solve the "is this actually a valid number?" issue, I can't use it in Hypatia, because it doesn't accept &b… and &h… for binary and hex numbers (and I can't use #… for hex numbers, because PHP-inspired # begins comment lines, etc.) Also, I'm not that happy that to_number() allows/ignores underscore characters in a number (why?), which allows for some possible typo mishaps.
Btw, you say, This routine also allows eg "65'A'" which is treated as if it was just "65" — not that I understand what this is about, but when I try
? to_number("65'A'")
Phix crashes — which means, user input could crash the program, which is another thing I wouldn't be happy about — probably a bug that you will fix, but my main issue is still with &b… and &h…
But, if you promise I can keep using value(), I'm happy enough!
Robert
4. Re: Phix value() function
- Posted by petelomax in January
- 542 views
it doesn't accept &b… and &h… for binary and hex numbers
I'm confused: are you saying value() does accept &b and &h?
to_number() allows/ignores underscore characters in a number (why?)
Just because 1_000_000_000 is easier to read than 100000000, and in some senses easier to type (and partly because it don't allow/support 1,000,000,000).
Did you spot the deliberate typo I did there?
when I try ? to_number("65'A'") Phix crashes
Quite right, that was a silly bug, I'd even left myself a "this don't look right" comment just before that line, presumably while too busy to test/fix it, which I now have:
-- allow eg 65'A' to be the same as 65: --DEV could probably do with some more bounds checking here (spotted in passing) -- if scan_ch='\'' and s[sidx]=N and s[sidx+2]='\'' then if scan_ch='\'' and scan_ch2=N and sidx<length(s) and s[sidx+1]='\'' then
But, if you promise I can keep using value(), I'm happy enough!
Of course, I have no problem at all with that, especially "as-is".
I added a little "Don't panic" remark against that overly dramatic threat.
Pete
5. Re: Phix value() function
- Posted by RobertS in January
- 578 views
it doesn't accept &b… and &h… for binary and hex numbers
I'm confused: are you saying value() does accept &b and &h?
Omg — omg — omg, I am so incredibly stupid, I can't believe it! Sorry! In fact, I wrote my own routine to deal with &b and &h, and totally forgot that it was silently operating in the depths of Hypatia's engine room — my only excuse being that this was in 2007, and I never thought about it again, always assuming it was value() itself that processed binary and hex input.
So, yes, sure, since I already have this routine, I could use it with to_number() just as well. I withdraw my objection against it!
to_number() allows/ignores underscore characters in a number (why?)
Just because 1_000_000_000 is easier to read than 100000000, and in some senses easier to type (and partly because it don't allow/support 1,000,000,000).
Did you spot the deliberate typo I did there?
I'd write 1Esomething :)
But yes, I see your point — just, would it be possible to allow _ only where it might belong — that is, 7_000 would be ok, but 70_00 not?
But admittedly, this is a minor issue, and if I really feel it's worth the effort I could do it myself, but it's probably not.
I added a little "Don't panic" remark against that overly dramatic threat.
Thank you! :)
And again, forgive my stupidity not to remember my own code!
Robert
