Support Formal Front-End of Float Type Data #470

Alexius-Huang · 2017-10-20T07:07:52Z

Currently using the Go float64 datatype to support for Goby's float type data

Small issue to address - cases below will show the correct result

(3.14159265358979).to_d.to_s # => "3.14159265358979"
(-273.150000000).to_d.to_s # => "-273.15"

# and without the round bracket
3.14159265358979.to_d.to_s # => "3.14159265358979"

However, there is a case when a negative valued float type number cannot call method without round bracket which I've labeled with a TODO

-273.150000000.to_d.to_s # ERROR

See #526

Another thing to address is that, currently this PR only support the basic format of Float API (and because this PR is big enough), so to implement the special format of float, e.g. the exponential format as described in issue #471, welcome to contribute another PR

houndci-bot · 2017-10-20T07:08:02Z

compiler/parser/expression_parsing.go

+	if ok && p.peekTokenIs(token.Int) {
+		// When both receiver & caller are integer => Float
+		return p.parseFloatLiteral(receiver)
+	} else {


if block ends with a return statement, so drop this else and outdent its block

houndci-bot · 2017-10-20T07:08:02Z

compiler/ast/expressions.go

+}
+
+func (il *FloatLiteral) expressionNode() {}
+func (il *FloatLiteral) TokenLiteral() string {


exported method FloatLiteral.TokenLiteral should have comment or be unexported

houndci-bot · 2017-10-20T07:08:03Z

compiler/ast/expressions.go

@@ -19,6 +19,19 @@ func (il *IntegerLiteral) String() string {
 	return il.Token.Literal
 }

+type FloatLiteral struct {


exported type FloatLiteral should have comment or be unexported

houndci-bot · 2017-10-20T07:08:03Z

compiler/parser/expression_parsing.go

+	if ok && p.peekTokenIs(token.Int) {
+		// When both receiver & caller are integer => Float
+		return p.parseFloatLiteral(receiver)
+	} else {


if block ends with a return statement, so drop this else and outdent its block

houndci-bot · 2017-10-20T07:08:03Z

compiler/ast/expressions.go

+}
+
+func (il *FloatLiteral) expressionNode() {}
+func (il *FloatLiteral) TokenLiteral() string {


exported method FloatLiteral.TokenLiteral should have comment or be unexported

houndci-bot · 2017-10-20T07:08:03Z

compiler/ast/expressions.go

@@ -19,6 +19,19 @@ func (il *IntegerLiteral) String() string {
 	return il.Token.Literal
 }

+type FloatLiteral struct {


exported type FloatLiteral should have comment or be unexported

houndci-bot · 2017-10-20T07:08:03Z

compiler/parser/expression_parsing.go

+	if ok && p.peekTokenIs(token.Int) {
+		// When both receiver & caller are integer => Float
+		return p.parseFloatLiteral(receiver)
+	} else {


if block ends with a return statement, so drop this else and outdent its block

houndci-bot · 2017-10-20T07:08:03Z

compiler/ast/expressions.go

+}
+
+func (il *FloatLiteral) expressionNode() {}
+func (il *FloatLiteral) TokenLiteral() string {


exported method FloatLiteral.TokenLiteral should have comment or be unexported

houndci-bot · 2017-10-20T07:08:03Z

compiler/ast/expressions.go

@@ -19,6 +19,19 @@ func (il *IntegerLiteral) String() string {
 	return il.Token.Literal
 }

+type FloatLiteral struct {


exported type FloatLiteral should have comment or be unexported

Alexius-Huang · 2017-10-20T07:10:53Z

@st0012 Can you hint me on writing tests about parseFloatLiteral or other kind of tests? I'm still a little confused and not sure about I'm on the right track. QAQ

st0012

I think you just need to make VM's tests all be passed for now

st0012 · 2017-10-20T08:29:24Z

vm/float_test.go

@@ -200,8 +200,8 @@ func TestFloatConversions(t *testing.T) {
 		input    string
 		expected interface{}
 	}{
-		{`'100.3'.to_f.to_i`, 100},
-		{`'100.3'.to_f.to_s`, "100.3"},
+		{`(100.3).to_i`, 100},


We should also support (or raise parsing error) when there's no parentheses around the float.

st0012 · 2017-10-20T08:33:30Z

@Maxwell-Alexius We'll have an large reconstruction for our compiler's tests, so don't worry about adding parser tests now.

64kramsystem · 2017-10-20T08:35:21Z

For reference, programming languages generally support also the exponential format:

2E2
2e2
2e-2
20.0e2

I think this should be either implemented in this PR, or a separate issue should be created, for tracking purposes.

st0012 · 2017-10-20T08:37:13Z

@saveriomiroddi Thanks for reminding, I'll create another issue for this format.

codecov · 2017-10-24T09:34:16Z

Codecov Report

Merging #470 into master will decrease coverage by 0.3%.
The diff coverage is 44.68%.

@@            Coverage Diff             @@
##           master     #470      +/-   ##
==========================================
- Coverage    83.6%   83.29%   -0.31%     
==========================================
  Files          53       53              
  Lines        9325     9369      +44     
==========================================
+ Hits         7796     7804       +8     
- Misses       1289     1320      +31     
- Partials      240      245       +5

Impacted Files	Coverage Δ
compiler/token/token.go	`100% <ø> (ø)`	⬆️
compiler/bytecode/instruction.go	`62.5% <ø> (ø)`	⬆️
compiler/bytecode/expression_generation.go	`74.4% <0%> (-0.72%)`	⬇️
compiler/parser/data_type_parsing.go	`59.66% <0%> (-9.95%)`	⬇️
compiler/parser/parser.go	`79.47% <100%> (ø)`	⬆️
vm/float.go	`83.87% <100%> (-4.84%)`	⬇️
vm/json.go	`72.27% <62.5%> (-0.85%)`	⬇️
compiler/parser/expression_parsing.go	`52.22% <62.5%> (+0.31%)`	⬆️
vm/instruction.go	`94.36% <90%> (-0.38%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 407c3c1...3f86f8c. Read the comment docs.

Alexius-Huang · 2017-11-18T13:27:03Z

@st0012 Currently there is a small problem -- cases below will show the correct result

(3.14159265358979).to_d.to_s # => "3.14159265358979"
(-273.150000000).to_d.to_s # => "-273.15"

# and without the round bracket
3.14159265358979.to_d.to_s # => "3.14159265358979"

However, there is a case when a negative valued float type number cannot call method without round bracket which I've labeled with a TODO

-273.150000000.to_d.to_s # ERROR

Alexius-Huang · 2017-11-18T13:27:37Z

vm/float_test.go

+		3.14159265358979.to_d.to_s`,
+			"3.14159265358979"},
+		// TODO: Able to parse negative float value and call method without parentheses
+		//{`


Here is the small problem which is described in PR

Alexius-Huang · 2017-11-18T13:33:13Z

Another thing to address is that, currently this PR only support the basic format of Float API (and because this PR is big enough), so to implement the special format of float, e.g. the exponential format as described in issue #471, welcome to contribute another PR

st0012 · 2017-11-18T13:58:40Z

@saveriomiroddi Do you want to take a look before I merge this?

64kramsystem · 2017-11-18T19:34:07Z

compiler/parser/expression_parsing.go

+	_, ok := receiver.(*ast.IntegerLiteral)
+
+	// When both receiver & caller are integer => Float
+	if ok && p.peekTokenIs(token.Int) {


Based on this code, expresions with spaces on the sides of the dot will be parsed as floats (eg. 2 . 3).

If this is intended (other scripting languages forbid it), I think it should be documented with a test case.

Actually currently Goby doesn't recognize white space, so it's not just float has this issue, like:

[] . length #=> 0

But this shouldn't be too hard to solve I think, already have a rough idea. But that won't be included in this PR.

64kramsystem · 2017-11-18T19:35:06Z

vm/float.go

@@ -438,7 +438,7 @@ func (f *FloatObject) numericComparison(t *thread, rightObject Object, operation
 // toString returns the object's value as the string format, in non
 // exponential format (straight number, without exponent `E<exp>`).
 func (f *FloatObject) toString() string {
-	return strconv.FormatFloat(f.value, 'f', -1, 64)
+	return strconv.FormatFloat(f.value, 'f', -1, 64) // fmt.Sprintf("%f", f.value)


Is the comment intended?

Alexius-Huang requested a review from a team October 20, 2017 07:07

ghost assigned Alexius-Huang Oct 20, 2017

ghost added the in progress label Oct 20, 2017

houndci-bot reviewed Oct 20, 2017

View reviewed changes

st0012 requested changes Oct 20, 2017

View reviewed changes

Alexius-Huang force-pushed the feature/issue-379-float-type-front-end branch 2 times, most recently from a26852c to d968d3f Compare October 24, 2017 09:00

Alexius-Huang force-pushed the feature/issue-379-float-type-front-end branch 2 times, most recently from e428340 to 5991cbe Compare October 27, 2017 07:08

Alexius-Huang changed the title ~~[WIP] Support Formal Front-End of Float Type Data~~ Support Formal Front-End of Float Type Data Oct 27, 2017

Alexius-Huang changed the title ~~Support Formal Front-End of Float Type Data~~ [WIP] Support Formal Front-End of Float Type Data Oct 27, 2017

Alexius-Huang changed the title ~~[WIP] Support Formal Front-End of Float Type Data~~ Support Formal Front-End of Float Type Data Oct 27, 2017

Alexius-Huang force-pushed the feature/issue-379-float-type-front-end branch from e0c381c to c365987 Compare October 27, 2017 08:42

st0012 mentioned this pull request Nov 5, 2017

[Experimental] Decimal class #502

Merged

23 tasks

Alexius-Huang force-pushed the feature/issue-379-float-type-front-end branch from 4d9bb06 to e935aec Compare November 18, 2017 11:19

Alexius-Huang added 7 commits November 18, 2017 19:23

Complete float literal and token part

d462c96

Support PutFloat instruction

6cba315

Rescue test case for JSON parse in float format

e1cbef0

Rescue some case for float type data

a05cf14

Fix errors and refactor the float expression parsing part

10f8a0a

Fix the comment in expression.go

d151ecd

Rebase master

19972aa

Alexius-Huang force-pushed the feature/issue-379-float-type-front-end branch from e935aec to 19972aa Compare November 18, 2017 11:24

Alexius-Huang commented Nov 18, 2017

View reviewed changes

Alexius-Huang mentioned this pull request Nov 18, 2017

Fix Negative Float Type Data Parsing #526

Closed

st0012 requested a review from 64kramsystem November 18, 2017 15:26

64kramsystem reviewed Nov 18, 2017

View reviewed changes

Merge branch 'master' into feature/issue-379-float-type-front-end

3f86f8c

ghost assigned st0012 Nov 25, 2017

st0012 approved these changes Nov 25, 2017

View reviewed changes

st0012 merged commit fd60f81 into master Nov 25, 2017

ghost removed the in progress label Nov 25, 2017

st0012 deleted the feature/issue-379-float-type-front-end branch January 15, 2018 11:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support Formal Front-End of Float Type Data #470

Support Formal Front-End of Float Type Data #470

Alexius-Huang commented Oct 20, 2017 •

edited

Loading

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

houndci-bot Oct 20, 2017

Alexius-Huang commented Oct 20, 2017

st0012 left a comment

st0012 Oct 20, 2017

st0012 commented Oct 20, 2017

64kramsystem commented Oct 20, 2017 •

edited

Loading

st0012 commented Oct 20, 2017

codecov bot commented Oct 24, 2017 •

edited

Loading

Alexius-Huang commented Nov 18, 2017 •

edited

Loading

Alexius-Huang Nov 18, 2017

Alexius-Huang commented Nov 18, 2017

st0012 commented Nov 18, 2017

64kramsystem Nov 18, 2017 •

edited

Loading

st0012 Nov 19, 2017

64kramsystem Nov 18, 2017

Support Formal Front-End of Float Type Data #470

Support Formal Front-End of Float Type Data #470

Conversation

Alexius-Huang commented Oct 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Alexius-Huang commented Oct 20, 2017

st0012 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

st0012 commented Oct 20, 2017

64kramsystem commented Oct 20, 2017 • edited Loading

st0012 commented Oct 20, 2017

codecov bot commented Oct 24, 2017 • edited Loading

Codecov Report

Alexius-Huang commented Nov 18, 2017 • edited Loading

Choose a reason for hiding this comment

Alexius-Huang commented Nov 18, 2017

st0012 commented Nov 18, 2017

64kramsystem Nov 18, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Alexius-Huang commented Oct 20, 2017 •

edited

Loading

64kramsystem commented Oct 20, 2017 •

edited

Loading

codecov bot commented Oct 24, 2017 •

edited

Loading

Alexius-Huang commented Nov 18, 2017 •

edited

Loading

64kramsystem Nov 18, 2017 •

edited

Loading