mini-jstorch 1.8.2 → 2.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/Docs/About.md +84 -83
- package/Docs/Structure.md +115 -128
- package/README.md +70 -31
- package/demo/fu_fun.js +71 -71
- package/demo/linear_regression.js +42 -0
- package/demo/xor_classification.js +47 -0
- package/package.json +23 -23
- package/src/jstorch.js +838 -166
package/Docs/About.md
CHANGED
|
@@ -1,83 +1,84 @@
|
|
|
1
|
-
# Mini-JSTorch — Technical Information
|
|
2
|
-
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
## General Information
|
|
6
|
-
|
|
7
|
-
- **Project Name:** mini-jstorch
|
|
8
|
-
- **Internal Name:** JST (JST-orch)
|
|
9
|
-
|
|
10
|
-
> Note:
|
|
11
|
-
> Early versions of JST do not strictly follow semantic versioning conventions
|
|
12
|
-
> (e.g. `0.0.1` for patches, `0.1.0` for minor releases, `1.0.0` for major releases).
|
|
13
|
-
> This inconsistency reflects the early learning and experimental phase of the project.
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## 1. Engine Architecture Limitations (JST Core)
|
|
18
|
-
|
|
19
|
-
This section outlines the known structural weaknesses of the JST engine.
|
|
20
|
-
Although the architecture may appear complex, it is currently sensitive and tightly coupled.
|
|
21
|
-
|
|
22
|
-
### Identified Limitations
|
|
23
|
-
|
|
24
|
-
- **High dependency on Utilities**
|
|
25
|
-
Every core class depends directly on the Utilities module, which is defined at the top of the `jstorch.js` file. This creates strong coupling across the engine.
|
|
26
|
-
|
|
27
|
-
- **Limited Tensor dimensionality**
|
|
28
|
-
Tensor implementations currently support only two dimensions.
|
|
29
|
-
Extending support to higher-dimensional tensors would require significant architectural changes due to the existing complexity.
|
|
30
|
-
|
|
31
|
-
- **Uneven class complexity**
|
|
32
|
-
New or recently modified classes often become significantly more complex than others, leading to inconsistency in maintainability and internal design balance.
|
|
33
|
-
|
|
34
|
-
---
|
|
35
|
-
|
|
36
|
-
## 2. Rationale Behind the `fu_` Utilities
|
|
37
|
-
|
|
38
|
-
This section explains why the `fu_` utilities were introduced despite the existence of internal Utilities.
|
|
39
|
-
|
|
40
|
-
### Issues with Internal Utilities
|
|
41
|
-
|
|
42
|
-
- The Utilities defined at the beginning of `jstorch.js` are **internal engine helpers**, not intended for direct user interaction.
|
|
43
|
-
|
|
44
|
-
- These Utilities are heavily reused across multiple core classes.
|
|
45
|
-
Any modification to a utility function may trigger **cascading (domino) errors** throughout the engine due to tight dependencies.
|
|
46
|
-
|
|
47
|
-
- Some utility functions intentionally diverge from standard or expected formulas.
|
|
48
|
-
For example:
|
|
49
|
-
- Expected formula:
|
|
50
|
-
`Param1 - Param4 * Param3`
|
|
51
|
-
- Internal Utilities implementation:
|
|
52
|
-
`Param1 - Param2 * Param3 + Param4`
|
|
53
|
-
|
|
54
|
-
This behavior exists because internal Utilities are optimized for class-level computations, not for user-facing correctness or predictability.
|
|
55
|
-
|
|
56
|
-
### Purpose of `fu_` Utilities
|
|
57
|
-
|
|
58
|
-
The `fu_` utilities were designed to improve the **user experience** by providing:
|
|
59
|
-
|
|
60
|
-
- Predictable and correct computational behavior
|
|
61
|
-
- User-friendly and stable helper functions
|
|
62
|
-
- Isolation from internal engine changes
|
|
63
|
-
- Reduced risk of incorrect outputs and dependency-based cascading errors
|
|
64
|
-
|
|
65
|
-
In short, `fu_` exists to ensure safety, clarity, and consistency for end users of Mini-JSTorch.
|
|
66
|
-
|
|
67
|
-
---
|
|
68
|
-
|
|
69
|
-
## 3. SJK (Shortcut JST Keywords) Reference
|
|
70
|
-
|
|
71
|
-
This section lists commonly used abbreviations and keywords within the mini-jstorch ecosystem.
|
|
72
|
-
|
|
73
|
-
**Format:** `"KEYWORD" : "Full Name / Meaning"`
|
|
74
|
-
|
|
75
|
-
- `"JST"` : JSTorch
|
|
76
|
-
- `"fu"` : For User / User-Friendly
|
|
77
|
-
- `"fun"` : Function
|
|
78
|
-
- `"Dummy"` : Experimental
|
|
79
|
-
- `"Exp"` : Restricted experimental entity
|
|
80
|
-
- `"msg"` : Message, comment, warning, announcement
|
|
81
|
-
- `"donot"` : Do not / Don't
|
|
82
|
-
|
|
83
|
-
|
|
1
|
+
# Mini-JSTorch — Technical Information
|
|
2
|
+
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
## General Information
|
|
6
|
+
|
|
7
|
+
- **Project Name:** mini-jstorch
|
|
8
|
+
- **Internal Name:** JST (JST-orch)
|
|
9
|
+
|
|
10
|
+
> Note:
|
|
11
|
+
> Early versions of JST do not strictly follow semantic versioning conventions
|
|
12
|
+
> (e.g. `0.0.1` for patches, `0.1.0` for minor releases, `1.0.0` for major releases).
|
|
13
|
+
> This inconsistency reflects the early learning and experimental phase of the project.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## 1. Engine Architecture Limitations (JST Core)
|
|
18
|
+
|
|
19
|
+
This section outlines the known structural weaknesses of the JST engine.
|
|
20
|
+
Although the architecture may appear complex, it is currently sensitive and tightly coupled.
|
|
21
|
+
|
|
22
|
+
### Identified Limitations
|
|
23
|
+
|
|
24
|
+
- **High dependency on Utilities**
|
|
25
|
+
Every core class depends directly on the Utilities module, which is defined at the top of the `jstorch.js` file. This creates strong coupling across the engine.
|
|
26
|
+
|
|
27
|
+
- **Limited Tensor dimensionality**
|
|
28
|
+
Tensor implementations currently support only two dimensions.
|
|
29
|
+
Extending support to higher-dimensional tensors would require significant architectural changes due to the existing complexity.
|
|
30
|
+
|
|
31
|
+
- **Uneven class complexity**
|
|
32
|
+
New or recently modified classes often become significantly more complex than others, leading to inconsistency in maintainability and internal design balance.
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## 2. Rationale Behind the `fu_` Utilities
|
|
37
|
+
|
|
38
|
+
This section explains why the `fu_` utilities were introduced despite the existence of internal Utilities.
|
|
39
|
+
|
|
40
|
+
### Issues with Internal Utilities
|
|
41
|
+
|
|
42
|
+
- The Utilities defined at the beginning of `jstorch.js` are **internal engine helpers**, not intended for direct user interaction.
|
|
43
|
+
|
|
44
|
+
- These Utilities are heavily reused across multiple core classes.
|
|
45
|
+
Any modification to a utility function may trigger **cascading (domino) errors** throughout the engine due to tight dependencies.
|
|
46
|
+
|
|
47
|
+
- Some utility functions intentionally diverge from standard or expected formulas.
|
|
48
|
+
For example:
|
|
49
|
+
- Expected formula:
|
|
50
|
+
`Param1 - Param4 * Param3`
|
|
51
|
+
- Internal Utilities implementation:
|
|
52
|
+
`Param1 - Param2 * Param3 + Param4`
|
|
53
|
+
|
|
54
|
+
This behavior exists because internal Utilities are optimized for class-level computations, not for user-facing correctness or predictability.
|
|
55
|
+
|
|
56
|
+
### Purpose of `fu_` Utilities
|
|
57
|
+
|
|
58
|
+
The `fu_` utilities were designed to improve the **user experience** by providing:
|
|
59
|
+
|
|
60
|
+
- Predictable and correct computational behavior
|
|
61
|
+
- User-friendly and stable helper functions
|
|
62
|
+
- Isolation from internal engine changes
|
|
63
|
+
- Reduced risk of incorrect outputs and dependency-based cascading errors
|
|
64
|
+
|
|
65
|
+
In short, `fu_` exists to ensure safety, clarity, and consistency for end users of Mini-JSTorch.
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## 3. SJK (Shortcut JST Keywords) Reference
|
|
70
|
+
|
|
71
|
+
This section lists commonly used abbreviations and keywords within the mini-jstorch ecosystem.
|
|
72
|
+
|
|
73
|
+
**Format:** `"KEYWORD" : "Full Name / Meaning"`
|
|
74
|
+
|
|
75
|
+
- `"JST"` : JSTorch
|
|
76
|
+
- `"fu"` : For User / User-Friendly
|
|
77
|
+
- `"fun"` : Function
|
|
78
|
+
- `"Dummy"` : Experimental
|
|
79
|
+
- `"Exp"` : Restricted experimental entity
|
|
80
|
+
- `"msg"` : Message, comment, warning, announcement
|
|
81
|
+
- `"donot"` : Do not / Don't
|
|
82
|
+
// add more.
|
|
83
|
+
|
|
84
|
+
---
|
package/Docs/Structure.md
CHANGED
|
@@ -1,129 +1,116 @@
|
|
|
1
|
-
# Project File Structure #
|
|
2
|
-
|
|
3
|
-
This document describes the directory and file structure of the **mini-JSTorch** package.
|
|
4
|
-
It provides an overview of how the project is organized and the purpose of each major component.
|
|
5
|
-
|
|
6
|
-
---
|
|
7
|
-
|
|
8
|
-
## Repository Overview
|
|
9
|
-
|
|
10
|
-
```text
|
|
11
|
-
mini-jstorch/
|
|
12
|
-
├── demo/
|
|
13
|
-
│ ├── fu_fun.js
|
|
14
|
-
│ ├── MakeModel.js
|
|
15
|
-
│ └── scheduler.js
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
├──
|
|
20
|
-
│
|
|
21
|
-
|
|
22
|
-
│
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
- Notes: Defines dependencies, scripts, and package information
|
|
117
|
-
|
|
118
|
-
`README.md`
|
|
119
|
-
|
|
120
|
-
- Purpose: Main documentation entry
|
|
121
|
-
- Notes: Provides overview, installation instructions, and basic usage
|
|
122
|
-
|
|
123
|
-
**Notes**
|
|
124
|
-
|
|
125
|
-
- Experimental files may change or be restricted without notice
|
|
126
|
-
- Users are encouraged to rely on public APIs and documented utilities
|
|
127
|
-
- Internal structures are subject to refactoring as the project evolves
|
|
128
|
-
|
|
1
|
+
# Project File Structure #
|
|
2
|
+
|
|
3
|
+
This document describes the directory and file structure of the **mini-JSTorch** package.
|
|
4
|
+
It provides an overview of how the project is organized and the purpose of each major component.
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Repository Overview
|
|
9
|
+
|
|
10
|
+
```text
|
|
11
|
+
mini-jstorch/
|
|
12
|
+
├── demo/
|
|
13
|
+
│ ├── fu_fun.js
|
|
14
|
+
│ ├── MakeModel.js
|
|
15
|
+
│ └── scheduler.js
|
|
16
|
+
xor_classification.js
|
|
17
|
+
linear_regression.js
|
|
18
|
+
├── Docs/
|
|
19
|
+
│ ├── About.md
|
|
20
|
+
│ └── Structure.md
|
|
21
|
+
├── src/
|
|
22
|
+
│ ├── jstorch.js
|
|
23
|
+
│ └── Dummy/
|
|
24
|
+
│ └── msg/
|
|
25
|
+
├── index.js
|
|
26
|
+
├── package.json
|
|
27
|
+
└── README.md
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Directory Descriptions
|
|
33
|
+
|
|
34
|
+
`/demo`
|
|
35
|
+
|
|
36
|
+
- Contains demonstration and testing files.
|
|
37
|
+
|
|
38
|
+
- Used for unit testing, quick system checks, and example usage
|
|
39
|
+
- Intended for users who prefer practical examples over reading full API documentation
|
|
40
|
+
- Allows testing features without writing extensive manual code
|
|
41
|
+
|
|
42
|
+
`/Docs`
|
|
43
|
+
|
|
44
|
+
- Contains detailed documentation related to the mini-JSTorch package.
|
|
45
|
+
|
|
46
|
+
- Provides deeper explanations of internal design and usage
|
|
47
|
+
- Intended for contributors and advanced users
|
|
48
|
+
|
|
49
|
+
`/src`
|
|
50
|
+
|
|
51
|
+
- Contains the source code of the JSTorch engine.
|
|
52
|
+
|
|
53
|
+
- Houses all core logic and internal implementations
|
|
54
|
+
- Modifications in this directory directly affect engine behavior
|
|
55
|
+
|
|
56
|
+
`/src/Dummy`
|
|
57
|
+
|
|
58
|
+
- Experimental and restricted directory.
|
|
59
|
+
|
|
60
|
+
- Used for experimental purposes and future development
|
|
61
|
+
- Files inside this directory may be unstable or incomplete
|
|
62
|
+
- Not intended for public or production use
|
|
63
|
+
|
|
64
|
+
`/src/Dummy/msg`
|
|
65
|
+
|
|
66
|
+
- Contains warning or message files.
|
|
67
|
+
|
|
68
|
+
- Indicates that files within the `Dummy` directory are restricted
|
|
69
|
+
- Serves as a notification mechanism for experimental or future-update-related content
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## File Descriptions
|
|
74
|
+
|
|
75
|
+
`/Docs/About.md`
|
|
76
|
+
|
|
77
|
+
- Purpose: Contains additional information about the mini-JSTorch package
|
|
78
|
+
- Notes: May include background, design decisions, or non-API-related explanations
|
|
79
|
+
|
|
80
|
+
`/Docs/Structure.md`
|
|
81
|
+
|
|
82
|
+
- Purpose: Documents the repository file and folder structure
|
|
83
|
+
- Notes: This file
|
|
84
|
+
|
|
85
|
+
`/src/jstorch.js`
|
|
86
|
+
|
|
87
|
+
- Purpose: Core engine implementation
|
|
88
|
+
|
|
89
|
+
- Notes:
|
|
90
|
+
|
|
91
|
+
- Contains all JSTorch engine logic and functions
|
|
92
|
+
- Central file of the entire package
|
|
93
|
+
- Changes here have wide-ranging effects
|
|
94
|
+
|
|
95
|
+
`index.js`
|
|
96
|
+
|
|
97
|
+
- Purpose: Package entry point
|
|
98
|
+
- Notes: Exposes public APIs and connects internal modules
|
|
99
|
+
|
|
100
|
+
`package.json`
|
|
101
|
+
|
|
102
|
+
- Purpose: Project configuration and metadata
|
|
103
|
+
- Notes: Defines dependencies, scripts, and package information
|
|
104
|
+
|
|
105
|
+
`README.md`
|
|
106
|
+
|
|
107
|
+
- Purpose: Main documentation entry
|
|
108
|
+
- Notes: Provides overview, installation instructions, and basic usage
|
|
109
|
+
|
|
110
|
+
**Notes**
|
|
111
|
+
|
|
112
|
+
- Experimental files may change or be restricted without notice
|
|
113
|
+
- Users are encouraged to rely on public APIs and documented utilities
|
|
114
|
+
- Internal structures are subject to refactoring as the project evolves
|
|
115
|
+
|
|
129
116
|
---
|
package/README.md
CHANGED
|
@@ -1,12 +1,26 @@
|
|
|
1
|
-
## Mini-JSTorch
|
|
1
|
+
## Mini-JSTorch (MAJOR UPDATE)
|
|
2
2
|
|
|
3
|
+
---
|
|
3
4
|
|
|
4
5
|
Mini-JSTorch is a lightweight, `dependency-free` JavaScript neural network library designed for `education`, `experimentation`, and `small-scale models`.
|
|
5
6
|
It runs in Node.js and modern browsers, with a simple API inspired by PyTorch-style workflows.
|
|
6
7
|
|
|
7
8
|
This project prioritizes `clarity`, `numerical correctness`, and `accessibility` over performance or large-scale production use.
|
|
8
9
|
|
|
9
|
-
In this version `
|
|
10
|
+
In this version `2.0.0`, we introduce:
|
|
11
|
+
- **Fixed Linear layer cache** (critical bug fix for training)
|
|
12
|
+
- **Fixed GELU gradient calculation**
|
|
13
|
+
- **Fixed MSELoss gradient scaling**
|
|
14
|
+
- **Optimized Softmax gradient** (O(n²) → O(n))
|
|
15
|
+
- **Improved Tokenizer** with proper PAD/UNK separation
|
|
16
|
+
- **Added Sequential.zeroGrad(), train(), eval(), stateDict() methods**
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
**⚠️ BREAKING CHANGES in v2.0.0:**
|
|
21
|
+
- Tokenizer API: `tokenizeBatch()` → `transform()`, `detokenizeBatch()` → `inverseTransform()`
|
|
22
|
+
- Tokenizer now uses `<PAD>` at index 0 and `<UNK>` at index 1
|
|
23
|
+
- MSELoss gradient scale now matches PyTorch behavior
|
|
10
24
|
|
|
11
25
|
---
|
|
12
26
|
|
|
@@ -28,7 +42,6 @@ In this version `1.8.2`, we Introduce the **SoftmaxCrossEntropyLoss**, and **BCE
|
|
|
28
42
|
# Key Characteristics
|
|
29
43
|
|
|
30
44
|
- Zero dependencies
|
|
31
|
-
- ESM-first (`type: module`)
|
|
32
45
|
- Works in Node.js or others enviornments and browser environments
|
|
33
46
|
- Explicit, manual forward and backward passes
|
|
34
47
|
- Focused on 2D training logic (`[batch][features]`)
|
|
@@ -133,7 +146,7 @@ In Browser/Website:
|
|
|
133
146
|
# Loss Functions
|
|
134
147
|
|
|
135
148
|
- MSELoss
|
|
136
|
-
- CrossEntropyLoss (*legacy
|
|
149
|
+
- CrossEntropyLoss (*legacy*, use **SoftmaxCrossEntropy** instead)
|
|
137
150
|
- SoftmaxCrossEntropyLoss (**recommended**)
|
|
138
151
|
- BCEWithLogitsLoss (**recommended**)
|
|
139
152
|
|
|
@@ -150,7 +163,7 @@ In Browser/Website:
|
|
|
150
163
|
- LambdaLR
|
|
151
164
|
- ReduceLROnPlateau
|
|
152
165
|
- Regularization
|
|
153
|
-
- Dropout
|
|
166
|
+
- Dropout
|
|
154
167
|
- BatchNorm2D (*experimental*)
|
|
155
168
|
|
|
156
169
|
# Utilities
|
|
@@ -201,9 +214,9 @@ import {
|
|
|
201
214
|
} from "./src/jstorch.js";
|
|
202
215
|
|
|
203
216
|
const model = new Sequential([
|
|
204
|
-
new Linear(2,
|
|
217
|
+
new Linear(2, 8),
|
|
205
218
|
new ReLU(),
|
|
206
|
-
new Linear(
|
|
219
|
+
new Linear(8, 2) // logits output
|
|
207
220
|
]);
|
|
208
221
|
|
|
209
222
|
const X = [
|
|
@@ -215,7 +228,7 @@ const Y = [
|
|
|
215
228
|
];
|
|
216
229
|
|
|
217
230
|
const lossFn = new SoftmaxCrossEntropyLoss();
|
|
218
|
-
const optimizer = new Adam(model.parameters(), 0.1);
|
|
231
|
+
const optimizer = new Adam(model.parameters(), {lr: 0.1});
|
|
219
232
|
|
|
220
233
|
for (let epoch = 1; epoch <= 300; epoch++) {
|
|
221
234
|
const logits = model.forward(X);
|
|
@@ -223,13 +236,16 @@ for (let epoch = 1; epoch <= 300; epoch++) {
|
|
|
223
236
|
const grad = lossFn.backward();
|
|
224
237
|
model.backward(grad);
|
|
225
238
|
optimizer.step();
|
|
239
|
+
|
|
240
|
+
// Zero gradients for next iteration
|
|
241
|
+
model.zeroGrad();
|
|
226
242
|
|
|
227
243
|
if (epoch % 50 === 0) {
|
|
228
|
-
console.log(`Epoch ${epoch}, Loss: ${loss.toFixed(
|
|
244
|
+
console.log(`Epoch ${epoch}, Loss: ${loss.toFixed(6)}`);
|
|
229
245
|
}
|
|
230
246
|
}
|
|
231
247
|
```
|
|
232
|
-
Do not combine `SoftmaxCrossEntropyLoss` with a `Softmax` layer.
|
|
248
|
+
`Important:` Do not combine `SoftmaxCrossEntropyLoss` with a `Softmax` layer.
|
|
233
249
|
|
|
234
250
|
# Binary Classifiaction (BCEWithLogitsLoss)
|
|
235
251
|
|
|
@@ -243,21 +259,20 @@ import {
|
|
|
243
259
|
} from "./src/jstorch.js";
|
|
244
260
|
|
|
245
261
|
const model = new Sequential([
|
|
246
|
-
new Linear(2,
|
|
262
|
+
new Linear(2, 8),
|
|
247
263
|
new ReLU(),
|
|
248
|
-
new Linear(
|
|
264
|
+
new Linear(8, 1) // logit output
|
|
249
265
|
]);
|
|
250
266
|
|
|
251
267
|
const X = [
|
|
252
268
|
[0,0], [0,1], [1,0], [1,1]
|
|
253
269
|
];
|
|
254
|
-
|
|
255
270
|
const Y = [
|
|
256
271
|
[0], [1], [1], [0]
|
|
257
272
|
];
|
|
258
273
|
|
|
259
274
|
const lossFn = new BCEWithLogitsLoss();
|
|
260
|
-
const optimizer = new Adam(model.parameters(), 0.1);
|
|
275
|
+
const optimizer = new Adam(model.parameters(), {lr: 0.1});
|
|
261
276
|
|
|
262
277
|
for (let epoch = 1; epoch <= 300; epoch++) {
|
|
263
278
|
const logits = model.forward(X);
|
|
@@ -265,7 +280,37 @@ for (let epoch = 1; epoch <= 300; epoch++) {
|
|
|
265
280
|
const grad = lossFn.backward();
|
|
266
281
|
model.backward(grad);
|
|
267
282
|
optimizer.step();
|
|
283
|
+
model.zeroGrad();
|
|
284
|
+
|
|
285
|
+
// Print progress every 50 epochs
|
|
286
|
+
if (epoch % 50 === 0) {
|
|
287
|
+
const probs = logits.map(p => 1 / (1 + Math.exp(-p[0])));
|
|
288
|
+
console.log(`Epoch ${epoch} | Loss: ${loss.toFixed(6)}`);
|
|
289
|
+
probs.forEach((prob, i) => {
|
|
290
|
+
const pred = prob > 0.5 ? 1 : 0;
|
|
291
|
+
console.log(` [${X[i]}] → prob: ${prob.toFixed(4)} (${pred}) | target: ${Y[i][0]}`);
|
|
292
|
+
});
|
|
293
|
+
console.log('');
|
|
294
|
+
}
|
|
268
295
|
}
|
|
296
|
+
|
|
297
|
+
// Final evaluation
|
|
298
|
+
console.log("\nTraining Complete\n");
|
|
299
|
+
model.eval();
|
|
300
|
+
|
|
301
|
+
const finalLogits = model.forward(X);
|
|
302
|
+
const finalProbs = finalLogits.map(p => 1 / (1 + Math.exp(-p[0])));
|
|
303
|
+
|
|
304
|
+
console.log("Final Results:");
|
|
305
|
+
let correct = 0;
|
|
306
|
+
finalProbs.forEach((prob, i) => {
|
|
307
|
+
const pred = prob > 0.5 ? 1 : 0;
|
|
308
|
+
const target = Y[i][0];
|
|
309
|
+
const isCorrect = pred === target;
|
|
310
|
+
if (isCorrect) correct++;
|
|
311
|
+
console.log(` [${X[i]}] → ${prob.toFixed(4)} (${pred}) | target: ${target} ${isCorrect ? '✓' : '✗'}`);
|
|
312
|
+
});
|
|
313
|
+
console.log(`\nAccuracy: ${(correct / X.length * 100).toFixed(2)}%`);
|
|
269
314
|
```
|
|
270
315
|
Do not combine `BCEWithLogitsLoss` with a `Sigmoid` layer.
|
|
271
316
|
|
|
@@ -274,7 +319,8 @@ Do not combine `BCEWithLogitsLoss` with a `Sigmoid` layer.
|
|
|
274
319
|
# Save & Load Models
|
|
275
320
|
|
|
276
321
|
```javascript
|
|
277
|
-
|
|
322
|
+
// WARN: Error/Bug may be expected for this time!
|
|
323
|
+
import { saveModel, loadModel, Sequential } from "./src/jstorch.js";
|
|
278
324
|
|
|
279
325
|
const json = saveModel(model);
|
|
280
326
|
const model2 = new Sequential([...]); // same architecture
|
|
@@ -285,16 +331,18 @@ loadModel(model2, json);
|
|
|
285
331
|
|
|
286
332
|
# Demos
|
|
287
333
|
|
|
288
|
-
See the `demo/` directory for runnable examples
|
|
289
|
-
- `demo/
|
|
290
|
-
- `demo/
|
|
291
|
-
- `demo/
|
|
334
|
+
See the `demo/` directory for runnable examples!
|
|
335
|
+
- `demo/fu_fun.js`
|
|
336
|
+
- `demo/MakeModel.js`
|
|
337
|
+
- `demo/scheduler.js`
|
|
338
|
+
- `demo/xor_classification.js`
|
|
339
|
+
- `demo/linear_regression.js`
|
|
340
|
+
|
|
292
341
|
|
|
293
342
|
```bash
|
|
294
|
-
node demo
|
|
295
|
-
node demo/scheduler.js
|
|
296
|
-
node demo/fu_fun.js
|
|
343
|
+
node demo/<fileNameInDemo>.js
|
|
297
344
|
```
|
|
345
|
+
**Make sure your directory while run this at root folder!**
|
|
298
346
|
|
|
299
347
|
---
|
|
300
348
|
|
|
@@ -308,15 +356,6 @@ node demo/fu_fun.js
|
|
|
308
356
|
|
|
309
357
|
---
|
|
310
358
|
|
|
311
|
-
# Intended Use Cases
|
|
312
|
-
|
|
313
|
-
- Learning how neural networks work internally
|
|
314
|
-
- Teaching ML fundamentals
|
|
315
|
-
- Small experiments in Node.js or the browser
|
|
316
|
-
- Lightweight AI demos without GPU or large frameworks
|
|
317
|
-
|
|
318
|
-
---
|
|
319
|
-
|
|
320
359
|
# License
|
|
321
360
|
|
|
322
361
|
MIT License
|