I love regex. Haters hate.
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I'm with you - I use regex a lot if I can...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Is indeed astounding about the brain which first conceived the regex. And the first coder who implemented it. Ordinary users like me make mistakes in formulating regular expressions; just imagine how rock solid must be the code which does the parsing.
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yes, I used an easier path: go to json.org[^] and follow their "railway diagram" for numbers :laugh: (It is very close/identical to your graph) That's how I did mine: mlib/src/json.cpp at master · neacsum/mlib · GitHub[^]
Mircea
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I hate regexp. Mostly because I only have a need for it once every decade and I forget about it.
CI/CD = Continuous Impediment/Continuous Despair
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I like your Visual FA project. You don't want to allow
-0.xxx? -
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I only hate it because I can't understand it. I have yet to find the tutorial that explains it in a way I can understand it.
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes) -
I like your Visual FA project. You don't want to allow
-0.xxx?That regex is in error, and I've since updated it, but not the post.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Yes, I used an easier path: go to json.org[^] and follow their "railway diagram" for numbers :laugh: (It is very close/identical to your graph) That's how I did mine: mlib/src/json.cpp at master · neacsum/mlib · GitHub[^]
Mircea
I find their railway diagram to be much harder to follow than my state diagram.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I find their railway diagram to be much harder to follow than my state diagram.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Ha! That's proof positive that you didn't play enough with model trains when you were little. :laugh:
Mircea
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I think I would have probably created the state machine from scratch instead of trying to describe the valid input with that regex! :wtf:
FormerBIOSGuy
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
It's nothing to do with love or hate. I recognise regular expressions' utility, but simply don't use (or need) them often enough to be comfortable with them.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
It's nothing to do with love or hate. I recognise regular expressions' utility, but simply don't use (or need) them often enough to be comfortable with them.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
You wouldn't be one of the haters I was referring to then. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
(not read all replies so it might been discussed already) How about being able to parse leading zero's? They do not occur often, but these are valid ascii representations of numbers. E.g. -000123.456 or 0000042 may not be efficient but very well parsable. Supporting leading zeros would add two edges to your dfa.
-
(not read all replies so it might been discussed already) How about being able to parse leading zero's? They do not occur often, but these are valid ascii representations of numbers. E.g. -000123.456 or 0000042 may not be efficient but very well parsable. Supporting leading zeros would add two edges to your dfa.
Not valid JSON, IIRC. Though my regex has since been updated. The one in the original post was not compliant.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Is indeed astounding about the brain which first conceived the regex. And the first coder who implemented it. Ordinary users like me make mistakes in formulating regular expressions; just imagine how rock solid must be the code which does the parsing.
Parsing it is a lot easier than it seems. The thing about a regular language is it's very ... regular. The code is predictable to write, which makes things much smoother. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Not valid JSON, IIRC. Though my regex has since been updated. The one in the original post was not compliant.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
You are right, integers starting with a 0 are considered OCTAL in many programming languages (except zero itself). - https://stackoverflow.com/questions/27361565/why-is-json-invalid-if-an-integer-begins-with-a-leading-zero[^] Numbers with leading zeros should thus be a "string" in JSON. My thoughts came from parsing input from users and/or tabular data from files but that is not JSON. Thanks!
-
You are right, integers starting with a 0 are considered OCTAL in many programming languages (except zero itself). - https://stackoverflow.com/questions/27361565/why-is-json-invalid-if-an-integer-begins-with-a-leading-zero[^] Numbers with leading zeros should thus be a "string" in JSON. My thoughts came from parsing input from users and/or tabular data from files but that is not JSON. Thanks!
rob tillaart wrote:
integers starting with a 0 are considered OCTAL in many programming languages (except zero itself).
Why would that be an exception? What would happen if 0 were interpreted as octal zero? :-)
Religious freedom is the freedom to say that two plus two make five.
-
rob tillaart wrote:
integers starting with a 0 are considered OCTAL in many programming languages (except zero itself).
Why would that be an exception? What would happen if 0 were interpreted as octal zero? :-)
Religious freedom is the freedom to say that two plus two make five.
> What would happen if 0 were interpreted as octal zero? answer 1: Nothing answer 2: unless the parser expects additional digits {0..7}
-
For reasons I have to hand implement a parser for JSON numbers that can operate over a stream parsing part of the number with each fetch. It's kind of difficult, so I fired up my Visual FA C# project and fed it this code
var number = FA.Parse(@"(0|-?([1-9][0-9]*))((\.[0-9]+[Ee]\-?[1-9][0-9]*)?|\.[0-9]+)");
var dgo = new FADotGraphOptions();
dgo.HideAcceptSymbolIds = true;
number = number.ToMinimizedDfa();
number.RenderToFile(@"..\..\..\number.jpg",dgo);which gave me this which I can use to guide my hand rolled implementation: DFA state diagram[^] Bam! Now it makes it easy to write what is pretty complicated code by following this graph. The code that I need to write to be clear, must be able to parse a very long number. For example 3.14159265358979462643 and parse it using say, 8 bytes of memory for the capture, so it can parse 8 characters at a time. Real world those figures would be larger, but the principle is the same. If you have an easier way, put it in the replies. :) I'd love to hear them, honestly. Otherwise I'm sticking with my regex solution because I can't think of a more direct route from A to B. Edit: Aaand my regex was wrong (not quite JSON spec) so I since fixed it but haven't updated this post to reflect the changes. Still, it was easy to change.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Anything that can be used to distinguish between us, who master it, and them, the primitive people who do not master it, is great! That goes for all sorts of technology, philosophy, culture, ... Whatever. Anything that let you excel over others is essential to your self image. If it were so simple to understand that your old mother (and grandmother) could easily understand it, then you could impress noone with it.
Religious freedom is the freedom to say that two plus two make five.
-
Anything that can be used to distinguish between us, who master it, and them, the primitive people who do not master it, is great! That goes for all sorts of technology, philosophy, culture, ... Whatever. Anything that let you excel over others is essential to your self image. If it were so simple to understand that your old mother (and grandmother) could easily understand it, then you could impress noone with it.
Religious freedom is the freedom to say that two plus two make five.
Personally I'm more about the utility and mathematical purity of it.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
